# Gentoo und Ryzen

## michael_w

Hallo,

ich plane für den Spätsommer einen neuen PC mit einer Ryzen-CPU. Nun irritiert mich ein wenig die Meldung bei fefe im Blog. 

https://community.amd.com/message/2796982

https://forums.gentoo.org/viewtopic-t-1061546-postdays-0-postorder-asc-start-0.html

Hat hier schon jemand eine Ryzen-CPU im Einsatz und kann etwas dazu sagen und wie sieht es perspektivisch aus mit den Problemen (im gentoo forum)?

----------

## schmidicom

So weit ich weiß (es gab dazu mal einen Artikel auf Heise) hatte der AM4-Microcode, welcher vom BIOS in die CPU geladen wird, einen Fehler den AMD inzwischen korrigiert hat. Wenn also das BIOS/UEFI den aktuellen Microcode für die neuen CPU's enthält sollte es wohl keine Probleme mehr geben.

EDIT:

Mein Spielerechner ist inzwischen eine solche AM4-Kiste und bis jetzt ist zumindest unter Windows noch nichts abgestürzt. Für die Installation von Linux hatte ich noch keine Zeit.

----------

## michael_w

Hallo,

 *schmidicom wrote:*   

> So weit ich weiß (es gab dazu mal einen Artikel auf Heise) hatte der AM4-Microcode, welcher vom BIOS in die CPU geladen wird, einen Fehler den AMD inzwischen korrigiert hat. Wenn also das BIOS/UEFI den aktuellen Microcode für die neuen CPU's enthält sollte es wohl keine Probleme mehr geben.

 

Ich kenne bzw. verfolge Heise zu dem Thema. AMD fixt imho derzeit mit den AGESA Updates so einiges. Aber scheinbar ist da das Ende der Fahnenstange noch lange nicht erreicht, wenn man die erwähnten Threads verfolgt.   :Evil or Very Mad: 

Neuer Thread dazu: https://www.phoronix.com/forums/forum/hardware/processors-memory/955368-some-ryzen-linux-users-are-facing-issues-with-heavy-compilation-loads

 *Quote:*   

> 
> 
> Mein Spielerechner ist inzwischen eine solche AM4-Kiste und bis jetzt ist zumindest unter Windows noch nichts abgestürzt. Für die Installation von Linux hatte ich noch keine Zeit.

 

Gerade unter Linux scheint es ja Probleme zu geben, warum auch immer (ich schätze Gentoo reizt da aus, was technisch geht).

----------

## demiurg

Als eigene Platform-Erfahrung (siehe unten)  4 Wochen in Betrieb ohne Übertakten mit win10 und Gentoo (monolithischer Kernel). Vorgängerplattform war ein AMD Phenom(tm) II X4 965 auf einem GA-890GPA-UD3H.

Das X370 Mainboard hat noch eine kleine Hängepartie mit dem Kernel 4.11. https://forums.gentoo.org/viewtopic-t-1063214.html - liegt aber an der Ausstattung mit zwei 1220 Chips. Auf dem alten System einen 4.11 Kernel mit den Ergänzungen für die neue Hardware vom Motherboard gebaut und dann auf das neue Equipment gewechselt, Laufwerke angeschlossen und alles lief.

Das BIOS war noch bei AGESA 1004. Damit gibt es noch RAM-Probleme. Ich hatte mich bewusst nur für 2400-er Module entschieden, die vom BIOS automatisch nur auf 2133 gestartet wurden. Mit Auswahl des XMP-Profil 1 liefen Sie mit 2400. Allerdings dann auch gelegentlich mit Segfault Abbrüchen beim Compilieren. Ein zweiter Anlauf für das gleiche Programm lief dann meist durch. Mit 2133 gab es nie Probleme. Es gibt jetzt ein Beta Bios mit AGESA 1006, das ich aber noch nicht getestet habe. In einschlägigen Foren bei Gigabyte wird von einer deutlichen Verbesserung der RAM-Erkennung berichtet, insbesondere von den Modulen für hohe Taktraten, die auch ohne Auswahl XMP-Profil automatisch für den hohen Takt erkannt werden und nicht nur mit 2133 gestartet werden.

In der make.conf hatte ich mit cpuid2cpuflags die CPU_FLAGS_X86="aes avx avx2 fma3 mmx mmxext popcnt sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3" aktualisiert, -j17 eingestellt und bei CFLAGS -mtune-native stehen lassen. Damit war erstmal die Grundlage für ein lauffähiges und compilierfähiges System gegeben.

Das Beta BIOS habe ich noch nicht ausprobiert, da ich das MoBo gestern wieder eingeschickt habe. Es verlor nach dem Runterfahren nicht reproduzierbar die Netzteilspannung und ließ sich nach dem 3. Auftreten zwar wiederbeleben aber nicht mehr booten.

P.S. Win 10 startete ohne Neuinstallation und benötigte nur einige Treiberaktualisierungen.

Insgesamt gesehen also lauffähig mit einigen Early Bird Unzulänglichkeiten.

edit:

MoBo ist wieder zurück und läuft inzwischen mit BIOS F4e mit AGESA 1.0.0.6. Segfaults hatte ich mit allen Standardeinstellungen (RAM mit xmp1 Profil) keine mehr. Allerdings war mesa-17.1.3 mit gcc-5.4.0 nicht zu bauen. Mittendrin gab es eine Reihe emake Fehler mit Abbruch. Ich habe gcc-6.3.0 demaskiert, den Upgradeprozess durchgeführt und versucht Mesa zu bauen. Abbruch an der gleichen Stelle beim Bauen von mesa. gcc-6.3.0 mit "sich selbst" noch mal gebaut(ob so was Sinn macht weiß ich nicht) libtool und llvm auch noch mit dem "erneuerten" gcc-6.3.0 neugebaut. Jetzt funktionierte der Bau von mesa. Ich habe mal eine Schleife von 20 x mesa bauen laufen lassen - alles ohne Aussteiger.

----------

## michael_w

Und ein neues Problem taucht auf: https://www.heise.de/newsticker/meldung/SegFault-Bug-AMD-bestaetigt-Ryzen-Fehler-beim-Kompilieren-unter-Linux-3796688.html

Nun frage ich mich gerade, bei Gentoo erlebt man ja teilweise ganze Compiler-Orgien (firefox, libreoffice, etc.). Da sind solche segfaults nicht hilfreich, oder? Anders gefragt, gibt es bei den Ryzen-Usern solche segfaults aktuell beim compilieren (so ala emerge -auvDN world)?

----------

## demiurg

https://community.amd.com/thread/215773?start=690&tstart=0 ist die Seite im Thread mit der Info von AMDMatt. Wenn Du das Thema über die Posts etwas verfolgst, sind die Segfaults erzeugbar, aber nicht immer reproduzierbar an der gleichen Stelle. Das macht eine dedizierte Fehlerbestimmung m.E. schwierig.

Mein Ryzen 1700 murkst da auch etwas, allerdings nur bei mesa. Ich benötige dann manchmal einen 2. oder 3. Anlauf. BIOS mit AGESA1.0.0.6a ist mindestens Pflicht, gcc-6.4 sicher nicht von Nachteil. Außer mesa habe ich bei keinem weiteren Paket Segfaults. emerge -uD -newuse world läuft bis jetzt klaglos durch, wenn kein mesa dabei ist. Also heute brauchte ich für mesa-17.2.0-rc3 einen 2. Anlauf. Der Abbruch erfolgte allerdings schon mit einem emake Error

und das log lieferte 

sh[29145] general protection ip:7fd461765620 sp:7ffd943006c8 error:0 in libc-2.23.so[7fd461646000+18c000]

Ich vermag nicht einzuschätzen, ob ein Microcodeupdate das verbessern wird oder wir alle noch RMAs an AMD schicken werden, um verbessertes Silizium zu bekommen. Mit einem Ryzen für Gentoo würde ich momentan jedenfalls noch warten.

----------

## michael_w

Hallo,

könntest Du mal das Stepping Deiner CPU posten!? Es scheint so, als wäre der Fehler in den neuen Steppings (Zeppelin B2) nicht mehr enthalten (siehe Kommentare bei Heise).

