[gentoo-user] Microcode update AMD

[gentoo-user] Microcode update AMD

[meino.cramer]

Hi,

I have two questions:

 1) Do I have to enable microcode updates in the BIOS of my Crosshair
    IV Formula to activate microcodes push in the CPU by the module
    "microcode" ? (AMD Phenom X6 1090T)

 2) Does anyone know, what these microcodes do? They are fixes for...
    ...what?

 Thank you very much in advance for any help!
 Best regards,
 mcc

Re: [gentoo-user] Microcode update AMD

[BRM]

----- Original Message ----

> I have two questions:
> 
>  1) Do I have to enable microcode  updates in the BIOS of my Crosshair
>     IV Formula to activate  microcodes push in the CPU by the module
>     "microcode" ? (AMD  Phenom X6 1090T)

Not sure about BIOS, but the Linux Kernel you are running will certainly need 
support enabled too.
 
>  2) Does anyone know, what these microcodes do? They are  fixes for...
>     ...what?

The Intel and AMD processors are more abstract than physical now. With i486 and 
earlier the processors were typically hard wired; hardware "bug" fixes could not 
be pushed out.
Intel's Pentium (and I don't know which AMD) started using micro-code to program 
the processor. This enabled them to push out "hardware" bug fixes for the 
processors.

So what happens is the x86 instruction (e.g. mov ax, bx) gets translated to 
micro-code first, then it gets processed, and the result translated back to the 
expected instruction result - essentially, emulating the x86 instruction set in 
the processor. That's the simple version.

So now when they discover a bug in the hardware they can push out a micro-code 
update to either fix the "hardware"  (microcode) bug or work around a hardware 
(physical hardware) bug.

Ben

Re: [gentoo-user] Microcode update AMD

[meino.cramer]

BRM <bm_witness@yahoo.com> [11-01-17 19:16]:
> ----- Original Message ----
> 
> > I have two questions:
> > 
> >  1) Do I have to enable microcode  updates in the BIOS of my Crosshair
> >     IV Formula to activate  microcodes push in the CPU by the module
> >     "microcode" ? (AMD  Phenom X6 1090T)
> 
> Not sure about BIOS, but the Linux Kernel you are running will certainly need 
> support enabled too.
>  
> >  2) Does anyone know, what these microcodes do? They are  fixes for...
> >     ...what?
> 
> The Intel and AMD processors are more abstract than physical now. With i486 and 
> earlier the processors were typically hard wired; hardware "bug" fixes could not 
> be pushed out.
> Intel's Pentium (and I don't know which AMD) started using micro-code to program 
> the processor. This enabled them to push out "hardware" bug fixes for the 
> processors.
> 
> So what happens is the x86 instruction (e.g. mov ax, bx) gets translated to 
> micro-code first, then it gets processed, and the result translated back to the 
> expected instruction result - essentially, emulating the x86 instruction set in 
> the processor. That's the simple version.
> 
> So now when they discover a bug in the hardware they can push out a micro-code 
> update to either fix the "hardware"  (microcode) bug or work around a hardware 
> (physical hardware) bug.
> 
> Ben
> 
> 

Hi Ben,

thanks for your explanation...
I meant: What is fixed the uc-patches? Does "mov" only except "17" as
argument...or... 
I searched AMD for a changelog or something like but I ound nothing...

Best regards,
mcc

Re: [gentoo-user] Microcode update AMD

[Volker Armin Hemmann]

On Monday 17 January 2011 19:34:08 meino.cramer@gmx.de wrote:
> BRM <bm_witness@yahoo.com> [11-01-17 19:16]:
> > ----- Original Message ----
> > 
> > > I have two questions:
> > >  1) Do I have to enable microcode  updates in the BIOS of my
> > >  Crosshair
> > >  
> > >     IV Formula to activate  microcodes push in the CPU by the
> > >     module
> > >     "microcode" ? (AMD  Phenom X6 1090T)
> > 
> > Not sure about BIOS, but the Linux Kernel you are running will certainly
> > need support enabled too.
> > 
> > >  2) Does anyone know, what these microcodes do? They are  fixes
> > >  for...
> > >  
> > >     ...what?
> > 
> > The Intel and AMD processors are more abstract than physical now. With
> > i486 and earlier the processors were typically hard wired; hardware
> > "bug" fixes could not be pushed out.

even the 68000 used microcode...

> > Intel's Pentium (and I don't know which AMD) started using micro-code to
> > program the processor. This enabled them to push out "hardware" bug
> > fixes for the processors

sure that microcode was not introduced to x86 a lot earlier?

> > 
> > So what happens is the x86 instruction (e.g. mov ax, bx) gets translated
> > to micro-code first, then it gets processed, and the result translated
> > back to the expected instruction result - essentially, emulating the
> > x86 instruction set in the processor. That's the simple version.
> > 
> > So now when they discover a bug in the hardware they can push out a
> > micro-code update to either fix the "hardware"  (microcode) bug or work
> > around a hardware (physical hardware) bug.
> > 
> > Ben
> 
> Hi Ben,
> 
> thanks for your explanation...
> I meant: What is fixed the uc-patches? Does "mov" only except "17" as
> argument...or...
> I searched AMD for a changelog or something like but I ound nothing...

they never publish changelogs for microcode.

Re: [gentoo-user] Microcode update AMD

[Mark Knecht]

On Mon, Jan 17, 2011 at 10:10 AM, BRM <bm_witness@yahoo.com> wrote:
> ----- Original Message ----
>
>> I have two questions:
>>
>>  1) Do I have to enable microcode  updates in the BIOS of my Crosshair
>>     IV Formula to activate  microcodes push in the CPU by the module
>>     "microcode" ? (AMD  Phenom X6 1090T)
>
> Not sure about BIOS, but the Linux Kernel you are running will certainly need
> support enabled too.
>
>>  2) Does anyone know, what these microcodes do? They are  fixes for...
>>     ...what?
>
> The Intel and AMD processors are more abstract than physical now. With i486 and
> earlier the processors were typically hard wired; hardware "bug" fixes could not
> be pushed out.
> Intel's Pentium (and I don't know which AMD) started using micro-code to program
> the processor. This enabled them to push out "hardware" bug fixes for the
> processors.
>
> So what happens is the x86 instruction (e.g. mov ax, bx) gets translated to
> micro-code first, then it gets processed, and the result translated back to the
> expected instruction result - essentially, emulating the x86 instruction set in
> the processor. That's the simple version.
>
> So now when they discover a bug in the hardware they can push out a micro-code
> update to either fix the "hardware"  (microcode) bug or work around a hardware
> (physical hardware) bug.
>
> Ben

