Kernel 6 zeigt Firmware bug

Mike

Grand Admiral Special
Mitglied seit
11.11.2001
Beiträge
5.089
Renomée
103
Standort
Bayern
Habe letzte Woche auf Kernel 6.0.10 upgedated.
Seit dem habe ich mit spontanen freezes und reboots zu kämpfen.
Was mich wunderte daß die reboots immer im idle passiert sind.
Also solange Boinc die Machine beschäftigt hat lief alles rund.
Als braver Bürger wollte ich etwas Strom sparen über Nacht und habe Boinc deaktiviert und da passierte es wieder.

Journalctl zeigte dann einige Dinge die mich etwas schockieren.

Nov 30 20:15:13 solus kernel: ACPI: 9 ACPI AML tables successfully acquired and loaded
Nov 30 20:15:13 solus kernel: ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored
Nov 30 20:15:13 solus kernel: ACPI: EC: EC started
Nov 30 20:15:13 solus kernel: ACPI: EC: interrupt blocked
Nov 30 20:15:13 solus kernel: ACPI: EC: EC_CMD/EC_SC=0x66, EC_DATA=0x62
Nov 30 20:15:13 solus kernel: ACPI: \_SB_.PCI0.SBRG.EC0_: Boot DSDT EC used to handle transactions
Nov 30 20:15:13 solus kernel: ACPI: Interpreter enabled
Nov 30 20:15:13 solus kernel: ACPI: PM: (supports S0 S3 S4 S5)
Nov 30 20:15:13 solus kernel: ACPI: Using IOAPIC for interrupt routing
Nov 30 20:15:13 solus kernel: PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
Nov 30 20:15:13 solus kernel: ACPI: Enabled 3 GPEs in block 00 to 1F

Das C6H scheinte eine falsche ACPI table zu nutzen.
Also taktet die CPU zu weit herunter.
Habe im idle gerade mal 25C. und der Takt sollte bei 2200 im idle sein ist aber zwischen 1800 und 2100.
Die vcore dürfte dann auch zu weit sinken.
Bios ist das neste 8601.

Gibt es da fixes von Assus oder kann man das selbst korrigieren ?
 
Gibt doch mal bitte die Ausgabe davon
Code:
dmesg -x -l crit,warn,err
journalctl -p 3 -xb

ACPI Fehler sind eher Fehler dir der Hersteller des Mainboards beheben muss, ob die Hersteller Linux unterstützen ist eine andere Frage. Die Neustarts und das Einfrieren kenne ich auch, aber nur von AMD Systemen.

Vielleicht hilft es die Hardware-Iommu in Grub zu aktivieren.
 
Ich sehe gerade, du hast nen 1800X. Da gibt es einen Hardware Bug in der CPU, der genau das macht was du hier beschreibst.
Eine Lösung dafür ist mir nicht bekannt, ein Workaround ist es den C6(?) State im UEFI zu deaktivieren. Das geht meistens.
Der Firmware Bug, der da in deinem Code aufgelistet ist hat damit glaube ich nichts zu tun.
Edit: mit Kernel 6.0 sollte es auch nichts zu tun haben, aber du kannst ja mal gegen LTS testen zur Sicherheit.

Edit2: schau dir mal dies hier an:
 
Zuletzt bearbeitet:
Gibt doch mal bitte die Ausgabe davon
Code:
dmesg -x -l crit,warn,err
journalctl -p 3 -xb

ACPI Fehler sind eher Fehler dir der Hersteller des Mainboards beheben muss, ob die Hersteller Linux unterstützen ist eine andere Frage. Die Neustarts und das Einfrieren kenne ich auch, aber nur von AMD Systemen.

Vielleicht hilft es die Hardware-Iommu in Grub zu aktivieren.

Hier der output.

