NUC 11i3 - ein core immer mit 60% ausgelastet

Hi ich suche schon länger nach der Ursache. Leider reicht mein System / Linux Verständnis nicht zur Fehleingrenzung.

Ich habe 2 NUCs Der NUC mit 60% auf einem Core ist ein NUC11PAHi30Z. Der Andere ist ein NUC11PAHi3000 (der ist etwas älter und hat intern keine Thunderbolts, aber dafür einige Dig.Micros). Beide haben den Intel i3-1115G4.

Installiere ich die SSD (mit dem BM2LTS image) in den NUC11PAHi3 laufen alle 4 cores mit unter 6% load. In dem folgenden Bild seht ihr beide NUCs untereinander.

Ich habe nun die meisten Prozesse bereits angehalten. Hier die verbleibenden (sortiere ich nach CPU Last kommt da nichts mehr über 0,2%):

The content cannot be displayed because you do not have authorisation to view this content.

Ich vermute nun, dass der Kernel nicht mit der Hardware dieses NUC "harmoniert"

Nun hoffe ich auf euch. Falls es in ein anderes Forum sollte, bitte gerne verschieben !

nach

modprobe -r snd_hda_intel

ist Ruhe. Mal sehen welchen Param ich nun brauche damit der Treiber ohne Probs läuft. Der Unterschied der 2 NUC liegt ja unter anderem an den beim 60% NUC nicht vorhandenen DMICs. Aber der Parameter

snd_hda_intel.dmic_detect=0 hilft nicht (ev. veraltet)

Hier die enorme interuptzahl 1 Minute
cat /proc/interrupts | grep -iE 'snd|hda|audio|i915'
183: 0 0 5 577 IR-PCI-MSI-0000:00:02.0 0-edge i915
185: 0 0 0 973279 IR-PCI-MSI-0000:00:1f.3 0-edge snd_hda_intel:card0

Hier die Erläuterungen der KI, ohne dass das Problem bisher gelöst wäre:

Das grundlegende Problem Ihres Intel NUC 11 Pro (NUC11TNHi30Z) unter der BM2LTS-Distribution mit dem XanMod-Kernel (6.15) lässt sich in drei logische Ebenen unterteilen: die Hardware, das Linux-Timing und die Funktionsweise von Treibern.

Hier ist die Zusammenfassung dessen, was auf Ihrem System im Detail passiert:

1. Das Phänomen: Der „unsichtbare“ Interrupt-Sturm

Wenn Sie in htop sehen, dass ein CPU-Kern permanent mit 60 % ausgelastet ist, aber kein normaler Prozess (wie Ihr VDR) als Verursacher auftaucht, liegt das an Hardware-Interrupts (IRQs).
Interrupts sind dringende Signale der Hardware an die CPU (z. B.: "Ich habe neue Audiodaten für dich!"). Normalerweise verarbeitet die CPU diese Signale in Mikrosekunden und schläft dann weiter. Auf Ihrem NUC Pro feuert der HDMI-Audio-Chip jedoch über 319 Millionen Signale in einer unendlichen Schleife ab. Die CPU ist so stark damit beschäftigt, diese leeren Signale zu quittieren, dass ein Kern zu 60 % blockiert wird.

2. Die Ursache: Der Timing- und Hardware-Konflikt

Sie haben einen zweiten NUC (PAHi3), auf dem exakt dieselbe Konfiguration problemlos läuft. Dass Ihr Sorgenkind (TNHi30Z) abstürzt, liegt an zwei Faktoren:

• Der nolapic-timer-Parameter: Dieser Befehl in Ihrem GRUB schaltet den lokalen Hardware-Timer der einzelnen CPU-Kerne ab. Moderne Grafik- und Soundchips der 11. Intel-Generation benötigen diesen Timer jedoch zwingend für die Synchronisation des Audiotakts.
• Das Pro-Mainboard: Das Consumer-Modell (PAHi3) besitzt physikalisch verbaute Digitalmikrofone (DMIC) und fängt das fehlende Timingsignal über das BIOS intern ab. Ihr Pro-NUC (TNHi30Z) hat diese Mikrofone nicht verbaut, besitzt ein anderes Platinen-Layout und ein anderes BIOS. Wenn der Linux-Treiber (snd_hda_intel) beim Booten versucht, die HDMI-Audio-Register mit dem Grafiktreiber (i915) zu verknüpfen, verliert er ohne den lokalen Timer die Synchronisation. Er meldet permanent „nicht bereit“, woraufhin die Hardware den Interrupt-Sturm startet.

