possible bug in ide-disk.c (2.6.18.2 but also older)

possible bug in ide-disk.c (2.6.18.2 but also older)

[Andreas Leitgeb]

Since I got not even a beep as answer, I'm trying again
to get this through to someone who cares:

The problem, I'm writing about is really a major nuissance
to whom it hits, because due to this problem the system turns
off dma for the harddisks, which makes the machine painfully slow.

However it seems to show up only for a limited set of 
harddisks, one of which happens to be in one of my machines.

Here is the complete previous attempt at submitting it
(with all the details I was able to come up with):

----- Forwarded message from Andreas Leitgeb <avl@logic.at> -----
From: Andreas Leitgeb <avl@logic.at>
Subject: possible bug in ide-disk.c (2.6.17.13 but also older)
To: B.Zolnierkiewicz@elka.pw.edu.pl
Cc: linux-ide@vger.kernel.org
Delivery-date: Tue, 19 Sep 2006 10:01:40 +0200
Reply-To: avl@logic.at

I noticed the bug only recently, but checking with older Knoppix
boot-cds, it seems to date back to about 2.6.9, where disk-access
was generally slower, and hpa probably not detected at all)

The symptom of the bug is, that an HPA is believed (by the kernel)
to exist, and the capacity is believed to be one sector larger.
When accessing that one last sector, the harddisk (rightly) reports
an error, which causes the kernel to retry a few times (getting
the same error each time) and finally the kernel switches off dma.

The problem is in  idedisk_read_native_max_address()
and equivalently in idedisk_read_native_max_address_ext()
in a line like this (near the end):
  addr++; /* since the return value is (maxlba - 1), we add 1 */

I believe that this is wrong, in so far as it is device-specific.
My belief is, that what might need to be added instead is drive->sect0
or perhaps something completely different.

This belief is based on that the  addr++; works fine with some other
harddisks in my reach (so obviously, adding one isn't always wrong),
and that other people shared my problem as described in a newsgroup,
found at: <http://tinyurl.com/ee7me> which redirects to

<http://groups.google.com/group/linux.debian.user.german/browse_thread/thread/ab8980cb5ea0a9fb/7f475d3ce8f34211?tvc=2&q=linux+hpa+seagate+0x10>

(german-language, but the dmesg-excerpts and patches speak for themselves)
They suggest to comment out the "addr++;" altogether, which I don't think
is good, but at least doesn't hurt, because a too-small value is
ignored anyway lateron in idedisk_check_hpa(), so in worst case
the hpa is disabled only partially (up to one sector).

Please let me know what you think of it.
People on the list: please Cc: avl@logic.at in this thread.
----- End forwarded message -----

Re: possible bug in ide-disk.c (2.6.18.2 but also older)

[Alan]

On Mon, 20 Nov 2006 15:51:48 +0100
Andreas Leitgeb <avl@logic.at> wrote:

> Since I got not even a beep as answer, I'm trying again
> to get this through to someone who cares:

Sounds like the Knoppix kernel is built with GPT partition handling and
your disk has an odd number of sectors ?

> The problem is in  idedisk_read_native_max_address()
> and equivalently in idedisk_read_native_max_address_ext()
> in a line like this (near the end):
>   addr++; /* since the return value is (maxlba - 1), we add 1 */
> 
> I believe that this is wrong, in so far as it is device-specific.

Which part of the standard are you referring to here ?

Alan

Re: possible bug in ide-disk.c (2.6.18.2 but also older)

[Andreas Leitgeb]

On Mon, Nov 20, 2006 at 03:25:05PM +0000, Alan wrote:
> On Mon, 20 Nov 2006 15:51:48 +0100
> Andreas Leitgeb <avl@logic.at> wrote:
> > Since I got not even a beep as answer, I'm trying again
> > to get this through to someone who cares:
> Sounds like the Knoppix kernel is built with GPT partition handling and
> your disk has an odd number of sectors ?

While I used Knoppix to determine the age of the bug, it does also
appear with a plain vanilla 2.6.18.2 kernel from www.kernel.org.
The ChangeLog for 2.6.18.3 also doesn't mention ide-disk.

I must admit, I don't know about GPT.  My system's bios
is old enough to not know about EFI, and the partition-scheme
on that harddisk dates back quite a few years, so it's unlikely
to be anything than the good ol' MBR.

The original reported number of sectors was an even number.
After HPA-correction it was an odd number.  I cannot tell
if the original even number wasn't actually "odd" in the
sense of "strange". It was, at least, plausible in so far
as access to the last sector went ok, whereas access to the
hpa-corrected (with addr++) last sector failed.

> > The problem is in  idedisk_read_native_max_address()
> > and equivalently in idedisk_read_native_max_address_ext()
> > in a line like this (near the end):
> >   addr++; /* since the return value is (maxlba - 1), we add 1 */
> > I believe that this is wrong, in so far as it is device-specific.
> Which part of the standard are you referring to here ?

I must also admit that I do know nothing about drive hardware specs.

All I know is, that the current code works for some(most?) disks,
and triggers turning off dma on some other drives and, that changing 
"addr++;" to "addr+=drive->sect0;"  (or removing the line completely)
solved the problem for my particular drive.

I hope that someone who understands the ide-driver better than I do,
would evaluate my proposed solution, and either confirm the bug,
or say that this affects just a few broken drives, and that these
don't justify any fixing of the driver.

I could live with either, and I'm glad when this issue is at least
taken care of.  If this has been discussed already in the past, then
please give me a pointer, since my googling failed to give me anything
but archives of other people complaining about the same problem.

For the while being, I currently patch out the hpa-detection entirely
before compiling a new kernel for that particular machine, until either
the bug is corrected for me (and others with an equal harddisk), or
until I replace my affected 40GB disk with a newer/larger one for
which the "addr++" then again might happen to be the right thing.

Alternatively, a kernel-option to manually disable hpa-checking
would be a good step to solve the problem even for drives like mine.

Re: possible bug in ide-disk.c (2.6.18.2 but also older)

[Alan]

> While I used Knoppix to determine the age of the bug, it does also
> appear with a plain vanilla 2.6.18.2 kernel from www.kernel.org.
> The ChangeLog for 2.6.18.3 also doesn't mention ide-disk.

The old IDE layer does not currently have a maintainer.
 
> I must admit, I don't know about GPT.  My system's bios
> is old enough to not know about EFI, and the partition-scheme
> on that harddisk dates back quite a few years, so it's unlikely
> to be anything than the good ol' MBR.

The reason I ask is that they put the partition in the last sector which
means a block read of the last sector goes off the end of the disk and
certainly used to be mishandled by the IDE code.

> Alternatively, a kernel-option to manually disable hpa-checking
> would be a good step to solve the problem even for drives like mine.

It's a compile time option. If you don't have GPT partitioning support
then the system ought to behave correctly.

Alan

Re: possible bug in ide-disk.c (2.6.18.2 but also older)

[Andreas Leitgeb]

On Mon, Nov 20, 2006 at 05:28:12PM +0000, Alan wrote:
> > Alternatively, a kernel-option to manually disable hpa-checking
> > would be a good step to solve the problem even for drives like mine.
> It's a compile time option. If you don't have GPT partitioning support
> then the system ought to behave correctly.

To me it now seems that my symptoms have twofold cause:
  -) misinterpretation of that drive's reported number of sectors.
  -) accessing the last reported sector in search for a GPT.

If I turn off GPT, then perhaps the last (non-existent-but-
believed-by-the-kernel-to-exist) sector is likely never ever
accessed, and therefore the dma-switching-off doesn't happen.
(Well, at least not at boot time, but still, if anyone did 
"dd if=/dev/hda ..." without limiting count=...)

Otoh, patching out this "addr++;" leads to the GPT-test to 
access a valid (in HD's view) sector which contains (who knows,
I even might have a GPT without being aware) or doesn't contain
a GPT, but anyway everthing works.

This does make sense to me.
Please let me know if this makes no sense
  to anyone really knowing ide-stuff.

PS: If it weren't that the failure to access that last sector
    caused dma to be turned off, I'd never have noticed anything
    special.

Re: possible bug in ide-disk.c (2.6.18.2 but also older)

[Alan]

On Mon, 20 Nov 2006 18:57:21 +0100
Andreas Leitgeb <avl@logic.at> wrote:
> To me it now seems that my symptoms have twofold cause:
>   -) misinterpretation of that drive's reported number of sectors.

The current code appears correct.

>   -) accessing the last reported sector in search for a GPT.

The partition code triggers a 1K read for the last 512 bytes of the disk.
This breaks.

Re: possible bug in ide-disk.c (2.6.18.2 but also older)

[Andreas Leitgeb]

On Mon, Nov 20, 2006 at 05:28:12PM +0000, Alan wrote:
> The reason I ask is that they put the partition in the last sector which
> means a block read of the last sector goes off the end of the disk and
> certainly used to be mishandled by the IDE code.

After reading it a second time, I'll see if I got it straight now:

.) the kernel always loads even-aligned pairs of sectors.
.) for an odd-sectored disk, this results in the GPT plus the
     following (non-existent) sector being accessed from disk.
.) the old, unmaintained ide-driver generally does not handle
     the odd-size case right, as it misinterprets the harddisks
     error for the second sector (the one after the end) as a
     general error causing dma to be turned off, after some retries.
     It would also do that, if I later accessed the last sector
     (e.g. dd if=/dev/hda ..., or by accessing a file that happens
     to be stored there per filesystem, if at all possible),
     not just during the initial GPT-check.
.) If I remove the "addr++;", then the harddisk is actually
     believed to be 1 sector smaller than it really is, which
     means that it looks like an even-sized disk. This could mean
     that an eventually existing GPT could be missed. What would
     be the "worst-case" consequences?
.) if ((old ide-driver) && (odd # of sectors)) youre_doomed_anyway(); ?

Right so far?

If yes, then wouldn't it be most sane to generally *ignore*
any trailing single sectors, at least as long as we still have
to deal with old ide driver:
    addr = (addr & ~1) + 1;
Since this piece of code is in the old ide-disk.c, it would
become ineffective automatically, once libpata (or what it's
called) is ready to take over.

Thanks for caring.

Re: possible bug in ide-disk.c (2.6.18.2 but also older)

[Alan]

> After reading it a second time, I'll see if I got it straight now:
> 
> .) the kernel always loads even-aligned pairs of sectors.
> .) for an odd-sectored disk, this results in the GPT plus the
>      following (non-existent) sector being accessed from disk.

Yes

> .) the old, unmaintained ide-driver generally does not handle
>      the odd-size case right, as it misinterprets the harddisks
>      error for the second sector (the one after the end) as a
>      general error causing dma to be turned off, after some retries.
>      It would also do that, if I later accessed the last sector
>      (e.g. dd if=/dev/hda ..., or by accessing a file that happens
>      to be stored there per filesystem, if at all possible),
>      not just during the initial GPT-check.

Only ever seen during the partition check

> .) If I remove the "addr++;", then the harddisk is actually
>      believed to be 1 sector smaller than it really is, which
>      means that it looks like an even-sized disk. This could mean
>      that an eventually existing GPT could be missed. What would
>      be the "worst-case" consequences?
> .) if ((old ide-driver) && (odd # of sectors)) youre_doomed_anyway(); ?

Not in any normal situation it appears, just the partition code seems to
trip it up.

Re: possible bug in ide-disk.c (2.6.18.2 but also older)

[Andreas Leitgeb]

On Tue, Nov 21, 2006 at 12:06:14PM +0000, Alan wrote:
> >      It would also do that, if I later accessed the last sector
> >      (e.g. dd if=/dev/hda ..., or by accessing a file that happens
> >      to be stored there per filesystem, if at all possible),
> >      not just during the initial GPT-check.
> Only ever seen during the partition check

Last evening I got my hands back on that machine,
checked the kernel-config, and saw that GPT was 
already *unselected*!
Actually, the whole "Advanced partition..."-bundle
was unchecked.

While I can't tell whether the disk has such a thing,
(The kernel used at partitioning time might have had
GPT enabled. the tool used was either fdisk or cfdisk,
I don't remember exactly, but never use anything else.
It's about 3 years since.)

Turning off GPT in the current kernel obviously
*does not* solve the problem. :-(

Anything else I could do, short of patching ide-disk.c?

Re: possible bug in ide-disk.c (2.6.18.2 but also older)

[Andreas Leitgeb]

On Wed, Nov 22, 2006 at 11:57:35AM +0100, Andreas Leitgeb wrote:
> Last evening I got my hands back on that machine,
> checked the kernel-config, and saw that GPT was 
> already *unselected*!
> Actually, the whole "Advanced partition..."-bundle
> was unchecked.

Meanwhile I also found this bugreport (for ubuntu):
  https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+bug/26119
which has quite a few "me,too"s, most of them referring to the 
same (as mine) Seagate 40GB model ST340823A, some others to a 
seagate 20GB model.
And, they are better than me at collecting relevant facts ;-)

Btw., this excerpt:
  hdc: Host Protected Area detected.
          current capacity is 78165360 sectors (40020 MB)
          native  capacity is 78165361 sectors (40020 MB)
  hdc: Host Protected Area disabled.
  hdc: 78165361 sectors (40020 MB) w/1024KiB Cache, CHS=65535/16/63, UDMA(100)
  hdc: cache flushes not supported

looked the same for me those days,  but when retrying lately
with a yet unpatched 2.6.18.3, it reported the current capacity
as 78165359 (one less!) (but the native capacity still 78165361)

After patching away the "addr++;", the logs now say:
  hda: 78165360 sectors (40020 MB) w/512KiB Cache, CHS=65535/16/63, UDMA(100)
and I really got 78165360 sectors according to /proc/ide/hda/capacity.

PS:
Will this turn out as:
  "drive is broken, no kernel workaround will be done, end this thread"
or is a real solution in any way realistic?

hpa-problem in ide-disk.c - new insights.

[Andreas Leitgeb]

It appears, as if the drive is really approaching breakdown, 
remapping bad sectors and is out of spare sectors. Thus
reducing capacity.   The call to determine the native
sectors seems to still count in those remapped sectors, 
yielding an effectively bogus number.

Perhaps the drive had originally 78165361 sectors, and
(speculating further) the problems only started to show
up, when the "current" sectors dropped down to 78165360,
while the "native" sectors remained at 78165361.

Since I've got no precious data on that disk (anymore),
I'll just watch it, until it suffers the final headcrash.

PS:
It would still be good to be able to turn off hpa-checking
with some module/boot-option to help with any drives that
return effectively wrong "native" capacity (whether they're
actually broken, or might just have a broken firmware).

Re: hpa-problem in ide-disk.c - new insights.

[Alan]

On Mon, 27 Nov 2006 14:09:53 +0100
Andreas Leitgeb <avl@logic.at> wrote:

> It appears, as if the drive is really approaching breakdown, 
> remapping bad sectors and is out of spare sectors. Thus

HPA has nothign to do with sector remapping. HPA simply allows the BIOS
(or disk by jumper option) to hide part of the drive early in boot so
that it doesn't confuse/break old OS/BIOS code, or to use it to hide
things like windows reinstall images.

Alan

Allow turning off hpa-checking.

[Andreas Leitgeb]

On Mon, Nov 27, 2006 at 01:30:44PM +0000, Alan wrote:
> HPA has nothign to do with sector remapping.

What the drive reports as "native" capacity indeed does
*not* take into (negative-)account those sectors, that have
been remapped.   So after real remaining capacity has dropped
below original capacity,  querying the "native" size still
returns the original size, which is no longer physically
backed.

This is, I admit, practically irrelevant, because such 
drives should really be dumped before doing any harm 
to one's precious data, but please read further...

> HPA simply allows the BIOS (or disk by jumper option)
> to hide part of the drive early in boot so that it doesn't
> confuse/break old OS/BIOS code,

This pattern is probably of vanishing importance with modern
BIOS's (caring less and less about too large disks) and old
old OS's (being less and less runnable on modern hardware despite
these kinds of hacks).


> or to use it to hide things like windows reinstall images.

I see it as a rational wish to not interfere with *these*
reserved sectors (e.g. when installing linux parallel to
windows), even for correctly working drives.

I ask for a module/boot-option to allow to skip hpa-checks
generally, or even for specific drives - to be used, if one
needs to be sure that these reserved sectors of a connected
drive are not going to be touched, even when re-partitioning
the disk.   Afterall that's why they are reserved in the
first place.

That said, it's surely good to be able to access them, if one
desires so.

Re: Allow turning off hpa-checking.

[Alan]

> What the drive reports as "native" capacity indeed does
> *not* take into (negative-)account those sectors, that have
> been remapped.   So after real remaining capacity has dropped
> below original capacity,  querying the "native" size still
> returns the original size, which is no longer physically
> backed.

This is incorrect.

> I ask for a module/boot-option to allow to skip hpa-checks
> generally, or even for specific drives - to be used, if one
> needs to be sure that these reserved sectors of a connected
> drive are not going to be touched, even when re-partitioning
> the disk.   Afterall that's why they are reserved in the
> first place.

This is a matter for the partitioning tool. You don't know at boot time
what you wish to do with the HPA so a boot option is inappropriate.

Alan

Re: Allow turning off hpa-checking.

[Andreas Leitgeb]

On Mon, Nov 27, 2006 at 04:33:28PM +0000, Alan wrote:
> > So after real remaining capacity has dropped
> > below original capacity,  querying the "native" size still
> > returns the original size, which is no longer physically
> > backed.
> This is incorrect.

Please, also give some hints, what actually falsifies my 
observation-based speculations. I surely don't insist in them
being accurate, but I try to understand what's really going on.

What else (if not sector remapping) could make the "current"
size gradually smaller between reboots. And why is "native"
size still constant?  And why does now even access to the but-last
native sector fail? The explanation with block-reads no longer
works.

> This is a matter for the partitioning tool. You don't know at boot time
> what you wish to do with the HPA so a boot option is inappropriate.

If I boot linux (e.g. from CD) on some precious windows-machine,
I do know that at boot time. Ditto if I connect a foreign
windows-disk in my machine (ata is afaik not yet hot-pluggable),
I'm also bound to know that at boot time.

There are also user-land tools (using ioctl) to manipulate 
this, in case I change my mind lateron.

How should the partitioning tool know, if I want to ignore the
HPA, or respect it (knowing it contains stuff that I might need in
future).  Does there exist any that asks me?

Re: Allow turning off hpa-checking.

[Alan]

> What else (if not sector remapping) could make the "current"
> size gradually smaller between reboots. And why is "native"
> size still constant?  And why does now even access to the but-last
> native sector fail? The explanation with block-reads no longer
> works.

The presented size of an ATA disk is constant. It keeps additional space
for error blocks. The HPA merely tells the disk to lie about its size.
 
> > This is a matter for the partitioning tool. You don't know at boot time
> > what you wish to do with the HPA so a boot option is inappropriate.
> 
> If I boot linux (e.g. from CD) on some precious windows-machine,
> I do know that at boot time. Ditto if I connect a foreign
> windows-disk in my machine (ata is afaik not yet hot-pluggable),
> I'm also bound to know that at boot time.

Some ATA is hot pluggable. The new libata stuff very much so (although it
at the moment doesn't handle HPA)
 
> There are also user-land tools (using ioctl) to manipulate 
> this, in case I change my mind lateron.
> 
> How should the partitioning tool know, if I want to ignore the
> HPA, or respect it (knowing it contains stuff that I might need in
> future).  Does there exist any that asks me?

I have no idea. If not perhaps one should be written.

Re: Allow turning off hpa-checking.

[Andreas Leitgeb]

On Mon, Nov 27, 2006 at 06:10:33PM +0000, Alan wrote:
> > What else (if not sector remapping) could make the "current"
> > size gradually smaller between reboots. And why is "native"
> > size still constant?  And why does now even access to the but-last
> > native sector fail? The explanation with block-reads no longer
> > works.
> The presented size of an ATA disk is constant. It keeps additional space
> for error blocks. The HPA merely tells the disk to lie about its size.

I was speaking about a disk, whose "additional space" appeared to 
be already exhausted.  After that, it appears as if the native
size remains still constant, and the exceeding damaged sectors are 
auto-"hidden" by the drive by means of HPA.

Still incorrect?

Then I'm also speaking about not-broken disks, where I just want
to be able to tell the driver to believe the drive's "HPA-lie"
for whatever reason :-)

> > How should the partitioning tool know, if I want to ignore the
> > HPA, or respect it (knowing it contains stuff that I might need in
> > future).  Does there exist any that asks me?
> I have no idea. If not perhaps one should be written.
Till that happens ... ;-)

Re: Allow turning off hpa-checking.

[Alan]

> size remains still constant, and the exceeding damaged sectors are 
> auto-"hidden" by the drive by means of HPA.
> 
> Still incorrect?

Still incorrect. HPA has nothing to do with damaged sectors. The damaged
sectors are replaced from a pool of sectors that are reserved for this
purpose.
 
Alan

Re: Allow turning off hpa-checking.

[Andreas Leitgeb]

On Mon, Nov 27, 2006 at 07:59:40PM +0000, Alan wrote:
> > size remains still constant, and the exceeding damaged sectors are 
> > auto-"hidden" by the drive by means of HPA.
> > Still incorrect?
> Still incorrect. HPA has nothing to do with damaged sectors. The damaged
> sectors are replaced from a pool of sectors that are reserved for this
> purpose.

Please re-read my previous mail.   I *explicitly* wrote that
I'm talking about drives, whose "reserved pool of extra/spare
sectors" was already exhausted. 

Considering that: still incorrect?

Re: Allow turning off hpa-checking.

[Tejun Heo]

Andreas Leitgeb wrote:
> On Mon, Nov 27, 2006 at 07:59:40PM +0000, Alan wrote:
>>> size remains still constant, and the exceeding damaged sectors are 
>>> auto-"hidden" by the drive by means of HPA.
>>> Still incorrect?
>> Still incorrect. HPA has nothing to do with damaged sectors. The damaged
>> sectors are replaced from a pool of sectors that are reserved for this
>> purpose.
> 
> Please re-read my previous mail.   I *explicitly* wrote that
> I'm talking about drives, whose "reserved pool of extra/spare
> sectors" was already exhausted. 
> 
> Considering that: still incorrect?

Yeap, if the drive has run out of spare sectors, bad sectors will no 
longer get better after being written to.  The drive will *never* *ever* 
get shorter.

-- 
tejun

Re: Allow turning off hpa-checking.

[Andreas Leitgeb]

It seems I was too eagerly deleting context from my mails.
This made people misunderstand my questions or answer
details that have been clarified in previous mails already.

I did learn quite a lot already about harddisks during this thread.
"Thank you" to Alan.  In particular, about the quantities involved:

                         1                      2
+---------------------------------------------+---+
                                   ^-3
There is
   1) the "native" size of the disk: strictly constant
   2) the spare sectors for remapping bad ones. (not included in 1)
   3) An arbitrary quantity, being what the drive advertises as size.

Bios thinks 3) is the disks total size. So does Linux before the
hpa-check.  During that "hpa-check", Linux queries the quantity "1)",
which is indeed the disks (constant) size. 

There seem to be many (in some way conflicting) uses for "3)":
  - fool the BIOS: because bioses might get upset for too large disks.
  - fool some old OS: because the OS might get upset ---"---
  - reserve some sectors for some non-volatile data hidden to 
      certain systems e.g. for "nanny the user"-purposes.

This thread is (for one part) about another appearant use of "3)",
namely by the drive to tell that "2)" is exhausted, and less than
"1)" sectors are left usable.  So quantity "3)" is set to the number
of actually physically remaining sectors.

This theory is backed by my observation of a nearly-broken disk,
that the quantity "3)" gradually goes down one step after some time.
The first such step was, when I noticed the problem about half a
year ago, and just recently it stepped down by another one.

Linux queries the real size "1)", gets read errors on the last two
sectors and consequencially turns off dma making the machine awfully
slow.  But this is not a kernel's problem, because really the disk
should be replaced (it doesn't contain precious data, so I keep
watching its degrade, till it no longer does anything).

The point I'm really trying to make is, that there should be a
boot option, to disable the query for "1)".  This *must* be a
boot option, because the querying that I want to be able to
prevent happens at boot time.
My broken drive surely doesn't justify the option (or even this
thread), but the third one of the "uses for 3)" mentioned above
does. Once the native size is read, I no longer know how many
sectors were previously "hidden away" by HPA, except by checking
the kernel-log.

While Alan has already said, why he thought that this was the
wrong approach, the reasoning was based on a misunderstanding
of my question, which I here tried to clear up.

Re: Allow turning off hpa-checking.

[Tejun Heo]

Andreas Leitgeb wrote:
[--snip--]
> This theory is backed by my observation of a nearly-broken disk,
> that the quantity "3)" gradually goes down one step after some time.
> The first such step was, when I noticed the problem about half a
> year ago, and just recently it stepped down by another one.

Okay, if that happens on your drive, you gotta burn that foul thing and 
run away as fast/far away as you can.  ;-)

[--snip--]
> The point I'm really trying to make is, that there should be a
> boot option, to disable the query for "1)".  This *must* be a
> boot option, because the querying that I want to be able to
> prevent happens at boot time.
> My broken drive surely doesn't justify the option (or even this
> thread), but the third one of the "uses for 3)" mentioned above
> does. Once the native size is read, I no longer know how many
> sectors were previously "hidden away" by HPA, except by checking
> the kernel-log.
> 
> While Alan has already said, why he thought that this was the
> wrong approach, the reasoning was based on a misunderstanding
> of my question, which I here tried to clear up.

Dunno about IDE layer.  It has been done that way for long time and not 
sure whether adding such option will happen, but for libata, hpa 
handling is still not implemented and it will have to be optional when 
it gets implemented.  So, libata will have such option when it finally 
receives implementation for hpa handling.

-- 
tejun

Re: Allow turning off hpa-checking.

[Andreas Leitgeb]

Just a Thank you & EOThread message :-)

On Tue, Nov 28, 2006 at 09:24:15PM +0900, Tejun Heo wrote:
> Dunno about IDE layer.  It has been done that way for long time and not 
> sure whether adding such option will happen, but for libata, hpa 
> handling is still not implemented ...

I'm now (since 2.6.19) happily using libata instead of ide
on that machine, no longer need to apply extra patches and will
do so until the harddisk finally dies.

> and it will have to be optional when 
> it gets implemented.  So, libata will have such option when it finally 
> receives implementation for hpa handling.

Glad to read that.

Thanks for all the patience with me.