Kernel Bug Tracker – Bug 12778
suspend regression from 29rc5 to 29rc6
Last modified: 2013-04-09 06:23:26 UTC
Latest working kernel version: 2.6.29 rc5
Earliest failing kernel version: 2.6.29 rc6
Hardware Environment: acer travelmate 4051
Software Environment: debian squeeze
Problem Description: system fail to suspend under X
but few tests from console are ok.
Steps to reproduce:
echo "mem" > /sys/power/state
or try to suspend via hal ( ie ask guidance-power-manager to suspend)
should i attach .config/dmesg ?
intel driver: 2:2.3.2-2+lenny6
hm... i file the bug and now can't reproduce it...
but i can't 100% reproduce it every suspend .
if i trying to suspend in just after X loaded - box hangs
if i wait a bit (minute or so) - suspend/resume working ok.
in both cases suspend are ok.
Does suspend work with .29-rc6 and without X?
rc6 w/o X is ok. ( at least few times it suspends/resumes ok)
a have try rc8 - and rare hangs during suspend from X still exists. unfortunately i have nothing in logs (
only this one is looks strage:
but i got this message on successful suspend.
[drm:i915_get_vblank_counter] *ERROR* trying to get vblank count for dis
abled pipe 0
Thanks for the update.
If you have DRI enabled in the X config, please try to disable it and see if that makes a difference.
The fact that -rc6 w/o X is fine indicates a problem with graphics.
(In reply to comment #7)
> Thanks for the update.
> If you have DRI enabled in the X config, please try to disable it and see if
> that makes a difference.
here, you probably need a reboot to unload the drm/i915 driver. :)
I also suffer from this for a while now. I reported the problem against xserver-xorg-video-intel back then (see https://bugs.freedesktop.org/show_bug.cgi?id=20520 for all the logs), and just got pointed to this bug here.
When the freeze happens (a few minutes after resuming), I also get those kernel messages:
Mar 29 23:32:54 tick kernel: [14858.069290] [drm:i915_get_vblank_counter] *ERROR* trying to get vblank count f
or disabled pipe 1
Mar 29 23:32:54 tick kernel: [14858.074255] mtrr: no MTRR for d0000000,10000000 found
I see nothing else, in Xorg.log, etc., just the intel register dump shows that the chip crashed (MI_MODE: 0x00000000).
I confirm that running X with Option "DRI" "off", and rmmod'ing i915 and drm, suspend works fine.
If it really happened between rc5 and rc6 something outside of drivers/gpu must be to blame:
[jbarnes@jbarnes-t61 drm-intel]$ git log v2.6.28-rc5..v2.6.28-rc6 drivers/gpu
After -rc6 came out there were some changes though (and the resulting kernel would have still been called -rc6 until the final Makefile change):
[jbarnes@jbarnes-t61 drm-intel]$ git shortlog v2.6.28-rc5..v2.6.28-rc7 drivers/gpu
Andrew Morton (1):
drivers/gpu/drm/i915/i915_irq.c: fix warning
Eric Anholt (3):
drm/i915: Remove IMR masking during interrupt handler, and restart it if n
drm/i915: Avoid BUG_ONs on VT switch with a wedged chipset.
drm/i915: Fix copy'n'pasteo that broke VT switch if flushing was non-empty
Keith Packard (5):
drm/i915: Manage PIPESTAT to control vblank interrupts instead of IMR.
drm/i915: Subtract total pinned bytes from available aperture size
drm/i915: Always read pipestat in irq_handler
drm/i915: execbuffer pins objects, no need to ensure they're still in the
drm: move drm vblank initialization/cleanup to driver load/unload
Peng Li (1):
drm/i915: Save/restore HWS_PGA on suspend/resume
Would it be possible for one of you to bisect? Martin, you also mentioned that X was hanging on an ioctl, can you attach to the server with gdb and get a proper backtrace? Please post further info to http://bugs.freedesktop.org/show_bug.cgi?id=20520 since it's easier for me to track there.
i now using kernel with verbose-PM messages
and... i can find nothing in syslog.
lock appears to be before syncing disks:
1. just black screen -> SysRQ doesn't help here..
2. black screen and cursor blinking, then few messages about syncing disk frozing tasks, and system successfully sleep.
i about to suspect that bug is really intel-driver/xorg problem.
i can't be sure that problem is 100% between rc5 and 6, since i belive it really rare and earlier version maybe affected.
My instance of that problem has now finally been tracked down, it was caused by the patch in http://bugzilla.kernel.org/show_bug.cgi?id=12950 . We reverted this in Ubuntu, and suspend works once again flawlessly. Thus I cannot contribute to debugging this any more.
after xorg/intel-driver update i have no more hangs.