Alan Cox wrote:
> Greg Felix wrote:
> > 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).
>
> So your actual problem is nothing to do with the kernel or with the HPA
> behaviour ? Whatever tool you are using for raid set up isn't reading
> and processing the right fields.
If the formula is to fix all the userspace apps to take into account a
potential HPA, then eg. FDISK + SFDISK + Disk Druid et al should also
be fixed. Because if you create a partition spanning your entire
disk, including the HPA area, and your boot files by some coincidence
ends up in the HPA part of the disk, the BIOS won't be able to read
them, and your system will not boot. And if you fix those tools now,
what about users that use older Linux distributions? They'll have a
parade of problems coming to them with their new HPA-enabled disks
because every userspace tool assumes that <BIOS sector count == Linux
sector count>.
> It isnt the kernels fault if you compute from of end of disk rather than
> from end of non reserved area is it ?
I agree that the entire disk should be visible under Linux. But
instead of fixing every userspace app that assumes <BIOS sector count
== Linux sector count> (I'm guessing that's a lot), how about simply
exporting the HPA as /dev/ide/hostX/busY/targetZ/lunA/hpa, next to the
'disc' device ?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
|
|