From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Cc: Greg Felix <greg.felix@gmail.com>,
Oliver Tennert <O.Tennert@science-computing.de>,
linux-kernel@vger.kernel.org
Subject: Re: IDE HPA
Date: Tue, 30 Aug 2005 18:05:18 +0100 [thread overview]
Message-ID: <1125421518.8276.45.camel@localhost.localdomain> (raw)
In-Reply-To: <58cb370e0508300916432fc003@mail.gmail.com>
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 numbers of systems. Large numbers of disks as strapped for
32GB and other clipping arrangements. With a vendor hat on thats
unworkable because
a) It will stop thousands of people installing their systems
b) Many users will get horrible corruption when they update the kernel
and their box explodes as the fs tries to write to areas of disk that
have vanished mysteriously.
(and we know all about this because ancient kernels had options for
doing this in the compile that burned people)
So its a very bad idea indeed. A boot option for not disabling the hpa
is possibly sensible for a few users who want that, or simply getting
them to fix their buggy user space app would be even simpler.
The only way I can see to truely automate it for most cases would be to
snoop the partition table if its MSDOS format and see if the table
matches the HPA clipped disk or the non-HPA clipped disk. If it matches
the HPA clipped disk then you know not to fiddle. Otherwise its either a
new disk, clipped by the 32GB jumper, non-x86 disk etc in which case you
might as well disable any HPA.
Alan
next prev parent reply other threads:[~2005-08-30 16:36 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 ` Greg Felix
2005-08-30 16:16 ` Bartlomiej Zolnierkiewicz
2005-08-30 17:05 ` Alan Cox [this message]
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=1125421518.8276.45.camel@localhost.localdomain \
--to=alan@lxorguk.ukuu.org.uk \
--cc=O.Tennert@science-computing.de \
--cc=bzolnier@gmail.com \
--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
Powered by JetHome