FFMPEG Hardware De- oder Enkodierung: System mit Intel GPU (UHD 500) friert ein

[clang]

Hallo an alle! Ich hoffe ich bin im richtigen Unterforum.
Habe mein Osterwochenende damit verbracht, dieses Problem zu troubleshooten, deshalb möcht ich das jetzt irgendwo festhalten:

Problem: System friert nach kurzer Zeit komplett ein und reagiert nur noch auf Reset über Powerbutton, wenn ich per FFMPEG und VAAPI Hardwarebeschleunigung einen oder mehrere Streams transkodiere (de- und enkodiere). Das reproduzieren des Fehlers ist relativ einfach:

Code: Alles auswählen

ffmpeg -hwaccel vaapi -hwaccel_output_format vaapi -vaapi_device /dev/dri/renderD128 -i "${file}" -codec:v h264_vaapi  "${file}-x264_aac.mp4"

Wenn ich obigen Befehl auf ein oder mehreren Files ausführe, friert das System nach einigen Minuten komplett ein. Je mehr streams gleichzeitig, desto eher friert das System ein.

Hardware:
Intel NUC6CAYH
Intel Celeron J3455 ("Apollo Lake" oder "Goldmount")
Intel UHD 500
4GB Ram (memtest86+ ohne Fehler)

Software
Debian 10 (Kernel 5.10) & Debian 11 bzw. 11.5 (Kernel 5.10 und Kernel 6.1)

Leider gibt es keinerlei Errorlogs zu finden, weder in dmesg/journalctl -b -1 noch in den eigenen Intel Fehlerlogs.

Code: Alles auswählen

# /sys/module/i915# cat /sys/class/drm/card0/error
No error state collected

Ich habe wie geasgt, das ganze Osterwochende damit verbracht mich hier einzulesen, und vieles deutet auf verbuggte driver hin (eine der vielen Seiten die das nahlegen):
https://linuxreviews.org/Intel_graphics#Troubleshooting

Allerdings hab ich alle workarounds schon durchprobiert und nichts hat geklappt:
zur GRUB_CMDLINE_LINUX-Zeile in /etc/default/grub hinzefügt und dann "update-grub" neugestartet:

Code: Alles auswählen

i915.enable_psr=0 intel_idle.max_cstate=1 i915.enable_dc=0 ahci.mobile_lpm_policy=1

auch einzeln und zusätzlich

Code: Alles auswählen

i915.enable_sel_psr2_fetch=0

Habe auch versucht den Monitor per HDMI-Kabel an das Gerät (normal per VGA) anzuschließen, weil es wo hieß, dass das problem mit einem "Dummy-Adaptor" gelöst werden könnte. Hat auch nicht geholfen. Das Ganze tritt auch auf einer komplett frischen Debian 10 (Kernel 5.10) installation auf.

Jetzt würde man meinen: "Das muss doch ein Hardwareproblem sein", aber: In meiner Verzweiflung hab ich das ganze mal per Ubunut 22.04 probiert (Kernel 5.19) und siehe da, ich konnte Stundenlang transcodieren, selbst 6 Streams gleichzeitig, und das System ist nie eingefroren.

Ubunutu nutzt eine aktuellere Version des i915 (Graifktreiber) und iHD-Treiber; deshalb vermute ich dass es daran liegen könnte.

Hier die Infos von Debian:

Code: Alles auswählen

# journalctl | grep i915
Apr 11 00:53:41 suteki-omv kernel: i915 0000:00:02.0: [drm] VT-d active for gfx access
Apr 11 00:53:41 suteki-omv kernel: i915 0000:00:02.0: vgaarb: deactivate vga console
Apr 11 00:53:41 suteki-omv kernel: i915 0000:00:02.0: [drm] Using Transparent Hugepages
Apr 11 00:53:41 suteki-omv kernel: i915 0000:00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=io+mem
Apr 11 00:53:41 suteki-omv kernel: i915 0000:00:02.0: [drm] Disabling framebuffer compression (FBC) to prevent screen flicker with VT-d enabled
Apr 11 00:53:41 suteki-omv kernel: i915 0000:00:02.0: firmware: direct-loading firmware i915/bxt_dmc_ver1_07.bin
Apr 11 00:53:41 suteki-omv kernel: i915 0000:00:02.0: [drm] Finished loading DMC firmware i915/bxt_dmc_ver1_07.bin (v1.7)
Apr 11 00:53:41 suteki-omv kernel: [drm] Initialized i915 1.6.0 20201103 for 0000:00:02.0 on minor 0
Apr 11 00:53:41 suteki-omv kernel: fbcon: i915drmfb (fb0) is primary device
Apr 11 00:53:41 suteki-omv kernel: i915 0000:00:02.0: [drm] fb0: i915drmfb frame buffer device

Code: Alles auswählen

# vainfo
error: can't connect to X server!
libva info: VA-API version 1.10.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_10
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.10 (libva 2.10.0)
vainfo: Driver version: Intel iHD driver for Intel(R) Gen Graphics - 21.1.1 ()
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            : VAEntrypointVLD
      VAProfileMPEG2Main              : VAEntrypointVLD
      VAProfileH264Main               : VAEntrypointVLD
      VAProfileH264Main               : VAEntrypointEncSliceLP
      VAProfileH264High               : VAEntrypointVLD
      VAProfileH264High               : VAEntrypointEncSliceLP
      VAProfileJPEGBaseline           : VAEntrypointVLD
      VAProfileJPEGBaseline           : VAEntrypointEncPicture
      VAProfileH264ConstrainedBaseline: VAEntrypointVLD
      VAProfileH264ConstrainedBaseline: VAEntrypointEncSliceLP
      VAProfileVP8Version0_3          : VAEntrypointVLD
      VAProfileHEVCMain               : VAEntrypointVLD
      VAProfileHEVCMain10             : VAEntrypointVLD
      VAProfileVP9Profile0            : VAEntrypointVLD

Hat jemand eine Idee, wo ich noch nach logs gucken könnte?
Wie könnte ich die Treiber in Debian updaten? Könnte ich einfach die Treiberfiles aus Ubuntu in den entsprechenden Pfad in Debian ziehen? Wenn ja, was wären die Pfade?

[hikaru]

Ist deine vainfo-Ausgabe aus Debian oder Ubuntu? Sie könnte nämlich aus Bullseye stammen. Wenn sie also aus Ubuntu ist, dann ist da nichts neuer. Das sollte auch nicht das Problem sein. Die CPU ist 6 Jahre alt.
Sind bei dir intel-microcode und firmware-misc-nonfree installiert?

[clang]

Hallo Hikaru,

danke für die Antwort. vainfo stammt aus Debian Bullseye (11.5 - Kernel 6.1).

intel-microcode ist nicht installiert, firmware-misc-nonfree schon.

Code: Alles auswählen

dpkg -s intel-microcode
dpkg-query: package 'intel-microcode' is not installed and no information is available
Use dpkg --info (= dpkg-deb --info) to examine archive files.

Code: Alles auswählen

dpkg -s firmware-misc-nonfree
Package: firmware-misc-nonfree
Status: install ok installed
Priority: optional
Section: non-free/kernel
Installed-Size: 40435
Maintainer: Debian Kernel Team <debian-kernel@lists.debian.org>
Architecture: all
Multi-Arch: foreign
Source: firmware-nonfree
Version: 20210818-1~bpo11+1

In ubuntu ist intel-microcode installiert; soll ich das mal in debian nacholen?

Edit: Gleich getestet, aber leider wieder eingefroren nach ca. 2 Minuten. Danke aber für den Tipp! Dachte gar nicht daran, dass microcde updates nicht automatisch installiert werden.

[MSfree]

Diese Atom-CPUs haben einen Hardwarebug, den Intel (angeblich) erst mit dem Celeron N/J-4xxx gelöst haben will.

