Well, I want to add some confusion into this thread...
> We definitely need more data points too. So far we dont have any athlon.c
> data for kt133a with the bit on and off, only kt133.
... I have at home Asus A7V (with KT133, non A), it has register 0x55
set to 0x89 and I thought that it works fine. I modified athlon.c
so that it fills buffer with random data on start, and then it compares
results of copy_page. And after about 10th run with 0x89 promise
driver told me that func:13 (not 14...) is not supported and all HDDs
became inaccessible. After reboot portion of /usr/include/bits (and
few other) was overwritten with 0xFF... I was not able to recreate
this problem after that crash (but I did not tried too hard, as I have
important data on my hdds, and all hdds attached to promise were
affected, not only one which was 'active' before crash (I was doing
compilation & logged outputs on secondary master, but primary master
was corrupted...)
After fsck, reinstalling libc6-dev and apache-doc, I started playing
with 0x55 bits and found that bits 0x80 and 0x01 have no effect on
performance, but CLEARING bit 0x08 increases my motherboard performace
by 1% (I'm getting very consistent results, they vary around +-10 cycles,
with 12200 cycles with 0x08 and 12060 with 0x00 in register 0x55).
So I personally will apply this patch even on my KT133... And just
for completness, kernel 2.4.9-ac10 (with AMD opts), Athlon 1GHz, two
singlesided 128MB DIMMs, interleaving enabled (disabling slows down
K7 copy page system by 4%).
Best regards,
Petr Vandrovec
vandrove@vc.cvut.cz
-
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/