Du bist nicht angemeldet.

#1 25.10.2014 00:23:54

stefanhusmann
Moderator

Änderungen am Kernel hinsichtlich Microcode

Leider haben es schon einige schmerzlich mitbekommen: Auf einigen Rechnern ist es nach einem Update des Kernel nötig, manuelle Änderungen am Bootloader vorzunehmen. Insbesondere Intel-Prozessoren sind betroffen.

Die Änderungen sind je nach dem verwendeten Bootloader unterschiedlich und im englischen Wiki beschrieben.

Hat man eine Intel-CPU, aber intel-ucode nicht im Einsatz, ist keine Änderung nötig.

Entschuldigung für die späte Ankündigung.

Offline

#2 25.10.2014 10:41:11

chepaz
Mitglied

Re: Änderungen am Kernel hinsichtlich Microcode

stefanhusmann schrieb:

Hat man eine Intel-CPU, aber intel-ucode nicht im Einsatz, ist keine Änderung nötig.

Wann will man denn intel-ucode nutzen? IMHO ist das nur nötig wenn man in irgendwelche Firmwarebugs rennt oder der Kernel nicht mehr booten will. Ist das richtig?

Offline

#3 25.10.2014 12:14:37

Creshal
Mitglied

Re: Änderungen am Kernel hinsichtlich Microcode

Nachdem alle CPUs der letzten 20 Jahre seitenweise Firmwarebugs haben, sind regelmäßige Microcode-Updates durchaus sinnvoll. In der Regel werden die aber vom BIOS durchgeführt, wenn das aktuell ist (und der Hersteller aktuelle Microcode-Updates eingebettet hat), ists daher auf OS-Ebene nicht mehr nötig.

Offline

#4 25.10.2014 12:35:50

kar
Mitglied

Re: Änderungen am Kernel hinsichtlich Microcode

Ähm, da muss ich jetzt doch nochmal nachfragen:

Habe einen i7-2600K und ArchLinux startet auch mit dem neuen Kernel 3.17.1 problemlos. Ist es jetzt trotzdem ratsam "intel-ucode" zu installieren und meinen Bootloader entsprechend zu ergänzen? Oder könnte es eventuell auch schädlich sein, wenn bisher alles läuft?

Irgendwie sehe ich diesbezüglich auch nach dem Kommentar von Creshal nicht durch und im oben verlinkten Thema ist es wohl auch nicht allen klar, was diese Intel-Microcodes eigentlich genau sind bzw. machen.

Auf der anderen Seite, sind diese Microcodes auf der oben verlinkten Intel-Seite auch für i7 Desktop-CPUs freigegeben. Vielleicht werde ich es einfach mal vagen und installiere sie einfach mal.

Beitrag geändert von kar (25.10.2014 12:38:43)

Offline

#5 25.10.2014 12:56:11

efreak4u
Mitglied

Re: Änderungen am Kernel hinsichtlich Microcode

@kar
Warum etwas, was problemlos funktioniert veraendern?

Wenn alles laeuft, wie es soll und du keine Firmware-Aktualisierungen deiner CPU vornehmen willst, lass ucode weg und speichere diesen Thread im Gedaechnis unter "Wenn unerklaerbare Probleme, dann hier schauen" ab.

Online

#6 25.10.2014 12:58:58

Hackepeter
Mitglied

Re: Änderungen am Kernel hinsichtlich Microcode

Naja, Fehler in der CPU führen ja nicht gleich zum Absturz. Es können aber z.Bsp. falsche Rechenergebnisse entstehen. Soweit zumindest mein Kentnisstand.

Von daher weiss ich nicht, ob diese pauschale Aussage ok ist.

Mich würde auch interessieren, ob ich mich auf den Boardhersteller verlassen kann oder es Sinn macht, trotzdem ucode zu nehmen.


Grüße

Offline

#7 25.10.2014 13:09:29

efreak4u
Mitglied

Re: Änderungen am Kernel hinsichtlich Microcode