In den meisten Fällen hilft es, die Energiesparmodi der CPU zu begrenzen. Das geht mit der Kernelkommandozeile in /etc/default/grub mit

Code: Alles auswählen

GRUB_CMDLINE_LINUX_DEFAULT="intel_idle.max_cstate=1 processor.max_cstate=1"

Man kann auch versuchen, im UEFI Enhanced Speed Step auszuschalten, sofern man das im UEFI findet bzw, wenn es überhaupt zur Verfügung steht.

[clang]

Hallo MSfree,

danke für die Vorschläge. Ja, das habe ich auch öfter gelesen. SpeedStep deaktivieren hatte ich tatsächlich intuitiv als eine der ersten Sachen getestet als sich meine NAS das erste mal komplett aufgehängt hat, allerdings ohne die Modulparamenter.

Code: Alles auswählen

intel_idle.max_cstate=1

hatte ich schon mal versucht(mit aktiven SpeedStep).

Code: Alles auswählen

processor.max_cstate=1

könnte ich noch versuchen, aber in Ubuntu wird das ja auch nicht gesetzt, deshalb denke ich nicht, dass es daran liegen sollte.

Update, auch mit processor.max_cstate=1 bleibt das System leider hängen

[clang]

Weiteres update:
Hab nun auch die driver aus ubuntu ins debian reingeklatscht (glaub ich zumindest) aber auch hier blieb das system binnen 2-3 min. hängen:

Habe /usr/lib/x86_64-linux-gnu/dri/i915_dri.so und /usr/lib/modules/${kernel}/kernel/drivers/gpu/i915 von ubuntu nach debian kopiert; die dateien sind anscheinend acuh anders:

Code: Alles auswählen

root@debian:/usr/lib/modules/5.10.0-21-amd64/kernel/drivers/gpu# cksum i915/i915.ko
4144120331 6577929 i915/i915.ko #ubuntu driver
root@debian:/usr/lib/modules/5.10.0-21-amd64/kernel/drivers/gpu# cksum i915bak/i915.ko
4290304771 5762403 i915bak/i915.ko #debian driver

Ich bin mir leider nicht sicher, ob das überhaupt was gebracht hat, oder ob die driver ganz woanders liegen...

[MSfree]

Hab nun auch die driver aus ubuntu ins debian reingeklatscht (glaub ich zumindest) aber auch hier blieb das system binnen 2-3 min. hängen:

Mit Treibern hat das nichts zu tun.

Wenn die CPU aus einem der C-States hochkommt, kann es passieren, daß die Kiste sich aufhängt, vor allem, wenn irgendwo Last auf der Graphikhardware ist. Da du ja mit der Graphikhardware Videos trankodierst, ist genau das der Fall bei dir.

Es gibt im Linuxkernel seit mehreren Jahren unterschiedliche Versuche, dieses Problem zu vermeiden, indem der Kernel selbst versucht, die C-States zu unterdrücken, wenn ein bestimmter CPU-Typ erkannt wurde. Leider hat das bei einigen Rechner nicht zum Erfolg geführt. Auch das Unterdrücken der C-States mitttels Kernelparameter funktioniert nicht in allen Fällen.

Die Hardware ist schlicht fehlerhaft und dagegen hilft am Ende gar nichts ausser andere Hardware zu nutzen.

[Livingston]

Mit Treibern hat das nichts zu tun.
...
Die Hardware ist schlicht fehlerhaft und dagegen hilft am Ende gar nichts ausser andere Hardware zu nutzen.

Wie passt das zu obiger Aussage von clang im Eingangspost, dass es mit Ubuntu 22.04 und dessen Kernel 5.19 funktioniert?

[MSfree]

Wie passt das zu obiger Aussage von clang im Eingangspost, dass es mit Ubuntu 22.04 und dessen Kernel 5.19 funktioniert?

Der Fehler tritt zufällig auf. Beim Test mit Ubuntu war eventuell nur Glück im Spiel.

[clang]

