Re: mpt(4) timeout recovery improvements

[Brian Buhrow <buhrow%nfbcal.org@localhost>]

        hello Edgar.  I know we've been  corresponding on this for a while and
you've been trying my patches and making your own, but I know the answers
to some of the  questions you asked since I had to answer them when I wrote
the original patches.  See below for What I know in the context of your
question.


--- Forwarded mail from Edgar =?iso-8859-1?B?RnXf?= 
<ef%math.uni-bonn.de@localhost>

Now, what's the correct way of reset/init the IOC and returning everything 
to scsipi? I guess the correct order is to reset (which leave the IOC in 
the stopped state), then to set xs->error and call scsipi_done(xs) on all 
pending operations and then init the IOC (which empties the request queue).

        No, that order won't work.  If you look at the patch, I return all
pending SCSI requests to the driver instance before resetting the IOC.  If
you  don't  return the requests to the SCSI layer before resetting the
card, you'll lose the  requests entirely and potentially create a real
mess.


First question: what's the appropriate xs->error? XS_TIMEOUT seems to work, 
but doesn't seem correct (save the original timed out request, of course). 
Is there some XS_NEVER_MIND_JUST_TRY_AGAIN code?
        I picked that error because most other errors cause the SCSI subsystem
to not retry the request which wasn't what I wanted.    You can also use
XS_REQUEUE, which looks like it falls through to the XS_TIMEOUT case.


Second question: When repeatedly calling scsipi_done(), can it happen that 
scsipi tries to re-queue these requests before I return? I would then loose 
them when re-initializing the IOC.

        No.  The splbio() takes care of that.

Third question: Do I need to care about xs->xs_callout?

        Yes, you do.  If you don't clear the callout when you  clear the
requests, you'll find the test I wrote for null pointers triggering in the
mpt_timeout function.