Bug description: Running a for about 24 hours stable then GPU hangs, might be slight memory leak? Not using alot of intense apps, just Konqueror and kmail. System environment: -- chipset:00:02.0 VGA compatible controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02) 00:02.1 Display controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02) -- system architecture: x86 Linux 2.6.34-gentoo-r1 #6 SMP Sat Jul 3 14:11:02 PDT 2010 i686 Mobile Intel(R) Pentium(R) 4 CPU 3.33GHz GenuineIntel GNU/Linux built with gcc 4.3.4 CBUILD="i686-pc-linux-gnu" CFLAGS="-march=pentium4 -mtune=pentium4 -pipe -O2" CHOST="i686-pc-linux-gnu" -- xf86-video-intel: 2.9.1 -- xserver: 1.7.6 -- mesa: 7.7.1 -- libdrm: 2.4.18_pre20100211-r1 -- kernel: 2.6.24-r1 -- Linux distribution: gentoo -- Machine or mobo model: Toshiba a45_s120 -- Display connector: ( LVDS built in laptop ) Reproducing steps: Run this combination of software on a 855GM. Seems to be kernel version as other Gentoo users report the problem goes away with 2.6.32 kernels. Other users whom are running svn versions of the above software experience hangs. Additional info: Complete xorg log, GPU core dump, /sys/kernel/debug/dri/0/i915_error_state, dmesg, kernel config is located at: http://www.think-electric.com/pentium4/ to much to add here.
batchbuffer at 0x056ed000: 0x056ed000: 0x54f00006: XY_SRC_COPY_BLT (rgb enabled, alpha enabled, src tile 0, dst tile 0) 0x056ed004: 0x03cc0fc0: format 8888, dst pitch 4032, clipping disabled 0x056ed008: 0x00750000: dst (0,117) 0x056ed00c: 0x029003dc: dst (988,656) 0x056ed010: 0x05f89000: dst offset 0x05f89000 0x056ed014: 0x008d0000: src (0,141) 0x056ed018: 0x00000fc0: src pitch 4032 0x056ed01c: 0x05f89000: src offset 0x05f89000 0x056ed020: 0x00000000: MI_NOOP 0x056ed024: 0x05000000: MI_BATCH_BUFFER_END buffers: 05f89000 4194304 00000002 00000002 00697030 dirty Superficially looks valid.
A stress test for SRC_COPY_BLT is x11perf -copypixwin500. This has been shown to be a reliable trigger of hangs for a Core2/i945, and I am wondering if we are seeing a similar issue here. Could you please test with x11perf -copypixwin500 and see if your machine survives? Thanks.
Created attachment 37226 [details] output of dmesg during test
x11perf -copypixwin500 x11perf - X11 performance program, version 1.2 The X.Org Foundation server version 10706000 on :0.0 from lapcat Mon Jul 19 18:15:46 2010 Sync time adjustment is 0.2340 msecs. 3600 reps @ 1.3924 msec ( 718.0/sec): Copy 500x500 from pixmap to window 3600 reps @ 1.4114 msec ( 709.0/sec): Copy 500x500 from pixmap to window 3600 reps @ 1.3944 msec ( 717.0/sec): Copy 500x500 from pixmap to window 3600 reps @ 1.3886 msec ( 720.0/sec): Copy 500x500 from pixmap to window 3600 reps @ 1.4041 msec ( 712.0/sec): Copy 500x500 from pixmap to window 18000 trep @ 1.3982 msec ( 715.0/sec): Copy 500x500 from pixmap to window and again: x11perf -copypixwin500 && dmesg > dmesg_during_x11perf.txt x11perf - X11 performance program, version 1.2 The X.Org Foundation server version 10706000 on :0.0 from lapcat Mon Jul 19 18:17:41 2010 Sync time adjustment is 0.2078 msecs. 3600 reps @ 1.3802 msec ( 725.0/sec): Copy 500x500 from pixmap to window 3600 reps @ 1.3833 msec ( 723.0/sec): Copy 500x500 from pixmap to window 3600 reps @ 1.3875 msec ( 721.0/sec): Copy 500x500 from pixmap to window 3600 reps @ 1.3897 msec ( 720.0/sec): Copy 500x500 from pixmap to window 3600 reps @ 1.3823 msec ( 723.0/sec): Copy 500x500 from pixmap to window 18000 trep @ 1.3846 msec ( 722.0/sec): Copy 500x500 from pixmap to window
Yeah, it appears that the x11perf triggered a bug in the i915 code, so not relevant here. :(
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.
(In reply to comment #6) > 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. Is it a kernel patch or a xf86-video-intel patch?
Created attachment 39334 [details] Applied patch to older version. I do not have a intel_uxa.c in the current version of xf86-video-intel-2.9.1 on Gentoo so I applied the patch to what looks like a i830_uxa.c and changed refs from intel to i830. Recompiled and rebooted now I have not had any crashes.
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.