From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
To: Greg Felix <greg.felix@gmail.com>
Cc: Oliver Tennert <O.Tennert@science-computing.de>,
linux-kernel@vger.kernel.org
Subject: Re: IDE HPA
Date: Tue, 30 Aug 2005 18:16:36 +0200 [thread overview]
Message-ID: <58cb370e0508300916432fc003@mail.gmail.com> (raw)
In-Reply-To: <87941b4c05083008523cddbb2a@mail.gmail.com>
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 somebody wants to go ahead and submit actual patches...
[s]he is welcomed to.
Thanks,
Bartlomiej
On 8/30/05, Greg Felix <greg.felix@gmail.com> wrote:
> 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-raid mailing list and Oliver. I feel we should copy the
> kernel list because we don't think the current behavior is the
> desirable one.
>
> Below is some discussion Oliver and I have had about it.
>
> > > Sorry for taking up your time. I saw your emails recently to the Linux
> > > kernel mailing list concerning IDE host protected areas. You were
> > > asking why they are unconditionally disabled. Did anyone ever give
> > > you a good response to your question?
> > >
> >
> > Hi Greg,
> >
> > Alan Cox answered, but he focussed entirely on the point that in his opinion,
> > the main reason for using HPAs is something like backward-compatibility of
> > the drive with old BIOSses that have problems with large disks.
> >
> > But to be honest, I have never ever heard about that being a motivation to use
> > an HPA. And as far as I know, that was not the reason for introducing an HPA
> > anyway.
> >
> > As far as I know, some HW vendors store some diagnostic tools in an HPA.
> >
> > > I have found a bug where my BIOS is storing some RAID metadata near
> > > the end of a disk. The problem i run into is that the end of the disk
> > > is 20MB off when Linux counts the HPA.
> > >
> >
> > So you are sure that your RAID controller uses an HPA to store the metadata? I
> > am asking because some RAID controllers simply cut away a moderate region
> > from the end of the disks and present the OS with a smaller disk, which is
> > but a virtual one. In that case, no HPA is used. It is rather like the MD
> > driver works.
>
> My RAID controller isn't using an HPA to store metadata. It's simply
> recognizing that there is an HPA and reading its 63 sector backwards
> offset starting at totalSectors-sizeOfHPA.
>
> > But of course, the Linux kernel simply shows whether an HPA is used or not.
>
> 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).
>
> > > Have you heard of any kernel parameters that disable the HPA disabling?
> > >
> >
> > There is no runtime variable, the code is run unconditionally, unfortunately.
>
> I've found where the code is and it'd be a simple hack to fix it and
> recompile, but I'm concerned that other people will run into this at
> some point. I think we or the people who make decisions ought to
> revisit the disabling of HPAs idea.
>
> > > Thanks for your time,
> > > Greg Felix
> >
> > Not at all! Should we CC the mail the kernel mailing list?
>
> I think we should. In fact, I will with this email.
>
> > Best regards
> >
> > Oliver
next prev parent reply other threads:[~2005-08-30 16:16 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 [this message]
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
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=58cb370e0508300916432fc003@mail.gmail.com \
--to=bzolnier@gmail.com \
--cc=O.Tennert@science-computing.de \
--cc=greg.felix@gmail.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