Launchpad has imported 28 comments from the remote bug at https://bugzilla.redhat.com/show_bug.cgi?id=676031.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2011-02-08T16:48:41+00:00 Joseph wrote: 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 (mockbu...@x86-12.phx2.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 Reply at: https://bugs.launchpad.net/ubuntu/+source/upower/+bug/597963/comments/16 ------------------------------------------------------------------------ On 2011-02-08T16:54:15+00:00 Matthew wrote: 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? Reply at: https://bugs.launchpad.net/ubuntu/+source/upower/+bug/597963/comments/17 ------------------------------------------------------------------------ On 2011-02-08T16:58:34+00:00 Matthew wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/upower/+bug/597963/comments/18 ------------------------------------------------------------------------ On 2011-02-08T17:07:14+00:00 Joseph wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/upower/+bug/597963/comments/19 ------------------------------------------------------------------------ On 2011-02-08T17:08:48+00:00 Joseph wrote: 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$ Reply at: https://bugs.launchpad.net/ubuntu/+source/upower/+bug/597963/comments/20 ------------------------------------------------------------------------ On 2011-02-08T17:30:38+00:00 Joseph wrote: FWIW, lid state stays closed across hibernate as well. (In retrospect, this is probably expected, since it doesn't get changed on resume) Reply at: https://bugs.launchpad.net/ubuntu/+source/upower/+bug/597963/comments/21 ------------------------------------------------------------------------ On 2011-02-08T17:31:58+00:00 Joseph wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/upower/+bug/597963/comments/22 ------------------------------------------------------------------------ On 2011-02-08T17:38:11+00:00 Joseph wrote: Added relevant launchpad bug; this may also affect (some?) vaio systems. Reply at: https://bugs.launchpad.net/ubuntu/+source/upower/+bug/597963/comments/23 ------------------------------------------------------------------------ On 2011-02-08T17:45:15+00:00 Matthew wrote: 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? Reply at: https://bugs.launchpad.net/ubuntu/+source/upower/+bug/597963/comments/24 ------------------------------------------------------------------------ On 2011-02-08T17:52:03+00:00 Joseph wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/upower/+bug/597963/comments/25 ------------------------------------------------------------------------ On 2011-02-08T18:15:41+00:00 Joseph wrote: OK; they said the person working on this bug will email you later today. Reply at: https://bugs.launchpad.net/ubuntu/+source/upower/+bug/597963/comments/26 ------------------------------------------------------------------------ On 2011-02-08T18:47:03+00:00 Joseph wrote: 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). Reply at: https://bugs.launchpad.net/ubuntu/+source/upower/+bug/597963/comments/27 ------------------------------------------------------------------------ On 2011-02-08T19:02:23+00:00 Joseph wrote: 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) Reply at: https://bugs.launchpad.net/ubuntu/+source/upower/+bug/597963/comments/28 ------------------------------------------------------------------------ On 2011-02-08T19:03:38+00:00 Joseph wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/upower/+bug/597963/comments/29 ------------------------------------------------------------------------ On 2011-02-08T19:47:03+00:00 Joseph wrote: 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, Reply at: https://bugs.launchpad.net/ubuntu/+source/upower/+bug/597963/comments/30 ------------------------------------------------------------------------ On 2011-02-11T12:17:23+00:00 Joseph wrote: 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. :) Reply at: https://bugs.launchpad.net/ubuntu/+source/upower/+bug/597963/comments/31 ------------------------------------------------------------------------ On 2011-02-20T02:47:48+00:00 Joseph wrote: fwiw, I cannot stop the lid state from being "closed" by rebooting at the moment. Reply at: https://bugs.launchpad.net/ubuntu/+source/upower/+bug/597963/comments/32 ------------------------------------------------------------------------ On 2011-02-20T02:49:08+00:00 Joseph wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/upower/+bug/597963/comments/33 ------------------------------------------------------------------------ On 2011-02-22T20:09:04+00:00 Matthew wrote: 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? Reply at: https://bugs.launchpad.net/ubuntu/+source/upower/+bug/597963/comments/34 ------------------------------------------------------------------------ On 2011-02-22T20:36:50+00:00 Joseph wrote: I'll see if I can get the lid state back to open. Reply at: https://bugs.launchpad.net/ubuntu/+source/upower/+bug/597963/comments/35 ------------------------------------------------------------------------ On 2011-02-23T04:18:51+00:00 Joseph wrote: 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) Reply at: https://bugs.launchpad.net/ubuntu/+source/upower/+bug/597963/comments/36 ------------------------------------------------------------------------ On 2011-02-23T14:25:57+00:00 Matthew wrote: Sorry, you'll need at least a .37 kernel. Any chance you can test with a rawhide live image? Reply at: https://bugs.launchpad.net/ubuntu/+source/upower/+bug/597963/comments/37 ------------------------------------------------------------------------ On 2011-02-24T20:08:51+00:00 Joseph wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/upower/+bug/597963/comments/38 ------------------------------------------------------------------------ On 2011-02-25T01:00:15+00:00 Joseph wrote: I've attached one; the opregions are identical before and after: 653b48084ddf6127e266c65b1aaf5ecc i915_opregion_after.dat 653b48084ddf6127e266c65b1aaf5ecc i915_opregion_before.dat Reply at: https://bugs.launchpad.net/ubuntu/+source/upower/+bug/597963/comments/39 ------------------------------------------------------------------------ On 2011-02-25T01:01:39+00:00 Joseph wrote: Created attachment 480901 opregion data, from today's rawhide image. Reply at: https://bugs.launchpad.net/ubuntu/+source/upower/+bug/597963/comments/40 ------------------------------------------------------------------------ On 2011-02-25T01:02:48+00:00 Joseph wrote: (I also verified that the lid state was open before closing and closed when I opened the lid again) Reply at: https://bugs.launchpad.net/ubuntu/+source/upower/+bug/597963/comments/41 ------------------------------------------------------------------------ On 2011-03-03T03:54:52+00:00 Joseph wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/upower/+bug/597963/comments/42 ------------------------------------------------------------------------ On 2012-08-16T14:43:12+00:00 Fedora wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/upower/+bug/597963/comments/43 ** Changed in: fedora Status: Unknown => Won't Fix ** Changed in: fedora Importance: Unknown => Medium -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/597963 Title: Sony Vaio W laptop lid reports incorrectly To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/upower/+bug/597963/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
