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,
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,
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
> 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
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
>
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
behaviour ?
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 the
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
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 Windows
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
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...
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:
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 because
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 that
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. And if
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
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 would
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
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 normal use
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
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 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 existing
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
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
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
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
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
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
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
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
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
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
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 parameter to
50 matches
Mail list logo