Zu den Fehlberechnungen:
Soweit ich weiss, werden die Operationen, die eine CPU durchfuehrt/errechnet immer noch mal gegen geprueft. Gibt es dabei Abweichungen wird das Ergebnis verworfen und neu berechnet. Sollte - bis auf einen im normalen Gebrauch nicht spuerbaren 'Zeitverlusst' - also keine grossen Auswirkungen haben. Wenn man die CPU fuer wissenschaftliche Berechnungen/Auswertungen/etc. benutzt, sieht das vermutlich auch wieder anders aus, da es dort sehr auf die Zeit ankommt.

Meine Intel i7-3770 CPU in Kombination mit einer Hauptplatine von Intel laufen jedenfalls super. BIOS/UEFI verwende ich die aktuellste Firmware-Version, obwohl diese eine grafische, bunte und mit Maus zu bedienende Oberflaeche hat. *wuerg*

Online

#8 25.10.2014 13:11:11

kar
Mitglied

Re: Änderungen am Kernel hinsichtlich Microcode

efreak4u schrieb:

@kar
Warum etwas, was problemlos funktioniert veraendern?

Und genau das ist eben die Frage? Diese Microcodes waren doch bisher im Paket "linux-firmware" enthalten und wurden jetzt in ein eigenes Paket ausgelagert, oder habe ich da etwas falsch verstanden? Zumindest schließe ich das aus dem oben verlinkten Wiki-Artikel, wo beschrieben steht, dass Microcodes nicht mehr automatisch aktualisiert werden. Oder liege ich hier gänzlich falsch?

Offline

#9 25.10.2014 13:11:59

Werner
Mitglied

Re: Änderungen am Kernel hinsichtlich Microcode

Meine Meinung:
Ich habe Intel-Microcode auf keinem Intel-Rechner installiert, ohne dadurch irgendeinen Nachteil erkennen zu können.
Intel erfasst die CPU-Bugs in Errata-Listen: ein Beispiel für den Core i7 als PDF. Nur wenige Bugs bzw. Errata werden entweder über ein BIOS-Update oder über den Microcode gefixt.
In dem jeweiligen »Processor Family: Specification Update« für den eigenen Prozessor kann man in der Spalte »Status« unter »Fixed« nachschauen, welche Probleme ein BIOS-Update bzw. der intel-ucode beheben würde. Sowas z.B. könnte ein BIOS-Update oder den Intel-Microcode nötig machen: TSX in Haswell.

Bislang sehe ich eigentlich keinen zwingenden Grund, intel-ucode zu verwenden, wenn man nicht von einem spezifischen Firmware-Bug betroffen ist (oder das bereits über ein BIOS-Update gelöst hat).  Aber ich lasse mich da gerne eines Besseren belehren.

Gruß, Werner

Offline

#10 25.10.2014 14:54:17

chepaz
Mitglied

Re: Änderungen am Kernel hinsichtlich Microcode

Creshal schrieb:

Nachdem alle CPUs der letzten 20 Jahre seitenweise Firmwarebugs haben, sind regelmäßige Microcode-Updates durchaus sinnvoll. In der Regel werden die aber vom BIOS durchgeführt, wenn das aktuell ist (und der Hersteller aktuelle Microcode-Updates eingebettet hat), ists daher auf OS-Ebene nicht mehr nötig.

Danke. Das ist ungefähr das was ich bestätigt haben wollte.

Offline

#11 25.10.2014 18:10:43

Martin-MS
Mitglied

Re: Änderungen am Kernel hinsichtlich Microcode

kar schrieb:

Diese Microcodes waren doch bisher im Paket "linux-firmware" enthalten und wurden jetzt in ein eigenes Paket ausgelagert, oder habe ich da etwas falsch verstanden?

Dieses Paket gibt es immer noch und so wie ich das verstehe befanden bzw. befindet sich hier nur Firmware irgendwelcher Hardwarekomponenten.

