Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: From release of kernel 3.15.x up to 3.16.x, screen is blank on resume from suspend. Kernel 3.14.x and earlier worked properly. Version-Release number of selected component (if applicable): xorg-x11-drv-ati-7.2.0-3.20131101git3b38701.fc20.x86_64 How reproducible: Close lid to suspend device. Open lid to resume device. Steps to Reproduce: 1. Close lid on device. Device suspends 2. Open lid on device. Device appears to resume. 3. Hit a key to bring up unlock dialog box Actual results: Screen remains blank. Expected results: Screen would show dialog box to unlock screen Additional info: While screen remains blank, computer is not locked. The only way I can do anything is to work blind. I can hit CTRL-ALT-F2/F3, etc. but I still cannot see anything. Hitting CTRL-ALT-Backspace does nothing. The only way to restore the screen to normal is to switch to a different VT and log in as root blindly, and then execute a reboot. Upon reboot, the screen works normally until I attempt to suspend again. Reverting to kernel 3.14.x restores suspend/resume functionality. Even though I am on Fedora 20, I am currently using kernel-3.14.19-100.fc19.x86_64, as the kernel 3.14 series is no longer available for Fedora 20. /sys/class/backlight yields the following: acpi_video0 radeon_bl0 I have to leave now. I will post more about this when I get back, to include logs. I had previously listed this in bug # 1121838 The logs I intend to post later are included in that report. I am adding a new bug based on advice I received there.
Created attachment 943792 [details] dmidecode file
Created attachment 943793 [details] dmesg file for working system
Created attachment 943794 [details] dmesg file after failure to resume dmesg file after failure to resume was captured by switching to alternate VT and (in the blind) capturing the output of dmesg.
removed external bug tracker since bug cited was internal.
Adding Hans to Cc per bug 1121838 comment 17.
I believe I have the same problem (AO 722). I am using kdm + KDE.
Hi, 3 questions. 1) You mention that: "ls /sys/class/backlight yields the following: acpi_video0 radeon_bl0" With which kernel version is that ? What is the output with other kernel versions ? 2) I notice that you use "radeon.dpm=1" on the kernel commandline, what happens if you remove that ? 3) Can you please try with a 3.17 kernel: http://koji.fedoraproject.org/koji/buildinfo?buildID=587243 Note F-21 kernels are split up, you need all 3 of the kernel, kernel-core and kernel-module packages, then install them with: "rpm -ivh kernel*.rpm" from a dir where you've put all 3 of them. Regards, Hans
kernel-3.14.19-100.fc19.x86_64 is the one I cited in the original post with the "ls /sys/class/backlight" results of "acpi_video0 radeon_bl0" Kernel-3.16.6-200.fc20.x86_64 "ls /sys/class/backlight" results are "radeon_bl0" It looks like the "acpi_video0" is missing and might be what is causing this problem. lsmod | grep acpi yields "acpi_cpufreq" which seems to confirm this. I will have to get back with you on the F-21 3.17 kernel. In the meantime, how do I add the acpi_video0 module to the kernel. insmod acpi_video0 does not work. lsmod | grep radeon yields radeon i2c_algo_bit drm_kms_helper ttm drm i2c_core When I changed "radeon.dpm=1" to "radeon.dpm=0", it made no difference.
(In reply to Stephen Haffly from comment #8) > kernel-3.14.19-100.fc19.x86_64 is the one I cited in the original post with > the "ls /sys/class/backlight" results of "acpi_video0 radeon_bl0" > > Kernel-3.16.6-200.fc20.x86_64 > "ls /sys/class/backlight" results are "radeon_bl0" > > It looks like the "acpi_video0" is missing and might be what is causing this > problem. Ah, good. Can you try booting 3.16.6 with "video.use_native_backlight=0" on the kernel commandline, then do "ls /sys/class/backlight" and see if acpi_video0 is back, and if it is back, see if things work again ? It looks like we may need to add a quirk for your model, can you please also do: sudo dmidecode > dmi.log And attach the generated dmi.log file here ?
(In reply to Michał Goliński from comment #6) > I believe I have the same problem (AO 722). I am using kdm + KDE. Can you also try the debugging steps from comment 9, and can you also please generate a dmi.log and attach it here as described in comment 9.
I've installed the 3.17.1 kernel and I've added the video.use_native_backlight=0 to my command line. After booting I've had two files in /sys/class/backlight, but after "echo mem >/sys/power/state", the screen hasn't come up properly. Only black with very little light seeping through (so the backlight isn't completely turned off, just that there is no image).
Created attachment 950493 [details] dmidecode output (Acer AO 722)
Re: Comment 9 Adding "video.use_native_backlight=0" to the vmlinuz line and booting results in both acpi_video0 and radeon_bl0 being present. I will attach the dmidecode output.
Created attachment 950513 [details] dmi.log file for AO722
First suspend and resume worked. Second has backlight on but blank display. same behavior as before.
(In reply to Michał Goliński from comment #11) > I've installed the 3.17.1 kernel and I've added the > video.use_native_backlight=0 to my command line. > > After booting I've had two files in /sys/class/backlight, but after "echo > mem >/sys/power/state", the screen hasn't come up properly. Only black with > very little light seeping through (so the backlight isn't completely turned > off, just that there is no image). Ok, this "backlight is not completely turned off, just that there is no image" behavior, is this new compared to 3.15 / 3.16 without video.use_native_backlight=0 ? Or do you have the same behavior with 3.15 / 3.16 without video.use_native_backlight=0 ? Also can you please test 3.15.x and 3.16.x with video.use_native_backlight=0 and without radeon.dpm=1, and see if those work any better? As for 3.17 did you try with video.use_native_backlight=0 and without radeon.dpm=1 ?
I'll do some more testing later. As far as I recall the behsaviour was pretty much the same with the previous kernels (3.15, 3.16). I am not quite sure, but with 3.16 I think it someetimes worked properly (albeit I quickly reverted to 3.14 so my memory might be wrong). I thought radeon.dpm=1 is the default for my APU (AMD C-60), only left on the commandline after upgrading from previous versions. Still, I am gonna test.
I've installed 3.16.6 and this is what happened (no radeon.dpm=1, just radeon.use_native_backlight=0 and radeon.audio=1). I've tried first suspending from a text virtual console (Alt+Ctrl+F2). After 'echo mem > /sys/power/state' I was able to resume properly. Twice. Afterwords the screen went black when I tried to switch from the text console to the graphical console (at this point kdm greeting screen). I was still able to suspend my computer blindly from a text console (Alt+Ctrl+F2,Up,Enter), but now it didn't resume properly. I wasn't able to shut it down (shutdown -h now) blindly.
Hi, So we seem to have 2 issues here: 1) Kernel >= 3.15 do not turn on the backlight after suspend / resume, can you confirm that the backlight is really off, when booting without any special options, and that the problem is not a black screen with the backlight being on ? 2) Kernel >= 3.15 do turn on the backlight after suspend / resume when using video.use_native_backlight=0 bit then once every x suspend / resume's the screen is all black (with some backlight bleeding visible. Correct ? Can you try passing video.use_native_backlight=1 to the 3.14 kernel and sees what happens then ? Regards, Hans
I would guess there is only a single problem really, just that if you are trying to switch to a graphical console after resuming, then you are presented with a black screen (text consoles work ok). It doesn't help if you suspend from a text console, resume to a text console and then switch. Still black. Sometimes it is hard to tell whether the backlight is on (as this is a black screen), but it is not the case, that only the backlight is missing. If you turn the backlight off normally (Fn+F6, don't know if this is hardware or software), then in bright ambient light you can still see some details on the screen, e.g. white text fields for password of the screen lock. I've checked with 3.16.6, and after resume there is no image on the screen, but the backlight is working. You can even turn it off and on with the Fn+F6 button or change the brightness. This doesn't depend on use_native_backlight. With 3.14.9 use_native_backlight changes nothing (it works either way). Regards Michał
(In reply to Michał Goliński from comment #20) > I would guess there is only a single problem really, just that if you are > trying to switch to a graphical console after resuming, then you are > presented with a black screen (text consoles work ok). It doesn't help if > you suspend from a text console, resume to a text console and then switch. > Still black. > > Sometimes it is hard to tell whether the backlight is on (as this is a black > screen), but it is not the case, that only the backlight is missing. If you > turn the backlight off normally (Fn+F6, don't know if this is hardware or > software), then in bright ambient light you can still see some details on > the screen, e.g. white text fields for password of the screen lock. > > I've checked with 3.16.6, and after resume there is no image on the screen, > but the backlight is working. You can even turn it off and on with the Fn+F6 > button or change the brightness. This doesn't depend on use_native_backlight. > > With 3.14.9 use_native_backlight changes nothing (it works either way). Ok, so this really seems to be a radeon driver issue then, and this needs one of the radeon devs to look at it. I'm afraid there is nothing more I can to help here. One thing which you could do if you've the time is do a git bisect between kernels 3.14 and 3.15 and try to find out exactly which commit broke things, but that is a lot of work. If you're willing to do this, search the internet for howto-s on kernel bisecting.
I might do that one day. But for bisecting I have one question. I've tried to compile a custom kernel for this netbook a long time ago. But I didn't go through the rpm hassle, just downloaded sources from kernel.org, menuconfigured them, compiled, installed and was greeted with a black screen on entering the graphical login (everything worked up to this point). Is it possible to run a vanilla kernel or do I have to download an SRPM and generate packages?
It should be possible to run a vanilla kernel, tip, start with: cp /boot/config-3.14.x-.. .config make oldconfig So that you've all the right config options set, and then do: make bzImage && make modules && sudo make modules_install && sudo make install The "make install" will automatically generate an initrd and add the proper menu entry stuff to grub, this is what I use to build custom kernels all the time.
For now I have bisected using Fedora kernels. It seems that the last kernel that works is: kernel-3.15.0-0.rc0.git9.1.fc21 and the first that doesn't work is the next one: kernel-3.15.0-0.rc0.git12.1.fc21 Unfortunately there are over 2 thousand commits, bisecting with git will take a while. Is it reasonable to suppose that the needle in the haystack is in the drivers/gpu/drm/radeon directory?
(In reply to Michał Goliński from comment #24) > For now I have bisected using Fedora kernels. > > It seems that the last kernel that works is: > > kernel-3.15.0-0.rc0.git9.1.fc21 > > and the first that doesn't work is the next one: > > kernel-3.15.0-0.rc0.git12.1.fc21 > > Unfortunately there are over 2 thousand commits, bisecting with git will > take a while. > > Is it reasonable to suppose that the needle in the haystack is in the > drivers/gpu/drm/radeon directory? It likely will be, but it could be caused by an acpi change too, so I would just go with the 2000 commits, after 2 cycles you've already brought it down to 500, so trying to be smart won't save you much, and possibly only cause more work in the end. Have you tried the bad commit with video.use_native_backlight=0 ? As that seems to help a bit, it may well still be 2 problems, and we don't want you to be bisecting the wrong one ...
I am able to do a few steps a day, each taking over an hour. It seems it might be futile though, as I've stumbled into a problem with suspend. I've started with kernel-3.15.0-0.rc0.git9.1.fc21, that is commit c9b76548899 (good, vanilla works as supposed to work) and kernel-3.15.0-0.rc0.git9.1.fc21, that is commit 9e897e13bd46 (bad). Unfortunately, even though the bad fedora kernel displays the behaviour I am looking for (black screen on resume), the vanilla kernel does not, as the suspend isn't even working properly. The suspend process (initiated by "echo mem>/sys/power/state" and diplaying a graphical terminal) stops with a text console displaying a few lines, the last of which talks about "no_console_suspend". I am bisecting nevertheless, taking this as a bad commit.
I noticed something interesting. I installed and ran logwatch. When I ran it, I saw this in the logwatch output: --------------------- Kernel Begin ------------------------ WARNING: Kernel Errors Present ACPI Error: Method parse/ex ...: 4 Time(s) ACPI Error: No handler for ...: 4 Time(s) ACPI Error: Region Embedded ...: 4 Time(s) ERROR @wl_notify_scan_ ...: 6 Time(s) ata1: SError: { CommWake 10B8 ...: 4 Time(s) ---------------------- Kernel End ------------------------- Are these ACPI errors pertinent to the problem?
(In reply to Stephen Haffly from comment #27) > I noticed something interesting. I installed and ran logwatch. When I ran > it, I saw this in the logwatch output: > > --------------------- Kernel Begin ------------------------ > > > WARNING: Kernel Errors Present > ACPI Error: Method parse/ex ...: 4 Time(s) > ACPI Error: No handler for ...: 4 Time(s) > ACPI Error: Region Embedded ...: 4 Time(s) > ERROR @wl_notify_scan_ ...: 6 Time(s) > ata1: SError: { CommWake 10B8 ...: 4 Time(s) > > ---------------------- Kernel End ------------------------- > > Are these ACPI errors pertinent to the problem? Maybe. If you want help with (possible) ACPI issues the linux-acpi mailinglist is probably the best place to ask for help.
Additional information: I just tried the Fedora 21 beta using the Xfce Live ISO on a USB stick. I tried successive suspend/resume attempts, and it seemed to work okay. I did not try an extended suspend. However, I do not know if that would make any difference as I then tried to reboot to Fedora 20 with kernel-3.16.6-200.fc20.x86_64. My first suspend/resume resulted in the backlight on but blank screen problem. The difference? I don't know if the difference is in the 3.17 kernel or in that when I booted from the USB stick, my primary drive was not mounted. The partitions on the drive have a /boot partition, and the /, /home, and swap partitions are LUKS encrypted. Would this potentially be a problem with encrypted partitions and not with xorg-x11-drv-ati? If so, why does it work with kernels 3.14.x and earlier but not with 3.15.x and newer?
(In reply to Stephen Haffly from comment #29) > Additional information: > > I just tried the Fedora 21 beta using the Xfce Live ISO on a USB stick. I > tried successive suspend/resume attempts, and it seemed to work okay. I did > not try an extended suspend. However, I do not know if that would make any > difference as I then tried to reboot to Fedora 20 with > kernel-3.16.6-200.fc20.x86_64. My first suspend/resume resulted in the > backlight on but blank screen problem. Interesting, my guess would be that 3.17 fixes things. Can you try to install 3.17 from koji, on your F-20 install: http://koji.fedoraproject.org/koji/buildinfo?buildID=590144 And see if that also fixes things with your F-20 install ?
Kernel 3.17 has the following effects: Using lid switch to suspend: Same behavior as 3.15 and 3.16. Using pm-suspend: Seems to work. I looked at the Common kernel problems page under Suspend/resume problems, and saw the suggestion to try pm-suspend. What is the difference between suspending via lid switch and suspending via pm-suspend? It may be in how the lid switch is handled that is causing this problem to occur.
In addition, when it wakes up from using the lid switch to suspend, there is a very brief flash of text at the top left that disappears too fast for me to read. This happens just before the screen goes blank.
I have been testing now over several suspend/resume cycles. Suspending using pm-suspend works every time for suspend/resume. Suspending using the lid switch fails every time for suspend/resume. Kernel is 3.17.2-200.fc20.x86_64
Hmm, it might be that the lid-switch, which typically is hooked up through the firmware, is causing the firmware to do more things then just send the lid-switch event. Can you try using the suspend option in the gnome system menu (the menu on the right side of the top bar ? Keep the left alt button pressed when the menu is open to change the power off button into a "pause" button, then click the pause button, that will suspend the system using the normal mechanism gnome3 uses on a suspend button press (which the lid switch is).
I'm not using Gnome. I am using Xfce. I tried the menu option for suspend there, and it seemed to work okay. The options there are Logout, Restart, Shut Down, Suspend, and Hibernate. I selected the option to suspend. It does seem that the difference is in how the lid switch is handled. I'm not sure if the Suspend option from the menu is actually hooked to pm-suspend or if it uses systemd's functions.
Hi Stephen, Can you try: "systemctl suspend" That directly calls into systemd, but I'm not sure if systemd is handling the lid-switch directly, that is seen as just a keypress going through Xorg and then XFCE afaik, so I would expect the code path for the menu option and the lid-switch to be mostly the same. But lets try "systemctl suspend" and then see from there. Regards, Hans
The menu option for Xfce worked a couple of times, and then I got the same blank screen. It seems to happen most when I leave the machine for an extended period. After a reboot, I tried "systemctl suspend" and it seemed to work. Sometimes though, what will work once or twice after a reboot will no longer work on subsequent attempts. I will let you know if "systemctl suspend" continues to work after I give it another few cycles. could XScreensaver be playing a part in this?
Using "systemctl suspend" has so far been reliable. I am going to uncomment the entry for handle lid swich in /etc/systemd/logind.conf and set it to suspend and then disable Xfce4-power-manager's handling of the lid switch and see what happens.
Changing /etc/systemctl/logind.conf's entry to suspend and disabling Xfce4-power-manager's options to "nothing" instead of "suspend" has the effect of the lid switch doing nothing. The computer screen appears to blank, but the computer stays on. Changing Xfce4-power-manager's options for lid switch back to "suspend" and leaving the entry in logind.conf as "suspend" allows the computer to suspend, but has the effect of the blank screen on wakeup. Using "systemctl suspend" has so far been the only reliable way to get the computer to suspend and resume with 3.15.x and newer kernels.
(In reply to Stephen Haffly from comment #39) > Changing /etc/systemctl/logind.conf's entry to suspend and disabling > Xfce4-power-manager's options to "nothing" instead of "suspend" has the > effect of the lid switch doing nothing. The computer screen appears to > blank, but the computer stays on. Right, quoting the logind.conf man-page: IdleAction= Configures the action to take when the system is idle. Takes one of "ignore", "poweroff", "reboot", "halt", "kexec", "suspend", "hibernate", "hybrid-sleep", and "lock". Defaults to "ignore". Note that this requires that user sessions correctly report the idle status to the system. The system will execute the action after all sessions report that they are idle, no idle inhibitor lock is active, and subsequently, the time configured with IdleActionSec= (see below) has expired. So the problem is that xfce4 is not reporting itself as idle to logind. which is to be expected, because if it was, then it would likely not be doing its own pm stuff in the first place. Can you try installing acpid, make that listen to the suspend button and make it call systemctl suspend when the button is pressed (and disable xfce-power-manager) ?
I've installed acpid. The example talks about the power switch. How to I make it listen to the suspend button (Fn-F4) and/or the lid switch? I would assume it is to make an entry in /etc/acpi/events, but would it need a corresponding script in /etc/acpi/actions to make it work? I think I could muddle through the event entry, but I don't know about the action script.
(In reply to Stephen Haffly from comment #41) > I've installed acpid. The example talks about the power switch. How to I > make it listen to the suspend button (Fn-F4) and/or the lid switch? I would > assume it is to make an entry in /etc/acpi/events, but would it need a > corresponding script in /etc/acpi/actions to make it work? I think I could > muddle through the event entry, but I don't know about the action script. Hi, I'm afraid I'm not that much of an acpid expert. AFAIK the lid switch handling should be similar to thr powerswitch handling, other then I'm afraid I have to refer you to the documentation.
I uninstalled acpid. Right after installing and typing the note, I was trying to do an update via yum and the machine became totally non-responsive with a blank screen. The only way I could get it back was to force a shutdown via the power button and then boot again. I had a bit of work to fix the update that had been interrupted. Rather than fiddle with something that is working, even if it is not solving the lid switch suspend/resume problem, I will wait and use systemctl suspend for now. We just purchased a house and are trying to get ready to move, so my time to work on this problem will be extremely limited for a while.
I just upgraded the Fedora from 20 to 21 on this machine using FedUP. I don't know what changed, but the suspend and resume via the lid switch seems to be working again. kernel-3.17.6-300.fc21.x86_64 xorg-x11-drv-ati-7.5.0-1.fc21.x86_64 I have supended and resumed twice with the lid switch so far. If the AO1-722 continues to behave properly over the next few suspend/resume cycles, then it might be safe to assume the problem has been fixed. I'll report the results in a day or two, after I have had several more suspend/resume cycles.
I updated my AO-725 from Fedora 19 to 21 and started experiencing similar issues with suspend and hibernate. I've had a few occasions where it will come back from either state, but for the most part, I get a blank screen and have to restart blindly by starting a new session via ctrl+alt+F2. I just did updates yesterday: kernel-3.17.7-300.fc21.x86_64 xorg-x11-drv-ati-7.5.0-1.fc21.x86_64 If I can provide any other information to help with this please let me know.
Upgraded kernel to 3.17.7-300.fc21.x86_64. I decided to try Xfce and Enlightenment again. With both of these, I experienced the blank screen on resume. However, with Mate, I have been able to successfully suspend and resume. What is the difference in suspending via lid switch when done by Mate as opposed to Xfce or Enlightenment? So, at least in some circumstances, this bug still exists and should still be left active.
I can now say with relative certainty that when using Mate, suspend/resume with the lid switch works. Using Xfce and Enlightenment, suspend/resume via the lid switch fails.
Fix that worked for me: Open /etc/UPower/UPower.conf and change IgnoreLid=false to true. Reboot and then check if it worked for you.
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.