[gm45] Session lost on resume from sleep in Jaunty on Lenovo T500

I can confirm this issue, also with intel driver from git master as of January 24th.

I'm happily suspending and resuming daily on my machine. Please attach Xorg.0.log and dmesg to bug reports. If you can get a gdb backtrace of X crashes, that's the best.

Created an attachment (id=22303)
backtrace

ok, did manage to get a backtrace

Xorg.0.log and dmesg please.

Created an attachment (id=22359)
Xorg.0.log after suspend

This is /var/log/Xorg.0.log.old. Although it doesn't look like it when judging from the log, this is in fact the log from *after* I was sent back to the login window.

Created an attachment (id=22360)
dmesg output taken after a suspend/resume cycle

I just noticed that this bug only surfaces when compiz is running. That is, if compiz is not running, my laptop suspends and resumes reliably.

Created an attachment (id=23078)
Xorg.log with backtrace (modedebug on), uxa+compiz=crash

Here's a log I managed to capture that's somewhat better than the last. There's a small backtrace at the end of it, and I also had modedebug enabled. Hope it helps.

By the way, it seems I have forgotten to provide this information:

$ lspci -vvnn | grep -A2 "VGA compat"
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a42] (rev 07)
 Subsystem: ASUSTeK Computer Inc. Device [1043:1862]
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+

Isn't this a consequence of the fact that the server crashes on chvt, when using UXA and when GL clients (compiz) are active? Some distros (Debian, Ubuntu) chvt away from the X display before suspending.

(In reply to comment #10)
> Isn't this a consequence of the fact that the server crashes on chvt, when
> using UXA and when GL clients (compiz) are active? Some distros (Debian,
> Ubuntu) chvt away from the X display before suspending.
>

I'm not sure, but I do VT switch occasionally, and should have noticed crashes that result from that. But, on the other hand, by chance I might have not been doing that while running with UXA. I'll give it a try and will post back here.

Did some VT switching now. No crash.

That's interesting. It's a 100% crasher with Intel 2.6.1, xorg 1.5.99.902, and Linux 2.6.28, when using UXA and Compiz on GM965.

(In reply to comment #13)
> That's interesting. It's a 100% crasher with Intel 2.6.1, xorg 1.5.99.902, and
> Linux 2.6.28, when using UXA and Compiz on GM965.
>

Actually, there's been the odd couple of times when suspend/resume has worked with that setup. But definitely only once or twice out of 20-30 attempts so far.

I also have run into this bug. Running Gentoo x86-64, X.org 1.5.3-r5, Intel video driver 2.6.3 on an Intel GMA X3100, and kernel 2.6.28-gentoo-r3. I indeed use a compositing window manager (Metacity). After the crash dmesg contains "[drm:i915_setparam] *ERROR* unknown parameter 4".

Created an attachment (id=23998)
Another X.org crash log

I want to note that I still see this issue even after updating to
* kernel 2.6.29-rc8 (KMS enabled)
* xf86-video-intel 2.6.902
* xserver 1.6.0

I can confirm this issue on a thinkpad x200s running xorg from debian experimental (xserver-xorg-core 1.5.99.902-1, xserver-xorg-video-intel 2.6.1-1). About 50% of the time it resumes correctly, the other 50% of the time I end up back at the gdm prompt, which makes me reluctant to use suspend/resume at all. Let me know if there is there any additional information you need that I could provide.

Same problem here: X crashes and login screen appears after (i) resuming from suspend and (ii) switching back from a VT. My /var/log/messages contains:

(a hundred times those "bad handle" messages)
[drm:i915_gem_busy_ioctl] *ERROR* Bad handle in i915_gem_busy_ioctl(): 553649086
[drm:i915_gem_busy_ioctl] *ERROR* Bad handle in i915_gem_busy_ioctl(): 553649086
X[24377] general protection ip:4530d2 sp:7fff84f666f0 error:0 in Xorg[400000+1a9000]
X:24377 freeing invalid memtype d0000000-e0000000
kdm[8631]: X server for display :0 terminated unexpectedly

However, here this problem occurs with EXA and UXA. But it seems that the Gentoo package xf86-video-intel-2.5.1-r1 is clean.

Hi, I have a similar problem and get the following output in my Xorg.0.log:

[...]
(II) intel(0): Modeline "1440x900"x0.0 97.78 1440 1488 1520 1760 900 903 909 926 -hsync -vsync (55.6 kHz)
(II) intel(0): Modeline "1440x900"x0.0 81.49 1440 1488 1520 1760 900 903 909 926 -hsync -vsync (46.3 kHz)
(II) intel(0): Modeline "800x600"x0.0 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz)
(II) intel(0): Modeline "640x480"x0.0 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz)
(II) intel(0): Modeline "1024x768"x0.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz)
(II) intel(0): EDID vendor "LEN", prod id 16435
(II) AIGLX: Suspending AIGLX clients for VT switch

