public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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