Re: Athlon: Try this (was: Re: Athlon bug stomping #2)

Steffen Persvold
2001-09-16T07:25:18Z

Petr Vandrovec wrote:
>
> > +static void __init pci_fixup_athlon_bug(struct pci_dev *d)
> > +{
> > + u8 v;
> > + pci_read_config_byte(d, 0x55, &v);
> > + if(v & 0x80) {
> > + printk(KERN_NOTICE "Stomping on Athlon bug.\n");
> > + v &= 0x7f; /* clear bit 55.7 */
> > + pci_write_config_byte(d, 0x55, v);
> > + }
> > +}
> >
> > Well, these are cosmetic changes anyway...
> > What is more important now:
> > 1) Do we have people who still see Athlon bug with the patch?
>
> Just by any chance - does anybody have KT133 (not KT133A)
> datasheet? I just noticed at home that my KT133 has reg 55 set
> to 0x89 and it happilly lives... So maybe some BIOS vendors
> used KT133 instead of KT133A BIOS image?

Hmm, I have a "KT133 Athlon Norbridge, Preliminary Revision 1.0 May 12, 2000"
PDF. Register 55 is described like this :

Device 0 Offset 55 Debug .............................................. RW
7-5 Reserved (do not program)...................... default = 0
4 Write Policy for CPU Write to DRAM
0 Issue DRAM write when FIFO holds more
than two requests of DRAM controller idle . def
1 Disable Write Policy
3-0 Reserved (do not program)...................... default = 0

Which doesn't explain things much more since the bits in question (7, 3, 0) is
marked as "Reserved".

I also have a question; if "movntq; sfence" type of memory copy can cause data
corruption in kernel space, it can in theory also do so in user space right ?
So, if I'm right this bug could also be on machines running a 2.2 kernel with
userspace programs using 3DNow (or SSE even) instructions.

Regards,
--
Steffen Persvold | Scalable Linux Systems | Try out the world's best
mailto:sp@scali.no | http://www.scali.com | performing MPI implementation:
Tel: (+47) 2262 8950 | Olaf Helsets vei 6 | - ScaMPI 1.12.2 -
Fax: (+47) 2262 8951 | N0621 Oslo, NORWAY | >300MBytes/s and <4uS latency