Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 02 Jun 1998 10:07:18 -0700
From:      Mike Smith <mike@smith.net.au>
To:        shimon@simon-shapiro.org
Cc:        Mike Smith <mike@smith.net.au>, "freebsd-current@freebsd.org" <freebsd-current@FreeBSD.ORG>, "freebsd-scsi@freebsd.org" <freebsd-scsi@FreeBSD.ORG>, tcobb <tcobb@staff.circle.net>
Subject:   Re: DPT Redux 
Message-ID:  <199806021707.KAA00985@antipodes.cdrom.com>
In-Reply-To: Your message of "Mon, 01 Jun 1998 21:21:13 EDT." <XFMail.980601212113.shimon@simon-shapiro.org> 

next in thread | previous in thread | raw e-mail | index | archive | help
> 
> I did find a window with these conditions:
> 
> *  During boot (and only during boot), while the scsi abstraction layer
>    still runs in polled mode (interrupts off).
> 
> *  The DPT controller has enough bandwidth to accept commands one at a time.
> 
> *  The DPT controller then delays responding to commands 1,000 longer than
>    the SCSI abstraction layer (sd.c, in this case) specified.  In 3.0 I
>    reduced this to only 50 times longer.
> 
> *  When command completion is probed, the DPT will NOT report error, but
>    successful condition, or no condition at all.
> 
> Under these conditions, the DPT driver could return a ``successful''
> completion code.  In this case, the abstraction layer will post the device
> with whatever capacity value was there before calling the DPT driver.
> It is possible, under these conditions that nonsense will be assumed.
> The panic may be triggered by the SCSI abstraction layer trying to
> interpret some of its trash as valid data.
...
> Summary:  Theyre is a bit of ``pointing elsewhere'' here as, after thorough
> review, I do not see the memory failure in the driver.  Neither do I see
> any other defect.

Then could you characterise "returning a successful completion code for 
an incomplete/failed transfer"?  The SCSI stack has to assume at this 
point that the transaction is complete, even though you're admitting 
that it's not.

-- 
\\  Sometimes you're ahead,       \\  Mike Smith
\\  sometimes you're behind.      \\  mike@smith.net.au
\\  The race is long, and in the  \\  msmith@freebsd.org
\\  end it's only with yourself.  \\  msmith@cdrom.com



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



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