Sony Vaio W laptop lid reports incorrectly

Created attachment 477650
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 2.6.35.10-74.fc14.i686 (<email address hidden>) (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

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?

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.

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.

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
LCL/;ruth:~:8$

FWIW, lid state stays closed across hibernate as well. (In retrospect, this is probably expected, since it doesn't get changed on resume)

(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.

Added relevant launchpad bug; this may also affect (some?) vaio systems.

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?

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.

OK; they said the person working on this bug will email you later today.

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).

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)

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.

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,

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. :)

fwiw, I cannot stop the lid state from being "closed" by rebooting at the moment.

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.

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?

I'll see if I can get the lid state back to open.

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
/sys/kernel/debug/dri/0

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

Sorry, you'll need at least a .37 kernel. Any chance you can test with a rawhide live image?

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.

I've attached one; the opregions are identical before and after:
653b48084ddf6127e266c65b1aaf5ecc i915_opregion_after.dat
653b48084ddf6127e266c65b1aaf5ecc i915_opregion_before.dat

Created attachment 480901
opregion data, from today's rawhide image.

(I also verified that the lid state was open before closing and closed when I opened the lid again)

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.

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:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping