On Sat, 2012-08-11 at 15:44 +0200, Paul Menzel wrote: > 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? It is. Ben. > Another solution would be that the packages shipping microcodes should > also ship an appropriate `/etc/modprobe.d/microcode.conf` file to load > the module. -- Ben Hutchings Unix is many things to many people, but it's never been everything to anybody.
Attachment:
signature.asc
Description: This is a digitally signed message part