Bug 32539 - [SNB] Black screen while resume from suspend to mem
[SNB] Black screen while resume from suspend to mem
Status: CLOSED DUPLICATE of bug 35462
Product: DRI
Classification: Unclassified
Component: DRM/Intel
unspecified
Other Linux (All)
: medium normal
Assigned To: Yuanhan Liu
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-12-20 18:41 UTC by Yi Sun
Modified: 2011-11-03 23:11 UTC (History)
6 users (show)

See Also:


Attachments
The dmesg when black screen (122.09 KB, text/plain)
2010-12-20 18:42 UTC, Yi Sun
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Yi Sun 2010-12-20 18:41:15 UTC
Environment:
------------
platform: SurgarBay
kernel:        (drm-intel-next)3b8d8d91d51c7d15cda51052624169edf7b6dbc6

Libdrm:         (master)2.4.23-1-g0184bb1c6d946bcaf198f7680b3405adca676790
Mesa:           (master)c451aade889c3c0733fabab691f2a33643e8a054
Xserver:       (master)xorg-server-1.9.99.901-39-ge7dc253452a1ba64718a08fdc070405b494f53cd
Xf86_video_intel:  (master)2.13.902-4-g6f21405454487adf7623cf22f0fdd9f127099afd


Bug detailed description:
--------------------------
We tested the suspend and resume as following steps:
1,suspend to mem(S3) several times in the text mode.
2,start X and then S3 several times.
Repeat the step 1 and 2, then the black screen issue may occur.
The issue is unstable, and it will occur when when we execute about 20 times S3 usually.
Comment 1 Yi Sun 2010-12-20 18:42:06 UTC
Created attachment 41327 [details]
The dmesg when black screen
Comment 2 Gordon Jin 2010-12-20 18:50:53 UTC
hw info: SNB D2 (id=0x0102, rev 09), CougarPoint B1 (H67 rev 03 -- got from Micheal), desktop.

This doesn't exist in another Sandybridge machine (Huron River SDP with SNB D1 rev 08).

Yi, does this exist with -fixes kernel?
Comment 3 Wang Zhenyu 2010-12-20 19:15:28 UTC
So screen is black in failure, but machine is still active right, I mean you only see graphics problem but whole system resume is fine, right? So you can still be able to grab intel_reg_dump?

Please note which connector you use.
Comment 4 Yuanhan Liu 2010-12-22 02:20:09 UTC
(In reply to comment #3)
> So screen is black in failure, but machine is still active right, I mean you
> only see graphics problem but whole system resume is fine, right? So you can
> still be able to grab intel_reg_dump?

Nope, the system is not back. You can't ssh to login to it. So, would not be able to grab info by intel_reg_dump.

> 
> Please note which connector you use.

HDMI here.


NOTE: the suspend issue is 100% reproduceable on Zhang Rui's snb machine(0x102, rev9), even on an old kernel, like 2.6.35.


BTW, I used Sun Yi's suspend script to do test on my dev machine, can't reproduce this issue.


Thanks.
Yuanhan Liu
Comment 5 Yuanhan Liu 2010-12-23 00:47:23 UTC
> 
> NOTE: the suspend issue is 100% reproduceable on Zhang Rui's snb machine(0x102,
> rev9), even on an old kernel, like 2.6.35.