----------

## demiurg

Wird noch ein wenig dauern. Ich habe erst nächstes WE Gelegenheit die Kiste wieder auseinander zu pflücken. Ich will dann auch Anlauf über AMD Customer care nehmen.

Gruß

demiurg

----------

## demiurg

Ich habe mir das mit dem Stepping und der Herstellungswoche mal gespart und den Kühler drauf gelassen. Dafür den Weg über AMD customer care angestoßen. Es lauft jetzt mal die Standardprozedur, Bildschirmfotos vom BIOS, Temperaturüberwachung unter Last (Spaßvögel - geben noch kein Spezifikationen zum real-time Ermitteln der Chiptemperatur durch den Kernel raus) Für das Gerümpel wie https://linuxconfig.org/monitor-amd-ryzen-temperatures-in-linux-with-latest-kernel-modules fehlt mir im Moment auch die Zeit. Im Bios konnte ich wenigstens die Alarmtemperatur auf 60°C setzen und da gab es keinen Alarm wegen Temp >60°C dafür aber weiter segfaults.

Schauen wir mal, wie es weitergeht. Jedenfalls gibt es in diversen Foren Hinweise und aktuelle RMA Abwicklungen, dass die Produktion ab KW 27/2017 stabil läuft.

Gruß

demiurg

----------

## Josef.95

Jo, ist wohl nun auch halbwegs offiziell, und betroffene CPUs sollten ohne viel Aufwand ausgetauscht werden

laut https://www.golem.de/news/performance-marginality-amd-ersetzt-fehlerhafte-ryzen-7-prozessoren-1709-129873.html

----------

## schmidicom

Besser wäre ein offizielles kleines Programm, meinetwegen auch eines für Windows, das einem anzeigt ob der eigene Prozessor von dem Fehler betroffen ist oder nicht. Denn das Testprogramm aus dem Artikel braucht ja stellenweise bis zu mehrere Stunden um den Fehler aufzudecken.

----------

## demiurg

Es gab eine kleine Urlaubspause. 

Unter dem Strich ist alles ausgeschlossen worden, was helfen könnte bzw. Ursache sein könnte. Selbst das Beta-BIOS für das Board mit AGESA 1.0.0.6b , was ich gestern nach dem Urlaub ausprobiert habe, bringt nichts. Vom AMD Kundendienst habe ich einen Link für ein RMA Ticket bekommen, den Antrag gestern ausgefüllt und erst mal eine automatisierte Registrierung bekommen. Versandhinweise gibt es dann per Mail und wenn das Teil auf dem Weg ist, Info an den Kundenservice, damit der Ersatz sozusagen parallel auf den Weg gebracht wird. Ich gehe mal davon aus, dass es so auch wird.

Merkwürdigerweise ist das compilieren von mesa bei mir die beste Variante Segfaults zu produzieren. Das klappt sowohl ohne weitere "Grundlast" als auch mit "Grundlast" wie emerge gcc und emerge libreoffice in jeweils einer weiteren Konsole, die für sich auch schon mal über lange Strecken 100% CPU verursachen. Mesa verabschiedet sich dann zu völlig willkürlichen Zeitpunkten sicher mit einem Segfault. GCC verabschiedet sich selten und libreoffice nie.

Ich halte Euch auf dem Laufenden.

Edit 25.09. : Die CPU (Produziert KW 13 2017) ist auf dem Weg zum Austausch.

Gruß

demiurg

----------

## michael_w

Hallo allerseits, 

ich hatte mir ja einen 1800X gegönnt. Leider hat er scheinbar auch das Problem. Wie schon berichtet, bei mir ist es auch mesa, was segfaults erzeugt (beim compilieren). Ich habe aber auch das kill-ryzen.sh Script benutzt, ebenfalls mit segfaults. Ich hatte ja gehofft, das ich mit dem etwas späteren Kauf eine später gefertigte CPU bekomme, leider war dem wohl nicht so.   :Sad: 

Nunja, ich habe die CPU bei AMD reklamiert, mal schauen wie das weiter geht.

----------

## demiurg

