Subject: Re: Filesystem Corruption (ext2) on Tyan S2462, 2xAMD1900MP, 2.4.17SMP (RH7.2)
To: ken@irridia.com (Ken Brownfield)
Date: Wed, 20 Mar 2002 01:31:46 +0000 (GMT)
Cc: m.knoblauch@TeraPort.de,
        linux-kernel@vger.kernel.org (linux-kernel@vger.kernel.org)
In-Reply-To: <20020319190211.B15811@asooo.flowerfire.com> from "Ken Brownfield" at Mar 19, 2002 07:02:11 PM
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <E16nUx8-0000w4-00@the-village.bc.nu>
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Sender: linux-kernel-owner@vger.kernel.org

> We're seeing this with Tyan 2410s and Seagate drives.  I think Tyan just
> can't get DMA right.  Luckily we mainly lost docs or man pages before we
> disabled DMA, although losing the rpm database sucked.  MDMA2 seems okay
> but we haven't tested it long enough to form a lasting impression.
> I'm actually patching the ServerWorks driver to honor the CONFIG flag,
> since even with hdparm there is a narrow risk to the fs during the boot
> process before DMA is disabled.

I can confirm problems with serverworks OSB4 and UDMA. With UDMA and
a seagate disk you see 4 bytes repeat from one transfer into the next
shuffling all the data up 4 bytes (which since it includes inode and
metadata is *messy*). Current 2.4 has detect code that sometimes traps this
and panics to avoid fs death.

With MWDMA all was fine.

This was observed across a large number of boxes in a rendering farm so its
not a one off flawed box, and across two board vendors. I reported it to
serverworks who were interested but couldnt reproduce it in their lab.
-
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/