Jeff Garzik wrote:
It seems to me that one should write an ATA-specific Device Mapper
driver, which layers on top of an ATA disk. The driver obtains the
starting location of HPA, then exports two block devices: one for the
primary data area, and one for the HPA.
I've stayed out of this, bu
Peter Jones wrote:
So where would you envision this code to check the partition table, the
HPA/host default disk size, and guess how things should be set up?
From a userland perspective, it's very difficult to let users know
they'll be screwing themselves by partitioning the entire disk, so we
On Fri, Sep 02, 2005 at 09:22:58PM +0100, Alan Cox wrote:
> You installed it on Red Hat 7 ? I think 7, may have been 6.x or earlier.
> This behaviour goes back pretty much to the creation of the ATA spec for
> HPA. In fact if it was that long ago IBM shipped it with Windows so it
> did have a parti
On Gwe, 2005-09-02 at 17:14 -0400, Peter Jones wrote:
> > You installed it on Red Hat 7 ? I think 7, may have been 6.x or earlier.
>
> You may be right -- it's likely that I shrank my windows partition on
> some other OS or Distro that wasn't designed with to screw up the disk.
If you shrink exis
On Fri, 2005-09-02 at 21:22 +0100, Alan Cox wrote:
> On Gwe, 2005-09-02 at 15:14 -0400, Peter Jones wrote:
> > Ugh. So some BIOSes use it for legitimate reasons (like thinkpads), and
> > some use it to work around BIOS bugs. Great.
>
> All are legitimate uses. The partition table tells you which
On Gwe, 2005-09-02 at 15:14 -0400, Peter Jones wrote:
> Ugh. So some BIOSes use it for legitimate reasons (like thinkpads), and
> some use it to work around BIOS bugs. Great.
All are legitimate uses. The partition table tells you which.
> Mine didn't, but it does have an HPA. Thankfully we wer
On Fri, 2005-09-02 at 19:59 +0100, Alan Cox wrote:
> On Gwe, 2005-09-02 at 14:09 -0400, Peter Jones wrote:
> > (if there's already a straightforward way, feel free to clue me in --
> > but the default should almost certainly be to assume the HPA is set up
> > correctly, shouldn't it?)
>
> The norm
On Gwe, 2005-09-02 at 14:09 -0400, Peter Jones wrote:
> (if there's already a straightforward way, feel free to clue me in --
> but the default should almost certainly be to assume the HPA is set up
> correctly, shouldn't it?)
The normal use of HPA is to clip drives to get them past BIOS boot
chec
On Gwe, 2005-09-02 at 19:44 +0200, Molle Bestefich wrote:
> The current default is causing grief because dmraid doesn't work, grub
> doesn't work and other userspace apps probably breaks too. Users have
> to google and post to mailing lists just to get things to work (... if
> they could, which wo
On Fri, 2005-09-02 at 19:44 +0200, Molle Bestefich wrote:
> Related matters:
> If you decide to include the HPA in one of your filesystems, is there
> not a big risk that the BIOS will overwrite something there?
Isn't the bigger risk that if you include the HPA in your block device,
you'll overwr
Molle Bestefich <[EMAIL PROTECTED]> wrote:
> The other way round, users would have to google to find the kernel
> option that claims the HPA area (if they felt the need to overwrite
> the BIOS's backup area), but those that felt the need would then be
> rewarded with eg. 10 GB extra disk space. A
On Fri, Sep 02, 2005 at 06:05:12PM +0100, Alan Cox wrote:
> On Gwe, 2005-09-02 at 18:24 +0200, Molle Bestefich wrote:
> > I meant the BIOS setup screen, not a firmware update...
> > Supposedly the BIOS can change the bounds of the HPA with special ATA
> > commands..
>
> I've yet to see a BIOS tha
Alan Cox wrote:
> Molle Bestefich wrote:
> > Not if, as proposed, there was a kernel switch to enable including the
> > HPA in the disc area.
>
> And users magically knew about it - thats why it has to default the
> other way.
Ok, so just to reiterate..
The current default is causing grief becau
On Gwe, 2005-09-02 at 18:24 +0200, Molle Bestefich wrote:
> I meant the BIOS setup screen, not a firmware update...
> Supposedly the BIOS can change the bounds of the HPA with special ATA
> commands..
I've yet to see a BIOS that exposed the functionality
> Not if, as proposed, there was a kernel
Alan Cox wrote:
> > If one does not care to use the HPA, one should disable it in the
> > BIOS entirely, so that everywhere (!) the entire disk is seen.
>
> And in the real world BIOSes don't get updated often
> by vendors let alone by users.
I meant the BIOS setup screen, not a firmware update...
Molle Bestefich <[EMAIL PROTECTED]> wrote:
> If HPA were exposed as /dev/.../hpa then it wouldn't be possible to
> create such a filesystem. I'm guessing it's not possible with Windows
> either, or with any BIOS-based OS.
Such filesystems already exist. Changing this behaviour now would break
exi
On Gwe, 2005-09-02 at 15:33 +0200, Molle Bestefich wrote:
> > It also wouldn't solve the case of a file system that spans both inside and
> > outside the HPA.
>
> If HPA were exposed as /dev/.../hpa then it wouldn't be possible to
> create such a filesystem. I'm guessing it's not possible with Win
Alan Cox wrote:
> > If the formula is to fix all the userspace apps to take into account a
> > potential HPA, then eg. FDISK + SFDISK + Disk Druid et al should also
> > be fixed. Because if you create a partition spanning your entire
> > disk, including the HPA area, and your boot files by some co
> If the formula is to fix all the userspace apps to take into account a
> potential HPA, then eg. FDISK + SFDISK + Disk Druid et al should also
> be fixed. Because if you create a partition spanning your entire
> disk, including the HPA area, and your boot files by some coincidence
> ends up in t
Alan Cox wrote:
> Greg Felix wrote:
> > Right. I get the output at bootup time. It reads that the HPA is
> > 20MB. Which is exactly the size of how far off the metadata is in
> > Linux (once the HPA is disabled).
>
> So your actual problem is nothing to do with the kernel or with the HPA
> beha
On 8/30/05, Alan Cox <[EMAIL PROTECTED]> wrote:
> On Maw, 2005-08-30 at 18:16 +0200, Bartlomiej Zolnierkiewicz wrote:
> > HPA shouldn't be disabled by default and new kernel parameter ("hdx=hpa")
> > should be added for disabling HPA (yep, people with buggy BIOS-es will
> > have to add this paramet
On Maw, 2005-08-30 at 18:16 +0200, Bartlomiej Zolnierkiewicz wrote:
> HPA shouldn't be disabled by default and new kernel parameter ("hdx=hpa")
> should be added for disabling HPA (yep, people with buggy BIOS-es will
> have to add this parameter to their kernel command line, sorry).
Thats large nu
Hi,
OK, it seems, there is enough need for bringing back more control over HPA.
HPA shouldn't be disabled by default and new kernel parameter ("hdx=hpa")
should be added for disabling HPA (yep, people with buggy BIOS-es will
have to add this parameter to their kernel command line, sorry).
If som
On Maw, 2005-08-30 at 09:52 -0600, Greg Felix wrote:
> Right. I get the output at bootup time. It reads that the HPA is
> 20MB. Which is exactly the size of how far off the metadata is in
> Linux (once the HPA is disabled).
So your actual problem is nothing to do with the kernel or with the HPA
Kernel list,
A while ago there was some discussion on the list regarding the
behavior of the kernel in regards to its unconditional disabling of
host protected areas of hard drives. I ran into a problem this causes
with some RAID controllers. I've been discussing the problem with
both the ata-ra
25 matches
Mail list logo
