lkml.org 
[lkml]   [2001]   [Sep]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: DMA problem (?) w/2.4.6-xfs and ServerWorks OSB4 Chipset
Date
Alright. Until the situation clarifies you might tell RH turn off OSB4 by 
default in future releases. It caused us no end of grief with 2.4.3-12.

--
Marvin Justice
Software Developer
BOXX Technologies, Inc.
www.boxxtech.com
512-235-6318 (V)
512-835-0434 (F)


On Sunday 30 September 2001 03:50 pm, Alan Cox wrote:
> > Curious - OSB4 thinks the DMA is still running.
> > OSB4 wait exit
>
> This is an OSB4 trap for a problem I've seen with seagate drivers on some
> boxes. Under very high load with UDMA seagate drives the OSB4 returns to
> us with the chip reporting DMA in progress. The next I/O after this will
> cause disk corruption as it DMA's the last 4 bytes of the previous write,
> then the data shifted up by 4 bytes until the end of that I/O. I need
> to confirm nobody else is seeing this with other working workloads, then
> I'll swap it for a panic - better to die than kill the disc contents.
>
> Serverworks have been looking at the problem but have yet to duplicate it.
> As far as we can tell (and Red Hat have been working with a customer on
> this directly) your choices are
>
> 1. Use multiword DMA not UDMA
> 2. Use non seagate disks with that controller
>
> I am hopeful that serverworks will figure out what is up, but not every box
> sees it - and indeed they've yet to be able to reproduce it.
>
>
> Alan

-
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:03    [W:0.070 / U:0.092 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site