Messages in this thread |  | | Date | Sun, 16 Sep 2001 09:21:49 +0200 | From | Steffen Persvold <> | Subject | Re: Athlon: Try this (was: Re: Athlon bug stomping #2) |
| |
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 - 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/
|  |