Re: [parisc-linux] Re: tag starvation

[James Bottomley <James.Bottomley@HansenPartnership.com>]

> > That's essentially it.  A driver is allowed to execute simple tagged
> > commands
> > in any order it chooses (since it knows its own internal platter
> > topology, it

> James, thanks for the excellent explanation. But did you mean device
> or drive?  (instead of "driver") 

drive (but actually device is more accurate).

> > One thing that irritates me about 
> > this option is that it should be a global one (belonging to the whole
> > SCSI 
> > subsystem) not local to each driver.

> It should also be *per drive*. Different drives implement different
> numbers of queue tags (eg disk array vs simple mech). 

That's what I mean:  Inside scsi_scan.c there's a table which identifies 
various devices (by INQUIRY string) and takes certain actions (scan all luns, 
turn on/off tag queueing etc.).  There should be module parameters that allow 
adding to or modifying this.  In addition, there should be a module parameter 
that allows setting these actions by (scsi,channel,target,lun) quad, then we 
wouldn't need each of the low level drivers to have its own module commands 
for doing this.

> > Obviously, since the SCSI mid-layer also keeps a timer on outstanding 
> > commands, it is a complete waste to duplicate this inside the driver.
> 
> > Unfortunately, the first the driver hears from the mid-layer about a
> > problem 
> > command is when the mid-layer wants it aborted, by which time it is a
> > bit lat
> >  e.

> This is fun part about driver interactions in the error recovery path.
> Could one avoid this mess if the SCSI interface driver could guarantee
> the IO will complete (with or w/o error) with-in the time frame
> specified by the device (eg tape or disk) driver? 

Actually, I looked and the timeout is now 10s, not 2s.  The upper device 
drivers (st, sd etc.) do get to override this.  The problems tend to come when 
the error recovery takes over.

James