tech-kern archive

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


On Tue, Dec 15, 2009 at 06:17:27PM +0100, Christoph Badura wrote:
> On Tue, Dec 15, 2009 at 05:37:34PM +0100, Manuel Bouyer wrote:
> > On Tue, Dec 15, 2009 at 05:25:47PM +0100, Christoph Badura wrote:
> > > The check I proposed in the patch effectively is:
> > > 
> > > if (drive supports LBA48) {
> > >   if (transfer accesses sectors beyond 0xffffffe)
> > >           use LBA48 transfer;
> > but that's wrong, for some drives 0xffffffe should be 0xfffffff
> Why is that wrong?  *All* sectors (from 0 to max capacity) are accessible in
> LBA48 mode with LBA48 commands. 

Exept if the controller doesn't support LBA48.

> So even for LBA48 drives that report
> 0x10000000 as the LBA28 capacity, accessing sectors from 0xffffffe up
> with LBA48 commands works.  Do such drives actually exist?

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.

> > Sure. But some drives report it as 0x10000000. This is why I suggest
> > using the content of word 60:61 instead of a constant.
> Why?  The contents of that word tell you how many sectors are accessible
> with LBA28 commands.  The same sectors are accessible with LBA48 commands,
> too.  So there is little gain in using LBA48 commands to access them.
                                         ^^^^^ LBA28 I guess

What this changes is that systems with controller which don't understand
LBA48 can still access the last sector of the drive.
Otherwise we could just use LBA48 for the whole drive.

Manuel Bouyer <>
     NetBSD: 26 ans d'experience feront toujours la difference

Home | Main Index | Thread Index | Old Index