Skip site navigation (1)Skip section navigation (2)
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>