Update: The suspend issue(can't resume back) happened on Zhang Rui's snb machine is not an i915 issue. Since this issue does exist even though the drm and i915 is not loaded. And Zhang Rui has found something about this, but it is not related to i915 module.

 
Thanks.
Yuanhan Liu
Comment 6 Jesse Barnes 2010-12-23 08:21:36 UTC
Without i915 loaded, nothing will even attempt to save/restore video state (unless you ask ACPI to do it, but that's unreliable), so I don't think we can rule out an i915 problem even if the problem occurs without it.
Comment 7 Yuanhan Liu 2010-12-23 18:05:21 UTC
(In reply to comment #6)
> Without i915 loaded, nothing will even attempt to save/restore video state
> (unless you ask ACPI to do it, but that's unreliable), so I don't think we can
> rule out an i915 problem even if the problem occurs without it.

Hi Jesse,

Nope, without i915 and drm loaded, the system will hang, but not just blank screen. So, from that point, we can sure it's somewhere else but not i915 cause the system hang, right?


> And Zhang Rui has found something about this, but it is
> not related to i915 module.

Sorry, I didn't make it clear. It's a little weird: the system will not hang when pm_trace is enabled. While, it will hang when you disabled the pm_trace, which is the default case.


Jesse, here is the background of this bug(feel free to correct me if I am wrong):

Zhang Rui found his machine can't resume back after suspend, it hangs but not just blank screen, which is 100% reproduceable as I said above.  Zhang Rui did some investigation and found the system hangs when resuming i915 module. Then we tried to reproduce this issue. While, expcept Sun Yi met the suspend issue(no hang, just blank screen) with the steps he described, we can't reproduce the suspend issue(either hang or blank screen).




Thanks.
Yuanhan Liu
Comment 8 Jesse Barnes 2010-12-27 09:24:47 UTC
On Thu, 23 Dec 2010 18:05:22 -0800 (PST)
bugzilla-daemon@freedesktop.org wrote:
> Nope, without i915 and drm loaded, the system will hang, but not just blank
> screen. So, from that point, we can sure it's somewhere else but not i915 cause
> the system hang, right?

Ah yes, if there's a system hang w/o i915 loaded, then it sounds like
there's a problem in another driver or in the system firmware.  Of
course if we can get that fixed, we'll still need to load i915 or the
display probably won't come back. :)

> Zhang Rui found his machine can't resume back after suspend, it hangs but not
> just blank screen, which is 100% reproduceable as I said above.  Zhang Rui did
> some investigation and found the system hangs when resuming i915 module. Then
> we tried to reproduce this issue. While, expcept Sun Yi met the suspend
> issue(no hang, just blank screen) with the steps he described, we can't
> reproduce the suspend issue(either hang or blank screen).

Sounds like we're fighting multiple problems.  If resume hung in i915,
I'd guess something in our mode setting or DRPS code was causing
trouble.  But it sounds like there are more problems than just that on
this system.
Comment 9 Yuanhan Liu 2011-01-05 00:59:40 UTC
Low down the priority, since it only exist on Zhangrui's machine here and seems we met more than one issue.

Thanks,
Yuanhan Liu
Comment 10 mus.svz 2011-02-16 08:02:30 UTC
I have the same problem on my Sandy Bridge machine:

chipset: H67
system architecture: 64-bit
xf86-video-intel: 2.14.0
xserver: 1.9.3.901
mesa: 7.10
libdrm: 2.4.23
kernel: 2.6.37
Linux distribution: ArchLinux
Machine or mobo model: Intel DH67GD / Core i5 2500
Display connector: HDMI/DVI (2 Displays)

Suspending to RAM works fine, but on wake up the displays get no signal I can't even ping the machine.

Please let me know if there's anything I can do to help fixing this.
Comment 11 alanw 2011-03-15 12:42:05 UTC
Same problem here. Complete hang no matter if it is in text-mode or in Xorg.
I have a H67 chipset with a Core i5 2500k CPU.

I tested on Ubuntu Natty Alpha3 (2.6.38-rc7) with updated packages with xorg edgers ppa up to today's git updates. Suspend goes well. I can "wake" up the machine to a point where the cpu cooler gets spinning, but that is all. No log at suspend log about waking up (only of course about going to sleep). System completely hangs. No way to connect with ssh.

Other users from xbmc forums reported this problem as well. On windows the machine wakes up perfectly.

dmesg output:  http://pastebin.com/Lum9CLBW

pm-suspend.log: http://pastebin.com/tPHNrW0L
Comment 12 Gordon Jin 2011-03-23 17:47:58 UTC
Yuanhan, we can't reproduce this on our current machines. Please feel free to close this or mark dup with bug#35462.
Comment 13 Yuanhan Liu 2011-03-23 18:16:38 UTC

*** This bug has been marked as a duplicate of bug 35462 ***
Comment 14 Yi Sun 2011-11-03 23:11:32 UTC
Since the bug 35462 has be verified, close this one.