> "Because things are so much better now that the chance of a bug in the
> checking code causing trouble is higher than the chance of the hardware
> failing", perhaps?

Remembering a memory parity error problem that happened when DMA write,
DRAM refresh and (IIRC) IACK read happened in some sequence....

OTOH I've also seen a VMEbus board that had trouble writing certain
data patterns to system memory [1].  Since we were using an on-board
prototcol stack these errors happened AFTER all the checksums and
ended up in the data files being transferred.

After identifying the problem, I kept the board - I didn't want it getting
into the spares loop (no fault found!) and ending up on a customers system.

	David

[1] The repeated pattern 0xff, 0xff, 0x0 was effective!  Fault was probably
due to ground bounce.

-- 
David Laight: david@l8s.co.uk