3. Warum normale Parameter und Patches live versagt haben

Wir haben im laufenden Betrieb versucht, das Problem über Software-Befehle (MSI-Abschaltung, Bus-Snooping, DMIC-Deaktivierung und sogar eine starre Patch-Datei) zu lösen.

Obwohl das System die Parameter (wie enable_msi=0 und patch=hdmi_audio_fix.patch) erfolgreich geschluckt hat, blieb die Last bei 60 %. Das beweist: Sobald der Treiber die Hardware im normalen Boot-Zustand einmal berührt, läuft die Hardware im Silizium des Chips so tief heiß, dass man sie per Software im laufenden Betrieb nicht mehr einfangen kann. Der Deadlock ist dann bereits im Speicher "festgefroren".

Ich versuche mit der KI nun einen anderen TReiber. Die KI sagt AVS weil es beim SOF Passtrough Probleme geben soll.
modinfo -p snd-intel-dspcfg
dsp_driver:Force the DSP driver for Intel DSP (0=auto, 1=legacy, 2=SST, 3=SOF, 4=AVS) (int)

Test mit SOF und AVS scheitern:
Line 4088: Sep 23 14:05:46 BM2LTS-MC kernel: [ 7.758023] sof-audio-pci-intel-tgl 0000:00:1f.3: enabling device (0000 -> 0002)
Line 4089: Sep 23 14:05:46 BM2LTS-MC kernel: [ 7.758268] sof-audio-pci-intel-tgl 0000:00:1f.3: the DSP is not enabled on this platform, aborting probe

und der legacy hat auch die 60%

ein Problem ist ev. auch dass der Kernel glaubt es wäre ein normaler i3 mit DSP (wie mein 2. NUC) der hat einen DSP. Der 30Z aber nicht.

[ 0.000000] DMI: Intel(R) Client Systems NUC11PAHi3/NUC11PABi3, BIOS PATGL357.0057.2024.0918.1215 09/18/2024
[ 0.037683] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-6.15.2-x64v3-xanmod1 root=UUID=a48865c1-45b7-4ba7-b12b-674e46d0738d ro net.ifname s=0 biosdevname=0 intel_pstate=enable splash quiet loglevel=3 video=HDMI-A-2:1280x720@50D drm.edid_firmware=edid/edid.bin nohz=off nolapic-tim er vt.handoff=7 acpi=force acpi_enforce_resources=lax snd_intel_dspcfg.dsp_driver=3
[ 0.039166] software IO TLB: area num 4.
[ 1.007768] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
[ 1.007769] software IO TLB: mapped [mem 0x000000002d546000-0x0000000031546000] (64MB)
[ 1.087461] ACPI: thermal: [Firmware Bug]: No valid trip points!
[ 1.549092] integrity: Loaded X.509 cert 'Microsoft Corporation UEFI CA 2011: 13adbf4309bd82709c8cd54f316ed522988a1bd4'
[ 1.549101] integrity: Loaded X.509 cert 'Microsoft Windows Production PCA 2011: a92902398e16c49778cd90f99e4f9ae17c55af53'
[ 1.712657] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[ 5.971406] i915 0000:00:02.0: [drm] Finished loading DMC firmware i915/tgl_dmc_ver2_12.bin (v2.12)
[ 7.656865] sof-audio-pci-intel-tgl 0000:00:1f.3: enabling device (0000 -> 0002)
[ 7.657108] sof-audio-pci-intel-tgl 0000:00:1f.3: the DSP is not enabled on this platform, aborting probe

SHF Ich hab einen Fehler gemacht. Der 60% NUC ist ein auch ein PAH aber halt 30Z (LiteSKU: ohne dig.Mic) und kein 3000.
RNUC11PAHi30Z M68269-xxx “Intel® NUC 11 Performance kit”, “Lite SKU”
The content cannot be displayed because you do not have authorisation to view this content. The content cannot be displayed because you do not have authorisation to view this content.

lt. Blockdiagramm ist ein Codec verbaut, (pdf im Anhang), und im Bios kann man HDaudio disablen und dann kommt kein Ton (keine soundkarte) mehr. Auch die Eingrenzung auf snd_hda_intel.probe_mask=4
zeigt dass nur ein Slot einen Audio hat. Das ist der Interrupt der "stürmt"
185: 0 0 0 973279 IR-PCI-MSI-0000:00:1f.3 0-edge snd_hda_intel:card0.
Die Fummelei mit enable_msi=01/1, snoop=0 bringt nichts. Setze ich
snd_hda_intel.single_cmd=1 sinkt die Last des einen Caore schon mal auf unter 25%.

Ein Prob könnte auch sein, dass das System den 30Z wie den 3000 als NUC11PA erkennt.
[ 0.000000] DMI: Intel(R) Client Systems NUC11PAHi3/NUC11PABi3
Lt. der KI ist das der Grund warum der Kernel den AVS oder SOF Treibers zwar aktiviert
snd-intel-dspcfg.dsp_driver=3/4 aber danach das probing stoppt und keine Soundkarte findet. [ 7.657108] sof-audio-pci-intel-tgl 0000:00:1f.3: the DSP is not enabled on this platform, aborting probe

Beim 30Z scheint der Codec tats. zu fehlen... und auch der USB CMEDIA Chip existiert nicht. Die Tigerlake und ISST Ids sind ident

watch -n 1 "cat /proc/interrupts | grep -iE '185:|snd_hda_intel'"
Der fehlende Codec führt aufgrund gleicher Kennungen am PAHi30Z zu 40.000 Ineterrupts/s. Beim PAHi3000 40/s,
cat /proc/interrupts | grep -i snd
watch -n 1 "cat /proc/interrupts | grep -iE '185:|snd'"

 lspci -vnn -s 00:00:1f.3
00:1f.3 Audio device [0403]: Intel Corporation Tiger Lake-LP Smart Sound Technology Audio Controller [8086:a0c8] (rev 20)
       DeviceName: Onboard - Sound
       Subsystem: Intel Corporation Tiger Lake-LP Smart Sound Technology Audio Controller [8086:3004]
    ...
       Kernel driver in use: snd_hda_intel
       Kernel modules: snd_hda_intel, snd_soc_avs, snd_sof_pci_intel_tgl

KI:
Der Realtek-Chip wird von Intel auf der Lite-SKU (30Z) nicht über einen alternativen Bus (wie USB) gelöst, sondern wie folgt umgangen:

Wie Intel das Fehlen des Realtek-Chips beim 30z löst

Intel nutzt für den Front-Audio-Jack die im Prozessor integrierten Intel Smart Sound Technology (SST) Logik-Gatter. Statt eines separaten, teuren Realtek-HDA-Wandlerbausteins greift das System direkt auf die internen Audio-Ausgänge des Intel-SoCs zu.

PAHi3000:
ls -la /proc/asound/card0/
-r--r--r-- 1 root root 0 Sep 24 09:10 codec#0
-r--r--r-- 1 root root 0 Sep 24 09:10 codec#2
... pcm0c / pcm0p (analog Capture/Playback für Realtek) UND die Ordner pcm3p, pcm7p, pcm8p, pcm9p (die digitalen HDMI-Kanäle)
dr-xr-xr-x 4 root root 0 Sep 24 09:10 pcm0c
dr-xr-xr-x 4 root root 0 Sep 24 09:10 pcm0p
dr-xr-xr-x 5 root root 0 Sep 24 09:10 pcm2c
dr-xr-xr-x 4 root root 0 Sep 24 09:10 pcm3p
dr-xr-xr-x 4 root root 0 Sep 24 09:10 pcm7p
dr-xr-xr-x 4 root root 0 Sep 24 09:10 pcm8p
dr-xr-xr-x 4 root root 0 Sep 24 09:10 pcm9p

dmesg | grep -iE 'dsp|sof|hda|tgl|intel.*audio'
[ 0.000000] DMI: Intel(R) Client Systems NUC11PAHi3/NUC11PABi3, BIOS PATGL357.0057.2024.0918.1215 09/18/2024
[ 0.046534] software IO TLB: area num 4.
[ 0.999204] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
[ 0.999205] software IO TLB: mapped [mem 0x000000002a39d000-0x000000002e39d000] (64MB)
[ 1.550197] integrity: Loaded X.509 cert 'Microsoft Corporation UEFI CA 2011: 13adbf4309bd82709c8cd54f316ed522988a1bd4'
[ 1.550208] integrity: Loaded X.509 cert 'Microsoft Windows Production PCA 2011: a92902398e16c49778cd90f99e4f9ae17c55af53'
[ 1.757490] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[ 3.278074] i915 0000:00:02.0: [drm] Finished loading DMC firmware i915/tgl_dmc_ver2_12.bin (v2.12)
[ 4.718981] snd_hda_intel 0000:00:1f.3: enabling device (0000 -> 0002)
[ 4.719278] snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops intel_audio_component_bind_ops [i915])
[ 4.798564] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC256: line_outs=1 (0x21/0x0/0x0/0x0/0x0) type:hp
[ 4.798569] snd_hda_codec_realtek hdaudioC0D0: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
[ 4.798571] snd_hda_codec_realtek hdaudioC0D0: hp_outs=0 (0x0/0x0/0x0/0x0/0x0)
[ 4.798572] snd_hda_codec_realtek hdaudioC0D0: mono: mono_out=0x0
[ 4.798573] snd_hda_codec_realtek hdaudioC0D0: inputs:
[ 4.926653] input: HDA Intel PCH Headphone as /devices/pci0000:00/0000:00:1f.3/sound/card0/input6
[ 4.926698] input: HDA Intel PCH HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input7
[ 4.926730] input: HDA Intel PCH HDMI/DP,pcm=7 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input8
[ 4.926764] input: HDA Intel PCH HDMI/DP,pcm=8 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input9
[ 4.926795] input: HDA Intel PCH HDMI/DP,pcm=9 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input10

PAHi30Z:
NUR: -r--r--r-- 1 root root 0 Sep 24 09:09 codec#2
... nur die digitalen HDMI-Kanäle
dr-xr-xr-x 4 root root 0 Sep 24 09:09 pcm3p
dr-xr-xr-x 4 root root 0 Sep 24 09:09 pcm7p
dr-xr-xr-x 4 root root 0 Sep 24 09:09 pcm8p
dr-xr-xr-x 4 root root 0 Sep 24 09:09 pcm9p

[ 0.000000] DMI: Intel(R) Client Systems NUC11PAHi3/NUC11PABi3, BIOS PATGL357.0057.2024.0918.1215 09/18/2024
[ 0.038898] software IO TLB: area num 4.
[ 1.003300] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
[ 1.003301] software IO TLB: mapped [mem 0x000000002d53d000-0x000000003153d000] (64MB)
[ 1.547955] integrity: Loaded X.509 cert 'Microsoft Corporation UEFI CA 2011: 13adbf4309bd82709c8cd54f316ed522988a1bd4'
[ 1.547964] integrity: Loaded X.509 cert 'Microsoft Windows Production PCA 2011: a92902398e16c49778cd90f99e4f9ae17c55af53'
[ 1.702453] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[ 6.019422] i915 0000:00:02.0: [drm] Finished loading DMC firmware i915/tgl_dmc_ver2_12.bin (v2.12)
[ 8.425061] snd_hda_intel 0000:00:1f.3: enabling device (0000 -> 0002)
[ 8.425323] snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops intel_audio_component_bind_ops [i915])
[ 9.455097] snd_hda_intel 0000:00:1f.3: azx_get_response timeout, switching to polling mode: last cmd=0x000f0000
[ 10.467129] snd_hda_intel 0000:00:1f.3: No response from codec, disabling MSI: last cmd=0x000f0000
[ 11.479170] snd_hda_intel 0000:00:1f.3: Codec #0 probe error; disabling it...
[ 11.514736] input: HDA Intel PCH HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input6
[ 11.515075] input: HDA Intel PCH HDMI/DP,pcm=7 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input7
[ 11.516401] input: HDA Intel PCH HDMI/DP,pcm=8 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input8
[ 11.516797] input: HDA Intel PCH HDMI/DP,pcm=9 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input9

Die Analyse der KI:

1. Die Anatomie der Codec-Slots (/proc/asound/card0/)

Der Intel High Definition Audio-Controller besitzt intern mehrere logische „Slots“ (Kanäle), auf denen er nach Sound-Chips sucht.