Ben,
   Do you know how security on these updates is handled? Seems to me
this is an area rife for exploitation so I've been very hesitant to
use them until I understood more.

Cheers,
Mark

Re: [gentoo-user] Microcode update AMD

[Volker Armin Hemmann]

On Monday 17 January 2011 10:48:36 Mark Knecht wrote:
> On Mon, Jan 17, 2011 at 10:10 AM, BRM <bm_witness@yahoo.com> wrote:
> > ----- Original Message ----
> > 
> >> I have two questions:
> >> 
> >>  1) Do I have to enable microcode  updates in the BIOS of my Crosshair
> >>     IV Formula to activate  microcodes push in the CPU by the module
> >>     "microcode" ? (AMD  Phenom X6 1090T)
> > 
> > Not sure about BIOS, but the Linux Kernel you are running will certainly
> > need support enabled too.
> > 
> >>  2) Does anyone know, what these microcodes do? They are  fixes for...
> >>     ...what?
> > 
> > The Intel and AMD processors are more abstract than physical now. With
> > i486 and earlier the processors were typically hard wired; hardware
> > "bug" fixes could not be pushed out.
> > Intel's Pentium (and I don't know which AMD) started using micro-code to
> > program the processor. This enabled them to push out "hardware" bug
> > fixes for the processors.
> > 
> > So what happens is the x86 instruction (e.g. mov ax, bx) gets translated
> > to micro-code first, then it gets processed, and the result translated
> > back to the expected instruction result - essentially, emulating the
> > x86 instruction set in the processor. That's the simple version.
> > 
> > So now when they discover a bug in the hardware they can push out a
> > micro-code update to either fix the "hardware"  (microcode) bug or work
> > around a hardware (physical hardware) bug.
> > 
> > Ben
> 
> Ben,
>    Do you know how security on these updates is handled? Seems to me
> this is an area rife for exploitation so I've been very hesitant to
> use them until I understood more.

you can not not use them because alsmost all bios load the microcode 
automatically.

[gentoo-user] Re: Microcode update AMD

[walt]

On 01/17/2011 11:12 AM, Volker Armin Hemmann wrote:

> alsmost all bios load the microcode automatically.

I've known for years what microcode is and what it does, but the idea
of updating it is a complete surprise to me.

 From where does the bios get the microcode that it loads?

[gentoo-user] Re: Microcode update AMD

[walt]

On 01/19/2011 04:53 PM, walt wrote:
> On 01/17/2011 11:12 AM, Volker Armin Hemmann wrote:
>
>> alsmost all bios load the microcode automatically.
>
> I've known for years what microcode is and what it does, but the idea
> of updating it is a complete surprise to me.
>
>  From where does the bios get the microcode that it loads?

Oops, please disregard.  Your link to flameyes's blog answers my question.

Re: [gentoo-user] Microcode update AMD

[Volker Armin Hemmann]

On Monday 17 January 2011 18:21:48 meino.cramer@gmx.de wrote:
> Hi,
> 
> I have two questions:
> 
>  1) Do I have to enable microcode updates in the BIOS of my Crosshair
>     IV Formula to activate microcodes push in the CPU by the module
>     "microcode" ? (AMD Phenom X6 1090T)
> 

you ALWAYS have to activate that! This way the bios updates the microcode with 
the latest version it is carrying around. Not activating that option is 
really, really stupid. For many reasons. It is also (almost) completely 
unrelated to that blob.

That blob is for the OS so you can upload an even more recent version of 
microcode. In case your bios sucks. For example.

>  2) Does anyone know, what these microcodes do? They are fixes for...
>     ...what?

the CPU. All CPUs use microcode. For decades. Google, or go straight to 
wikipedia.
http://en.wikipedia.org/wiki/Microcode

Re: [gentoo-user] Microcode update AMD

[meino.cramer]

Volker Armin Hemmann <volkerarmin@googlemail.com> [11-01-17 20:16]:
> On Monday 17 January 2011 18:21:48 meino.cramer@gmx.de wrote:
> > Hi,
> > 
> > I have two questions:
> > 
> >  1) Do I have to enable microcode updates in the BIOS of my Crosshair
> >     IV Formula to activate microcodes push in the CPU by the module
> >     "microcode" ? (AMD Phenom X6 1090T)
> > 
> 
> you ALWAYS have to activate that! This way the bios updates the microcode with 
> the latest version it is carrying around. Not activating that option is 
> really, really stupid. For many reasons. It is also (almost) completely 
> unrelated to that blob.
> 
> That blob is for the OS so you can upload an even more recent version of 
> microcode. In case your bios sucks. For example.
> 
> >  2) Does anyone know, what these microcodes do? They are fixes for...
> >     ...what?
> 
> the CPU. All CPUs use microcode. For decades. Google, or go straight to 
> wikipedia.
> http://en.wikipedia.org/wiki/Microcode
> 

Cool down. I know for waht microcodes are good for.

My question means: What specific bugs/features of my CPU get fixed,
when I use the microcde included in the recent microcode update???

Re: [gentoo-user] Microcode update AMD

[Volker Armin Hemmann]

On Monday 17 January 2011 20:19:04 meino.cramer@gmx.de wrote:
> Volker Armin Hemmann <volkerarmin@googlemail.com> [11-01-17 20:16]:
> > On Monday 17 January 2011 18:21:48 meino.cramer@gmx.de wrote:
> > > Hi,
> > > 
> > > I have two questions:
> > >  1) Do I have to enable microcode updates in the BIOS of my
> > >  Crosshair
> > >  
> > >     IV Formula to activate microcodes push in the CPU by the
> > >     module
> > >     "microcode" ? (AMD Phenom X6 1090T)
> > 
> > you ALWAYS have to activate that! This way the bios updates the
> > microcode with the latest version it is carrying around. Not activating
> > that option is really, really stupid. For many reasons. It is also
> > (almost) completely unrelated to that blob.
> > 
> > That blob is for the OS so you can upload an even more recent version of
> > microcode. In case your bios sucks. For example.
> > 
> > >  2) Does anyone know, what these microcodes do? They are fixes
> > >  for...
> > >  
> > >     ...what?
> > 
> > the CPU. All CPUs use microcode. For decades. Google, or go straight to
> > wikipedia.
> > http://en.wikipedia.org/wiki/Microcode
> 
> Cool down. I know for waht microcodes are good for.
> 
> My question means: What specific bugs/features of my CPU get fixed,
> when I use the microcde included in the recent microcode update???

