Bug 676031 - Lid state gets stuck closed. While stuck closed, AC power state changes cause suspend-to-ram
Summary: Lid state gets stuck closed. While stuck closed, AC power state changes caus...
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 14
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: John Feeney
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2011-02-08 16:48 UTC by Joseph Pingenot
Modified: 2013-01-10 08:16 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2012-08-16 14:43:09 UTC
Type: ---

Attachments (Terms of Use)
gzipped Terra HD DSDT, from cat /proc/acpi/dsdt > terra_hd.dsdt (8.88 KB, application/x-gzip)
2011-02-08 16:48 UTC, Joseph Pingenot
no flags Details
opregion data, from today's rawhide image. (1.45 KB, application/x-gzip)
2011-02-25 01:01 UTC, Joseph Pingenot
no flags Details

System ID Private Priority Status Summary Last Updated
Launchpad 597963 0 None None None Never

Description Joseph Pingenot 2011-02-08 16:48:41 UTC
Created attachment 477650 [details]
gzipped Terra HD DSDT, from cat /proc/acpi/dsdt > terra_hd.dsdt

Description of problem:
If the lid state is open (upower -d -> lid-is-closed: no; cat /proc/acpi/button/lic/LID0/state-> state: open), if you close the lid on this ZaReason netbook (Terra HD), the lid state will be reported as closed (lid-is-closed: yes; state: closed) on resume.  Further manual changes in lid state do not seem to fix the acpi lid state.  (On Ubuntu, lid state did not seem to change on reboot; I've not check this on Fedora but I don't expect that it's different).  The state does change back, but I am not certain what causes it.

In addition, when the lid state is stuck closed, changing the AC power state (plugging or unplugging the power cord) causes the machine to suspend to RAM.

Version-Release number of selected component (if applicable):
Linux version (mockbuild.fedoraproject.org) (gcc version 4.5.1 20100924 (Red Hat 4.5.1-4) (GCC) ) #1 SMP Thu Dec 23 16:17:40 UTC 2010

How reproducible:
Get Terra HD and play with the lid

Steps to Reproduce:
1. Get Terra HD from ZaReason
2. Close the lid

Actual results:
3. Watch it not be reported open on resume.

Expected results:
3. Watch it be reported open on resume.

Additional info:
DSDT attached

Comment 1 Matthew Garrett 2011-02-08 16:54:15 UTC
If you don't have gnome-power-manager running, does the state update correctly? ie, is it just that if the machine is suspended when the lid is closed, it believes it's still closed on resume, or is it that if you close the lid and reopen it it doesn't believe it's open?

Comment 2 Matthew Garrett 2011-02-08 16:58:34 UTC
Looks like the lid state doesn't get updated on wake - adding:

                            If (LNotEqual (LSTE, LIDS))
                                Store (LSTE, LIDS)
                                Notify (\_SB.LID0, 0x80)

to the _WAK method should work. But we may be able to work around that by calling _REG on resume.

Comment 3 Joseph Pingenot 2011-02-08 17:07:14 UTC
Just got back from more testing:
1) Lid state was reset to "open" on reboot.  (between Ubuntu running on "my terra hd" and Fedora 14 was a mobo change to fix a buggy/broken mobo, so it's possible that it's another thing that the OOEM silently fixed without telling ZaR)
2) Suspend isn't required; I tested with gnome-power-manager set to blank screen on lid close, and the same issue occurred.

I will test after killing gnome-power-manager.