So, eben habe ich den PC mit einem neuen Ryzen aus KW 33 hochgefahren. RMA Abwicklung hat funktioniert. AMD hat einen DHL Express Account für mein RMA angelegt, damit ich keine Versandkosten nach Holland tragen muss. Die alte CPU ist dann durch die Sichtkontrolle wegen mech. Unversehrtheit gelaufen und es gab eine Info, dass die o.k. war, allerdings das Lager mit Ersatz-CPU aufgefüllt werden muss, was zum 02.10. erwartet wurde. Insofern passt die Zustellung für nach dem Feiertag in D. Allerdings gab es keine Info mehr, dass die CPU in die Post gegangen ist, sondern sie war dann einfach da. 

Ich lasse mal emerge -uD --newuse world laufen, da ist dann mesa-17.2.2 mit dabei.

edit: 5x mesa ohne Fehler compiliert - sieht gut aus.

Gruß

demiurg

----------

## michael_w

Hallo allerseits, 

ich nutze den Thread weiterhin zu Dokumentationszwecken, vielleicht hilft es dem einen oder anderen. 

Ich hatte meine CPU (1800X) bei AMD via RMA getauscht. Mit der neuen CPU hatte ich dann hin und wieder freezes, sprich, der PC blieb ohne Last einfach stehen, nix ging mehr. Auch in den Logfiles war nichts zu finden. Ein Posting im heise Forum brachte dann Aufschluss. Weiter Infos findet man u.a. hier: https://bugzilla.kernel.org/show_bug.cgi?id=196683

Nach dem einschalten der kernel Optionen rund um RCU_NOCB_CPU treten bei mir keine freezes mehr auf. Offensichtlich geht die Diskussion hier weiter: https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/990202-linux-4-15-is-a-huge-update-for-both-amd-cpu-radeon-gpu-owners

Mal schauen was da noch rauskommt.

edit: hier beschreibt einer das Problem mit Ubuntu (und illustriert es anschaulich): http://blog.programster.org/ubuntu-16-04-compile-custom-kernel-for-ryzen

----------

## michael_w

Hallo,

nach über einem Jahr hole ich diesen Thread mal wieder raus, weil ... es ist wieder soweit. Seit neuestem habe ich hier das Problem, der Rechner bleibt ohne Last einfach "stehen". Man findet nichts im syslog. 

Was ist neu bei mir:

- ich habe umgestellt auf gcc 8.2 (vermutlich nicht das Problem)

- neuer kernel -> 4.19.27-r1

- letztens gab es ein update von linux-firmware (steckt da was für die cpu mit drin?)

- im syslog taucht seit kurzem das hier auf: 

```

Mar 19 07:12:52 ryzen kernel: [ 2136.069870] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)

Mar 19 07:12:52 ryzen kernel: [ 2136.069889]  cache: parent cpu10 should not be sleeping

Mar 19 07:12:52 ryzen kernel: [ 2136.069933] microcode: CPU10: patch_level=0x08001137

Mar 19 07:12:52 ryzen kernel: [ 2136.069994] CPU10 is up

Mar 19 07:12:52 ryzen kernel: [ 2136.070004] smpboot: Booting Node 0 Processor 11 APIC 0xb

```

