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]
