Description of problem: I first installed Fedora on my Lenovo v570 laptop a few days ago. The installed kernel was kernel-3.11.10-301.fc20.x86_64, where suspend worked without issues. I was able to close the laptop to suspend, or to use pm-suspend to suspend and wake up. Suspend no longer seems to work on kernel-3.16.6-200.fc20.x86_64; the power light no longer blinks on suspend, and waking up with machine by opening the laptop or hitting a key does not work. Version-Release number of selected component (if applicable): kernel-3.16.6-200.fc20.x86_64 How reproducible: Every single time using kernel-3.16.6-200.fc20.x86_64 Never using kernel-3.11.10-301.fc20.x86_64 Steps to Reproduce: 1. Boot with kernel kernel-3.16.6-200.fc20.x86_64 2. Close laptop / do sudo pm-suspend 3. Open laptop / hit keys on keyboard Actual results: Display is black (doesn't appear to be on). Cannot open VTs, cannot login to any session or display previously suspended session. Expected results: Screen lights up and allows user to use machine. Additional info:
*** Bug 1154423 has been marked as a duplicate of this bug. ***
Created attachment 948790 [details] dmesg post suspend 3.16.6-200.fc20.x86_64 After I ran: sudo sh -c "sync && echo 1 > /sys/power/pm_trace && pm-suspend" the machine appeared to suspend (screen turned off), although the power light did not begin to blink as it does not the previous kernel. Attached is the dmesg post reboot, where I was unable to find any "hash matches".
Created attachment 948797 [details] dmesg post suspend 3.14.1-200.fc20.x86_64
Created attachment 948798 [details] dmesg post suspend 3.14.9-200.fc20.x86_64
Created attachment 948799 [details] dmesg post suspend 3.15.10-201.fc20.x86_64
I did some additional testing and found that the first kernel update where this appeared was kernel-3.14.1-200.fc20.x86_64. I tested the version prior to this, kernel-3.13.10-200.fc20.x86_64 and it suspends and resumes without issue. I am now running this version instead of kernel-3.16.6-200.fc20.x86_64 (the latest update in F20).
Created attachment 949445 [details] git bisect log I did some more testing, and found that the issue exists on the upstream kernel as well. I did a git bisect encompassing up to Linux v3.18-rc1, and found that the first bad commit upstream. $ git bisect bad d2f7cbe7b26a74dbbbf8f325b2a6fd01bc34032c is the first bad commit commit d2f7cbe7b26a74dbbbf8f325b2a6fd01bc34032c Author: Borislav Petkov <bp> Date: Thu Oct 31 17:25:08 2013 +0100 x86/efi: Runtime services virtual mapping We map the EFI regions needed for runtime services non-contiguously, with preserved alignment on virtual addresses starting from -4G down for a total max space of 64G. This way, we provide for stable runtime services addresses across kernels so that a kexec'd kernel can still use them. Thus, they're mapped in a separate pagetable so that we don't pollute the kernel namespace. Add an efi= kernel command line parameter for passing miscellaneous options and chicken bits from the command line. While at it, add a chicken bit called "efi=old_map" which can be used as a fallback to the old runtime services mapping method in case there's some b0rkage with a particular EFI implementation (haha, it is hard to hold up the sarcasm here...). Also, add the UEFI RT VA space to Documentation/x86/x86_64/mm.txt. Signed-off-by: Borislav Petkov <bp> Signed-off-by: Matt Fleming <matt.fleming> :040000 040000 647ee7417eab7dcfc79010bd1b3c2de4b9e59430 6e200f64984088810515a1b49031c9ebc73ad8a4 M Documentation :040000 040000 2170c13e32f7c055559ba37938301d5e3157e5fb c8f1816f400ef6a8737d1a1c68151c9265395167 M arch :040000 040000 f046d2f3e615015934b00b694e3b56c2990836e4 db19b9d1e4b0c3c00ba81e4b9fc8167289ffe563 M include I couldn't figure out koji-bisect (I tried this first), so I am unable to find the Fedora code where this appeared, although Fedora rebasing could explain this. Please let me know the best way to proceed here.
Quick update. I updated the BIOS of my machine from the previous version, 44CN33WW to the latest one available for my machine: 44CN43WW. The issues with all kernel versions, including the v3.18-rc1 tag have disappeared. The issue also only occurs for EFI boot; prior to upgrading the BIOS, I tried an Ubuntu install with a 3.16 kernel and BIOS boot, and I was able to suspend without incident. If I don't receive a response on this ticket in a day or two, I'll go ahead and report this upstream - I added fedora-kernel-uefi as this team maybe the most interested in this issue. Thanks!
*********** 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.