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?= <[email protected]> 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.
