You are not logged in.
For those wanting to use grub-mkconfig, these are the changes in the patch proposed in the bug report mentioned by rumpelsepp (copied as a reference for creating a temporary workaround until grub is patched in the repository):
Add the following code in the file /etc/grub.d/10_linux (better backup the original) before the call of the "linux_entry" function (in the patch it's just before "title_correction_code="):
intel_ucode=
if test -e "/boot/intel-ucode.img" ; then
gettext_printf "Found Intel Microcode image\n" >&2
intel_ucode="$(make_system_path_relative_to_its_root /boot/intel-ucode.img)"
fi
To use this newly defined variable simply add it into the initrd-entry within the linux_entry function:
initrd ${intel_ucode} ${rel_dirname}/${initrd}
HTH
Offline
Sorry for cross-posting, I posted first in another thread but then I found this one where it seems most appropriate to post in. Here is my puzzle:
I have an Atom 330 processor (dual-core with hyperthreading), so it appears as 4 CPUs.
With the new intel-ucode.img in syslinux.cfg, this is what I get:
[ 0.000000] CPU0 microcode updated early to revision 0x219, date = 2009-04-10
[ 0.556420] microcode: CPU0 sig=0x106c2, pf=0x8, revision=0x219
[ 0.556453] microcode: CPU1 sig=0x106c2, pf=0x8, revision=0x213
[ 0.556481] microcode: CPU2 sig=0x106c2, pf=0x8, revision=0x219
[ 0.556510] microcode: CPU3 sig=0x106c2, pf=0x8, revision=0x213
[ 0.556808] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
So yeah, it applied the microcode (early) to just one core.
You can see above that CPU0 and CPU2 (same core) are 0x219, the other core (CPU1,CPU3) remained at 0x213.
Nice, isn't it?
Offline
Howdy!
I know that a lot has been said on this subject, but I still have a few questions.
My system:
3.16.4-1-ARCH x86_64
KDE 4.14.2
#lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 119,2G 0 disk
├─sda1 8:1 0 22G 0 part /
└─sda2 8:2 0 97,2G 0 part /home
sdb 8:16 0 698,7G 0 disk
├─sdb1 8:17 0 15,2G 0 part /var
└─sdb2 8:18 0 683,5G 0 part /data
sr0 11:0 1 1024M 0 rom
#journalctl -b | grep microcode
okt 28 09:41:24 asus-arch kernel: microcode: CPU0 sig=0x306a9, pf=0x10, revision=0x12
okt 28 09:41:24 asus-arch kernel: microcode: CPU0 sig=0x306a9, pf=0x10, revision=0x12
okt 28 09:41:24 asus-arch kernel: microcode: CPU0 updated to revision 0x1b, date = 2014-05-29
okt 28 09:41:24 asus-arch kernel: microcode: CPU1 sig=0x306a9, pf=0x10, revision=0x12
okt 28 09:41:24 asus-arch kernel: microcode: CPU1 sig=0x306a9, pf=0x10, revision=0x12
okt 28 09:41:24 asus-arch kernel: microcode: CPU1 updated to revision 0x1b, date = 2014-05-29
okt 28 09:41:24 asus-arch kernel: microcode: CPU2 sig=0x306a9, pf=0x10, revision=0x12
okt 28 09:41:24 asus-arch kernel: microcode: CPU2 sig=0x306a9, pf=0x10, revision=0x12
okt 28 09:41:24 asus-arch kernel: microcode: CPU2 updated to revision 0x1b, date = 2014-05-29
okt 28 09:41:24 asus-arch kernel: microcode: CPU3 sig=0x306a9, pf=0x10, revision=0x12
okt 28 09:41:24 asus-arch kernel: microcode: CPU3 sig=0x306a9, pf=0x10, revision=0x12
okt 28 09:41:24 asus-arch kernel: microcode: CPU3 updated to revision 0x1b, date = 2014-05-29
okt 28 09:41:24 asus-arch kernel: microcode: CPU4 sig=0x306a9, pf=0x10, revision=0x12
okt 28 09:41:24 asus-arch kernel: microcode: CPU4 sig=0x306a9, pf=0x10, revision=0x12
okt 28 09:41:24 asus-arch kernel: microcode: CPU4 updated to revision 0x1b, date = 2014-05-29
okt 28 09:41:24 asus-arch kernel: microcode: CPU5 sig=0x306a9, pf=0x10, revision=0x12
okt 28 09:41:24 asus-arch kernel: microcode: CPU5 sig=0x306a9, pf=0x10, revision=0x12
okt 28 09:41:24 asus-arch kernel: microcode: CPU5 updated to revision 0x1b, date = 2014-05-29
okt 28 09:41:24 asus-arch kernel: microcode: CPU6 sig=0x306a9, pf=0x10, revision=0x12
okt 28 09:41:24 asus-arch kernel: microcode: CPU6 sig=0x306a9, pf=0x10, revision=0x12
okt 28 09:41:24 asus-arch kernel: microcode: CPU6 updated to revision 0x1b, date = 2014-05-29
okt 28 09:41:24 asus-arch kernel: microcode: CPU7 sig=0x306a9, pf=0x10, revision=0x12
okt 28 09:41:24 asus-arch kernel: microcode: CPU7 sig=0x306a9, pf=0x10, revision=0x12
okt 28 09:41:24 asus-arch kernel: microcode: CPU7 updated to revision 0x1b, date = 2014-05-29
okt 28 09:41:24 asus-arch kernel: microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
#dmidecode -t processor
Processor Information
Socket Designation: SOCKET 0
Type: Central Processor
Family: Core i7
Manufacturer: Intel(R) Corporation
ID: A9 06 03 00 FF FB EB BF
Signature: Type 0, Family 6, Model 58, Stepping 9
$ 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
#cat /boot/grub/grub.cfg
linux /boot/vmlinuz-linux root=UUID=f7b05be7-44b8-40a5-b623-c387ca167de1 rw quiet rcutree.rcu_idle_gp_delay=1 acpi_osi=
echo 'Loading initial ramdisk ...'
initrd /boot/initramfs-linux.img
So:
- When I update my system and do not change anything in the "/boot/grub/grub.cfg" and then restart it, what would happen? Kernel panic or everything would be OK?
- But if I change the parameters in the "/boot/grub/grub.cfg" to initrd /intel-ucode.img /boot/initramfs-linux.img save and reboot the system, it should be all OK?
Offline
Howdy!
- When I update my system and do not change anything in the "/boot/grub/grub.cfg" and then restart it, what would happen? Kernel panic or everything would be OK?
- But if I change the parameters in the "/boot/grub/grub.cfg" to initrd /intel-ucode.img /boot/initramfs-linux.img save and reboot the system, it should be all OK?
- You would boot as usual, but would have an out of date cpu microcode.
- You would have an updated microcode, but only until kernel update. After update /boot/grub/grub.cfg would be as it was before your edit.
To make the change permanent you need to edit /etc/grub.d/10_linux. Consult wiki for the task.
Offline
Thanks, bstaletic
Offline
My results before editing /boot/grub/grub.cfg :
Kernel: 3.17.1-1-ARCH x86_64
# journalctl -b | grep microcode
okt 28 13:45:12 asus-arch kernel: microcode: CPU0 sig=0x306a9, pf=0x10, revision=0x12
okt 28 13:45:12 asus-arch kernel: microcode: CPU1 sig=0x306a9, pf=0x10, revision=0x12
okt 28 13:45:12 asus-arch kernel: microcode: CPU2 sig=0x306a9, pf=0x10, revision=0x12
okt 28 13:45:12 asus-arch kernel: microcode: CPU3 sig=0x306a9, pf=0x10, revision=0x12
okt 28 13:45:12 asus-arch kernel: microcode: CPU4 sig=0x306a9, pf=0x10, revision=0x12
okt 28 13:45:12 asus-arch kernel: microcode: CPU5 sig=0x306a9, pf=0x10, revision=0x12
okt 28 13:45:12 asus-arch kernel: microcode: CPU6 sig=0x306a9, pf=0x10, revision=0x12
okt 28 13:45:12 asus-arch kernel: microcode: CPU7 sig=0x306a9, pf=0x10, revision=0x12
okt 28 13:45:12 asus-arch kernel: microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
and after editing /boot/grub/grub.cfg :
# journalctl -b | grep microcode
okt 28 14:14:00 asus-arch kernel: CPU0 microcode updated early to revision 0x1b, date = 2014-05-29
okt 28 14:14:00 asus-arch kernel: CPU1 microcode updated early to revision 0x1b, date = 2014-05-29
okt 28 14:14:00 asus-arch kernel: CPU2 microcode updated early to revision 0x1b, date = 2014-05-29
okt 28 14:14:00 asus-arch kernel: CPU3 microcode updated early to revision 0x1b, date = 2014-05-29
okt 28 14:14:00 asus-arch kernel: microcode: CPU0 sig=0x306a9, pf=0x10, revision=0x1b
okt 28 14:14:00 asus-arch kernel: microcode: CPU1 sig=0x306a9, pf=0x10, revision=0x1b
okt 28 14:14:00 asus-arch kernel: microcode: CPU2 sig=0x306a9, pf=0x10, revision=0x1b
okt 28 14:14:00 asus-arch kernel: microcode: CPU3 sig=0x306a9, pf=0x10, revision=0x1b
okt 28 14:14:00 asus-arch kernel: microcode: CPU4 sig=0x306a9, pf=0x10, revision=0x1b
okt 28 14:14:00 asus-arch kernel: microcode: CPU5 sig=0x306a9, pf=0x10, revision=0x1b
okt 28 14:14:00 asus-arch kernel: microcode: CPU6 sig=0x306a9, pf=0x10, revision=0x1b
okt 28 14:14:00 asus-arch kernel: microcode: CPU7 sig=0x306a9, pf=0x10, revision=0x1b
okt 28 14:14:00 asus-arch kernel: microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
So the only difference is revision, which has changed from revision=0x12 into revision=0x1b
Offline
That is supposed to be the only difference. May I ask you something? Why have you not made this change permanent through /etc/grub.d/10_linux?
Offline
I edited /etc/grub.d/10_linux but I wonder why the kernel stops providing this service? Why stop Intel firmware and autoupdate AMD? Is there any given reason?
"Common sense is not common"
Offline
Hi All,
I modified the /etc/grub.d/10_linux as instructed in the wiki. This is my machine:
$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 42
model name : Intel(R) Pentium(R) CPU G620 @ 2.60GHz
stepping : 7
microcode : 0x29
# bsdtar -Oxf /boot/intel-ucode.img | iucode_tool -tb -lS -
iucode_tool: system has processor(s) with signature 0x000206a7
selected microcodes:
001: sig 0x000206a7, pf mask 0x12, 2013-06-12, rev 0x0029, size 10240
$ dmesg | grep microcode
[ 0.000000] CPU0 microcode updated early to revision 0x29, date = 2013-06-12
[ 0.084750] CPU1 microcode updated early to revision 0x29, date = 2013-06-12
[ 0.446728] microcode: CPU0 sig=0x206a7, pf=0x2, revision=0x29
[ 0.446734] microcode: CPU1 sig=0x206a7, pf=0x2, revision=0x29
[ 0.446790] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
$ pacman -Q intel-ucode
intel-ucode 20140913-1
Is it abnormal that dmesg said the date of 2013-06-12 instead of some date in 2014?
Offline
Hi All,
I modified the /etc/grub.d/10_linux as instructed in the wiki. This is my machine:
$ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 42 model name : Intel(R) Pentium(R) CPU G620 @ 2.60GHz stepping : 7 microcode : 0x29
# bsdtar -Oxf /boot/intel-ucode.img | iucode_tool -tb -lS - iucode_tool: system has processor(s) with signature 0x000206a7 selected microcodes: 001: sig 0x000206a7, pf mask 0x12, 2013-06-12, rev 0x0029, size 10240
$ dmesg | grep microcode [ 0.000000] CPU0 microcode updated early to revision 0x29, date = 2013-06-12 [ 0.084750] CPU1 microcode updated early to revision 0x29, date = 2013-06-12 [ 0.446728] microcode: CPU0 sig=0x206a7, pf=0x2, revision=0x29 [ 0.446734] microcode: CPU1 sig=0x206a7, pf=0x2, revision=0x29 [ 0.446790] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
$ pacman -Q intel-ucode intel-ucode 20140913-1
Is it abnormal that dmesg said the date of 2013-06-12 instead of some date in 2014?
The date 2013-06-12 is in your case the latest microcode for your specific CPU - so that looks normal.
Mike C
Offline