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