From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; X11; Linux i686; en) Opera 8.01 Description of problem: The recent kernel releases from fedora fail to handle host protect area of the hard disk as they should. Host protect area is the hidden remaining capacity of the hard disk set by a jumper to overcome BIOS limitations of hard disk sizes. Linux kernel's behaviour with respect to this was set by IDE_DISK_STROKE parameter in kernel configuration. Somewhere along 2.6.X kernels,this parameter became boot time diskwise kernel option. I learned this option also went and kernel handles this intelligently now. ( OR DISK_STROKE became default ).Example is kernel-2.6.11-1.1226_FC4 which handles this well to disable host protect area and restore full capacity. Come later kernels, kernel-2.6.11-1.1369_FC4,kernel-2.6.12-1.1390_FC4, this ability of the kernel is inhibited by Fedora developer's configuration of kernel. Contemporary kernels from other distributions do not exhibit this problem. Though this doen't do any more harm than allowing just BIOS limited size, it cripples kernel's ability of restoring full capacity of hard disk. Also, now I am unable to look into my data partitions beyond 33.8 GB on the hard disk created during kernel-2.6.11-1.1226_FC4. Also I had to install FC afresh on a second hard disk. Version-Release number of selected component (if applicable): kernel-2.6.11-1.1369_FC4, kernel-2.6.12-1.1390_FC4 How reproducible: Always Steps to Reproduce: 1.just boot with mentioned kernels 2. 3. Actual Results: Fc4 not able to boot off this disk with mentioned kernels Size fo the hard disk reported wrongly Expected Results: Kernel should have automatically read the native capacity of the hard disk. Additional info: Output of 2.6.12-1.1390_FC4 kernel Jul 15 06:49:22 sidharth kernel: hdb: max request size: 1024KiB Jul 15 06:49:22 sidharth kernel: hdb: Host Protected Area detected. Jul 15 06:49:22 sidharth kernel: current capacity is 66055248 sectors (33820 MB) Jul 15 06:49:22 sidharth kernel: native capacity is 78165360 sectors (40020 MB) Jul 15 06:49:22 sidharth kernel: hdb: task_no_data_intr: status=0x51 { DriveReady SeekComplete Error } Jul 15 06:49:22 sidharth kernel: hdb: task_no_data_intr: error=0x04 { DriveStatusError } Jul 15 06:49:22 sidharth kernel: ide: failed opcode was: 0xf9 Jul 15 06:49:22 sidharth kernel: hdb: 66055248 sectors (33820 MB) w/2048KiB Cache, CHS=16383/255/63, UDMA(33) Output of kernel 2.6.11-1.1226_FC4 hdb: max request size: 1024KiB Jul 15 08:16:53 sidharth kernel: hdb: Host Protected Area detected. Jul 15 08:16:53 sidharth kernel: current capacity is 66055248 sectors (33820 MB) Jul 15 08:16:53 sidharth kernel: native capacity is 78165360 sectors (40020 MB) Jul 15 08:16:53 sidharth kernel: hdb: Host Protected Area disabled. Jul 15 08:16:53 sidharth kernel: hdb: 78165360 sectors (40020 MB) w/2048KiB Cache, CHS=16383/255/63, UDMA(33) Jul 15 08:16:53 sidharth kernel: hdb: cache flushes supported Jul 15 08:16:53 sidharth kernel: hdb: hdb1 hdb3 < hdb5 hdb6 hdb7 hdb8 >
Also, this choice is historical with redhat, as all kernels from earlier feodra Cores had IDE_DISK_STROKE not set in kernel configuration.This was inconsistent with the minimum requirement claims of P II / III processors, as BIOSes from that era all had this limitation for hard Disk size. Also, this is denying the kernel's potential to users. Allowing this ability in kernel doesn't do any harm to those who do not need it. Parameshwara Bhat, peebhat
That bug should be fixed in the newest FC3/FC4 kernels. We issued a 48bit LBA HPA request for 28bit only aware devices. Please test with a current kernel
As of kernel-2.6.12-1.1398_FC4(Latest) the issue is not resolved. Relevant portion of boot log (dmesg) follows: hda: max request size: 128KiB hda: 16841664 sectors (8622 MB) w/512KiB Cache, CHS=16708/16/63, UDMA(33) hda: cache flushes not supported hda: hda1 hda2 hda3 hdb: max request size: 1024KiB hdb: Host Protected Area detected. current capacity is 66055248 sectors (33820 MB) native capacity is 78165360 sectors (40020 MB) hdb: task_no_data_intr: status=0x51 { DriveReady SeekComplete Error } hdb: task_no_data_intr: error=0x04 { DriveStatusError } ide: failed opcode was: 0xf9 hdb: 66055248 sectors (33820 MB) w/2048KiB Cache, CHS=16383/255/63, UDMA(33) hdb: cache flushes supported hdb: hdb1 hdb3 < hdb5 hdb6 hdb7 hdb8 > Parameshwara Bhat
There's a nasty FC3 <-> FC4 regression too related to host protected areas. IBM thinkpads have a few GB recovery area in the host protected area that FC3 happily ignored. FC4 overrides the BIOS/harddisk and thinks it can use the entire disk. Which means anaconda makes partitions that fill the entire disk. Everything is fine until you come back from suspend -> that part of the disk is unaccessible since the bios has locked it -> your system gets very confused. So there's two scenarios, some people really want to use that space and others absolutely require that the kernel doesn't touch it. Lovely :)
Please file seperate bugs for seperate problems. The HPA/BIOS/anaconda item is unrelated to the bug report. I'd suggest Anaconda is probably the best place to file your bug. Thanks
I talked with Matthew Garrett about the HPA on resume problem. It looks like upstream needs to specifically handle this case. Fortunately it seems Matthew has an afflicted machine
*** Bug 164139 has been marked as a duplicate of this bug. ***
In Fedora-2.6.13-1.1532_FC4 kernel update, the behaviour of the kernel is restored.Kernel automatically disables host protect area.From dmesg: hdb: max request size: 1024KiB hdb: Host Protected Area detected. current capacity is 66055248 sectors (33820 MB) native capacity is 78165360 sectors (40020 MB) hdb: Host Protected Area disabled. hdb: 78165360 sectors (40020 MB) w/2048KiB Cache, CHS=16383/255/63, UDMA(33) hdb: cache flushes supported hdb: hdb1 hdb3 < hdb5 hdb6 hdb7 hdb8 >
2.6.14-1.1637_FC4 has been released as an update for FC4. Please retest with this update, as a large amount of code has been changed in this release, which may have fixed your problem. Thank you.
kernel behaviour wrt HPA has not changed in kernel-2.6.13-1.1532_FC4 from release kernel-2.6.13-1.1532_FC4.But shows something of the behaviour of bugs # 163423, 162347. A few lines of I/O error messages and then goes on. Parameshwara Bhat
Just changing component to kernel, since it's clearly not a 4Suite issue. Does this behavior still occur in FC5?
It was never filed as 4suite issue. It is a kernel issue. For FC5 I haven't tested as yet.As my bandwideth is consumed for April, I do not hink I can test it before that either. Parameshwara bhat
[This comment added as part of a mass-update to all open FC4 kernel bugs] FC4 has now transitioned to the Fedora legacy project, which will continue to release security related updates for the kernel. As this bug is not security related, it is unlikely to be fixed in an update for FC4, and has been migrated to FC5. Please retest with Fedora Core 5. Thank you.
A new kernel update has been released (Version: 2.6.18-1.2200.fc5) based upon a new upstream kernel release. Please retest against this new kernel, as a large number of patches go into each upstream release, possibly including changes that may address this problem. This bug has been placed in NEEDINFO state. Due to the large volume of inactive bugs in bugzilla, if this bug is still in this state in two weeks time, it will be closed. Should this bug still be relevant after this period, the reporter can reopen the bug at any time. Any other users on the Cc: list of this bug can request that the bug be reopened by adding a comment to the bug. In the last few updates, some users upgrading from FC4->FC5 have reported that installing a kernel update has left their systems unbootable. If you have been affected by this problem please check you only have one version of device-mapper & lvm2 installed. See bug 207474 for further details. If this bug is a problem preventing you from installing the release this version is filed against, please see bug 169613. If this bug has been fixed, but you are now experiencing a different problem, please file a separate bug for the new problem. Thank you.
Still no change (well, FC6 not FC5 + 2.6.18 update kernel). Patch for resetting the HPA after resume seemed to be in 2.6.18-rcX-mm for a while, but it got reverted, so it's not there anymore either.
My case was: Have Linux installed on a Thinkpad X31 with funny harddrive that has HPA that can't be removed permanently (it can on several identical machines, just not this one harddrive. I've tried. Several times. ) After powerup machine works fine, kernel disables HPA and the whole harddrive is available. Suspend, resume, and the last 6 GB are gone -> much unhappyness if you have data there. I can imagine use cases that don't depend on a weird harddrive that would show problems ;) I ended up repartitioning so that the last 6GB doesn't get used, ages ago (FC2/FC3-era) Linux didn't see it and that worked just fine. Probably should ask for a non-broken drive without HPA, that would be the easy fix ;)
Marking as WONTFIX, sorry. I'm not sure whether newer releases would have better driver level support for HPA. It might be worth giving them a try.
Actually the switch to libata for PATA in F7 made things work, it honors it by default and can be overridden by a commandline option (would make things work for original submitter) + even the suspend/resume paths probably are fixed -> changing to CURRENTRELEASE ;) Laptop with funny harddrive with impossible-to-remove-HPA is now someone-elses-problem anyway. Woo! An entire 6 GB of extra space on my laptop!
The original bug was against FC5, which we won't (AFAIK) be fixing, so WONTFIX is actually the right closure. Nevertheless, great to hear it's working now.