Bug 340884

Summary: s2ram on lid close only every second time
Product: [openSUSE] openSUSE 10.3 Reporter: Christian Trippe <ctrippe>
Component: KernelAssignee: Thomas Renninger <trenn>
Status: RESOLVED WONTFIX QA Contact: E-mail List <qa-bugs>
Severity: Normal    
Priority: P5 - None CC: trenn
Version: Final   
Target Milestone: ---   
Hardware: i686   
OS: openSUSE 10.3   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description Christian Trippe 2007-11-10 18:49:47 UTC
I have a Samsung P35 and use KDE. I have kpowersave configured to do s2ram on lid-close. After a fresh boot it works for the first lid-close. After this sucessful suspend it only works on every second lid-close. Even the screen is not locked when the laptop does not suspend, which should be the case. After sucessful suspend the screen is locked.

The fix for bug 326814 does not work for me. I am using 2.6.22.12-0.1-default.

The difference in my case to bug 326814 I see, is that my laptop does not resume on lid-open, but I have to press the power-button.
Comment 1 Pavel Machek 2007-11-15 17:41:35 UTC
I'm not sure if this is a kernel problem. Can you do

root@amd:~# cat /proc/acpi/event 
ibm/hotkey HKEY 00000080 00005001
button/lid LID 00000080 00000001
ibm/hotkey HKEY 00000080 00005002
button/lid LID 00000080 00000002

(you'll need to kill acpid or something), verify it works for you, then suspend/resume and see how it interacts? Also verify:

root@amd:~# cat /proc/acpi/button/lid/LID/*
type:                    Lid Switch
state:      open

Comment 2 Christian Trippe 2007-11-15 18:37:06 UTC
After stopping acpid 

"cat /proc/acpi/event"

returns nothing.

The other thing you asked for is true:

cat /proc/acpi/button/lid/LID0/*
type:                    Lid Switch
state:      open

Doing the suspend/resume.
The value of "cat /proc/acpi/button/lid/LID0/*" does not change.

cat /proc/acpi/event
button/lid LID0 00000080 00000003
processor CPU0 00000081 00000000
processor CPU0 00000081 00000000
processor CPU0 00000081 00000000
processor CPU0 00000081 00000000
processor CPU0 00000081 00000000
processor CPU0 00000081 00000000
processor CPU0 00000081 00000000
processor CPU0 00000081 00000000
processor CPU0 00000081 00000000
processor CPU0 00000081 00000000
processor CPU0 00000081 00000000
processor CPU0 00000081 00000000
processor CPU0 00000081 00000000
processor CPU0 00000081 00000000
processor CPU0 00000081 00000000
processor CPU0 00000081 00000000
processor CPU0 00000081 00000000
processor CPU0 00000081 00000000
processor CPU0 00000081 00000000
processor CPU0 00000081 00000000
processor CPU0 00000081 00000000
processor CPU0 00000081 00000000
processor CPU0 00000081 00000000
processor CPU0 00000081 00000000
processor CPU0 00000081 00000000
processor CPU0 00000081 00000000
processor CPU0 00000081 00000000
processor CPU0 00000081 00000000
processor CPU0 00000081 00000000
processor CPU0 00000081 00000000
processor CPU0 00000081 00000000
processor CPU0 00000081 00000000
processor CPU0 00000081 00000000
processor CPU0 00000081 00000000
processor CPU0 00000081 00000000
processor CPU0 00000081 00000000
processor CPU0 00000081 00000000
processor CPU0 00000081 00000000


Doing another lid-close where it does not suspend

button/lid LID0 00000080 00000001
button/lid LID0 00000080 00000002

is added to the output of /proc/acpi/event

Comment 4 Thomas Renninger 2008-01-04 10:15:41 UTC
Does this still happen with latest 10.3 update kernel?
If yes, pls carefully check:
 - Do acpi events for LID closing AND opening happen, this should look like:
   button/lid LID0 00000080 0000000X
   every time the LID is opened or closed.
   Can you verify that those events still show up after a suspend (better check
   some more events than one...).

 - Is the LID open/close status correct
   After suspending, check for:
   cat /proc/acpi/button/lid/LID0/*
   Is the status correct? Open and close the Lid some times and recheck, do you
   get into a state where it is not correct?
Comment 5 Christian Trippe 2008-01-04 10:45:26 UTC
It still happens with the latest kernel:

uname -r
2.6.22.13-0.3-default

After a fresh boot I have:

cat /proc/acpi/button/lid/LID0/*
type:                    Lid Switch
state:      open

This result is always the same.

1.)Doing the first lid close the notebook does s2ram. After opening the lid and pressing the power-button it resumes. Output of acpi_listen:

button/lid LID0 00000080 00000001

The result of "cat /proc/acpi/button/lid/LID0/*" stays the same as above.

2.)The next lid close does not s2ram. Opening the LID again the sessions is not even locked. Output of acpi_listen:

button/lid LID0 00000080 00000001
button/lid LID0 00000080 00000002

"cat /proc/acpi/button/lid/LID0/*" gives the same as above.

3.)The next lid close the notebook does s2ram. After opening the lid and pressing the power-button it resumes. Output of acpi_listen:

button/lid LID0 00000080 00000003

"cat /proc/acpi/button/lid/LID0/*" gives the same as above.

From now on 2.) and 3.) are repeated.


Comment 6 Thomas Renninger 2008-01-04 13:58:39 UTC
Can you try one of these kernels, pls:
ftp.suse.com/pub/people/trenn/s2ram_lid_issue
Comment 7 Christian Trippe 2008-01-05 18:23:13 UTC
(In reply to comment #6 from Thomas Renninger)
> Can you try one of these kernels, pls:
> ftp.suse.com/pub/people/trenn/s2ram_lid_issue
> 
I installed kernel-default-2.6.22.15-0.3.i586.rpm.

The behaviour is changed but worse as a lid-close does now never result in s2ram.

The output of 

cat /proc/acpi/button/lid/LID0/*
type:                    Lid Switch
state:      open

is always the same.

acpi_listen gives 

button/lid LID0 00000080 00000002
button/lid LID0 00000080 00000003

for the first lid-close/lid-open after a fresh boot the second gives

button/lid LID0 00000080 00000004
button/lid LID0 00000080 00000005

and so on.

Comment 8 Thomas Renninger 2008-02-06 18:33:18 UTC
> The behaviour is changed but worse as a lid-close does now never result in
> s2ram.
Ok, we should better move this on to 11.0.
I don't want to take the risk to break other machines.
Please try the next 11.0 Alpha/Beta release.
If you still have problems there, we still have enough time to fix it and sent patches upstream for broad testing.
You may then want to reopen the bug instead of creating a new one and adjust the product from 10.3 to 11.0
Comment 9 Christian Trippe 2008-02-12 19:59:22 UTC
Hello Thomas,

I did what you suggested and installed 11.0 Alpha2. There it works fine. The machine suspends with every lid-close.

I do not know if should move the bug to 11.0 and close it as fixed?

Thanks again for your help.
Christian
Comment 10 Thomas Renninger 2008-02-13 11:35:58 UTC
No, better let it as it is.
People also running into this have a reference with this bug report now.
Thanks for trying out.