nobody knows.

Re: [gentoo-user] Microcode update AMD

[meino.cramer]

Volker Armin Hemmann <volkerarmin@googlemail.com> [11-01-17 20:52]:
> On Monday 17 January 2011 20:19:04 meino.cramer@gmx.de wrote:
> > Volker Armin Hemmann <volkerarmin@googlemail.com> [11-01-17 20:16]:
> > > On Monday 17 January 2011 18:21:48 meino.cramer@gmx.de wrote:
> > > > Hi,
> > > > 
> > > > I have two questions:
> > > >  1) Do I have to enable microcode updates in the BIOS of my
> > > >  Crosshair
> > > >  
> > > >     IV Formula to activate microcodes push in the CPU by the
> > > >     module
> > > >     "microcode" ? (AMD Phenom X6 1090T)
> > > 
> > > you ALWAYS have to activate that! This way the bios updates the
> > > microcode with the latest version it is carrying around. Not activating
> > > that option is really, really stupid. For many reasons. It is also
> > > (almost) completely unrelated to that blob.
> > > 
> > > That blob is for the OS so you can upload an even more recent version of
> > > microcode. In case your bios sucks. For example.
> > > 
> > > >  2) Does anyone know, what these microcodes do? They are fixes
> > > >  for...
> > > >  
> > > >     ...what?
> > > 
> > > the CPU. All CPUs use microcode. For decades. Google, or go straight to
> > > wikipedia.
> > > http://en.wikipedia.org/wiki/Microcode
> > 
> > Cool down. I know for waht microcodes are good for.
> > 
> > My question means: What specific bugs/features of my CPU get fixed,
> > when I use the microcde included in the recent microcode update???
> 
> nobody knows.
> 

So...why should I try unknown code patched into my CPU.

It looks like "install this virus" from the security point
of view, doesn't ist?

Re: [gentoo-user] Microcode update AMD

[Mark Knecht]

On Mon, Jan 17, 2011 at 11:57 AM,  <meino.cramer@gmx.de> wrote:
<SNIP>
> So...why should I try unknown code patched into my CPU.
>
> It looks like "install this virus" from the security point
> of view, doesn't ist?

That was my point.

I think the idea Volker is suggesting is the micro-code updates go
from AMD (who understands what the issue is with their processor) to
the BIOS manufacturer (Phoenix or whoever did yous) and get
incorporated in a secure way. They are 'known good' in the BIOS update
we receive and write into a Flash drive. It's just a choice whether
you want to use that part of BOIS or now.

After all, _any_ BIOS update represents an opportunity for someone to
really mess you machine up. Doesn't matter if it's micro-code or
something else.

That's my reading of this so far....

- Mark

Re: [gentoo-user] Microcode update AMD

[Volker Armin Hemmann]

On Monday 17 January 2011 12:12:08 Mark Knecht wrote:
> On Mon, Jan 17, 2011 at 11:57 AM,  <meino.cramer@gmx.de> wrote:
> <SNIP>
> 
> > So...why should I try unknown code patched into my CPU.
> > 
> > It looks like "install this virus" from the security point
> > of view, doesn't ist?
> 
> That was my point.
> 
> I think the idea Volker is suggesting is the micro-code updates go
> from AMD (who understands what the issue is with their processor) to
> the BIOS manufacturer (Phoenix or whoever did yous) and get
> incorporated in a secure way. They are 'known good' in the BIOS update
> we receive and write into a Flash drive. It's just a choice whether
> you want to use that part of BOIS or now.
> 
> After all, _any_ BIOS update represents an opportunity for someone to
> really mess you machine up. Doesn't matter if it's micro-code or
> something else.
> 
> That's my reading of this so far....
> 
> - Mark

also the microcode you download is from amd's servers. If you don't that stuff 
- you can't use CPUs because they might be loaded with 'hacked' microcode from 
the start. Or motherboards, because the bios might be hacked. Or the linux 
kernel because maybe somebody incorporated code into linux. gcc and binutils 
that looks innocent but combined will kill your machine.

On the other hand, CPU bugs can result in miscalculations. Very, very 
expensive miscalculations.

So what is worse - an instable, incorrect CPU or paranoia?

Re: [gentoo-user] Microcode update AMD

[William Kenworthy]

On Mon, 2011-01-17 at 20:46 +0100, Volker Armin Hemmann wrote:
> On Monday 17 January 2011 20:19:04 meino.cramer@gmx.de wrote:
> > Volker Armin Hemmann <volkerarmin@googlemail.com> [11-01-17 20:16]:
> > > On Monday 17 January 2011 18:21:48 meino.cramer@gmx.de wrote:
> > > > Hi,
> > > > 
> > > > I have two questions:
> > > >  1) Do I have to enable microcode updates in the BIOS of my
> > > >  Crosshair
> > > >  
> > > >     IV Formula to activate microcodes push in the CPU by the
> > > >     module
> > > >     "microcode" ? (AMD Phenom X6 1090T)

> nobody knows.
> 


Not amd, but follow the links for some explanation.

*  sys-apps/microcode-ctl
      Latest version available: 1.17-r2
      Latest version installed: [ Not Installed ]
      Size of downloaded files: 319 kB
      Homepage:    http://www.urbanmyth.org/microcode
      Description: Intel processor microcode update utility
      License:     GPL-2

*  sys-apps/microcode-data
      Latest version available: 20100209
      Latest version installed: [ Not Installed ]
      Size of downloaded files: 549 kB
      Homepage:    http://urbanmyth.org/microcode/
      Description: Intel IA32 microcode update data
      License:     as-is

I manually grabbed a later data set from Intel when the kernel would
throw a message about needing a microcode update on my Intel Atom. There
are a couple of kernel options that need setting as well as the above
packages - loading is via an /etc/init.d/ script. There was a changelog
there as well - AMD should be similar.  Also, you could ask AMD what the
update fixes?

The bios microcode update is likely an enable setting rather than the
bios actually updating the cpu.  You need to do some reading/asking of
the manufacturers (not here) if it bothers you.

BillK


-- 
William Kenworthy <billk@iinet.net.au>
Home in Perth!

Re: [gentoo-user] Microcode update AMD

[Paul Hartman]

