Re: [arch-general] [arch-dev-public] Changes to microcode updates

older
[arch-general] Problems updating...

Genes Lists

18 Oct 2014 18 Oct '14

9:06 p.m.

For info - I have tried to get it working in refind and failed. I added a second initrd line in the boot stanza in refind.conf. But the firmware was not updated. I added to refind sourceforge report[1], perhaps Rod will respond. [1] https://sourceforge.net/p/refind/discussion/general/thread/7da6cd81/ gene

Show replies by date

Mike Cloaked

19 Oct 19 Oct

5:54 p.m.

New subject: [arch-general] [arch-dev-public] Changes to microcode updates

On Sat, Oct 18, 2014 at 10:06 PM, Genes Lists wrote:

...

For info - I have tried to get it working in refind and failed. I added a second initrd line in the boot stanza in refind.conf. But the firmware was not updated.

I added to refind sourceforge report[1], perhaps Rod will respond.

[1] https://sourceforge.net/p/refind/discussion/general/thread/7da6cd81/

It would seem that there might be some problems with this microcode update apart from the issues with bootloaders. See 1) https://lkml.org/lkml/2014/9/18/218 2) https://bugs.launchpad.net/intel/+bug/1370352 -- mike c

Thomas Bächler

20 Oct 20 Oct

4:44 p.m.

New subject: [arch-general] [arch-dev-public] Changes to microcode updates

Am 19.10.2014 um 19:54 schrieb Mike Cloaked:

...

On Sat, Oct 18, 2014 at 10:06 PM, Genes Lists wrote:

...
For info - I have tried to get it working in refind and failed. I added a second initrd line in the boot stanza in refind.conf. But the firmware was not updated.

I added to refind sourceforge report[1], perhaps Rod will respond.

[1] https://sourceforge.net/p/refind/discussion/general/thread/7da6cd81/

It would seem that there might be some problems with this microcode update apart from the issues with bootloaders. See

1) https://lkml.org/lkml/2014/9/18/218

2) https://bugs.launchpad.net/intel/+bug/1370352

These changes have been done precisely to avoid these problems, the first link and its responses summarize the situation pretty well.

Mike Cloaked

21 Oct 21 Oct

9:36 a.m.

New subject: [arch-general] [arch-dev-public] Changes to microcode updates

On Mon, Oct 20, 2014 at 5:44 PM, Thomas Bächler wrote:

...

These changes have been done precisely to avoid these problems, the first link and its responses summarize the situation pretty well.

The file at https://www.kernel.org/doc/Documentation/x86/early-microcode.txt gives a method that should allow creating a combined initrd img file that anyone booting with refind EFI may be able to test. There are suggested methods to implement early microcode loading for the other main bootloaders in the arch wiki, but until now for refind it seems not to have been verified to work. It would be nice to see verification that early microcode loading has been successful using all the main bootloaders/bootmanagers, as well as direct efistub boot. -- mike c

Thomas Bächler

23 Oct 23 Oct

3:55 p.m.

New subject: [arch-general] [arch-dev-public] Changes to microcode updates

Am 21.10.2014 um 11:36 schrieb Mike Cloaked:

...

On Mon, Oct 20, 2014 at 5:44 PM, Thomas Bächler wrote:

...
These changes have been done precisely to avoid these problems, the first link and its responses summarize the situation pretty well.

The file at https://www.kernel.org/doc/Documentation/x86/early-microcode.txt gives a method that should allow creating a combined initrd img file that anyone booting with refind EFI may be able to test. There are suggested methods to implement early microcode loading for the other main bootloaders in the arch wiki, but until now for refind it seems not to have been verified to work. It would be nice to see verification that early microcode loading has been successful using all the main bootloaders/bootmanagers, as well as direct efistub boot.

A 2 minute Google search indicates that refind merely appends the initrd as a kernel command line option (initrd=) - refind, like gummiboot, is merely an EFI bootmanager and not a bootloader and thus relies on the kernel's EFIstub feature. Therefore, refind does not load the initrd itself, but delegates that task to the kernel.

