From owner-freebsd-hackers Mon Jul 5 17:21:35 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 4793514C94 for ; Mon, 5 Jul 1999 17:21:30 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.8.7/8.8.7) with ESMTP id RAA10653; Mon, 5 Jul 1999 17:21:22 -0700 Date: Mon, 5 Jul 1999 17:21:20 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Nick Hibma 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 case AC_SENT_BDR: case AC_BUS_RESET: { cam_periph_bus_settle(periph, SCSI_DELAY); break; } 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 > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message