ike@solus ~ $ dmesg -x -l crit,warn,err
kern :warn : [ 0.260619] mtrr: your CPUs had inconsistent variable MTRR settings
kern :warn : [ 0.546176] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)
kern :warn : [ 0.546269] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)
kern :warn : [ 0.546374] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)
kern :warn : [ 0.546459] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)
kern :warn : [ 0.546523] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)
kern :warn : [ 0.546629] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)
kern :warn : [ 0.546729] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)
kern :warn : [ 0.546798] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)
kern :warn : [ 0.546865] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)
kern :warn : [ 0.546948] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)
kern :warn : [ 0.547034] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)
kern :warn : [ 0.547114] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)
kern :warn : [ 0.547197] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)
kern :warn : [ 0.547286] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)
kern :warn : [ 0.547356] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)
kern :warn : [ 0.547419] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)
kern :warn : [ 0.557664] nvme nvme0: missing or invalid SUBNQN field.
kern :warn : [ 0.894620] acpi PNP0C14:02: duplicate WMI GUID 05901221-D566-11D1-B2F0-00A0C9062910 (fir
st instance was on PNP0C14:01)
kern :warn : [ 1.379056] ata1.00: supports DRM functions and may not be fully accessible
kern :warn : [ 1.379344] ata1.00: NCQ Send/Recv Log not supported
kern :warn : [ 1.380683] ata1.00: supports DRM functions and may not be fully accessible
kern :warn : [ 1.380995] ata1.00: NCQ Send/Recv Log not supported
kern :warn : [ 1.843680] ata2.00: ATA Identify Device Log not supported
kern :warn : [ 1.845242] ata2.00: ATA Identify Device Log not supported
kern :warn : [ 4.219384] amdgpu 0000:0d:00.0: amdgpu: PSP runtime database doesn't exist
kern :warn : [ 4.515856] sd 9:0:0:0: [sdd] Optimal transfer size 33553920 bytes not a multiple of phys
ical block size (4096 bytes)
kern :err : [ 6.490596] sd 10:0:0:0: [sde] No Caching mode page found
kern :err : [ 6.490597] sd 10:0:0:0: [sde] Assuming drive cache: write through
kern :warn : [ 8.489326] amdgpu 0000:0d:00.0: amdgpu: SMU driver if version not matched
kern :warn : [ 8.785293] [drm] REG_WAIT timeout 1us * 100000 tries - mpc2_assert_idle_mpcc line:479
kern :warn : [ 8.822603] amdgpu: SRAT table not found
kern :warn : [ 9.077969] [drm] REG_WAIT timeout 1us * 100000 tries - mpc2_assert_idle_mpcc line:479
kern :warn : [ 11.527343] ext4 filesystem being mounted at /boot supports timestamps until 2038 (0x7fff
ffff)
kern :warn : [11464.911857] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)
kern :warn : [11464.914405] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)
kern :warn : [11464.916886] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)
kern :warn : [11464.919446] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)
kern :warn : [11464.922104] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)
kern :warn : [11464.924797] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)
kern :warn : [11464.927540] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)
kern :warn : [11464.930309] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)
kern :warn : [11464.933239] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)
kern :warn : [11464.936124] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)
kern :warn : [11464.939112] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)
kern :warn : [11464.942222] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)
kern :warn : [11464.945412] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)
kern :warn : [11464.948684] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)
kern :warn : [11464.952109] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)
kern :warn : [11465.016277] xhci_hcd 0000:02:00.0: xHC error in resume, USBSTS 0x401, Reinit
kern :warn : [11465.258280] amdgpu 0000:0d:00.0: amdgpu: SMU driver if version not matched
kern :warn : [11465.476914] ata1.00: supports DRM functions and may not be fully accessible
kern :warn : [11465.477894] ata1.00: NCQ Send/Recv Log not supported
kern :warn : [11465.479433] ata1.00: supports DRM functions and may not be fully accessible
kern :warn : [11465.479770] ata1.00: NCQ Send/Recv Log not supported
kern :warn : [11467.699910] ata2.00: ATA Identify Device Log not supported
kern :warn : [11467.701491] ata2.00: ATA Identify Device Log not supported
Doppelposting wurde automatisch zusammengeführt:

Ich sehe gerade, du hast nen 1800X. Da gibt es einen Hardware Bug in der CPU, der genau das macht was du hier beschreibst.
Eine Lösung dafür ist mir nicht bekannt, ein Workaround ist es den C6(?) State im UEFI zu deaktivieren. Das geht meistens.
Der Firmware Bug, der da in deinem Code aufgelistet ist hat damit glaube ich nichts zu tun.
Edit: mit Kernel 6.0 sollte es auch nichts zu tun haben, aber du kannst ja mal gegen LTS testen zur Sicherheit.

Edit2: schau dir mal dies hier an:

Das habe ich im journal output auch gesehen.
Was mich nur wundert warum laufen dann die älteren Kernel ohne Probleme ???
Habe mit 5.15.77 überhaupt keine Störungen.
Im 6er werden sie ja angeblich nur geprüft.
Heisst das dann dass ich auf dem 5er Kernel bleiben muss ?
Solus ist ja eine Rolling Distro da werden ja ständig neue Kernels raus gebracht.
Dann müsste ich ja ständig den alten zurück installieren.

Im LTS wird der Bug auch angezeigt hat aber keine Auswirkungen.
Der läuft über Tage hin stabil.
 
Zuletzt bearbeitet:
Hm, das ist wirklich seltsam.
Aber probier doch mal im UEFI die deep sleep C-states zu deaktivieren (kann dir leider nicht genau sagen wie die heißt ist bei jedem MB anders).
Wenn es bei Solus ein Linux LTS Paket gibt, dann kannst ja erstmal das nutzen, den 5.15er LTS Kernel sollte es noch ne ganze Weile geben.