Mike Cloaked

7:58 p.m.

New subject: [arch-general] [arch-dev-public] Changes to microcode updates

On Thu, Oct 23, 2014 at 4:55 PM, Thomas Bächler wrote:

...

A 2 minute Google search indicates that refind merely appends the initrd as a kernel command line option (initrd=) - refind, like gummiboot, is merely an EFI bootmanager and not a bootloader and thus relies on the kernel's EFIstub feature. Therefore, refind does not load the initrd itself, but delegates that task to the kernel.

I am confused about this now. In my previous post I quoted that using refind boots with the dual initrd files in the refind_linux.conf file, and leads to lines in the journal log like: Oct 23 15:41:56 localhost kernel: CPU0 microcode updated early to revision 0x1b, date = 2014-05-29 Does this mean that the quoted early update has used the wrong file from an earlier date than current, or does this journal log line confirm correct early loading of the up-to-date microcode? Or does delegating the task to the kernel when efistub loading produce a correctly working processor with the intended new microcode at the early stage of booting the kernel? Thanks -- mike c

Thomas Bächler

8:42 p.m.

New subject: [arch-general] [arch-dev-public] Changes to microcode updates

Am 23.10.2014 um 21:58 schrieb Mike Cloaked:

...

Oct 23 15:41:56 localhost kernel: CPU0 microcode updated early to revision 0x1b, date = 2014-05-29

Does this mean that the quoted early update has used the wrong file from an earlier date than current, or does this journal log line confirm correct early loading of the up-to-date microcode?

This is the timestamp that marks Intel's internal version. This is what I get: [ 0.000000] lije kernel: CPU0 microcode updated early to revision 0x1c, date = 2014-07-03

Mike Cloaked

8:59 p.m.

New subject: [arch-general] [arch-dev-public] Changes to microcode updates

On Thu, Oct 23, 2014 at 9:42 PM, Thomas Bächler wrote:

...

Am 23.10.2014 um 21:58 schrieb Mike Cloaked:

...
Oct 23 15:41:56 localhost kernel: CPU0 microcode updated early to revision 0x1b, date = 2014-05-29

Does this mean that the quoted early update has used the wrong file from an earlier date than current, or does this journal log line confirm correct early loading of the up-to-date microcode?

This is the timestamp that marks Intel's internal version. This is what I get:

[ 0.000000] lije kernel: CPU0 microcode updated early to revision 0x1c, date = 2014-07-03

On a second machine (a Haswell laptop) I get: Oct 23 15:16:38 localhost kernel: CPU0 microcode updated early to revision 0x1c, date = 2014-07-03 which might suggest that mine has the same CPU as yours, so that this is indeed the latest internal version date for the microcode - (which makes me feel a little easier seeing you get the same as me!) -- mike c

Jody Allen

10:34 p.m.

New subject: [arch-general] [arch-dev-public] Changes to microcode updates

On Thu, Oct 23, 2014 at 4:59 PM, Mike Cloaked wrote:

...

On Thu, Oct 23, 2014 at 9:42 PM, Thomas Bächler wrote:

...
Am 23.10.2014 um 21:58 schrieb Mike Cloaked:

...
Oct 23 15:41:56 localhost kernel: CPU0 microcode updated early to revision 0x1b, date = 2014-05-29

Does this mean that the quoted early update has used the wrong file from an earlier date than current, or does this journal log line confirm correct early loading of the up-to-date microcode?

This is the timestamp that marks Intel's internal version. This is what I get:

[ 0.000000] lije kernel: CPU0 microcode updated early to revision 0x1c, date = 2014-07-03

On a second machine (a Haswell laptop) I get:

Oct 23 15:16:38 localhost kernel: CPU0 microcode updated early to revision 0x1c, date = 2014-07-03

which might suggest that mine has the same CPU as yours, so that this is indeed the latest internal version date for the microcode - (which makes me feel a little easier seeing you get the same as me!)

Is anyone only having one core updated? I get this:

...

