[6135] in linux-scsi channel archive
Re: Guru required: BUSY status
daemon@ATHENA.MIT.EDU (Gerard Roudier)
Fri Mar 19 17:54:32 1999
Date: Fri, 19 Mar 1999 23:42:53 +0100 (MET)
From: Gerard Roudier <groudier@club-internet.fr>
To: Marc SCHAEFER <schaefer@alphanet.ch>
cc: linux-scsi@vger.rutgers.edu
In-Reply-To: <7crsv7$hdd$1@vulcan.alphanet.ch>
What confused a BUSYness ! ;-)
- DID_BUS_BUSY if it exists under Linux may be returned by a scsi
low-level driver when it is unable to use the SCSI BUS since something
is currently preventing it from using it.
- The BUSY SCSI status is returned by a SCSI device server (SCSI device)
to the application client (something that wanted to send the SCSI command
to the device) to report that the device is unable to accept the command
since it is currently busy to something else.
- The BUSY SCSI bus signal is involved in the SCSI interlocked protocol
used by initiators and targets to communicate accross the SCSI BUS.
On 18 Mar 1999, Marc SCHAEFER wrote:
> grant@torque.net wrote:
> > option - the initiator must respond to reselection within 200us, so
>
> 250 ms (250 millisecond).
The SCSI selection/reselection procedure on SCSI requires all the SCSI
agents connected to the BUS to follow some specified timings. When a
device is too wrong with regards to these timings, wrong selection /
relection may occur: for example, 2 targets beleiving that they have been
selected by the initiator.
> > the CPU would be dedicated to watching for the reselection.
The selection procedure is normally handled by some controller core, since
the C code will not be accurate enough or fast enough to ensure the
required timings to be within the allowed range.
> But you are right that with a strictly polling hardware (ie no
> automatic reselection handling like even chips like 53CF94 can
> do) it's a little bad.
>
> > As far as I can tell, the scsi mid-level code assumes that a BUSY
> > status is always an error, and the _new_ eh code appears to respond
> > by issuing a reset.
The BUSY status is indeed not a success, but it does not indicate that
the command di fail. It just indicates that the device was not able to
accept it at the moment it has been presented to it.
What you want to do after a BUSY status is to requeue the command later.
The problem is 'when ?'. Most SCSI sub-systems and not only Linux-scsi
just requeue the command immediately and doing so just floods everything .
This is probably close to the worst thing to do, but it is done.
> A few years ago I had to do exactly the contrary: change aic7xxx handling
> so that it fails after the first busy to demonstrate a problem in
> some other company's code.
Normally, the BUSY status should not be handled by too low level layers,
unless it is reported when there are outstanding commands for the devices
(tagged), and the layer is handling the QUEUE FULL condition and does
take care of commands not being reordered.
The BUSY status is that vague an information and trying to handle it from
low-level layers seems not the appropriate place to me . The device driver
or the application can probably implement better heuristics.
> So it probably depends on the driver.
>
> > What I propose is to detect the BUSY status in the low-level driver,
> > sleep for a short time, and then retry the command, without ever alerting
> > the mid-level code. This seems a fairly obvious solution, but I
> > might be missing something. (In particular, I'm worried about the
> > possibility of the mid-level code timing out and aborting the command.)
>
> If you set DID_BUS_BUSY, the higher level code will retry indefinitely.
> Look in aic7xxx.c for BUSY for more details.
Regards,
Gerard.
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.rutgers.edu
