Thinkpad ACPI woes

Thinkpad ACPI woes

[john maclean]

Hey chaps,

I'm a user and lurking on this list to keep abreast of what you chaps
are upto. Great work and keep it up. However ACPI used to just work on
my IBM Thinkpad x30. I close the lid, open it after some time and I
get X back. Right now it's unpredictable as I never can tell when I'll
get it out of sleep as the screen remains black no matter what keys i
hit. This is with no boot parameters and default "everything" from
distribution maintainers. This is the case ever since the 2.6.25.+
kernel.

Right now uname -r 2.6.25.10-libre.86.fc9.1.i686.

I've seen recommendations
here:-http://www.thinkwiki.org/wiki/Problem_with_display_remaining_black_after_resume.

1) Is anyone else facing this black screen after resume problem? If so
what have you done to correct this?
2) Is this the right location for this message?
3) How much body armour do I need to prepare myself for the barrage of
"GTFO, n00b!"?

-- 
John Maclean - 07739 171 531
MSc (DIC)

Re: Thinkpad ACPI woes

[Andi Kleen]

"john maclean" <jayeola@gmail.com> writes:

> I'm a user and lurking on this list to keep abreast of what you chaps
> are upto. Great work and keep it up. However ACPI used to just work on
> my IBM Thinkpad x30. I close the lid, open it after some time and I
> get X back. Right now it's unpredictable as I never can tell when I'll
> get it out of sleep as the screen remains black no matter what keys i
> hit. This is with no boot parameters and default "everything" from
> distribution maintainers. This is the case ever since the 2.6.25.+
> kernel.
>
> Right now uname -r 2.6.25.10-libre.86.fc9.1.i686.

The usual formal procedure for handling hard "i have no clue what causes it"
regression problem is:

- You make sure you can reproduce the problem reliably
- You verify the variable is really only the kernel and not some
user space update. You can do that by only changing kernels
and verifying the bug was not there with the old kernel, is there again 
with the new kernel (2 reboots)  
- You check it also happens with mainline kernels, not only fedora
- Then you do a git bisect between these two kernel versions. You'll
need to be able to fetch git versions of the kernel and compile
them yourself. Then do man git-bisect and do the bisecting.
[There are various better tutorials on that available if you google for it]
- Then you identify some commit that causes the problem.
- You report that to the author (all people in From/Signed-off-by) and
to linux-kernel.

It's not totally trivial, but also not that difficult, and while
it takes some time it really gives results.

-Andi