Re: amd64 sata_nv (massive) memory corruption

[Alan Cox]

> I then did some more debugging, and isolated the original data corruption
> problem to a bad pair of RAM sticks. But this was subtle, so let me recap:
> 
> -- The bad ram passes memtest86+

You are assuming bad RAM then not bad bus loadings, corrosion on the
pins.. ?

> So I'm wondering: can we devise a test to validate system-bus interactions
> like this? Clearly, the memtest86 test validates the RAM and the northbridge
> bus between CPU and system RAM, so that seems OK.

If you have a good enough pile of hardware and the right monitoring stuff
loaded then you should get EDAC event logs from the PCI/PCI-X for PCI
card logged traps, MCE errors for the higher level busses, L1/L2 cache or
CPU parity errors and ECC traps for memory problems either via EDAC or
MCE.

If you are using a generic end user motherboard then you don't.

> doesn't exist. I have no clue about SATA.  Is there possibly some ide or
> scsi command that can be used to loop-back? Some sort of "send bytes
> to disk, but don't actually write them to platter" command? Maybe just
> a write to some scratch ram on the disk drive itself? Even just a few bytes

Yes for SCSI. In theory yes for ATA but I've never tested to see what the
level of actual support is, and I'm not sure you can test it in DMA mode.

> would be enough to implement a loopback test. Maybe some sort of

For the simpler cases perhaps. The more interesting approaches I think
are the fs level ones where you accept the fact that hardware sucks and
do end to end checksumming from the fs or even the app in some
situations. We don't yet have that functionality mainstream although it
might make an interesting device mapper module ...


Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/