[8349] in linux-scsi channel archive
RE: spoofing SCSI retries
daemon@ATHENA.MIT.EDU (Ralston, Steve)
Fri Mar 10 04:30:04 2000
Message-ID: <B2B3C90E45AED111B7B40001FA7E520A03833FD7@exw-kansas.ks.lsil.com>
From: "Ralston, Steve" <steve.ralston@lsil.com>
To: "'mjacob@feral.com'" <mjacob@feral.com>
Cc: "'linux-scsi'" <linux-scsi@vger.rutgers.edu>
Date: Fri, 10 Mar 2000 03:12:32 -0600
MIME-Version: 1.0
Content-Type: text/plain
Thanks. Running on 2.3.47 at the moment but fall
back to 2.2.{5,12,n} also.
Yeah I have to give the new_eh_code another
serious go rsn.
BTW: Slight correction to my orig. post (sorry):
I've tried:
1) sc->result = DID_BUS_BUSY << 16; // 00020000h
// YIKES! This seems to kill linux interrupt handler!!!
1b) sc-result = DID_ERROR << 16; // 00070000h
// Sort of works, but end up with corrupted file system
2) sc->result = 0x08; // 00000008h, Try SCSI BUSY!
// Sort of works, but end up with io process hang
3) sc->result = 0x28; // 00000028h, Try SCSI QUEUE_FULL!
// Best results so far...
Plus I've had periods where the device temporarily went
away, and I set:
4) sc->result = DID_NO_CONNECT << 16; // 00010000h, spoof SelTO
// fairly disastrous results --> io/device failure, fs corruption
Thanks,
-SteveR
> -----Original Message-----
> From: Matthew Jacob [SMTP:mjacob@feral.com]
> Sent: Friday, March 10, 2000 2:50 AM
> To: Ralston, Steve
> Cc: 'linux-scsi'
> Subject: Re: spoofing SCSI retries
>
>
> 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 majordomo@vger.rutgers.edu
> >
>
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.rutgers.edu
