Re: [SOLVED] initramfs-tools and intel-microcode with kernel 3.9.1 (sid)
On 09/07/13 14:26, Henrique de Moraes Holschuh wrote:
On Tue, 09 Jul 2013, Klaus wrote:
On my laptop I'm running sid amd64.
I've noticed that during the early stages of booting, the Intel
microcode fails to get loaded. Switching back
On 3.9.x, it should load as the very first thing the kernel actually logs
(it will be the very first line in /var/log/dmesg), and not through the
to kernel version 3.8.2 solves this issue. So far I can't tell
whether this is an actual problem, since I haven't
even understood what the microcode is or does.
It fixes nasty bugs in your system processor. But it is possible that you
don't need a microcode update in the first place at this time, which would
explain why you don' get a "microcode early update" first line in
When I manually re-run "update-initramfs -uv", it tells me that the
microcode is found, bundled and put into
the initrd image. Here is an extract of the output:
It does, but as an early initramfs. And it could still be either the same
version as the microcode in your BIOS/EFI, or maybe even an older version.
In either case, it will not be used, as the kernel _never_ downgrades
intel-microcode: Using early firmware update mode (Linux v3.9 and later)...
/usr/sbin/iucode_tool: system has processor(s) with signature 0x0001067a
/usr/sbin/iucode_tool: selected 3 microcode(s), 3 signature(s)
Please boot kernel 3.9 with the early initramfs, and give me the output of:
grep microcode /proc/cpuinfo
/usr/sbin/iucode_tool -s 0x0001067a -l /lib/firmware/intel-ucode/
Also interesting (?) to see, that the newer initrd image is not compressed:
The early initramfs image is an uncompressed CPIO archive without CRC, which
is *prepended* to the regular compressed initramfs image.
There isn't an userspace tool that actually duplicates what the kernel does
for loading the initramfs image (it will read any mix of compressed and
uncompressed cpio archives appended one after the other. However, the early
initramfs for firmware and microcode update *must* be uncompressed, and it
*must* be the first cpio image in the initramfs).
Thank you very much for your comprehensive explanations! Here are the
bits of information you suggested looking at:
$ head -20 /var/log/dmesg
[ 0.000000] CPU0 microcode updated early to revision 0xa0b, date =
[ 0.000000] Initializing cgroup subsys cpuset
[ 0.000000] Initializing cgroup subsys cpu
[ 0.000000] Linux version 3.9-1-amd64
(email@example.com) (gcc version 4.7.3 (Debian 4.7.3-5) )
#1 SMP Debian 3.9.8-1
[ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-3.9-1-amd64
root=UUID=b392c1fb-7707-4a2c-8129-a6a1b41446bf ro quiet
It's a dual core cpu:
$ head -5 /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Core(TM)2 Duo CPU U9400 @ 1.40GHz
so there are two entries for the microcode:
$ grep microcode /proc/cpuinfo
microcode : 0xa0b
microcode : 0xa0b
and the iucode_tool lists these:
$ /usr/sbin/iucode_tool -s 0x0001067a -l /lib/firmware/intel-ucode/
001: sig 0x0001067a, pf mask 0xa0, 2010-09-28, rev 0x0a0b, size 8192
002: sig 0x0001067a, pf mask 0x11, 2010-09-28, rev 0x0a0b, size 8192
003: sig 0x0001067a, pf mask 0x44, 2010-09-28, rev 0x0a0b, size 8192
Looks all just as you predicted.
Feature / bug / needs reporting?