From owner-freebsd-scsi Tue Jun 2 11:13:11 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA12141 for freebsd-scsi-outgoing; Tue, 2 Jun 1998 11:13:11 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from antipodes.cdrom.com (castles327.castles.com [208.214.167.27]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA12095; Tue, 2 Jun 1998 11:12:55 -0700 (PDT) (envelope-from mike@antipodes.cdrom.com) Received: from antipodes.cdrom.com (localhost [127.0.0.1]) by antipodes.cdrom.com (8.8.8/8.8.5) with ESMTP id KAA00985; Tue, 2 Jun 1998 10:07:18 -0700 (PDT) Message-Id: <199806021707.KAA00985@antipodes.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: shimon@simon-shapiro.org cc: Mike Smith , "freebsd-current@freebsd.org" , "freebsd-scsi@freebsd.org" , tcobb Subject: Re: DPT Redux In-reply-to: Your message of "Mon, 01 Jun 1998 21:21:13 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 02 Jun 1998 10:07:18 -0700 From: Mike Smith Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > 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-scsi" in the body of the message