[lkml]   [1998]   [Aug]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectData corruption using 2940U

    Perhaps this question is not really kernel related, but it's a lowlevel
    problem and it _could_ be a serious kernel problem.

    I've some problems with data corruption on my SCSI discs connected to an
    Adaptec 2940U. Mainboard is a dual Pentium Tyan Tomcat II (HX chipset,
    2*P100, 64 MB RAM, Kernel compiles without problems) using SMP Kernel

    It happens during copying from a MO drive 'Fujitsu' Model: M2512A (216 MB)
    to a Micropolis SCSI harddrive Model: 4343NS using the Adaptec driver
    Version 5.1.0pre4/3.2.4. Ultra support for the Micropolis is enabled, parity
    checking on the pci_bus using the LILO commandline option
    "aic7xxx=pci_parity" is enabled. SCSI parity checking is also enabled in the
    BIOS setup. It's not only one or 2 bits, but a whole disc block of corrupted

    First of all I copied a large (100MB) software package stored on the MO with
    cp to the hard drive. I did the copy a second time to a different directory
    on the same hard drive because of problems with the first copy:

    I'll would like to show the corruption pattern right here:
    -rw-r--r-- 1 carsten muser 1716224 Aug 2 21:43
    python:/scratch/carsten/win98>cmp -l ../win98-2/ |wc -l
    508 [Bytes are different, should be the same, copied with cp]
    python:/scratch/carsten/win98>cmp ../win98-2/ ../win98-2/ differ: char 697346, line 2757
    python:/scratch/carsten/win98>hexdump -s 697346 -n 64
    00aa402 0ba6 f32d 1a0e 2677 58fb 1d54 00a6 ce04
    00aa412 a765 3028 96ae 117c f644 6ac1 4031 57a1
    00aa422 9a84 d9f1 355f 45f7 4e3d 287e 9674 34e9
    00aa432 d5b5 44de b8ab 5102 8656 08a6 1450 a781 [...]
    python:/scratch/carsten/win98>hexdump -s 697346 -n 64 ../win98-2/
    00aa402 dc81 0d4f 992e 412c 61d0 4dc4 9bef a94e
    00aa412 b6fa 86b1 efac 97cb a1ce 4a03 4384 d02e
    00aa422 2fcb c0c8 49b3 45b9 eb7e 9477 f111 3222
    00aa432 0d5e af47 02a7 84eb b826 a431 afb9 48c5 [...]

    I'll hold the 'original' and the corrupted file for further examination.
    Perhaps a hardware problem during reading/writing? This one happend during
    writing, because it's reproducable defecitve, but I've also some 'sporadic'
    (read)errors. But how to check for this? The data corruptions size is about
    one disc block (508 vs. 512 byte) and the beginning of the problem is really
    close to a 512 byte aligned file offset (this would be: 697344). But in my
    opinion every simple harddrive has a crc-32 checksum, so a low-level disc
    read problem shouldn't be the reason for this (there are no SCSI medium
    errors in my logs).

    Thanks for your help


    Linux, WinNT and MS-DOS. The Good, The Bad and The Ugly
    Carsten Gross
    Wohnheim Heilmeyersteige Sebastian Kneipp Weg 6, 89075 Ulm

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:43    [W:0.020 / U:30.980 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site