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 eisc...@vigrid.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