• Der i3000 (Standard SKU):
  • codec#0 existiert physisch. Das ist der onboard verlötete Realtek ALC256 Audio-Codec für den analogen Front-Jack.
  • codec#2 existiert physisch. Das ist der digitale Intel HDMI/DP-Audio-Codec (gesteuert über die i915-Grafikeinheit).
  • Resultat im Verzeichnis: Es gibt die Ordner pcm0c / pcm0p (analog Capture/Playback für Realtek) UND die Ordner pcm3p, pcm7p, pcm8p, pcm9p (die digitalen HDMI-Kanäle).
• Ihr i30z (Lite SKU):
  • codec#0 fehlt physisch komplett! Intel hat den Realtek-Chip auf dieser Platine schlicht nicht verbaut. Der Front-Jack wird stattdessen über eine alternative HDA-Lösung (Laut Datenblatt ein CMEDIA-Chip) angesteuert, der sich dem System aber nicht als klassischer HDA-Codec auf Slot 0 zu erkennen gibt.
  • codec#2 existiert physisch. Das ist auch hier der digitale Intel HDMI/DP-Audio-Codec für Ihren Fernseher.
  • Resultat im Verzeichnis: Die analogen Ordner pcm0* fehlen komplett. Es existieren ausschließlich die digitalen HDMI-Kanäle (pcm3p bis pcm9p).

2. Das Drama im Boot-Protokoll (dmesg)

Da beide NUCs laut DMI-Eintrag dieselbe Hauptplatine melden (NUC11PAHi3), weiß der Linux-Audiotreiber snd_hda_intel beim Booten nichts von der "Lite"-Kastration. Er arbeitet starr sein fest programmiertes Skript für dieses Board ab.

• Beim i3000 (Standard):
  Der Treiber startet, fragt Slot 0 ab, der Realtek-Chip antwortet sofort (autoconfig for ALC256), danach wird HDMI eingebunden. Der gesamte Vorgang dauert Millisekunden, läuft ohne Fehler durch, und das System bleibt im Idle bei 0 % Last.
