From owner-freebsd-hackers Tue Jul 6 1:36:22 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mrelay.jrc.it (mrelay.jrc.it [139.191.1.65]) by hub.freebsd.org (Postfix) with ESMTP id C5EFE15348 for ; Tue, 6 Jul 1999 01:36:15 -0700 (PDT) (envelope-from nick.hibma@jrc.it) Received: from elect8 (elect8.jrc.it [139.191.71.152]) by mrelay.jrc.it (LMC5692) with SMTP id KAA29809; Tue, 6 Jul 1999 10:36:08 +0200 (MET DST) Date: Tue, 6 Jul 1999 10:36:06 +0200 (MET DST) From: Nick Hibma X-Sender: n_hibma@elect8 Reply-To: Nick Hibma To: Matthew Jacob Cc: FreeBSD Hackers mailing list Subject: Re: CAM: delaying new commands during reset In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 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