Date: Tue, 6 Jul 1999 11:13:14 -0600 (MDT) From: "Justin T. Gibbs" <gibbs@narnia.plutotech.com> To: Nick Hibma <hibma@skylink.it> Cc: scsi@FreeBSD.org Subject: Re: CAM: delaying new commands during reset Message-ID: <199907061713.LAA68449@narnia.plutotech.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
This stuff should really go to the SCSI list. I read that list much more frequently than this one. > 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). The hard coded reset delay in there is quite crude. You should just call xpt_freeze_devq() for that device and then release the queue from a timeout handler. In general, the peripheral drivers will wait until after a bus settle delay anyway, but the only way to ensure this delay is to freeze the queue. > The problem is that the reset is initiated and the command that failed > xpt_done()-d with an error. All ccbs that have an error status set should cause the device queue to be frozen and the CAM_DEV_QFRZN flag should be set in the cam status field of the CCB. If you don't freeze the queue, the peripheral driver cannot perform error recovery in a consistant way. It also looks like all umass I/O is blocking/polling. Since this can occur from a SWI, this is pretty bad to do. Is there no alternative? It also appears that this driver has a very limited error code vocabulary. Is that because the transport or device gives little information about errors? > 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? CAM_REQUEUE_REQ is for commands that have been queued in the SIM but have never been sent to a device. The error modle goes something like this: All ccbs with non-zero status should cause the device queue to be frozen and the CAM_DEV_QFRZN flag set in the status word. When an error occurrs: Return all queued CCBs that match the device(s) affected by the error with CAM_REQUEUE_REQ status. Return any 'invalidated' commands (commands that were on the device but have been thrown out in response to this error) with the correct error status (CAM_BUS_RESET, CAM_BDR_SENT, etc.) Return any commands that have completed with an error with the apropriate error code (CAM_UNCOR_PARIY, CAM_SCSI_STATUS_ERROR, CAM_DATA_RUN_ERR, etc.) If you require a specific amount of recovery time, freeze the device or simq and schedule a timeout to release the queue. An underrun is not an error. If a ccb is returned with no error codes set, the residual will be examined, so you must set the residual on all completed commands. -- Justin 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?199907061713.LAA68449>