• Bei Ihrem i30z (Lite SKU):
  Der Treiber startet bei Sekunde 8.42, fragt Slot 0 ab – und greift in gähnende Leere. Da der Kernel aber fest mit dem Realtek-Chip rechnet, gerät der Treiber in eine schwere Timeout-Krise:
  1. Sekunde 9.45: Der Treiber wartet vergeblich auf Antwort von Slot 0 (azx_get_response timeout, switching to polling mode).
  2. Sekunde 10.46: Aus purer Verzweiflung schaltet der Treiber die moderne, sichere Interrupt-Signalisierung ab (No response from codec, disabling MSI).
  3. Sekunde 11.47: Der Treiber gibt auf und deaktiviert Slot 0 komplett (Codec #0 probe error; disabling it...).

3. Warum das zu den 60 % / 25 % Last führt und sich nicht auf 0 % bringen lässt

Weil der Treiber wegen des fehlenden Chips auf Slot 0 gezwungen wird, MSI (Message Signaled Interrupts) global für die gesamte Soundkarte abzuschalten, verliert das System die Fähigkeit, Audio-Signale präzise und direkt in den RAM zu schreiben. Der Controller fällt dauerhaft in den alten, langsamen Legacy-PCI-IRQ-Modus zurück.

Wenn Sie nun den Ton per HDMI an den Fernseher übertragen (codec#2), passiert Folgendes auf dem PCI-Bus:

1. Im Werkszustand (60 % Last): Der Controller versucht im HDA-Standardmodus, ununterbrochen parallele Abfragen über den Bus zu jagen. Da MSI deaktiviert ist, führt das zu einem ununterbrochenen, amoklaufenden Hardware-Interrupt-Sturm, der sich als 60%ige kworker-Dauerschleife auf einem CPU-Kern festfrisst.
2. Mit Ihrem Fix single_cmd=1 (25 % Last): Dieser Parameter zwingt den Controller, jede Abfrage starr nacheinander (seriell) abzuarbeiten und auf die Antwort der Grafikkarte zu warten. Das hat das aggressive parallele Bombardieren der CPU zwar gestoppt und die Last halbiert – aber das serielle, endlose Warten des Treibers auf dem blockierten Bus erzeugt nun die wie festgemauerte Grundlast von exakt 25 % (was mathematisch genau einem voll ausgelasteten logischen Kern Ihres Quad-Core-Prozessors entspricht).

Fazit:

Die 25 % Last sind das absolute Hardware-Minimum für diese Lite-SKU-Platine. Der Treiber kann diese Grenze im Legacy-Modus nicht unterschreiten, weil die hardwareseitige Abschaltung von MSI durch den fehlenden Realtek-Chip die PCI-Kommunikation dauerhaft aus dem Tritt bringt.

1 Was denkt ihr bez. der Nachteile von single_cmd=1

• Verzögerte Audioumschaltung (Latenz bei Kanalwechseln):
  Wenn Sie den TV-Kanal wechseln und sich das Audioformat ändert (z. B. von Stereo auf Dolby Digital), müssen Grafik- und Soundkarte neue Steuerbefehle austauschen. Durch den seriellen Modus dauert dieser "Handshake" geringfügig länger. Es kann beim Umschalten zu einer minimal längeren Gedenksekunde (Stummschaltung) kommen, bis der Ton des neuen Senders anspringt.
• Einschränkung bei extremen Multichannel-Formaten:
  Wenn Sie hochkomplexe, dynamische Audio-Metadaten (wie Dolby Atmos oder DTS:X Passthrough) an einen AV-Receiver senden möchten, kann die Bandbreite des seriellen Befehlsbusses theoretisch an Grenzen stoßen. Für normales Stereo, PCM oder klassisches 5.1-Dolby-Digital über Ihren Fernseher reicht die Geschwindigkeit aber völlig aus.
• Erhöhte Anfälligkeit für kurze Tonaussetzer (Dropouts) bei Systemlast:
  Da der Treiber bei jedem Befehl starr blockiert und wartet, bis die Hardware antwortet, kann ein plötzlicher CPU-Peak an anderer Stelle im System dazu führen, dass ein Audio-Steuerbefehl das Timing verpasst. Das kann sich in seltenen, kurzen Knacksern im Ton äußern, wenn das System extrem ausgelastet ist.

2 Habt ihr noch eine Idee bez. des Problems

Ich habe keinen USB Soundchip gefunden:
lsusb
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 002: ID 174c:55aa ASMedia Technology Inc. ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridge
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

dmesg | grep -i usb
[    0.986722] ACPI: bus type USB registered
[    0.986722] usbcore: registered new interface driver usbfs
[    0.986722] usbcore: registered new interface driver hub
[    0.986722] usbcore: registered new device driver usb
[    1.152435] xhci_hcd 0000:00:0d.0: new USB bus registered, assigned bus number 1
[    1.153739] xhci_hcd 0000:00:0d.0: new USB bus registered, assigned bus number 2
[    1.153741] xhci_hcd 0000:00:0d.0: Host supports USB 3.1 Enhanced SuperSpeed
[    1.153862] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 6.15
[    1.153864] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    1.153865] usb usb1: Product: xHCI Host Controller
[    1.153866] usb usb1: Manufacturer: Linux 6.15.2-x64v3-xanmod1 xhci-hcd
[    1.153867] usb usb1: SerialNumber: 0000:00:0d.0
[    1.153944] hub 1-0:1.0: USB hub found
[    1.154007] usb usb2: New USB device found, idVendor=1d6b, idProduct=0003, bcdDevice= 6.15
[    1.154008] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    1.154009] usb usb2: Product: xHCI Host Controller
[    1.154009] usb usb2: Manufacturer: Linux 6.15.2-x64v3-xanmod1 xhci-hcd
[    1.154010] usb usb2: SerialNumber: 0000:00:0d.0
[    1.154052] hub 2-0:1.0: USB hub found
[    1.154700] xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 3
[    1.156041] xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 4
[    1.156042] xhci_hcd 0000:00:14.0: Host supports USB 3.1 Enhanced SuperSpeed
[    1.156062] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 6.15
[    1.156064] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    1.156064] usb usb3: Product: xHCI Host Controller
[    1.156065] usb usb3: Manufacturer: Linux 6.15.2-x64v3-xanmod1 xhci-hcd
[    1.156066] usb usb3: SerialNumber: 0000:00:14.0
[    1.156127] hub 3-0:1.0: USB hub found
[    1.157381] usb usb4: New USB device found, idVendor=1d6b, idProduct=0003, bcdDevice= 6.15
[    1.157382] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    1.157383] usb usb4: Product: xHCI Host Controller
[    1.157384] usb usb4: Manufacturer: Linux 6.15.2-x64v3-xanmod1 xhci-hcd
[    1.157384] usb usb4: SerialNumber: 0000:00:14.0
[    1.157427] hub 4-0:1.0: USB hub found
[    1.157951] usbcore: registered new interface driver usbserial_generic
[    1.157954] usbserial: USB Serial support registered for generic
[    1.407160] usb 3-2: new high-speed USB device number 2 using xhci_hcd
[    1.549080] usb 3-2: New USB device found, idVendor=174c, idProduct=55aa, bcdDevice= 1.00
[    1.549083] usb 3-2: New USB device strings: Mfr=2, Product=3, SerialNumber=1
[    1.549084] usb 3-2: Product: ASMT105x
[    1.549085] usb 3-2: Manufacturer: ASMT
[    1.549085] usb 3-2: SerialNumber: 234567890126
[    1.721684] usbcore: registered new interface driver usb-storage
[    1.762271] usbcore: registered new interface driver uas

