Thinkpad, Thinkpad, Thinkpad

Peter Jones pjones at redhat.com
Tue Mar 28 19:54:17 UTC 2006


On Tue, 2006-03-28 at 05:13 -0500, Alan Cox wrote:
> On Mon, Mar 27, 2006 at 07:09:16PM -0500, Eric S. Raymond wrote:
> > That's wacky.  Doesn't happen on an X40, thank goodness.  Which is interesting,
> > because several of my sources claim the T40 and X40 are electronically 
> > identical, with X40 just being skrunched into a smaller form factor.
> 
> The old IDE layer does not support suspend/resume. The failure in this case
> is just an example of that, in this case cause by corruption of the HPA
> limits

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.

http://people.redhat.com/pjones/hpa/linux-2.6.16-hpa-resume.patch

Also, http://people.redhat.com/pjones/hpa/ is a yum repo with the
2.6.16-1.2080 kernel from cvs rebuilt for i686 with this patch.  I hope
this was a good kernel to test with, or davej will surely come make fun
of me ;)  I haven't tested it yet, but just as soon as I finish this
email I'll try it on my laptop.  I'll put x86_64 packages up when they
finish building.

I've got another patch that's hopefully mostly right and provides full
control of an IDE drive's HPA features via sysfs at:

http://people.redhat.com/pjones/hpa/linux-2.6.16-hpa.patch

The two patches are mutually exclusive.  The biggest issue I have right
now with the second one is that we seem to be caching BIO errors, so if
you enable HPA, do an I/O to the disabled parts of the disk, and then
turn HPA off again, you get errors on further IOs when you try to read
that part of the disk.  What code should I be looking at to figure this
part out?  There may also be a lingering off-by-one bug in the second
patch... it needs some more thorough testing, and I've written a small
test suite, but it's hard to count on the answers when getting bogus IO
errors from the kernel.

(obviously, this needs to be done for libata as well)

-- 
  Peter




More information about the fedora-devel-list mailing list