Created attachment 41327 [details]
The dmesg when black screen

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?

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.

(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

> 
> 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

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.

(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

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.

Low down the priority, since it only exist on Zhangrui's machine here and seems we met more than one issue.

Thanks,
Yuanhan Liu

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.

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

Yuanhan, we can't reproduce this on our current machines. Please feel free to close this or mark dup with bug#35462.

*** This bug has been marked as a duplicate of bug 35462 ***

Since the bug 35462 has be verified, close this one.