dmesg | grep microcode [ 0.000000] CPU0 microcode updated early to revision 0x29, date = 2013-06-12 [ 0.344194] microcode: CPU0 sig=0x206a7, pf=0x10, revision=0x29 [ 0.344203] microcode: CPU1 sig=0x206a7, pf=0x10, revision=0x28 [ 0.344260] microcode: Microcode Update Driver: v2.00 , Peter Oruba

I checked dmesg and I can find no error messages. -- Jody

Genes Lists

10:45 p.m.

New subject: [arch-general] [arch-dev-public] Changes to microcode updates

On 10/23/2014 06:34 PM, Jody Allen wrote: ...

...

Is anyone only having one core updated? I get this:

...
dmesg | grep microcode [ 0.000000] CPU0 microcode updated early to revision 0x29, date = 2013-06-12 [ 0.344194] microcode: CPU0 sig=0x206a7, pf=0x10, revision=0x29 [ 0.344203] microcode: CPU1 sig=0x206a7, pf=0x10, revision=0x28 [ 0.344260] microcode: Microcode Update Driver: v2.00 , Peter Oruba

I checked dmesg and I can find no error messages.

I am only getting even cores updated (which may be same as you are seeing). dmesg | egrep microcode [ 0.000000] CPU0 microcode updated early to revision 0x1c, date = 2014-07-03 [ 0.305434] CPU2 microcode updated early to revision 0x1c, date = 2014-07-03 [ 0.345462] CPU4 microcode updated early to revision 0x1c, date = 2014-07-03 [ 0.385501] CPU6 microcode updated early to revision 0x1c, date = 2014-07-03 [ 0.961766] microcode: CPU0 sig=0x306c3, pf=0x10, revision=0x1c [ 0.961785] microcode: CPU1 sig=0x306c3, pf=0x10, revision=0x1c [ 0.961805] microcode: CPU2 sig=0x306c3, pf=0x10, revision=0x1c [ 0.961825] microcode: CPU3 sig=0x306c3, pf=0x10, revision=0x1c [ 0.961836] microcode: CPU4 sig=0x306c3, pf=0x10, revision=0x1c [ 0.961857] microcode: CPU5 sig=0x306c3, pf=0x10, revision=0x1c [ 0.961876] microcode: CPU6 sig=0x306c3, pf=0x10, revision=0x1c [ 0.961897] microcode: CPU7 sig=0x306c3, pf=0x10, revision=0x1c [ 0.962003] microcode: Microcode Update Driver: v2.00 , Peter Oruba

Neitsab

10:53 p.m.

New subject: [arch-general] [arch-dev-public] Changes to microcode updates

On 2014-10-23 00:45 (UTC+2) Genes Lists wrote: On 10/23/2014 06:34 PM, Jody Allen wrote: ...

...

Is anyone only having one core updated? I get this:

...
dmesg | grep microcode [ 0.000000] CPU0 microcode updated early to revision 0x29, date = 2013-06-12 [ 0.344194] microcode: CPU0 sig=0x206a7, pf=0x10, revision=0x29 [ 0.344203] microcode: CPU1 sig=0x206a7, pf=0x10, revision=0x28 [ 0.344260] microcode: Microcode Update Driver: v2.00 , Peter Oruba

I checked dmesg and I can find no error messages.

Jody Allen

10:57 p.m.

New subject: [arch-general] [arch-dev-public] Changes to microcode updates

On Thu, Oct 23, 2014 at 6:53 PM, Neitsab wrote:

...

My guess is it's because of hyperthreading: my CPU has 2 physical cores but kernel detects 4 CPUs; however only "real"/physical cores get the microcode update, so two (0 and 2) out of the four detected.

Thanks for the info. I had a feeling it would be something like this. -- Jody

Marko Hauptvogel

11:12 p.m.

New subject: [arch-general] [arch-dev-public] Changes to microcode updates

