RE: Loading Pentium III microcode under Linux - catch 22!

RE: Loading Pentium III microcode under Linux - catch 22!

[Nakajima, Jun]

One issue with doing it in lilo or grub is that we need to apply
microcode update to each (physical) CPU. So we need to change the
current driver structure if we want to move it to the boot loader. So
one of the other ways is:
1. Boot loader copies update to memory
2. Kernel applies update soon after it brings the processors (including
BP, and APs) online in init_intel() or something like that. 

We don't need IPI or even the microcode update driver if we do this. But
I think putting it in initrd should be sufficient.

Thanks,
Jun

> -----Original Message-----
> From: Alan Cox [mailto:alan@lxorguk.ukuu.org.uk]
> Sent: Thursday, August 07, 2003 8:55 AM
> To: Tigran Aivazian
> Cc: Chris Rankin; Linux Kernel Mailing List
> Subject: Re: Loading Pentium III microcode under Linux - catch 22!
> 
> On Iau, 2003-08-07 at 16:57, Tigran Aivazian wrote:
> > I could implement this, but if you tell me that this is not allowed
> > because of the GPL issues (microcode data chunks are copyrighted by
> Intel)
> > then obviously I won't waste time writing the code to do this.
> 
> Thats something we are moving away from, so that we can load firmware
> from the initrd. Another interesting place to tackle it might be in
lilo
> or grub ?
> 
> -
> 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/

RE: Loading Pentium III microcode under Linux - catch 22! BOARD NOW STABLE!

[Chris Rankin]

 --- "Nakajima, Jun" <jun.nakajima@intel.com> wrote:
> We don't need IPI or even the microcode update
> driver if we do this. But I think putting it in
> initrd should be sufficient.

Well, I don't know about "sufficient". Someone on
"www.hardwareanalysis.com" suggested underclocking my
CPUs. So my dual 933 MHz CPUs are now running at 700
MHz (FSB changed from 133 MHz to 100 MHz) and
everything has been fine for the past 3 hours; same
load as when everything hit the fan last week too. Of
course, the CPUs run cooler like this, so I can't
ignore the thermal element...

$ more /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 8
model name      : Pentium III (Coppermine)
stepping        : 6
cpu MHz         : 696.033
cache size      : 256 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8
apic sep mtrr pge mca cmov 
pat pse36 mmx fxsr sse
bogomips        : 1389.36

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 6
model           : 8
model name      : Pentium III (Coppermine)
stepping        : 6
cpu MHz         : 696.033
cache size      : 256 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8
apic sep mtrr pge mca cmov 
pat pse36 mmx fxsr sse
bogomips        : 1389.36

The correct microcode has been loaded successfully:

IA-32 Microcode Update Driver: v1.11
<tigran@veritas.com>
microcode: CPU0 updated from revision 0 to 7,
date=05052000
microcode: CPU1 updated from revision 0 to 7,
date=05052000

This was not done from initrd (yet). However, I should
probably point out that 4 weeks ago, I *must* have
successfully loaded the microcode from rc.sysinit in
order for the box to survive for the next 3 weeks.

Now throughout all these problems, Linux has never
locked up before this message has appeared in the boot
log:

Freeing unused kernel memory: 108k freed

However, it seems that it can crash at any point
afterwards. (I never had to wait too long either,
although it seemed that the more work the box did, the
quicker it crashed.)

The conclusions from all this seem to be:
- Linux was crashing due to an incorrect
CPU/motherboard interaction.
- the current microcode for these CPUs does not fix
the problem, although it might reduce it (literally
weather permitting).

I spoke to Supermicro about this i840 board (PIIIDME)
last year, and all BIOS development has stopped. The
best they could offer me was my existing BIOS
containing the new microcode (which I already have).

Given the information at hand, my options would seem
to be:
a) reinstall the original 733 MHz CPUs, accepting that
this is the best that the board can do. These CPUs
would need the FSB putting back to 133 MHz so it's not
exactly a "slam-dunk" success. However, I have run
them  successfully in hot weather before, so I'm
reasonably confident that they would work now.
b) relocate close to one of the Earth's Poles, where
seasonal temperatures are more favourable to CPUs.

Stablising the 933 MHZ CPUs on this board properly
would appear to need extra help from Intel. Judging by
what I've seen, Linux does seem to have a window in
its boot sequence when any extra workaround could
safely be applied.

Cheers,
Chris

P.S. I'm now going to set up an initrd anyway out of
sheer bloody-mindedness ... ;-)


________________________________________________________________________
Want to chat instantly with your online friends?  Get the FREE Yahoo!
Messenger http://uk.messenger.yahoo.com/

RE: Loading Pentium III microcode under Linux - catch 22!

[Alan Cox]

On Iau, 2003-08-07 at 18:40, Nakajima, Jun wrote:
> One issue with doing it in lilo or grub is that we need to apply
> microcode update to each (physical) CPU. So we need to change the
> current driver structure if we want to move it to the boot loader.

Not really. The boot loader loads the kernel and initrd image and runs
the kernel. The initrd is a file system which can contain things like
the microcode loader and the microcode sets, just like it can contain
anything else.