«

Hi,

I installed a new SATA drive in my box this morning. This is the first
SATA drive I have owned, and the first one used with this PC. Twice so
far, I have detected data corruption in files copied to this drive.

I'm posting here in case someone knows that this is a 'known issue' that
I may have missed.

In both cases the errors have been single bit errors. 1000 ( <-> 1100
(C), and 0000 (0) <-> 0100 (4). The exact way in which the files was
changed I'm not certain of, but in both cases it was the second bit in
the nibble. I believe the bit was 1 when it should have been 0.

After the first error, I ran chkdsk in full repair mode, which took
hours, and no bad sectors were found, although a couple of indexes were
corrected.

I again copied large amounts of data to the drive, and detected the
problem the second time. I modified the Sysinternals tool 'sdelete' to
overwrite the file with both 0x00 and 0xFF, instead of using random
data, and commented out the code to rename/delete the file. In both
cases, the data appeared correct when subsequently read. I guess it is
possible the data came from the drive cache rather than the disk surface
however, as this was done soon after the write.

The usual candidate for problems of this kind is system memory, however
as copy routines usually re-use a buffer, the frequency at which this
issue occurred should increase if that were the case. As the error only
showed up twice, once in a small file (~3.5MB), and once in a large one
(>300MB), I think it is safe to rule out system memory, although I will
run Memtest86 anyway.

System board is a Gigabyte GA-8KNXP with an Intel i875 chipset (Using
south bridge SATA channel, not the additional RAID controller). Drive is
a Western Digital WD5000AAKS.

If anyone has any suggestions on where the problem might be, please let
me know. I had big plans for this weekend which are on hold until this
issue is sorted.

Thanks,

- RL

RL wrote:

A little more info.

Windows XPSP2
The south bridge on this board is the ICH5. There are reports of data
corruption with this under Linux, no sign of issues with Windows that I
can see yet.

- RL

"RL" <> wrote in message news:etfi3h$4mp$...
> Hi,

>
> System board is a Gigabyte GA-8KNXP with an Intel i875 chipset (Using
> south bridge SATA channel, not the additional RAID controller). Drive is a
> Western Digital WD5000AAKS.
>
> If anyone has any suggestions on where the problem might be, please let me
> know. I had big plans for this weekend which are on hold until this issue
> is sorted.
>
> Thanks,
>

Update chipset drivers, Check WD support for firmware update for the HD
itself. Check which Sata mode the HD is set for some use jumpers. Some use a
utility to set the SATA mode.

Check event viewer log for any errors.. disable NCQ might be the answer..

just some ideas

RL wrote:
> Hi,
>
> I installed a new SATA drive in my box this morning. This is the first
> SATA drive I have owned, and the first one used with this PC. Twice so
> far, I have detected data corruption in files copied to this drive.
>
> I'm posting here in case someone knows that this is a 'known issue' that
> I may have missed.
>
> In both cases the errors have been single bit errors. 1000 ( <-> 1100
> (C), and 0000 (0) <-> 0100 (4). The exact way in which the files was
> changed I'm not certain of, but in both cases it was the second bit in
> the nibble. I believe the bit was 1 when it should have been 0.
>
> After the first error, I ran chkdsk in full repair mode, which took
> hours, and no bad sectors were found, although a couple of indexes were
> corrected.
>
> I again copied large amounts of data to the drive, and detected the
> problem the second time. I modified the Sysinternals tool 'sdelete' to
> overwrite the file with both 0x00 and 0xFF, instead of using random
> data, and commented out the code to rename/delete the file. In both
> cases, the data appeared correct when subsequently read. I guess it is
> possible the data came from the drive cache rather than the disk surface
> however, as this was done soon after the write.
>
> The usual candidate for problems of this kind is system memory, however
> as copy routines usually re-use a buffer, the frequency at which this
> issue occurred should increase if that were the case. As the error only
> showed up twice, once in a small file (~3.5MB), and once in a large one
> (>300MB), I think it is safe to rule out system memory, although I will
> run Memtest86 anyway.
>
> System board is a Gigabyte GA-8KNXP with an Intel i875 chipset (Using
> south bridge SATA channel, not the additional RAID controller). Drive is
> a Western Digital WD5000AAKS.
>
> If anyone has any suggestions on where the problem might be, please let
> me know. I had big plans for this weekend which are on hold until this
> issue is sorted.

Can't help with your file corruption problem but I have a comment to
make about your proposal to run a memory test. Do not put too much faith
in a single memory test program to establish the health of the RAM.

I had a RAM issue recently that caused me plenty of head scratching and
took 2 frustrating weeks to finally pinpoint. I was pretty certain I had
a faulty RAM module as the system (XP Pro) was unstable after an
upgrade. However, I could not confirm this using standalone memory
testing. I tried 3 different tests, including Memtest86, with no
success. It was only when I finally hit on a program called Testmem4
that errors were detected, the fault being consistent and repeatable.

I'm not suggesting for one minute that Testmem4 is 'the best' memory
test program (in fact, it has a terrible UI), just that you should not
place all your faith in one.

HTH

joe_90 wrote:

> I had a RAM issue recently that caused me plenty of head scratching and
> took 2 frustrating weeks to finally pinpoint. I was pretty certain I had
> a faulty RAM module as the system (XP Pro) was unstable after an
> upgrade. However, I could not confirm this using standalone memory
> testing. I tried 3 different tests, including Memtest86, with no
> success. It was only when I finally hit on a program called Testmem4
> that errors were detected, the fault being consistent and repeatable.
>
> I'm not suggesting for one minute that Testmem4 is 'the best' memory
> test program (in fact, it has a terrible UI), just that you should not
> place all your faith in one.

Ive had ram pass memtest86 and then go and fail when I used the
microsoft one and vice versa, and it was on the first pass in all cases
so yeah, try em all

Craig Sutton wrote:
> Update chipset drivers, Check WD support for firmware update for the HD
> itself. Check which Sata mode the HD is set for some use jumpers. Some
> use a utility to set the SATA mode.
>
> Check event viewer log for any errors.. disable NCQ might be the answer..
>
> just some ideas

Thanks Craig,

The drive looks like the problem here.

In addition to what I mentioned yesterday, I have also tried the Silicon
Image controller on the GA-8KNXP, with the same results. The error
occurred relatively early in the process of copying files, and has not
reoccurred by copying more data to the drive (~100GB at present). This
suggests the problem is specific to one sector of the drive, as if the
data were corrupted elsewhere in the system, the error should reoccur.

Thanks,

- RL

On Sat, 17 Mar 2007 14:58:57 +1300, RL <> wrote:

>Hi,
>
>I installed a new SATA drive in my box this morning. This is the first
>SATA drive I have owned, and the first one used with this PC. Twice so
>far, I have detected data corruption in files copied to this drive.
>
>I'm posting here in case someone knows that this is a 'known issue' that
>I may have missed.
>
>In both cases the errors have been single bit errors. 1000 ( <-> 1100
>(C), and 0000 (0) <-> 0100 (4). The exact way in which the files was
>changed I'm not certain of, but in both cases it was the second bit in
>the nibble. I believe the bit was 1 when it should have been 0.
>
>After the first error, I ran chkdsk in full repair mode, which took
>hours, and no bad sectors were found, although a couple of indexes were
>corrected.
>
>I again copied large amounts of data to the drive, and detected the
>problem the second time. I modified the Sysinternals tool 'sdelete' to
>overwrite the file with both 0x00 and 0xFF, instead of using random
>data, and commented out the code to rename/delete the file. In both
>cases, the data appeared correct when subsequently read. I guess it is
>possible the data came from the drive cache rather than the disk surface
>however, as this was done soon after the write.
>
>The usual candidate for problems of this kind is system memory, however
>as copy routines usually re-use a buffer, the frequency at which this
>issue occurred should increase if that were the case. As the error only
>showed up twice, once in a small file (~3.5MB), and once in a large one
>(>300MB), I think it is safe to rule out system memory, although I will
>run Memtest86 anyway.
>
>System board is a Gigabyte GA-8KNXP with an Intel i875 chipset (Using
>south bridge SATA channel, not the additional RAID controller). Drive is
>a Western Digital WD5000AAKS.
>
>If anyone has any suggestions on where the problem might be, please let
>me know. I had big plans for this weekend which are on hold until this
>issue is sorted.
>
>Thanks,
>
>- RL



Have you updated the Drivers for SATA as I think this was a known problem as
I have a similar MoBo..


This is for a Rev 2.x MoBo

http://www.gigabyte.com.tw/Support/M...ProductID=1717


And the Rev 1.x Board


http://www.gigabyte.com.tw/Support/M...ProductID=1630

Brian Withers wrote:
> Have you updated the Drivers for SATA as I think this was a known problem as
> I have a similar MoBo..
>
>
> This is for a Rev 2.x MoBo
>
> http://www.gigabyte.com.tw/Support/M...ProductID=1717
>
>
> And the Rev 1.x Board
>
>
> http://www.gigabyte.com.tw/Support/M...ProductID=1630

I switched to using the Silicon Image controller, and installed driver
from the Gigabyte site, with the same result. The latest full install of
the driver is from 2003, only the pre-install drivers have been updated
since then.

The one thing I haven't tried is updating the ICH5 drivers, however
given the problem exists across two different SATA controllers, I doubt
that will fix anything.

I've now copied over 110GB of data on to the drive with a similar load
as was being generated while copying files yesterday, and the problem
has not reoccurred other than once during the early stages of copying
files. I suspect therefore that the disk is the most likely cause of the
problem, and that the problem is isolated to one part of the disk.

RL