Backtrace:
0: X(xorg_backtrace+0x26) [0x4e9cd6]
1: X(xf86SigHandler+0x39) [0x487ca9]
2: /lib/libc.so.6 [0x3713633040]
3: /usr/lib/libdrm_intel.so.1(drm_intel_bufmgr_check_aperture_space+0x3) [0x7f643ee75803]
4: /usr/lib64/xorg/modules/drivers//intel_drv.so(i830_get_aperture_space+0x3d) [0x7f643f0dcecd]
5: /usr/lib64/xorg/modules/drivers//intel_drv.so [0x7f643f0dd092]
6: /usr/lib64/xorg/modules/drivers//intel_drv.so(uxa_copy_n_to_n+0x621) [0x7f643f0f0401]
7: /usr/lib64/xorg/modules//libfb.so(fbCopyRegion+0x19a) [0x7f643e95dffa]
8: /usr/lib64/xorg/modules/drivers//intel_drv.so(uxa_copy_window+0xc6) [0x7f643f0efc46]
9: X [0x53085b]
10: X [0x4da58f]
11: X(compCopyWindow+0xac) [0x4fa1dc]
12: X(miMoveWindow+0x1f5) [0x4e17d5]
13: X(compMoveWindow+0xae) [0x4fa7be]
14: X(ConfigureWindow+0x570) [0x433920]
15: X(ProcConfigureWindow+0x8d) [0x446f3d]
16: X(Dispatch+0x354) [0x4478b4]
17: X(main+0x3ad) [0x42d8ad]
18: /lib/libc.so.6(__libc_start_main+0xe6) [0x371361e5c6]
19: X [0x42cd49]

Fatal server error:
Caught signal 11. Server aborting

Please consult the The X.Org Foundation support
     at http://wiki.x.org
 for help.
Please also check the log file at "/var/log/Xorg.0.log" for additional information.
[...]

Distribution: Gentoo
Linux 2.6.29-tuxonice sources #2 SMP PREEMPT Fri May 8 16:11:50 CEST 2009 x86_64 Intel(R) Core(TM)2 Duo CPU T9300 @ 2.50GHz GenuineIntel GNU/Linux

lspci:
00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 0c)
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)
00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)
0

xorg.conf:
Section "Device"
    Identifier "Intel"
    Driver "intel"

    # Features
    Option "XvMC" "true"
    Option "XvMCSurfaces" "6"

    # Tweaks
    Option "AccelMethod" "UXA"
    Option "PageFlip" "true"
    Option "TripleBuffer" "true"
    Option "XAANoOffscreenPixmaps" "true"
    Option "BackingStore" "true"
    Option "FrameBufferCompression" "true"
    Option "MigrationHeuristic" "greedy"
    #Option "ExaNoComposite" "false"
EndSection

System crashes to login and I have to kill the process chvt. It doesn't happen at each suspend-resume cycle, though.

Adjusting severity: crashes & hangs should be marked critical.