On Mon, Jan 17, 2011 at 10:29 PM, William Kenworthy <billk@iinet.net.au> wrote:
> The bios microcode update is likely an enable setting rather than the
> bios actually updating the cpu.  You need to do some reading/asking of
> the manufacturers (not here) if it bothers you.

Thanks for the links, I didn't realize they made the microcode data
available separately.

From Intel's download site for the microcode data:

"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."

Re: [gentoo-user] Microcode update AMD

[Mark Knecht]

On Tue, Jan 18, 2011 at 7:38 AM, Paul Hartman
<paul.hartman+gentoo@gmail.com> wrote:
> On Mon, Jan 17, 2011 at 10:29 PM, William Kenworthy <billk@iinet.net.au> wrote:
>> The bios microcode update is likely an enable setting rather than the
>> bios actually updating the cpu.  You need to do some reading/asking of
>> the manufacturers (not here) if it bothers you.
>
> Thanks for the links, I didn't realize they made the microcode data
> available separately.
>
> From Intel's download site for the microcode data:
>
> "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."
>
>
Thanks for the info Paul.

For kicks I tried it on an Intel DH55HC MB running an Core i5-661.

1) Created /etc/firmware
2) Downloaded the Intel microcode-20101123.tgz file
3) Enabled the /dev/cpu/microcode option under Processor Types and Features
4) Rebuilt the kernel and rebooted

I see this in dmesg:

mark@firefly ~ $ dmesg | grep micro
[    0.495337] microcode: CPU0 sig=0x20652, pf=0x2, revision=0x9
[    0.495436] microcode: CPU1 sig=0x20652, pf=0x2, revision=0x9
[    0.495535] microcode: CPU2 sig=0x20652, pf=0x2, revision=0x9
[    0.495635] microcode: CPU3 sig=0x20652, pf=0x2, revision=0x9
[    0.495751] microcode: Microcode Update Driver: v2.00
<tigran@aivazian.fsnet.co.uk>, Peter Oruba
mark@firefly ~ $

On this machine the message doesn't change whether the microcode file
is located in /etc/firmware or not so I don't know how to tell if the
process worked but the processor doesn't need any updates or whether
it didn't work at all.

- Mark

Re: [gentoo-user] Microcode update AMD

[Mark Knecht]

On Tue, Jan 18, 2011 at 8:16 AM, Mark Knecht <markknecht@gmail.com> wrote:
> On Tue, Jan 18, 2011 at 7:38 AM, Paul Hartman
> <paul.hartman+gentoo@gmail.com> wrote:
>> On Mon, Jan 17, 2011 at 10:29 PM, William Kenworthy <billk@iinet.net.au> wrote:
>>> The bios microcode update is likely an enable setting rather than the
>>> bios actually updating the cpu.  You need to do some reading/asking of
>>> the manufacturers (not here) if it bothers you.
>>
>> Thanks for the links, I didn't realize they made the microcode data
>> available separately.
>>
>> From Intel's download site for the microcode data:
>>
>> "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."
>>
>>
> Thanks for the info Paul.
>
> For kicks I tried it on an Intel DH55HC MB running an Core i5-661.
>
> 1) Created /etc/firmware
> 2) Downloaded the Intel microcode-20101123.tgz file
> 3) Enabled the /dev/cpu/microcode option under Processor Types and Features
> 4) Rebuilt the kernel and rebooted
>
> I see this in dmesg:
>
> mark@firefly ~ $ dmesg | grep micro
> [    0.495337] microcode: CPU0 sig=0x20652, pf=0x2, revision=0x9
> [    0.495436] microcode: CPU1 sig=0x20652, pf=0x2, revision=0x9
> [    0.495535] microcode: CPU2 sig=0x20652, pf=0x2, revision=0x9
> [    0.495635] microcode: CPU3 sig=0x20652, pf=0x2, revision=0x9
> [    0.495751] microcode: Microcode Update Driver: v2.00
> <tigran@aivazian.fsnet.co.uk>, Peter Oruba
> mark@firefly ~ $
>
> On this machine the message doesn't change whether the microcode file
> is located in /etc/firmware or not so I don't know how to tell if the
> process worked but the processor doesn't need any updates or whether
> it didn't work at all.
>
> - Mark
>

OK, I got it to load by hand:

1) emerge microcode-ctl

which also emerges microcode-data. Unfortunately microcode-data looks
to be out of date. Add microcode_ctl to the boot level:

rc-update add microcode_ctl boot

2) Unzip and untar the microcode file from Intel.

3) The above emerge placed the microcode.dat file in /lib/firmware,
not /etc/firmware as suggested by the kernel, so I loaded the newer
one from Intel by hand using microcode-ctl:


firefly firmware # microcode_ctl -f /etc/firmware/microcode-20101123.dat
microcode_ctl: writing microcode (length: 430080)
microcode_ctl: microcode successfuly written to /dev/cpu/microcode
firefly firmware # dmesg | grep micro
[    0.495755] microcode: CPU0 sig=0x20652, pf=0x2, revision=0x9
[    0.495853] microcode: CPU1 sig=0x20652, pf=0x2, revision=0x9
[    0.495952] microcode: CPU2 sig=0x20652, pf=0x2, revision=0x9
[    0.496050] microcode: CPU3 sig=0x20652, pf=0x2, revision=0x9
[    0.496168] microcode: Microcode Update Driver: v2.00
<tigran@aivazian.fsnet.co.uk>, Peter Oruba
[ 2647.731262] microcode: CPU0 updated to revision 0xc, date = 2010-06-10
[ 2647.731982] microcode: CPU1 updated to revision 0xc, date = 2010-06-10
[ 2647.732815] microcode: CPU2 updated to revision 0xc, date = 2010-06-10
[ 2647.733608] microcode: CPU3 updated to revision 0xc, date = 2010-06-10
firefly firmware #

Now the microcode revision appears to be updated.

I suspected that if I renamed the file in /etc/firmware to
'microcode.dat' maybe it would load automatically at boot time but it
didn't so I moved it to lib/firmware where microcode_ctl does load it.

NOTE: There is a /etc/conf.d/microcode_ctl config file but it doesn't
see to include a path for microcode so I guess at this time I'm stuck
overwriting the /lib/firmware directory until I learn more.

Cheers,
Mark

Re: [gentoo-user] Microcode update AMD

[Volker Armin Hemmann]