Was aber ab Kernel 3.17.1-1 fehlt und bis 3.16.4-1 noch enthalten war ist /usr/lib/modules/3.16.4-1-ARCH/kernel/arch/x86/kernel/cpu/microcode/microcode.ko.gz
Ich vermute, dass dies jetzt aus dem aktuellen (und dem lts-)Kernel in ein separates Paket ausgelagert wurde. Das bedeute aber auch, dass dadurch in der Vergangenheit der Microcode immer automatisch geladen wurde und man mehr oder weniger unbewusst immer schon die Korrekturen angewandt hat, was jetzt nicht mehr der Fall ist. Die Logik "habe ich bislang nicht gebraucht, brauche ich auch jetzt nicht" ist deshalb etwas kurz gegriffen.

Das man die Microcode-Korrekturen in einer früheren Phase des Bootvorgangs zur Verfügung stellen will kann ich ja noch verstehen, die Umsetzung finde ich aber unglücklich gelöst. Warum wurde dafür ein neues Paket erstellt, für das weder eine optionale Abhängigkeit im Kernel-Paket hinterlegt wurde noch bei der Kernel-Aktualisierung hingewiesen wird. Und warum wurde der Microcode nicht einfach als Image im Kernel-Paket belassen und nach /boot installiert so wie es das separate Paket jetzt auch macht? Aktiviert werden hätte es dann immer noch über die Bootloader-Konfiguration aber man hätte sich das zusätzliche Paket gespart und vor allem würde das Image an richtiger Stelle bereits verfügbar sein und könnte notfalls über die Bootloader-Kommandozeile noch aktiviert werden wenn der Bootvorgang fehlschlägt und man behielte wenigstens ein beschränkt lauffähiges System.

Wer jetzt in einen Fehler läuft muss erst ein Arch-Notfall-System starten, sich das entsprechende Microcode-Paket besorgen und installieren und die Korrekturen am Bootloader vornehmen.

Offline

#12 25.10.2014 18:46:49

kar
Mitglied

Re: Änderungen am Kernel hinsichtlich Microcode

Martin-MS schrieb:

Was aber ab Kernel 3.17.1-1 fehlt und bis 3.16.4-1 noch enthalten war ist /usr/lib/modules/3.16.4-1-ARCH/kernel/arch/x86/kernel/cpu/microcode/microcode.ko.gz
Ich vermute, dass dies jetzt aus dem aktuellen (und dem lts-)Kernel in ein separates Paket ausgelagert wurde. Das bedeute aber auch, dass dadurch in der Vergangenheit der Microcode immer automatisch geladen wurde und man mehr oder weniger unbewusst immer schon die Korrekturen angewandt hat, was jetzt nicht mehr der Fall ist. Die Logik "habe ich bislang nicht gebraucht, brauche ich auch jetzt nicht" ist deshalb etwas kurz gegriffen.

Und genau darum geht es mir!

Bisher wurden die Microcodes über das Paket "linux-firmware" ausgeliefert und jetzt wurden sie in das neue Paket verpackt. Wenn ich jetzt also nach der Logik "Warum etwas, was problemlos funktioniert veraendern?" vorgehen will, muss ich mir also das neue Paket "intel-ucode" installieren und meinen Bootloader entsprechend anpassen?!

Aber warum wurden die Intel-Microcodes dann überhaupt in ein eigenes Paket ausgelagert? Wurde das von Intel gefordert oder hat es andere Gründe? Vielleicht Lizenz-Rechtliche Probleme bzw. Unstimmigkeiten?

Offline

#13 25.10.2014 19:50:03

Martin-MS
Mitglied

Re: Änderungen am Kernel hinsichtlich Microcode

kar schrieb:

Bisher wurden die Microcodes über das Paket "linux-firmware" ausgeliefert und jetzt wurden sie in das neue Paket verpackt.

Eben nicht; sie wurden bislang mit dem Kernel als Kernelmodul microcode.ko.gz ausgeliefert und jetzt als Image in einem neuen Paket.

