Red Hat Bugzilla – Bug 972471
Pavilion g4-1260la: Suspend fails, display stays black on resume
Last modified: 2013-10-08 13:13:03 EDT
Created attachment 758855 [details]
Log of last suspend
Description of problem:
On resume after suspend, display stays black, everything else works and I know it because if I left any music playing it will continue to play back on resume, it's just I can't see anything.
There are like 6 bugs similar to this but are as old as Fedora 9 and all are "CLOSED WONTFIX" without any solution.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
2. try to resume, get black screen
3. reboot the system as you can't recover
black screen after resume
Colorful and vibrant colors on my display
This is sad because I installed Fedora 18 (then upgraded to 19) to my GF because "Linux was great, you won't regret" and now she can't adjust brightness neither suspend her laptop.
What worries me is that this bug seems to be present as old as 2009, I don't know if it's even worth the time to report.
It seems there are some quirks for your machine in the quirks db which cannot be run because there is no vbetool. Could you try to install vbetool?
# yum install vbetool
However, the pm-utils is getting deprecated in the latest fedoras. The suspend is handled by systemd. It should work out of the box without the quirks.
In case you are able to correctly suspend / resume without X (i.e. from something previously called runlevel 3), please file a bug on the Xorg driver for you graphic. If it doesn't work correctly even without X, please file a bug on the kernel.
Thanks for your input, it seems vbetool can't be installed anymore via yum.
I'm doing yum upgrade right now and will test and report back as soon as finished.
Upgraded to F19 and did not work, after it I installed vbetool from a F17 rpm and now it not longer warns about vbetool not installed but still resume does not work.
Also I still can't change brightness.
This is probably not pm-utils fault.
We need to find out whether it is kernel fault or Xorg video driver fault (my guess is the latter).
1) Try to suspend from the terminal. Run by root:
# echo mem > /sys/power/state
2) Switch to runlevel 3 (i.e. the mode without X):
# telinit 3
Login as root.
# echo mem > /sys/power/state
If 1) fails and 2) works OK it is very probably the Xorg video driver.
If both fails it is very probably the kernel.
Sorry for slow reply, I've to borrow my GF laptop to test.
I tried both and neither worked out, both fails in the exact same way. I just updated to latest 13-Jun-2013 packages before running the test.
Should I fill a bug against kernel package?. Do you need any log file to debug it?.
Thank you for your help.
(In reply to Vladimir Hidalgo from comment #5)
OK, thanks for info, reassigning to kernel. I think it would be helpful if you could provide the output of the dmesg command after the wrong resume (e.g. grab it through the ssh).
*********** MASS BUG UPDATE **************
We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs.
Fedora 19 has now been rebased to 3.11.1-200.fc19. Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel.
If you experience different issues, please open a new bug report for those.
This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 2 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.