Disk to disk copying with overclocked memory

On 15 Mar 2004 21:32:35 GMT, Arno Wagner wrote:
In comp.sys.ibm.pc.hardware.storage "cquirke (MVP Win9x)"
On Fri, 12 Mar 2004 19:54:41 GMT, kony wrote:

comp.sys.ibm.pc.hardware.storage, eh? Been long since I was there,
and have an "interesting" problem that may fit there if anyone's
interesting in FATxx data recovery.

If the DMA system errors while CPU access does not (think square wave
pulse edges, rise time, local charge pump capacitors etc.) then
MemTest86 et al may pass, while UIDE transfers may fail.

True. But DMA is usually far less agressive in its timing, so
this is a rather unlikely scenario.

That's an interesting observation. I first thought of this (and AGP)
issues when I had an old PCI / ISA system that was fine as long as you
didn't play digitised sound or use the diskette. A provocative test
that almost always blew that system up was to copy the Start Menu (or
any other collection of small files) to a diskette. BSoD !!

So I thought "what do digitisesd sound (even .wav playback in Sound
Recorder, while FM-only DOS games didn't turn a hair) and diskette
drives have in common?" and the answer that came to me was: DMA.

Then I realised that no matter how exhaustive RAM testing programs
are, they are still only testing CPU memory access.

But after all, it's only conjecture on my part.

Then again, it was new RAM that fixed the diskette-and-digital-sound
problem, even tho the rather useless RAM testing apps I was using at
that time passed the old RAM as fine.

Other possibilities:
- buggy VIA 686B Southbridge problem (eats UIDE data)
- bad or noisy UIDE data cables
That should cause CRC errors.
- bad cache RAM on the HD itself
- static buildup on ungrounded HD
No. The HDD is grounded through the power cable and through the
data cable. Unless the whole mainboard is not grounded properly.

At the time I had the minitower open and extrra HDs sitting outside
the case, not touching anything. That was my SOP at the time, and UI
found a whole series of scrape-overs had the same problems; Doom would
always crash, and there was one other app that also misbehaved.

In those DOSsy days, apps were well-behaved and lived purely in their
own directory trees. So to pass on an active shareware-and-demos
collection, you'd just bulk-copy the Games subtree.

Eventually, I did an FC /B on 500M of stuff and found two errors -
both being 32-bit runs of junk ("snakebites"). So I did the same 500M
bulk transfer a few times, and each time I'd get 0 to 4 (max)
snakebites, always 32-bits. Then I tried grounding the HD's shell (I
put an old metal slot break-out strip from shell to case) and the
problems went away, on two tests (I was suffering "test fatigue" by
then, hence only two tests!).

That was the mileage, and as the HDs of those times wren't hot and
fast monsters, I attributed it to static build up. Since then I
always ground the HD's shell to case, and SF,SG.

Strange. The hdd has two low-resistance paths to the chassis.
These should be enough.

Yep; it's odd. The old full-height monsters used to have grounding
tags (using auto-electronics cables!) and I used to laugh at that :-)

Maybe you where statically charged and touched the HDD? That
yould have induced a spike in some logic-lines...

No, I don't think so - I generally don't touch what I don't need to
touch, and tend to leave these bulk ops to run unattended.

-------------------- ----- ---- --- -- - - - -
Running Windows-based av to kill active malware is like striking
a match to see if what you are standing in is water or petrol.
-------------------- ----- ---- --- -- - - - -

P.S.: Like the sig!

Here's another to match g


-- Risk Management is the clue that asks:
"Why do I keep open buckets of petrol next to all the
ashtrays in the lounge, when I don't even have a car?"
----------------------- ------ ---- --- -- - - - -