Ja,da hast du grundsätzlich schon recht. Aber auf Debian schaffe ich es den Bug bzw. das Einfrieren konsistent innerhalb von 3 minuten herbeizuführen. Diesen Text tippe ich jetzt gerade auf der selben intel NUC auf der im Hintergrund seit über 30 Minuten bereits 5 Streams gleichzeitig in Schleife laufen...

Also irgendwas spielt da softwareseitig etwas mit...

[hikaru]

In ubuntu ist intel-microcode installiert; soll ich das mal in debian nacholen?

Falls du das noch nicht getan hast, dann ja, probier das mal!

Ob dein Debian allerdings überhaupt noch stabil laufen kann, nachdem du Teile von Ubuntu da reinkopiert hast, ist reines Glückspiel.

[clang]

Ja, das hatte ich tatsächlich auch schon probiert und neugestartet vor dem Test. Leider trotzdem hängen geblieben.

Eine aus der Luft gegriffene Vermutung habe ich noch: In Ubuntu wird ja standardmäßig eine Desktopumgebung geladen, die den 3D-Teil der Intel-GPU bemüht. Eventuell muss die GPU einmal "geweckt" werden, damit die Videohardware nicht crashed? Auf Debian habe ich keine Desktopumgebung, da es eine OMV-NAS ist.

Eventuell könnte ich auf der Test-Debian-Instanz (nachdem ich die Treiber wieder zurückgesetzt habe) mal eine Desktopumgebung installieren die auf der Intel GPU gerendered wird. Was wäre dafür der einfachste Weg? Einfach

Code: Alles auswählen

# apt install gnome

?

[Livingston]

gnome "fordert" zumindest viel und installiert auch einiges mit, was man u.U. nicht so im Blickfeld hat. Andererseits erschwert die höhere Komplexität das Debuggen.
Einfach mal gnome draufpacken und schauen, ob's klappt, ist aber dennoch eine Option. Wenn es funktioniert und das Einfrieren nicht mehr stattfindet, wird es wahrscheinlich an nachinstallierten Paketen und/oder Feineinstellungen liegen, die gnome vornimmt. Dann lässt sich vielleicht nachvollziehen, was die Erlösung schafft.
Deinstallieren wäre ja nachträglich kein Problem, daher lohnt es sich, das mal auszuprobieren.

[clang]

So, ich hab jetzt noch zwei sachen probiert:
1) Nach dem verschieben der driver hatte ich kein update-initramfs gemacht; hab das mal probiert, hat aber nichts gebracht, also driver wieder zurückgeschoben und Debian-Originalzustand wiederhergestellt.
2) Gnome installiert: Leider nach 2-3 min. wieder eingefroren....

Wie kann man das denn am besten reporten? Ich denk ich werde jetzt einfach ohne HW-Beschleunigung auskommen, aber ist schon doof, dass das in Ubuntu geht aber in Debian nicht... Auf Ubuntu umsatteln möcht ich für meine NAS eigentlich nicht. Hat sonst jemand noch einen Idee bzw. könnte mich wer beim Bugreport unterstützen? (Hab ich noch nie gemacht)

[ToterEngel]

Welchen CPU-Governor hast du denn eingestellt?
Das währe auch noch so ne Sache, wo Ubuntu gern mal selbst etwas rum murkst...

[clang]

Hi, ich hatte offensichtlich "conservative" auf meinem Porduktivsystem eingestellt. Zumindest war das der governor, den Debian automatisch genutzt hatte. Kann sein, dass das durch die installation von OMV gesetzt wurde, denn bei der test-installation von Debian war der auf "schedutil", wie auch in Ubuntu. Als ich cpufrequtils installiert habe, wurde er auf "ondemand" umgestellt.

Ich habe den Governor also mal auf der Test-Debian-Umgebung auf "performance" gestellt, da sollte die CPU ja immer volle-pulle laufen:

Code: Alles auswählen

for i in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor; do echo "performance" > $i; done

Code: Alles auswählen

