Re: [PATCH 1/3] ide: add "ignore_hpa" module parameter

From: Frans Pop
Date: Tue May 26 2009 - 08:53:34 EST

On Tuesday 26 May 2009, Bartlomiej Zolnierkiewicz wrote:
> First time with the introduction of the default IDE HPA behavior of
> always giving the access to the full capacity of a disk and leaving
> decisions about HPA preservation/removal up to the installer & user.
> Second time when said distributions switched from IDE to libata (which
> uses the different default behavior as it limits the capacity to
> non-HPA part).

Has there really been something like a deliberate switch?

In my experience with Debian there's been no such thing. ATA has just been
gradually enabled. (And initially that resulted in quite a mess because
some devices would be supported by two drivers and the kernel couldn't
even make up its own mind which one it preferred, resulting in random
switches between drivers. At least that was resolved at some point.)

However, I must admit that Debian has not handled the IDE-ATA switch very
well. So far users have mostly been left to deal with any fallout for

> Please note that no fancy sysfs support was needed to prevent the
> problem: both stacks (ide & libata) support HDIO_DRIVE_TASK ioctl which
> can be used to execute commands needed to retrieve/change HPA setting.

I don't really see how that would help. The fact that fancy ioctls exist
does not mean users or even distros have the knowledge needed to use
them. IMHO such issues should be dealt with at the level where that
knowledge is available: the kernel community.

> Moreover the (much needed) work from Tejun doesn't help a tiny bit in
> case of people migrating their *working* setups from IDE to libata

>From what I've seen now that seems the most important case that needs
supporting, as well as the case where a working setup would migrate from
IDE with old HPA default to IDE with new HPA default.

Naive thought: wouldn't it be possible to check whether a partition
overlaps the HPA boundary and warn or even bug out in that case?

> (at least in distro upgrade case this could have been handled by distro
> installer but see above) and hitting the compatibility issue mentioned
> in bug #13365.

At least in the case of Debian there is no such thing as a "distro
installer" involved in upgrades. Debian only uses its installer for new
installs, not for upgrades between releases. The last is purely done by
regular package management.

It's also not sufficient to rely on that anyway because users sometimes do
install newer upstream kernels (whether because of issues or to help with
kernel development/testing), which means no distro upgrade is involved.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at