Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 29 Nov 2000 12:52:51 +1030
From:      Greg Lehey <grog@lemis.com>
To:        Soren Schmidt <sos@freebsd.dk>
Cc:        Carlos Amengual <webmaster@healthnet-sl.es>, freebsd-bugs@FreeBSD.ORG
Subject:   Re: kern/22086: DMA errors during intensive disk activity on vinum  volume
Message-ID:  <20001129125251.D45540@echunga.lemis.com>
In-Reply-To: <200011281917.UAA00377@freebsd.dk>; from sos@freebsd.dk on Tue, Nov 28, 2000 at 08:17:36PM %2B0100
References:  <200011281800.eASI03i24567@freefall.freebsd.org> <200011281917.UAA00377@freebsd.dk>

next in thread | previous in thread | raw e-mail | index | archive | help
[Format recovered--see http://www.lemis.com/email/email-format.html]

On Tuesday, 28 November 2000 at 20:17:36 +0100, Søren Schmidt wrote:
> On Tue, 28 Nov 2000 18:52:43 +0100, Carlos Amengual <webmaster@healthnet-sl.es> wrote:
>>
>>  I found the same problem on a 4.2-RELEASE system:
>>
>>  Vinum configuration:
>>
>>  drive idea device /dev/ad0s1e
>>  drive ideb device /dev/ad2s1f
>>  drive idec device /dev/ad4s1f
>>  volume raid5a
>>    plex org raid5 512k
>>      sd length 0 drive idea
>>      sd length 0 drive ideb
>>      sd length 0 drive idec
>>
>>  The error messages:
>>
>>  Nov 27 22:24:43 vega /kernel: ata0-master: zero length DMA transfer attempted
>>  Nov 27 22:25:06 vega /kernel: ad0: WRITE command timeout tag=0 serv=0 - resetting
>>  Nov 27 22:25:06 vega /kernel: ata0: resetting devices .. done
>>  Nov 27 22:25:06 vega /kernel: ata0-master: zero length DMA transfer attempted
>>  Nov 27 22:25:06 vega /kernel: ad0: WRITE command timeout tag=0 serv=0 - resetting
>>  Nov 27 22:25:06 vega /kernel: ata0: resetting devices .. done
>
> This is an old problem with vinum, somehow vinum manage to trash
> the ad_request struct between where the ata drives makes it in
> ad_strategy and when it actually gets used later..
> I thought this was fixed at least in -current long ago, but
> apparently this was either not backported to -stable or the fix
> was not good enough.

No, the problem went into hiding.  It was you who thought it had gone
away.

> I'm sure Greg will tell you its an ATA problem though :)

No, Greg doesn't get involved in that sort of finger pointing.  Greg
just wants somebody to help him debug it, and everybody he has asked
(including you) has not followed through.

This case looks interesting for a couple of reasons:

1.  This config does not include an fxp device, which you had in the
    past blamed for the problems:

    > Now, I'm not sure if its vinum or the fxp driver that has a
    > problem, but since others have seen strange problems semilar to
    > this on other type of systems, I'd say it points very much at
    > fxp...  The latest fix you put into -current is needed though...

2.  Robin seems to be able to work through the source code, so this
    time we may be able to catch it.

Greg
--
When replying to this message, please take care not to mutilate the
original text.  
For more information, see http://www.lemis.com/email.html
Finger grog@lemis.com for PGP public key
See complete headers for address and phone numbers


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001129125251.D45540>