root@debian:~# cpufreq-info
cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 0:
  driver: intel_cpufreq
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 20.0 us.
  hardware limits: 800 MHz - 2.30 GHz
  available cpufreq governors: conservative, powersave, userspace, ondemand, performance, schedutil
  current policy: frequency should be within 800 MHz and 2.30 GHz.
                  The governor "performance" may decide which speed to use
                  within this range.
  current CPU frequency is 2.20 GHz.
... (das selbe für die anderen 3 CPUs)

Tatsächlich läuft das hardware-basierte De- und Enkodieren damit etwas länger ohne Absturz... Hängt sich aber nach ca. 5 Minuten wieder auf.
Probeweise hatte ich auch "conservative" eingestellt bei Ubuntu, dort lief die Hardwaretranskondierung aber auch nach 15 Minuten noch munter weiter .
cpufreq-info sieht auch ansonsten identisch aus auf Ubuntu.

Ich bin echt ein bisschen am Ende mit meinem Latein.

(Den intel iHD-Treber schließe ich mal aus, weil das Abstürzen auch mit einem Dockercontainer zu beobachten ist (Debian) bzw. nicht passiert (Ubuntu) der folgende vainfo hat:

Code: Alles auswählen

./vainfo
Trying display: drm
libva info: VA-API version 1.18.0
libva info: Trying to open /usr/lib/jellyfin-ffmpeg/lib/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_18
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.18 (libva 2.18.0)
vainfo: Driver version: Intel iHD driver for Intel(R) Gen Graphics - 23.1.4 (12e141d)
vainfo: Supported profile and entrypoints
      VAProfileNone                   : VAEntrypointVideoProc
      VAProfileNone                   : VAEntrypointStats
      VAProfileMPEG2Simple            : VAEntrypointVLD
      VAProfileMPEG2Main              : VAEntrypointVLD
      VAProfileH264Main               : VAEntrypointVLD
      VAProfileH264Main               : VAEntrypointEncSlice
      VAProfileH264Main               : VAEntrypointFEI
      VAProfileH264Main               : VAEntrypointEncSliceLP
      VAProfileH264High               : VAEntrypointVLD
      VAProfileH264High               : VAEntrypointEncSlice
      VAProfileH264High               : VAEntrypointFEI
      VAProfileH264High               : VAEntrypointEncSliceLP
      VAProfileVC1Simple              : VAEntrypointVLD
      VAProfileVC1Main                : VAEntrypointVLD
      VAProfileVC1Advanced            : VAEntrypointVLD
      VAProfileJPEGBaseline           : VAEntrypointVLD
      VAProfileJPEGBaseline           : VAEntrypointEncPicture
      VAProfileH264ConstrainedBaseline: VAEntrypointVLD
      VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
      VAProfileH264ConstrainedBaseline: VAEntrypointFEI
      VAProfileH264ConstrainedBaseline: VAEntrypointEncSliceLP
      VAProfileVP8Version0_3          : VAEntrypointVLD
      VAProfileVP8Version0_3          : VAEntrypointEncSlice
      VAProfileHEVCMain               : VAEntrypointVLD
      VAProfileHEVCMain               : VAEntrypointEncSlice
      VAProfileHEVCMain               : VAEntrypointFEI
      VAProfileHEVCMain10             : VAEntrypointVLD
      VAProfileVP9Profile0            : VAEntrypointVLD

[clang]

Da ich sehr hartnäckig bin, habe ich weitergesucht und konnte folgenden Thread in den Unraid-Forums finden:
https://forums.unraid.net/bug-reports/p ... lake-r1674

Dort erwähntein User, dass er VT-d deaktiviert hat und somit sein System frei von Freezes blieb:

I tested in 6.10.3, when I disable vt-d in the bios, transcoding will not cause the unraid crash.

Das habe ich nun auchprobiert und siehe da... Keine crashes mehr. Diesen Post tippe ich gerade auf der Test-Debian-Instanz.

Der selbe User "airlychee" schreibt dann noch folgendes:

Today I enabled vt-d and added intel_iommu=igfx_off, no crashes occurred during transcoding.

Das muss ich noch probieren, klingt aber sehr vielversprechend! Eventuell liegt es also an intel_iommu... Das ist anscheinend (lt. schneller Google-Suche) in vielen Distros standardmäßig deaktiviert, eventuell auch in Ubuntu, aber dafür in Debian aktiv? Werde bei Zeiten nochmal testen, in der zwischenzeit freue ich mich über Absturzfreie Transkodierung

[hikaru]

Interessant! Hast du vorher irgendwelche "DMAR"-Fehlermeldungen [1] gesehen?

[1] https://www.kernel.org/doc/Documentatio ... -IOMMU.txt

[clang]

Nein, scheint keine Fehlermeldung zu geben, aber einige Warnungen mit "inconsistent":

Code: Alles auswählen

# journalctl -b -3 |grep DMAR
Apr 26 20:55:38 suteki-omv kernel: ACPI: DMAR 0x000000007B26D690 0000A8 (v01 INTEL  NUC6CAYB 00000003 BRXT 0100000D)
Apr 26 20:55:38 suteki-omv kernel: ACPI: Reserving DMAR table memory at [mem 0x7b26d690-0x7b26d737]
Apr 26 20:55:38 suteki-omv kernel: DMAR: Host address width 39
Apr 26 20:55:38 suteki-omv kernel: DMAR: DRHD base: 0x000000fed64000 flags: 0x0
Apr 26 20:55:38 suteki-omv kernel: DMAR: dmar0: reg_base_addr fed64000 ver 1:0 cap 1c0000c40660462 ecap 7e3ff0505e
Apr 26 20:55:38 suteki-omv kernel: DMAR: DRHD base: 0x000000fed65000 flags: 0x1
Apr 26 20:55:38 suteki-omv kernel: DMAR: dmar1: reg_base_addr fed65000 ver 1:0 cap d2008c40660462 ecap f050da
Apr 26 20:55:38 suteki-omv kernel: DMAR: RMRR base: 0x0000007b1ee000 end: 0x0000007b20dfff
Apr 26 20:55:38 suteki-omv kernel: DMAR: RMRR base: 0x0000007d800000 end: 0x0000007fffffff
Apr 26 20:55:38 suteki-omv kernel: DMAR-IR: IOAPIC id 1 under DRHD base  0xfed65000 IOMMU 1
Apr 26 20:55:38 suteki-omv kernel: DMAR-IR: HPET id 0 under DRHD base 0xfed65000
Apr 26 20:55:38 suteki-omv kernel: DMAR-IR: Queued invalidation will be enabled to support x2apic and Intr-remapping.
Apr 26 20:55:38 suteki-omv kernel: DMAR-IR: Enabled IRQ remapping in x2apic mode
Apr 26 20:55:38 suteki-omv kernel: DMAR: No ATSR found
Apr 26 20:55:38 suteki-omv kernel: DMAR: No SATC found
Apr 26 20:55:38 suteki-omv kernel: DMAR: IOMMU feature fl1gp_support inconsistent
Apr 26 20:55:38 suteki-omv kernel: DMAR: IOMMU feature pgsel_inv inconsistent
Apr 26 20:55:38 suteki-omv kernel: DMAR: IOMMU feature nwfs inconsistent
Apr 26 20:55:38 suteki-omv kernel: DMAR: IOMMU feature eafs inconsistent
Apr 26 20:55:38 suteki-omv kernel: DMAR: IOMMU feature prs inconsistent
Apr 26 20:55:38 suteki-omv kernel: DMAR: IOMMU feature nest inconsistent
Apr 26 20:55:38 suteki-omv kernel: DMAR: IOMMU feature mts inconsistent
Apr 26 20:55:38 suteki-omv kernel: DMAR: IOMMU feature sc_support inconsistent
Apr 26 20:55:38 suteki-omv kernel: DMAR: IOMMU feature dev_iotlb_support inconsistent
Apr 26 20:55:38 suteki-omv kernel: DMAR: dmar0: Using Queued invalidation
Apr 26 20:55:38 suteki-omv kernel: DMAR: dmar1: Using Queued invalidation
Apr 26 20:55:38 suteki-omv kernel: DMAR: Intel(R) Virtualization Technology for Directed I/O

Im Link den du gepostet hast, wird gebeten das ganze als Bug zu reporten, wenn iommu=igfx_off das problem behebt. Es scheinen ja doch einige betroffen zu sein. Wie würde ich da am Besten vorgehen?

Edit: Die "inconsistent" fehlermeldungen verschwinden mit intel_iommu=igfx_off

Code: Alles auswählen

root@suteki-omv:/etc# dmesg -T |grep DMAR
[Thu Apr 27 23:34:52 2023] ACPI: DMAR 0x000000007B26D690 0000A8 (v01 INTEL  NUC6CAYB 00000003 BRXT 0100000D)
[Thu Apr 27 23:34:52 2023] ACPI: Reserving DMAR table memory at [mem 0x7b26d690-0x7b26d737]
[Thu Apr 27 23:34:52 2023] DMAR: Disable GFX device mapping
[Thu Apr 27 23:34:52 2023] DMAR: Host address width 39
[Thu Apr 27 23:34:52 2023] DMAR: DRHD base: 0x000000fed64000 flags: 0x0
[Thu Apr 27 23:34:52 2023] DMAR: dmar0: reg_base_addr fed64000 ver 1:0 cap 1c0000c40660462 ecap 7e3ff0505e
[Thu Apr 27 23:34:52 2023] DMAR: DRHD base: 0x000000fed65000 flags: 0x1
[Thu Apr 27 23:34:52 2023] DMAR: dmar1: reg_base_addr fed65000 ver 1:0 cap d2008c40660462 ecap f050da
[Thu Apr 27 23:34:52 2023] DMAR: RMRR base: 0x0000007b1ee000 end: 0x0000007b20dfff
[Thu Apr 27 23:34:52 2023] DMAR: RMRR base: 0x0000007d800000 end: 0x0000007fffffff
[Thu Apr 27 23:34:52 2023] DMAR-IR: IOAPIC id 1 under DRHD base  0xfed65000 IOMMU 1
[Thu Apr 27 23:34:52 2023] DMAR-IR: HPET id 0 under DRHD base 0xfed65000
[Thu Apr 27 23:34:52 2023] DMAR-IR: Queued invalidation will be enabled to support x2apic and Intr-remapping.
[Thu Apr 27 23:34:52 2023] DMAR-IR: Enabled IRQ remapping in x2apic mode
[Thu Apr 27 23:34:52 2023] DMAR: No ATSR found
[Thu Apr 27 23:34:52 2023] DMAR: No SATC found
[Thu Apr 27 23:34:52 2023] DMAR: dmar1: Using Queued invalidation

[GregorS]

... Im Link den du gepostet hast, wird gebeten das ganze als Bug zu reporten, wenn iommu=igfx_off das problem behebt. Es scheinen ja doch einige betroffen zu sein. Wie würde ich da am Besten vorgehen?
...

Meine erste Anlaufstelle ist normalerweise der Hersteller des problematischen Dings.

Gibt's vielleicht dort eine Stelle, an der Du einen Bugreport abliefern kannst?

Gruß

Gregor

[clang]

Meinst du Intel? Ich weiß nicht genau, aber ich glaube kaum, dass die interessiert sind ein 8 Jahre altes Produkt noch irgendwie zu betreuen.

Ich dachte eher, dass das als Linux-Kernel-Bug reported werden sollte? Bzw. glaub ich, dass das gemeint war in dem Link weiter oben.

[GregorS]

Ich dachte eher, dass das als Linux-Kernel-Bug reported werden sollte? Bzw. glaub ich, dass das gemeint war in dem Link weiter oben.

Ja, klar. Ich hatte nur grad etwas im Kopf, das mit aktueller Hardware zu tun hatte.

Gruß

Gregor