Bug 471672 - no suspend on 2nd or subsequent attempts after kernel 2.6.27.4-79 on Toshiba A105
no suspend on 2nd or subsequent attempts after kernel 2.6.27.4-79 on Toshiba ...
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
12
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: John Feeney
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-11-14 17:40 EST by Jeff Guerdat
Modified: 2013-01-10 02:09 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-12-05 02:06:09 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
dmesg from successful suspend/resume (39.96 KB, text/plain)
2008-11-18 10:16 EST, Jeff Guerdat
no flags Details
acpidump output (131.62 KB, text/plain)
2010-06-07 13:05 EDT, Jeff Guerdat
no flags Details

  None (edit)
Description Jeff Guerdat 2008-11-14 17:40:51 EST
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.
Comment 1 Matthew Garrett 2008-11-17 23:40:20 EST
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?
Comment 2 Jeff Guerdat 2008-11-18 09:31:07 EST
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
Comment 3 Matthew Garrett 2008-11-18 09:43:16 EST
Ok. Can you please provide the entire output of dmesg once you've had a suspend/resume?
Comment 4 Jeff Guerdat 2008-11-18 10:16:05 EST
Created attachment 323910 [details]
dmesg from successful suspend/resume

First suspend from a fresh boot.
Comment 5 Bug Zapper 2008-11-26 00:24:24 EST
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
Comment 6 Jeff Guerdat 2009-04-08 16:30:26 EDT
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).
Comment 7 Bug Zapper 2009-11-18 03:52:00 EST
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
Comment 8 Jeff Guerdat 2009-11-18 06:19:36 EST
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.
Comment 9 Matthew Garrett 2010-06-07 12:41:37 EDT
Any chance you can install the pmtools package and attach the output of the acpidump command? This is really quite odd.
Comment 10 Jeff Guerdat 2010-06-07 13:05:32 EDT
Created attachment 421889 [details]
acpidump output

Here's the output requested after installing pmtools.
Comment 11 Jeff Guerdat 2010-06-07 13:12:59 EDT
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...
Comment 12 Matthew Garrett 2010-06-07 13:26:33 EDT
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?
Comment 13 Matthew Garrett 2010-06-07 13:38:26 EDT
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.
Comment 14 Jeff Guerdat 2010-06-07 13:41:14 EDT
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?
Comment 15 Jeff Guerdat 2010-06-08 06:25:29 EDT
Welp, it's broken again.  Anything you want me to try?
Comment 16 Matthew Garrett 2010-06-09 16:44:32 EDT
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?
Comment 17 Jeff Guerdat 2010-06-09 17:13:06 EDT
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
Comment 18 Matthew Garrett 2010-06-09 17:17:28 EDT
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.
Comment 19 Bug Zapper 2010-11-04 07:41:45 EDT
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
Comment 20 Bug Zapper 2010-12-05 02:06:09 EST
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.

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