lkml.org 
[lkml]   [2003]   [Jun]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectFS Corruption with VIA MVP3 + UDMA/DMA
    I was wondering if anyone knows about this issue or has had this problem?

    I've been fighting FS corruption since switching to a UDMA hard drive
    (Maxtor) on my FIC PA2013 with the VIA MVP3, but I didn't really know
    that since the change was a result of a dying drive. Finally, through
    the chance of having installed an older Quantum drive that only allowed
    DMA MultiMode 2 as the fastest mode, I found the problem.

    At least on my board, the IDE UDMA/DMA implementation appears flawed
    [lspci gives: "VT82C586/B/686A/B PI (rev 6)"]. I've had the same
    problem with three UDMA DVD drives -- two Toshibas and a Pioneer. They
    would all lock-up installing software or corrupt the data being
    installed causing the installation to fail. I've also had four other
    Maxtor hard drives (3 factory certified, one retail) randomly corrupt
    content on the drives (fs type doesn't matter [NTFS, FAT, FAT32, EXT2,
    REISERFS have been tried]). That means that every UDMA drive I've
    plugged in has had data corruption issues (trying no less than 10 IDE
    cables, which I confirmed good on the Promise and I've tried both IDE
    channels on the MVP3). I started with Linux kernel version 2.2 and the
    problem remains up to 2.5.73. I've also confirmed the issue in Windows
    98SE, Windows XP and Windows 2003 RC2. At this point, one might as well
    stick in a PCI adapter, since with "hdparm -t" I get between 5.5-8.5
    MB/s. With the same mode on my Promise 20269 I get 12 MB/s , so clearly
    something is odd. I know the hard drive can do better since I can get
    20MB/s in UDMA 2 on the MVP3, but of course that's not safe.

    Even at DMA multiword 2, I can force r/w errors by heavy io. Moving to
    DMA mode 1 clears up the errors, but performance degrades to a
    consistent 5.49 MB/s (all the higher modes actually vary 2-6 MB/s
    between runs of hdparm) while the Promise in the same mode still gets 12
    MB/s consistently. I've found that copying a 300 MB file to my drive on
    the Promise, making 12 new files while making 12 duplicates to the drive
    on the MVP3 can still force errors in dma multiword 2. I check for
    write errors by comparing the copied files to the source file. It's
    much easier to create errors in any of the UDMA modes. Errors actually
    seem more likely to occur during actual use of the system since they are
    fairly common even in multiword 2, but the copying method makes it
    extremely repeatable (though not all the files are corrupted, that
    part's random).

    My current configuration has the Promise as the boot device with a
    single drive on the primary. I have my DVD (UDMA) on the secondary of
    the Promise. My other Maxtor hard drive is on the primary channel
    (alone) of the MVP3 with UDMA disabled in the bios (and thus not used by
    WinXP/2003 or Linux). Finally my cd writer and IDE Zip are on the
    secondary channel of the MVP3. I'd put my hard drive on the secondary
    channel of the Promise, but for some reason the computer won't boot with
    both hard drives on the Promise (even though they're on different
    cables)... I don't remember right now if it just locks up during OS
    loading or if it won't post. I can test it if that information is required.

    Otherwise my machine is fairly stable (3+weeks, but I usually have to
    boot to Windows for Illustrator and such before then) and I don't get
    any corruption when copying files around on my Promise controller. I
    can get errors even copying from my MVP3 drive to itself (making
    defragging dangerous on my shared FAT32 partition) even in DMA multiword 2.

    Is there anything that can be done with the IDE drivers for this chipset
    to make it "safe" without resorting to forcing DMA mode 1?

    Thanks,
    Wes Janzen

    -
    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:46    [W:0.027 / U:0.168 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site