[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
On Tue, Dec 15, 2009 at 07:35:42PM +0100, Manuel Bouyer wrote:
> > 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.
Yeah, and if the drive actually reports 2^28 LBA28 accessible sectors instead
of 2^28-1 as most versions of the spec requires.
I've asked you multiple times: which drives and controllers exhibit that
behaviour. Please give me links where I can find proof that this actually
exists and is a problem.
> 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 driver violates the
specification because it tries to access sectors beyond 2^28-1 in LBA28 mode
and it fails to recover when the drives reports an error about that. I've
posted proof of that and suggested fixes. The behaviour you cite could as
easily explained by the erroneous behaviour of our buggy driver. So please
give me concrete evidence to the contrary.
> 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.
You know. I'm not going to waste any more time on this. Please see to it,
that the above two bugs that I have mentioned and provided corrections for
Now, in case there are actually people with non-LBA48 capable IDE controllers
and LBA48 capable IDE drives that are bothered that really can't access
the last sector out of 268435456 sectors, I make the following promise:
if there is actually a single person for whom it is important enough to access
that last sector that they will ship a drive and IDE controller that exhibit
the behaviour to me, then I will fix the access to that last sector for them.
Main Index |
Thread Index |