On Tuesday 18 January 2011 09:34:14 Mark Knecht wrote:
> On Tue, Jan 18, 2011 at 8:16 AM, Mark Knecht <markknecht@gmail.com> wrote:
> > On Tue, Jan 18, 2011 at 7:38 AM, Paul Hartman
> > 
> > <paul.hartman+gentoo@gmail.com> wrote:
> >> On Mon, Jan 17, 2011 at 10:29 PM, William Kenworthy <billk@iinet.net.au> 
wrote:
> >>> The bios microcode update is likely an enable setting rather than
> >>> the
> >>> bios actually updating the cpu.  You need to do some reading/asking
> >>> of
> >>> the manufacturers (not here) if it bothers you.
> >> 
> >> Thanks for the links, I didn't realize they made the microcode data
> >> available separately.
> >> 
> >> From Intel's download site for the microcode data:
> >> 
> >> "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."
> > 
> > Thanks for the info Paul.
> > 
> > For kicks I tried it on an Intel DH55HC MB running an Core i5-661.
> > 
> > 1) Created /etc/firmware
> > 2) Downloaded the Intel microcode-20101123.tgz file
> > 3) Enabled the /dev/cpu/microcode option under Processor Types and
> > Features 4) Rebuilt the kernel and rebooted
> > 
> > I see this in dmesg:
> > 
> > mark@firefly ~ $ dmesg | grep micro
> > [    0.495337] microcode: CPU0 sig=0x20652, pf=0x2, revision=0x9
> > [    0.495436] microcode: CPU1 sig=0x20652, pf=0x2, revision=0x9
> > [    0.495535] microcode: CPU2 sig=0x20652, pf=0x2, revision=0x9
> > [    0.495635] microcode: CPU3 sig=0x20652, pf=0x2, revision=0x9
> > [    0.495751] microcode: Microcode Update Driver: v2.00
> > <tigran@aivazian.fsnet.co.uk>, Peter Oruba
> > mark@firefly ~ $
> > 
> > On this machine the message doesn't change whether the microcode file
> > is located in /etc/firmware or not so I don't know how to tell if the
> > process worked but the processor doesn't need any updates or whether
> > it didn't work at all.
> > 
> > - Mark
> 
> OK, I got it to load by hand:
> 
> 1) emerge microcode-ctl
> 
> which also emerges microcode-data. Unfortunately microcode-data looks
> to be out of date. Add microcode_ctl to the boot level:
> 
> rc-update add microcode_ctl boot
> 
> 2) Unzip and untar the microcode file from Intel.
> 
> 3) The above emerge placed the microcode.dat file in /lib/firmware,
> not /etc/firmware as suggested by the kernel, so I loaded the newer
> one from Intel by hand using microcode-ctl:
> 
> 
> firefly firmware # microcode_ctl -f /etc/firmware/microcode-20101123.dat
> microcode_ctl: writing microcode (length: 430080)
> microcode_ctl: microcode successfuly written to /dev/cpu/microcode
> firefly firmware # dmesg | grep micro
> [    0.495755] microcode: CPU0 sig=0x20652, pf=0x2, revision=0x9
> [    0.495853] microcode: CPU1 sig=0x20652, pf=0x2, revision=0x9
> [    0.495952] microcode: CPU2 sig=0x20652, pf=0x2, revision=0x9
> [    0.496050] microcode: CPU3 sig=0x20652, pf=0x2, revision=0x9
> [    0.496168] microcode: Microcode Update Driver: v2.00
> <tigran@aivazian.fsnet.co.uk>, Peter Oruba
> [ 2647.731262] microcode: CPU0 updated to revision 0xc, date = 2010-06-10
> [ 2647.731982] microcode: CPU1 updated to revision 0xc, date = 2010-06-10
> [ 2647.732815] microcode: CPU2 updated to revision 0xc, date = 2010-06-10
> [ 2647.733608] microcode: CPU3 updated to revision 0xc, date = 2010-06-10
> firefly firmware #
> 
> Now the microcode revision appears to be updated.
> 
> I suspected that if I renamed the file in /etc/firmware to
> 'microcode.dat' maybe it would load automatically at boot time but it
> didn't so I moved it to lib/firmware where microcode_ctl does load it.
> 
> NOTE: There is a /etc/conf.d/microcode_ctl config file but it doesn't
> see to include a path for microcode so I guess at this time I'm stuck
> overwriting the /lib/firmware directory until I learn more.
> 
> Cheers,
> Mark

and that is all the intel stuff. For AMD all you have to do is:
modprobe -r microcode && modprobe microcode

Re: [gentoo-user] Microcode update AMD

[Enrico Weigelt]

* Volker Armin Hemmann <volkerarmin@googlemail.com> wrote:

> and that is all the intel stuff. For AMD all you have to do is:
> modprobe -r microcode && modprobe microcode

Is the microcode permanently flashed or loaded into some
internal RAM ?


cu
-- 
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weigelt@metux.de
 mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

Re: [gentoo-user] Microcode update AMD

[meino.cramer]

Enrico Weigelt <weigelt@metux.de> [11-02-05 16:08]:
> * Volker Armin Hemmann <volkerarmin@googlemail.com> wrote:
> 
> > and that is all the intel stuff. For AMD all you have to do is:
> > modprobe -r microcode && modprobe microcode
> 
> Is the microcode permanently flashed or loaded into some
> internal RAM ?
> 
> 
> cu
> -- 
> ----------------------------------------------------------------------
>  Enrico Weigelt, metux IT service -- http://www.metux.de/
> 
>  phone:  +49 36207 519931  email: weigelt@metux.de
>  mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
> ----------------------------------------------------------------------
>  Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
> ----------------------------------------------------------------------
> 

You need a kernel module to load the microcode into the CPU (I dont
know for sure what kind of memory holds it then) eacht time you boot
the machine.

Best regards
mcc

Re: [gentoo-user] Microcode update AMD

[Volker Armin Hemmann]

On Saturday 05 February 2011 15:28:22 Enrico Weigelt wrote:
> * Volker Armin Hemmann <volkerarmin@googlemail.com> wrote:
> > and that is all the intel stuff. For AMD all you have to do is:
> > modprobe -r microcode && modprobe microcode
> 
> Is the microcode permanently flashed or loaded into some
> internal RAM ?

loaded. microcode is never permanently changed on x86 derivates.

Re: [gentoo-user] Microcode update AMD

[Volker Armin Hemmann]

On Saturday 05 February 2011 15:28:22 Enrico Weigelt wrote:
> * Volker Armin Hemmann <volkerarmin@googlemail.com> wrote:
> > and that is all the intel stuff. For AMD all you have to do is:
> > modprobe -r microcode && modprobe microcode
> 
> Is the microcode permanently flashed or loaded into some
> internal RAM ?

loaded. microcode is never permanently changed on x86 derivates.

Re: [gentoo-user] Microcode update AMD

[Paul Hartman]

On Tue, Jan 18, 2011 at 11:34 AM, Mark Knecht <markknecht@gmail.com> wrote:
> OK, I got it to load by hand:
>
> 1) emerge microcode-ctl
>
> which also emerges microcode-data. Unfortunately microcode-data looks
> to be out of date.

The ebuild for newer versions (including the latest 20101123) is in
portage as ~amd64 and ~x86.

Re: [gentoo-user] Microcode update AMD

[Mark Knecht]

On Tue, Jan 18, 2011 at 9:55 AM, Paul Hartman
<paul.hartman+gentoo@gmail.com> wrote:
> On Tue, Jan 18, 2011 at 11:34 AM, Mark Knecht <markknecht@gmail.com> wrote:
>> OK, I got it to load by hand:
>>
>> 1) emerge microcode-ctl
>>
>> which also emerges microcode-data. Unfortunately microcode-data looks
>> to be out of date.
>
> The ebuild for newer versions (including the latest 20101123) is in
> portage as ~amd64 and ~x86.
>
>

Thanks Paul.

Also, it does seem to work, for Intel anyway, as a module or built
into the kernel. I chose to build it in as I'm tired of how long lsmod
is looking these days.

Cheers,
Mark

Re: [gentoo-user] Microcode update AMD

[Paul Hartman]

On Tue, Jan 18, 2011 at 12:21 PM, Mark Knecht <markknecht@gmail.com> wrote:
> On Tue, Jan 18, 2011 at 9:55 AM, Paul Hartman
> <paul.hartman+gentoo@gmail.com> wrote:
>> On Tue, Jan 18, 2011 at 11:34 AM, Mark Knecht <markknecht@gmail.com> wrote:
>>> OK, I got it to load by hand:
>>>
>>> 1) emerge microcode-ctl
>>>
>>> which also emerges microcode-data. Unfortunately microcode-data looks
>>> to be out of date.
>>
>> The ebuild for newer versions (including the latest 20101123) is in
>> portage as ~amd64 and ~x86.
>>
>>
>
> Thanks Paul.
>
> Also, it does seem to work, for Intel anyway, as a module or built
> into the kernel. I chose to build it in as I'm tired of how long lsmod
> is looking these days.

If you use the /etc/init.d/microcode_ctl runscript and have
MICROCODE_UNLOAD="yes" set in /etc/conf.d/microcode_ctl (which is the
default), it will unload the module automatically after it runs, so
you shouldn't see it in lsmod anyway, and saves a few kb of memory.
But, quite honestly, 8kb of memory is probably inconsequential on a
system where microcode_ctl is being used in the first place... :)

Re: [gentoo-user] Microcode update AMD

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 1422 bytes --]

On Tuesday 18 January 2011 20:42:05 Paul Hartman wrote:
> On Tue, Jan 18, 2011 at 12:21 PM, Mark Knecht <markknecht@gmail.com> wrote:
> > On Tue, Jan 18, 2011 at 9:55 AM, Paul Hartman
> > 
> > <paul.hartman+gentoo@gmail.com> wrote:
> >> On Tue, Jan 18, 2011 at 11:34 AM, Mark Knecht <markknecht@gmail.com> 
wrote:
> >>> OK, I got it to load by hand:
> >>> 
> >>> 1) emerge microcode-ctl
> >>> 
> >>> which also emerges microcode-data. Unfortunately microcode-data looks
> >>> to be out of date.
> >> 
> >> The ebuild for newer versions (including the latest 20101123) is in
> >> portage as ~amd64 and ~x86.
> > 
> > Thanks Paul.
> > 
> > Also, it does seem to work, for Intel anyway, as a module or built
> > into the kernel. I chose to build it in as I'm tired of how long lsmod
> > is looking these days.
> 
> If you use the /etc/init.d/microcode_ctl runscript and have
> MICROCODE_UNLOAD="yes" set in /etc/conf.d/microcode_ctl (which is the
> default), it will unload the module automatically after it runs, so
> you shouldn't see it in lsmod anyway, and saves a few kb of memory.
> But, quite honestly, 8kb of memory is probably inconsequential on a
> system where microcode_ctl is being used in the first place... :)

Is the /etc/microcode.dat path a bug, now that firmware is typically placed in 
/lib/firmware?

Shall I create a symlink or raise a bug report?
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Microcode update AMD

[Paul Hartman]

On Tue, Jan 18, 2011 at 2:56 PM, Mick <michaelkintzios@gmail.com> wrote:
> On Tuesday 18 January 2011 20:42:05 Paul Hartman wrote:
>> On Tue, Jan 18, 2011 at 12:21 PM, Mark Knecht <markknecht@gmail.com> wrote:
>> > On Tue, Jan 18, 2011 at 9:55 AM, Paul Hartman
>> >
>> > <paul.hartman+gentoo@gmail.com> wrote:
>> >> On Tue, Jan 18, 2011 at 11:34 AM, Mark Knecht <markknecht@gmail.com>
> wrote:
>> >>> OK, I got it to load by hand:
>> >>>
>> >>> 1) emerge microcode-ctl
>> >>>
>> >>> which also emerges microcode-data. Unfortunately microcode-data looks
>> >>> to be out of date.
>> >>
>> >> The ebuild for newer versions (including the latest 20101123) is in
>> >> portage as ~amd64 and ~x86.
>> >
>> > Thanks Paul.
>> >
>> > Also, it does seem to work, for Intel anyway, as a module or built
>> > into the kernel. I chose to build it in as I'm tired of how long lsmod
>> > is looking these days.
>>
>> If you use the /etc/init.d/microcode_ctl runscript and have
>> MICROCODE_UNLOAD="yes" set in /etc/conf.d/microcode_ctl (which is the
>> default), it will unload the module automatically after it runs, so
>> you shouldn't see it in lsmod anyway, and saves a few kb of memory.
>> But, quite honestly, 8kb of memory is probably inconsequential on a
>> system where microcode_ctl is being used in the first place... :)
>
> Is the /etc/microcode.dat path a bug, now that firmware is typically placed in
> /lib/firmware?
>
> Shall I create a symlink or raise a bug report?

On my ~amd64 system, using microcode-ctl-1.17-r2 and
microcode-data-20101123 the data is installed to /lib/firmware and the
runscript does:
microcode_ctl -qu -f /lib/firmware/microcode.dat -d ${MICROCODE_DEV}

I think the gentoo packages are designed for you to use the installed
runscript which works when you use the microcode-data package from
portage since they both use the /lib/firmware location.

Based on this I would guess that it is not a bug, but that it is the
intended behavior.

Re: [gentoo-user] Microcode update AMD

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 2558 bytes --]

On Tuesday 18 January 2011 21:13:49 Paul Hartman wrote:
> On Tue, Jan 18, 2011 at 2:56 PM, Mick <michaelkintzios@gmail.com> wrote:
> > On Tuesday 18 January 2011 20:42:05 Paul Hartman wrote:
> >> On Tue, Jan 18, 2011 at 12:21 PM, Mark Knecht <markknecht@gmail.com> 
wrote:
> >> > On Tue, Jan 18, 2011 at 9:55 AM, Paul Hartman
> >> > 
> >> > <paul.hartman+gentoo@gmail.com> wrote:
> >> >> On Tue, Jan 18, 2011 at 11:34 AM, Mark Knecht <markknecht@gmail.com>
> > 
> > wrote:
> >> >>> OK, I got it to load by hand:
> >> >>> 
> >> >>> 1) emerge microcode-ctl
> >> >>> 
> >> >>> which also emerges microcode-data. Unfortunately microcode-data
> >> >>> looks to be out of date.
> >> >> 
> >> >> The ebuild for newer versions (including the latest 20101123) is in
> >> >> portage as ~amd64 and ~x86.
> >> > 
> >> > Thanks Paul.
> >> > 
> >> > Also, it does seem to work, for Intel anyway, as a module or built
> >> > into the kernel. I chose to build it in as I'm tired of how long lsmod
> >> > is looking these days.
> >> 
> >> If you use the /etc/init.d/microcode_ctl runscript and have
> >> MICROCODE_UNLOAD="yes" set in /etc/conf.d/microcode_ctl (which is the
> >> default), it will unload the module automatically after it runs, so
> >> you shouldn't see it in lsmod anyway, and saves a few kb of memory.
> >> But, quite honestly, 8kb of memory is probably inconsequential on a
> >> system where microcode_ctl is being used in the first place... :)
> > 
> > Is the /etc/microcode.dat path a bug, now that firmware is typically
> > placed in /lib/firmware?
> > 
> > Shall I create a symlink or raise a bug report?
> 
> On my ~amd64 system, using microcode-ctl-1.17-r2 and
> microcode-data-20101123 the data is installed to /lib/firmware and the
> runscript does:
> microcode_ctl -qu -f /lib/firmware/microcode.dat -d ${MICROCODE_DEV}
> 
> I think the gentoo packages are designed for you to use the installed
> runscript which works when you use the microcode-data package from
> portage since they both use the /lib/firmware location.
> 
> Based on this I would guess that it is not a bug, but that it is the
> intended behavior.

Yes Paul, you're right.  In the days before /lib/firmware was made available I 
recall that /etc/microcode.dat was the default location of the code.  Now that 
I just ran it by hand once, it complained that /etc/microcode.dat doesn't 
exist.  

However, following your prompt I looked at the /etc/init.d/microcode-ctl 
script and it all makes sense.
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Microcode update AMD

[Mark Knecht]

On Tue, Jan 18, 2011 at 12:56 PM, Mick <michaelkintzios@gmail.com> wrote:
<SNIP>
>
> Is the /etc/microcode.dat path a bug, now that firmware is typically placed in
> /lib/firmware?
>
> Shall I create a symlink or raise a bug report?
> --
> Regards,
> Mick
>

Mick,
   I don't think so. Seems to me Gentoo can put this where ever it
wants as long as it matches the init script.

- Mark

Re: [gentoo-user] Microcode update AMD

[Jason Weisberger]

[-- Attachment #1: Type: text/plain, Size: 1807 bytes --]

As he said in the previous message, there are almost never changelogs for
microcode updates.

I do, however, have to disagree with *never* disabling microcode updates.
If I recall properly, the AMD Phenom II 720 was able to be unlocked to 4
cores via a misconfiguration that enabled it with ACC.  AMD later corrected
this issue with a microcode update.  True, some motherboards worked around
that fix a different way, but if you had a first gen board with ACC support
you *had* to have the old microcode for it to work.  The update killed your
free core :)
On Jan 17, 2011 3:06 PM, <meino.cramer@gmx.de> wrote:
> Volker Armin Hemmann <volkerarmin@googlemail.com> [11-01-17 20:16]:
>> On Monday 17 January 2011 18:21:48 meino.cramer@gmx.de wrote:
>> > Hi,
>> >
>> > I have two questions:
>> >
>> > 1) Do I have to enable microcode updates in the BIOS of my Crosshair
>> > IV Formula to activate microcodes push in the CPU by the module
>> > "microcode" ? (AMD Phenom X6 1090T)
>> >
>>
>> you ALWAYS have to activate that! This way the bios updates the microcode
with
>> the latest version it is carrying around. Not activating that option is
>> really, really stupid. For many reasons. It is also (almost) completely
>> unrelated to that blob.
>>
>> That blob is for the OS so you can upload an even more recent version of
>> microcode. In case your bios sucks. For example.
>>
>> > 2) Does anyone know, what these microcodes do? They are fixes for...
>> > ...what?
>>
>> the CPU. All CPUs use microcode. For decades. Google, or go straight to
>> wikipedia.
>> http://en.wikipedia.org/wiki/Microcode
>>
>
> Cool down. I know for waht microcodes are good for.
>
> My question means: What specific bugs/features of my CPU get fixed,
> when I use the microcde included in the recent microcode update???
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 2446 bytes --]

Re: [gentoo-user] Microcode update AMD

[Volker Armin Hemmann]

On Monday 17 January 2011 15:13:54 Jason Weisberger wrote:
> As he said in the previous message, there are almost never changelogs for
> microcode updates.
> 
> I do, however, have to disagree with *never* disabling microcode updates.
> If I recall properly, the AMD Phenom II 720 was able to be unlocked to 4
> cores via a misconfiguration that enabled it with ACC.  AMD later corrected
> this issue with a microcode update.  True, some motherboards worked around
> that fix a different way, but if you had a first gen board with ACC support
> you *had* to have the old microcode for it to work.  The update killed your
> free core :)

a 'free core' that is probably broken in mysterious and hard to find but 
nonetheless very dangerous ways. Thanks.

Re: [gentoo-user] Microcode update AMD

[Jason Weisberger]

[-- Attachment #1: Type: text/plain, Size: 1389 bytes --]

The word "probably" implies that you have no idea what the statistics were
on getting a perfectly good core were or why they disabled entire batches of
cores based on an error from one.

You are just overdriving your point.  If he doesn't want to enable updation
of microcode, it won't hurt anything.  If it was functioning fine before, it
will also be fine without an update.  There is nothing wrong with keeping
the version of code that is stable for you.  It isn't stupid, its a good
rule of thumb.  If it isn't broken, don't fix it.
On Jan 17, 2011 4:15 PM, "Volker Armin Hemmann" <volkerarmin@googlemail.com>
wrote:
> On Monday 17 January 2011 15:13:54 Jason Weisberger wrote:
>> As he said in the previous message, there are almost never changelogs for
>> microcode updates.
>>
>> I do, however, have to disagree with *never* disabling microcode updates.
>> If I recall properly, the AMD Phenom II 720 was able to be unlocked to 4
>> cores via a misconfiguration that enabled it with ACC. AMD later
corrected
>> this issue with a microcode update. True, some motherboards worked around
>> that fix a different way, but if you had a first gen board with ACC
support
>> you *had* to have the old microcode for it to work. The update killed
your
>> free core :)
>
> a 'free core' that is probably broken in mysterious and hard to find but
> nonetheless very dangerous ways. Thanks.
>
>

[-- Attachment #2: Type: text/html, Size: 1707 bytes --]

Re: [gentoo-user] Microcode update AMD

[Volker Armin Hemmann]

On Monday 17 January 2011 16:59:26 Jason Weisberger wrote:
> The word "probably" implies that you have no idea what the statistics were
> on getting a perfectly good core were or why they disabled entire batches of
> cores based on an error from one.
> 
> You are just overdriving your point.  If he doesn't want to enable updation
> of microcode, it won't hurt anything.  If it was functioning fine before, it
> will also be fine without an update.  There is nothing wrong with keeping
> the version of code that is stable for you.  It isn't stupid, its a good
> rule of thumb.  If it isn't broken, don't fix it.

the problem is: how do you know it is stable? Just might be lucky that fixed 
function was not hit by you so far. But will that be true tomorrow? Next week? 
With the next gcc version?

Microcode updates are there for a reason. There are ZILCH reasons to turn it 
off in the bios. 'Oh, there are a lots of fine 4cores marketed as 3cores. I want 
that' is not a reason not to turn it on. It is a reason to buy a mobo who can 
unlock those cores without turning off microcode updates.

Call me old fashioned, but I prefer computers as deterministic machines - and 
not very expensive random number generators (which is also the main reason why 
I don't overclock. 5% faster for 1% better chance of errors? 5% I will never 
ever able to 'feel'? No thank you).

[gentoo-user] Re: Microcode update AMD

[Nuno J. Silva]

Jason Weisberger <jbdubbs@gmail.com> writes:

> On Jan 17, 2011 4:15 PM, "Volker Armin Hemmann" <volkerarmin@googlemail.com> wrote:
>> On Monday 17 January 2011 15:13:54 Jason Weisberger wrote:
>>> 
>>> The update killed your free core :)
>>
>> a 'free core' that is probably broken in mysterious and hard to find but
>> nonetheless very dangerous ways. Thanks.
>
> The word "probably" implies that you have no idea what the statistics were
> on getting a perfectly good core were or why they disabled entire batches of
> cores based on an error from one.

I think you should worry more about the fact AMD disables known-good
cores due to excessive demand for lower-core versions. 

If you can somehow manage to find out if the disabled core is good or
not (keeping in mind that "testing may convincingly demonstrate the
presence of bugs, but can never demonstrate their absence." (EWD1036) -
it's more or less like when you use memtest), then you have a good
heuristic on whether or not to enable that core. Now I doubt I'd do it
blindly - YMMV, of course.


Also,
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

-- 
Nuno J. Silva
gopher://sdf-eu.org/1/users/njsg

Re: [gentoo-user] Microcode update AMD

[Enrico Weigelt]

* Volker Armin Hemmann <volkerarmin@googlemail.com> wrote:

> the CPU. All CPUs use microcode. For decades. Google, or go straight to 
> wikipedia.
> http://en.wikipedia.org/wiki/Microcode

Borroughs' large systems (b6500+) were designed as microcode
machines from ground up, which essentially interpreted an algol
bytecode (the whole OS was directly implemented in assembler,
w/o any machine specific assembler code). Paired w/ their entirely
stack-based architecture (there were no program-visible registers)
they could easily do massive-multiprocessing (everything's reentrant
by design), 24/7 uptime even w/ hw replacements/upgrades and
cpu improvements w/o ever having to recompile.

Their successors (now Unisys) are called emode machines - quite
the same approach as nowadays w/ Java (interpreter/JIT).


BTW: I'm currently designing an emode/microcode-base computer
architecture built on an matrix of nanocores, they don't have a
concept of main memory, instead a relatively large (linear
addressable) register memory, part of the register space is
shared with neighbours (multiport-RAMs). These are programmed
by an horizontal microcode, which is decoded by an static demux,
that directly connects registers to an micro-ALU (so there're
no additional load+store cycles) ...


cu
-- 
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weigelt@metux.de
 mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

Re: [gentoo-user] Microcode update AMD

[Florian Philipp]

[-- Attachment #1: Type: text/plain, Size: 664 bytes --]

Am 05.02.2011 14:34, schrieb Enrico Weigelt:
> 
> BTW: I'm currently designing an emode/microcode-base computer
> architecture built on an matrix of nanocores, they don't have a
> concept of main memory, instead a relatively large (linear
> addressable) register memory, part of the register space is
> shared with neighbours (multiport-RAMs). These are programmed
> by an horizontal microcode, which is decoded by an static demux,
> that directly connects registers to an micro-ALU (so there're
> no additional load+store cycles) ...
> 
> 
> cu

Interesting. Is there a paper on this?

What's its intended purpose?

Regards,
Florian Philipp


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-user] Microcode update AMD

[Volker Armin Hemmann]

btw, very related:

http://blog.flameeyes.eu/2011/01/17/microupdates-for-microcodes

Re: [gentoo-user] Microcode update AMD

[Volker Armin Hemmann]

btw, very related:

http://blog.flameeyes.eu/2011/01/17/microupdates-for-microcodes