Comment 4 Joseph Pingenot 2011-02-08 17:08:48 UTC
gnome-power-manager need not be running for the state to get "stuck":
CL/;ruth:~:3$ ps -ef | grep gnome-power-manager
solarion  1961  1817  0 11:01 ?        00:00:00 gnome-power-manager
solarion  2661  2507  0 11:07 pts/1    00:00:00 grep gnome-power-manager
LCL/;ruth:~:4$ kill 1961
LCL/;ruth:~:5$ ps -ef | grep gnome-power-manager
solarion  2670  2507  0 11:07 pts/1    00:00:00 grep gnome-power-manager
LCL/;ruth:~:6$ cat /proc/acpi/button/lid/LID0/state 
state:      closed
LCL/;ruth:~:7$ ps -ef | grep gnome-power-manager
solarion  2674  2507  0 11:08 pts/1    00:00:00 grep gnome-power-manager

Comment 5 Joseph Pingenot 2011-02-08 17:30:38 UTC
FWIW, lid state stays closed across hibernate as well.  (In retrospect, this is probably expected, since it doesn't get changed on resume)

Comment 6 Joseph Pingenot 2011-02-08 17:31:58 UTC
(also, hibernate doesn't shut off when it's done; rather it does a reboot.  I dunno if you want this to be a separate bug.)

After more testing, the suspend-on-unplug/replug issue is not materializing at the moment.  I'm not sure why; I've seen it many times before, recently, using Fedora.

Comment 7 Joseph Pingenot 2011-02-08 17:38:11 UTC
Added relevant launchpad bug; this may also affect (some?) vaio systems.

Comment 8 Matthew Garrett 2011-02-08 17:45:15 UTC
Ok, if it fails even without a suspend in the middle then it's probably unfixable without BIOS modification since we're not getting a notification on lid open. Either that or we're doing something very wrong in terms of our lid handling (which I don't /think/ is the case). Are Zareason in any communication with their BIOS supplier?

Comment 9 Joseph Pingenot 2011-02-08 17:52:03 UTC
They were last I knew; they were able to get a BIOS fix to get suspend-to-RAM working before they released the Terra HD (causing a delay in shipping)  I'll privmsg you on irc to try and get you two connected.  I've emailed them a link to this bug, so hopefully they're already on it.

Comment 10 Joseph Pingenot 2011-02-08 18:15:41 UTC
OK; they said the person working on this bug will email you later today.

Comment 11 Joseph Pingenot 2011-02-08 18:47:03 UTC
I'll also point out that the sensor itself clearly works; when gnome-power-manager was killed, if I closed the screen, it would be turned off when the screen was within epsilon of being closed (1cm or so from bottom of screen edge to top of laptop base).  Since g-p-m was killed, I'm thinking that it was the BIOS receiving the information and turning off the screen.

Also, with g-p-m running and set to turn the screen, the screen gets turned off on close and turned on when opened (but the state is still set to be closed).

