Bug 1404717
| Summary: | system fails to return from sleep | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Ray Holme <rayholme> | ||||||||
| Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> | ||||||||
| Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
| Severity: | medium | Docs Contact: | |||||||||
| Priority: | unspecified | ||||||||||
| Version: | 24 | CC: | cz172638, gansalmon, ichavero, itamar, johannbg, jonathan, kernel-maint, labbott, lnykryn, madhu.chinakonda, mchehab, msekleta, muadda, ssahani, s, systemd-maint, zbyszek | ||||||||
| Target Milestone: | --- | ||||||||||
| Target Release: | --- | ||||||||||
| Hardware: | x86_64 | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2017-02-10 20:21:27 UTC | Type: | Bug | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
Ray Holme
2016-12-14 13:38:27 UTC
Can you switch to a text console (e.g. ctrl-alt-f5)? Can you attach logs from before the reboot (journalctl -b-1)? Anyway, looks like a driver problem. will look and see for both (ssh a possability I think) 2 sleep cycles and no failures - cause I am ready! :=] trying again ... Created attachment 1232226 [details]
resuts of journalctl -b-1 from system console before a reboot
I hope this helps.
You have some custom scripts installed: Dec 13 13:07:12 rainbow systemd-sleep[5761]: /usr/lib/systemd/system-sleep/sleepWrap: line 13: [: suspend: integer expression expected Dec 13 13:07:12 rainbow systemd-sleep[5761]: /usr/lib/systemd/system-sleep/sleepWrap: line 14: [: missing `]' Dec 13 13:07:12 rainbow systemd-sleep[5761]: /usr/lib/systemd/system-sleep/sleepWrap: line 15: [: missing `]' Dec 13 13:07:12 rainbow systemd-sleep[5761]: Suspending system... Did you try without them? Also: Dec 14 07:59:04 rainbow org.gnome.Shell.desktop[1351]: Window manager warning: Failed to set power save mode for output DVII37: Permission denied Dec 14 07:59:04 rainbow org.gnome.Shell.desktop[1351]: Window manager warning: Failed to set power save mode for output DVII37: Permission denied This looks suspicious. Do you get this error too if the resume is successful? Maybe some selinux issue? Do you have selinux in enforcing mode? egg on face for script, it has been working till this latest release - curious fixed (weird that is worked) As for also, I do not know but will look for another failure to find out. Created attachment 1233160 [details]
another journalctl -b-1
OOPS - adding the attachment lost all my notes here:
Oh well.
This problem started about a week ago when I upgraded from
4.8.10-200 -> 4.8.12-200 (I upgrade weekly)
Before I had occasional problems coming back from sleep but the symptoms were different
Before: the login screen had a dead (old) clock and did nothing
Now: I type in my password while the screen is still powering up
so it is black, but when up I have my standard background and
standard terminal - but nothing works and the terminal is transparent
I see no more problems with my sleepWrap script (which has been running for about 3 months, killing any sshd and vpnc sessions I forgot to shut down - it was working even with the logged errors you saw, but is now silently working)
I also saw no recurrances of the power set failure you saw, but will continue to look for it.
Thanks - let me know if there is anything more I can get you that might help. I know how hard it is to fix a bug that is "sometimes".
Created attachment 1234390 [details]
another journalctl -b-1 (final)
one more journalctl -b-1 running new kernel initramfs-4.8.14-200.fc24.x86_64.img
It took five successful sleeps before this happened again.
It is still there.
I will send no more unless requested.
For the record, I have had "sleep return" issues with this particular system for over a year, through many revisions of Fedora. With this release, the problem happened more often than ever before. Now with vmlinuz-4.8.15-200.fc24.x86_64, I seem to have it less again, but it still happens. I have no way of knowing if this is software (not liking my hardware) or hardware as it comes and goes (sounds like hardware kind of). If there is anything I should look at, please let me know. I have just had my 8the successful sleep return so maybe the updates helped or I got lucky with hardware. At this point, I am just going to treat this as something to live with. Final comment - if this helps. I see the translucent screen as the system goes to sleep. I do not have enough times to be sure, but I think the problem is actually occuring before SLEEP is entered. 100% for sure now. The "translucent" command tool always shows up when I put the machine to sleep BEFORE it actually sleeps. When I come back, X is hung and I must reboot to get it back. Normal sleep gives the same screen I would get if I used screen-saver. problem continues. frequency is about 1 out of 3 times. No particular other notables. Since I have seen no postings here, I am assuming you all think it might be hardware. I have no way to confirm if it is hardware or software. But rebooting is not too painful so I guess that is what it is. This is the same as bug 1380434. Sorry I don't know how to record as a duplicate. But yes this is getting more and more consistent. Now this happens about every 2nd time or more that I put the system to sleep. The only other thing that I can note from the journal is the following occurs a lot. cinnamon-session: Fatal IO error 11 (Resource temporarily unavailable) on X server :0. It is not always cinnamon-session but the remainder of the error is the same message for all sorts of X related daemons. this is the same as bug 1380434. I cannot figure how to mark as a duplicate - sorry. *** This bug has been marked as a duplicate of bug 1380434 *** |