-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
When I try to update the microcode on my PIV (1.7GHz, Jetway mobo), the
update fails and i see --
microcode: CPU0 no microcode found! (sig=f0a, pflags=4)
in the kernel log. I couldn't find any reference to this on google, and it's
not urgent or anything; I just thought it might be helpful.
Thanks for any help
*MatthewM*
- --
Have you ever noticed that the people who are always trying to tell you
`there's a time for work and a time for play' never find the time for play?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE8yoxcoVQMDIAmueURAvSwAJ0f1BlZkLxL7NGyEDDXkIw2MGeSSwCeInIE
5WbS/IckoMPHgTuUbttCfFU=
=5PZ4
-----END PGP SIGNATURE-----
On Sat, Apr 27, 2002 at 12:32:42PM +0100, Matthew M wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> When I try to update the microcode on my PIV (1.7GHz, Jetway mobo), the
> update fails and i see --
>
> microcode: CPU0 no microcode found! (sig=f0a, pflags=4)
Probably the microcode.dat file has no updated microcode for this
stepping of CPU. Make sure you have the latest one from
http://www.urbanmyth.org/microcode/
But it's still possible that there is no update (yet).
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
Dave Jones wrote:
> On Sat, Apr 27, 2002 at 12:32:42PM +0100, Matthew M wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Hi,
> >
> > When I try to update the microcode on my PIV (1.7GHz, Jetway mobo), the
> > update fails and i see --
> >
> > microcode: CPU0 no microcode found! (sig=f0a, pflags=4)
>
> Probably the microcode.dat file has no updated microcode for this
> stepping of CPU. Make sure you have the latest one from
> http://www.urbanmyth.org/microcode/
>
> But it's still possible that there is no update (yet).
>
considering that the microcode update is one year old, I don't believe
there is an update for that CPU...
Fran?ois
> Probably the microcode.dat file has no updated microcode for this
> stepping of CPU. Make sure you have the latest one from
> http://www.urbanmyth.org/microcode/
Sorry if this is a FAQ, but where's the microcode.dat supposed to be
placed? I can't find any information about that in the doc.
roy
--
Roy Sigurd Karlsbakk, Datavaktmester
Computers are like air conditioners.
They stop working when you open Windows.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Saturday 27 April 2002 7:57 pm, Roy Sigurd Karlsbakk wrote:
> Sorry if this is a FAQ, but where's the microcode.dat supposed to be
> placed? I can't find any information about that in the doc.
/usr/share/misc/microcode.dat
*MatthewM*
- --
Failure is more frequently from want of energy than want of capital.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE8ywaloVQMDIAmueURAkfHAJ45eNlJ7NsOiEnRUQTjs0OFRlYp9gCcCeyI
nCPiNidQN+LULkRcO9dQGo0=
=fs4b
-----END PGP SIGNATURE-----
In article <m171Yag-000Ga6C@Wasteland> you wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Saturday 27 April 2002 7:57 pm, Roy Sigurd Karlsbakk wrote:
>> Sorry if this is a FAQ, but where's the microcode.dat supposed to be
>> placed? I can't find any information about that in the doc.
>
> /usr/share/misc/microcode.dat
hum doesn't the FHS specify that /usr/share shouldn't contain arch
specific files ? microcode.dat I can't really call arch neutral....
On Sat, 27 Apr 2002, Matthew M wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Saturday 27 April 2002 7:57 pm, Roy Sigurd Karlsbakk wrote:
> > Sorry if this is a FAQ, but where's the microcode.dat supposed to be
> > placed? I can't find any information about that in the doc.
>
> /usr/share/misc/microcode.dat
hm... but... Isn't the microcode update being done during kernel boot?
I rarely have a system set up with /usr on the same fs as /
roy
--
Roy Sigurd Karlsbakk, Datavaktmester
Computers are like air conditioners.
They stop working when you open Windows.
On Sat, 27 Apr 2002, Matthew M wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Saturday 27 April 2002 7:57 pm, Roy Sigurd Karlsbakk wrote:
> > Sorry if this is a FAQ, but where's the microcode.dat supposed to be
> > placed? I can't find any information about that in the doc.
>
> /usr/share/misc/microcode.dat
>
You could have asked the author of the driver (myself) or the author of
microcode_ctl (Simon Trimmer) before giving your "authoritative" answer :)
The default location is /etc/microcode.dat but distributions are free to
put it anywhere they like, e.g. Red Hat puts it in
/etc/firmware/microcode.dat
Regards
Tigran
On Saturday 27 April 2002 21:42, Roy Sigurd Karlsbakk wrote:
> On Sat, 27 Apr 2002, Matthew M wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On Saturday 27 April 2002 7:57 pm, Roy Sigurd Karlsbakk wrote:
> > > Sorry if this is a FAQ, but where's the microcode.dat supposed to be
> > > placed? I can't find any information about that in the doc.
> >
> > /usr/share/misc/microcode.dat
>
> hm... but... Isn't the microcode update being done during kernel boot?
> I rarely have a system set up with /usr on the same fs as /
On my system it lives in /etc, but you can place it anywhere you want, see the
part below which I copied from the microcode README
***************************************************************************
>>> updating every system boot
***************************************************************************
A simple script has been included for systems to apply the microcode
update on boot. The script is a good illustration on how to use the
utility but it may be useful to run through some basic usage.
Without using the provided startup script, to update your microcode and
free the internal buffer on every system boot you'll need to add a line
like the following to /etc/rc.d/rc.local (where prefix indicates the
location of the binary)
prefix/microcode_ctl -iu
or to specify another microcode file
prefix/microcode_ctl -if /etc/microcode.dat
Simple as that. Problems? Contact either myself at [email protected] or
Tigran at [email protected]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Saturday 27 April 2002 8:51 pm, RS wrote:
> ok
>
> running redhat, I have no microcode_ctl. but still, the kernel tells me
> 'IA-32 Microcode Update Driver: v1.09 <[email protected]>' during boot.
>
> where can i find it? Do I need it?
microcode_ctl is the userland utility which actually soed the uploading of
microcode. You will need to get the appropriate package, and this will come
with microcode.dat - then you should actually be able to update your
microcode. The message in your kernel log is just the driver initialisation.
*MatthewM*
- --
Sometimes love ain't nothing but a misunderstanding between two fools.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE8ywOfoVQMDIAmueURAvGVAJ95OFzC163RQ0veUPfndUqy7QzuWQCeOTKS
J9hy4k+y8O67Fnk5vPn9R6s=
=z/wB
-----END PGP SIGNATURE-----
On Sat, 27 Apr 2002, Matthew M wrote:
> microcode: CPU0 no microcode found! (sig=f0a, pflags=4)
>
> in the kernel log. I couldn't find any reference to this on google, and it's
> not urgent or anything; I just thought it might be helpful.
>
This simply means your CPU0 is uptodate, there is no need to update
anything. Don't worry about it.
Regards
Tigran
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Saturday 27 April 2002 9:03 pm, Tigran Aivazian wrote:
> You could have asked the author of the driver (myself) or the author of
> microcode_ctl (Simon Trimmer) before giving your "authoritative" answer :)
No, that would have been too sensible :)
> The default location is /etc/microcode.dat but distributions are free to
> put it anywhere they like, e.g. Red Hat puts it in
> /etc/firmware/microcode.dat
Yes; I have long since lost track of which parts of my system are debian and
which are not. Roy: sorry for any confusion.
*MatthewM*
- --
"You can't get very far in this world without your dossier being there first."
- -- Arthur Miller
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE8ywVPoVQMDIAmueURAo2oAKCb1JYCRuac1A7boyYnvj88j5WlWgCgiKFO
wHOpw6INae9bQgSf25pck4w=
=LZdS
-----END PGP SIGNATURE-----
On Sat, 27 Apr 2002, Matthew M wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Saturday 27 April 2002 8:51 pm, RS wrote:
> > ok
> >
> > running redhat, I have no microcode_ctl. but still, the kernel tells me
> > 'IA-32 Microcode Update Driver: v1.09 <[email protected]>' during boot.
> >
> > where can i find it? Do I need it?
>
> microcode_ctl is the userland utility which actually soed the uploading of
> microcode. You will need to get the appropriate package, and this will come
if he is running latest Red Hat beta then it is part of kernel-utils
package:
$ rpm -qif /sbin/microcode_ctl
Name : kernel-utils Relocations: (not relocateable)
Version : 2.4 Vendor: Red Hat, Inc.
Release : 7.4 Build Date: Tue 02 Apr 2002 18:22:09 BST
Install date: Thu 25 Apr 2002 10:32:35 BST Build Host: stripples.devel.redhat.com
Group : System Environment/Base Source RPM: kernel-utils-2.4-7.4.src.rpm
Size : 624523 License: GPL
Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
URL : http://www.urbanmyth.org/microcode/
Summary : Kernel and Hardware related utilities
Description :
kernel-utils contains several utilities that can be used to control
the kernel or your machines hardware. Included are
* dmidecode - gives information about the bios and motherboard revisisons
* microcode_ctl - updates the microcode on Intel cpu's
* smartctl - monitor the health of your disks
> with microcode.dat - then you should actually be able to update your
> microcode. The message in your kernel log is just the driver initialisation.
>
> *MatthewM*
> - --
>
> Sometimes love ain't nothing but a misunderstanding between two fools.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.6 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
>
> iD8DBQE8ywOfoVQMDIAmueURAvGVAJ95OFzC163RQ0veUPfndUqy7QzuWQCeOTKS
> J9hy4k+y8O67Fnk5vPn9R6s=
> =z/wB
> -----END PGP SIGNATURE-----
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
> > > where can i find it? Do I need it?
> >
> > microcode_ctl is the userland utility which actually soed the uploading of
> > microcode. You will need to get the appropriate package, and this will come
>
> if he is running latest Red Hat beta then it is part of kernel-utils
> package:
ok. so what the kernel is telling me during boottime (IA-32 Microcode
Update Driver: v1.09 <[email protected]>), is simply having the driver to
enable such uploads? It'd be great to have this documented openly
somewhere.
Thanks guys
roy
--
Roy Sigurd Karlsbakk, Datavaktmester
Computers are like air conditioners.
They stop working when you open Windows.
On Sat, 27 Apr 2002, Roy Sigurd Karlsbakk wrote:
> ok. so what the kernel is telling me during boottime (IA-32 Microcode
> Update Driver: v1.09 <[email protected]>), is simply having the driver to
> enable such uploads? It'd be great to have this documented openly
> somewhere.
The message means that the driver has registered a device
/dev/cpu/microcode with your kernel. Looking in /proc/misc you discover
that it is registered on minor 184 as a "misc" driver:
# modprobe microcode
# dmesg | tail -1
IA-32 Microcode Update Driver: v1.11 <[email protected]>
# cat /proc/misc
184 microcode
135 rtc
1 psaux
134 apm_bios
There is nothing special about microcode driver in this respect -- it is
just like any other device driver. I.e. userspace application opens the
device node /dev/cpu/microcode and writes the microcode data to it and,
possibly, uses an ioctl to free the memory (if the user isn't interested
in keeping a copy of what has been applied to each cpu).
Regards
Tigran
[email protected] wrote:
> In article <m171Yag-000Ga6C@Wasteland> you wrote:
>
>>On Saturday 27 April 2002 7:57 pm, Roy Sigurd Karlsbakk wrote:
>>
>>>Sorry if this is a FAQ, but where's the microcode.dat supposed to be
>>>placed? I can't find any information about that in the doc.
>>>
>>/usr/share/misc/microcode.dat
>>
>
> hum doesn't the FHS specify that /usr/share shouldn't contain arch
> specific files ? microcode.dat I can't really call arch neutral....
Right! But is not a configuration file (in /etc/, like the original sources
and RH). So it should be in /usr/lib (or in /usr/include, it is really a C/C++
file, but now we don't use it as a C file).
Anyway, I will no change the location [1]. The file is a nearly a C file, so
no problems with other archs. I see it as the man pages of lilo, and other
arch specific program. They are in /usr/share, readable by all arch,
but not so usefull on other arch.
giacomo
PS: Do you maintain the RH kernel-utils ?
[1] until I find a good new location in FHS
Giacomo Catenazzi wrote:
>
> [email protected] wrote:
>
> > In article <m171Yag-000Ga6C@Wasteland> you wrote:
> >
> >>On Saturday 27 April 2002 7:57 pm, Roy Sigurd Karlsbakk wrote:
> >>
> >>>Sorry if this is a FAQ, but where's the microcode.dat supposed to be
> >>>placed? I can't find any information about that in the doc.
> >>>
> >>/usr/share/misc/microcode.dat
> >>
> >
> > hum doesn't the FHS specify that /usr/share shouldn't contain arch
> > specific files ? microcode.dat I can't really call arch neutral....
>
> Right! But is not a configuration file (in /etc/, like the original sources
> and RH). So it should be in /usr/lib (or in /usr/include, it is really a C/C++
> file, but now we don't use it as a C file).
It's an ascii file for "configuring" the cpu. So I put it in /etc, some
sound firmware
is there anyway (not shipped by RHL but some vendors put it there)
> PS: Do you maintain the RH kernel-utils ?
yes
> [1] until I find a good new location in FHS
Once I hear a good FHS location I'll change it over to it as well,
/etc/firmware sounded as good as any to me ;(