Created attachment 114421 [details] dmesg log ==System Environment== -------------------------- HDMI monitor: ASUS PA238Q BIOS: V59 Regression: No. Tried on drm-intel-testing-2015-01-30 and still saw this issue. This might be related with processor and BIOS upgrade, since I tested before and didn't find this issue at that time. Non-working platforms: BSW ==kernel== -------------------------- -testing: drm-intel-testing-2015-03-13 (fails) ==Bug detailed description== ----------------------------- When connected ASUS PA238Q monitor with DP cable and un-plug eDP cable to keep DP to be the only connection, DP screen will be black screen after resuming from S3/S4. ==Reproduce steps== ---------------------------- 1. Connected ASUS PA238Q with DP cable, un-plug eDP cable and boot 2. echo mem > /sys/power/state 3. Resume by pressing power button
exists on drm-intel-testing-2015-03-27
Is this still present on drm-intel-testing-2015-04-10?
Yes this issue is still present on drm-intel-testing-2015-04-10. This time I used Dell U2311Hb DP monitor to workaround bug 90006. After resuming, DP screen is black. I tried to hotplug, power off/on DP monitor, and run "testdisplay -i", but the screen is still black. "testdisplay -a" will make the screen recover. I also tried S3 after X is started, the screen is black too after resuming. I can recover the screen by running 'xrandr --output DP1 --set "Broadcast RGB" Automatic/Full' to switch "Broadcast RGB" property.
I tried eDP + DP connected, S3 works on both console/X mode. Under X mode, I also tried disabling eDP by "xrandr --output eDP1 --off", and DP screen works after system resumes from S3
(In reply to Jeff Zheng from comment #4) > Under X mode, I also tried disabling eDP by "xrandr --output eDP1 --off", > and DP screen works after system resumes from S3 As this works, I'm wondering if we still want to treat this bug (with so special config -- no eDP) as high priority, or even won't fix?
I've tried to reproduce this, but failed; I've tested with eDP, DP, eDP + DP, HDMI->DVI, and eDP + HDMI->DVI. All of these successfully resume *if* they manage to suspend (suspend fails if attempted again right after resume). I'm using BIOS v58 for this though (and another monitor -- if you think that matters I can try to track down the same model); would it be possible for you to test with a downgraded BIOS -- either 56 or 58 should work, though 56 has some performance issues.
You need to have at least BIOS 61.3 and latest stepping
Yes. I used latest stepping. I tried another Dell U2311Hb DP monitor and saw the same issue. You might need to make sure: 1. Only DP connection, I unplugged the eDP cable. 2. Resume after the monitor power led color changes from white to orange. My BIOS version was V59. I have upgraded BIOS to V65, but my DUT is unable to get latest kernel because of local server room clear up. I will test and comment after local server recovers.
Unfortunately with V65 BIOS, system hang during resuming from S3. So V59 BIOS looks to be a better choice.
I've now tested the following setups: * eDP cable disconnected from motherboard Display: 1. Dell U2412M 2. HP ZR24w (both behaved similarly) Bios: v56 Bios: v58 Wakeup source: 1. power button 2. USB 3. rtcwake Environment: 1. X 2. Command line I'll try to install Bios v59 to see if that makes a difference.
I've now tested also with BIOS 59; no different behaviour observed -- I still cannot reproduce this bug. Do I understand correctly that you both tried from command line and X? If so I cannot think of any differences apart from the displays in our setup, and seeing as we both tried two different models (one being the same brand) it seems unlikely to be the cause of this. Your HW is a C0, right?
Once again - you need to have at least BIOS 61.3, or you don't have the right PUNIT FW in BIOS. Testing on anything else is wasting cycles.
I've tested with v61.4 too, without issues. One thing: the bug title mentions S3/S4, but the bug reproduction steps only involves passing "mem" to /sys/power/state, which means only S3 is tested. Is the bug title wrong, or is there a missing step somewhere? Also, I'd still need info on whether you can reproduce this from the command line, or if it's only in X (or, for that matter, vice versa)?
This morning, I tested on another machine, and didn't see this issue. I upgraded to V65 on original machine, but S3 will hang system. So I upgrade my test machine from V59 to V61.3, this issue does not exist. I think we can close this bug.
(In reply to David Weinehall from comment #13) > I've tested with v61.4 too, without issues. > > One thing: the bug title mentions S3/S4, but the bug reproduction steps only > involves passing "mem" to /sys/power/state, which means only S3 is tested. > > Is the bug title wrong, or is there a missing step somewhere? If using V59, both S3 and S4 will cause this issue. > > Also, I'd still need info on whether you can reproduce this from the command > line, or if it's only in X (or, for that matter, vice versa)? If using V59, both X and command line will cause this issue. This is just FYI. with V61.3, I don't see this issue.
closing, since this issue gone with BIOS v61.3.
Closing verified+notourbug.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.