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
On Mon, Mar 9, 2009 at 5:43 PM, Dragoslav Zaric
<[email protected]> 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
On Mon, Mar 09, 2009 at 06:00:35PM +0800, Jike Song wrote:
> On Mon, Mar 9, 2009 at 5:43 PM, Dragoslav Zaric
> <[email protected]> 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
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/
On Mon, 9 Mar 2009 14:16:55 +0000
Sitsofe Wheeler <[email protected]> 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
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 <[email protected]> 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/
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 <[email protected]> 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 <[email protected]>, 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
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 <[email protected]>, 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/
On Mon, 9 Mar 2009 10:43:57 +0100
Dragoslav Zaric <[email protected]> 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
On Mon, 9 Mar 2009 15:34:50 +0000
Sitsofe Wheeler <[email protected]> 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 <[email protected]> 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
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 <[email protected]>, 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.
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
Arjan van de Ven wrote:
> On Mon, 9 Mar 2009 15:34:50 +0000
> Sitsofe Wheeler <[email protected]> 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 <[email protected]> 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
I agree with you 100%, and I think that GRUB should do that loading and new
kernel version should supply newest and tested microcode.
On Thu, 12 Mar 2009 11:03:11 +0100
"Giacomo A. Catenazzi" <[email protected]> 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
Arjan van de Ven wrote:
> On Thu, 12 Mar 2009 11:03:11 +0100
> "Giacomo A. Catenazzi" <[email protected]> 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