Which kernel release are you working with? I really recommend you use the new
error handling code if you can.
With respect to LIPs, you may have to do as some of the other drivers do and
queue the commands locally (i.e., commit to actually run them at a later
date), make sure they don't time out by adjusting their timeout value (i.e,,
while you're doing all the PLOG/PRLI goofiness don't let the system get
impatient)- but I'm sure that others will have better suggestions than I
which *I'd* liek to hear as well.
On Fri, 10 Mar 2000, Ralston, Steve wrote:
> What's the best way to spoof the scsi mid-layer into
> retrying a cmd?
> (e.g., if a device is momentarily out to lunch)
>
> I've tried various flavors over the past few weeks with
> strange to interesting results.
> 1) sc->result = DID_BUS_BUSY << 16;
> // YIKES! This seems to kill linux interrupt handler!!!
> 2) sc->result = 0x08; // Try SCSI BUSY!
> // Sort of works, but end up with corrupted file system
> 3) sc->result = 0x28; // Try SCSI QUEUE_FULL!
> // Best results so far...
>
> Just curious if anyone out there recommends these
> or other methods.
>
> (I think it matters: the driver we're testing / developing
> currently has SHTp->use_new_eh_code == 0 because
> I've had too many problems so far when I set this to 1):-(
>
> BTW: Test scenario: someone continuously trips over the
> SCSI cable (or fibre channel in this case) while intense
> io is taking place on the bus. For fibre channel this
> typically means lots of LIPs and target discoveries
> taking place --> device momentarily out to lunch.
>
> Thanks,
> -SteveR
>
> PS: For WinNT (ack!) miniport drivers, the singlular
> answer seems to be: BUSY!
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to [EMAIL PROTECTED]
>
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