I'm on Debian and have an Intel GM45 graphics hardware. Kernel is 2.6.30-rc6 (KMS-enabled, self-compiled). X.org driver version is 2.7.1 (with UXA) and X.org version is 1.6.1.901-2 (both from Debian unstable).

I'm seeing the same behavior every now and then when resuming from sleep.

I don't think it is due to the resume, though, but only due to the text console -> xserver switch.

Just try switching from text console to X often, at some point X will crash and restart (this can take 20 switches or more!). It only happens when switching from text console to X that's why people only see this when resuming but never when going to sleep.

I'd have thought (please correct me if I'm wrong) that the vt switch on resume would not be needed if you use KMS. The suspend system in use (pm-suspend?) perhaps needs to have it's rules tweaked (think this is an fdi file?) to not do certain things if KMS is in use... not sure if this is automatically possible in hal, but I'm sure the hypothesis could be tested easily enough by hand.

100% reproducable here with UXA. If I disable "Lock screen on resume" in KDE4 power management options, it works without a problem. With EXA, it doesn't crash even if that option is enabled.

I am using KMS. Disabling KMS does not improve anything.

i965, UXA
kernel 2.6.30_rc5
libdrm 2.4.11
mesa 7.5_rc2
intel 2.7.1
xserver 1.6.1.901

For me, this has been fixed lately (about two-three weeks ago,
using git versions of libdrm, mesa, xf86-video-intel and
X.org server 1.6.1.901). GMA965, linux-2.6.29. Thanks to the devs!

I think that I am experiencing similar same issue, backtrace in Xorg slightly different but overall the same ;):

(II) AIGLX: Suspending AIGLX clients for VT switch

Backtrace:
0: /usr/bin/X(xorg_backtrace+0x26) [0x4ef246]
1: /usr/bin/X(xf86SigHandler+0x39) [0x476689]
2: /lib/libc.so.6 [0x7fb60c57d190]
3: /usr/lib/libdrm_intel.so.1(drm_intel_bufmgr_check_aperture_space+0x3) [0x7fb60a36c8f3]
4: /usr/lib/xorg/modules/drivers//intel_drv.so(i830_get_aperture_space+0x40) [0x7fb60a5d40f8]
5: /usr/lib/xorg/modules/drivers//intel_drv.so [0x7fb60a5d4ce2]
6: /usr/lib/xorg/modules/drivers//intel_drv.so(uxa_copy_n_to_n+0x18b) [0x7fb60a5e94b7]
7: /usr/lib/xorg/modules//libfb.so(fbCopyRegion+0x19a) [0x7fb609d5659a]
8: /usr/lib/xorg/modules/drivers//intel_drv.so(uxa_copy_window+0x127) [0x7fb60a5ead3f]
9: /usr/bin/X [0x535e7b]
10: /usr/bin/X [0x4dfa8f]
11: /usr/bin/X(compCopyWindow+0xac) [0x4ff5dc]
12: /usr/bin/X(miMoveWindow+0x1f5) [0x4e6d15]
13: /usr/bin/X(compMoveWindow+0xae) [0x4ffbbe]
14: /usr/bin/X(ConfigureWindow+0x576) [0x4392a6]
15: /usr/bin/X(ProcConfigureWindow+0x8d) [0x44c9ed]
16: /usr/bin/X(Dispatch+0x364) [0x44d374]
17: /usr/bin/X(main+0x3bd) [0x43321d]
18: /lib/libc.so.6(__libc_start_main+0xe6) [0x7fb60c5695a6]
19: /usr/bin/X [0x4326a9]

In Debian this bug is
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=529072

X org is 7.4
intel driver 2.7.99.1
kernel 2.6.29-2-amd64

Same crash experienced with almost same situation as previous commenter:

GM965GM, intel driver 2.7.99.1, xserver 1.6.901, linux 2.6.29.4, no KMS, libdrm 2.4.11, mesa 7.4.1, rest debian sid.

