Re: ANNOUNCEMENT: Intel/AMD x86 CPU microcode update system in non-free
On 07/11/12 02:50, Henrique de Moraes Holschuh wrote:
> On Wed, 07 Nov 2012, Adrian Fita wrote:
>> My CPU is an AMD Turion(tm)X2 Dual Core Mobile RM-76, cpu family: 17, so
>> it doesn't need the amd64-microcode package which contains microcode
>> updates only for cpu families: 10h - 14h & 15h. But the microcode kernel
> Family 17 (decimal) is family 11h (hexadecimal).
>> module gets loaded regardless of the fact that my CPU doesn't need it.
> Linux loads drivers for the devices it supports. Your processor supports
> microcode updates, and the kernel does know how to apply them, so the
> microcode driver will load.
> Also, the modular microcode driver won't complain of missing firmware files
> if amd64-microcode is properly installed and working (the firmware files
> with the microcode will be there), so something is wrong.
> Are you using a custom kernel? was the initramfs for the running kernel
> properly updated by "update-initramfs -u" ? Are you using systemd?
I'm not using a custom kernel, just the stock Debian,
linux-image-3.5-trunk-686-pae kernel. I was confused why I need to have
the amd64-microcode package instaled because it doesn't seem to matter
whether I have it installed or not. "dmesg | grep microcode:" gets me
"microcode: CPU0: patch_level=0x02000057" regardless if I have the
microcode package installed or not; so am I to assume that my CPU gets
its microcode update from the BIOS/EFI - if it even has one...? In that
case it does seem that having the amd64-microcode package installed is
superfluous, but if I uninstall it, I see the message "microcode: failed
to load file amd-ucode/microcode_amd.bin" displayed at boot, so I'll
keep it installed.
>> So, shouldn't the microcode module be loaded only for the CPUs that need
>> it? I know I can blacklist the module from loading, but I think this
>> should be handled more elegantly - read automatically - by Debian so
>> users wouldn't have to manually fiddle with blacklisting modules. I
> It is not a very good idea to overcomplicate stuff that will break the boot
> process should it be buggy.
Fair enough, but how about having the linux-image packages recommend the
*microcode packages for installation so users won't get confused by the
message caused by the module trying to load the file with the microcode
update and not finding it?