FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo User

 
 
LinkBack Thread Tools
 
Old 01-18-2011, 03:27 PM
Volker Armin Hemmann
 
Default Microcode update AMD

btw, very related:

http://blog.flameeyes.eu/2011/01/17/microupdates-for-microcodes
 
Old 01-18-2011, 04:34 PM
Mark Knecht
 
Default Microcode update AMD

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
 
Old 01-18-2011, 04:48 PM
Volker Armin Hemmann
 
Default Microcode update AMD

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
 
Old 01-18-2011, 04:55 PM
Paul Hartman
 
Default Microcode update AMD

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.
 
Old 01-18-2011, 05:21 PM
Mark Knecht
 
Default Microcode update AMD

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
 
Old 01-18-2011, 07:42 PM
Paul Hartman
 
Default Microcode update AMD

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...
 
Old 01-18-2011, 07:56 PM
Mick
 
Default Microcode update AMD

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
 
Old 01-18-2011, 08:13 PM
Paul Hartman
 
Default Microcode update AMD

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.
 
Old 01-18-2011, 10:08 PM
Mick
 
Default Microcode update AMD

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
 
Old 01-18-2011, 10:56 PM
Mark Knecht
 
Default Microcode update AMD

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
 

Thread Tools




All times are GMT. The time now is 04:48 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org