To remove any doubts, just take a look at /proc/cpuinfo. With 4 cores and 8 threads, I have 8 entries in there. The "processor" is ranging from 0 to 7 (aka threads) while "core id" (aka cores) from 0 to 3. If you grep it, it will (kinda) give you the thread-core mapping. % grep "processor\|core id" /proc/cpuinfo processor : 0 core id : 0 processor : 1 core id : 1 processor : 2 core id : 2 processor : 3 core id : 3 processor : 4 core id : 0 processor : 5 core id : 1 processor : 6 core id : 2 processor : 7 core id : 3 which perfectly matches with the microcode update output, if you keep in mind that every core is only updated once (probably they just iterate through them and update on first hit, which leads to some getting only every 2nd updated). % dmesg | grep microcode [ 0.000000] CPU0 microcode updated early to revision 0x1b, date = 2014-05-29 [ 0.087677] CPU1 microcode updated early to revision 0x1b, date = 2014-05-29 [ 0.107693] CPU2 microcode updated early to revision 0x1b, date = 2014-05-29 [ 0.127811] CPU3 microcode updated early to revision 0x1b, date = 2014-05-29 [ 0.405981] microcode: CPU0 sig=0x306a9, pf=0x2, revision=0x1b [ 0.405986] microcode: CPU1 sig=0x306a9, pf=0x2, revision=0x1b [ 0.405991] microcode: CPU2 sig=0x306a9, pf=0x2, revision=0x1b [ 0.405997] microcode: CPU3 sig=0x306a9, pf=0x2, revision=0x1b [ 0.406002] microcode: CPU4 sig=0x306a9, pf=0x2, revision=0x1b [ 0.406007] microcode: CPU5 sig=0x306a9, pf=0x2, revision=0x1b [ 0.406012] microcode: CPU6 sig=0x306a9, pf=0x2, revision=0x1b [ 0.406016] microcode: CPU7 sig=0x306a9, pf=0x2, revision=0x1b [ 0.406052] microcode: Microcode Update Driver: v2.00 , Peter Oruba Which CPU ids are updated shouldn't matter in any way, as long as the number of updates matches the number of real CPU cores and the system recognizes all threads. On 24.10.2014 00:57, Jody Allen wrote:

...

On Thu, Oct 23, 2014 at 6:53 PM, Neitsab wrote:

...
My guess is it's because of hyperthreading: my CPU has 2 physical cores but kernel detects 4 CPUs; however only "real"/physical cores get the microcode update, so two (0 and 2) out of the four detected.

Thanks for the info. I had a feeling it would be something like this.

Leonidas Spyropoulos

24 Oct 24 Oct

8:06 a.m.

New subject: [arch-general] [arch-dev-public] Changes to microcode updates

Just to clarify: No action required for AMD cpu. AMD FX-8120 Correct? -- Sent from my Android device with K-9 Mail. Please excuse my brevity.

Neven Sajko

10:31 a.m.

New subject: [arch-general] [arch-dev-public] Changes to microcode updates

I got the same output as Jody dmesg | grep microcod [ 0.000000] CPU0 microcode updated early to revision 0xa4, date = 2010-10-02 [ 0.497666] microcode: CPU0 sig=0x6fd, pf=0x80, revision=0xa4 [ 0.497679] microcode: CPU1 sig=0x6fd, pf=0x80, revision=0xa3 [ 0.497799] microcode: Microcode Update Driver: v2.00 , Peter Oruba ,and I have two cores. Albeit mine are quite old.

Neitsab

22 Oct 22 Oct

11:33 p.m.

New subject: [arch-general] [arch-dev-public] Changes to microcode updates

Le 21/10/2014, Mike Cloaked a écrit:

...

There are suggested methods to implement early microcode loading for the other main bootloaders in the arch wiki, but until now for refind it seems not to have been verified to work. It would be nice to see verification that early microcode loading has been successful using all the main bootloaders/bootmanagers, as well as direct efistub boot.

