Re: 2.1.111: IDE DMA disabled?

Aaron L. Meehan (aaron@utopia.ml.org)
Sun, 26 Jul 1998 23:53:06 -0700


I am inclined to agree with David. A vendor that we obtain most of
our hardware from sells mainly WD Caviar drives. Well, I've noted
repeated disk corruption on these drives, which seems to be
intermittent as hell. The only way I could actually get linux to
install on one machine without it crapping out was by setting
"ide0=noautotune".

I've noted these problems both with Triton chipsets and with Caviars
connected to Promise Ultra33 controllers. Just today, as a matter of
fact, I booted up 2.0.35 for the first time, and made the mistake of
not disabling autotune, and 'lo and behold I started noticing things
go wierd. fsck found one partition with a bad superblock. I saw
numerous console messages pertaining to DMA access on the drive
(DriveReady SeekComplete, etc).

The two particular drives I have on the machine I just mentioned are
WDC AC33100H <-- ide driver enables DMA only
WDC AC33200L <-- ide driver enables UDMA

I have not really done extensive tests to determine the exact nature
of the problems, but I do know both drives are connected to seperate
ide interfaces on the Promise with cables that are 18 inches long, and
both had major problems today.

Aaron

Quoting David S. Miller (davem@dm.cobaltmicro.com):
> Date: Sun, 26 Jul 1998 11:25:09 -0700 (PDT)
> From: Linus Torvalds <torvalds@transmeta.com>
>
> The argument is proven false by the fact that people who saw
> corruption with DMA on didn't see it with DMA off.
>
> The BIOS argument is pure shit, I agree with you on that.
>
> And let's gander that if we asked all these people seeing corruption
> what kind of disk they are using, and they all say "Western Digital
> Caviar", are we going to disable IDE dma by default just because WD
> makes crap drives with buggy firmware? Really, in my experience it's
> always been a crappy WDC disk, the link between those disks and any
> kind of IDE dma corruption, for me, has been inseperable. Therefore
> the blacklist approach seems more reasonable if this is the case.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html