> I can't be the only one to have noticed that both the IDE and the SCSI
> disk corruption reports are coming from DMA driven controllers in every case.
Does that make DMA bad for disk IOs ? ;)
We must be aware that buses that donnot implement either parity or
CRC may lead to _silent_ data corruption.
And yes, all can be fine for the processor accessing the RAM and something
can be broken in some chipsets/controllers/drivers (and even the RAM) that
corrupts data while doing DMA in our back.
> Originally I thought that was chance but now Im wondering.
DMA is used for disk IOs since more than 25 years on real computers.
If this was a misfeature, we could'nt have missed it.
> Is anyone seeing file system corruption from non DMA devices - ie non DMA
> IDE, non DMA SCSI (AHA152x, AHA2920 etc) ?
Easy to achieve with SCSI.
1 - Hack a terminator so that REQ/ACK terminations remains fine but data
lines are only OK for asynchronous transfers but not for FAST
synchronous data transfers.
2 - Perform FAST synchronous data transfers without checking SCSI parity.
The result will be silent data corruption since the SCSI protocol only
uses asynchonous transfers that will work and the data transfers will
look fine to the controller and device since the REQ/ACK will also work.
By the way, SCSI BUSes that work with async transfers and are not broken
enough to break REQ/ACK pacing exist, and so silent data corruption on a
bad but looking fine SCSI BUS may be reported when parity is not checked.
Regards,
Gerard.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html