Hello,
I have received and tested the latest microcode data file from Intel, The
file is dated 2nd September 2004. You can download it both as standalone
(bzip2-ed) text file and bundled with microcode_ctl utility from the
Download section of the website:
http://urbanmyth.org/microcode/
Please let me know if you find any problems with this data file or with
the Linux microcode driver. Thank you.
Kind regards
Tigran
On Thu, 9 Sep 2004 17:32:10 +0100 (BST), Tigran Aivazian
<[email protected]> wrote:
> Hello,
>
> I have received and tested the latest microcode data file from Intel, The
> file is dated 2nd September 2004. You can download it both as standalone
> (bzip2-ed) text file and bundled with microcode_ctl utility from the
> Download section of the website:
>
> http://urbanmyth.org/microcode/
>
> Please let me know if you find any problems with this data file or with
> the Linux microcode driver. Thank you.
>
> Kind regards
> Tigran
>
> -
> 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/
>
Could you give me a quick description of what exactly this does?
-DaMouse
--
I know I broke SOMETHING but its there fault for not fixing it before me
> I have received and tested the latest microcode data
> file from Intel, The file is dated 2nd September
> 2004.
Aha! And this microcode file actually contains data
for my dual P4 Xeons (HT):
IA-32 Microcode Update Driver: v1.14 <tigran@xxxx>
microcode: CPU2 updated from revision 0x18 to 0x22,
date = 03242004
microcode: CPU1 updated from revision 0x18 to 0x22,
date = 03242004
microcode: CPU0 updated from revision 0x18 to 0x22,
date = 03242004
microcode: CPU3 updated from revision 0x18 to 0x22,
date = 03242004
The July 27th offering didn't contain anything for
these CPUs at all. In fact, the July file was
suspiciously smaller than the one from 16th March.
Chris
___________________________________________________________ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com
Tigran Aivazian wrote:
> Hello,
>
> I have received and tested the latest microcode data file from Intel, The
> file is dated 2nd September 2004. You can download it both as standalone
> (bzip2-ed) text file and bundled with microcode_ctl utility from the
> Download section of the website:
>
> http://urbanmyth.org/microcode/
>
> Please let me know if you find any problems with this data file or with
> the Linux microcode driver. Thank you.
Why are you using /dev/cpu/microcode instead of /dev/cpu/N/microcode for
each CPU? Today they are all the same device, but for the future I would
think this was an obvious CYA.
--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
On Fri, 10 Sep 2004, Bill Davidsen wrote:
> Tigran Aivazian wrote:
> > Hello,
> >
> > I have received and tested the latest microcode data file from Intel, The
> > file is dated 2nd September 2004. You can download it both as standalone
> > (bzip2-ed) text file and bundled with microcode_ctl utility from the
> > Download section of the website:
> >
> > http://urbanmyth.org/microcode/
> >
> > Please let me know if you find any problems with this data file or with
> > the Linux microcode driver. Thank you.
>
> Why are you using /dev/cpu/microcode instead of /dev/cpu/N/microcode for
> each CPU? Today they are all the same device, but for the future I would
> think this was an obvious CYA.
I have two questions:
1. What does "CYA" mean?
2. How do you know which device nodes exist on my workstation?
Actually, I am using /dev/cpu/0/microcode as the device node (entry point
into the microcode driver) because that is what is in the distribution I
am running (old Red Hat).
The microcode_ctl utility had a hardcoded default "/dev/cpu/microcode" and
there is no real reason to change it because different distributions
prefer a different value, so how to decide who is "right"?
Also, there is no obvious reason why the future has to be in any way
different from the present (or the past :)
Kind regards
Tigran
Bill Davidsen wrote:
> Why are you using /dev/cpu/microcode instead of /dev/cpu/N/microcode for
> each CPU? Today they are all the same device, but for the future I would
> think this was an obvious CYA.
Potentially stupid question, how does microcode update interact with CPU
hotplug?
Nathan
On Gwe, 2004-09-10 at 16:46, Tigran Aivazian wrote:
> 2. How do you know which device nodes exist on my workstation?
I'm interested how he knows which CPU's are the same too. Only the
microcode driver can really handle the uglies there with HT.
> The microcode_ctl utility had a hardcoded default "/dev/cpu/microcode" and
> there is no real reason to change it because different distributions
> prefer a different value, so how to decide who is "right"?
Documentation/devices.txt aka LANANA
On Fri, 10 Sep 2004, Nathan Bryant wrote:
> Potentially stupid question, how does microcode update interact with CPU
> hotplug?
CPU hotplug? Is there such a thing as _working_ CPU hotplug support in
Linux? (or any hardware that can actually allow unplugging/plugging CPUs?)
Kind regards
Tigran
In a 1.5K blaze of typing glory, Tigran Aivazian wrote:
> On Fri, 10 Sep 2004, Bill Davidsen wrote:
>
> > Tigran Aivazian wrote:
> > > Hello,
> > >
> > > I have received and tested the latest microcode data file from Intel, The
> > > file is dated 2nd September 2004. You can download it both as standalone
> > > (bzip2-ed) text file and bundled with microcode_ctl utility from the
> > > Download section of the website:
> > >
> > > http://urbanmyth.org/microcode/
> > >
> > > Please let me know if you find any problems with this data file or with
> > > the Linux microcode driver. Thank you.
> >
> > Why are you using /dev/cpu/microcode instead of /dev/cpu/N/microcode for
> > each CPU? Today they are all the same device, but for the future I would
> > think this was an obvious CYA.
>
> I have two questions:
>
> 1. What does "CYA" mean?
Cover Your Ass.
[snippage]
Kurt
--
Green light in a.m. for new projects. Red light in P.M. for traffic
tickets.
On Fri, 10 Sep 2004, Alan Cox wrote:
> > The microcode_ctl utility had a hardcoded default "/dev/cpu/microcode" and
> > there is no real reason to change it because different distributions
> > prefer a different value, so how to decide who is "right"?
>
> Documentation/devices.txt aka LANANA
Ok, in that case microcode_ctl is right about "/dev/cpu/microcode" and
distributions need to change to match it. Indeed, it always seemed silly
to me to "pretend" that the microcode device node is "per cpu" in some
sense (as it is impossible under Linux to bind userspace app to a given
cpu then there is no "good" sense in which "per cpu" node can be defined).
Kind regards
Tigran
On Gwe, 2004-09-10 at 16:47, Nathan Bryant wrote:
> Potentially stupid question, how does microcode update interact with CPU
> hotplug?
You run the microcode update sequence after a CPU is plugged in. That
might be an argument for having user space kick off application use of
hotplugged processors so that some housekeeping can run first.
In the ideal case your BIOS vendor ships you needed BIOS updates to
handle such things and in a sane format.
* Tigran Aivazian ([email protected]) wrote:
> sense (as it is impossible under Linux to bind userspace app to a given
> cpu then there is no "good" sense in which "per cpu" node can be defined).
sched_setaffinity(2) allows you to bind a userspace app to a given cpu.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
> CPU hotplug? Is there such a thing as _working_ CPU hotplug support in
> Linux? (or any hardware that can actually allow unplugging/plugging CPUs?)
Sure, on ppc64 we move CPUs between partitions on the fly and use
hotplug cpu tricks with POWER5 threads to switch between single
threaded mode and SMT mode while the OS is running.
Anton
On Thursday 09 September 2004 18:32, Tigran Aivazian wrote:
> Hello,
>
> I have received and tested the latest microcode data file from Intel, The
> file is dated 2nd September 2004. You can download it both as standalone
> (bzip2-ed) text file and bundled with microcode_ctl utility from the
> Download section of the website:
>
> http://urbanmyth.org/microcode/
>
> Please let me know if you find any problems with this data file or with
> the Linux microcode driver. Thank you.
>
> Kind regards
> Tigran
i read about intel microcode upgrade before, but i never tried it. so my
question is, are there any reasons why somebody should upgrade his microcode?
i know that intel does not hand out a changelog, but maybe anybody knows more
about it. thx in advance!
best regards,
dominik
On Fri, 10 Sep 2004, Chris Wright wrote:
> * Tigran Aivazian ([email protected]) wrote:
> > sense (as it is impossible under Linux to bind userspace app to a given
> > cpu then there is no "good" sense in which "per cpu" node can be defined).
>
> sched_setaffinity(2) allows you to bind a userspace app to a given cpu.
>
Interesting, thank you, I didn't know that it is already possible to do
this.
Kind regards
Tigran
On Fri, 10 Sep 2004, Tigran Aivazian wrote:
> On Fri, 10 Sep 2004, Bill Davidsen wrote:
>
> > Tigran Aivazian wrote:
> > > Hello,
> > >
> > > I have received and tested the latest microcode data file from Intel, The
> > > file is dated 2nd September 2004. You can download it both as standalone
> > > (bzip2-ed) text file and bundled with microcode_ctl utility from the
> > > Download section of the website:
> > >
> > > http://urbanmyth.org/microcode/
> > >
> > > Please let me know if you find any problems with this data file or with
> > > the Linux microcode driver. Thank you.
> >
> > Why are you using /dev/cpu/microcode instead of /dev/cpu/N/microcode for
> > each CPU? Today they are all the same device, but for the future I would
> > think this was an obvious CYA.
>
> I have two questions:
>
> 1. What does "CYA" mean?
Cover Your Ass - or more politely, plan for likely future changes if there
isn't a high cost doing so.
>
> 2. How do you know which device nodes exist on my workstation?
I don't need to... the stat() call will tell me. If a /dev/cpu/0/microcode
exists it is more likely to be the correct loader for CPU0 than some
generic loader. Obviously if the user provides a name use it.
>
> Actually, I am using /dev/cpu/0/microcode as the device node (entry point
> into the microcode driver) because that is what is in the distribution I
> am running (old Red Hat).
That's exactly why I mentioned using the per-cpu device if present. While
having CPUs with different loaders is not a feature today, I wouldn't bet
that will always be true. We know that AMD expects to ship dual core CPUs
in an Opteron form factor. If I have a dual opteron system and replace one
CPU with dual core, will I need a different loader? I have no idea, but
since it's easy to use the per-CPU microcode I would.
>
> The microcode_ctl utility had a hardcoded default "/dev/cpu/microcode" and
> there is no real reason to change it because different distributions
> prefer a different value, so how to decide who is "right"?
The obvious seems to be to see if the per-CPU device is present, and use
it if possible. I can't believe that it would be (by design) less correct
than the generic device.
>
> Also, there is no obvious reason why the future has to be in any way
> different from the present (or the past :)
Your distro and mine already have per-CPU microcode, that's the present.
Lots of people just compile and run, that's the present. It's easy to
check for /dev/cpu/N/micorcode first, then /dev/cpu/microcode, I think
that's the future. I just like having code try a little harder to do the
right thing, Linux should be easy.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
On Wed, 15 Sep 2004, Bill Davidsen wrote:
> That's exactly why I mentioned using the per-cpu device if present. While
> having CPUs with different loaders is not a feature today, I wouldn't bet
> that will always be true. We know that AMD expects to ship dual core CPUs
> in an Opteron form factor. If I have a dual opteron system and replace one
> CPU with dual core, will I need a different loader? I have no idea, but
> since it's easy to use the per-CPU microcode I would.
The microcode driver handles the case of different types of CPUs in an SMP
system internally. Namely, it selects the appropriate microcode data
chunks for each CPU and then uploads them correctly to each one. Anyway,
it only works for Intel processors, so AMD is not in the equation anyway
(unless I discover that AMD processors support similar feature and enhance
the driver to support it).
Kind regards
Tigran
On Wed, Sep 15, 2004 at 04:43:59PM +0100, Tigran Aivazian wrote:
> The microcode driver handles the case of different types of CPUs in an SMP
> system internally. Namely, it selects the appropriate microcode data
> chunks for each CPU and then uploads them correctly to each one. Anyway,
> it only works for Intel processors, so AMD is not in the equation anyway
> (unless I discover that AMD processors support similar feature and enhance
> the driver to support it).
They do support the feature, but AMD folks have stated on this list that they
don't intend to release any updates other than through their
conventional means (Ie, BIOS updates).
There was a post just 2-3 weeks ago where someone patched microcode.c to
work on AMD64s.
Dave
Dave Jones wrote:
> On Wed, Sep 15, 2004 at 04:43:59PM +0100, Tigran Aivazian wrote:
>
> > The microcode driver handles the case of different types of CPUs in an SMP
> > system internally. Namely, it selects the appropriate microcode data
> > chunks for each CPU and then uploads them correctly to each one. Anyway,
> > it only works for Intel processors, so AMD is not in the equation anyway
> > (unless I discover that AMD processors support similar feature and enhance
> > the driver to support it).
Okay, then there was no need to patch the load program other than "it
makes me feel better" to use the per-CPU loader if present ;-) I've
spent more time for less benefit on other software, so I don't feel bad.
>
> They do support the feature, but AMD folks have stated on this list that they
> don't intend to release any updates other than through their
> conventional means (Ie, BIOS updates).
That's fine as long as you run some approved BIOS, your vendor provides
timely updates, etc. Having been on the wrong end of a few cases where a
BIOS "upgrade" broke something, I confess to liking the separation of
functionality.
>
> There was a post just 2-3 weeks ago where someone patched microcode.c to
> work on AMD64s.
--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me