From owner-freebsd-hackers Tue Jul 6 10:23:55 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (Postfix) with ESMTP id BFB0614C46; Tue, 6 Jul 1999 10:23:47 -0700 (PDT) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.3/8.7.3) id LAA68449; Tue, 6 Jul 1999 11:13:14 -0600 (MDT) Date: Tue, 6 Jul 1999 11:13:14 -0600 (MDT) From: "Justin T. Gibbs" Message-Id: <199907061713.LAA68449@narnia.plutotech.com> To: Nick Hibma Cc: scsi@FreeBSD.org Subject: Re: CAM: delaying new commands during reset X-Newsgroups: pluto.freebsd.hackers In-Reply-To: User-Agent: tin/pre-1.4-980818 ("Laura") (UNIX) (FreeBSD/4.0-CURRENT (i386)) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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