Suspend fails 50% of time on Linux 3.1.1, works on 3.0.4

Question

Hi folks,
I upgraded yesterday from 3.0.4 to 3.1.1 and noticed that suspend wasn't working anymore as it used to. I began to investigate the problem and at it's core I believe that the cause is a buggy BIOS - the lid states are not correctly reported. To be precise, after resume, the lid state is:
$ cat /proc/acpi/button/lid/LID/state
state: closed
which is obviously invalid. The problem is described in detail already in a 2006 bug report on ubuntu bug tracker.
However, to my Toshiba Satellite U300, this didn't pose a big problem, because the Linux 3.0.4 always returned a lid close event, regardless of the lid state. However, in 3.1.1 it seems that a lid close event is not generated if the lid state is already closed. Thus when the lid is closed, no event is generated and the computer does not suspend. But when the lid is opened, a lid open event is generated (note: lid open is never generated when resuming from a suspend!) which corrects the lid state as open!
This means that to suspend the computer, the lid has to be closed every time twice. I know this problem affects other models too.. I seem to have an HP laptop in this household that's showing roughly the same symptoms.. lid needs to be closed twice. It's running Linux Mint though, and I haven't diagnosed the problem at all yet.
Here are the differences between 3.0.4 and 3.1.1 in acpi_listen
linux 3.1.1
$ acpi_listen
(CLOSE LID)
button/lid LID close
(OPEN LID - No lid event!)
battery PNP0C0A:00 00000081 00000001
processor LNXCPU:00 00000081 00000000
processor LNXCPU:01 00000081 00000000
ac_adapter ACPI0003:00 00000080 00000001
battery PNP0C0A:00 00000080 00000001
(CLOSE LID - No lid event, no suspend!)
(OPEN LID)
button/lid LID open
(CLOSE LID)
button/lid LID close
(OPEN LID - No lid event!)
battery PNP0C0A:00 00000081 00000001
processor LNXCPU:00 00000081 00000000
processor LNXCPU:01 00000081 00000000
ac_adapter ACPI0003:00 00000080 00000001
battery PNP0C0A:00 00000080 00000001
linux 3.0.4
$ acpi_listen
(CLOSE LID)
button/lid LID 00000080 00000003
(OPEN LID - No lid event!)
battery BAT1 00000081 00000001
processor CPU0 00000081 00000000
processor CPU1 00000081 00000000
ac_adapter ACAD 00000080 00000001
battery BAT1 00000080 00000001
(CLOSE LID)
button/lid LID 00000080 00000004
(OPEN LID)
battery BAT1 00000081 00000001
processor CPU0 00000081 00000000
processor CPU1 00000081 00000000
ac_adapter ACAD 00000080 00000001
battery BAT1 00000080 00000001
They both repeat the same pattern. Any gurus here got any advices/ways to deal with this situation? I suppose a DSDT fix would be in place.. it would be nice to catch the lid open event too! For now I'll be sticking with 3.0.4 for the sake of convenience.
Last edited by snaip (2011-11-18 09:39:14)

Answer 1

skunktrader wrote:Same problem here https://bbs.archlinux.org/viewtopic.php?id=130372 complete with a workaround
Thanks, but unfortunately not the same problem. In the above url the problem was about laptops suspending upon receiving a "lid open" event. I noticed that (my laptop was suspending when opening the lid..) and corrected it already before posting this thread.
I'll try to clarify, step by step. Here is what happens, from the point when computer is freshly rebooted and turned on.
Action - output of /proc/acpi/button/lid/LID/state - ACPI event generated - Result
1) Close the lid - state: closed - button/lid LID close - computer suspends
2) Open the lid - state: closed - no event - computer resumes, everything works great, but no lid open event.
3) Close the lid - state: closed - no event - Nothing happens
4) Open the lid - state: open - button/lid LID open - Lid open event.. state changes.
5) Close the lid - state: close - button/lid LID close - Computer suspends
6) Move to step 2
The only difference between 3.1.1 and 3.0.4 behaviour is that in 3.0.4 a LID close event is generated in step 3 (and thus the next step is step 2). The proc/acpi/button/lid/LID/state is always "closed". I've been browsing the kernel git, but haven't found at least so far what has caused it.
I'll try to pinpoint the exact version change where the problem occurs.
Last edited by snaip (2011-11-18 11:56:23)