Re: Latest microcode data from Intel

Re: Latest microcode data from Intel

[watermodem]

A bit of a bug somewhere here...   If it is my mistake by having
the linux link pointing to ...
   linux -> linux-2.6.8.1/
sorry...  (I don't remember which libs were proper)
If it is not that... then the package has a bug.

Error:

rpm -U /usr/src/RPM/RPMS/i586/microcode_ctl-1.09-1.i586.rpm
error: %preun(microcode_ctl-1.06-6mdk) scriptlet failed, exit status 1


Leading up to this was:
rpmbuild -ta microcode_ctl-1.09.tar.gz
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.76578
+ umask 022
+ cd /usr/src/RPM/BUILD
+ cd /usr/src/RPM/BUILD
+ rm -rf microcode_ctl-1.09
+ /usr/bin/gzip -dc /home/watermod/Documents/microcode_ctl-1.09.tar.gz
+ tar -xf -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd microcode_ctl-1.09
+ exit 0
Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.76578
+ umask 022
+ cd /usr/src/RPM/BUILD
+ cd microcode_ctl-1.09
+ make
gcc -g -Wall -O2 -I /usr/src/linux/include -o microcode_ctl microcode_ctl.c
In file included from /usr/src/linux/include/asm/processor.h:18,
                  from microcode_ctl.c:30:
/usr/src/linux/include/asm/system.h: In function `__set_64bit_var':
/usr/src/linux/include/asm/system.h:193: warning: dereferencing 
type-punned pointer will break strict-aliasing rules
/usr/src/linux/include/asm/system.h:193: warning: dereferencing 
type-punned pointer will break strict-aliasing rules
In file included from microcode_ctl.c:30:
/usr/src/linux/include/asm/processor.h: In function `load_esp0':
/usr/src/linux/include/asm/processor.h:453: warning: implicit 
declaration of function `unlikely'
echo "/etc/init.d/microcode_ctl" > microcode-filelist
+ exit 0
Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.91789
+ umask 022
+ cd /usr/src/RPM/BUILD
+ cd microcode_ctl-1.09
+ '[' /var/tmp/microcode_ctl-1.09-root '!=' / ']'
+ '[' -d /var/tmp/microcode_ctl-1.09-root ']'
+ make DESTDIR=/var/tmp/microcode_ctl-1.09-root PREFIX=/usr install clean
install -d      /var/tmp/microcode_ctl-1.09-root/usr/sbin 
/var/tmp/microcode_ctl-1.09-root/etc \
                 /var/tmp/microcode_ctl-1.09-root/usr/man/man8 
/var/tmp/microcode_ctl-1.09-root/etc/init.d \
                 /var/tmp/microcode_ctl-1.09-root
install -s -m 755 microcode_ctl /var/tmp/microcode_ctl-1.09-root/usr/sbin
install -m 644 intel-ia32microcode-02Sep2004.txt 
/var/tmp/microcode_ctl-1.09-root/etc/microcode.dat
install -m 644 microcode_ctl.8 /var/tmp/microcode_ctl-1.09-root/usr/man/man8
gzip -9f /var/tmp/microcode_ctl-1.09-root/usr/man/man8/microcode_ctl.8
install -m 755 microcode_ctl.start 
/var/tmp/microcode_ctl-1.09-root/etc/init.d/microcode_ctl
echo "MAKE: Skipping chkconfig operation (rpm build?)"
MAKE: Skipping chkconfig operation (rpm build?)
rm -f microcode_ctl
+ /usr/lib/rpm/brp-mandrake
Cleaning files...done
Compressing files...done
Stripping files...done
Relativisation of symlinks...done
Clean perl...done
Building libraries symlinks...done
Gprintifying init scripts...done
Processing files: microcode_ctl-1.09-1
Finding  Provides: /usr/lib/rpm/filter.sh ' ' /usr/lib/rpm/find-provides
Using BuildRoot: /var/tmp/microcode_ctl-1.09-root to search libs
Finding  Requires: /usr/lib/rpm/filter.sh ' ' /usr/lib/rpm/find-requires 
/var/tmp/microcode_ctl-1.09-root i586
Requires(interp): /bin/sh /bin/sh
Requires(rpmlib): rpmlib(PayloadFilesHavePrefix) <= 4.0-1 
rpmlib(CompressedFileNames) <= 3.0.4-1
Requires(post): /bin/sh
Requires(preun): /bin/sh
Requires: bash libc.so.6 libc.so.6(GLIBC_2.0) libc.so.6(GLIBC_2.1)
Checking for unpackaged file(s): /usr/lib/rpm/check-files 
/var/tmp/microcode_ctl-1.09-root
Wrote: /usr/src/RPM/SRPMS/microcode_ctl-1.09-1.src.rpm
Wrote: /usr/src/RPM/RPMS/i586/microcode_ctl-1.09-1.i586.rpm
Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.99129
+ umask 022
+ cd /usr/src/RPM/BUILD
+ cd microcode_ctl-1.09
+ '[' /var/tmp/microcode_ctl-1.09-root '!=' / ']'
+ '[' -d /var/tmp/microcode_ctl-1.09-root ']'
+ rm -r /var/tmp/microcode_ctl-1.09-root
+ exit 0

RE: Latest microcode data from Intel.

[Chris Rankin]

> 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

Latest microcode data from Intel.

[Tigran Aivazian]

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

Re: Latest microcode data from Intel.

[DaMouse]

On Thu, 9 Sep 2004 17:32:10 +0100 (BST), Tigran Aivazian
<tigran@veritas.com> 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 majordomo@vger.kernel.org
> 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

Re: Latest microcode data from Intel.

[Bill Davidsen]

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 (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: Latest microcode data from Intel.

[Tigran Aivazian]

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

Re: Latest microcode data from Intel.

[Alan Cox]

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

Re: Latest microcode data from Intel.

[Tigran Aivazian]

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

Re: Latest microcode data from Intel.

[Chris Wright]

* Tigran Aivazian (tigran@veritas.com) 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

Re: Latest microcode data from Intel.

[Tigran Aivazian]

On Fri, 10 Sep 2004, Chris Wright wrote:

> * Tigran Aivazian (tigran@veritas.com) 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

Re: Latest microcode data from Intel.

[Kurt Wall]

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.

Re: Latest microcode data from Intel.

[Bill Davidsen]

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 <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: Latest microcode data from Intel.

[Tigran Aivazian]

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

Re: Latest microcode data from Intel.

[Dave Jones]

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

Re: Latest microcode data from Intel.

[Bill Davidsen]

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 (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: Latest microcode data from Intel.

[Nathan Bryant]

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

Re: Latest microcode data from Intel.

[Alan Cox]

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.

Re: Latest microcode data from Intel.

[Tigran Aivazian]

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

Re: Latest microcode data from Intel.

[Anton Blanchard]

 
> 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

Re: Latest microcode data from Intel.

[Dominik Karall]

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