Bug 878720

Summary: Dell Precision 4700 re-suspends after resume from s2ram
Product: [openSUSE] openSUSE 13.1 Reporter: Geoff Kuenning <geoff>
Component: BasesystemAssignee: Kristyna Streitova <kstreitova>
Status: RESOLVED FIXED QA Contact: E-mail List <qa-bugs>
Severity: Normal    
Priority: P5 - None CC: geoff, sbrabec
Version: Final   
Target Milestone: ---   
Hardware: x86-64   
OS: openSUSE 13.1   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---
Attachments: Log file from first suspend/resume
Log file from second suspend/resume

Description Geoff Kuenning 2014-05-19 21:33:47 UTC 
Created attachment 590931 [details]
Log file from first suspend/resume

User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0

Note: this may be related to Bug 639152.

When I suspend my Dell Precision M4700 to RAM by closing the lid and then open the lid again, it resumes just fine.  Then 3 to 10 seconds later it suspends again.  If I then resume by pressing the power button, it comes alive and works perfectly.  It's only a minor nuisance (except when I'm too eager on the power button and initiate shutdown instead!) but it would be nice to see it fixed.

About 1 time in 20 it doesn't happen.

I was able to capture both pm-suspend.log files by copying the first one during the few seconds before the machine re-suspended.  Both are attached.


Reproducible: Always

Steps to Reproduce:
1. Close lid and wait for suspend.
2. Open lid and wait a few seconds.

Actual Results:  
Laptop re-suspends after step 2.

Expected Results:  
After resume, laptop remains powered on.

The ".old" log file is from the first suspend.  Looking at the end of the first log and the beginning of the second, it's not clear *why* the suspend was initiated.  My best guess is that the "lid closed" signal from the first suspend isn't properly cleared, but that's only a guess.

Hmmm...looks like Bugzilla will only allow one attachment.  This is the "old" log file.  I'll try to add the new one in a separate comment.
Comment 1 Geoff Kuenning 2014-05-19 21:34:46 UTC 
Created attachment 590933 [details]
Log file from second suspend/resume
Comment 3 Stanislav Brabec 2015-06-26 12:21:20 UTC 
It looks like that during /usr/lib/pm-utils/sleep.d/50rcnetwork resume quirk, 10 seconds after first resume, the new suspend was initiated.

Maybe both pm-utils and systemd initiated suspend independently.

Could you reproduce in 13.2 or Tumbleweed/Factory?

Do you have suspend package installed?

Will it help if you remove suspend package?

Will it help if you remove both suspend and pm-utils package?
Comment 4 Kristyna Streitova 2015-09-03 15:09:59 UTC 
Geoff, did you have a chance to try Stanislav's suggestions? Thank you.
Comment 5 Kristyna Streitova 2015-09-24 11:23:55 UTC 
Closing as NORESPONSE. Feel free to reopen if you find out something new there.
Comment 6 Geoff Kuenning 2015-11-11 19:44:53 UTC 
Hi,

Sorry for the very slow response.  Removing pm-utils cured the problem.  I didn't realize that pm-utils is an obsolete package.
Comment 7 Stanislav Brabec 2015-11-12 14:02:32 UTC 
pm-utils contained lots of hardware specific hacks and some unique features.

There was a long discussion about it, but it seems that having only one way to suspend (kernel) is the best way to go.