Thinkpad, Thinkpad, Thinkpad

Alan Cox alan at redhat.com
Tue Mar 28 21:29:59 UTC 2006


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





More information about the fedora-devel-list mailing list