lkml.org 
[lkml]   [2004]   [Jan]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.4.23+atalib2 sil3112A write errors
Sorry for the false alarm.  I'm now suspecting hardware errors.  I took 
a look at the actual errors introduced into the files. When I octal
dump both the source file and destination file and diff them I'm only
seeing a short string of bytes changed. This is telling me I'm getting
multibit errors slipping though. Time to start swapping cables and
hardware. Is there a way to get the driver to output messages when
errors are seen rather than messages for all transfers?

This is an example of the differences seen.

72922,72923c72922,72923
< 4357500 064047 120335 134421 006545 137622 023477 043620 164561
< 4357520 106514 023757 026270 043466 051034 117400 174451 127107
---
> 4357500 064047 120335 134421 006545 136566 035207 015425 133770
> 4357520 012031 012055 171154 045114 015406 000160 017147 035214

- Bryan

Bryan Andersen wrote:
> I'm seeing silent write errors with two Seagate 160GB drives on a
> sil3112A SATA controller on an ASUS A7N8X-Deluxe motherboard, but I'm
> not seeing any read errors. Each drive is on it's own cable. Kernel is
> 2.4.23 release with the 2.4.23-libata2 patch and some patches for using
> MythTV applied. (I also see the same problem under 2.4.24+libata only)
> I'm also not seeing any error messages in any log files or the kernel
> dmesg output. The error rate looks to be around 1 in a million blocks.
> My current guess is the block or blocks just didn't get written by the
> drive as when the system reads in the blocks with the bad data I'm not
> seeing any read error messages.
>
> I am now running the tests again using jfs as the filesystem rather than
> ext3 to rule out the file system as the cause. As part of this test I'm
> also zeroing the disks before the test and then checking for non zero
> data and how large the non zero data blocks are. Given enough time I
> may run this test a couple of times to see if the positions of the bad
> data move about or stay put.
>
> How the first testes were run.
>
> I used "cp -a * /data10" as root to copy the data (150GB worth) to the
> disk under test. Then I created md5sum lists for all files in both the
> source and destination and sorted and compaired the lists. Differences
> were found between the lists, some files and directories were missing,
> or corrupted. On fscking the disks some inodes were found corrupted. I
> then copied only the corrupted files and after a few iterations I
> finally got a copy that was the same as the source. I then ran a
> program to repeatadly md5sum checksum all the files and check against
> the source. It did not see any differences in 10 cycles.
>
> I've attached my .config file, but don't have dmesg output to include. I
> will grab that when I reboot after the current tests are finished.
>
> - Bryan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:59    [W:0.034 / U:0.396 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site