I just tested with GRUB and it doesn't seem to work. I added /intel-ucode.img in first position in every /boot/grub/grub.cfg's initrd lines (standard and ck-kernels + fallback entries), upgraded my system (update contained new intel-ucode and linux) and rebooted on linux-ck (which is still at 3.16.6-2-ck if that matters). Rebooted fined, but : # journactl -b | grep microcode oct. 23 00:49:50 arch-clevo kernel: microcode: CPU0 sig=0x306a9, pf=0x10, revision=0x19 oct. 23 00:49:50 arch-clevo kernel: microcode: CPU1 sig=0x306a9, pf=0x10, revision=0x19 oct. 23 00:49:50 arch-clevo kernel: microcode: CPU2 sig=0x306a9, pf=0x10, revision=0x19 oct. 23 00:49:50 arch-clevo kernel: microcode: CPU3 sig=0x306a9, pf=0x10, revision=0x19 # journalctl | grep microcode | tail -100 ## -b -1 is broken, displays stuff from the beginning of my log... oct. 22 23:43:39 arch-clevo kernel: microcode: CPU0 sig=0x306a9, pf=0x10, revision=0x1b oct. 22 23:43:39 arch-clevo kernel: microcode: CPU1 sig=0x306a9, pf=0x10, revision=0x19 oct. 22 23:43:39 arch-clevo kernel: microcode: CPU1 updated to revision 0x1b, date = 2014-05-29 oct. 22 23:43:39 arch-clevo kernel: microcode: CPU2 sig=0x306a9, pf=0x10, revision=0x19 oct. 22 23:43:39 arch-clevo kernel: microcode: CPU2 updated to revision 0x1b, date = 2014-05-29 oct. 22 23:43:39 arch-clevo kernel: microcode: CPU3 sig=0x306a9, pf=0x10, revision=0x1b Just to give more info: # cat /boot/grub/grub.cfg | grep initrd initrd /intel-ucode.img /initramfs-linux-ck.img initrd /intel-ucode.img /initramfs-linux-ck.img initrd /intel-ucode.img /initramfs-linux-ck-fallback.img initrd /intel-ucode.img /initramfs-linux.img initrd /intel-ucode.img /initramfs-linux-fallback.img $ ls -l /boot total 61597 drwxr-xr-x 6 root root 1024 23 oct. 00:42 grub -rw-r--r-- 1 root root 20387566 20 oct. 23:36 initramfs-linux-ck-fallback.img -rw-r--r-- 1 root root 6574230 20 oct. 23:36 initramfs-linux-ck.img -rw-r--r-- 1 root root 20704983 23 oct. 00:47 initramfs-linux-fallback.img -rw-r--r-- 1 root root 6831046 23 oct. 00:47 initramfs-linux.img -rw-r--r-- 1 root root 648704 12 oct. 14:05 intel-ucode.img drwx------ 2 root root 12288 4 déc. 2013 lost+found -rw-r--r-- 1 root root 4026016 15 oct. 15:05 vmlinuz-linux -rw-r--r-- 1 root root 3887072 20 oct. 02:48 vmlinuz-linux-ck $ uname -a Linux arch-clevo 3.16.6-2-ck #1 SMP PREEMPT Sun Oct 19 20:46:56 EDT 2014 x86_64 GNU/Linux Downgrading to previous intel-ucode not to remain with no microcode update...

Marko Hauptvogel

23 Oct 23 Oct

12:01 a.m.

New subject: [arch-general] [arch-dev-public] Changes to microcode updates

Referring to the comments from october 16th on the ck kernel package page [0] and the config of said package [1], your version of the ck kernel has not yet been configured to do early microcode updates. But this should follow be fixed soon as the v20140913 microcode package hit [extra] today. Try to boot the stock kernel and you should see 'updated early' lines in your logs. Greetings [0] https://aur.archlinux.org/packages/linux-ck/ [1] http://pkgbuild.com/git/aur-mirror.git/tree/linux-ck/config?id=438644e59ea36... On 23.10.2014 01:33, Neitsab wrote:

...

Le 21/10/2014, Mike Cloaked a écrit:

...
There are suggested methods to implement early microcode loading for the other main bootloaders in the arch wiki, but until now for refind it seems not to have been verified to work. It would be nice to see verification that early microcode loading has been successful using all the main bootloaders/bootmanagers, as well as direct efistub boot.

