From owner-freebsd-hackers Mon Jul 5 16:23:19 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.skylink.it (ns.skylink.it [194.177.113.1]) by hub.freebsd.org (Postfix) with ESMTP id 2D63D14C40 for ; Mon, 5 Jul 1999 16:23:11 -0700 (PDT) (envelope-from hibma@skylink.it) Received: from heidi.plazza.it (va-166.skylink.it [194.185.55.166]) by ns.skylink.it (8.9.3/8.8.8) with ESMTP id BAA07194 for ; Tue, 6 Jul 1999 01:22:44 +0200 Received: from localhost (localhost.plazza.it [127.0.0.1]) by heidi.plazza.it (8.8.8/8.8.5) with SMTP id BAA13916 for ; Tue, 6 Jul 1999 01:21:54 +0200 (CEST) Date: Tue, 6 Jul 1999 01:21:54 +0200 (CEST) From: Nick Hibma X-Sender: n_hibma@heidi.plazza.it Reply-To: Nick Hibma To: FreeBSD Hackers mailing list Subject: CAM: delaying new commands during reset 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 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