This is the backtrace I get from core dump. Xorg log available on request.

#0 0x00007f4ab4e1c065 in *__GI_raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0x00007f4ab4e1f153 in *__GI_abort () at abort.c:88
#2 0x000000000046c949 in ddxGiveUp () at ../../../../hw/xfree86/common/xf86Init.c:1417
#3 0x00000000004f86ed in AbortServer () at ../../os/log.c:397
#4 0x00000000004f8d90 in FatalError (f=0x57c7b8 "Caught signal %d. Server aborting\n") at ../../os/log.c:522
#5 0x0000000000476699 in xf86SigHandler (signo=11) at ../../../../hw/xfree86/common/xf86Events.c:387
#6 <signal handler called>
#7 0x00007f4ab2c0b973 in drm_intel_bufmgr_check_aperture_space (bo_array=0x7fffbf394990, count=3)
    at ../../../libdrm/intel/intel_bufmgr.c:155
#8 0x00007f4ab2e730f8 in i830_get_aperture_space () from /usr/lib/xorg/modules/drivers//intel_drv.so
#9 0x00007f4ab2e73ce2 in i830_uxa_prepare_copy () from /usr/lib/xorg/modules/drivers//intel_drv.so
#10 0x00007f4ab2e884b7 in uxa_copy_n_to_n () from /usr/lib/xorg/modules/drivers//intel_drv.so
#11 0x00007f4ab25e859a in fbCopyRegion (pSrcDrawable=0x4ea2a90, pDstDrawable=0x4ea2a90, pGC=0x0,
    pDstRegion=<value optimized out>, dx=-2, dy=-27, copyProc=0x7f4ab2e8832c <uxa_copy_n_to_n>, bitPlane=0, closure=0x0)
    at ../../fb/fbcopy.c:396
#12 0x00007f4ab2e89d3f in uxa_copy_window () from /usr/lib/xorg/modules/drivers//intel_drv.so
#13 0x0000000000535e7b in damageCopyWindow (pWindow=0x5bfaed0, ptOldOrg=<value optimized out>, prgnSrc=0x5719740)
    at ../../../miext/damage/damage.c:1774
#14 0x00000000004dfa8f in miSpriteCopyWindow (pWindow=0x5bfaed0, ptOldOrg={x = 6, y = 297}, prgnSrc=0x5719740)
    at ../../mi/misprite.c:480
#15 0x00000000004ff5dc in compCopyWindow (pWin=0x5bfaed0, ptOldOrg=<value optimized out>, prgnSrc=0x5719740)
    at ../../composite/compwindow.c:577
#16 0x00000000004e6d15 in miMoveWindow (pWin=0x5bfaed0, x=2, y=27, pNextSib=0x0, kind=VTMove) at ../../mi/miwindow.c:317
#17 0x00000000004ffbbe in compMoveWindow (pWin=0x5bfaed0, x=8, y=279, pSib=0x0, kind=VTMove)
    at ../../composite/compwindow.c:363
#18 0x00000000004392a6 in ConfigureWindow (pWin=0x5bfaed0, mask=15, vlist=<value optimized out>, client=0x144)
    at ../../dix/window.c:2400
#19 0x000000000044c9ed in ProcConfigureWindow (client=0x4e47b90) at ../../dix/dispatch.c:741
#20 0x000000000044d374 in Dispatch () at ../../dix/dispatch.c:437
#21 0x000000000043321d in main (argc=8, argv=0x7fffbf395048, envp=<value optimized out>) at ../../dix/main.c:397

It seems fixed in master branch. Cannot reproduce anymore.

I can confirm this issue on 2.6.30-rc8+git and xf86-intel git. A 100% reliable crash upon resume *when within X*.

Machine is still alive afterwards sysrq+s etc still works.

Note that I can reliably suspend/resume when going to console and issueing
echo mem >/sys/power/state . However as soon as I switch to Xorg I get a hang - often with corrupted patterns in the background.

