[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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
firmware loader.

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
/var/log/dmesg.

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
microcode.

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).


Dear Henrique

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 = 2010-09-28
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[ 0.000000] Linux version 3.9-1-amd64 (debian-kernel@lists.debian.org) (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/
selected microcodes:
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?
FEATURE. ggg


Thanks again,

--
Klaus


Reply to: