public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Molle Bestefich <molle.bestefich@gmail.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: ataraid-list@redhat.com, linux-kernel@vger.kernel.org
Subject: Re: IDE HPA
Date: Fri, 2 Sep 2005 15:33:36 +0200	[thread overview]
Message-ID: <62b0912f05090206331d04afd3@mail.gmail.com> (raw)
In-Reply-To: <1125666332.30867.10.camel@localhost.localdomain>

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 coincidence
> > ends up in the HPA part of the disk, the BIOS won't be able to read
> > them, and your system will not boot.  And if you fix those tools now,
> 
> The distribution vendors already put the boot area low down the disk to
> handle a whole variety of problems like this and the 1024 cylinder limit
> on old BIOSes.

Only as an option - it's not always possible.
For example one might have a Windows partition already in place, etc..

> > what about users that use older Linux distributions?  They'll have a
> > parade of problems coming to them with their new HPA-enabled disks
> > because every userspace tool assumes that <BIOS sector count == Linux
> > sector count>.
> 
> I work for a vendor. I get most of our IDE layer bugs. And do you know
> HPA doesn't really feature.

Fair enough.  It took 5 seconds of googling to find a guy whose GRUB
stopped working because of the HPA, so at least *some* people are
already having problems...

> > > It isnt the kernels fault if you compute from of end of disk rather than
> > > from end of non reserved area is it ?
> >
> > I agree that the entire disk should be visible under Linux.  But
> > instead of fixing every userspace app that assumes <BIOS sector count
> > == Linux sector count> (I'm guessing that's a lot), how about simply
> > exporting the HPA as /dev/ide/hostX/busY/targetZ/lunA/hpa, next to the
> > 'disc' device ?
> 
> A lot of applications assume Linux reported size == real disk size.

I can't think of any, but you might be right.

> 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
either, or with any BIOS-based OS.

Creating filesystems that include the HPA defeats the entire idea of
the HPA in the first place.
  
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.

The inclusion of the HPA in /dev/.../disc should be a special case for
those unfortunate souls with laptops where the HPA cannot be disabled
because their BIOS is crap, IMHO.

  reply	other threads:[~2005-09-02 13:33 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <87941b4c05082913101e15ddda@mail.gmail.com>
     [not found] ` <200508300859.19701.tennert@science-computing.de>
2005-08-30 15:52   ` IDE HPA Greg Felix
2005-08-30 16:16     ` Bartlomiej Zolnierkiewicz
2005-08-30 17:05       ` Alan Cox
2005-08-31  0:30         ` Bartlomiej Zolnierkiewicz
2005-08-30 16:38     ` Alan Cox
     [not found]       ` <87941b4c050830095111bf484e@mail.gmail.com>
2005-09-02  7:27         ` Molle Bestefich
2005-09-02 13:05           ` Alan Cox
2005-09-02 13:33             ` Molle Bestefich [this message]
2005-09-02 14:35               ` Matthew Garrett
2005-09-02 16:24                 ` Molle Bestefich
2005-09-02 17:05                   ` Alan Cox
2005-09-02 17:44                     ` Molle Bestefich
2005-09-02 18:04                       ` Matthew Garrett
2005-09-02 18:09                       ` Peter Jones
2005-09-02 18:59                         ` Alan Cox
2005-09-02 19:14                           ` Peter Jones
2005-09-02 20:22                             ` Alan Cox
2005-09-02 21:14                               ` Peter Jones
2005-09-03  0:05                                 ` Alan Cox
2005-09-03 23:31                                 ` Jeff Garzik
2005-09-07 14:52                                   ` Bill Davidsen
2005-09-03  0:03                               ` Pekka Pietikainen
2005-09-02 18:57                       ` Alan Cox
2005-09-02 17:57                     ` Vojtech Pavlik
2005-09-02 14:50               ` Alan Cox

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=62b0912f05090206331d04afd3@mail.gmail.com \
    --to=molle.bestefich@gmail.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=ataraid-list@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox