tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: WD_QUIRK_FORCE_LBA48



On Wed, Dec 16, 2009 at 12:40:30PM +0100, Christoph Badura wrote:
> On Wed, Dec 16, 2009 at 10:13:23AM +0100, Manuel Bouyer wrote:
> > Drives: most drives manufactured before 2004 with more than 138Gb I guess.
> > The fact that it took 2 years for the problem to show up is enough
> > of a proof.
> 
> And the fact that after two years a changed was committed to wd.c that
> made it make illegal requests that cause the behaviour is merely coincidence?
> 
> > > > Yes. As I already said we got the sector 0xfffffff problem 2 years after
> > > > we added LBA48 support. So the earlier LBA48 drives probably used
> > > > 0x10000000 and not 0xfffffff for the max LBA28 capacity.
> > > 
> > > You haven't provided any evidence of that.
> > 
> > The fact that our driver worked with large drives before 2004 is enough.
> 
> OK, so lets look at the CVS history.
> 
> When the LBA48 support was committed in rev 1.220 in 2002 it used LBA48
> access for all blocks unconditionally and there wasn't any problem with
> large drives.

Ok. 
> 
> Then in rev. 1.256 the driver was changed to use LBA48 accesses only for
> non-LBA28 addressable sectors.

OK, I didn't remember this change. The CVS log suggest this could have been
an issue with a controller that doesn't work with LBA48, precisely.

> But the constant for the threshold was
> botched and it used LBA48 accesses for all sectores starting with sector 2^24.
> No LBA28 access crossed the actual LBA48 border.  And there wasn't a any
> problem with large drives.
> 
> Then on 2008-07-10 in rev 1.257 the threshold constant was corrected.  That
> caused the driver to make illegal LBA28 accesses across the LBA48 border.

that was rev 1.258, and this was 2003/07/10.

> 
> Then, a good year later the WD_QUIRK_FORCE_LBA48 was introduced to work around
> the bug introduced in 1.257 with LBA28 accesses that go beyond the border
> defined in words 60:61 (on LBA48 drives, obviously).

Yea. I didn't notice until recently that the LBA48 was decreased by
one between ATA6r1 and ATA6r3.

> 
> And you seriously want me to believe that it wasn't the bug introduced rev 
> 1.257
> that caused the issue but that somehow the disk drive manufacturers conspired
> to flood the market with millions of drives with out of spec firmware?
> 
> Please note: I am not entirely ruling out that there might LBA48 drivers out
> there that report 2^28 sectors as the LBA28 size.  But nobody else seems to
> care and I think it is not worth to build convoluted software workarounds
> unless we really know such drives exist.

Come on, it's not convoluted. It's just using the value provided by the
drive in words 60:61 of IDENTIFY instead of a constant. I believe it
would even be more correct from the specs POV than using a constant.

I can test such a change if you don't want to do it.

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--


Home | Main Index | Thread Index | Old Index