Mein aktueller Status ist:

• Es ist kein Codec verbaut.
• Aufgrund der Kennungen Vendor und SubclassID nur legacy als PAHi3000 Board führt es am Ende zum Interruptsturm von 40kHz. Schaltet man das auf polling um kommen zwar nur noch 20kHz aber die Last auf dem einen Kern steigt 60>70%.
• Auch alle anderen Versuche mit spoof=0, msi=0/1, jack_ms, snd_intel_dspcfg.dsp_driver=1 snd_hda_intel.model=intel-mac-auto / generic i915.disable_power_well=0 ändern nichts an den 60%
• Einzig mit single_cmd=1 lässt die Last auf 25% sinken, verändert die 40kHz aber nicht.

Aus meiner Sicht wäre die einzige Möglichkeit Vendor und Subclass ID 8086:a0c8 auf einen z.B. NUC11iTN / FN die dezitiert keinen Codec haben zu spoofen.

Leider ist mir das bisher nicht gelungen weil der benutzte XANMOD1 Kernel im Zusammenspiel mit dem inireamfs vieles nicht erlaubt:

• grub.conf: initrd /boot/dmi-spoof.img /boot/initrd.img-6.15.2-x64v3-xanmod1
• pci=early_dump pci=conf1 quirks=8086:a0c8:3024, pci=quirk=8086:a0c8:nodev0, quirks=0000:00:1f.3#0x401000. Hatte auch eine Variante mit @ ...
  dmi_product_name='NUC11TNHi3' dmi_board_name='NUC11TNBi3'
  

Hab das Alles probiert....
enable deaktiviert höchstens karten. Er findet aber eh nur die Richtige = EINE
probe_mask erspart ihm den nicht vorh. codec überhaupt zu prüfen. Hab ich schon drin =4
probe_only bringt auch keine Änderung weil er ohne mask nach einem timeout ohnehin drauf kommt dass der codec nicht da ist.
enable_msi=0 da sagt der Treiber dann zwar polling mode. In Wahrheit kommt der IQ dann aber auf Leitung #16 (lt. KI ein Sammelinterrupt) und führt zu 34% Last auf einem Kern.
snoop=0, Jackpoll_ms=0 bringen keine Änderung

[    7.419327] snd_hda_intel 0000:00:1f.3: Codec #0 probe error; disabling it...
[    7.577476] input: HDA Intel PCH HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input6
[    7.577888] input: HDA Intel PCH HDMI/DP,pcm=7 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input7
[    7.577929] input: HDA Intel PCH HDMI/DP,pcm=8 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input8
[    7.577966] input: HDA Intel PCH HDMI/DP,pcm=9 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input9

enbale_msi=0 führt dazu dass der Interrupt nicht mehr auf #185 sonder auf #16 los legt

Wie gesagt:
Das Problem ist , dass der Treiber im Glauben dass es den Realtec Chip Code#0 (wie beim PAH3000) gibt, verm. die Initialisierung falsch macht und damit mit 40kHz Interrupts generiert werden.
Sobald man mit modeprobe snd_hda_intel enabled startet auch der "Sturm".

