Date: Tue, 6 Jul 1999 07:01:16 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: mjacob@feral.com, nick.hibma@jrc.it Cc: hackers@FreeBSD.ORG Subject: Re: CAM: delaying new commands during reset Message-ID: <199907061101.HAA24567@pcnet1.pcnet.com>
next in thread | raw e-mail | index | archive | help
Nick Hibma wrote: > > 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. In this case, you're suppose to use xpt_freeze_simq() or xpt_freeze_devq(). This will stop commands from being issued to the bus (simq) or device (devq) while the bus/device reset is being processed. After the reset, you can then use xpt_release_simq()/xpt_release_devq() to allow commands to be sent once again. During a bus/device queue freeze, I think it is safe to mark pending CCBs to be resent (the xpt layer shouldn't resend them until you unfreeze the queue). Dan Eischen eischen@vigrid.com 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?199907061101.HAA24567>