Re: ANNOUNCEMENT: Intel/AMD x86 CPU microcode update system in non-free
On Thu, 08 Nov 2012, Carlos Alberto Lopez Perez wrote: On 06/11/12 17:05, Henrique de Moraes Holschuh wrote: Still, it did lead me to a possible cause: I am not trying to modprobe microcode in the intel-microcode postinst. This can indeed cause the failure to update microcode at package install time. I forget why I didn't do it that way in the first place, but that's easily fixed. Please file a bug, severity minor. I will check for any possible problems it might cause, and if I can't find any, I will fix it in unstable. Same here. Just installed intel-microcode and iucode-tool and it didn't worked until I manually modprobed the microcode module. Just wondering... Perhaps you should add a file in /etc/modules.d/ to automatically load the microcode module at start-up? It is indeed loaded on boot by the initramfs support, and it is also auto-loaded by the kernel in some situations. So, it will be fine after a reboot. Non-initramfs setups are supported in a limited fashion, and will require manual setup. This is properly documented in the package's README files in /usr/share/doc/intel-microcode/ or /usr/share/doc/amd64-microcode/. -- 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-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121108161933.ga9...@khazad-dum.debian.net
Re: ANNOUNCEMENT: Intel/AMD x86 CPU microcode update system in non-free
Hi, On Donnerstag, 8. November 2012, Ben Hutchings wrote: And an annoying technical detail makes it suboptimal to add the microcode packages as a recommendation of the firmware-linux-nonfree package. ...which is that dpkg does not support architecture-specific relations in binary packages. So make it recommend both microcode packages? cheers, Holger -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201211081933.34160.hol...@layer-acht.org
Re: ANNOUNCEMENT: Intel/AMD x86 CPU microcode update system in non-free
On Donnerstag, 8. November 2012, Ben Hutchings wrote: And an annoying technical detail makes it suboptimal to add the microcode packages as a recommendation of the firmware-linux-nonfree package. ...which is that dpkg does not support architecture-specific relations in binary packages. [Holger Levsen] So make it recommend both microcode packages? So firmware-linux-nonfree should have two Recommends that are unsatisfiable on all but 2 of Debian's architectures (i386 and amd64)? I agree with Ben that that is suboptimal. ...But it does bring up the question of why intel-microcode and amd64-microcode are not built on kFreeBSD or the Hurd. Maybe those kernels lack a CPU microcode interface? Peter -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121108195848.gh4...@p12n.org
Re: ANNOUNCEMENT: Intel/AMD x86 CPU microcode update system in non-free
Hi! Peter Samuelson pe...@p12n.org writes: ...But it does bring up the question of why intel-microcode and amd64-microcode are not built on kFreeBSD or the Hurd. Maybe those kernels lack a CPU microcode interface? http://www.freebsd.org/doc/faq/compatibility-processors.html Though I rather doubt the linux microcode framework and the FreeBSD one are *that* easily compatible -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87fw4j9819@mitoraj.siccegge.de
Re: ANNOUNCEMENT: Intel/AMD x86 CPU microcode update system in non-free
On Thu, 08 Nov 2012, Christoph Egger wrote: Peter Samuelson pe...@p12n.org writes: ...But it does bring up the question of why intel-microcode and amd64-microcode are not built on kFreeBSD or the Hurd. Maybe those kernels lack a CPU microcode interface? http://www.freebsd.org/doc/faq/compatibility-processors.html Though I rather doubt the linux microcode framework and the FreeBSD one are *that* easily compatible The datafiles should be identical, I think. So, if someone actually uses Debian/FreeBSD, has an AMD and Intel processor boxes that can take a microcode update (i.e. outdated BIOS/EFI), and wants to help, it should be possible to support it. -- 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-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121108210120.ga16...@khazad-dum.debian.net
Microcode update for Xen in Wheezy (Was: Re: ANNOUNCEMENT: Intel/AMD x86 CPU microcode update system in non-free)
Dropping users and adding pkg-xen-devel and debian-kernel. On Tue, 2012-11-06 at 15:43 +0100, Stephan Seitz wrote: On Mon, Nov 05, 2012 at 06:12:53PM -0200, Henrique de Moraes Holschuh wrote: I would like to bring to your attention the improved support for system processor (CPU) microcode updates, for x86/i686/x86-64/amd64 systems that was recently added to [non-free] Wheezy. Alas, this will not work for XEN users because I can’t update the microcode in Dom0 with xen-hypervisor 4.1. I think it would be useful to have this recorded as a (wishlist) bug. There exist kernel patches (over a year old), but according to the xen-devel ML they are not good enough to be included in the kernel. Basically the kernel guys have decided that microcode loading should be done earlier (pre kernel) and so aren't willing to take the Xen patches to integrate with the old mechanism. Which is frustrating but fair enough. With XEN 4.2 the hypervisor can load the CPU microcode. Would this be a reason to include XEN 4.2 in Wheezy? I don't think upgrading to 4.2 would be consistent with the freeze. I think there are basically two options here, first is to backport the patches to 4.1[0]. It's quite a big set of changes but it seems to be mostly contained to the microcode files (I'm not an expert in this area though). Second would be to take the kernel patches as an interim measure for Wheezy with the understanding that the inevitable upgrade to 4.2+ in Jessie will cause them to go away. Although the kernel patches are not in upstream they are pretty long standing (the same code is in the Squeeze kernel's xen flavour for example) and well tested compared with any proposed new backport of the Xen feature. With the kernel change there's also no need for surrounding tools changes (e.g. teaching update-grub about this stuff) for Wheezy, which is a can-o-worms in itself. So I'd be inclined to recommend going the kernel patch route for Wheezy. Ian. [0] I think the relevant set of backports would be: 24315:3e5683b6b37f x86/microcode: enable boot time (pre-Dom0) loading 24390:77528dbced3e x86/microcode: Allow ucode= argument to be negative 24411:ca5f588bd203 x86/ucode: fix for AMD Fam15 CPUs [1] 9 files changed, 230 insertions(+), 63 deletions(-) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1352285556.12977.42.ca...@hastur.hellion.org.uk
Re: ANNOUNCEMENT: Intel/AMD x86 CPU microcode update system in non-free
Henrique de Moraes Holschuh h...@debian.org writes: # iucode_tool --scan-system -vv iucode_tool: cpuid kernel driver unavailable, cannot scan system processor signatures Hmm, that should happen only if iucode-tool is installed/configured after intel-microcode. I've seen this message too, during the update-initramfs call. Best, -Nikolaus -- »Time flies like an arrow, fruit flies like a Banana.« PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y5idedaw@vostro.rath.org
Re: ANNOUNCEMENT: Intel/AMD x86 CPU microcode update system in non-free
On Wed, 07 Nov 2012, Nikolaus Rath wrote: Henrique de Moraes Holschuh h...@debian.org writes: # iucode_tool --scan-system -vv iucode_tool: cpuid kernel driver unavailable, cannot scan system processor signatures Hmm, that should happen only if iucode-tool is installed/configured after intel-microcode. I've seen this message too, during the update-initramfs call. The initramfs hook does try to load the cpuid module before it runs iucode_tool. If it didn't load, the problem lies elsewhere. -- 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-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121107145749.ga...@khazad-dum.debian.net
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=0x0257 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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/509a92e8.5000...@gmail.com
Re: ANNOUNCEMENT: Intel/AMD x86 CPU microcode update system in non-free
On Wed, 07 Nov 2012, Adrian Fita wrote: 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? I don't think we can do that, because the -microcode packages are in non-free. And an annoying technical detail makes it suboptimal to add the microcode packages as a recommendation of the firmware-linux-nonfree package. -- 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-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121107183300.ga6...@khazad-dum.debian.net
Re: ANNOUNCEMENT: Intel/AMD x86 CPU microcode update system in non-free
On Wed, Nov 07, 2012 at 04:33:00PM -0200, Henrique de Moraes Holschuh wrote: On Wed, 07 Nov 2012, Adrian Fita wrote: 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? I don't think we can do that, because the -microcode packages are in non-free. And an annoying technical detail makes it suboptimal to add the microcode packages as a recommendation of the firmware-linux-nonfree package. ...which is that dpkg does not support architecture-specific relations in binary packages. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121107234437.go13...@decadent.org.uk
Re: ANNOUNCEMENT: Intel/AMD x86 CPU microcode update system in non-free
On 08/11/12 01:44, Ben Hutchings wrote: On Wed, Nov 07, 2012 at 04:33:00PM -0200, Henrique de Moraes Holschuh wrote: On Wed, 07 Nov 2012, Adrian Fita wrote: 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? I don't think we can do that, because the -microcode packages are in non-free. And an annoying technical detail makes it suboptimal to add the microcode packages as a recommendation of the firmware-linux-nonfree package. ...which is that dpkg does not support architecture-specific relations in binary packages. Sorry if I don't understand what you're talking about... I was thinking about adding the *microcode to the recommends/suggests for the x86/amd64 kernel packages only (here's some of the packages that my system lists for these architecures: linux-image-486, linux-image-686, linux-image-686-pae, linux-image-amd64, linux-image-rt-686-pae). I don't think this needs any kind of special architecture-specific support in dpkg... -- Adrian Fita -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/509afe43.9070...@gmail.com
Re: ANNOUNCEMENT: Intel/AMD x86 CPU microcode update system in non-free
On Thu, 2012-11-08 at 02:35 +0200, Adrian Fita wrote: On 08/11/12 01:44, Ben Hutchings wrote: On Wed, Nov 07, 2012 at 04:33:00PM -0200, Henrique de Moraes Holschuh wrote: On Wed, 07 Nov 2012, Adrian Fita wrote: 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? I don't think we can do that, because the -microcode packages are in non-free. And an annoying technical detail makes it suboptimal to add the microcode packages as a recommendation of the firmware-linux-nonfree package. ...which is that dpkg does not support architecture-specific relations in binary packages. Sorry if I don't understand what you're talking about... I was expanding on Henrique's second point. I was thinking about adding the *microcode to the recommends/suggests for the x86/amd64 kernel packages only (here's some of the packages that my system lists for these architecures: linux-image-486, linux-image-686, linux-image-686-pae, linux-image-amd64, linux-image-rt-686-pae). I don't think this needs any kind of special architecture-specific support in dpkg... http://www.debian.org/doc/debian-policy/ch-archive.html#s-main ... packages in main ... must not require or recommend a package outside of main for compilation or execution Ben. -- Ben Hutchings The program is absolutely right; therefore, the computer must be wrong. signature.asc Description: This is a digitally signed message part
Re: ANNOUNCEMENT: Intel/AMD x86 CPU microcode update system in non-free
On 06/11/12 17:05, Henrique de Moraes Holschuh wrote: Still, it did lead me to a possible cause: I am not trying to modprobe microcode in the intel-microcode postinst. This can indeed cause the failure to update microcode at package install time. I forget why I didn't do it that way in the first place, but that's easily fixed. Please file a bug, severity minor. I will check for any possible problems it might cause, and if I can't find any, I will fix it in unstable. Same here. Just installed intel-microcode and iucode-tool and it didn't worked until I manually modprobed the microcode module. Just wondering... Perhaps you should add a file in /etc/modules.d/ to automatically load the microcode module at start-up? Thanks a lot for this! I didn't know about this packages, look great! signature.asc Description: OpenPGP digital signature
Re: ANNOUNCEMENT: Intel/AMD x86 CPU microcode update system in non-free
On Mon, Nov 05, 2012 at 06:12:53PM -0200, Henrique de Moraes Holschuh wrote: Microcode updates will be applied immediately when the microcode packages are installed or updated: you don't have to reboot. You will have to keep the packages installed, though: as explained above, the microcode updates have to be reapplied at every boot. You can check which version of the microcode your processors are running by looking for microcode lines on /proc/cpuinfo. This information is only available on recent kernels (such as the Wheezy kernel). This did not appear to work for me automatically. I did not upgrade my kernel in the same aptitude session. Before: $ grep microcode /proc/cpuinfo microcode : 0x1b After installing intel-microcode and iucode-tool 0.8.3-1: $ grep microcode /proc/cpuinfo microcode : 0x1b After some manual fiddling # iucode_tool --scan-system -vv iucode_tool: cpuid kernel driver unavailable, cannot scan system processor signatures # modprobe cpuid # iucode_tool --scan-system -vv iucode_tool: trying to get CPUID information from /dev/cpu/0/cpuid iucode_tool: system has processor(s) with signature 0x000206a7 iucode_tool: trying to get CPUID information from /dev/cpu/1/cpuid iucode_tool: trying to get CPUID information from /dev/cpu/2/cpuid iucode_tool: trying to get CPUID information from /dev/cpu/3/cpuid iucode_tool: checked the signature of 4 processor(s) $ grep microcode /proc/cpuinfo microcode : 0x28 $ dpkg -S /boot/vmlinuz-$(uname -r) linux-image-3.2.0-4-amd64: /boot/vmlinuz-3.2.0-4-amd64 ii udev 175-7amd64/dev/ and hotplug management daem Shall I file a bug? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121106143209.GB17743@debian
Re: ANNOUNCEMENT: Intel/AMD x86 CPU microcode update system in non-free
On Mon, Nov 05, 2012 at 06:12:53PM -0200, Henrique de Moraes Holschuh wrote: I would like to bring to your attention the improved support for system processor (CPU) microcode updates, for x86/i686/x86-64/amd64 systems that was recently added to [non-free] Wheezy. Alas, this will not work for XEN users because I can’t update the microcode in Dom0 with xen-hypervisor 4.1. There exist kernel patches (over a year old), but according to the xen-devel ML they are not good enough to be included in the kernel. With XEN 4.2 the hypervisor can load the CPU microcode. Would this be a reason to include XEN 4.2 in Wheezy? Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: ANNOUNCEMENT: Intel/AMD x86 CPU microcode update system in non-free
On Tue, 06 Nov 2012, Jon Dowland wrote: On Mon, Nov 05, 2012 at 06:12:53PM -0200, Henrique de Moraes Holschuh wrote: Microcode updates will be applied immediately when the microcode packages are installed or updated: you don't have to reboot. You will have to keep the packages installed, though: as explained above, the microcode updates have to be reapplied at every boot. You can check which version of the microcode your processors are running by looking for microcode lines on /proc/cpuinfo. This information is only available on recent kernels (such as the Wheezy kernel). This did not appear to work for me automatically. I did not upgrade my kernel in the same aptitude session. That can also happen if you upgrade it in a previous aptitude session, but didn't reboot yet. Before: microcode : 0x1b After installing intel-microcode and iucode-tool 0.8.3-1: microcode : 0x1b # iucode_tool --scan-system -vv iucode_tool: cpuid kernel driver unavailable, cannot scan system processor signatures Hmm, that should happen only if iucode-tool is installed/configured after intel-microcode. Still, it did lead me to a possible cause: I am not trying to modprobe microcode in the intel-microcode postinst. This can indeed cause the failure to update microcode at package install time. I forget why I didn't do it that way in the first place, but that's easily fixed. Please file a bug, severity minor. I will check for any possible problems it might cause, and if I can't find any, I will fix it in unstable. Still, those reports are very valuable. I will probably try to get some information about the microcode updates on the Wheezy release notes, and this thread will go a long way to make sure no pitfals are left behind. $ grep microcode /proc/cpuinfo microcode : 0x28 And that's why these packages exist... although you might want to check if your motherboard vendor has a BIOS/UEFI update available, as it is _always_ better to have microcode updated as early as possible, and that means the BIOS/UEFI. Shall I file a bug? Please do. -- 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-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121106160553.ga25...@khazad-dum.debian.net
Re: ANNOUNCEMENT: Intel/AMD x86 CPU microcode update system in non-free
On Tue, 06 Nov 2012, Stephan Seitz wrote: On Mon, Nov 05, 2012 at 06:12:53PM -0200, Henrique de Moraes Holschuh wrote: I would like to bring to your attention the improved support for system processor (CPU) microcode updates, for x86/i686/x86-64/amd64 systems that was recently added to [non-free] Wheezy. Alas, this will not work for XEN users because I can’t update the microcode in Dom0 with xen-hypervisor 4.1. There exist kernel patches (over a year old), but according to the xen-devel ML they are not good enough to be included in the kernel. With XEN 4.2 the hypervisor can load the CPU microcode. Would this be a reason to include XEN 4.2 in Wheezy? I wouldn't know, please ask the xen maintainers and the release manager about it. Maybe a backport of the relevant functionality is also a possible solution. What I do know is that lack of microcode update support is a severe issue IMO. -- 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-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121106160840.gb25...@khazad-dum.debian.net
Re: ANNOUNCEMENT: Intel/AMD x86 CPU microcode update system in non-free
On 05/11/12 22:12, Henrique de Moraes Holschuh wrote: Hello all, I would like to bring to your attention the improved support for system processor (CPU) microcode updates, for x86/i686/x86-64/amd64 systems that was recently added to [non-free] Wheezy. System Processors from Intel and AMD may need updates to their microcode (sort of a control sequence for the processor) to operate correctly. These updates fix bugs/errata that can cause anything from incorrect processing, to code and data corruption, and system lockups. [...] You can check which version of the microcode your processors are running by looking for microcode lines on /proc/cpuinfo. This information is only available on recent kernels (such as the Wheezy kernel). Hello. 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 module gets loaded regardless of the fact that my CPU doesn't need it. This leads to the following message being shown at boot, taining the boot process messages (basicaly it uglifies the boot process :D): microcode: failed to load file amd-ucode/microcode_amd.bin 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 don't exactly know how this should be done, but seeing that the microcode.ko belongs to the linux-image package, maybe there should be some script that runs when the package is installed that checks if the CPU needs a microcode update, and if it doesn't it should blacklist the module. -- Adrian Fita -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5099a17f.7010...@gmail.com
Re: ANNOUNCEMENT: Intel/AMD x86 CPU microcode update system in non-free
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). 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? 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. -- 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-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121107005052.gb5...@khazad-dum.debian.net
