[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
On Sat, Dec 05, 2009 at 03:06:50PM +0000, David Laight wrote:
> The 'wd' (aka ATA disk) driver has a load of code for the
> WD_QUIRK_FORCE_LBA48 quirk.
> This forces LBA48 transfers for an ever increasing number of disks.
> My suspicion is that the problems only relate to transfers that
> actually cross the LBA48 boundary.
> So quite possibly checking:
> wd->sc_wdc_bio.blkno + nblks > LBA48_THRESHOLD
> would remove the need for the quirk.
I have Seagate and Hitachi drives that refuse accesses across the LBA28
boundary with LBA28 commands.
In my opinion this shouldn't cause a error to pop up in the logs.
I don't know what the ATA standard has to say however.
I belive the original intention of this quirk, based on my
interpertation of the comment, is that some Seagate drives
would actually refuse access to the last LBA28 sector w/ LBA28
commands. This would seem to be a actual bug in the drive
firmware that we need to work around.
I do not believe that anyone should expect to be able to access data
above the LBA28 boundary if they have a LBA48-incompatible controller.
Currently, I wouldn't be surprised if the automatic WD_QUIRK_FORCE_LBA48
detection has actually "broken" setups on LBA48-incompatible controllers.
So based on my understanding:
- LBA48 commands should only be used for
- across-or-above-LBA28-boundary accesses
- accesses that start on LBA48_THRESHOLD and are of a single sector
and need WD_QUIRK_FORCE_LBA48 to work around drive firmware oddities
This wouldn't break accesses within 128GiB on LBA48-incompatible
controllers, as LBA28 commands would always be used for accesses within
128GiB, which is really all we can expect to work in such a case.
FWIW, I've tested a PIIX4 and PCI0646.
Both support LBA48 despite their age.
Main Index |
Thread Index |