Date: Tue, 6 Jul 1999 10:36:06 +0200 (MET DST) From: Nick Hibma <nick.hibma@jrc.it> To: Matthew Jacob <mjacob@feral.com> Cc: FreeBSD Hackers mailing list <hackers@FreeBSD.ORG> Subject: Re: CAM: delaying new commands during reset Message-ID: <Pine.GSO.3.95q.990706102658.3645k-100000@elect8> In-Reply-To: <Pine.BSF.4.05.9907051717170.9193-100000@semuta.feral.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> I'm not sure what you mean by 'Busy' here, but it doesn't matter I
> believe- the cam_periph_async called with
CAM actions come in and initiate one or more USB transfers. When the
action has completed or failed, xpt_done() is called to mark the ccb as
completed. If the command has failed, the umass driver initiates a bus
reset that takes a while to complete. In the meantime CAM tries to
submit new actions that fail because the subsystem is busy. Those
commands have to be delayed until the reset has completed.
> case AC_SENT_BDR:
> case AC_BUS_RESET:
> {
> cam_periph_bus_settle(periph, SCSI_DELAY);
> break;
> }
I guess I should dig through the async commands a bit more. It looks
like there is quite a few features document in C.
Cheers,
Nick
>
> should do bus settling for SCSI_DELAY. If you're not actually doing a bus
> reset, you need to hold off the command with a requeue but only if you
> tell it when it can go (I believe- I sure wish Justin would document this
> stuff).
>
>
> On Tue, 6 Jul 1999, Nick Hibma wrote:
>
> >
> > The Iomega USB Zip drive is a bit slow when resetting (reset of the USB
> > part of the drive). It takes 1s or more to reset. The reset is initiated
> > because for example an illegal command was received (sync cache for
> > example).
> >
> > umass0: XPT_SCSI_IO 0:1:0 command: 0x25 (10b command/8b data)
> > umass0: CBW 45: cmd = 10b (0x250000000000...), data = 8 bytes, dir = in
> > umass0: Handling state 2, Bulk Data, TIMEOUT
> > umass0: data-in 8b failed, TIMEOUT
> > umass0: Bulk Reset
> > (reset is now in progress and previous SCSI has been cancelled)
> > umass0: XPT_SCSI_IO 0:1:0 command: 0x25 (10b command/8b data)
> > (CAM retries command)
> > umass0: Busy, state 5, Bulk Reset
> > (but gets told that the SCSI bus is busy)
> > umass0: XPT_SCSI_IO 0:1:0 command: 0x25 (10b command/8b data)
> > (tries again)
> > umass0: Busy, state 5, Bulk Reset
> > (and is again told to go away, etc.)
> > umass0: XPT_SCSI_IO 0:1:0 command: 0x25 (10b command/8b data)
> > umass0: Busy, state 5, Bulk Reset
> > umass0: XPT_SCSI_IO 0:1:0 command: 0x25 (10b command/8b data)
> > umass0: Busy, state 5, Bulk Reset
> > (da0:umass0:0:1:0): got CAM status 0x3f
> > (da0:umass0:0:1:0): fatal error, failed to attach to device
> > (da0:umass0:0:1:0): lost device
> > (da0:umass0:0:1:0): removing device entry
> >
> > The problem is that the reset is initiated and the command that failed
> > xpt_done()-d with an error. scsi_da then retries the command, but it is
> > returned instantly with a CAM_SCSI_BUSY error because the reset is
> > still in progress.
> >
> > What would be the proper approach to make the ccb delay until the reset
> > has finished? return a CAM_REQUEUE_REQ instead of CAM_SCSI_BUSY? Or
> > store the ccb and process it when the reset is done?
> >
> > Thanks for any advice.
> >
> > Nick
> >
> > umass.c: http://www.etla.net/~n_hibma/usb/umass.c.new
> > --
> > e-Mail: hibma@skylink.it
> >
> >
> >
> > To Unsubscribe: send mail to majordomo@FreeBSD.org
> > with "unsubscribe freebsd-hackers" in the body of the message
> >
>
>
--
ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.3.95q.990706102658.3645k-100000>