Wenn ich jetzt also nach der Logik "Warum etwas, was problemlos funktioniert veraendern?" vorgehen will, muss ich mir also das neue Paket "intel-ucode" installieren und meinen Bootloader entsprechend anpassen?!

Das ist ja eben die Frage, ob es wirklich immer und bei jedem in der Vergangenheit problemlos funktionierte. Scheinbar nicht, sonst hätte man sich nicht dazu entschlossen, den Microcode in den Bootvorgang vorzuziehen.

Aber warum wurden die Intel-Microcodes dann überhaupt in ein eigenes Paket ausgelagert? Wurde das von Intel gefordert oder hat es andere Gründe? Vielleicht Lizenz-Rechtliche Probleme bzw. Unstimmigkeiten?

OK, das hatte ich ja weiter oben auch schon in Frage gestellt, warum man das Image nicht im Kernelpaket lassen konnte. Lizenzrechtliche Gründe halte ich für ausgeschlossen weil  ja einerseits der Microcode von Intel und für Linux öffentlich auf deren Website angeboten wird und zum anderen nur eine Verschiebung unter den verschiedenen Paketen stattgefunden hat; das löst keine Lizenzprobleme.

Der einzige plausible Grund für mich ist eigentlich nur, dass man nicht für beide Prozessorhersteller Intel und AMD in einem Kernel gemeinsam zwei Images aufnehmen wollte von denen eines dann immer und garantiert nicht benötigt würde. Unter /boot hätte man dann zwei Images mit verschiedenen Bezeichnungen, von denen man dann das richtige in den Bootloader aufnehmen müsste. Wie man das mit dem bis jetzt gemeinsam genutzten Kernelmodul gemacht hat weiß ich auch nicht, jedenfalls ist das Modul "microcode" unter Kernel-3.16 noch geladen.
Aber das ist auch nur eine Vermutung, besonders viel erfährt man ja zu dem Thema nicht.

Offline

#14 26.10.2014 02:51:49

LessWire
Mitglied

Re: Änderungen am Kernel hinsichtlich Microcode

Hello to all !

stefanhusmann schrieb:

Hat man eine Intel-CPU, aber intel-ucode nicht im Einsatz, ist keine Änderung nötig.

Dann könnte man eigentlich auch sagen, intel-ucode ist überflüssig. wink

Also ich sehe es so:

Der Hersteller hat schon seinen Grund, diesen "Korrekturcode" bereitzustellen und er sollte möglichst früh direkt in den Prozessor geladen werden. Wenn das ein aktuelles  BIOS bewerkstelligt - ok, aber wer weiß das schon. Darauf würde ich mich nicht verlassen, zumal es nicht schadet den Code im ungünstigsten Fall zweimal zu laden.

Für meine Rechner mit Intel Prozessoren habe ich es aktiviert und jetzt entsprechend geändert. Für AMD auch, aber da bleibt's ja erstmal bei der alten Prozedur.

Klar, der Rechner läuft auch ohne vermeintlich fehlerfrei, aber sind es nicht oft die kleinen "unerklärlichen" Effekte, die ab und zu mal auftreten? Muß natürlich nicht an diesem ucode liegen, kann aber! Und das will ich doch mal ausschliessen, wenn es schon die Möglichkeit gibt. wink

Gruß, mmi

Offline

#15 26.10.2014 17:04:12

ArchChem
Mitglied

Re: Änderungen am Kernel hinsichtlich Microcode

stefanhusmann schrieb:

Die Änderungen sind je nach dem verwendeten Bootloader unterschiedlich und im englischen Wiki beschrieben.

Für alle nicht englischsprechenden User habe ich den Artikel mal übersetzt: https://wiki.archlinux.de/title/Microcode.
Ist noch nicht ganz vollständig, werde ich aber demnächst noch ergänzen. Die wichtigsten Bootloader stehen schon mal drin.

ArchChem

Offline

#16 26.10.2014 18:46:00

unklar
Gesperrt

Re: Änderungen am Kernel hinsichtlich Microcode

