Bug 1121838

Summary: Blank Screen on Resume from Suspend via lid close or via power button
Product: [Fedora] Fedora Reporter: Phil V <pv.bugzilla>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: 20CC: gansalmon, hafflys, hdegoede, itamar, jonathan, jpazdziora, kernel-maint, luca.ciavatta, madhu.chinakonda, mchehab
Target Milestone: ---Flags: jforbes: needinfo?
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-12-10 15:01:37 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 Flags
dmidecode file for Acer Aspire One 722
none
dmesg capture of system before failure
none
dmesg capture during failure none

Description Phil V 2014-07-22 03:50:00 UTC
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.  

ls /sys/class/backlight
acpi_video0  acpi_video1  intel_backlight

 grep '.*' /sys/class/dmi/id/*_* 2> /dev/null
/sys/class/dmi/id/bios_date:01/17/2013
/sys/class/dmi/id/bios_vendor:Insyde Corp.
/sys/class/dmi/id/bios_version:6.30
/sys/class/dmi/id/board_asset_tag: 
/sys/class/dmi/id/board_name:Portable PC
/sys/class/dmi/id/board_vendor:TOSHIBA
/sys/class/dmi/id/board_version:MP
/sys/class/dmi/id/chassis_asset_tag:No Asset Tag
/sys/class/dmi/id/chassis_type:10
/sys/class/dmi/id/chassis_vendor:OEM Chassis Manufacturer
/sys/class/dmi/id/chassis_version:OEM Chassis Version
/sys/class/dmi/id/product_name:Satellite P870
/sys/class/dmi/id/product_version:PSPLFU-039011
/sys/class/dmi/id/sys_vendor:TOSHIBA

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


Additional info:

Comment 1 Luca Ciavatta 2014-08-12 04:45:07 UTC
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.

Comment 2 Stephen Haffly 2014-08-25 23:10:03 UTC
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.

Comment 3 Stephen Haffly 2014-08-25 23:12:03 UTC
Created attachment 930660 [details]
dmidecode file for Acer Aspire One 722

Comment 4 Stephen Haffly 2014-08-25 23:15:45 UTC
Created attachment 930661 [details]
dmesg capture of system before failure

Comment 5 Stephen Haffly 2014-08-25 23:17:19 UTC
Created attachment 930662 [details]
dmesg capture during failure

This capture was done typing blind by logging in as root and capturing it.

Comment 6 Stephen Haffly 2014-08-27 14:05:54 UTC
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.

Comment 7 Stephen Haffly 2014-08-27 14:12:37 UTC
There are two other bug reports which are probably the same issue. These could possibly be combined with this one.

https://bugzilla.redhat.com/show_bug.cgi?id=904265
https://bugzilla.redhat.com/show_bug.cgi?id=1105445

Comment 8 Stephen Haffly 2014-08-29 14:38:18 UTC
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.

Results:

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).

Comment 9 Stephen Haffly 2014-08-29 14:42:47 UTC
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.

Comment 10 Josh Boyer 2014-08-29 15:27:16 UTC
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.

Comment 11 Stephen Haffly 2014-08-29 15:53:21 UTC
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?

Comment 12 Josh Boyer 2014-08-29 16:10:02 UTC
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.

Comment 13 Stephen Haffly 2014-08-29 17:56:45 UTC
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.

Comment 14 Stephen Haffly 2014-10-03 01:55:47 UTC
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.

Comment 15 Hans de Goede 2014-10-03 08:37:06 UTC
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 ?

Comment 16 Stephen Haffly 2014-10-03 12:57:29 UTC
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-7.2.0.3-20131101git3b38701.fc20.x86_64 file that is installed.

Comment 17 Hans de Goede 2014-10-03 13:05:30 UTC
(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-7.2.0.3-20131101git3b38701.fc20.x86_64 file that is
> installed.

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

Thanks,

Hans

Comment 18 Stephen Haffly 2014-10-03 13:09:14 UTC
I appreciate the response and the suggestion. What log files are the relevant ones? I don't want to upload useless log files.

Comment 19 Hans de Goede 2014-10-03 13:51:29 UTC
(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.

Comment 20 Stephen Haffly 2014-10-03 14:53:15 UTC
Done. the new bug # is 1149233. I have to leave, so I will attach the logs later.

Comment 21 Justin M. Forbes 2014-11-13 16:02:14 UTC
*********** 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.

Comment 22 Justin M. Forbes 2014-12-10 15:01:37 UTC
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.