Bug 163419
Summary: | hard disk host protect area handling | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Parameshwara Bhat <peebhat> |
Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Brian Brock <bbrock> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 5 | CC: | alan, davej, ncunning, pp, wtogami, zing |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i686 | ||
OS: | Linux | ||
URL: | http://bugme.osdl.org/show_bug.cgi?id=6840 | ||
Whiteboard: | |||
Fixed In Version: | fc7 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2007-07-23 23:15:55 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Parameshwara Bhat
2005-07-16 02:46:59 UTC
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. |