Created attachment 38606 [details] Xorg log 2) System environment: 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) -- system architecture: i686 -- xf86-video-intel: 2.12.0 -- xserver version: 1.8.2 -- mesa version: 7.8.2 (from portage as glxinfo triggers more X crashes) --libdrm version: 2.4.21 -- kernel version: 2.6.34-hardened-r4 -- Linux distribution: Gentoo Linux -- Machine or mobo model: Toshiba Satellite A105-S4094 -- Display connector: LVDS1 connected 1280x800+0+0 (normal left inverted right x axis y axis) 289mm x 2100mm 3) Reproduce steps. Start X,kde,kwin compositing(optional seems to speed up hang) Start applications, esp OGL (zsnes, mupen etc) Use X as normal, wait for hang X restarts and disables acceleration as the GPU is hung. Any OGL application (glxgears, glxinfo,zsnes in my case) causes X to reset with a segfault
Created attachment 38607 [details] dmesg output
Created attachment 38608 [details] i915 error state
Created attachment 38609 [details] Register dump
Created attachment 38610 [details] vbios dump
Created attachment 38611 [details] xorg conf
commit 944001201ca0196bcdb088129e5866a9f379d08c Author: Dave Airlie <airlied@redhat.com> Date: Tue Jul 20 13:15:31 2010 +1000 drm/i915: enable low power render writes on GEN3 hardware. A lot of 945GMs have had stability issues for a long time, this manifested a one such report is at: https://bugs.freedesktop.org/show_bug.cgi?id=20560 along with numerous distro bugzillas. This only took a week of digging and hair ripping to figure out. Tracked down and tested on a 945GM Lenovo T60, previously running x11perf -copypixwin500 or x11perf -copywinpix500 repeatedly would cause the GPU to wedge within 4 or 5 tries, with random busy bits set. After this patch no hangs were observed. cc: stable@kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
Created attachment 38617 [details] Newer debug info with drm.debug=0x06 enabled on newer kernel I wasn't sure whether this was the same bug or not. Newer debug info on a 2.6.35 kernel.
Looks remarkably similar. Can you grab intel_reg_dumper from http://cgit.freedesktop.org/git/xorg/apps/intel-gpu-tools and attach its output?
Created attachment 38621 [details] Newer debug info with drm.debug=0x06 enabled on newer kernel
Comment on attachment 38621 [details] Newer debug info with drm.debug=0x06 enabled on newer kernel I didn't manage to get vanilla 2.6.35.3 running yet, so I used gentoo-sources-2.6.35-r5
Created attachment 38622 [details] register dump
Created attachment 38623 [details] Xorg log
Created attachment 38624 [details] dmesg output
Created attachment 38625 [details] i915 error state
Created attachment 38626 [details] vbios dump
Created attachment 38628 [details] xorg conf
This could have something to do with it: 0x08f10100: 0x54f00006: XY_SRC_COPY_BLT (rgb enabled, alpha enabled, src ti le 0, dst tile 0) 0x08f10104: 0x03cc0080: format 8888, dst pitch 128, clipping disabled 0x08f10108: 0x00000000: dst (0,0) 0x08f1010c: 0x00160016: dst (22,22) 0x08f10110: 0x01ba9000: dst offset 0x01ba9000 0x08f10114: 0x00080425: src (1061,8) 0x08f10118: 0x00000040: src pitch 64 0x08f1011c: 0x01ba8000: src offset 0x01ba8000
Created attachment 38632 [details] backtrace of Xorg on hang (gdb) bt #0 0xb7717424 in __kernel_vsyscall () #1 0xb7429471 in raise () from /lib/libc.so.6 #2 0xb742abb2 in abort () from /lib/libc.so.6 #3 0xb723f335 in i830_uxa_copy (dest=0xb9261e50, src_x1=1033, src_y1=8, dst_x1=0, dst_y1=0, w=22, h=22) at intel_uxa.c:427 #4 0xb7254dc2 in uxa_copy_n_to_n (pSrcDrawable=0xb8b67908, pDstDrawable=0xb9261e50, pGC=0x0, pbox=0xbfbbba10, nbox=1, dx=1033, dy=8, reverse=0, upsidedown=0, bitplane=0, closure=0x0) at uxa-accel.c:591 #5 0xb725c7ff in uxa_composite (op=1 '\001', pSrc=0xb91a1e10, pMask=0x0, pDst=0xb8f0c570, xSrc=<value optimized out>, ySrc=8, xMask=<value optimized out>, yMask=<value optimized out>, xDst=0, yDst=0, width=22, height=22) at uxa-render.c:1585 #6 0xb783bebd in damageComposite (op=6 '\006', pSrc=0xb91a1e10, pMask=0x0, pDst=0xb8f0c570, xSrc=<value optimized out>, ySrc=<value optimized out>, xMask=<value optimized out>, yMask=<value optimized out>, xDst=<value optimized out>, yDst=<value optimized out>, width=<value optimized out>, height=<value optimized out>) at damage.c:640 #7 0xb7832382 in CompositePicture (op=0 '\000', pSrc=0xb91a1e10, pMask=0x0, pDst=0xb8f0c570, xSrc=1033, ySrc=8, xMask=<value optimized out>, yMask=<value optimized out>, xDst=<value optimized out>, yDst=<value optimized out>, width=22, height=22) at picture.c:1710 #8 0xb77f937d in compNewPixmap (pWin=<value optimized out>, x=<value optimized out>, y=8, w=<value optimized out>, h=<value optimized out>) at compalloc.c:537 ---Type <return> to continue, or q <return> to quit--- #9 0xb77f996d in compAllocPixmap (pWin=0xb9067ee8) at compalloc.c:561 #10 0xb77fbe7a in compCheckRedirect (pWin=0x6) at compwindow.c:162 #11 0xb77fc098 in compRealizeWindow (pWin=0xb9067ee8) at compwindow.c:243 #12 0xb77710a2 in RealizeTree (pWin=0xb8b67908) at window.c:2533 #13 0xb77735d6 in MapWindow (pWin=0xb8b67908, client=0xb87d9628) at window.c:2628 #14 0xb777c3c4 in ProcMapWindow (client=0xb87d9628) at dispatch.c:809 #15 0xb777cd2f in Dispatch () at dispatch.c:432 #16 0xb775b222 in main (argc=10, argv=0xbfbbbf14, envp=0xbfbbbf40) at main.c:291
Created attachment 38643 [details] [review] Source clipping
Created attachment 38656 [details] backtrace of Xorg on hang with source clipping (In reply to comment #19) > Created an attachment (id=38643) [details] > Source clipping With your patch to drm-intel.git applied #0 0xb76e9424 in __kernel_vsyscall () #1 0xb73fb471 in raise () from /lib/libc.so.6 #2 0xb73fcbb2 in abort () from /lib/libc.so.6 #3 0xb7213b39 in i830_uxa_copy (dest=0x0, src_x1=1061, src_y1=9, dst_x1=0, dst_y1=0, w=22, h=22) at intel_uxa.c:454 #4 0xb7228db2 in uxa_copy_n_to_n (pSrcDrawable=0xa8e68e0, pDstDrawable=0xaf3c280, pGC=0x0, pbox=0xbfb920f0, nbox=1, dx=1061, dy=9, reverse=0, upsidedown=0, bitplane=0, closure=0x0) at uxa-accel.c:591 #5 0xb722fcbe in uxa_composite (op=1 '\001', pSrc=0xaf62e50, pMask=0x0, pDst=0xa16a088, xSrc=<value optimized out>, ySrc=9, xMask=<value optimized out>, yMask=<value optimized out>, xDst=0, yDst=0, width=22, height=22) at uxa-render.c:1585 #6 0x0812fa56 in damageComposite (op=6 '\006', pSrc=0xaf62e50, pMask=0x0, pDst=0xa16a088, xSrc=<value optimized out>, ySrc=<value optimized out>, xMask=<value optimized out>, yMask=<value optimized out>, xDst=<value optimized out>, yDst=<value optimized out>, width=<value optimized out>, height=<value optimized out>) at damage.c:643 #7 0x081295b2 in CompositePicture (op=0 '\000', pSrc=0xaf62e50, pMask=0x0, pDst=0xa16a088, xSrc=1061, ySrc=9, xMask=<value optimized out>, yMask=<value optimized out>, xDst=<value optimized out>, yDst=<value optimized out>, width=22, height=22) at picture.c:1714 #8 0x080faa8b in compNewPixmap (pWin=<value optimized out>, x=<value optimized out>, y=9, w=<value optimized out>, h=<value optimized out>) at compalloc.c:536 ---Type <return> to continue, or q <return> to quit--- #9 0x080fad5c in compAllocPixmap (pWin=0xb04c770) at compalloc.c:560 #10 0x080fd0e2 in compCheckRedirect (pWin=0xb04c770) at compwindow.c:162 #11 0x080fd203 in compRealizeWindow (pWin=0xb04c770) at compwindow.c:243 #12 0x080791e2 in RealizeTree (pWin=0xa8e68e0) at window.c:2556 #13 0x0807ce0e in MapWindow (pWin=0xa8e68e0, client=0xa1915b0) at window.c:2651 #14 0x08084545 in ProcMapWindow (client=0xa1915b0) at dispatch.c:837 #15 0x08084efd in Dispatch () at dispatch.c:439 #16 0x08065bae in main (argc=10, argv=0xbfb92604, envp=0xbfb92630) at main.c:286
Created attachment 38657 [details] [review] Source clipping v2
commit 08c2caca48323d6d5701dcef3486f850619d7905 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Sun Sep 12 12:34:51 2010 +0100 uxa: Apply source clipping to blits Yes, this should be done in the higher layers. Yes, I have written code to that. No, it is not ready, hence add the sanity check to the SRC_COPY_BLT. This isn't the first report that I've seen, but will be the last.
Closing resolved+fixed after >seven years of silence.
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.