[Bug 847158] New: intel microcode not loaded?
https://bugzilla.novell.com/show_bug.cgi?id=847158
https://bugzilla.novell.com/show_bug.cgi?id=847158#c0
Summary: intel microcode not loaded?
Classification: openSUSE
Product: openSUSE 13.1
Version: RC 1
Platform: Other
OS/Version: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Kernel
AssignedTo: kernel-maintainers@forge.provo.novell.com
ReportedBy: jnelson-suse@jamponi.net
QAContact: qa-bugs@suse.de
Found By: ---
Blocker: ---
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101
Firefox/24.0
I do have microcode_ctl ( microcode_ctl-1.17-142.5.1.x86_64 ) installed, but it
doesn't appear to have changed anything:
linux-k1fq:/lib/firmware/intel-ucode # dmesg | grep microcode
[ 0.000000] Looking for kernel/x86/microcode/GenuineIntel.bin
[ 0.021286] perf_event_intel: PEBS disabled due to CPU errata, please
upgrade microcode
[ 0.627676] microcode: CPU0 sig=0x206a7, pf=0x10, revision=0x1b
[ 0.627681] microcode: CPU1 sig=0x206a7, pf=0x10, revision=0x1b
[ 0.627711] microcode: Microcode Update Driver: v2.00
https://bugzilla.novell.com/show_bug.cgi?id=847158
https://bugzilla.novell.com/show_bug.cgi?id=847158#c1
Borislav Petkov
https://bugzilla.novell.com/show_bug.cgi?id=847158
https://bugzilla.novell.com/show_bug.cgi?id=847158#c2
--- Comment #2 from Jon Nelson
https://bugzilla.novell.com/show_bug.cgi?id=847158
https://bugzilla.novell.com/show_bug.cgi?id=847158#c3
--- Comment #3 from Jon Nelson
https://bugzilla.novell.com/show_bug.cgi?id=847158
https://bugzilla.novell.com/show_bug.cgi?id=847158#c4
Borislav Petkov
https://bugzilla.novell.com/show_bug.cgi?id=847158
https://bugzilla.novell.com/show_bug.cgi?id=847158#c5
Dirk Weber
https://bugzilla.novell.com/show_bug.cgi?id=847158
https://bugzilla.novell.com/show_bug.cgi?id=847158#c6
Borislav Petkov
https://bugzilla.novell.com/show_bug.cgi?id=847158
https://bugzilla.novell.com/show_bug.cgi?id=847158#c7
Dirk Weber
https://bugzilla.novell.com/show_bug.cgi?id=847158
https://bugzilla.novell.com/show_bug.cgi?id=847158#c8
--- Comment #8 from Dirk Weber
https://bugzilla.novell.com/show_bug.cgi?id=847158
https://bugzilla.novell.com/show_bug.cgi?id=847158#c9
Borislav Petkov
https://bugzilla.novell.com/show_bug.cgi?id=847158
https://bugzilla.novell.com/show_bug.cgi?id=847158#c10
--- Comment #10 from Dirk Weber
https://bugzilla.novell.com/show_bug.cgi?id=847158
https://bugzilla.novell.com/show_bug.cgi?id=847158#c11
--- Comment #11 from Dirk Weber
https://bugzilla.novell.com/show_bug.cgi?id=847158
https://bugzilla.novell.com/show_bug.cgi?id=847158#c12
Borislav Petkov
I have a valid microcode file which loads successfully with echo 1 > /sys/devices/system/cpu/microcode/reload
Therefore I do not think the version of the microcode file is the problem, even if seems to be a leftover of 12.3
Who said the version is the problem?
I read arch/x86/kernel/microcode_amd_early.c, and according to this the microcode must be prepended to the initrd in a file kernel/x86/microcode/AuthenticAMD.bin "Microcode patch container file is prepended to the initrd in cpio format."
That's what the last 'cat' command in Documentation/x86/early-microcode.txt does.
I will try to produce an initrd according to the procedure described in Documentation/x86/early-microcode.txt
Still confusing is that there are 2 microcode files for AMD and lots for Intel At least for AMD it is easy to choose the correct one.
The Intel microcode is also supposed to be one file. The split patches in the microcode_ctl package are not the ones you can directly use for early microcode loading - this file is talking about the microcode blobs you get from the CPU vendors directly, at least in the Intel case. In the AMD case, you can simply cat all the bin files together. (In reply to comment #11)
The procedure described in Documentation/x86/early-microcode.txt works.
dmesg|grep microc [ 0.147631] microcode: CPU1: new patch_level=0x010000db [ 0.162593] microcode: CPU2: new patch_level=0x010000db [ 0.177585] microcode: CPU3: new patch_level=0x010000db [ 0.853640] microcode: updated early to new patch_level=0x010000db [ 0.863500] microcode: CPU0: patch_level=0x010000db [ 0.863545] microcode: CPU1: patch_level=0x010000db [ 0.863596] microcode: CPU2: patch_level=0x010000db [ 0.863646] microcode: CPU3: patch_level=0x010000db [ 0.863716] microcode: Microcode Update Driver: v2.00
, Peter Oruba Specifically I used: cp /lib/firmware/amd-ucode/microcode_amd.bin kernel/x86/microcode/AuthenticAMD.bin
with /lib/firmware/amd-ucode/microcode_amd.bin from the "obsolete" microcode_ctl package.
Good, thanks for confirming this. @Michal, can we add the microcode to the initrd creation process for oS? Actually for SLE12 too, while we're at it. Thanks. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=847158
https://bugzilla.novell.com/show_bug.cgi?id=847158#c13
--- Comment #13 from Dirk Weber
From bnc#851398 I learned that for 13.1 ucode-amd and ucode-intel packages exist.
I can confirm that the update with zypper dup from 12.3 did not replace the microcode_ctl from 12.3 with the new ucode-* packages of 13.1. I manually uninstalled microcode_ctl and installed ucode-amd. With the microcode from ucode-amd (/lib/firmware/amd-ucode/microcode_amd.bin) microcode update works on my system (of course). I have only tried "late" updating by echo 1 > /sys/devices/system/cpu/microcode/reload with this version, but I am quite sure if properly included in the initrd early update will work, too. To me the packaging of ucode files and their signatures is a little bit strange: $ rpm -qf /lib/firmware/amd-ucode/microcode_amd.bin ucode-amd-20130714git-2.1.1.noarch $ rpm -qf /lib/firmware/amd-ucode/microcode_amd.bin.asc kernel-firmware-20130714git-2.1.1.noarch Is there some deeper meaning that the binaries and their signatures are not in the same package? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=847158
https://bugzilla.novell.com/show_bug.cgi?id=847158#c14
Thomas Renninger
@Michal, can we add the microcode to the initrd creation process for oS? dracut does this already. At least for Intel the "early microcode update feature is implemented", for AMD it needs to be double checked. Iirc I at least stumbled over some kernel code, that enables early microcode loading for AMD.
Is there some deeper meaning that the binaries and their signatures are not in the same package? Yes. I asked Intel and AMD to submit their microcodes to the kernel-firmware project/git repo for the future. Like that they do not have to open bugs every some months for all distros they would like to see their microcodes included, but can simply submit their stuff to where it belongs: kernel-firmware git repo. And all distros can pick it up and add things to their supported products with all the other up-to-date firmware in there.
Unsatisfied dependencies for microcode_ctl-1.17-142.5.1.x86_64: microcode_ctl is obsoleted by (installed) This looks weird? Did you do a fresh 13.1 (RC1 or earlier?) installation and
While AMD did adjust their license and is submitting their microcodes to kernel-firmware now, Intel does and will not, due to license issues. It looks like the microcode updating mechanism works in general, but we have a higher level problem at packaging/installer level? then update (zypper dup) to GM? Then this may simply be an issue that you installed a devel version when later the microcode_ctl package got split. Or was this a 12.3 to 13.1 update? Hm, I remember a bug where zypper/rpm did not detect correctly whether firmware package has to be installed. Maybe you installed at that time? Anyway, if we want to root cause this, it makes sense to install a fresh 13.1 GM to make sure there are no "devel release only" problems we are hunting. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=847158
https://bugzilla.novell.com/show_bug.cgi?id=847158#c15
--- Comment #15 from Thomas Renninger
@Michal, can we add the microcode to the initrd creation process for oS? dracut does this already. That means this is not implemented in 13.1, but only in factory yet. But that should not matter, this is a brand new feature this bug is not about. Let's discuss and make sure general microcode loading via services is working correctly for 13.1 here.
-- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=847158
https://bugzilla.novell.com/show_bug.cgi?id=847158#c16
--- Comment #16 from Michele Cherici
Anyway, if we want to root cause this, it makes sense to install a fresh 13.1 GM to make sure there are no "devel release only" problems we are hunting.
I've installed a fresh 13.1 (used DVD x86_64 and KDE Live x86_64) and ucode-intel is not installed. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=847158
https://bugzilla.novell.com/show_bug.cgi?id=847158#c17
Dirk Weber
@Michal, can we add the microcode to the initrd creation process for oS? dracut does this already. At least for Intel the "early microcode update feature is implemented", for AMD it needs to be double checked. Iirc I at least stumbled over some kernel code, that enables early microcode loading for AMD. in comment #11 I have written that the "early microcode update" works for AMD CPUs with standard 13.1 if only the initrd correctly contains the microcode.
It looks like the microcode updating mechanism works in general, but we have a higher level problem at packaging/installer level? I agree.
Unsatisfied dependencies for microcode_ctl-1.17-142.5.1.x86_64: microcode_ctl is obsoleted by (installed) This looks weird? Did you do a fresh 13.1 (RC1 or earlier?) installation and then update (zypper dup) to GM? Then this may simply be an issue that you installed a devel version when later the microcode_ctl package got split. Or was this a 12.3 to 13.1 update? I observed it at 2 systems. One was updated with zypper dup from a fully updated 12.3 to 13.1RC2, the other one from a fully updated 12.3 to 13.1GM.
Hm, I remember a bug where zypper/rpm did not detect correctly whether firmware package has to be installed. Maybe you installed at that time? Anyway, if we want to root cause this, it makes sense to install a fresh 13.1 GM to make sure there are no "devel release only" problems we are hunting. comment #16 also confirms that the ucode-* packages are not installed in a clean install from DVD.
There are now several tickets open related to microcode loading and the information is distributed between these tickets: bnc#851398 bnc#761728 Summing these up it seems: - early microcode loading is working (tested myself with AMD systems) when the ucode is prepended to the initrd. - "late" microcode loading is working (tested myself with AMD systems) - if the ucode files are available BUT: - mkinitrd does not prepend the ucodes into the initrd - could be fixed by an addon script to mkinitrd, the steps to do it are not complicated. - the ucode-* packages are not installed by default and the old microcode_ctl package is not removed - could maybe be fixed by some dependency or pattern update? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=847158
https://bugzilla.novell.com/show_bug.cgi?id=847158#c18
--- Comment #18 from Dirk Weber
Summing these up it seems: - early microcode loading is working (tested myself with AMD systems) when the ucode is prepended to the initrd. - "late" microcode loading is working (tested myself with AMD systems) - if the ucode files are available
I have additional results from another system with an AMD E-350 CPU.
In this case "late" microcode update works:
[ 1.301598] microcode: CPU0: patch_level=0x05000028
[ 1.301616] microcode: CPU1: patch_level=0x05000028
[ 1.301780] microcode: Microcode Update Driver: v2.00
https://bugzilla.novell.com/show_bug.cgi?id=847158
https://bugzilla.novell.com/show_bug.cgi?id=847158#c19
--- Comment #19 from Dirk Weber
I have additional results from another system with an AMD E-350 CPU. In this case "late" microcode update works: [ 1.301598] microcode: CPU0: patch_level=0x05000028 [ 1.301616] microcode: CPU1: patch_level=0x05000028 [ 1.301780] microcode: Microcode Update Driver: v2.00
, Peter Oruba # echo 1 > /sys/devices/system/cpu/microcode/reload
[ 737.932099] microcode: CPU0: new patch_level=0x05000029 [ 737.940576] microcode: CPU1: new patch_level=0x05000029
But early microcode update with a handcrafted initrd (like in comment #11) causes a reboot (everything tested with plain 13.1).
So there are still more problems in this area, and just adding the ucodes to the initrd could cause boot problems for users on certain systems.
bnc#852007 opened to track this specific issue with AMD E-350 separately from the initrd creation or general microcode loading via services as mentioned in comment #15 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=847158
https://bugzilla.novell.com/show_bug.cgi?id=847158#c20
--- Comment #20 from Thomas Renninger
https://bugzilla.novell.com/show_bug.cgi?id=847158
https://bugzilla.novell.com/show_bug.cgi?id=847158#c21
Thomas Renninger
https://bugzilla.novell.com/show_bug.cgi?id=847158
https://bugzilla.novell.com/show_bug.cgi?id=847158#c22
--- Comment #22 from Thomas Renninger
Ideally modalias(pci...) is checked against lspci And best there is an interface in module-init-tools which asks the kernel whether a specific modalias fits the machine to avoid duplicated code, something like: modprobe --alias "x86cpu:vendor:0002:family:*:model:*:feature:*" returning true or false, depending on whether the machine matches or not. Not sure what exactly needs to be touched to implement this.
-- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=847158
https://bugzilla.novell.com/show_bug.cgi?id=847158#c23
Michael Schröder
https://bugzilla.novell.com/show_bug.cgi?id=847158
https://bugzilla.novell.com/show_bug.cgi?id=847158#c24
Thomas Renninger
https://bugzilla.novell.com/show_bug.cgi?id=847158
https://bugzilla.novell.com/show_bug.cgi?id=847158#c25
Michael Schröder
I wonder how this can be fixed in openSUSE:13.1 automatically (install ucode-intel package even it has not been at distro install time)?
https://bugzilla.novell.com/show_bug.cgi?id=847158
https://bugzilla.novell.com/show_bug.cgi?id=847158#c26
--- Comment #26 from Dirk Weber
As 13.1 is out the fix will not show up in GM, but only as maintenance update and I doubt zypper will re-evaluate when doing zypper dup or zypper update, that the package now has to be installed additionally? Maybe for 13.1 just a hint could be added to the release note that users should or have to install ucode-intel/ucode-amd packages (and possibly uninstall microcode_ctl if they upgraded).
Apart from this - at the moment there is also no trigger to actually load the ucode patches into the CPU when the system is up. Something would need to do: echo 1 > /sys/devices/system/cpu/microcode/reload -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=847158
https://bugzilla.novell.com/show_bug.cgi?id=847158#c27
--- Comment #27 from Bernhard Wiedemann
https://bugzilla.novell.com/show_bug.cgi?id=847158
https://bugzilla.novell.com/show_bug.cgi?id=847158#c28
--- Comment #28 from Bernhard Wiedemann
https://bugzilla.novell.com/show_bug.cgi?id=847158
https://bugzilla.novell.com/show_bug.cgi?id=847158#c29
Michael Andres
I wonder how this can be fixed in openSUSE:13.1 automatically (install ucode-intel package even it has not been at distro install time)? Is this possible at all? As 13.1 is out the fix will not show up in GM, but only as maintenance update and I doubt zypper will re-evaluate when doing zypper dup or zypper update, that the package now has to be installed additionally?
'zypper inr' will -amongst others- re-evaluate the modalias deps. Also 'zypper dup'. 'zypper up' won't. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=847158
https://bugzilla.novell.com/show_bug.cgi?id=847158#c30
Thomas Renninger
https://bugzilla.novell.com/show_bug.cgi?id=847158
https://bugzilla.novell.com/show_bug.cgi?id=847158#c31
--- Comment #31 from Borislav Petkov
For AMD I gave it a try and run into strang issues (but on a 13.1 Milestone 4 system): - AMD microcode got added to initrd correctly, but reboot did not result in an update.
That's a different bug: bnc#852007 and you're on CC there too. I've uploaded a fix today for the upstream kernel and it would be great if you could test it and let me know if it works on your box.
Triggering microcode reload manually: echo 1 >/sys/devices/system/cpu/microcode/reload resulted in updating only some of the 16 cores: microcode: CPU0: new patch_level=0x0600063d microcode: CPU1: new patch_level=0x0600063d microcode: CPU4: new patch_level=0x0600063d microcode: CPU5: new patch_level=0x0600063d microcode: CPU8: new patch_level=0x0600063d microcode: CPU9: new patch_level=0x0600063d microcode: CPU12: new patch_level=0x0600063d microcode: CPU13: new patch_level=0x0600063d Strange, I guess/hope this is a leftover of old 3.11.0-rc7-1.g99e1318-default kernel.
No, this is because Bulldozer has compute units which have 2 cores but need to update the microcode on only one core of the compute unit to have the updated microcode on both cores. You can verify this by doing $ grep microcode /proc/cpuinfo It should give you the same microcode version on each core. Thanks. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=847158
https://bugzilla.novell.com/show_bug.cgi?id=847158#c32
--- Comment #32 from Michele Cherici
I have put fixed ucode-intel and ucode-amd packages here: ftp.suse.com/pub/people/trenn/13.1_microcode_updates Installing should trigger mkinitrd. When initrd is created there is an additional line now: Microcode: ... telling the user whether a suitable microcode update has been found and added to initrd. If one is found, rebooting must result in a microcode update (check dmesg or /var/log/messages).
I've tested your package and microcode is updated after install but is not
updated after reboot.
/var/log/messages after package install:
2013-12-03T09:37:18.869222+01:00 bestia kernel: [ 4084.183167] microcode: CPU0
sig=0x306a9, pf=0x2, revision=0x15
2013-12-03T09:37:18.869232+01:00 bestia kernel: [ 4084.183628] microcode: CPU0
updated to revision 0x19, date = 2013-06-13
2013-12-03T09:37:18.869234+01:00 bestia kernel: [ 4084.183641] microcode: CPU1
sig=0x306a9, pf=0x2, revision=0x15
2013-12-03T09:37:18.869234+01:00 bestia kernel: [ 4084.183872] microcode: CPU1
updated to revision 0x19, date = 2013-06-13
2013-12-03T09:37:18.869237+01:00 bestia kernel: [ 4084.183891] microcode: CPU2
sig=0x306a9, pf=0x2, revision=0x15
2013-12-03T09:37:18.869750+01:00 bestia kernel: [ 4084.184134] microcode: CPU2
updated to revision 0x19, date = 2013-06-13
2013-12-03T09:37:18.869762+01:00 bestia kernel: [ 4084.184165] microcode: CPU3
sig=0x306a9, pf=0x2, revision=0x15
2013-12-03T09:37:18.869763+01:00 bestia kernel: [ 4084.184411] microcode: CPU3
updated to revision 0x19, date = 2013-06-13
/var/log/messages after reboot:
2013-12-03T09:38:08.315985+01:00 bestia kernel: [ 0.296788] microcode: CPU0
sig=0x306a9, pf=0x2, revision=0x15
2013-12-03T09:38:08.315985+01:00 bestia kernel: [ 0.296793] microcode: CPU1
sig=0x306a9, pf=0x2, revision=0x15
2013-12-03T09:38:08.315986+01:00 bestia kernel: [ 0.296798] microcode: CPU2
sig=0x306a9, pf=0x2, revision=0x15
2013-12-03T09:38:08.315986+01:00 bestia kernel: [ 0.296800] microcode: CPU3
sig=0x306a9, pf=0x2, revision=0x15
2013-12-03T09:38:08.315986+01:00 bestia kernel: [ 0.296822] microcode:
Microcode Update Driver: v2.00
https://bugzilla.novell.com/show_bug.cgi?id=847158
https://bugzilla.novell.com/show_bug.cgi?id=847158#c33
Jon Nelson
https://bugzilla.novell.com/show_bug.cgi?id=847158
https://bugzilla.novell.com/show_bug.cgi?id=847158#c34
--- Comment #34 from Dirk Weber
... I have put fixed ucode-intel and ucode-amd packages here: ftp.suse.com/pub/people/trenn/13.1_microcode_updates Installing should trigger mkinitrd. When initrd is created there is an additional line now: Microcode: ... telling the user whether a suitable microcode update has been found and added to initrd. If one is found, rebooting must result in a microcode update (check dmesg or /var/log/messages).
For AMD I gave it a try and run into strang issues (but on a 13.1 Milestone 4 system): - AMD microcode got added to initrd correctly, but reboot did not result in an update. Triggering microcode reload manually: echo 1 >/sys/devices/system/cpu/microcode/reload resulted in updating only some of the 16 cores:
Would be great if others can give the packages a try.
I have tested your ucode-amd package. mkinitrd is run after installation and gives this output: .. Microcode: Adding AMD microcode microcode_amd.bin Microcode: Adding AMD microcode microcode_amd.bin .. it seems that the body of the script lib/mkinitrd/scripts/setup-amd_microcode.sh is duplicated? # lsinitrd initrd-3.11.6-4-desktop | grep ucode lib/firmware/amd-ucode lib/firmware/amd-ucode/microcode_amd.bin.asc lib/firmware/amd-ucode/microcode_amd.bin shows that the microcode is included in the initrd, but I think the path/filename is not correct and therefore it is not found at boot time. According to https://www.kernel.org/doc/Documentation/x86/early-microcode.txt the name should be kernel/x86/microcode/AuthenticAMD.bin and this is also the path which appears in /usr/src/linux/arch/x86/kernel/microcode_amd_early.c Besides it seems that the ucode file should be in a separate cpio prepended to the standard initrd, see comment #11 which shows an example of successful early update with AMD CPU. But please also mind comment #18 and related bnc#852007 where successful creation of an initrd including the ucode update almost resulted in an unbootable system - luckily I had a backup initrd. BTW: is there a kernel parameter which inhibits early microcode update which can be used to boot the system in case the early update makes the system unbootable and all available initrds contain the microcode? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=847158
https://bugzilla.novell.com/show_bug.cgi?id=847158#c35
--- Comment #35 from Borislav Petkov
According to https://www.kernel.org/doc/Documentation/x86/early-microcode.txt the name should be kernel/x86/microcode/AuthenticAMD.bin and this is also the path which appears in /usr/src/linux/arch/x86/kernel/microcode_amd_early.c
That is correct.
Besides it seems that the ucode file should be in a separate cpio prepended to the standard initrd, see comment #11 which shows an example of successful early update with AMD CPU.
But please also mind comment #18 and related bnc#852007 where successful creation of an initrd including the ucode update almost resulted in an unbootable system - luckily I had a backup initrd.
Right, I'm still working on those - it looks like 32-bit was completely b0rked from the beginning and it was rushed in without any serious testing.
BTW: is there a kernel parameter which inhibits early microcode update which can be used to boot the system in case the early update makes the system unbootable and all available initrds contain the microcode?
Unfortunately, no. The thing is, if the loading would have worked from the beginning, we wouldnt've needed a kernel parameter in the first place. :) What you can do for now is drop the ucode from the initrd so that it cannot be found and loading fails. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=847158
https://bugzilla.novell.com/show_bug.cgi?id=847158#c36
--- Comment #36 from Dirk Weber
(In reply to comment #34) ... Right, I'm still working on those - it looks like 32-bit was completely b0rked from the beginning and it was rushed in without any serious testing. It is probably difficult to test the possible combinations. E.g. if the HW vendor includes the microcode update already in the BIOS/UEFI then this machine can not be used for these tests anymore.
BTW: is there a kernel parameter which inhibits early microcode update which can be used to boot the system in case the early update makes the system unbootable and all available initrds contain the microcode?
Unfortunately, no. The thing is, if the loading would have worked from the beginning, we wouldnt've needed a kernel parameter in the first place. :)
What you can do for now is drop the ucode from the initrd so that it cannot be found and loading fails. yes, currently with openSUSE 13.1 and the official mkinitrd it is easy to have the ucode *NOT* in the initrd. :-) But if mkinitrd gets this functionality and automatically all initrds of the system are updated this could be a problem.
Regarding comment #33: I am now just using /etc/init.d/after.local to check if the ucode was not yet updated and then trigger the update. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=847158
https://bugzilla.novell.com/show_bug.cgi?id=847158#c37
--- Comment #37 from Bernhard Wiedemann
https://bugzilla.novell.com/show_bug.cgi?id=847158
https://bugzilla.novell.com/show_bug.cgi?id=847158#c38
Thomas Renninger
https://bugzilla.novell.com/show_bug.cgi?id=847158
https://bugzilla.novell.com/show_bug.cgi?id=847158#c39
--- Comment #39 from Bernhard Wiedemann
https://bugzilla.novell.com/show_bug.cgi?id=847158
https://bugzilla.novell.com/show_bug.cgi?id=847158#c40
--- Comment #40 from Michele Cherici
https://bugzilla.novell.com/show_bug.cgi?id=847158
https://bugzilla.novell.com/show_bug.cgi?id=847158#c41
--- Comment #41 from Bernhard Wiedemann
https://bugzilla.novell.com/show_bug.cgi?id=847158
https://bugzilla.novell.com/show_bug.cgi?id=847158#c42
Thomas Renninger
https://bugzilla.novell.com/show_bug.cgi?id=847158
https://bugzilla.novell.com/show_bug.cgi?id=847158#c
Thomas Renninger
https://bugzilla.novell.com/show_bug.cgi?id=847158
https://bugzilla.novell.com/show_bug.cgi?id=847158#c43
Michele Cherici
https://bugzilla.novell.com/show_bug.cgi?id=847158
https://bugzilla.novell.com/show_bug.cgi?id=847158#c44
--- Comment #44 from Borislav Petkov
- ucode-amd will get installed automatically (Supplements, modalias fix), but firmware will not be added to mkinitrd automatically. The solution Dirk suggested, adding: if [ -w /sys/devices/system/cpu/microcode/reload ];then echo 1 >/sys/devices/system/cpu/microcode/reload fi to /etc/init.d/after.local People would have to add this manually.
Ok, this is not really good. Why can't the installation procedure edit files in /etc/init.d/? People won't do this manually, believe me. If we're not going to load the ucode early we at least need to automate the application later. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=847158
https://bugzilla.novell.com/show_bug.cgi?id=847158#c45
Thomas Renninger
Ok, this is not really good. Keep calm and use the force...
Seriously: AMD and Intel should work exactly the same way. Now as I understand that udev must go first, I can and will do the same for ucode-amd. All which is then needed from users is a: zypper dup or zypper inr (install-new-recommends) to get ucode-intel or ucode-amd installed. Then mkinitrd will be built automatically at package installation time and the microcode will be loaded at next reboot (in fact a reload is already triggered at installation time as well before rebooting). I will now also commit the ucode-amd needed changes to Base:System/kernel-firmware and will trigger submit requests against openSUSE:Factory and openSUSE:13.1 Stay tuned... -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=847158
https://bugzilla.novell.com/show_bug.cgi?id=847158#c46
--- Comment #46 from Borislav Petkov
Ok, this is not really good. Keep calm and use the force...
I do, my young padawan - don't you notice it? :-)
to get ucode-intel or ucode-amd installed. Then mkinitrd will be built automatically at package installation time and the microcode will be loaded at next reboot
Question is, will the amd ucode get loaded during every boot? We said we don't want to do early loading but will a script do echo 1 > .../reload during every boot? And will this script get added automagically, using the force?
(in fact a reload is already triggered at installation time as well before rebooting).
One reload is enough. Thanks. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=847158
https://bugzilla.novell.com/show_bug.cgi?id=847158#c47
--- Comment #47 from Bernhard Wiedemann
https://bugzilla.novell.com/show_bug.cgi?id=847158
https://bugzilla.novell.com/show_bug.cgi?id=847158#c48
--- Comment #48 from Bernhard Wiedemann
https://bugzilla.novell.com/show_bug.cgi?id=847158
https://bugzilla.novell.com/show_bug.cgi?id=847158#c49
--- Comment #49 from Bernhard Wiedemann
https://bugzilla.novell.com/show_bug.cgi?id=847158
https://bugzilla.novell.com/show_bug.cgi?id=847158#c50
--- Comment #50 from Bernhard Wiedemann
https://bugzilla.novell.com/show_bug.cgi?id=847158
https://bugzilla.novell.com/show_bug.cgi?id=847158#c51
Marcus Meissner
https://bugzilla.novell.com/show_bug.cgi?id=847158
https://bugzilla.novell.com/show_bug.cgi?id=847158#c52
--- Comment #52 from Swamp Workflow Management
https://bugzilla.novell.com/show_bug.cgi?id=847158
https://bugzilla.novell.com/show_bug.cgi?id=847158#c53
--- Comment #53 from Swamp Workflow Management
https://bugzilla.novell.com/show_bug.cgi?id=847158
https://bugzilla.novell.com/show_bug.cgi?id=847158#c
Ihno Krumreich
https://bugzilla.novell.com/show_bug.cgi?id=847158
https://bugzilla.novell.com/show_bug.cgi?id=847158#c54
Thomas Renninger
participants (1)
-
bugzilla_noreply@novell.com