Latest working kernel version: 2.6.29 rc5 Earliest failing kernel version: 2.6.29 rc6 Distribution: kernel.org 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 ? xorg: 2:1.4.2-10 intel driver: 2:2.3.2-2+lenny6
hm... i file the bug and now can't reproduce it...
problem exists. but i can't 100% reproduce it every suspend .
rc6 if i trying to suspend in just after X loaded - box hangs if i wait a bit (minute or so) - suspend/resume working ok. rc5 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 [jbarnes@jbarnes-t61 drm-intel]$ 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. Thanks.
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. ps: 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.