Bug 275651 - Thinkpad Z60m misses first lid close after each suspend
Summary: Thinkpad Z60m misses first lid close after each suspend
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 8
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-09-03 23:55 UTC by Nick Lamb
Modified: 2007-12-20 19:56 UTC (History)
2 users (show)

Fixed In Version: 2.6.23.9-85.fc8
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-12-20 19:56:20 UTC


Attachments (Terms of Use)

Description Nick Lamb 2007-09-03 23:55:26 UTC
Description of problem:

I can boot up the Z60m, suspend to RAM by closing the lid, and it restores
correctly and can be used again when I re-open the lid. However, at this point
the state of the lid is reported incorrectly (as closed), and closing the lid
does not re-suspend the laptop. However, when the lid is re-opened, the state is
updated, and so closing it for an additional time works.


Version-Release number of selected component (if applicable):

kernel-2.6.22.4-65.fc7
and all packages up-to-date as of 2007-09-03

How reproducible:

100% reliable.

Steps to Reproduce:
1. Power on
2. Close lid - suspends correctly
3. Open lid - restores correctly (but lid is reported as closed)
4. Close lid - nothing happens
5. Open lid - nothing happens but now lid is reported as open
6. Close lid - suspends correctly

Actual results:

As described

Expected results:

After step 3, the lid should be reported as 'open'
and consequently step 4 should suspend the laptop.

Comment 1 Nick Lamb 2007-09-18 00:07:03 UTC
Actually further investigation reveals that after suspending and subsequently
restoring

/proc/acpi/button/lid/LID/state
contains the correct value

whereas

hal-get-property  --udi /org/freedesktop/Hal/devices/computer_logicaldev_input_1
--key button.state.value

returns the wrong value until the lid changes state

This suggests two possibilities, a HAL bug of some kind or a failure in the
kernel layer / ACPI driver / hardware to signal this as an event that will cause
HAL to re-evaluate the state of the lid. Someone who knows how these pieces are
supposed to work together could perhaps give some advice on how to pinpoint that?

Comment 2 Christopher Brown 2007-10-01 15:00:06 UTC
Hello,

I'm reviewing this bug as part of the kernel bug triage project, an attempt to
isolate current bugs in the fedora kernel.

http://fedoraproject.org/wiki/KernelBugTriage

I am CC'ing myself to this bug and will try and assist you in resolving it if I can.

You might be interested in the following site which may help resolve this issue
for you:

http://people.freedesktop.org/~hughsient/quirk/

I note your laptop is listed with some quirks available to test - I suggest you
do so and post back with the results of these.

If the problem no longer exists then please close this bug or I'll do so in a
few days if there is no additional information lodged.

Comment 3 Nick Lamb 2007-10-01 16:33:21 UTC
The quirks listed are S3 bios quirks, so they're not relevant to my lid switch.
But in any case yes the Z60m S3 bios quirk is already included in the FDI files
on this machine so I'm using that.

Re-tested with 2.6.22.9-91.fc7

Same phenomenon, the kernel's proc file is updated with the correct lid state
when we come out of sleep, but the HAL is not.

If someone who owns the kernel layer can say categorically that the HAL is
supposed to pick this up then I can give this to the HAL component.



Comment 4 Nick Lamb 2007-11-15 09:04:47 UTC
Still see this problem after upgrading to Fedora 8, updating to reflect that

Now running 2.6.23.1-49.fc8

Comment 5 Ronald Kuetemeier 2007-11-30 19:29:37 UTC
Acer 3610.
Same problem. 
Worked just fine with FC6, so this is actually a regression.
I did this:
 CNT=1;while(true); do  cat /proc/acpi/button/lid/LID0/state >> /tmp/lid.txt;
hal-get-property  --udi /org/freedesktop/Hal/devices/computer_logicaldev_input_1
--key button.state.value >> /tmp/lid.txt ;sleep 1; echo $((CNT++)) >>
/tmp/lid.txt;done
.....
Result, cut for just the interesting part(open lid from _NO_ suspend:
state:      closed
true
15
state:      closed
true
16
state:      open
false
17

Looks like the kernel state is correct. But hal somehow misses out on it.



Comment 6 Chuck Ebbert 2007-11-30 22:52:41 UTC
Probably fixed by commit 23de5d9ef2a4bbc4f733f58311bcb7cf6239c813
"ACPI: button: send initial lid state after add and resume"

Comment 7 Chuck Ebbert 2007-12-01 01:05:25 UTC
In CVS

Comment 8 Ronald Kuetemeier 2007-12-04 15:08:21 UTC
Kernel:
2.6.23.8-63.fc8 

Did _NOT_ fix the problem. 

Change log shows:
- ACPI: suspend/resume fixes 

Don't know if it was supposed to fix it.


Comment 9 Chuck Ebbert 2007-12-04 19:28:07 UTC
Fix is in kernel -77 and up.


Comment 10 Fedora Update System 2007-12-12 20:00:09 UTC
kernel-2.6.23.9-85.fc8 has been pushed to the Fedora 8 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update kernel'

Comment 11 Nick Lamb 2007-12-14 01:21:36 UTC
kernel-2.6.23.9-85.fc8  fixes this issue for me (the original reporter)

Big thumbs up here. Thanks for that.

Comment 12 Fedora Update System 2007-12-20 19:56:10 UTC
kernel-2.6.23.9-85.fc8 has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.