* Linux* Processor Microcode Data File @ 2009-03-09 9:43 Dragoslav Zaric 2009-03-09 10:00 ` Jike Song ` (2 more replies) 0 siblings, 3 replies; 18+ messages in thread From: Dragoslav Zaric @ 2009-03-09 9:43 UTC (permalink / raw) To: LKML Hello, I was browsing Intel web site for my processor docs and I bumped on download link "Linux* Processor Microcode Data File" and it says there: "The microcode data file contains the latest microcode definitions for all Intel processors. Intel releases microcode updates to correct processor behavior as documented in the respective processor specification updates. While the regular approach to getting this microcode update is via a BIOS upgrade, Intel realizes that this can be an administrative hassle. The Linux Operating System and VMware ESX products have a mechanism to update the microcode after booting. For example, this file will be used by the operating system mechanism if the file is placed in the /etc/firmware directory of the Linux system." So, does new kernel versions just copy this microcode update file in /etc/firmware folder or new instructions are replaced in assembly code ? greet ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Linux* Processor Microcode Data File 2009-03-09 9:43 Linux* Processor Microcode Data File Dragoslav Zaric @ 2009-03-09 10:00 ` Jike Song 2009-03-09 10:30 ` Andreas Herrmann 2009-03-09 14:16 ` Sitsofe Wheeler 2009-03-09 14:27 ` Arjan van de Ven 2 siblings, 1 reply; 18+ messages in thread From: Jike Song @ 2009-03-09 10:00 UTC (permalink / raw) To: Dragoslav Zaric; +Cc: LKML On Mon, Mar 9, 2009 at 5:43 PM, Dragoslav Zaric <dragoslav.zaric.kd@gmail.com> wrote: > Hello, > > I was browsing Intel web site for my processor docs and I bumped > on download link "Linux* Processor Microcode Data File" and it says > there: > > "The microcode data file contains the latest microcode definitions for > all Intel processors. > Intel releases microcode updates to correct processor behavior as > documented in the respective > processor specification updates. While the regular approach to getting > this microcode update is via > a BIOS upgrade, Intel realizes that this can be an administrative > hassle. The Linux Operating System > and VMware ESX products have a mechanism to update the microcode after > booting. For example, > this file will be used by the operating system mechanism if the file > is placed in the /etc/firmware > directory of the Linux system." > > So, does new kernel versions just copy this microcode update file in > /etc/firmware folder or new > instructions are replaced in assembly code ? > Linux provides an microcode driver for Intel & AMD CPUs: arch/x86/kernel/microcode_* and there is a service called "microcode_ctl" to open it and write the microcode on every starting. Where to find the microcode data is this service specified, and the kernel doesn't care it. You may want to find: http://www.urbanmyth.org/microcode/ > new instructions are replaced in assembly code ? As far as I can tell, no. The microcode only only change the CPU's behavior, not the assembler. -- Thanks, Jike ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Linux* Processor Microcode Data File 2009-03-09 10:00 ` Jike Song @ 2009-03-09 10:30 ` Andreas Herrmann 0 siblings, 0 replies; 18+ messages in thread From: Andreas Herrmann @ 2009-03-09 10:30 UTC (permalink / raw) To: Jike Song; +Cc: Dragoslav Zaric, LKML On Mon, Mar 09, 2009 at 06:00:35PM +0800, Jike Song wrote: > On Mon, Mar 9, 2009 at 5:43 PM, Dragoslav Zaric > <dragoslav.zaric.kd@gmail.com> wrote: > > Hello, > > > > I was browsing Intel web site for my processor docs and I bumped > > on download link "Linux* Processor Microcode Data File" and it says > > there: > > > > "The microcode data file contains the latest microcode definitions for > > all Intel processors. > > Intel releases microcode updates to correct processor behavior as > > documented in the respective > > processor specification updates. While the regular approach to getting > > this microcode update is via > > a BIOS upgrade, Intel realizes that this can be an administrative > > hassle. The Linux Operating System > > and VMware ESX products have a mechanism to update the microcode after > > booting. For example, > > this file will be used by the operating system mechanism if the file > > is placed in the /etc/firmware > > directory of the Linux system." > > > > So, does new kernel versions just copy this microcode update file in > > /etc/firmware folder or new > > instructions are replaced in assembly code ? > > > > Linux provides an microcode driver for Intel & AMD CPUs: > > arch/x86/kernel/microcode_* > > and there is a service called "microcode_ctl" to open it and write the > microcode on every starting. Where to find the microcode data is > this service specified, and the kernel doesn't care it. You may want > to find: > http://www.urbanmyth.org/microcode/ FYI, microcode patch loading for AMD CPUs uses only the firmware loader interface. The patches for AMD CPUs are available from http://www.amd64.org/support/microcode.html Regards, Andreas -- Operating | Advanced Micro Devices GmbH System | Karl-Hammerschmidt-Str. 34, 85609 Dornach b. München, Germany Research | Geschäftsführer: Jochen Polster, Thomas M. McCoy, Giuliano Meroni Center | Sitz: Dornach, Gemeinde Aschheim, Landkreis München (OSRC) | Registergericht München, HRB Nr. 43632 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Linux* Processor Microcode Data File 2009-03-09 9:43 Linux* Processor Microcode Data File Dragoslav Zaric 2009-03-09 10:00 ` Jike Song @ 2009-03-09 14:16 ` Sitsofe Wheeler 2009-03-09 15:11 ` Arjan van de Ven 2009-03-09 14:27 ` Arjan van de Ven 2 siblings, 1 reply; 18+ messages in thread From: Sitsofe Wheeler @ 2009-03-09 14:16 UTC (permalink / raw) To: Dragoslav Zaric; +Cc: LKML On Mon, Mar 09, 2009 at 10:43:57AM +0100, Dragoslav Zaric wrote: > So, does new kernel versions just copy this microcode update file in > /etc/firmware folder or new > instructions are replaced in assembly code ? The kernel doesn't load microcode automatically but it can provide a device to allow userspace to trigger a microcode update (via /dev/cpu/microcode ). On boot the patching process is normally started by an initscript. See http://www.urbanmyth.org/microcode/ for details. -- Sitsofe | http://sucs.org/~sits/ ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Linux* Processor Microcode Data File 2009-03-09 14:16 ` Sitsofe Wheeler @ 2009-03-09 15:11 ` Arjan van de Ven 2009-03-09 15:34 ` Sitsofe Wheeler 0 siblings, 1 reply; 18+ messages in thread From: Arjan van de Ven @ 2009-03-09 15:11 UTC (permalink / raw) To: Sitsofe Wheeler; +Cc: Dragoslav Zaric, LKML On Mon, 9 Mar 2009 14:16:55 +0000 Sitsofe Wheeler <sitsofe@yahoo.com> wrote: > On Mon, Mar 09, 2009 at 10:43:57AM +0100, Dragoslav Zaric wrote: > > > So, does new kernel versions just copy this microcode update file in > > /etc/firmware folder or new > > instructions are replaced in assembly code ? > > The kernel doesn't load microcode automatically it does if you have the right format; the kernel uses request_firmware() for this. The microcode on the intel website is not ready for this yet, but we're working hard to have future drops to be in the new format. -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Linux* Processor Microcode Data File 2009-03-09 15:11 ` Arjan van de Ven @ 2009-03-09 15:34 ` Sitsofe Wheeler 2009-03-09 15:58 ` Gene Heskett 2009-03-09 16:53 ` Arjan van de Ven 0 siblings, 2 replies; 18+ messages in thread From: Sitsofe Wheeler @ 2009-03-09 15:34 UTC (permalink / raw) To: Arjan van de Ven; +Cc: Dragoslav Zaric, LKML On Mon, Mar 09, 2009 at 08:11:09AM -0700, Arjan van de Ven wrote: > On Mon, 9 Mar 2009 14:16:55 +0000 > Sitsofe Wheeler <sitsofe@yahoo.com> wrote: > > > The kernel doesn't load microcode automatically > > it does if you have the right format; the kernel uses > request_firmware() for this. > The microcode on the intel website is not ready for this yet, but we're > working hard to have future drops to be in the new format. Wow so I was redundant AND wrong in the same email! What motivated the switch to the generic request_firmware interface? Is it just less messy/faster than previous methods? Additionally while I remember, is it worth updating the microcode on all machines? At present I have an EeePC 900 and it's unclear if it would benefit from a microcode update (but there's a definite cost to running the current initscript at boot). -- Sitsofe | http://sucs.org/~sits/ ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Linux* Processor Microcode Data File 2009-03-09 15:34 ` Sitsofe Wheeler @ 2009-03-09 15:58 ` Gene Heskett 2009-03-09 16:24 ` Sitsofe Wheeler 2009-03-09 16:53 ` Arjan van de Ven 1 sibling, 1 reply; 18+ messages in thread From: Gene Heskett @ 2009-03-09 15:58 UTC (permalink / raw) To: Sitsofe Wheeler; +Cc: Arjan van de Ven, Dragoslav Zaric, LKML, tigran On Monday 09 March 2009, Sitsofe Wheeler wrote: >On Mon, Mar 09, 2009 at 08:11:09AM -0700, Arjan van de Ven wrote: >> On Mon, 9 Mar 2009 14:16:55 +0000 >> >> Sitsofe Wheeler <sitsofe@yahoo.com> wrote: >> > The kernel doesn't load microcode automatically >> >> it does if you have the right format; the kernel uses >> request_firmware() for this. >> The microcode on the intel website is not ready for this yet, but we're >> working hard to have future drops to be in the new format. > >Wow so I was redundant AND wrong in the same email! > >What motivated the switch to the generic request_firmware interface? Is >it just less messy/faster than previous methods? > >Additionally while I remember, is it worth updating the microcode on all >machines? At present I have an EeePC 900 and it's unclear if it would >benefit from a microcode update (but there's a definite cost to running >the current initscript at boot). Slight hijack of thread here, but... I'll have to admit it was with some trepidation that I might brick my processor, which is a quad core AMD 9550, stepping 03 running at 2.2 ghz, but the directions didn't note until the end, that it would take a 2.6.29 series kernel to do it and I was running 2.6.28.7. But when I got to the modprobe -r microcode, modprobe microcode part, there was no feedback from either command. So did I, or did I not do this as I was and am running 2.6.28.7? The following was reported in my log: Mar 9 07:22:04 coyote kernel: [65725.810333] microcode: collect_cpu_info_amd : patch_id=0x1000065 Mar 9 07:22:04 coyote kernel: [65725.810338] platform microcode: firmware: requesting amd-ucode/microcode_amd.bin Mar 9 07:22:04 coyote kernel: [65725.847258] microcode: size 1936, total_size 960 Mar 9 07:22:04 coyote kernel: [65725.847265] microcode: CPU0 patch does not match (processor_rev_id: 1020, eqiv_cpu_id: 1022) Mar 9 07:22:04 coyote kernel: [65725.847269] microcode: size 968, total_size 960 Mar 9 07:22:04 coyote kernel: [65725.847278] microcode: CPU0 updated from revision 0x1000065 to 0x1000083 Mar 9 07:22:04 coyote kernel: [65725.847312] microcode: collect_cpu_info_amd : patch_id=0x1000065 Mar 9 07:22:04 coyote kernel: [65725.847317] platform microcode: firmware: requesting amd-ucode/microcode_amd.bin Mar 9 07:22:04 coyote kernel: [65725.851377] microcode: size 1936, total_size 960 Mar 9 07:22:04 coyote kernel: [65725.851390] microcode: CPU1 patch does not match (processor_rev_id: 1020, eqiv_cpu_id: 1022) Mar 9 07:22:04 coyote kernel: [65725.851393] microcode: size 968, total_size 960 Mar 9 07:22:04 coyote kernel: [65725.851403] microcode: CPU1 updated from revision 0x1000065 to 0x1000083 Mar 9 07:22:04 coyote kernel: [65725.851421] microcode: collect_cpu_info_amd : patch_id=0x1000065 Mar 9 07:22:04 coyote kernel: [65725.851426] platform microcode: firmware: requesting amd-ucode/microcode_amd.bin Mar 9 07:22:04 coyote kernel: [65725.855323] microcode: size 1936, total_size 960 Mar 9 07:22:04 coyote kernel: [65725.855330] microcode: CPU2 patch does not match (processor_rev_id: 1020, eqiv_cpu_id: 1022) Mar 9 07:22:04 coyote kernel: [65725.855333] microcode: size 968, total_size 960 Mar 9 07:22:04 coyote kernel: [65725.855344] microcode: CPU2 updated from revision 0x1000065 to 0x1000083 Mar 9 07:22:04 coyote kernel: [65725.855361] microcode: collect_cpu_info_amd : patch_id=0x1000065 Mar 9 07:22:04 coyote kernel: [65725.855365] platform microcode: firmware: requesting amd-ucode/microcode_amd.bin Mar 9 07:22:04 coyote kernel: [65725.863101] microcode: size 1936, total_size 960 Mar 9 07:22:04 coyote kernel: [65725.863107] microcode: CPU3 patch does not match (processor_rev_id: 1020, eqiv_cpu_id: 1022) Mar 9 07:22:04 coyote kernel: [65725.863110] microcode: size 968, total_size 960 Mar 9 07:22:04 coyote kernel: [65725.863120] microcode: CPU3 updated from revision 0x1000065 to 0x1000083 Mar 9 07:22:04 coyote kernel: [65725.863122] Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba Inquiring minds and all that. Comments please? -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) "I have five dollars for each of you." -- Bernhard Goetz ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Linux* Processor Microcode Data File 2009-03-09 15:58 ` Gene Heskett @ 2009-03-09 16:24 ` Sitsofe Wheeler 2009-03-09 17:03 ` Gene Heskett 2009-03-09 17:57 ` Andreas Herrmann 0 siblings, 2 replies; 18+ messages in thread From: Sitsofe Wheeler @ 2009-03-09 16:24 UTC (permalink / raw) To: Gene Heskett Cc: Arjan van de Ven, Dragoslav Zaric, LKML, tigran, Andreas Herrmann At the risk of being wrong twice in a row... On Mon, Mar 09, 2009 at 11:58:22AM -0400, Gene Heskett wrote: > I'll have to admit it was with some trepidation that I might brick my > processor, which is a quad core AMD 9550, stepping 03 running at 2.2 ghz, but Microcode patching in this particular fashion (i.e. _not_ updating the BIOS but "on the fly") is volatile (so it has to be redone at every boot) which should mean it is very hard to brick a machine this way as rebooting will undo everything. Of course someone is going to tell me how they managed to kill a machine stone dead due to some sequence of events I hadn't thought of and I disclaim any responsiblity if someone tries to update their microcode and harms their machine in any fashion - you update at your own risk :). > the directions didn't note until the end, that it would take a 2.6.29 series > kernel to do it and I was running 2.6.28.7. But when I got to the > modprobe -r microcode, modprobe microcode part, there was no feedback from > either command. So did I, or did I not do this as I was and am running > 2.6.28.7? The following was reported in my log: modprobe generally doesn't return much if the module in question loads or (as in this case because you were using -r) is removed. That's the typical Unix command line behviour - no response/output on "OK". > Mar 9 07:22:04 coyote kernel: [65725.855365] platform microcode: firmware: requesting amd-ucode/microcode_amd.bin > Mar 9 07:22:04 coyote kernel: [65725.863101] microcode: size 1936, total_size 960 > Mar 9 07:22:04 coyote kernel: [65725.863107] microcode: CPU3 patch does not match (processor_rev_id: 1020, eqiv_cpu_id: 1022) > Mar 9 07:22:04 coyote kernel: [65725.863110] microcode: size 968, total_size 960 > Mar 9 07:22:04 coyote kernel: [65725.863120] microcode: CPU3 updated from revision 0x1000065 to 0x1000083 > Mar 9 07:22:04 coyote kernel: [65725.863122] Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba > > Inquiring minds and all that. Comments please? It looks like the firmware file (amd-ucode/microcode_amd.bin) doesn't match your processor. CC'ing Andreas for comment as you have an AMD machine... -- Sitsofe | http://sucs.org/~sits/ ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Linux* Processor Microcode Data File 2009-03-09 16:24 ` Sitsofe Wheeler @ 2009-03-09 17:03 ` Gene Heskett 2009-03-09 17:57 ` Andreas Herrmann 1 sibling, 0 replies; 18+ messages in thread From: Gene Heskett @ 2009-03-09 17:03 UTC (permalink / raw) To: Sitsofe Wheeler Cc: Arjan van de Ven, Dragoslav Zaric, LKML, tigran, Andreas Herrmann On Monday 09 March 2009, Sitsofe Wheeler wrote: >At the risk of being wrong twice in a row... > >On Mon, Mar 09, 2009 at 11:58:22AM -0400, Gene Heskett wrote: >> I'll have to admit it was with some trepidation that I might brick my >> processor, which is a quad core AMD 9550, stepping 03 running at 2.2 ghz, >> but > >Microcode patching in this particular fashion (i.e. _not_ updating the >BIOS but "on the fly") is volatile (so it has to be redone at every >boot) which should mean it is very hard to brick a machine this way as >rebooting will undo everything. Of course someone is going to tell me >how they managed to kill a machine stone dead due to some sequence of >events I hadn't thought of and I disclaim any responsiblity if someone >tries to update their microcode and harms their machine in any fashion - >you update at your own risk :). > >> the directions didn't note until the end, that it would take a 2.6.29 >> series kernel to do it and I was running 2.6.28.7. But when I got to the >> modprobe -r microcode, modprobe microcode part, there was no feedback from >> either command. So did I, or did I not do this as I was and am running >> 2.6.28.7? The following was reported in my log: > >modprobe generally doesn't return much if the module in question loads >or (as in this case because you were using -r) is removed. That's the >typical Unix command line behviour - no response/output on "OK". > >> Mar 9 07:22:04 coyote kernel: [65725.855365] platform microcode: >> firmware: requesting amd-ucode/microcode_amd.bin Mar 9 07:22:04 coyote >> kernel: [65725.863101] microcode: size 1936, total_size 960 Mar 9 >> 07:22:04 coyote kernel: [65725.863107] microcode: CPU3 patch does not >> match (processor_rev_id: 1020, eqiv_cpu_id: 1022) Mar 9 07:22:04 coyote >> kernel: [65725.863110] microcode: size 968, total_size 960 Mar 9 07:22:04 >> coyote kernel: [65725.863120] microcode: CPU3 updated from revision >> 0x1000065 to 0x1000083 Mar 9 07:22:04 coyote kernel: [65725.863122] >> Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba >> >> Inquiring minds and all that. Comments please? > >It looks like the firmware file (amd-ucode/microcode_amd.bin) doesn't >match your processor. CC'ing Andreas for comment as you have an AMD >machine... Thank You. But the text report above also says it did update it, hence the confusion. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) For fast-acting relief, try slowing down. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Linux* Processor Microcode Data File 2009-03-09 16:24 ` Sitsofe Wheeler 2009-03-09 17:03 ` Gene Heskett @ 2009-03-09 17:57 ` Andreas Herrmann 1 sibling, 0 replies; 18+ messages in thread From: Andreas Herrmann @ 2009-03-09 17:57 UTC (permalink / raw) To: Sitsofe Wheeler Cc: Gene Heskett, Arjan van de Ven, Dragoslav Zaric, LKML, tigran On Mon, Mar 09, 2009 at 04:24:16PM +0000, Sitsofe Wheeler wrote: > On Mon, Mar 09, 2009 at 11:58:22AM -0400, Gene Heskett wrote: > > Mar 9 07:22:04 coyote kernel: [65725.855365] platform microcode: firmware: requesting amd-ucode/microcode_amd.bin ... > > Mar 9 07:22:04 coyote kernel: [65725.863107] microcode: CPU3 patch > > does not match (processor_rev_id: 1020, eqiv_cpu_id: 1022) is > > printed. This line should better be a debug message. There can be several ucode-patches in amd-ucode/microcode_amd.bin. The kernel code checks whether those patches match the CPU revision and if a patch doesn't match, one such a line shows up. (which is ... obfuscating) I'll fix this asap in mainline, but IMHO it's not worth to fix this in .28. > > Mar 9 07:22:04 coyote kernel: [65725.863120] microcode: CPU3 > > updated from revision 0x1000065 to 0x1000083 Finally CPU microcode was updated as this message is indicating. Regards, Andreas PS: You can check the microcode patch level of your AMD family 10h and 11h CPU by reading MSR 0x0000008b. E.g. using lsmsr from x86info package shows # lsmsr -r 0x0000008b -c 0 PATCH_LEVEL = 0x0000000001000065 -- Operating | Advanced Micro Devices GmbH System | Karl-Hammerschmidt-Str. 34, 85609 Dornach b. München, Germany Research | Geschäftsführer: Jochen Polster, Thomas M. McCoy, Giuliano Meroni Center | Sitz: Dornach, Gemeinde Aschheim, Landkreis München (OSRC) | Registergericht München, HRB Nr. 43632 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Linux* Processor Microcode Data File 2009-03-09 15:34 ` Sitsofe Wheeler 2009-03-09 15:58 ` Gene Heskett @ 2009-03-09 16:53 ` Arjan van de Ven 2009-03-12 10:03 ` Giacomo A. Catenazzi 1 sibling, 1 reply; 18+ messages in thread From: Arjan van de Ven @ 2009-03-09 16:53 UTC (permalink / raw) To: Sitsofe Wheeler; +Cc: Dragoslav Zaric, LKML On Mon, 9 Mar 2009 15:34:50 +0000 Sitsofe Wheeler <sitsofe@yahoo.com> wrote: > On Mon, Mar 09, 2009 at 08:11:09AM -0700, Arjan van de Ven wrote: > > On Mon, 9 Mar 2009 14:16:55 +0000 > > Sitsofe Wheeler <sitsofe@yahoo.com> wrote: > > > > > The kernel doesn't load microcode automatically > > > > it does if you have the right format; the kernel uses > > request_firmware() for this. > > The microcode on the intel website is not ready for this yet, but > > we're working hard to have future drops to be in the new format. > > Wow so I was redundant AND wrong in the same email! > > What motivated the switch to the generic request_firmware interface? > Is it just less messy/faster than previous methods? 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 -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Linux* Processor Microcode Data File 2009-03-09 16:53 ` Arjan van de Ven @ 2009-03-12 10:03 ` Giacomo A. Catenazzi 2009-03-12 14:07 ` Arjan van de Ven 2009-03-12 14:53 ` Dragoslav Zaric 0 siblings, 2 replies; 18+ messages in thread From: Giacomo A. Catenazzi @ 2009-03-12 10:03 UTC (permalink / raw) To: Arjan van de Ven; +Cc: Sitsofe Wheeler, Dragoslav Zaric, LKML Arjan van de Ven wrote: > On Mon, 9 Mar 2009 15:34:50 +0000 > Sitsofe Wheeler <sitsofe@yahoo.com> wrote: > >> On Mon, Mar 09, 2009 at 08:11:09AM -0700, Arjan van de Ven wrote: >>> On Mon, 9 Mar 2009 14:16:55 +0000 >>> Sitsofe Wheeler <sitsofe@yahoo.com> wrote: >>> >>>> The kernel doesn't load microcode automatically >>> it does if you have the right format; the kernel uses >>> request_firmware() for this. >>> The microcode on the intel website is not ready for this yet, but >>> we're working hard to have future drops to be in the new format. >> Wow so I was redundant AND wrong in the same email! >> >> What motivated the switch to the generic request_firmware interface? >> Is it just less messy/faster than previous methods? > > 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. BTW: why do we have microcode loading modular? Offtopic: IMHO if we could move the load of firmware before booting linux, it would be nicer and cleaner (by open source point of view). ciao cate ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Linux* Processor Microcode Data File 2009-03-12 10:03 ` Giacomo A. Catenazzi @ 2009-03-12 14:07 ` Arjan van de Ven 2009-03-13 8:37 ` Giacomo A. Catenazzi [not found] ` <2d05c4580903130142o2e5ebbcfw1e35eb52ea48e4b1@mail.gmail.com> 2009-03-12 14:53 ` Dragoslav Zaric 1 sibling, 2 replies; 18+ messages in thread From: Arjan van de Ven @ 2009-03-12 14:07 UTC (permalink / raw) To: Giacomo A. Catenazzi; +Cc: Sitsofe Wheeler, Dragoslav Zaric, LKML On Thu, 12 Mar 2009 11:03:11 +0100 "Giacomo A. Catenazzi" <cate@cateee.net> 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 ? > BTW: why do we have microcode loading modular? only the legacy initscript part is modular afaik. -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Linux* Processor Microcode Data File 2009-03-12 14:07 ` Arjan van de Ven @ 2009-03-13 8:37 ` Giacomo A. Catenazzi [not found] ` <2d05c4580903130142o2e5ebbcfw1e35eb52ea48e4b1@mail.gmail.com> 1 sibling, 0 replies; 18+ messages in thread From: Giacomo A. Catenazzi @ 2009-03-13 8:37 UTC (permalink / raw) To: Arjan van de Ven; +Cc: LKML Arjan van de Ven wrote: > On Thu, 12 Mar 2009 11:03:11 +0100 > "Giacomo A. Catenazzi" <cate@cateee.net> 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
[parent not found: <2d05c4580903130142o2e5ebbcfw1e35eb52ea48e4b1@mail.gmail.com>]
* Linux* Processor Microcode Data File [not found] ` <2d05c4580903130142o2e5ebbcfw1e35eb52ea48e4b1@mail.gmail.com> @ 2009-03-13 8:44 ` Dragoslav Zaric 2009-03-13 14:55 ` Gene Heskett 0 siblings, 1 reply; 18+ messages in thread From: Dragoslav Zaric @ 2009-03-13 8:44 UTC (permalink / raw) To: LKML --------------------------------------------- I found this on web site http://kerneltrap.org Tigran Aivazian, author of the IA32 microcode driver and Microcode Update Utility for Linux explained: "The answer to your question is that some Intel CPUs (just like any other hardware or software) contain bugs and, fortunately, their architecture is flexible enough to provide a way to fix those bugs by means of loading the microcode update on the fly, i.e. while the OS is running with no need to reboot (in fact, rebooting or otherwise resetting the CPU causes the update to be lost and requires to run the update again)." --------------------------------------------- So when you reboot system, you reset CPU to original state, and after that you must apply microcode, and this is what is actually doing right now, you put microcode in folder /etc/firmware and after boot microcode is loaded. So I think for CPU hotplug it is also natural that microcode is loaded after plugging, because you can not use microcode from boot process. Maybe kernel should have database of tested microcodes, so when you plug CPU appropriate microcode is loaded. -- Thanks Dragoslav Zaric [Programmer ; M.Sc. in Astrophysics] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Linux* Processor Microcode Data File 2009-03-13 8:44 ` Dragoslav Zaric @ 2009-03-13 14:55 ` Gene Heskett 0 siblings, 0 replies; 18+ messages in thread From: Gene Heskett @ 2009-03-13 14:55 UTC (permalink / raw) To: Dragoslav Zaric; +Cc: LKML On Friday 13 March 2009, Dragoslav Zaric wrote: >--------------------------------------------- >I found this on web site http://kerneltrap.org > >Tigran Aivazian, author of the IA32 microcode driver and Microcode >Update Utility for Linux explained: > >"The answer to your question is that some Intel CPUs (just like any >other hardware or software) contain bugs >and, fortunately, their architecture is flexible enough to provide a >way to fix those bugs by means of loading the >microcode update on the fly, i.e. while the OS is running with no need >to reboot (in fact, rebooting or otherwise >resetting the CPU causes the update to be lost and requires to run the >update again)." And what runs this update? I saw it apply once in the dmesg output, about 3 full powerdown reboots ago, never since, and the code is still there in /lib/firmware AMD quad core 9550 here, stepping 03. Thanks. >--------------------------------------------- > >So when you reboot system, you reset CPU to original state, and after >that you must apply microcode, and this >is what is actually doing right now, you put microcode in folder >/etc/firmware and after boot microcode is loaded. > >So I think for CPU hotplug it is also natural that microcode is loaded >after plugging, because you can not use >microcode from boot process. Maybe kernel should have database of >tested microcodes, so when you plug CPU >appropriate microcode is loaded. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) The only thing that experience teaches us is that experience teaches us nothing. -- Andre Maurois (Emile Herzog) ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Linux* Processor Microcode Data File 2009-03-12 10:03 ` Giacomo A. Catenazzi 2009-03-12 14:07 ` Arjan van de Ven @ 2009-03-12 14:53 ` Dragoslav Zaric 1 sibling, 0 replies; 18+ messages in thread From: Dragoslav Zaric @ 2009-03-12 14:53 UTC (permalink / raw) To: Giacomo A. Catenazzi, LKML I agree with you 100%, and I think that GRUB should do that loading and new kernel version should supply newest and tested microcode. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Linux* Processor Microcode Data File 2009-03-09 9:43 Linux* Processor Microcode Data File Dragoslav Zaric 2009-03-09 10:00 ` Jike Song 2009-03-09 14:16 ` Sitsofe Wheeler @ 2009-03-09 14:27 ` Arjan van de Ven 2 siblings, 0 replies; 18+ messages in thread From: Arjan van de Ven @ 2009-03-09 14:27 UTC (permalink / raw) To: Dragoslav Zaric; +Cc: LKML On Mon, 9 Mar 2009 10:43:57 +0100 Dragoslav Zaric <dragoslav.zaric.kd@gmail.com> wrote: > Hello, > > I was browsing Intel web site for my processor docs and I bumped > on download link "Linux* Processor Microcode Data File" and it says > there: > > "The microcode data file contains the latest microcode definitions for > all Intel processors. > Intel releases microcode updates to correct processor behavior as > documented in the respective > processor specification updates. While the regular approach to getting > this microcode update is via > a BIOS upgrade, Intel realizes that this can be an administrative > hassle. The Linux Operating System > and VMware ESX products have a mechanism to update the microcode after > booting. For example, > this file will be used by the operating system mechanism if the file > is placed in the /etc/firmware > directory of the Linux system." > > So, does new kernel versions just copy this microcode update file in > /etc/firmware folder yup just place it there.... and it'll get picked up. -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2009-03-13 14:56 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-03-09 9:43 Linux* Processor Microcode Data File Dragoslav Zaric 2009-03-09 10:00 ` Jike Song 2009-03-09 10:30 ` Andreas Herrmann 2009-03-09 14:16 ` Sitsofe Wheeler 2009-03-09 15:11 ` Arjan van de Ven 2009-03-09 15:34 ` Sitsofe Wheeler 2009-03-09 15:58 ` Gene Heskett 2009-03-09 16:24 ` Sitsofe Wheeler 2009-03-09 17:03 ` Gene Heskett 2009-03-09 17:57 ` Andreas Herrmann 2009-03-09 16:53 ` Arjan van de Ven 2009-03-12 10:03 ` Giacomo A. Catenazzi 2009-03-12 14:07 ` Arjan van de Ven 2009-03-13 8:37 ` Giacomo A. Catenazzi [not found] ` <2d05c4580903130142o2e5ebbcfw1e35eb52ea48e4b1@mail.gmail.com> 2009-03-13 8:44 ` Dragoslav Zaric 2009-03-13 14:55 ` Gene Heskett 2009-03-12 14:53 ` Dragoslav Zaric 2009-03-09 14:27 ` Arjan van de Ven
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.