[6123] in linux-scsi channel archive
Re: Guru required: BUSY status
daemon@ATHENA.MIT.EDU (Marc SCHAEFER)
Thu Mar 18 18:53:35 1999
To: linux-scsi@vger.rutgers.edu
From: Marc SCHAEFER <schaefer@alphanet.ch>
Date: 18 Mar 1999 22:59:03 +0100
grant@torque.net wrote:
> option - the initiator must respond to reselection within 200us, so
250 ms (250 millisecond).
> the CPU would be dedicated to watching for the reselection.
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.
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.
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.
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.rutgers.edu
