[8353] in linux-scsi channel archive
Re: spoofing SCSI retries
daemon@ATHENA.MIT.EDU (Eric Youngdale)
Fri Mar 10 07:45:46 2000
Date: Fri, 10 Mar 2000 07:40:06 -0500 (EST)
From: Eric Youngdale <eric@andante.org>
To: "Ralston, Steve" <steve.ralston@lsil.com>
Cc: "'linux-scsi'" <linux-scsi@vger.rutgers.edu>
In-Reply-To: <B2B3C90E45AED111B7B40001FA7E520A03833FD6@exw-kansas.ks.lsil.com>
Message-ID: <Pine.LNX.4.10.10003100734440.17430-100000@gwyn.tux.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
> 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)
No matter what you do, the command will only be retried a limited
number of times. There isn't an easy way to tell the thing to just keep
trying until it eventually succeeds.
> 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):-(
Sigh. Let's work out what the problems are when it is set to 1. I
don't want to support new drivers using the old error handling code. In
addition, at some point in the not to distant future I am going to blow
away the old error handling code, and at that time drivers using it will
essentially be running with no error handling.
-Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.rutgers.edu
