ubuntuusers.de

Hallo Leute,

ich besitze einen Ryzen 7 1700 und das Asus B350M-A. Hin und wieder (ca. alle 20 bis 100 Stunden), friert das System Komplett ein. Dies hängt nicht mit besonders hoher Auslastung zusammen, sondern passiert auch beim Surfen im Netz oder bei der Textverarbeitung mit LibreOffice. Ich habe mittlerweile alle Kernelversionen zwischen 4.10 und 4.13, sowie alle verfügbaren BIOS-Versionen durchprobiert. Aktuell verwende ich das neuste BIOS (Version 0902) und den Kernel 4.13.3 aus dem Ubuntu Mainline-Archiv. Auch habe ich die Magic SysRQ aktiviert:

1

echo 1 | sudo tee /proc/sys/kernel/sysrq 

Offensichtlich friert aber nicht nur der X-Server, sondern das gesamte System ein. ALT + Druck + R E I S U B funktionieren beim Freeze leider auch nicht mehr. Nur der Reset-Knopf hilft dann weiter. Syslog enthält auch leider keine Einträge zum Zeitpunkt des Einfrierens.

Jetzt habe gelesen, dass Leute mit ähnlichen Problemen, das Problem durch deaktivieren der C-States in den Griff bekommen haben sollen. Somit komme ich zu meinen diesbezüglichen Fragen:

1.

1

cat /sys/module/intel_idle/parameters/max_cstate

zeigt bei mir eine

1

9

Laut der Webseite http://www.linuxtopia.org/online_books/linux_kernel/kernel_configuration/re90.html bedeutet das:

Limit the processor to a maximum C-state, no matter what the ACPI tables say it can support. n is a valid C-state value. A value of 9 overrides any DMI blacklist limit that might be present for this processor.

Mir ist nur nicht ganz klar, mit welchen Wert das "DMI blacklist limit" überschrieben wird. Welchen Wert habe ich jetzt real?

2. Offensichtlich bietet der Linux Kernel die Möglichkeit via Grub oder direkt beim Kompilieren vom BIOS abweichende C-States anzugeben. Auf den meisten Seiten wird aber empfohlen, die C-States direkt im BIOS zu deaktivieren. Nur leider finde ich weder in der UEFI Oberfläche noch im Handbuch irgendwelche Einstellungsmöglichkeiten dazu. Hat zufällig jemand das gleiche Mainboard und kann mir sagen ob und wie ich die C-States im BIOS konfigurieren kann?

3. Worin liegt der Unterschied zwischen den Kernelparametern processor.max_cstate und intel_idle.max_cstate?

4. Hat jemand ähnliche Probleme mit einem Ryzen-Prozessor und eventuell noch andere Ideen oder Lösungsvorschläge???

Deine CPU

Ryzen 7 1700

gehört zur Serie "Radeon™ RX 500 ​Series" Ist Software von dieser Support - Seite aktiv ?? ​ http://support.amd.com/de-de/download Linux Download Center Radeon™ RX 500​ Series Ubuntu ​16.04 ​​(​64-bit​)

Andere Info's SegFault-Bug: AMD bestätigt Ryzen-Fehler beim Kompilieren unter Linux https://www.heise.de/newsticker/meldung/SegFault-Bug-AMD-bestaetigt-Ryzen-Fehler-beim-Kompilieren-unter-Linux-3796688.html

Nachtrag AMD Ryzen: Für Linux ist der neueste Kernel notwendig http://www.tomshardware.de/linux-kernel-amd-ryzen-smt,news-257857.html Kernel v4.9.51 http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.9.51/

gehört zur Serie "Radeon™ RX 500 ​Series" Ist Software von dieser Support - Seite aktiv ?? ​ http://support.amd.com/de-de/download Linux Download Center Radeon™ RX 500​ Series Ubuntu ​16.04 ​​(​64-bit​)

Ich besitze eine NVIDIA Karte. Aktueller Treiber ist seit kurzem 384.90 von der Nvidia Seite. Bis dahin war es der aus den Paketquellen (375).

Andere Info's SegFault-Bug: AMD bestätigt Ryzen-Fehler beim Kompilieren unter Linux https://www.heise.de/newsticker/meldung/SegFault-Bug-AMD-bestaetigt-Ryzen-Fehler-beim-Kompilieren-unter-Linux-3796688.html

Jupp, bin ich leider auch von betroffen.

Nachtrag AMD Ryzen: Für Linux ist der neueste Kernel notwendig http://www.tomshardware.de/linux-kernel-amd-ryzen-smt,news-257857.html Kernel v4.9.51 http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.9.51/

Wie ich bereits schrieb, nutze ich 4.13. Aktueller geht derzeit nicht. Zuvor waren es 4.10 bis 4.12, die allesamt Ryzen unterstützen sollten.

Sehe Dir mal die Info's zu den Kernel - Änderungen "AMD" an,

Kernel 4.13.4 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/log/?h=v4.13.4&qt=grep&q=amd Kernel 4.9.52 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/log/?h=v4.9.52&qt=grep&q=amd in Arbeit Kernel 4.9.51 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/log/?h=v4.9.51&qt=grep&q=amd

Änderung der letzten Tage, fasst gleich

Kernel-Treiber folgen der LTS-Version, deswegen der Vorschlag

@SpiritOfTux: hmmm, mir ist ehrlich gesagt nicht so ganz klar, inwiefern mir das eventuell weiter helfen könnte.

Hi,
Du kannst über Grub einen entsprechenden Kernelparameter testen:

processor.max_cstate=[Wert]

Also in der /etc/default/grub in die freie Optionszeile ...

GRUB_CMDLINE_LINUX=""

... die Option eintragen,

GRUB_CMDLINE_LINUX="processor.max_cstate=1"

... übernehmen und testen:

1
2

sudo sed -i "s/GRUB_CMDLINE_LINUX=""/GRUB_CMDLINE_LINUX="processor.max_cstate=1"/g" /etc/default/grub
sudo update-grub

→ Booten

intel_idle.max_cstate ist halt für Intel CPU (die Intel Bay-Trail/Atom CPU haben da ebenfalls Probleme)

Siehe dazu auch gist.github.com C-States

@elektronenblitz63: Danke, aber soweit hatte ich das auch schon verstanden. Es beantwortet nur nicht ganz meine Fragen. Und leider gibt es jetzt auch noch einen kleinen Nachtrag. Als ich eben am Rechner arbeitete wurde plötzlich der Bildschirm schwarz und der Rechner rebootete. Beim Hochfahren war etwas von "mce Hardware Error" zu lesen. Die Meldungen finden sich in dmesg auch wieder:

1

dmesg | grep -i mce

gibt folgendes aus:

1
2
3
4
5
6

[    0.021433] mce: CPU supports 23 MCE banks
[    0.678018] mce: [Hardware Error]: Machine check events logged
[    0.678018] mce: [Hardware Error]: CPU 15: Machine Check: 0 Bank 5: bea0000000000108
[    0.678018] mce: [Hardware Error]: TSC 0 ADDR 1ffffb6703188 MISC d012000101000000 SYND 4d000000 IPID 500b000000000 
[    0.678018] mce: [Hardware Error]: PROCESSOR 2:800f11 TIME 1506952092 SOCKET 0 APIC f microcode 8001129
[    6.775069] MCE: In-kernel MCE decoding enabled.

Die Datei /var/log/syslog schweigt sich mal wieder aus zu den Vorgängen.

PROCESSOR 2:800f11 TIME 1506952092 SOCKET 0 APIC f microcode 8001129

Das Paket amd64-microcode ist installiert (stammt aus 2016, also älter)? Der angezeigte Fehler scheint mit APIC zu tun zu haben, muss aber nichts mit dem Systemabsturz zu tun haben, und wenn im „Normalbetrieb“ soweit alles läuft.

Hast Du memtest mal längere Zeit laufen lassen. Vielleicht kannst Du die RAM-Timings und den Takt im UEFI probeweise auch etwas moderater einstellen. Probleme mit dem RAM sind bei Ryzen-Platformen ja nicht neu.

→ https://ocaholic.ch/modules/news/article.php?storyid=16493&lang=german (da wird auf ein BIOS/UEFI-Update des MB-Herstellers verwiesen, der den aktuellen Microcode einspielen muss)

Es gibt da aktuell anscheinend noch einen weiteren Bug → https://www.extremetech.com/computing/246304-amd-fix-coming-fused-multiply-add-fma3-ryzen-bug

@elektronenblitz63: Danke für die Hilfe erst mal soweit. Ich habe jetzt im UEFI die Option "Global C-state Control" gefunden und von "Auto" auf "Disabled" gesetzt. Laut

1

cat /sys/module/intel_idle/parameters/max_cstate

ist immer noch der mysteriöse C-State 9 gesetzt. Wenn ich das nur richtig interpretieren könnte.

1

dpkg -l | grep amd64-microcode

ergibt:

1

ii  amd64-microcode                             2.20160316.1                                 amd64        Processor microcode firmware for AMD CPUs

keine Ahnung, ob da eine neuere Version von außerhalb der Paketquellen helfen könnte?

Hast Du memtest mal längere Zeit laufen lassen. Vielleicht kannst Du die RAM-Timings und den Takt im UEFI probeweise auch etwas moderater einstellen. Probleme mit dem RAM sind bei Ryzen-Platformen ja nicht neu.

memtest läuft Stundenlang durch ohne Fehler zu finden. Alle Einstellungen bezüglich RAM-Timings und Takt sind auf "Auto". Es ist und war nie etwas übertaktet.

→ https://ocaholic.ch/modules/news/art93&lang=german (da wird auf ein BIOS/UEFI-Update des MB-Herstellers verwiesen, der den aktuellen Microcode einspielen muss)

BIOS-Version ist die aktuelle von der ASUS-Seite (0902, AGESA 1.0.0.6b).

Es gibt da aktuell anscheinend noch einen weiteren Bug → https://www.extremetech.com/computinfma3-ryzen-bug

Der ist angeblich längst gefixt und hätte auch nur unter sehr speziellen Umständen Probleme gemacht. Hat nichts mit meinem Fehlerbild zu tun.

Rechnungstore schrieb:

ist immer noch der mysteriöse C-State 9 gesetzt. Wenn ich das nur richtig interpretieren könnte.

Mir auch nicht bekannt.

1	ii amd64-microcode 2.20160316.1 amd64 Processor microcode firmware for AMD CPUs

Es gibt IMHO momentan nichts aktuelleres

Alle Einstellungen bezüglich RAM-Timings und Takt sind auf "Auto". Es ist und war nie etwas übertaktet.

Nicht wegen Übertakten, den Standardtakt und Timings etwas herabsetzen meine ich, also den RAM probeweise etwas „untertakten“.