I'm not sure whether this falls in the same category, but I've had two
data corruptions with 2.0.32 on an AMD K5/133 with Triton chipset.
Triton support was NOT compiled in, and interrupt unmasking hasn't
been turned on.
First time the emacs binary got corrupted, and cmp'ing it with a good
copy revealed a single almost contiguous 3 kbyte range which had any
differences -- looks like a single page. I restored the binary, then
two days later the same thing happend to perl. This time I replaced
the kernel with one which had Triton support, and did hdparm -u 1.
No problems since.
There were some reports of "hda IRQ timeout" in the logs at the time.
Filesystem structure was okay; fsck didn't complain.
/proc/pci and /proc/cpuinfo are attached at the end of this post. The
machine in question doesn't have anything unusual built in (except for
a Digi PC/8e multiport). The kernel was stock 2.0.32, compiled with
gcc 2.7.2.1.
i.
PCI devices found:
Bus 0, device 7, function 1:
IDE interface: Intel 82371SB Natoma/Triton II PIIX3 (rev 0).
Medium devsel. Fast back-to-back capable. Master Capable. Latency=32.
I/O at 0xf000.
Bus 0, device 7, function 0:
ISA bridge: Intel 82371SB Natoma/Triton II PIIX3 (rev 1).
Medium devsel. Fast back-to-back capable. Master Capable. No bursts.
Bus 0, device 0, function 0:
Host bridge: Intel 82437VX Triton II (rev 2).
Medium devsel. Master Capable. Latency=32.
processor : 0
cpu : 586
model : Pentium 60/66
vendor_id : AuthenticAMD
stepping : 1
fdiv_bug : no
hlt_bug : no
f00f_bug : no
fpu : yes
fpu_exception : yes
cpuid : yes
wp : yes
flags : fpu vme de pse tsc msr mce cx8 pge
bogomips : 199.88