Description of problem: Toshiba laptop P870 resumes from suspend with blank screen. Ctrl-Alt-F2 accesses console. This occurs with suspend triggered by laptop close or by pressing power button. Also, is there any way to use a keystroke instead of the GNOME action of holding down the Alt key with one hand, navigating the mouse with the other hand to the tiny corner icon, and dragging down and clicking the power button? Because that awkward action gives a suspend which succeeds.
acpi_video0 acpi_video1 intel_backlight
grep '.*' /sys/class/dmi/id/*_* 2> /dev/null
/sys/class/dmi/id/chassis_asset_tag:No Asset Tag
/sys/class/dmi/id/chassis_vendor:OEM Chassis Manufacturer
/sys/class/dmi/id/chassis_version:OEM Chassis Version
Please give a link to (or give) explicit instructions for editing the kernel commandline. This process was simple before GRUB2. Now the online docs seem fragmentary and incomplete. Exactly which file should I edit? What changes should one make?
Version-Release number of selected component (if applicable):
How reproducible: 100%
Steps to Reproduce:
1. Boot laptop
2. Close lid or press power button
3. Open lid or press power button again
Actual results: Blank screen
Expected results: Return to existing GNOME session
Same problem here on Lenovo z510 with Fedora 20 3.15.7-200.fc20.x86_64 and Gnome 3.12. First suspend the system closing laptop id or pressing power button, after there's no way to wake up the system that freezes on a blank screen.
Acer Aspire One 722 with Fedora 20 3.15.10-200.fc20.x86_64.
Problem is DE independent. It happens with Xfce, Lxde, and Enlightenment.
Close lid and system suspends.
Open within a short period and screen restores.
Subsequent suspend/resume attempts, especially after several hours has passed inevitably results in a blank screen on resume.
Ctrl-Alt-F2 switches to a new terminal, kill programs on the current virtual console, but but the screen is still blank, so i am typing in the dark. I can log in as root and reboot or poweroff, but I can't get the screen to resume.
Editing /proc/sys/kernel/sysrq to enable full access allows me to use the commands to try to kill the x server. However, it makes no difference. The screen still remains blank. The only thing that will give me a working screen again is to reboot.
I don't believe this is a backlight issue as I see the screen's backlight turn on.
The problem for me cropped up with the 3.15.x kernels. Up through the 3.14.x kernels, suspend and resume worked without issue.
This problem is urgent. I can't just suspend when I need to travel with this netbook. I now have to shut down, which means that it is very disruptive.
I will attach dmidecode information about this system.
Created attachment 930660 [details]
dmidecode file for Acer Aspire One 722
Created attachment 930661 [details]
dmesg capture of system before failure
Created attachment 930662 [details]
dmesg capture during failure
This capture was done typing blind by logging in as root and capturing it.
My system is completely encrypted with LUKS for /, /home, and swap. Only /boot is unencrypted. Does this have anything to do with this problem? Even adding the switch, "resume=/dev/dm-1" or "resume=/dev/sda3" does not help as apparently, now encryption is not activated until after the system needs to access swap. the /dev/dm-1 is not reliable since I noticed that sometimes swapon -s comes up with /dev/dm-0, so I tried the /dev/sda3 instead.
I had tried this as some people indicated that the resume= switch fixes this problem. Unfortunately, it does not seem to do so when encryption is involved.
The question is still, what changed between the 3.14 kernels and the 3.15 kernels that has caused this problem? The subsequent question is, how do I fix this so my system suspends and resumes properly again?
Since I travel with this netbook, I want it to be encrypted, to include swap. It is a prudent precaution since there is greater risk of this netbook being stolen and the information on it is something I don't want identity thieves to get.
There are two other bug reports which are probably the same issue. These could possibly be combined with this one.
In an attempt to see if it was something in the install other than the kernel which might be causing this, I totally wiped and reinstalled Fedora 20 x86_64 mate edition from a drive which had all prior partitions removed.
Again, I chose a similar structure for installation.
Partition 1 is 500 MB /boot
Partition 2 is 21 GB LUKS containing Ext4 filesystem, /
Partition 3 is 4.2 GB LUKS containing Swap
Partition 4 is an Extended Partition
Partition 5 is 93 GB LUKS containing EXT4 filesystem /home
Also, there is a 2 MB BIOSboot that does not show, but which was set up by the installer.
Kernel 3.11.10-301.fc20.x86_64 from this installation:
Suspend works as expected. Resume from suspend occurs without any problems.
Kernel 3.15.10-200.fc20.x86_64 installed by yum update:
Suspend works but resume results in a blank screen.
This reinforces that between the 3.14 and prior series of kernels, things worked and that there has been a major regression with the 3.15 series of kernels that breaks resume from suspend (and presumably, hibernation).
I was just on www.kernel.org and noticed that kernel 3.14.17 is listed as a longterm release. Please make this kernel available for those of us for whom the 3.15 kernels break suspend/resume.
Thanks for taking the time to verify your findings with a fresh install. We appreciate the effort there.
(In reply to Stephen Haffly from comment #9)
> I was just on www.kernel.org and noticed that kernel 3.14.17 is listed as a
> longterm release. Please make this kernel available for those of us for whom
> the 3.15 kernels break suspend/resume.
Our infrastructure isn't setup to offer multiple kernel versions in the updates repo. We also aren't staffed well enough to support mutiple kernel versions per release in parallel. You can, if needs be, install the F19 kernel on F20. The F19 kernel is based on 3.14.y and will remain on that until F19 goes end of life.
Thanks. I am installing it and if it works, will then disable any further kernel updates until this is fixed. I also uninstalled the 3.15 kernel as yum complained otherwise.
What is happening with the kernel to cause this? Is there any way to fix it and still use the 3.15 kernels?
We don't know what is happening. At the moment, we haven't gotten an opportunity to look at it at all. F20 will be rebasing to 3.16.y soon, and that may or may not contain a fix. If not, it would likely be fixed in a 3.16.y kernel if we get around to investigating.
Installing the kernel-3.14.17-100.fc19.x86_64 packages fixed the problem. My system is now suspending and resuming correctly.
I saw on Phoronix that the 3.15 kernels had some changes to make resume faster. Apparently, whatever changes were made introduced this regression. I am not sure how to go about reporting this problem upstream to kernel.org, but I'll see what I can do.
Thanks for your help Josh. I appreciate it.
Has there been any progress in diagnosing this issue and figuring out how to fix it? It is now October. The 3.16.x kernels are now out. They exhibit the same failure on resume as the 3.15.x kernels. Meanwhile, the 3.14.x kernels still work.
This sounds a lot like an xorg-x11-drv-intel bug which I fixed a while back, see bug 1032978 and bug 1103806.
Can you all please run:
rpm -q xorg-x11-drv-intel
And verify that it is at version 2.21.15-7 or newer ?
current version is xorg-x11-drv-intel-2.21.15-7.fc20.x86_64
Since this machine has an AMD C50 processor and AMD graphics, what would an intel driver have to do with it unless the same bug exists in the xorg-x11-drv-ati-184.108.40.206-20131101git3b38701.fc20.x86_64 file that is installed.
(In reply to Stephen Haffly from comment #16)
> current version is xorg-x11-drv-intel-2.21.15-7.fc20.x86_64
> Since this machine has an AMD C50 processor and AMD graphics, what would an
> intel driver have to do with it unless the same bug exists in the
> xorg-x11-drv-ati-220.127.116.11-20131101git3b38701.fc20.x86_64 file that is
Well, that is what you get for lumping your case together with an existing bug even though this is a hardware related issue and you've completely different hardware then the original reporter. Please file a new bug against component kernel for your case, with:
- Acer Aspire One 722 in the summary
- A detailed description explaining what exactly does not work, and when it does not work
- Put me in the CC
- Attach all relevant log files for your machine there
I appreciate the response and the suggestion. What log files are the relevant ones? I don't want to upload useless log files.
(In reply to Stephen Haffly from comment #18)
> I appreciate the response and the suggestion. What log files are the
> relevant ones? I don't want to upload useless log files.
The files you've attached here are a good start, also please do "ls /sys/class/backlight" and give the output of that in the bug description.
Done. the new bug # is 1149233. I have to leave, so I will attach the logs later.
*********** 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 20 kernel bugs.
Fedora 20 has now been rebased to 3.17.2-200.fc20. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.
If you have moved on to Fedora 21, and are still experiencing this issue, please change the version to Fedora 21.
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 over 3 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.