Evtl. könnte ich mir auch vorstellen, dass des mit dem neuen p States Treiber (amd_pstate) zu tun haben könnte.
Eigentlich würde ich nicht davon ausgehen, dass der für einen 1800X genutzt wird, jedenfalls nicht ohne das zu forcieren.
(Und selbst dann hätte ich nicht gedacht, dass 1st Gen Ryzen unterstützt wird.)
Kannst aber ja mal prüfen, ob der Treiber genutzt wird oder acpi_cpufreq.
 
Ich habe da anscheinend noch Glück.
Das scheint in der Linux Welt ein großes Thema zu sein. Ryzen Abstürze Linux
Die C State im Bios abschalten scheint gar nicht zu reichen, wenn es einen script namens zenstate.py gibt.

Ich habe im Solus Forum einen Entwickler hellhörig gemacht.
Wenn ich in den älteren Kernel boote bekommt man nur updates aber keine features mehr.
So kann ich einen fix überbrücken.
Was mich wirklich wundert, ist dass ich immer reboots nach einem Kernel update habe.
Arbeite ich dann ein paar Tage verschwinden diese für Wochen.
In Windows hatte ich das überhaupt noch nicht weder in win 7 noch in win 10.
Da habe ich aber gelesen dass Windows einfach zu schlecht programmiert ist.
Ist mir schon aufgefallen , daß die idle temps in Linux wesentlich niedriger sind als in win.
Win 10 selten unter 35C in Linux kernel 5.x 31C und in 6 25C ???
 
Gibt es denn Gründe, auf dem doch schon etwas betagteren PC die allerneuesten Kernel zu nutzen?
Ich bin ehrlich gesagt froh, dass Ubuntu da sehr konservativ ist und nicht immer sofort das neueste Zeug integriert. Die LTS-Versionen sind ja noch mal konservativer.
 
Bei 2 Systemen mit Ryzen 1700 die ich betreue hat das Abschalten der C-States genügt. Seitdem ist alles ok, auch über Jahre hinweg.
zenstate.py gab es glaube ich(?) auch schon vorher.

Mit meinen beiden Systemen (3800X und 5950X) hatte ich überhaupt keine Stabilitätsprobleme, auch nicht mit C-States.
Evtl. ist das wieder so ein Thema, dass man halt hauptsächlich die schlechten Stimmen hört, aber nicht die ganzen Leute bei denen es läuft. ;)

Hast du das mit dem Treiber mal überprüft?
 
Gibt es denn Gründe, auf dem doch schon etwas betagteren PC die allerneuesten Kernel zu nutzen?
Ich bin ehrlich gesagt froh, dass Ubuntu da sehr konservativ ist und nicht immer sofort das neueste Zeug integriert. Die LTS-Versionen sind ja noch mal konservativer.
Wie schon gesagt Solus ist eine Rolling Distro da bleibt dir keine Wahl.
Entweder gar keine updates installieren oder eben alles.
Abwählen ist nicht.
Jetzt steht schon wieder ein neuer Kernel 6.0.11 im update bereit.
Da warte ich aber erst mal da ich befürchte, daß dann der 5.15.77 verschwindet.
Muss den erst mal sichern, daß ich ihn evtl nach installieren kann.

@Berniyh
Wie kann ich das prüfen ???
 