root@BM2LTS-MC:~# echo 1 > /sys/kernel/tracing/events/hda/enable
root@BM2LTS-MC:~# tail -f /sys/kernel/tracing/trace
... # entries-in-buffer/entries-written: 36086/313220   #P:4
#                                _-----=> irqs-off/BH-disabled
#                               / _----=> need-resched
#                              | / _---=> hardirq/softirq
#                              || / _--=> preempt-depth
#                              ||| / _-=> migrate-disable
#                              |||| /     delay
#           TASK-PID     CPU#  |||||  TIMESTAMP  FUNCTION
#              | |         |   |||||     |         |
          <idle>-0       [002] d.h2.    66.482369: hda_unsol_event: [0000:00:1f.3:0] res=0xffffffff, res_ex=0x00000010
          <idle>-0       [002] dNh2.    66.482373: hda_unsol_event: [0000:00:1f.3:0] res=0xffffffff, res_ex=0x00000010
          <idle>-0       [002] d.h2.    66.482411: hda_unsol_event: [0000:00:1f.3:0] res=0xffffffff, res_ex=0x00000010
          <idle>-0       [002] dNh2.    66.482414: hda_unsol_event: [0000:00:1f.3:0] res=0xffffffff, res_ex=0x00000010
          <idle>-0       [002] d.h2.    66.482453: hda_unsol_event: [0000:00:1f.3:0] res=0xffffffff, res_ex=0x00000010

Quote

Da dein System keinen dedizierten physischen Codec-Chip besitzt, sondern rein auf Intel Smart Sound Technology (SST) mit dem Sound Open Firmware (SOF) DSP-Subsystem des Tigerlake-Chipsatzes setzt, läuft der Standard-HDA-Treiber ins Leere.

Der Interrupt-Flood entsteht, weil snd_hda_intel fälschlicherweise an die Hardware gebunden ist und versucht, ein klassisches HDA-Register abzufragen. Da dieses ohne Codec physikalisch nicht existiert, liefert es die im Trace sichtbare Endlosschleife aus 0xffffffff-Timeouts. [1, 2]

Hier sind die zwei Wege, wie du diesen Fehler behebst:

Lösung A: Den Treiber zwingen, den richtigen DSP-Treiber (SOF) zu laden

Standardmäßig entscheidet ein interner Auto-Detektor (snd_intel_dspcfg), welcher Treiber geladen wird. Erzwinge die moderne SOF-Architektur, die für Tigerlake SST zwingend benötigt wird.

Ehrlich gesagt bezweifle ich dass SOF die Lösung ist, da das System ja keinen DSP hat ...

Aktuell bekommt man bei sof Vorgabe snd-intel-dspcfg driver=3 wie ganz oben beschrieben keine Soundkarte:
[ 7.656865] sof-audio-pci-intel-tgl 0000:00:1f.3: enabling device (0000 -> 0002)
[ 7.657108] sof-audio-pci-intel-tgl 0000:00:1f.3: the DSP is not enabled on this platform, aborting prob

SHF  cinfo Man müsste also dem Treiber klar machen, dass es eine andere Hardware wie oben beschrieben ist.

Dann würde er ev. von selbst den SOF wählen oder diesen zumindest akzeptieren

Ich habe nun versucht den Interrupt zu disablen setpci -s 0000:00:1f.3 62.w=0080 und hab mich zu früh gefreut.

Der IRQ Sturm war weg und bis zur Umschaltung auf ServusTV (1080i50 mir Dolby digital Ton) Kanal 16 hatte Alles gut ausgesehen. Aber wenn man da von PCM Stereo auf Pass-Trough umschaltet, startet auch die Bildausgabe neu und hat plötzlich Kammartefakten = als ob kein Deinterlacing aktiv wäre.

Ich hab im Syslog aber keinen Hinweis darauf gefunden. Hier der Link zum Log:
snd_hda_intel – Google Drive

Könnte ihr bitte einen Blick drauf werfen. Ich habe dabei mit versch. snd_hda_parametern (enable_msi, single_cmd, ....) experimentiert und zum Test immer zwischen PCM und Dolby (Pass-Trough) umgeschalten.

Ev. könnt ihr auch direkt sagen, warum das ohne IRQ nicht funken kann. (Komisch ist nur, dass es bis zur Tonformatumschltung problemlos läuft)