und in dem oben genannten Thread bei bugzilla ist auch wieder "Leben in der Bude".  (https://bugzilla.kernel.org/show_bug.cgi?id=196683)

Frage, haben andere Ryzen User hier auch dieses Problem? Gibt es bereits eine Lösung dafür bzw. was ist der Grund für ein erneutes auftauchen des Problems?

----------

## demiurg

Hallo michael_w,

```
[    0.342950] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)

[    0.343223] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)

[    0.343484] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)

[    0.343747] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)

[    0.344010] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)

[    0.344277] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)

[    0.344531] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)

[    0.344798] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)

[    0.345073] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)

[    0.345354] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)

[    0.345627] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)

[    0.345904] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)

[    0.346178] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)

[    0.346457] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)

[    0.346732] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0)

[    0.347003] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW (0x0
```

kommt bei mir schon beim booten für alle 16 "Kerne"

Ich habe mich mit der Option "typical idle current"  anstelle auto im Bios "gerettet". Die Kiste ist seitdem auch bei langem Leerlauf stabil. Ob jetzt mit der Option möglicherweise die Meldung Firmwarebug zusammenhängt oder wo anders her, habe ich nicht untersucht. Bin froh, dass ich die RMA CPU bekommen habe und die Kiste stabil läuft. Den Bugzilla-Thread habe ich auch abonniert. Es ist noch ganz schön stochern im Nebel. Systemkomponenten siehe Signatur

Gruß

demiurg

-

----------

## haegar87

Bei mir überhaupt keine Probleme mit der Ryzen CPU.

Läuft butterweich...

Hier ein Auszug aller Meldung einmal mit dem Schlagwort "bug":

```
Mär 24 11:02:37 hostname kernel: ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored
```

Und mit dem Schlagwort "cpu"

```

Mär 24 11:02:37 hostname kernel: Command line: BOOT_IMAGE=/vmlinuz-5.0.2-gentoo.0 root=/dev/mapper/ssd-root ro quiet systemd.show_status=1 vfio-pci.ids=10de:1b81,10de:10f0,1b73:1100 vfio.allow_unsafe_interrupts=1 vfio-pci.allow_unsafe_interrupts=1 default_hugepagesz=1G hugepagesz=1G hugepages=16 transparent_hugepage=never isolcpus=8-15 nohz_full=8-15 rcu_nocbs=8-15 kvm.ignore_msrs=1 video=DP-1:2560x1080@60e video=DVI-D-1:1920x1080@60e

Mär 24 11:02:37 hostname kernel: ACPI: SSDT 0x00000000BC2CDF70 0020E4 (v01 AMD    AMD CPU  00000001 AMD  00000001)

Mär 24 11:02:37 hostname kernel: smpboot: Allowing 16 CPUs, 0 hotplug CPUs

Mär 24 11:02:37 hostname kernel: setup_percpu: NR_CPUS:64 nr_cpumask_bits:64 nr_cpu_ids:16 nr_node_ids:1

Mär 24 11:02:37 hostname kernel: percpu: Embedded 43 pages/cpu @(____ptrval____) s138968 r8192 d28968 u262144

Mär 24 11:02:37 hostname kernel: pcpu-alloc: s138968 r8192 d28968 u262144 alloc=1*2097152

Mär 24 11:02:37 hostname kernel: pcpu-alloc: [0] 00 01 02 03 04 05 06 07 [0] 08 09 10 11 12 13 14 15 

Mär 24 11:02:37 hostname kernel: Kernel command line: BOOT_IMAGE=/vmlinuz-5.0.2-gentoo.0 root=/dev/mapper/ssd-root ro quiet systemd.show_status=1 vfio-pci.ids=10de:1b81,10de:10f0,1b73:1100 vfio.allow_unsafe_interrupts=1 vfio-pci.allow_unsafe_interrupts=1 default_hugepagesz=1G hugepagesz=1G hugepages=16 transparent_hugepage=never isolcpus=8-15 nohz_full=8-15 rcu_nocbs=8-15 kvm.ignore_msrs=1 video=DP-1:2560x1080@60e video=DVI-D-1:1920x1080@60e

Mär 24 11:02:37 hostname kernel: SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=16, Nodes=1

Mär 24 11:02:37 hostname kernel: rcu:         RCU restricting CPUs from NR_CPUS=64 to nr_cpu_ids=16.

Mär 24 11:02:37 hostname kernel: rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=16

Mär 24 11:02:37 hostname kernel: NO_HZ: Full dynticks CPUs: 8-15.

Mär 24 11:02:37 hostname kernel: rcu:         Offload RCU callbacks from CPUs: 8-15.

Mär 24 11:02:37 hostname kernel: mce: CPU supports 23 MCE banks

Mär 24 11:02:37 hostname kernel: smpboot: CPU0: AMD Ryzen 7 1700X Eight-Core Processor (family: 0x17, model: 0x1, stepping: 0x1)

Mär 24 11:02:37 hostname kernel: smp: Bringing up secondary CPUs ...

Mär 24 11:02:37 hostname kernel: .... node  #0, CPUs:        #1  #2  #3  #4  #5  #6  #7  #8  #9 #10 #11 #12 #13 #14 #15

Mär 24 11:02:37 hostname kernel: smp: Brought up 1 node, 16 CPUs

Mär 24 11:02:37 hostname kernel: cpuidle: using governor menu

Mär 24 11:02:37 hostname kernel: [drm] GART: num cpu pages 65536, num gpu pages 65536

Mär 24 11:02:37 hostname kernel: microcode: CPU0: patch_level=0x08001129

Mär 24 11:02:37 hostname kernel: microcode: CPU1: patch_level=0x08001129

Mär 24 11:02:37 hostname kernel: microcode: CPU2: patch_level=0x08001129

Mär 24 11:02:37 hostname kernel: microcode: CPU3: patch_level=0x08001129

Mär 24 11:02:37 hostname kernel: microcode: CPU4: patch_level=0x08001129

Mär 24 11:02:37 hostname kernel: microcode: CPU5: patch_level=0x08001129

Mär 24 11:02:37 hostname kernel: microcode: CPU6: patch_level=0x08001129

Mär 24 11:02:37 hostname kernel: microcode: CPU7: patch_level=0x08001129

Mär 24 11:02:37 hostname kernel: microcode: CPU8: patch_level=0x08001129

Mär 24 11:02:37 hostname kernel: microcode: CPU9: patch_level=0x08001129

Mär 24 11:02:37 hostname kernel: microcode: CPU10: patch_level=0x08001129

Mär 24 11:02:37 hostname kernel: microcode: CPU11: patch_level=0x08001129

Mär 24 11:02:37 hostname kernel: microcode: CPU12: patch_level=0x08001129

Mär 24 11:02:37 hostname kernel: microcode: CPU13: patch_level=0x08001129

Mär 24 11:02:37 hostname kernel: microcode: CPU14: patch_level=0x08001129

Mär 24 11:02:37 hostname kernel: microcode: CPU15: patch_level=0x08001129

Mär 24 11:02:37 hostname kernel: acpi_cpufreq: overriding BIOS provided _PSD data

Mär 24 11:02:37 hostname dracut-cmdline[299]: Using kernel command line parameters: rd.lvm.lv=ssd/root rd.lvm.lv=ssd/boot rd.lvm.lv=hdd/swap resume=/dev/mapper/hdd-swap root=/dev/mapper/ssd-root rootfstype=ext4 rootflags=rw,relatime BOOT_IMAGE=/vmlinuz-5.0.2-gentoo.0 root=/dev/mapper/ssd-root ro quiet systemd.show_status=1 vfio-pci.ids=10de:1b81,10de:10f0,1b73:1100 vfio.allow_unsafe_interrupts=1 vfio-pci.allow_unsafe_interrupts=1 default_hugepagesz=1G hugepagesz=1G hugepages=16 transparent_hugepage=never isolcpus=8-15 nohz_full=8-15 rcu_nocbs=8-15 kvm.ignore_msrs=1 video=DP-1:2560x1080@60e video=DVI-D-1:1920x1080@60e

Mär 24 11:02:47 hostname libvirtd[818]: 2019-03-24 10:02:47.023+0000: 834: warning : qemuDomainObjTaint:7715 : Domain id=1 name='win10' uuid=25d7a261-7f62-4763-9267-8ed35840ecf9 is tainted: host-cpu

Mär 24 11:02:51 hostname libvirtd[818]: 2019-03-24 10:02:51.107+0000: 834: warning : qemuDomainObjTaint:7715 : Domain id=2 name='win10-work' uuid=8ab07a45-0391-452c-891b-4bb139718f82 is tainted: host-cpu

Mär 24 11:02:55 hostname kernel: kvm [1119]: vcpu0, guest rIP: 0xfffff8007b090950 ignored rdmsr: 0xc0011023

Mär 24 11:02:55 hostname kernel: kvm [1119]: vcpu0, guest rIP: 0xfffff8007b090965 ignored wrmsr: 0xc0011023 data 0x100

Mär 24 11:02:55 hostname kernel: kvm [1119]: vcpu1, guest rIP: 0xfffff8007b090950 ignored rdmsr: 0xc0011023

Mär 24 11:02:55 hostname kernel: kvm [1119]: vcpu1, guest rIP: 0xfffff8007b090965 ignored wrmsr: 0xc0011023 data 0x100

Mär 24 11:03:00 hostname kernel: kvm [1064]: vcpu0, guest rIP: 0xfffff8010dd03950 ignored rdmsr: 0xc0011023

Mär 24 11:03:00 hostname kernel: kvm [1064]: vcpu0, guest rIP: 0xfffff8010dd03965 ignored wrmsr: 0xc0011023 data 0x100

Mär 24 11:03:00 hostname kernel: kvm [1064]: vcpu1, guest rIP: 0xfffff8010dd03950 ignored rdmsr: 0xc0011023

Mär 24 11:03:00 hostname kernel: kvm [1064]: vcpu1, guest rIP: 0xfffff8010dd03965 ignored wrmsr: 0xc0011023 data 0x100

Mär 24 11:03:00 hostname kernel: kvm [1064]: vcpu2, guest rIP: 0xfffff8010dd03950 ignored rdmsr: 0xc0011023

Mär 24 11:03:00 hostname kernel: kvm [1064]: vcpu2, guest rIP: 0xfffff8010dd03965 ignored wrmsr: 0xc0011023 data 0x100

Mär 24 11:03:00 hostname kernel: kvm [1064]: vcpu3, guest rIP: 0xfffff8010dd03950 ignored rdmsr: 0xc0011023

Mär 24 11:03:00 hostname kernel: kvm [1064]: vcpu3, guest rIP: 0xfffff8010dd03965 ignored wrmsr: 0xc0011023 data 0x100

Mär 24 11:03:00 hostname kernel: kvm [1064]: vcpu4, guest rIP: 0xfffff8010dd03950 ignored rdmsr: 0xc0011023

Mär 24 11:03:00 hostname kernel: kvm [1064]: vcpu4, guest rIP: 0xfffff8010dd03965 ignored wrmsr: 0xc0011023 data 0x100

Mär 24 11:03:00 hostname kernel: kvm [1064]: vcpu5, guest rIP: 0xfffff8010dd03950 ignored rdmsr: 0xc0011023

Mär 24 11:03:00 hostname kernel: kvm [1064]: vcpu5, guest rIP: 0xfffff8010dd03965 ignored wrmsr: 0xc0011023 data 0x100

Mär 24 11:03:00 hostname kernel: kvm [1064]: vcpu6, guest rIP: 0xfffff8010dd03950 ignored rdmsr: 0xc0011023

Mär 24 11:03:00 hostname kernel: kvm [1064]: vcpu6, guest rIP: 0xfffff8010dd03965 ignored wrmsr: 0xc0011023 data 0x100

Mär 24 11:03:00 hostname kernel: kvm [1064]: vcpu7, guest rIP: 0xfffff8010dd03950 ignored rdmsr: 0xc0011023

Mär 24 11:03:00 hostname kernel: kvm [1064]: vcpu7, guest rIP: 0xfffff8010dd03965 ignored wrmsr: 0xc0011023 data 0x100

```

 *Quote:*   

> 
> 
> - ich habe umgestellt auf gcc 8.2 (vermutlich nicht das Problem)
> 
> - neuer kernel -> 4.19.27-r1
> ...

 

- gcc sollte es nicht sein, bin ebenfalls auf x86_64-pc-linux-gnu-8.2.0 ohne Probleme.

- Zum Kernel kann ich nichts sagen, bin inzwischen auf 5.0.2 mit znver1 Optimierung

- ja, im Paket linux-firmware steckt der AMD Mircocode:

```

# equery files linux-firmware

/lib

/lib/firmware

/lib/firmware/amd-ucode

/lib/firmware/amd-ucode/microcode_amd_fam17h.bin

```

----------

## michael_w

Hallo,

auch wieder zur Dokumentation. Ich habe diverse BIOS Einstellungen durchgetestet, nichts hat wirklich geholfen. Als Mainboard ist ein B 350 Gaming Pro Carbon von MSI verbaut, BIOS ist das derzeit aktuelle 7B00v1H. Das sporadische Einfrieren lässt sich nicht vernünftig nachvollziehen. Ich habe nun den kernel patch aus dem Kommentar Nr. 580 von hier: https://bugzilla.kernel.org/show_bug.cgi?id=196683#c580 eingebaut und boote nun mit der Zeile GRUB_CMDLINE_LINUX="rcu_nocbs=0-15 rifw=alfie" (siehe /etc/default/grub). Damit habe ich nun seit über einer Woche wieder ein stabiles system.

Ich sehe aber gerade, das sich da am kernel etwas tut in dieser Hinsicht: https://bugzilla.kernel.org/show_bug.cgi?id=196683 posting nr. 593. Ich werde das mal ausprobieren.

----------

## michael_w

Hallo, 

mal wieder eine "Wasserstandsmeldung". Vorweg nochmal, das Ganze hier hat ja weniger mit Gentoo zu tun, heisst, das System läuft zwar mit Gentoo, die Abstürze, etc. haben aber mit der Software (Gentoo) nix zu tun. 

Ich habe jetzt aus dem Thread bei bugzilla, aus dem Posting Nr. 615 (https://bugzilla.kernel.org/show_bug.cgi?id=196683#c615) die Einstellungen im BIOS übernommen ("Power Supply Idle Control" to ... "Typical Current Idle") danach den rifw-patch rausgenommen udn siehe da, der Rechner läuft seit einer Woche (mit diversen suspends) ohne Aufhänger stabil. Von daher erstmal alles gut bei mir. 

Gegen Ende des Jahres wird dann wohl ein Ryzen 7 3700X Einzug halten.

----------

## stahlsau

kurze Info dazu von mir, falls noch jemand anderes nach ner Lösung sucht:

hatte mit dem Ryzen 2600X auch erst unerklärliche freezes (richtiger hardlock, powercycle notwendig), die ich erst auf den Ryzen geschoben hatte. Hab alle bekannten fixes ausprobiert (u.a. was Du auch geschrieben hast), no-go.

Letztendlich lags an nouveau, der Treiber unterstützt meine RTX2060 zwar, friert aber immer wieder mal ein. Mit dem proprietären Treiber läufts problemlos.

----------

## l3u

Was ist denn momentan Stand der Dinge? Kann man mittlerweile bedenkenlos eine Ryzen-CPU kaufen? Und wenn ja, welche?

----------

## michael_w

 *l3u wrote:*   

> Was ist denn momentan Stand der Dinge? Kann man mittlerweile bedenkenlos eine Ryzen-CPU kaufen? Und wenn ja, welche?

 

sagen wir es so, mein 1800X läuft nun schon seit einiger Zeit ohne Probleme. Habe mir gerade das Upgrade, einen 3700X bestellt. Wenn der drin  steckt kann ich mehr dazu sagen. Aber ganz grundsätzlich spricht nichts gegen einen Ryzen.

----------

## l3u

Heißt jetzt "grundsätzlich", dass die die Probleme in den Griff bekommen haben?

----------

## michael_w

 *l3u wrote:*   

> Heißt jetzt "grundsätzlich", dass die die Probleme in den Griff bekommen haben?

 

wurde in software gelöst.

----------

## michael_w

So, 3700X ist eingebaut, samt einem gleichzeitigem Wechsel des Mainboards und des RAM. Das System ist quasi mit der NVME gewandert. Läuft ohne Probleme sofort los, lediglich der Netzwerktreiber musste neu in den Kernel gebaut werden.

btw; für /etc/portage/make.conf bleibt es wohl bei "CFLAGS="-O2 -march=znver1"" wie man liest!? Offenbar soll es wohl mit gcc 10 eine neue Optimierung geben (znver2). Hat das schonmal wer getestet?

----------

## Child_of_Sun_24

 *michael_w wrote:*   

> btw; für /etc/portage/make.conf bleibt es wohl bei "CFLAGS="-O2 -march=znver1"" wie man liest!? Offenbar soll es wohl mit gcc 10 eine neue Optimierung geben (znver2). Hat das schonmal wer getestet?

 

-march=znver2 gibt es schon bei gcc 9.X.X

----------

