Bug#684569: linux-image-3.5-trunk-686-pae: microcode module loaded on Celeron CPU
Dear Andi, thank you for your response. Am Sonntag, den 12.08.2012, 06:10 -0700 schrieb Andi Kleen: On Sat, Aug 11, 2012 at 03:17:19PM +0200, Paul Menzel wrote: 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. So I do not see what purpose this module has for desktop users. Intel regularly releases microcode updates and distributions are supposed to do regular package updates with the latest microcode file. You should get those with your normal update mechanism. In general it's recommended to run with the latest microcode. Looking into this some more, this seems unlikely in Debian because the microcode packages are in non-free [1] and therefore not available for Debian users not having enabled non-free repositories. Because of that the microcode packages are also non-essential, that means not installed by default even when non-free packages are allowed. And normal users will never install them by themselves. So currently I am pretty sure 99, % of Debian users do not have it installed. With the latest mainline kernel the microcode driver should be automatically loaded by CPUID probing through udev. How can I find out, if the microcode provided by my BIOS is older than the one provided by the processor vendor? I am pretty sure, that for example Intel does not release any updates for the Celeron CPU in my ASUS Eee PC 701 4G. Thanks, Paul [1] http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=intel-microcode;dist=unstable signature.asc Description: This is a digitally signed message part
Bug#684569: linux-image-3.5-trunk-686-pae: microcode module loaded on Celeron CPU
On Mon, 13 Aug 2012, Paul Menzel wrote: Looking into this some more, this seems unlikely in Debian because the microcode packages are in non-free [1] and therefore not available for Debian users not having enabled non-free repositories. Because of that the microcode packages are also non-essential, that means not installed by default even when non-free packages are allowed. And normal users will never install them by themselves. So currently I am pretty sure 99, % of Debian users do not have it installed. That is correct, yes. We may change the Debian installer to offer to install the microcode packages for AMD and/or Intel to users that enable non-free. We could also document the availability of the microcode packages in the release documentation, I suppose. But Debian really isn't big on the non-free stuff. With the latest mainline kernel the microcode driver should be automatically loaded by CPUID probing through udev. How can I find out, if the microcode provided by my BIOS is older than the one provided by the processor vendor? I am pretty sure, that for example Intel does not release any updates for the Celeron CPU in my ASUS Eee PC 701 4G. The easiest way, by far, is to attempt to update to the latest microcode in the microcode distribution. Assuming you're using Debian testing/unstable, install the intel-microcode package (in unstable, install also package iucode-tool to avoid bloating the initramfs). Then grep for microcode in the kernel logs. The 3.2 kernel will log the fact that it had to update the processor microcode. If it doesn't log anything, either no microcode for that processor model is available, or you're already running newer microcode. In Debian stable, it works the same way but I am not sure the kernel will log anything of value. If you want to do it the hard way: iucode-tool --scan-system will tell you your processor's signature (requires the cpuid module to be loaded first). If you're running Debian stable, wait a few days for the Squeeze backport to hit the mirrors. You can get the pf_mask and current version of microcode on each core from /sys/devices/system/cpu/cpu*/microcode/, and you can check the intel-microcode package changelog for your processor's signature to see if a higher revision is available. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120813163215.ga3...@khazad-dum.debian.net
Bug#684569: linux-image-3.5-trunk-686-pae: microcode module loaded on Celeron CPU
On Mon, Aug 13, 2012 at 09:44:48AM +0200, Paul Menzel wrote: Looking into this some more, this seems unlikely in Debian because the microcode packages are in non-free [1] and therefore not available for Debian users not having enabled non-free repositories Because of that the microcode packages are also non-essential, that means not installed by default even when non-free packages are allowed. And normal users will never install them by themselves. Sounds like a problem. They actually fix bugs so it's recommended. BIOSes are not normally updated regularly, so the microcode update gives you a faster path to that. So currently I am pretty sure 99, % of Debian users do not have it installed. With the latest mainline kernel the microcode driver should be automatically loaded by CPUID probing through udev. How can I find out, if the microcode provided by my BIOS is older than the one provided by the processor vendor? I am pretty sure, that for example Intel does not release any updates for the Celeron CPU in my ASUS Eee PC 701 4G. The newer kernels report the microcode version in /proc/cpuinfo If not you can probably use some tool like x86info. Check version. Load the latest microcode. Compare versions. -Andi -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120813164459.go2...@tassilo.jf.intel.com
Bug#684569: linux-image-3.5-trunk-686-pae: microcode module loaded on Celeron CPU
On Sat, Aug 11, 2012 at 03:17:19PM +0200, Paul Menzel wrote: 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. So I do not see what purpose this module has for desktop users. Intel regularly releases microcode updates and distributions are supposed to do regular package updates with the latest microcode file. You should get those with your normal update mechanism. In general it's recommended to run with the latest microcode. With the latest mainline kernel the microcode driver should be automatically loaded by CPUID probing through udev. -Andi -- a...@linux.intel.com -- Speaking for myself only -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120812131028.gj2...@tassilo.jf.intel.com
Bug#684569: linux-image-3.5-trunk-686-pae: microcode module loaded on Celeron CPU
Package: src:linux Version: 3.5-1~experimental.1 Severity: normal Control: user debian-eeepc-de...@lists.alioth.debian.org Control: usertags -1 701 Dear Debian folks, 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. [7.197429] [drm] initialized overlay support […] [7.342650] microcode: Microcode Update Driver: v2.00 tig...@aivazian.fsnet.co.uk, Peter Oruba This is an ASUS Eee PC 701 4G [2] with an Intel Celeron processor. $ more /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 13 model name : Intel(R) Celeron(R) M processor 900MHz stepping: 8 microcode : 0x20 cpu MHz : 630.097 cache size : 512 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov clflush dts acpi mmx fxsr sse sse2 ss tm pbe nx up bts bogomips: 1260.19 clflush size: 64 cache_alignment : 64 address sizes : 32 bits physical, 32 bits virtual There are several descriptions but one is »AMD Microcode Update Driver«, but looking at the source it also has a component to work with Intel processors. $ sudo modinfo microcode filename: /lib/modules/3.5-trunk-686-pae/kernel/arch/x86/kernel/microcode.ko alias: devname:cpu/microcode alias: char-major-10-184 license:GPL author: Tigran Aivazian tig...@aivazian.fsnet.co.uk description:Microcode Update Driver license:GPL author: Tigran Aivazian tig...@aivazian.fsnet.co.uk description:Microcode Update Driver license:GPL v2 author: Peter Oruba description:AMD Microcode Update Driver alias: x86cpu:vendor:0002:family:*:model:*:feature:* alias: x86cpu:vendor::family:*:model:*:feature:* depends: intree: Y vermagic: 3.5-trunk-686-pae SMP mod_unload modversions 686 So to summarize I think, this module should not be loaded automatically for this Celeron processor, which is not need for operation. Commit 78ff123b [1] commit 78ff123b05fb15beb1ad670372eea0d299d0b8af Author: Andi Kleen a...@linux.intel.com Date: Thu Jan 26 00:09:13 2012 +0100 is likely the one introducing this behavior. $ git describe 78ff123b05fb15beb1ad670372eea0d299d0b8af v3.3-rc1-38-g78ff123 Thanks, Paul [1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=78ff123b05fb15beb1ad670372eea0d299d0b8af -- Package-specific info: ** Version: Linux version 3.5-trunk-686-pae (Debian 3.5-1~experimental.1) (debian-kernel@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-8) ) #1 SMP Thu Aug 2 17:56:18 UTC 2012 ** Command line: BOOT_IMAGE=/boot/vmlinuz-3.5-trunk-686-pae root=UUID=b33ef3d8-b6d8-481d-a9a3-0050047ab9b0 ro quiet noisapnp ** Not tainted ** Kernel log: [2.112230] ata2.00: configured for UDMA/66 [2.112610] scsi 1:0:0:0: Direct-Access ATA SILICONMOTION SM n/a PQ: 0 ANSI: 5 [2.133133] sd 1:0:0:0: [sda] 7815024 512-byte logical blocks: (4.00 GB/3.72 GiB) [2.133316] sd 1:0:0:0: [sda] Write Protect is off [2.133327] sd 1:0:0:0: [sda] Mode Sense: 00 3a 00 00 [2.133403] sd 1:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA [2.135947] sda: sda1 [2.137146] sd 1:0:0:0: [sda] Attached SCSI disk [2.144709] sd 1:0:0:0: Attached scsi generic sg0 type 0 [2.236088] usb 1-5: new high-speed USB device number 3 using ehci_hcd [2.276134] Refined TSC clocksource calibration: 630.064 MHz. [2.276155] Switching to clocksource tsc [2.295504] kjournald starting. Commit interval 5 seconds [2.295571] EXT3-fs (sda1): mounted filesystem with ordered data mode [2.369423] usb 1-5: New USB device found, idVendor=0951, idProduct=1606 [2.369440] usb 1-5: New USB device strings: Mfr=1, Product=2, SerialNumber=4 [2.369451] usb 1-5: Product: UB6225 [2.369459] usb 1-5: Manufacturer: ENE [2.369467] usb 1-5: SerialNumber: 146030377350 [2.480161] usb 1-8: new high-speed USB device number 4 using ehci_hcd [2.613176] usb 1-8: New USB device found, idVendor=eb1a, idProduct=2761 [2.613192] usb 1-8: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [2.980091] usb 3-1: new low-speed USB device number 2 using uhci_hcd [3.160058] usb
Bug#684569: linux-image-3.5-trunk-686-pae: microcode module loaded on Celeron CPU
On Sat, 2012-08-11 at 12:24 +0200, Paul Menzel wrote: Package: src:linux Version: 3.5-1~experimental.1 Severity: normal Control: user debian-eeepc-de...@lists.alioth.debian.org Control: usertags -1 701 Dear Debian folks, 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. Commit 78ff123b [1] commit 78ff123b05fb15beb1ad670372eea0d299d0b8af Author: Andi Kleen a...@linux.intel.com Date: Thu Jan 26 00:09:13 2012 +0100 is likely the one introducing this behavior. $ git describe 78ff123b05fb15beb1ad670372eea0d299d0b8af v3.3-rc1-38-g78ff123 I think that should actually be backported to wheezy, as I meant to apply all the CPU auto-loading patches. Ben. -- Ben Hutchings Unix is many things to many people, but it's never been everything to anybody. signature.asc Description: This is a digitally signed message part
Bug#684569: linux-image-3.5-trunk-686-pae: microcode module loaded on Celeron CPU
user debian-eeepc-de...@lists.alioth.debian.org usertags 684569 701 quit Dear Ben, thank you for your reply. Tigran, Andi, you can read the whole thread under for #684569 [1]. It would be great, if you could clarify the points below for me. Am Samstag, den 11.08.2012, 13:23 +0100 schrieb Ben Hutchings: On Sat, 2012-08-11 at 12:24 +0200, Paul Menzel wrote: Package: src:linux Version: 3.5-1~experimental.1 Severity: normal Control: user debian-eeepc-de...@lists.alioth.debian.org Control: usertags -1 701 I have no idea why the last two processing control commands were rejected by the Debian BTS [2][3]. Hopefully it will work now. 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. So I do not see what purpose this module has for desktop users. Commit 78ff123b [1] commit 78ff123b05fb15beb1ad670372eea0d299d0b8af Author: Andi Kleen a...@linux.intel.com Date: Thu Jan 26 00:09:13 2012 +0100 is likely the one introducing this behavior. $ git describe 78ff123b05fb15beb1ad670372eea0d299d0b8af v3.3-rc1-38-g78ff123 I think that should actually be backported to wheezy, as I meant to apply all the CPU auto-loading patches. I never thought that this would be the outcome of my report. ;-) Thanks, Paul [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684569 [2] http://wiki.debian.org/bugs.debian.org/usertags [3] http://www.donarmstrong.com/posts/control_at_submit/ signature.asc Description: This is a digitally signed message part
Bug#684569: linux-image-3.5-trunk-686-pae: microcode module loaded on Celeron CPU
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 signature.asc Description: This is a digitally signed message part
Bug#684569: linux-image-3.5-trunk-686-pae: microcode module loaded on Celeron CPU
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. signature.asc Description: This is a digitally signed message part
Bug#684569: linux-image-3.5-trunk-686-pae: microcode module loaded on Celeron CPU
Am Samstag, den 11.08.2012, 15:12 +0100 schrieb Ben Hutchings: 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. Sorry for being dumb. But why is needed now that the module automatically/unconditionally loads? 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 and sorry for my ignorance, Paul signature.asc Description: This is a digitally signed message part
Bug#684569: linux-image-3.5-trunk-686-pae: microcode module loaded on Celeron CPU
On Sat, 2012-08-11 at 19:50 +0200, Paul Menzel wrote: Am Samstag, den 11.08.2012, 15:12 +0100 schrieb Ben Hutchings: 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. Sorry for being dumb. But why is needed now that the module automatically/unconditionally loads? udev is the thing that automatically loads modules related to devices. But the modules need to provide a clue to udev (or modprobe) that they are related to those devices. And that's what the change you identified does. 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. Thanks and sorry for my ignorance, Paul -- Ben Hutchings Unix is many things to many people, but it's never been everything to anybody. signature.asc Description: This is a digitally signed message part
