Am Samstag, den 11.08.2012, 14:24 +0100 schrieb Ben Hutchings:
> On Sat, 2012-08-11 at 15:17 +0200, Paul Menzel wrote:
> [...]
> > > > testing Linux kernel 3.5-1~experimental.1 [1] from Debian experimental I
> > > > noticed that the module `microcode` is loaded which has according to
> > > > `/var/log/syslog` not been the case with Linux 3.2.y.
> > > [...]
> > > > So to summarize I think, this module should not be loaded automatically
> > > > for this Celeron processor, which is not need for operation.
> > >
> > > This really depends on what operations you want to do, and how buggy the
> > > CPU microcode installed by the BIOS is. If you care that much about it,
> > > you can blacklist it.
> >
> > Understood. Although I do not understand from where the updated
> > microcode is fetched. The only way for desktop users were BIOS upgrades
> > if I remember correctly. Linux does not ship the microcode, does not it.
> [...]
>
> It's packaged in ia32-microcode (and amd64-microcode)
Hmm, no microcode packages are installed on my systems. (Which seems to
be a bad thing.)
$ aptitude search microcode
p amd64-microcode - Processor microcode firmware for AMD CPUs
p intel-microcode - Processor microcode firmware for Intel CPUs
My point is that if you do not have these microcode packages installed,
and if they are not installed automatically most users will not do so,
then loading the microcode module/driver does not have any effect.
> and I believe it can be loaded by udev now.
Should not be udev also responsible for loading the necessary modules
then?
Another solution would be that the packages shipping microcodes should
also ship an appropriate `/etc/modprobe.d/microcode.conf` file to load
the module.
Thanks,
Paul
Attachment:
signature.asc
Description: This is a digitally signed message part