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 majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
