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
This also exists in Chris's -fixes. Bo to bisect.
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.
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
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..
(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
(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.
Now ickle/drm-intel-staging commit 8ff887c847a8c88cee2cddffb8b94f41ebd5e4db Author: Chris Wilson <chris@chris-wilson.co.uk> 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
Chris, is the commit pushed?
Yes, it landed not too long ago upstream: commit 31acbcc408f412d1ba73765b846c38642be553c3 Author: Chris Wilson <chris@chris-wilson.co.uk> 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 <bryan.christ@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36314 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36456 Reported-and-tested-by: Bo Wang <bo.b.wang@intel.com> Cc: stable@kernel.org Signed-off-by: Keith Packard <keithp@keithp.com>
Test in commit 31acbcc408f412d1ba73765b846c38642be553c3, It works fine!
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.