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

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

Oh, ok.

>> 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?

Adrian Fita

Reply to: