On Tue, Mar 28, 2006 at 02:54:17PM -0500, Peter Jones wrote: > Speaking of which, I've got a patch that duplicates our current startup > breakage in the resume path. Which is to say, since we've already > screwed up the data that's in the protected area, this just disables it > again during resume, so you don't get IO errors. Its not breakage its quite intentional. For 99% of cases HPA is set because it is being used fo BIOS clipping > http://people.redhat.com/pjones/hpa/linux-2.6.16-hpa-resume.patch Looks basically sane. You have to run the ACPI taskfiles from the BIOS first however or you are out of spec and anything can happen (although fortunately it ususally doesnt) Problems in the patch aside from that #1: HPA support and active state are in the identify data so you should consult that (which is boot time cached). #2: You can't assume LBA48 read_native_max_address_ext is supported just because LBA48 is, some maxtors don't. (dont copy the base kernel HPA code that is broken too but fails fairly safe with just message spew) #3: The proper way to decide to issue a set max is to check if the HPA is active but the size check is fine too I think #4: You need to tell the block layer about any size changes. > (obviously, this needs to be done for libata as well) At the moment libata doesn't do HPA. Some ideas have been kicked around for how to handle it neatly but no conclusions AFAIK reached. Lobby Jeff, especially if you have a smart idea. Alan -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
