Re: Linux* Processor Microcode Data File

[Giacomo A. Catenazzi]

Arjan van de Ven wrote:
> On Thu, 12 Mar 2009 11:03:11 +0100
> "Giacomo A. Catenazzi" <cate@xxxxxxxxxx> wrote:
>
> > > there are various cases where microcode is needed (for example, when
> > > you hotplug a new cpu); request_firmware() is just the right way to
> > > do such things, and an initscript is just the wrong way
> > I don't agree ;-)
> > I agree that request_firmware method is better than init.d scripts,
> > but not that it is the right things. microcodes should be loaded at
> > very beginning of boot process, so by BIOS, by GRUB or on hotpug
> > event by request_firmware.
>
> ... and how do you do CPU hotplug then ?

and system that doesn't use GRUB vX.Y, and ...

The driver in kernel should remain, for hotplug (CPU not completely
initialized) and for the other cases.

But my argument is that microcode loading in kernel, in "other cases"
is not optimal.
IIRC Intel documentation recommends to update microcodes in BIOS
(before full initialize all registers).

Anyway the "GRUB" proposal will be as an additional way, like BIOS
update: try to load microcode earlier as possible. The worse case
will be done very late, at new package installation time.

But now I've an other doubt:
Users asked me for a script that check and update microcode as
cronjob (I hope nobody will use extreme short "polling" periods to
Intel server.).
Updating microcode at full running time is not supported by
update_firmware method, right?
Is it the correct bahaviour? (according the "load earlier" I think
yes, but maybe I miss something)

> > BTW: why do we have microcode loading modular?
>
> only the legacy initscript part is modular afaik.

ok

ciao
	cate
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/