On 2/9/2011 10:37 AM, Alan Cox wrote: > Unlocking the HPA is actually necessary for sanity on a lot of systems Right.. ones that were partitioned using an older kernel with the buggy behavior of unlocking it by default. > too, and there are really no standards. Remember the primary use of HPA > has actually been to hide most of the disk from buggy BIOSen so that the > OS can then unlock it after the BIOS has stopped looking. The ATA spec describes the HPA saying: A reserved area for data storage outside the normal operating system file system is required for several specialized applications. This tells me that it is intended for the bios to reserve an area of the disk that the OS should NOT access. So far the only use of it that I have seen is by bioses to hide a small area, presumably to store platform specific information. I see about a dozen reports on the ubuntu forums and bug tracker each year of people with HPA problems and it always seems to be a small area, as opposed to hiding everything above 128 MB or something. > We cannot create a situation where any system that now unlocks the HPA > ceases to do so, that breaks back compat in a potentially catastrophic > way. We already have that situation today. This is the reason why Ubuntu defaulted to having libata unlock the HPA by default, even though Linus's tree did not ( and AFAIK, still does not, excepting the commit in question here ). No matter which choice you make, you cause some breakage, so the goal is to minimize that breakage. This commit attempts to do that by auto unlocking the HPA iff it appears necessary to access user data. It is that test that I am asking be refined a bit since it finds false positives for raid users. > Probably the fakeraid layers need a way to see the geometry reported > before unlock, then they can make their own decisions. The lock/unlock in > hardware is just a hardware hack. We can still do the unlocking of > hardware and using whatever values we choose in software at different > points. > > "Should we unlock" is almost an academic debate given we are the OS and > control the commands sent to the drive anyway. Again, Linus's tree does not unlock, and should not since the bios presumably had a reason for locking it in the first place ( it stores something there ). -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