System is debian-sid + self compiled libdrm2/xf86-intel/kernel. GPU is i945 all this on a Samsung NC10 netbook (which used to be rock stable before experiencing the xf86-intel 2.6.X issues).

(In reply to comment #33)
> I can confirm this issue on 2.6.30-rc8+git and xf86-intel git. A 100% reliable
> crash upon resume *when within X*.
>
> Machine is still alive afterwards sysrq+s etc still works.
>
> Note that I can reliably suspend/resume when going to console and issueing
> echo mem >/sys/power/state . However as soon as I switch to Xorg I get a hang -
> often with corrupted patterns in the background.
>
> System is debian-sid + self compiled libdrm2/xf86-intel/kernel. GPU is i945 all
> this on a Samsung NC10 netbook (which used to be rock stable before
> experiencing the xf86-intel 2.6.X issues).
>

I can also confirm I see this bug on 2.6.30.
However, and this would explain Dark Shadow not reproducing, I cannot reproduce this bug on 2.6.29.5.

More evidence that the problem might be on the kernel side.

I can confirm that this bug is still there in 2.6.30 + recent git versions of xf86 intel. However, as recently reported I can also confirm that it does *not occur* with 2.6.29.1 nor 2.6.29.5 (at least I could reliably suspend/resume for 5 times).

I just notice that on 2.6.29.X I see a ton of

s2ram:5248 freeing invalid memtype d1508000-d1509000
...
in steps of 1000 until d1757000-d1758000 in the kernel logs.

Not sure if this happens on suspend or on resume.

intel 965gma

xorg-server-1.6.1.901-r4
mesa-7.4.2
libdrm-2.4.11
video-intel-2.7.1
kernel-2.6.30 with kms

KDE 4.2 with desktop effects.

I can confirm this behaviour. It is caused by fullscreen 3D things... I updated qt from 4.4somethign to 4.5.1 and I assume it changed something about the handling of the desktop with 3D effects. 3D fullscreen games I could run without problems, but when they quit, xorg crashed. Eventually this is the same that happens when I resume from hibernate.

(In reply to comment #33)
> I can confirm this issue on 2.6.30-rc8+git and xf86-intel git. A 100% reliable
> crash upon resume *when within X*.
> Machine is still alive afterwards sysrq+s etc still works.
> Note that I can reliably suspend/resume when going to console and issueing
> echo mem >/sys/power/state . However as soon as I switch to Xorg I get a hang -
> often with corrupted patterns in the background.
Do you mean that the suspend/resume can work on your box if you switch to console mode?
Will you please do the following test and see whether the X can work well?
   a. boot the system into console mode(the i915 driver should also be loaded)
   b. do the suspend/resume
   c. start X and see whether the X can work well.

If it can work well, it will be great if you can do another test
   d. boot the system into X mode and then get the gpu dump using intel-gpu-tool)
   e. switch to console mode and get the gpu dump
   f. do the supend/resume and get the gpu dump after resuming

After the test, please attach the outputs of gpu dump.
thanks.
> System is debian-sid + self compiled libdrm2/xf86-intel/kernel. GPU is i945 all
> this on a Samsung NC10 netbook (which used to be rock stable before
> experiencing the xf86-intel 2.6.X issues).

Well, what I was trying to say was that I did a,b,c and received a hang (X garbled, IIRC mouse could still be moved) when doing c.

Note that I was using 2.6.30 + UXA for this. EXA works fine and 2.6.29 + UXA at least sometimes).

Timo, do you still have this issue? I never got a Xorg.0.log from you, which should have hopefully included the assertion failure. (I suspect the assertion failure has been fixed since your report, though, in which case this bug should be closed and people reporting other problems should open their own bug reports)

Eric, sorry for not updating this. It's fixed as far as I'm concerned. Running Ubuntu Karmic devel release, and there it's working just fine. Closing as fixed.