K8N Neo corrupts data - should I RMA?

Question

Mobo: K8N Neo Platinum
AMD 3000+
1 GB memory (Generic)
Primary IDE: 160GB maxtor and DVD (in that order)
Secondard IDE: 160GB maxtor (same model) and DVD (in that order)
SATA 1 to 4: 250 GB maxtor (same model on each)
So that's 6 hard disks and 2 DVDs in total.
Greaphics: Asus v9400 magic
NOT overclocked!
BIOSes tried 1.1 and 1.3
After my 20th (or 30th) install of Win 2003, I've finally concluded, I think, that I have a faulty mobo, unless soemone has any good ideas. Basically, if I copy large quantities (say 2GB or more) of data to the device on SATA3 or SATA4, the data corrupts. No errors in the event log, but apps fail to work randomly, and a binary file comparison definiitely shows the corrupt file is not the same as the source. (usualoly by one bit only).
OK. Here's what I've tried:
1. Swapping hard disks around. Result: it's always the device on SATA3 and SATA4 that fails.
2. Swapping SATA cables. Result: No difference.
3. Doing large quantities of data moving on the other drives: Result: no problemo on IDEs and SATA1/2.
4. I've followed the instructions in the FAQ (the rsheppick one that instructs to set up the disks as raid 0 stripes even if they're single disks and use the Nvidia drivers). result: Still corrupts on SATA3/4.
5. I've also disabled the raid bios and used the Nvidia IDE s/w drivers. Same result.
6. I've disabled the RAID bios and used the MS drivers: same result.
7. In case anyone asks: no I'm not overclocking!
8. Just for fun, I've also set up various RAID configuraytions in hardware and software and the bottom line is that any array that uses SATA3/4 gets data corruption.
9. There's no other hardware in the machine other than what's mentioned.
10. I've tried all combinations of BIOSes 1.1, 1.3 and NVidia IDE drivers 2.5 and 2.6. result: always a corruption on SATA3/4.
The annoying this is   that because there were no errors when the system was installed and got up and running, it's been a pain to locate the problem of the various app crashes. (The OS has always been on the IDE channels and hasn't been a problem.)
Questions:
1. Has anyone else found the same problem? WARNING: if it's a bad batch of mobos or a design fault then there could be lots of people with this problem that don't know it!
2. Any other ideas? Just a faulty mobo?
Cheers
Mark

Answer 1

Several of us have reported data corruption with nForce 4 based motherboards.
I'd like to share my experiences with you. I hope nVidia's & MSI's experts read this forum and finally offer us the right solution.
In short:
Some random data data corruption happens if a motherboard is stressed with DMA transfers (about 2 or 3 bytes altered out of  ~5 GBytes). The operating system does not log any error.
You copy a file of some GBytes, you compare them e.g. with the "comp" command in a DOS window, and the two files wont be the same. You repeat comparing them: you may see different errors at different file offsets each time. It seems to be a random error.
You can reproduce this error under Linux, too, e.g. SuSE 9.3.
I think data corruption happens when the DMA writes the memory.
- If disk writes (DMA memory reads) were broken, then once the file copy is carried out (with some errors), you would always see the same errors when comparing the two files repeatedly.
- I moved a disk of mines to an "old" machine, I created some files (big RAR-s) and double-checked them on that machine. Moving back, the files seem to be corrupted.
It is funny to see that it is always the byte at the offset hexadecimal 0x1d8 (out of the 512 = 0x200 byte long disk sectors) that is altered by 0x10, e.g. 0x2f becomes 0x3f or vice versa.
My HW-SW configuration:
- MSI K8N Neo4 Platinum MS-7125 ver: 1
- AMD Athlon 64 3700++
- 2 * 512 MByte Kingston DDR 400 MHz PC3200
- Leadtek PX6600 GT
- 2 * Maxtor DiamonMax Plus 10, 250 GBytes
- BIOS updated to 1.90, factory optimized defaults
- Windows XP pro + SP2 + nForce_amd_6.66.WinXP2K_international.e xe
- SuSE Linux 9.3
The data corruption error can be reproduced with both RAID-ed and singe disks.
Just to make sure no other HW component can be blamed for this data corruption, I changed:
- the CPU: AMD Athlon 64 3000++ (the n-1 technology)
- the memory: no-name DIMs of 333 MHz
- the video card: an old Trio64 PCI
- the power supply: 2 of them from 2 other manufacturers
Needless to say that the data corruption error persists despite the speed reduction of the machine.
For the log:
- The usual CPU temperature is about 35 Centigrade, the voltages are no more that 2 % off from their nominal values.
- I tested the memory by the stand alone Memtest-86 v3.2 (e.g. on the SuSE 9.3 install CD) for hours, no memory error could be detected.
I can reproduce this error by connecting my disks on both the S-ATA controller built in to the nForce 4 chip set and on the Silicon Image's S-ATA-RAID controller (I guess this latter is a PCI device happened to be soldered on the motherboard). This is why I think it is the nForce 4 DMA logic (that is common for both of these S-ATA controllers) that is responsible for this error.
I connected some P-ATA disks and some SCSI ones (via an NCR-875 card). None of them suffered from the data corruption. Explanation: these disks stress less the nForce 4 DMA logic due to their lower data rate.
Some of the posters suggested the the NCQ/TCQ would be the origin of the data corruption. I set off the
Device Manager
   Nvidia nForce4 ADMA Controller Properties
      Primary and Secondary Channel
         Enable Command Queuing
I compared some files of ~10 GBytes on a single disk: they did match.
Having become enthusiastic over the success, I compared files located on two distinct disks. The deception was back: they were different. The number of the differences were somewhat lower.
I organized my disks as RAID-0. In addition to switching off the command queuing as before, I set off the
Device Manager
   Nvidia Stripe Properties
      SCSI Properties
         Disable Tagged Queuing
It did not help.
I think by switching off the NCQ/TCQ, the error is not eliminated, only the transfer rate is diminished. If the nForce 4 DMA logic is sufficiently stressed, data corruption will happen.