[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20061127160144.GB2352@gamma.logic.tuwien.ac.at>
Date: Mon, 27 Nov 2006 17:01:44 +0100
From: Andreas Leitgeb <avl@...ic.at>
To: Alan <alan@...rguk.ukuu.org.uk>
Cc: avl@...ic.at, linux-kernel@...r.kernel.org
Subject: Allow turning off hpa-checking.
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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists