Re: Linux 2.5.3-pre1-aia1

[Jens Axboe]

On Sun, Jan 20 2002, Andre Hedrick wrote:
> > Even if the drive is programmed for 16 sectors in multi mode, it still
> > must honor lower transfer sizes. The fix I did was not to limit this,
> > but rather to only setup transfers for the amount of sectors in the
> > first chunk. This is indeed necessary now that we do not have a copy of
> > the request to fool around with.
> > 
> > > Basically as the Block maintainer, you pointed out I am restricted to 4k
> > > chunking in PIO.  You decided, in the interest of the block glue layer
> > > into the driver, to force early end request per Linus's requirements to
> > > return back every 4k completed to block regardless of the size of the
> > > total data requested.
> > 
> > Correct. The solution I did (which was one of the two I suggested) is
> > still the cleanest, IMHO.
> > 
> > > For the above two condition to be properly satisfied, I have to adjust
> > > and apply one driver policy make the driver behave and give the desired
> > > results.  We should note this will conform with future IDEMA proposals
> > > being submitted to the T committees.
> > 
> > I still don't see a description of why this would cause a lost
> > interrupt. What is the flaw in my theory and/or code?
> 
> We issue a setmultimode command and the driver defaults to maximum or 16
> sectors in most cases.  This means the drive is expecting 16 sectors, and

Correct so far.

> your design is to issue only 8 sectors or less.  The issuing of 8 sectors
> or less in the sector_count, while the device is expecting 16 is a setup
> for problems.

No it's not. By your standards, that would mean that if the device is
setup for 16 sector multi mode, then I could never ever issue requests
less than that (without doing some crap 'toss away extra data' stuff).
How else would you handle, eg, 2 sector requests with multi mode set?

> The effective operations your changes have created without addressing all
> the variables is to terminate the command in process.  Therefore, the
> decision made by you was to restrict the transfers to be process to the
> count in rq->current_nr_sectors.  There is no bounds checking based on the
> command executed.

I'm not stopping a request in progress. I told the drive that the
request is current_nr_sectors big, so once it finishes transferring
current_nr_sectors sectors it truly thinks it's really done with that
request. And it is. However, I'm leaving the request on the queue (or,
really, ide_end_request is not taking it off because
end_that_request_first is not indicating it's complete). So I'm simply
starting from scratch with the remaining data. See?

> *****************************
> The questions to ask "How would the host terminate a command in progress, 
> since BSY=1 (or DRQ=1) at this point?   Is that done via a DEVICE_RESET or
> SRST write?"

[snip]

Moot, there's no premature termination going on.

-- 
Jens Axboe