Bug 275651 - Thinkpad Z60m misses first lid close after each suspend
Thinkpad Z60m misses first lid close after each suspend
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
8
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-09-03 19:55 EDT by Nick Lamb
Modified: 2007-12-20 14:56 EST (History)
2 users (show)

See Also:
Fixed In Version: 2.6.23.9-85.fc8
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-12-20 14:56:20 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Nick Lamb 2007-09-03 19:55:26 EDT
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-17 20:07:03 EDT
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 11:00:06 EDT
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 12:33:21 EDT
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 04:04:47 EST
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 14:29:37 EST
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 17:52:41 EST
Probably fixed by commit 23de5d9ef2a4bbc4f733f58311bcb7cf6239c813
"ACPI: button: send initial lid state after add and resume"
Comment 7 Chuck Ebbert 2007-11-30 20:05:25 EST
In CVS
Comment 8 Ronald Kuetemeier 2007-12-04 10:08:21 EST
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 14:28:07 EST
Fix is in kernel -77 and up.
Comment 10 Fedora Update System 2007-12-12 15:00:09 EST
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-13 20:21:36 EST
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 14:56:10 EST
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.