AC> Several reports. Back down the BIOS version
Aha, we need to make kernel reprogram KT133A so that we won't be blamed
for BIOS flaws. Does anybody have a clue what's exactly changed in
chipset programming from YH to 3R BIOS? BIOSes are on
ftp://ftp.leo.org/pub/comp/general/devices/abit/bios/kt7/
>> ...
>> kernel_fpu_end();
>> + from-=4096;
>> + to-=4096;
>> + if(memcmp(from,to,4096)!=0) {
>> + printk("Athlon bug!"); //add printout of from,to,...?
>> + memcpy(to,from,4096);
>> + }
>> }
RJD> I then get 'Athlon bug!' Still oopses.
Waah! That means movntq's moved data to some other place in memory!
memcmp detected that and memcpy fixed, but that 'other place' was
corrupted and that's the cause of oops.
You may change printk to see when this happens:
printk(KERN_ERR "Athlon bug! from=%08X to=%08X\n", from, to);
If you do, please post from/to pairs printed to lkml.
>> Comparing K7 and MMX fast_copy_page...
>>
>> Does replacing movntq->movq makes oops go avay?
RJD> Yes, it does! Didn't tested exaustively, but it seems to go away!
This is a check to dismiss "bad PSU/memory/..." theories.
It is indeed CPU/chipset interaction bug fixable by chipset
programming.
RJD> As said earlier, this happens after upgrading from BIOS YH to 3R in the
RJD> KT7A-RAID. The processor is a Duron 800 not overclocked.
-- Best regards, VDA mailto:VDA@port.imtp.ilyichevsk.odessa.ua http://port.imtp.ilyichevsk.odessa.ua/vda/
- 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/