Comment 12 Joseph Pingenot 2011-02-08 19:02:23 UTC
Mystery solved:
1) g-p-m doesn't turn the screen off on lid close when lid state is stuck closed.
2) g-p-m doesn't turn the screen on on lid open; rather, it turns the screen on when the trackpad is used (untested: keyboard?)
3) g-p-m may be doing the wrong thing because it turns the screen on when the trackpad is used, despite thinking that the lid is closed!  (is possibly a safe assumption; I need to check if it'd do the same thing when an aux input such as a usb mouse is attached. (this is a bug I should look into elsewhere, though)

Comment 13 Joseph Pingenot 2011-02-08 19:03:38 UTC
Ugh. "Mystery solved" is vague; the mystery in question is why g-p-m was turning the screen back on when the laptop was opened again.  The answer is that it's not; it's turning the screen back on when the trackpad (or other input device?) is used.  Sorry for the confusion.

Comment 14 Joseph Pingenot 2011-02-08 19:47:03 UTC
Update from ZaReason:
>Thanks for the info.  I'm checking it out.  I'll make an account to
>  weigh in soon, until then I thought I'd ping you to let you know that
>  the suspend and hibernate features work in windows, which means the
>  manufacturers see no reason to update the bios, which leaves us with
>  figuring out a solution in linux.  Hope this helps,

Comment 15 Joseph Pingenot 2011-02-11 12:17:23 UTC
Maco (another zareason customer) has sent me the DSDT from the old motherboard.

The DSDTs are the same.  If you wish, I can upload it, but I don't see the point in having two copies. :)

Comment 16 Joseph Pingenot 2011-02-20 02:47:48 UTC
fwiw, I cannot stop the lid state from being "closed" by rebooting at the moment.

Comment 17 Joseph Pingenot 2011-02-20 02:49:08 UTC
The sensor is functioning; the BIOS (or whoever) is shutting off the screen when the lid is closed.  So it's not a sensor fault.

Comment 18 Matthew Garrett 2011-02-22 20:09:04 UTC
After a clean boot (ie, the lid state is open), can you:

mount -t debugfs /sys/kernel/debug /sys/kernel/debug

and then copy /sys/kernel/debug/dri/0/i915_opregion . Close the lid, open the lid (ie, the lid state is now "closed") and then take another copy. Tar those up and attach them to this bug?

Comment 19 Joseph Pingenot 2011-02-22 20:36:50 UTC
I'll see if I can get the lid state back to open.

Comment 20 Joseph Pingenot 2011-02-23 04:18:51 UTC
I've not gotten the state to toggle.  Still, I wanted to poke at it, but there's no /sys/kernel/debug/dri/0/i915_opregion:

[root@ruth 0]# ls
bufs               i915_cur_delayinfo    i915_fbc_status      i915_gem_inactive   i915_inttoext_table   i915_wedged
clients            i915_delayfreq_table  i915_gem_active      i915_gem_interrupt  i915_ringbuffer_data  name
gem_names          i915_drpc_info        i915_gem_fence_regs  i915_gem_request    i915_ringbuffer_info  queues
gem_objects        i915_emon_status      i915_gem_flushing    i915_gem_seqno      i915_rstdby_delays    vm
i915_batchbuffers  i915_error_state      i915_gem_hws         i915_gfxec          i915_sr_status        vma
[root@ruth 0]# pwd

(there's also a /sys/kernel/debug/dri/64, for whatever that's worth)

Comment 21 Matthew Garrett 2011-02-23 14:25:57 UTC
Sorry, you'll need at least a .37 kernel. Any chance you can test with a rawhide live image?

Comment 22 Joseph Pingenot 2011-02-24 20:08:51 UTC
FWIW, I may have found a way to make it un-stuck.  The "closed" state persisted across reboots.  Aside from a number of reboots (accidentally; I was trying to get at the BIOS settings), I closed the lid whilst in the BIOS settings screen.  After booting, the lid state is now open again.

I will test, but it sounds like this theory of yours may well be the right explanation.  I'm downloading the livecd now and will test once that's done.

Comment 23 Joseph Pingenot 2011-02-25 01:00:15 UTC
I've attached one; the opregions are identical before and after:
653b48084ddf6127e266c65b1aaf5ecc  i915_opregion_after.dat
653b48084ddf6127e266c65b1aaf5ecc  i915_opregion_before.dat

Comment 24 Joseph Pingenot 2011-02-25 01:01:39 UTC
Created attachment 480901 [details]
opregion data, from today's rawhide image.

Comment 25 Joseph Pingenot 2011-02-25 01:02:48 UTC
(I also verified that the lid state was open before closing and closed when I opened the lid again)

Comment 26 Joseph Pingenot 2011-03-03 03:54:52 UTC
FWIW, the lid state was again stuck "closed" across reboots.
Booting into the BIOS settings screen was insufficient.
Booting into the BIOS settings screen and then closing and reopening the lid was required.

Comment 27 Fedora End Of Life 2012-08-16 14:43:12 UTC
This message is a notice that Fedora 14 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 14. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained.  At this time, all open bugs with a Fedora 'version'
of '14' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this 
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen 
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we were unable to fix it before Fedora 14 reached end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" (top right of this page) and open it against that 
version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 

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