I just tested with GRUB and it doesn't seem to work.

I added /intel-ucode.img in first position in every /boot/grub/grub.cfg's initrd lines (standard and ck-kernels + fallback entries), upgraded my system (update contained new intel-ucode and linux) and rebooted on linux-ck (which is still at 3.16.6-2-ck if that matters).

Rebooted fined, but :

# journactl -b | grep microcode oct. 23 00:49:50 arch-clevo kernel: microcode: CPU0 sig=0x306a9, pf=0x10, revision=0x19 oct. 23 00:49:50 arch-clevo kernel: microcode: CPU1 sig=0x306a9, pf=0x10, revision=0x19 oct. 23 00:49:50 arch-clevo kernel: microcode: CPU2 sig=0x306a9, pf=0x10, revision=0x19 oct. 23 00:49:50 arch-clevo kernel: microcode: CPU3 sig=0x306a9, pf=0x10, revision=0x19

# journalctl | grep microcode | tail -100 ## -b -1 is broken, displays stuff from the beginning of my log... oct. 22 23:43:39 arch-clevo kernel: microcode: CPU0 sig=0x306a9, pf=0x10, revision=0x1b oct. 22 23:43:39 arch-clevo kernel: microcode: CPU1 sig=0x306a9, pf=0x10, revision=0x19 oct. 22 23:43:39 arch-clevo kernel: microcode: CPU1 updated to revision 0x1b, date = 2014-05-29 oct. 22 23:43:39 arch-clevo kernel: microcode: CPU2 sig=0x306a9, pf=0x10, revision=0x19 oct. 22 23:43:39 arch-clevo kernel: microcode: CPU2 updated to revision 0x1b, date = 2014-05-29 oct. 22 23:43:39 arch-clevo kernel: microcode: CPU3 sig=0x306a9, pf=0x10, revision=0x1b

Just to give more info:

# cat /boot/grub/grub.cfg | grep initrd initrd /intel-ucode.img /initramfs-linux-ck.img initrd /intel-ucode.img /initramfs-linux-ck.img initrd /intel-ucode.img /initramfs-linux-ck-fallback.img initrd /intel-ucode.img /initramfs-linux.img initrd /intel-ucode.img /initramfs-linux-fallback.img

$ ls -l /boot total 61597 drwxr-xr-x 6 root root 1024 23 oct. 00:42 grub -rw-r--r-- 1 root root 20387566 20 oct. 23:36 initramfs-linux-ck-fallback.img -rw-r--r-- 1 root root 6574230 20 oct. 23:36 initramfs-linux-ck.img -rw-r--r-- 1 root root 20704983 23 oct. 00:47 initramfs-linux-fallback.img -rw-r--r-- 1 root root 6831046 23 oct. 00:47 initramfs-linux.img -rw-r--r-- 1 root root 648704 12 oct. 14:05 intel-ucode.img drwx------ 2 root root 12288 4 déc. 2013 lost+found -rw-r--r-- 1 root root 4026016 15 oct. 15:05 vmlinuz-linux -rw-r--r-- 1 root root 3887072 20 oct. 02:48 vmlinuz-linux-ck

$ uname -a Linux arch-clevo 3.16.6-2-ck #1 SMP PREEMPT Sun Oct 19 20:46:56 EDT 2014 x86_64 GNU/Linux

Downgrading to previous intel-ucode not to remain with no microcode update...

Mike Cloaked

2:57 p.m.

New subject: [arch-general] [arch-dev-public] Changes to microcode updates

On Thu, Oct 23, 2014 at 1:01 AM, Marko Hauptvogel < marko.hauptvogel@googlemail.com> wrote:

...

Referring to the comments from october 16th on the ck kernel package page [0] and the config of said package [1], your version of the ck kernel has not yet been configured to do early microcode updates. But