ArchChem schrieb:

Für alle nicht englischsprechenden User habe ich den Artikel mal übersetzt..

Großes Dankeschön!   wink

Offline

#17 27.10.2014 07:36:28

mönch
Mitglied

Re: Änderungen am Kernel hinsichtlich Microcode

Habe bei mir mit "dmesg" nachgeschaut (noch der Kernel 3.16.4-1)

 [     9.690542] microcode: CPU0 sig=0x861, pf=0x8, revision=0xf   
 [     9.807008] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba 

Mehr steht nichts drin. Das bedeutet, Microship-Update wurde nicht ausgeführt, obwohl das Modul laut "lsmod" aktiv ist. Wie ich verstehe, wird intel-ucode bei mir nicht eingesetzt und ich brauche das Paket intel-ucode nicht installieren, oder sicherheitshalber vielleicht doch?

Mein Prozessor IP 3 M Baujahr 1999 würde zu der Kategorie IP Prozessor for Mobile aus der Liste passen, aber schlau aus der Liste bin ich nicht geworden.

Beitrag geändert von mönch (27.10.2014 08:13:21)

Offline

#18 27.10.2014 19:15:07

Photor
Mitglied

Re: Änderungen am Kernel hinsichtlich Microcode

ArchChem schrieb:

Für alle nicht englischsprechenden User habe ich den Artikel mal übersetzt: https://wiki.archlinux.de/title/Microcode.
Ist noch nicht ganz vollständig, werde ich aber demnächst noch ergänzen. Die wichtigsten Bootloader stehen schon mal drin.

Danke ArchChem,

wenn ich das richtig verstanden habe, SOLLTE man den microcode schon einspielen, richtig? Mein Rechnerchen hat folgende CPU

# cat /proc/cpuinfo
[...]
processor	: 3
vendor_id	: GenuineIntel
cpu family	: 6
model		: 69
model name	: Intel(R) Core(TM) i5-4300U CPU @ 1.90GHz
stepping	: 1
microcode	: 0x16
cpu MHz		: 1138.281
cache size	: 3072 KB
physical id	: 0
siblings	: 4
core id		: 1
cpu cores	: 2
apicid		: 3
initial apicid	: 3
fpu		: yes
fpu_exception	: yes
cpuid level	: 13
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm ida arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm xsaveopt
bugs		:
bogomips	: 4990.40
clflush size	: 64
cache_alignment	: 64
address sizes	: 39 bits physical, 48 bits virtual
power management:

die bisher auch ganz ordentlich tut. Ich frage mich, ob Variante 1: "never change a running system" oder Variante 2: ich versuche mein System so weit zu optimieren, wie es geht, die bessere ist wink. Als Boot-Loader ist ein Grub installiert.

Ciao,

Photor

Offline

#19 27.10.2014 21:24:26

ArchChem
Mitglied

Re: Änderungen am Kernel hinsichtlich Microcode

"Phoster schrieb:

Ich frage mich, ob Variante 1: "never change a running system" oder Variante 2: ich versuche mein System so weit zu optimieren, wie es geht, die bessere ist wink. Als Boot-Loader ist ein Grub installiert.

Dann würde ich dir  empfehlen, es dabei zu lassen smile Meiner Meinung nach ist es sowieso eher für wissenschaftliche Analysen wichtig, dass der Prozessor 100%ig up to date ist und sich quasi kaum verrechnet. So geht vielleicht alles einen Tick schneller, der "normale" Anwender merkt jedoch den Unterschied sowieso nicht...
Aber das muss natürlich jeder für sich selbst entscheiden...

Liebe Grüße
ArchChem

Beitrag geändert von ArchChem (27.10.2014 21:24:51)

Offline

#20 27.10.2014 22:53:42

Kabbone
Mitglied

Re: Änderungen am Kernel hinsichtlich Microcode

Nach dieser Theorie sollte man auch keine Updates bei Arch machen. Ich sehe soweit eigentlich keine größeren Risiken den Microcode upzudaten, lasse mich aber gerne eines besseren belehren

