On Thu, Mar 08, 2007 at 04:46:41PM +0000, David Laight wrote:
> On Wed, Mar 07, 2007 at 10:37:54PM +0100, Manuel Bouyer wrote:
> > 
> > Could you try the attached patch against current ? This should fix the
> > issue for the most common cases, and hopefully it won't break any working
> > setups.
> > 
> > Manuel Bouyer <bouyer@antioche.eu.org>
> >      NetBSD: 26 ans d'experience feront toujours la difference
> 
> > -	if (wd->sc_flags & WDF_LBA48 &&
> > -	    (wd->sc_wdc_bio.blkno > LBA48_THRESHOLD ||
> > -	    (wd->sc_quirks & WD_QUIRK_FORCE_LBA48) != 0))
> > +	if (wd->sc_flags & WDF_LBA48)
> >  		wd->sc_wdc_bio.flags |= ATA_LBA48;
> >  	if (wd->sc_flags & WDF_LBA)
> >  		wd->sc_wdc_bio.flags |= ATA_LBA;
> 
> Doesn't that have the effect of always trying to do LBA48 transfers
> on disks that appear to support LBA48 ?

only if they are strictly larger than 128GB.

> 
> There are two problems:
> 1) The controller may not support LBA48 (even though the disk does)

Agreed. In such a case a workaround is to use the disk's jumper to clamp dowm
the size to 128GB.

> 2) There is a performance penalty for using LBA48 transfers.
> IIRC that is why 28 bit transfers are done whenever possible.

Long term I think we want to alway use LBA48 anyway, to have single transfers
larger than 128k. Right now we're limited to 64k because of MAXPHYS but this
is something that has to die. The performance penalty of such small
transfers is much highter than LBA48 ...

-- 
Manuel Bouyer, LIP6, Universite Paris VI.           Manuel.Bouyer@lip6.fr
     NetBSD: 26 ans d'experience feront toujours la difference
--