Re: SCSI woes (followup)

Patrick Mansfield
2002-09-24T22:23:19Z

On Tue, Sep 24, 2002 at 09:00:42PM +0100, Russell King wrote:

> I agree. I'm actually running against the "rmk" error handler, which
> has a fair number of the problems with the existing error handler fixed.
> For instance, it won't leave the HBA driver with a currently executing
> command and a stuck bus after attempting a retry.
>
> It also knows about channels, and knows that if it a command fails on
> a bus that has needed a reset, then the right thing to do is to reset
> it _once_ again and only once, because the bus is probably stuck.
>
> Oh, yes, I've put a lot of thought into this. 8)

Have you seen Mike Anderon's 2.5 cleanup patch?

Patch:

http://www-124.ibm.com/storageio/gen-io/patch-scsi_error-2.5.34-1.gz

Posting:

http://marc.theaimsgroup.com/?l=linux-scsi&m=103187417110244&w=2

I've been focusing on 2.5.x scsi (i.e. scsi multi-path), and would prefer
work be done there first.

> > > 5) the head of the request queue is _not_ the door lock, but the original
> > > request.
> >
> > I still don't see how this can be the original request. The TUR is sent via
> > the error handler, the INQUIRY resent during error handling does not call
> > scsi_request_fn().
> >
> > So, where is the request requeued?
>
> A request received via ioctl is queued at the tail of the request queue,
> not the head. I can give you a reference if you'd like. 8)

Yes, I understand that, but where is the original, non-door lock request
coming from?

My point is that I think there is none, and there can't be any on
a partially initialized device, since there are no command blocks
for the device - put a printk in the scsi_ioctl or such to dump
Scsi_Device::queue_depth and/or Scsi_Device::has_cmdblocks.

-- Patrick Mansfield