linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Wes Janzen <superchkn@sbcglobal.net>
To: Linux Kernel <linux-kernel@vger.kernel.org>, reiserfs-list@namesys.com
Subject: FS Corruption with VIA MVP3 + UDMA/DMA
Date: Mon, 30 Jun 2003 13:17:35 -0500	[thread overview]
Message-ID: <3F007EBF.9020506@sbcglobal.net> (raw)
In-Reply-To: <16128.19218.139117.293393@charged.uio.no>

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


  parent reply	other threads:[~2003-06-30 18:03 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-30 14:37 [PATCH 1/4] Optimize NFS open() calls by means of 'intents' Trond Myklebust
2003-06-30 14:39 ` Trond Myklebust
2003-06-30 18:17 ` Wes Janzen [this message]
2003-07-12 20:42   ` FS Corruption with VIA MVP3 + UDMA/DMA Wes Janzen
2003-07-14  9:06     ` Vladimir B. Savkin
2003-08-09 12:19     ` Wes Janzen
2003-08-09 14:37       ` Alan Cox
2003-08-09 15:57         ` Helge Hafting
2003-08-09 17:11           ` John Wendel
2003-08-09 16:27       ` Jamie Lokier
2003-08-09 16:43         ` insecure
2003-08-09 17:38           ` Jamie Lokier
2003-08-09 23:18             ` Wes Janzen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3F007EBF.9020506@sbcglobal.net \
    --to=superchkn@sbcglobal.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=reiserfs-list@namesys.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).