Offline

#21 27.10.2014 23:12:02

Martin-MS
Mitglied

Re: Änderungen am Kernel hinsichtlich Microcode

Ein Risiko ist es sowieso nicht weil die Microcode-Korrektur immer nur temporär und nicht statisch ist. Wahrscheinlich haben sie auch in der Vergangenheit die meisten schon durch das automatisch geladene Kernelmodul durchgeführt (lässt sich im Journal verfolgen wenn man auf "microcode" filtert). Ich habe es auf zwei Rechnern installiert, hier auf dem Arbeitsrechner wird eine Korrektur durchgeführt, auf dem Notebook nicht; wahrscheinlich ist der Prozessor zu alt oder wird nicht unterstützt. Die Änderung ist ja eigentlich nur, dass die Korrektur jetzt nicht mehr über ein Kernelmodul währen des Bootvorgangs erfolgt sondern ziemlich früh über ein Image.
Es hat schon einen gewissen Charm dass man auf diese Weise noch zu Microcode-Korrekturen des CPU-Herstellers kommt, wenn die Mainboard-Hersteller die BIOS-Unterstützung schon lange aufgegeben haben.

Offline

#22 27.10.2014 23:41:17

ArchChem
Mitglied

Re: Änderungen am Kernel hinsichtlich Microcode

Kabbone schrieb:

Nach dieser Theorie sollte man auch keine Updates bei Arch machen. Ich sehe soweit eigentlich keine größeren Risiken den Microcode upzudaten, lasse mich aber gerne eines besseren belehren

Risiken entstehen dabei nicht, wie du ja schon sagst. Es ist aber halt eine Frage des Aufwandes, ob ich Lust habe, meinen GRUB mittels einer temporären Notlösung zu konfigurieren (siehe Wiki-Artikel), die beide eher schlecht als recht sind, oder ob man erst einmal abwartet.

Offline

#23 28.10.2014 11:16:49

Kabbone
Mitglied

Re: Änderungen am Kernel hinsichtlich Microcode

ArchChem schrieb:
Kabbone schrieb:

Nach dieser Theorie sollte man auch keine Updates bei Arch machen. Ich sehe soweit eigentlich keine größeren Risiken den Microcode upzudaten, lasse mich aber gerne eines besseren belehren

Risiken entstehen dabei nicht, wie du ja schon sagst. Es ist aber halt eine Frage des Aufwandes, ob ich Lust habe, meinen GRUB mittels einer temporären Notlösung zu konfigurieren (siehe Wiki-Artikel), die beide eher schlecht als recht sind, oder ob man erst einmal abwartet.

Wer sagt, dass das eine temporäre Notlösung ist?

Offline

#24 28.10.2014 11:30:52

chepaz
Mitglied

Re: Änderungen am Kernel hinsichtlich Microcode

Kabbone schrieb:

Wer sagt, dass das eine temporäre Notlösung ist?

Da du mit dieser Methodik immer selbst daran denken musst die Bootloaderkonfigurationen anzupassen ist das definitiv eine Notlösung.

Offline

#25 28.10.2014 12:49:56

Kabbone
Mitglied

Re: Änderungen am Kernel hinsichtlich Microcode

chepaz schrieb:

Da du mit dieser Methodik immer selbst daran denken musst die Bootloaderkonfigurationen anzupassen ist das definitiv eine Notlösung.

Das zähle ich jetzt mal nicht als Argument, weil wenn ich ein Feature nutzen will, muss ich es eben einrichten und das in diesem Fall 1x, sei es direkt in der Grub-config oder z.B. wenn man sich diese öfter generieren lässt in dem default-file.
Nach der Argumentation wäre ja dm-crypt auch eine Notlösung, weil das muss ich auch immer im Bootloader anpassen

Offline

Schnellantwort auf dieses Thema

Schreibe deinen Beitrag und versende ihn
Deine Antwort

Fußzeile des Forums