Date: Mon, 5 Jul 1999 17:21:20 -0700 (PDT) From: Matthew Jacob <mjacob@feral.com> To: Nick Hibma <hibma@skylink.it> Cc: FreeBSD Hackers mailing list <hackers@FreeBSD.ORG> Subject: Re: CAM: delaying new commands during reset Message-ID: <Pine.BSF.4.05.9907051717170.9193-100000@semuta.feral.com> In-Reply-To: <Pine.BSF.3.96.990706010514.13864B-100000@heidi.plazza.it>
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
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9907051717170.9193-100000>