tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: mpt(4) timeout recovery improvements



> On the whole, I like this patch
Thanks.

> 1.  The original patch I created tries to recover from a number of
> conditions other than simple timeouts based on messages that come back from
> the IOC.  In such cases, mpt_restart() is called.  I think those events can
> still be handled gracefully by your reworked [m]pt_restart() routine.
Yes. That's why I didn't integrate the code into mpt_timeout().
However, for now, I wanted to stick to the error I could actually test, 
i.e., provoke.

> However, I wonder why the mpt_restart() has a second argument?  Is that
> simply for debugging purposes?
No, its the failed request whose xfer->error has already been set.
All other requests are scsipi_done()'d with xfer->error set to XS_REQUEUE.
Additionally, req0 is not counted for the "requeued n requests" message.

> Could that second argument be dropped?
No. You have to remember which transfer to fail with, i.e. XS_TIMEOUT and 
which to return with the XS_REQUEUE non-error. I thought about setting 
req->xfer->error = XS_NOERROR in mpt_scsipi_request() and, in mpt_restart(), 
only set it to XS_REQUEUE if it was still XS_NOERROR, but I couldn't find 
out whether that was safe.

You can either pass NULL or a request whose xfer->error has already set 
to something other than XS_REQUEUE.


Home | Main Index | Thread Index | Old Index