I have just updated my arch linux system to the new kernel and new microcode packages (linux 3.17.1-1 intel-ucode 20140913-1). This system boots with rEFInd. The /boot/refind_linux.conf file was edited to include the microcode image file as an initrd= entry with lines as: cat /boot/refind_linux.conf "Boot to X" "root=PARTUUID=b0c9c220-0f8d-49c1-b306-873d2519ce47 rw rootfstype=ext4 add_efi_memmapinitrd=/boot/intel-ucode.img initrd=/boot/initramfs-linux.img systemd.unit=graphical.target" "Boot to console" "root=PARTUUID=b0c9c220-0f8d-49c1-b306-873d2519ce47 rw rootfstype=ext4 add_efi_memmap initrd=/boot/intel-ucode.img initrd=/boot/initramfs-linux.img systemd.unit=multi-user.target" "Boot Fallback to console" "root=PARTUUID=b0c9c220-0f8d-49c1-b306-873d2519ce47 rw rootfstype=ext4 add_efi_memmap initrd=/boot/intel-ucode.img initrd=/boot/initramfs-linux-fallback.img systemd.unit=multi-user.target" The system boots in the same time as previously with kernel 3.16 and the journal log confirms early microcode update. journalctl -b | grep microcode Oct 23 15:41:56 localhost kernel: CPU0 microcode updated early to revision 0x1b, date = 2014-05-29 Oct 23 15:41:56 localhost kernel: CPU1 microcode updated early to revision 0x1b, date = 2014-05-29 Oct 23 15:41:56 localhost kernel: microcode: CPU0 sig=0x306a9, pf=0x2, revision=0x1b Oct 23 15:41:56 localhost kernel: microcode: CPU1 sig=0x306a9, pf=0x2, revision=0x1b Oct 23 15:41:56 localhost kernel: microcode: CPU2 sig=0x306a9, pf=0x2, revision=0x1b Oct 23 15:41:56 localhost kernel: microcode: CPU3 sig=0x306a9, pf=0x2, revision=0x1b Oct 23 15:41:56 localhost kernel: microcode: Microcode Update Driver: v2.00 tigran@aivazian.fsnet.co.uk, Peter Oruba So the updated kernel works fine for early microcode update, with the small amendment to the refind_linux.conf file as the rEFInd author suggested it would. I have tested this on three different machines all of which use rEFInd to boot. I note that the arch wiki has already been edited to include the change needed for the rEFInd boot manager. So this works fine. It is presumed that the latest microcode for the CPU in this machine is dated correctly as 2014-05-29. -- mike c

Neitsab

4:10 p.m.

New subject: [arch-general] [arch-dev-public] Changes to microcode updates

Le 23/10/2014 02:01, Marko Hauptvogel a écrit :

...

Referring to the comments from october 16th on the ck kernel package page [0] and the config of said package [1], your version of the ck kernel has not yet been configured to do early microcode updates. But this should follow be fixed soon as the v20140913 microcode package hit [extra] today. Try to boot the stock kernel and you should see 'updated early' lines in your logs.

Greetings

[0] https://aur.archlinux.org/packages/linux-ck/ [1] http://pkgbuild.com/git/aur-mirror.git/tree/linux-ck/config?id=438644e59ea36...

Thanks for the pointers ! I had imagined the ck kernel not being updated could matter, but as I failed having GRUB menu display on reboot I neglected trying the standard kernel before posting. My bad and thanks again!

Genes Lists

10:30 p.m.

New subject: [arch-general] [arch-dev-public] Changes to microcode updates

For refind: This is resolved. As per: https://bbs.archlinux.org/viewtopic.php?pid=1468931#p1468931 Summary: There are 2 methods: (a) Add the initrd=.. to the refind_linux.conf file. (b) If using stanza in refind.conf then add initrd= Both methods work it seems. I can confirm (b) works fine. g

3487

Age (days ago)

3493

Last active (days ago)

List overview

Download

19 comments

8 participants

participants (8)

Genes Lists
Jody Allen
Leonidas Spyropoulos
Marko Hauptvogel
Mike Cloaked
Neitsab
Neven Sajko
Thomas Bächler