Re: Linux 2.5.3-pre1-aia1

[Andre Hedrick]

On Mon, 21 Jan 2002, Vojtech Pavlik wrote:

> On Mon, Jan 21, 2002 at 12:29:54PM +0100, Jens Axboe wrote:
> > On Mon, Jan 21 2002, Vojtech Pavlik wrote:
> > > I always thought it is like this (and this is what I still believe after
> > > having read the sprcification):
> > > 
> > > ---
> > > SET_MUTIPLE 16 sectors
> > > ---
> > > READ_MULTIPLE 24 sectors
> > > IRQ
> > > PIO transfer 16 sectors
> > > IRQ
> > > PIO transfer 8 sectors
> > > ---
> > > 
> > > Where am I wrong?
> > 
> > I agree completely, see previous mail.
> > 
> > > By the way, the device *isn't* required to support any lower multiple
> > > count than the maximum one it advertizes. Ugly.
> > 
> > Oh? That basically narrows down the multi count value from hdparm to a
> > boolean on-or-off. I'd be surprised to see any drives break with lower
> > multi count in real life, though..
> 
> The spec seems to mandate to check the Identify data again after setting
> new Multmode to see whether the drive supported the value we wanted to
> program it to.

Forget the TEXT in the command description, cause what you are looking for
is not there.  It is stated and expressed in the state-diagrams, only.
There is minimal text, and only timing profiles for the device
manufacturers.  How to make it go is in the pictures and the text is only
supporting information.

That is why it is so painful to decode, and why it does not fit into the
requirements of early return of ever 4k or page of data back to the upper
layers.  So if we can not do the entire transfer w/ contigious memory we
are forced into this game of jump through the hoops.

Regards,

Andre Hedrick
Linux Disk Certification Project                Linux ATA Development