Intel - Hardwarebug

[Columbo0815]

Ich habe sie vorhin installiert. Natürlich wurde vmm.ko auch geändert. Da ich aber ein eigenes Modul gebaut hatte, wurde es nicht überschrieben. Ich muss jetzt mal sehen, ob ich die alten Patches für den "-c Bug" noch gegen die neuen Sourcen bauen kann.

 

[Yamagi]

Die Änderungen an vmm halten sich stark in Grenzen, daher müsste es eigentlich gehen. Wenn nicht wäre es wahrscheinlich einfacher gleich auf 11-STABLE zu gehen, was beide Patches integriert.

 

[h^2]

Noch mal etwas abwarten, wenn aber im Frühjahr der erste Ryzen-Refresh kommt,

Also unter meinem Ryzen der zweiten Generation segfaultet mir der Clang mehrmals im buildworld weg, aber nicht reproduzierbar, also nicht an denselben Stellen. Die Fixes von https://lists.freebsd.org/pipermail/freebsd-current/2018-June/069799.html helfen auch explizit nicht – leider.
Ich versuche jetzt auf CURRENT zu wechseln und werde schauen ob es dann besser ist.

 

[h^2]

Auf CURRENT scheint es noch schlimmer zu sein, auch ohne hohe Load durch Kompilieren stürzt der Firefox nach 2-3min ab. Thunderbird stürzt sofort ab, ist quasi nicht benutzbar das System.
Das Devuan Linux im Dual Boot scheint bis jetzt Null Probleme zu haben. Ein erster Durchlauf mit memtest86+ brachte auch keine Fehler zu Tage.

 

[Yamagi]

Hast du den aktuellen Microcode eingespielt? Unter 12-CURRENT muss du nur noch sysutils/devcpu-data installieren und es in der /boot/loader.conf einschalten:

cpu_microcode_load="YES"

Wobei ich nicht weiß wie aktuell das Microcode-Paket für AMD im Port ist.

 

[edlomprul]

Ist es immer noch so, dass alpha/beta/snapshots nach der Installation per default langsamer sind als reguläre Releases? Irgendwas mit Debugging?
Oder kann man sich z.B. die 12.0 alpha 9 ohne großes Nachdenken installieren?

 

[h^2]

> Hast du den aktuellen Microcode eingespielt? Unter 12-CURRENT muss du nur noch sysutils/devcpu-data installieren und es in der /boot/loader.conf einschalten:

Jo, das habe ich drin. Nach ein wenig hin-und-her, ist das System jetzt wieder so "stabil" wie vorher, also normales Benutzen geht relativ gut, aber wenn man ordentlich Load auf die Cores packt segfaulten die betroffenen Prozesse.

Ist es immer noch so, dass alpha/beta/snapshots nach der Installation per default langsamer sind als reguläre Releases? Irgendwas mit Debugging?

Ja, witness ist aktiviert, das macht Sachen langsamer.

Oder kann man sich z.B. die 12.0 alpha 9 ohne großes Nachdenken installieren?

Geht sowieso auch nur per src im Moment. Erst von den BETAs gibt es es binary snapshots.

 

[serie300]

Hallo

kann mir mal jemand erklären, was man in Zukunft bei einer i5 Maschine unter FreeBSD 12 tun soll, um die wichtigen Microcode Updates zu bekommen. Ich bin anhand dieses Threads etwas verwirrt.

a) Ich habe die Updates von Lenovo über WIndows eingespielt. Brauche ich dann 'sysutils/devcpu-data' + 'cpu_microcode_load="YES"' noch?
b) Sollte man 'sysutils/devcpu-data' + 'cpu_microcode_load="YES"' auf jeden Fall einschalten und ist dann auf der sicheren Seite?

Serie300

 

[Andy_m4]

a) Ich habe die Updates von Lenovo über WIndows eingespielt.

Microcode-Updates sind nicht persistent und müssen bei jedem Systemstart erneut eingespielt werden.
Wenn die als Teil eines BIOS/UEFI-Update kommen übernimmt das eben das BIOS/UEFI.
Reine Windows-Updates dürften Dir dagegen nicht weiterhelfen.

 

[Yamagi]

Ich persönlich habe für mich mal entschieden in Sachen Microcode-Updates nicht mehr mit BIOS-Updates zu arbeiten. Aus mehreren Gründen. Es geht damit los, dass viel zu viele Hardware schon nach höchstens einigen Jahren keine BIOS-Updates mehr bekommt. Wenn überhaupt. Außerdem sind die Mainboard- und Systemhersteller träge, wenn es Updates gibt, kommen sie nicht selten mit Wochen oder sogar Monaten Verzögerung. Aus genau dieser Argumentation heraus ist auch Microsoft nach vielen Jahren der Verweigerungshaltung nun doch dazu übergegangen Microcode-Updates ohne 3rd Party Treiber aus Windows heraus zu ermöglichen und die Images per Windows Update auszuliefern.
Dazu kommt, dass BIOS-Updates händisch eingespielt werden müssen. Ich muss für jedes System regelmäßig schauen, ob es Updates gibt, Downtime anberäumen, das Update flashen... Es nervt. Und nicht zuletzt hatte ich über die Jahre einfach zu viele problematische BIOS-Updates, als das ich sie noch unbedarft einspielen würde. Das Fass zum Überlaufen brachte mein Dell XPS 13, in das ich ein Update mit defektem Skylake-Microcode eingespielt hatte. Aus "Sicherheitsgründen" ließ das System kein Downgrade mehr zu, Dells lapidare Meinung dazu war, dass ich auf das nächste Update warten müsse. Was erst nach Wochen kam.
Nimmt man einfach das Microcode-Paket und den im System integrierten Updater muss man sich um nichts kümmern. Das Paket aktualisiert von alleine mit und wenn es ein Problem geben sollte, macht man darauf halt ein Downgrade.

FreeBSD bis einschließlich 11.2 kann Microcode-Updates erst nach dem Boot einspielen:

• sysutils/devcpu-data installieren
• In der rc.conf 'microcode_update_enable="YES"' setzen

Der Nachteil dabei ist, dass das System mit veraltetem Microcode hochfährt. Wenn der Microcode größere Fehler aufweist, kommt es vielleicht gar nicht so weit oder ist schon inkonsistent. Wenn Software die per Microcode-Update in die CPU gepatchten Features nutzen will, sind diese beim Software-Start vielleicht noch nicht verfügbar.

Ab FreeBSD 12.0 können Microcode-Updates wie unter Linux auch früh im Boot eingespielt werden:

• sysutils/devcpu-data installieren
• In der loader.conf 'cpu_microcode_load="YES"' und besser auch noch 'cpu_microcode_name="/boot/firmware/intel-ucode.bin"' setzen.

Laut Manpage funktioniert das aber nur für Intel. Das hatte ich nicht beachtet, als ich gestern @h^2 den Tipp gab.