|Summary:||[piketon] system hang after S4 resume|
|Component:||Driver/intel||Assignee:||Chris Wilson <chris>|
|Status:||VERIFIED FIXED||QA Contact:||Xorg Project Team <xorg-team>|
|i915 platform:||i915 features:|
Description bo.b.wang 2011-04-21 00:08:15 UTC
System Environment: -------------------------- kernel (drm-intel-fixes)commit:5c72d064f7ead1126bed6faab0c2bfb7418036e2 platform piketon Bug detailed description: ------------------------- I use keithp kernel tree. when I do s4, it can sleeps but when I press power button to resume, the screen will be black after grub phase. SSH can't login, mouse and keyboard can't wake it up, the system down. It's a regression, commit v2.6.38 is ok. Reproduce steps: ---------------- 1.no X 2.echo disk>/sys/power/state 3.press power button
Comment 1 Gordon Jin 2011-04-21 00:42:14 UTC
This also exists in Chris's -fixes. Bo to bisect.
Comment 2 Chris Wilson 2011-04-21 02:01:39 UTC
There were a number of non-i915 suspend/hibernate regressions in 2.6.39. Let's verify that is i915-related first by not loading the i915.ko and doing a hibernate cycle.
Comment 3 bo.b.wang 2011-04-21 02:21:31 UTC
I use both DP and VGA interface when do s4. This issue exists in keith tree 2.6.39rc2( commit 6221f222c0ebf1acdf7abcf927178f40e1a65e2a) and in chris' tree
Comment 4 bo.b.wang 2011-04-21 03:57:19 UTC
S4 can't also resume in G45 platform . But after grub phase ,there are some information in the screen. "PM. Loading and decompressing image data .... PM. Read .... Suspending ... use_console_suspend to debug..
Comment 5 bo.b.wang 2011-04-22 01:45:04 UTC
(In reply to comment #2) > There were a number of non-i915 suspend/hibernate regressions in 2.6.39. Let's > verify that is i915-related first by not loading the i915.ko and doing a > hibernate cycle. this issue still exist after rmmod i915.ko.I will bisect
Comment 6 Gordon Jin 2011-04-24 17:27:12 UTC
(In reply to comment #5) > (In reply to comment #2) > > There were a number of non-i915 suspend/hibernate regressions in 2.6.39. Let's > > verify that is i915-related first by not loading the i915.ko and doing a > > hibernate cycle. > this issue still exist after rmmod i915.ko.I will bisect That means it's probably not our driver bug. You can hold on the bisecting until Chris gives the next signal.
Comment 7 bo.b.wang 2011-04-25 00:11:19 UTC
Now ickle/drm-intel-staging commit 8ff887c847a8c88cee2cddffb8b94f41ebd5e4db Author: Chris Wilson <firstname.lastname@example.org> Date: Sun Apr 17 06:38:35 2011 +0100 drm/i915/dp: Be paranoid in case we disable a DP before it is attached Hi Chris, I have tested this commit.And s4 is no problem
Comment 8 Gordon Jin 2011-05-19 00:03:15 UTC
Chris, is the commit pushed?
Comment 9 Chris Wilson 2011-05-19 00:32:24 UTC
Yes, it landed not too long ago upstream: commit 31acbcc408f412d1ba73765b846c38642be553c3 Author: Chris Wilson <email@example.com> Date: Sun Apr 17 06:38:35 2011 +0100 drm/i915/dp: Be paranoid in case we disable a DP before it is attached Given that the hardware may be left in a random condition by the BIOS, it is conceivable that we then attempt to clear the DP_PIPEB_SELECT bit without us ever enabling/attaching the DP encoder to a pipe. Thus causing a NULL deference when we attempt to wait for a vblank on that crtc. Reported-and-tested-by: Bryan Christ <firstname.lastname@example.org> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36314 Signed-off-by: Chris Wilson <email@example.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36456 Reported-and-tested-by: Bo Wang <firstname.lastname@example.org> Cc: email@example.com Signed-off-by: Keith Packard <firstname.lastname@example.org>
Comment 10 bo.b.wang 2011-06-06 19:22:55 UTC
Test in commit 31acbcc408f412d1ba73765b846c38642be553c3, It works fine!