Description of problem: Any attempt to suspend to RAM by closing lid more than one time results in no activity nor log entries. It's as if the lid close action is ignored but hibernate (suspend to disk) works properly. This on a 3 year-old Toshiba A105. Version-Release number of selected component (if applicable): 2.6.27.5-88 and newer How reproducible: 100% Steps to Reproduce: 1.Close lid 2. 3. Actual results: Nothing happens - no disk activity, no apparent activity relative to an attempted suspend at all. Logs don't even show the attempt. Expected results: Suspend to RAM Additional info: I can manually invoke pm-suspend and all works fine. Reverting to 2.6.27.4-79 works fine.
Could you attach the full output of the dmesg command at the point where it's failing? If you run the command lshal -m and open and close the lid, is any output generated?
No dmesg info at all is output on the second attempt. Here's the last snippet of the first suspend - the second attempt adds nothing: 445517057049376293 new 18445517057041376264 attempts 1 firewire_core: created device fw0: GUID 00080da0d12dd4d6, S400 ata1.00: ACPI cmd ef/03:0c:00:00:00:a0 filtered out ata1.00: ACPI cmd ef/03:45:00:00:00:a0 filtered out ata1.00: configured for UDMA/100 sd 0:0:0:0: [sda] 195371568 512-byte hardware sectors (100030 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA pci 0000:00:02.0: PCI INT A -> Link[LNKA] -> GSI 11 (level, low) -> IRQ 11 pci 0000:00:02.0: setting latency timer to 64 PM: Finishing wakeup. Restarting tasks ... done. ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready /dev/vmnet: open called by PID 2162 (vmnet-bridge) /dev/vmnet: hub 0 does not exist, allocating memory. /dev/vmnet: port on hub 0 successfully opened bridge-eth0: is a Wireless Adapter bridge-eth0: up bridge-eth0: attached eth0: no IPv6 routers present The timestamps on /var/log/messages as well as the internal text is unchanged. Here's the output of the "lshal -m" for both the first and second attempt: [root@toshiba ~]# lshal -m Start monitoring devicelist: ------------------------------------------------- 09:09:49.508: computer_logicaldev_input_3 property button.state.value = true 09:09:49.515: computer_logicaldev_input_3 condition ButtonPressed = lid 09:10:04.992: computer_logicaldev_input_3 property button.state.value = false 09:10:04.995: computer_logicaldev_input_3 condition ButtonPressed = lid 09:10:05.011: ieee1394_guid80da0d12dd4d6 removed 09:10:05.014: ieee1394_guid80da0d12dd4d6 added ^C [root@toshiba ~]# lshal -m Start monitoring devicelist: ------------------------------------------------- ^C
Ok. Can you please provide the entire output of dmesg once you've had a suspend/resume?
Created attachment 323910 [details] dmesg from successful suspend/resume First suspend from a fresh boot.
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Same issue with F11 beta - first suspend works fine but additional attempts via closing lid are ignored completely (no messages, no runs, no drips, no errors).
This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '10'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 10's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 10 is 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 please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. 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
Exactly the same issue into F12 now. Rarely, the system will continue to detect the lid closing but 99% of the time nothing happens. I've created an ACPI event and action and tried to echo "closed" to /proc/acpi/button/lid/LID0/state with no success. I've followed the troubleshooting steps I've found on the web (run a command that I can't remember at the moment to monitor the lid state, close the lid, and note that the closure was never detected). The only things that work are all manual steps - use the Gnome power settings to suspend when pressing the power button, use the suspend option from the Gnome shutdown dialog box or run pm-suspend. FWIW, hibernate does the same thing since it's the lid closure that's being missed. The one bright spot was that earlier kernels (or acpid or whatever) in the F12 beta worked. As updates were applied, it stopped working. Since there had been no activity around this for quite some time, I didn't note the point in time where it broke again. All I can say was that it worked when F12 beta was installed and now doesn't.
Any chance you can install the pmtools package and attach the output of the acpidump command? This is really quite odd.
Created attachment 421889 [details] acpidump output Here's the output requested after installing pmtools.
FWIW, this is still occurring in F13. I did an update rather than a fresh install but F12 was fresh. As it turns out, it's as odd as you suggest - it's now, and still, working after a couple of reboots. The only thing that seems to be related is some sort of crash where I force an fsck (forcefsck boot option). While it doesn't always work, once I have a crash that I've forced the fsck on the chances improve that it will suddenly work and remain that way until something happens and it goes away. My thought, although not provable, is that there's something like a config file that has gotten corrupted, a crash and fsck causes the file to be cleared/deleted, and a fresh one is put into place. At the moment, I can't get it to fail. Hopefully, the acpidump will provide a clue. If there's anything else, yell...
Does /proc/acpi/button/lid/LID0/state continue to represent the state of the lid correctly when it's broken, or does it claim that it's always open?
Awesome. The firmware in this system implements its own embedded controller access instead of using the operating system's code for doing so. What I suspect happens is that some minor difference in suspend/resume handling on Linux leaves the DSDT's EC state machine confused and lid events stop being generated, but it's not entirely clear to me how or why.
Reply to comment 12: Difficult to say now that all is working properly - can't force it into bad behavior. Note comment #2 above that shows lshal -m with no output when closing the lid with no sleep action occurring. How would I test this?
Welp, it's broken again. Anything you want me to try?
Ok. Can you try reading /proc/acpi/button/lid/*/state with the lid open and the lid closed while it's in the broken state?
Simple test - during the "sleep 10" I closed the lid. [jguerdat@toshiba Desktop]$ cat /proc/acpi/button/lid/LID0/state ; sleep 10 ; cat /proc/acpi/button/lid/LID0/state state: open state: closed
Well, that's kind of insane. I'll look some more, but I suspect that there's going to be something very subtle involving the embedded controller access functions on this machine.
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is 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 please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. 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
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.