Bug 87911

Summary: [ilk] Xorg blank screen after suspending to ram
Product: Drivers Reporter: Jeff Z (shakuganxxii)
Component: Video(DRI - Intel)Assignee: intel-gfx-bugs (intel-gfx-bugs)
Status: RESOLVED CODE_FIX    
Severity: normal CC: intel-gfx-bugs
Priority: P3    
Hardware: Intel   
OS: Linux   
Kernel Version: 3.17.2 Subsystem:
Regression: No Bisected commit-id:
Attachments: dmesg

Description Jeff Z 2014-11-07 01:17:30 UTC 
I have a 1st Generation Intel HD Graphics.
It is using the i915 driver I believe, but it is compatible with the i965 driver too. I'm just not sure if I have it enabled or not (since X can't tell the difference). 

When I close my laptop lid, I have an ACPI script making it suspend to ram.
Here is the script:

# nano /etc/acpi/actions/lm_lid.sh
if [[ "$3" == "close" ]] 
then 
  sync; echo "mem" > /sys/power/state 
fi

And it works fine. But whenever I awake my laptop (by opening the lid), 
I would not be able to go into xorg.
If I'm already in the GUI, then if I ever get out of it. I can't go back in; it gives me a blank screen.
If I was in the terminal when I suspended, it would give me a blank screen when I try $startx.
I am using DWM as my graphical user interface.
Comment 1 Jani Nikula 2014-11-07 08:40:22 UTC 
Does suspend/resume work all right without closing the lid if you manually echo "mem" > /sys/power/state?

Please attach dmesg with drm.debug=14 module parameter set all the way from boot to suspend and resume.
Comment 2 Jeff Z 2014-11-07 12:46:12 UTC 
Created attachment 156951 [details]
dmesg
Comment 3 Jeff Z 2014-11-07 12:46:50 UTC 
# echo "mem" > /sys/power/state works all right without closing the lid.
I'm not exactly sure how to add module parameters.. ):
I did add drm.debug=14 as a boot parameter, is that fine?
I found this guide and changed my Grub2 menu
https://wiki.archlinux.org/index.php/kernel_parameters
so my boot looked something like this:
linux /boot/vmlinuz-linux root=UUID=978e3e81-.... ro drm.debug=14
Anyways, theres my dmesg
Comment 4 Jani Nikula 2015-01-28 15:22:29 UTC 
Please try a recent kernel and report back.
Comment 5 Jeff Z 2015-01-28 15:30:31 UTC 
Yes, this has been fixed after updating to kernel 3.18.x
Comment 6 Jani Nikula 2015-01-29 08:12:06 UTC 
(In reply to Shana Shakugan from comment #5)
> Yes, this has been fixed after updating to kernel 3.18.x

I can't pinpoint a commit that fixed this, but I'm glad to hear it's working now. Thanks for the report and follow-up.