Gibt es denn Gründe, auf dem doch schon etwas betagteren PC die allerneuesten Kernel zu nutzen?
Ich bin ehrlich gesagt froh, dass Ubuntu da sehr konservativ ist und nicht immer sofort das neueste Zeug integriert. Die LTS-Versionen sind ja noch mal konservativer.
Die Problematik ist da schon etwas vielschichtiger. Auch der Ansatz von Ubuntu hat teilweise echt Nachteile.
Wobei es zumindest im Hinblick auf den Kernel besser geworden ist, seit es die offiziellen LTS Releases gibt und Ubuntu immer (meistens?) eines davon nutzt.
Dennoch, auch für ältere Systeme kann ein neuerer Kernel Vorteile bringen.
Ich hatte z.B. lange Zeit einen Kaveri im Desktopsystem. Der lief mit amdgpu als Treiber besser als mit dem älteren (und mutmaßlich stabileren) radeon Treiber.
Dafür brauchte es aber tendenziell neuere Kernel, da der amdgpu Treiber weiter verbessert wurde und Features dazu kamen, welche auch für den Kaveri noch relevant waren.
Letztendlich ist es eine Abwägung und ich persönlich halte es absolut nicht für verkehrt eine bestimmte LTS Version dauerhaft zu nutzen, solange diese unterstützt wird.
Kommt halt darauf an ob und wie man von einem neuen Kernel profitieren würde.
Wie schon gesagt Solus ist eine Rolling Distro da bleibt dir keine Wahl.
Entweder gar keine updates installieren oder eben alles.
Abwählen ist nicht.
Jetzt steht schon wieder ein neuer Kernel 6.0.11 im update bereit.
Da warte ich aber erst mal da ich befürchte, daß dann der 5.15.77 verschwindet.
Muss den erst mal sichern, daß ich ihn evtl nach installieren kann.
Es bleibt immer eine Wahl unter Linux. ;)
Einfach nur sichern ist aber keine gute Idee, denn dann fehlen ggf. Sicherheitsupdates für den Kernel. Stillstand ist halt auch nix.
Im Zweifelsfall kopier die die Konfiguration des Kernels (sollte unter /proc/config.gz zu finden sein) und kompilier dir die neueren LTS Releases selbst.
So schwer ist das nicht. ;)
@Berniyh
Wie kann ich das prüfen ???
[/QUOTE]
Mit cpupower:
Code:
cpupower frequency-info 
analyzing CPU 0:
  driver: amd-pstate
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 131 us
  hardware limits: 550 MHz - 5.08 GHz
  available cpufreq governors: performance schedutil
  current policy: frequency should be within 550 MHz and 5.08 GHz.
                  The governor "schedutil" may decide which speed to use
                  within this range.
  current CPU frequency: Unable to call hardware
  current CPU frequency: 550 MHz (asserted by call to kernel)
  boost state support:
    Supported: yes
    Active: yes
    AMD PSTATE Highest Performance: 166. Maximum Frequency: 5.08 GHz.
    AMD PSTATE Nominal Performance: 111. Nominal Frequency: 3.40 GHz.
    AMD PSTATE Lowest Non-linear Performance: 57. Lowest Non-linear Frequency: 1.74 GHz.
    AMD PSTATE Lowest Performance: 19. Lowest Frequency: 550 MHz.

Mit acpi_cpufreq sollte natürlich dann stattdessen das bei driver stehen. Zudem hat man typischerweise deutlich States (ich glaube 3) und die niedrigste Frequenz liegt deutlich höher. Dazu kommt, dass bei amd_pstate die Frequenz auch Werte zwischen diesen States annehmen kann, wie man z.B. bei meiner CPU sieht:
amd_pstate.png
Bei acpi_cpufreq hingegen liegt die angezeigte Frequenz immer exakt bei einem der von cpupower ausgegebenen States.

Auch funktioniert mit amd_pstate PBO vernünftig, soweit man das im UEFI aktiviert hat. Mit acpi_cpufreq ist das nicht (oder nur eingeschränkt?) der Fall.
So geht meine CPU jetzt auch auf über 5 GHz, mit acpi_cpufreq war das nicht der Fall.
 
CPU 0 wird analysiert:
driver: acpi-cpufreq
CPUs, die mit der gleichen Hardwarefrequenz laufen: 0
CPUs, die ihre Frequenz mit Software koordinieren müssen: 0
Maximale Dauer eines Taktfrequenzwechsels: Cannot determine or is not supported.
Hardwarebegrenzungen: 2.20 GHz - 3.60 GHz
available frequency steps: 3.60 GHz, 3.20 GHz, 2.20 GHz
verfügbare cpufreq-Regler: ondemand performance schedutil
momentane Richtlinie: Frequenz sollte innerhalb 2.20 GHz und 3.60 GHz.
sein. Der Regler "ondemand" kann frei entscheiden,
welche Geschwindigkeit er in diesem Bereich verwendet.
current CPU frequency: Unable to call hardware
current CPU frequency: 2.23 GHz (asserted by call to kernel)
boost state support:
Unterstützt: nein
Aktiv: nein

Habe jetzt C state deaktiviert und in Kernel 6.0.10 gebootet.
Taktfrequenz zeigt nun 2.2 Ghz wie es sein soll.
Mal sehen.
 
So nach 22 Stunden läuft immer noch alles stabil.

System:
Host: solus Kernel: 6.0.10-224.current arch: x86_64 bits: 64 compiler: gcc
v: 12.2.0 Desktop: KDE Plasma v: 5.26.4 Distro: Solus 4.3 fortitude

Info:
Processes: 345 Uptime: 22h 27m Memory: 15.55 GiB used: 3.52 GiB (22.7%)
Init: systemd target: graphical (5) Compilers: gcc: N/A Packages: 1127
Shell: Bash v: 5.1.16 inxi: 3.3.23

Das sieht schon mal nicht schlecht aus.
Der idlle Bug meines 1800X ist wohl im Griff.
 
Zurück
Oben Unten