When I try to render an animation in Blender, the first couple of times it works, but sooner or later it always crashes the X server. The xserver then keeps restarting (probably triggered by kdm), the mouse is shown an can be moved, but the keyboard is dead. Hardware: Intel G965 Distribution: Debian/sid Kernel: 2.6.22 Xserver: 1.3 Driver: Intel 2.1 Mesa: 6.5.2 Logs/config will follow.
Created attachment 10990 [details] Xorg.0.log
Created attachment 10991 [details] lspci -vvv output
Created attachment 10992 [details] xorg.conf
Created attachment 10993 [details] KDM log file
Created attachment 11038 [details] Backtrace Backtrace. This is with the most recent Mesa now (7.x)
I have tried now with Exa enabled in xorg.conf. X does not crash anymore, but rather quits with error code 1. Also the keyboard stays alive, but re-starting X fails. I will attach two more logs, one that shows X quitting on the error, and one that shows X refusing to start.
Created attachment 11039 [details] Xorg.0.log with Exa, quitting on error
Created attachment 11040 [details] Xorg.0.log with Exa, unable to start after error
Created attachment 11041 [details] Blender data file that I use to reproduce crash This is the file I use with Blender 2.44 to reproduce the crash. I open it and then repeatedly do Render -> Render Animation until it crashes.
Christian, error message "Error in I830WaitLpRing(), timeout for 2 seconds" normally means that we can't do any rendering as graphics engine looks hang for too long, so we believe it's dead and quit. It means we have programmed something wrong on the device. pls try with latest mesa git, which contains some fixes for 3D bugs on 965, to see if it also helps blender.
(In reply to comment #10) > pls try with latest mesa git, which contains some fixes for 3D bugs on 965, to > see if it also helps blender. > I tried with mesa git today, (as of commit bad6e175cf59cce630c37d73f6e71f3a4de50ae6), but I can still reproduce the lockup. The only difference to before is that kdm gives up on trying to restart the X server after a couple of times and drops back to console login with the keyboard working again, so at least I can reboot gracefully without remote login now :-) New logs will follow.
Created attachment 11322 [details] kdm.log 2007-08-29
Created attachment 11323 [details] Xorg.0.log 2007-08-29
Could you add Option "EXANoComposite" "true", in Device section? that will disable i965 X render composite. So I want to tell if this is truely a 3D bug or EXA bug.
I can't reproduce it, even with your xorg.conf. Could you try the latest 2D driver?
(In reply to comment #14) > Could you add Option "EXANoComposite" "true", in Device section? that will > disable i965 X render composite. So I want to tell if this is truely a 3D bug > or EXA bug. > With this "Device" section I can still reproduce the lockup: Section "Device" Identifier "Intel Corporation 82G965 Integrated Graphics Controller" Driver "intel" BusID "PCI:0:2:0" Option "AccelMethod" "EXA" Option "EXANoComposite" "true" EndSection I turned off direct rendering, and I could NOT reproduce the lockup: Section "Device" Identifier "Intel Corporation 82G965 Integrated Graphics Controller" Driver "intel" BusID "PCI:0:2:0" Option "AccelMethod" "EXA" Option "DRI" "false" EndSection
(In reply to comment #15) > I can't reproduce it, even with your xorg.conf. Could you try the latest 2D > driver? > Do you mean xf86-video-intel? If so then the latest version rom git/master does still lockup here (as of commit f7fd9a98178cdebda4213796fdc452a8a265a1197).
Christian, would you please test to see if this bug still exist? we tested last week and still can't reproduce this bug...:( what's the model name of your PC or mobo if it's a DIY machine?
(In reply to comment #18) > Christian, would you please test to see if this bug still exist? we tested last > week and still can't reproduce this bug...:( > > what's the model name of your PC or mobo if it's a DIY machine? > Hello Michael. I have last tested this on 2007-10-20 and I can still reproduce the crash. In fact I reproduced it three times in a row, and then I turned DRI back off. This test was done with xorg core 1.4, intel 2.1.1 and mesa 7.0.1. The motherboard is a GigaByte GA-965GM-S2. cheers, Christian
*** Bug 13503 has been marked as a duplicate of this bug. ***
Another good way to reproduce the crash is with the game Scorched 3d. configure scorched to use a large window and high detail, to increase the frequency of crashing (but nothing makes it stable) start a single-player game in 'apoc' mode. select a practice level (target practice) game in the game, click on 'smoke tracer' and select apocalypse as your weapon push down arrow to aim turret directly up (90 degrees) push page-down to lower power a little, to 700 or so. press space to fire. repeat as needed to cause crash. i cannot do above steps 10 times in a row without having to reboot my whole system. with a large window, it most often crashes on the first try. hope this helps. (ps, thinkpad T61 with intel 965 and ubuntu gutsy here)
Another way to cause this crash is to start Tremulous (a game that uses the Q3 engine) then press Alt+Enter to leave fullscreen mode then open the console by pressing ~ or ` (this is to release the mouse) then move the cursor over a window handle in the taskbar . The crash happened as the KDE window description box was being drawn.
Hi, I suspect that this is the same bug that has been reported in the latest Ubuntu (Gutsy - 7.10), and that I can reproduce reliably by simply using PyMol. https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/124023 Thanks Anders
There is also a reference to this freedesktop bugzilla in Ubuntu launchpad 120834 "intel gm965 freezes with 3d applications" https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/120834
I am getting the same crash on a Toshiba Satellite U300-11Y. The crash happens in K-3D, after creating a mesh and rotating the viewport, with DRI enabled in xorg.conf, and VBO (vertex buffer) painters enabled in K-3D. Leaving DRI enabled, but disabling the VBO code in K-3D does not cause a crash. Running with DRI disabled, K-3D no longer detects VBO availability and switches to non-VBO code automatically. To me, it seems the crash is related to some of the more advanced OpenGL features, such as vertex buffers.
I experience this bug with Ubuntu Gutsy (Kubuntu alternate-installation on AMD64) on a Dell Optiplex 745, one graphics controller Intel 965 with one or two monitors connected. An excerpt from lspci: 00:02.0 VGA compatible controller: Intel Corporation 82Q963/Q965 Integrated Graphics Controller (rev 02) 00:02.1 Display controller: Intel Corporation 82Q963/Q965 Integrated Graphics Controller (rev 02) To trigger the bug I compiled the contents of the mesademos-package. When more than one of the demos are running and the windows are moved fast on the screen one over the other, sooner or later the system crashes. The demos "terrain", "tunnel", "fire" and "bounce" were my favorite candidates, two or three of them, some window-moving preferably also from one screen to the other and one over the other, and it took most certainly less than a minute to stop my computer.
Everybody who isn't the original submitter with blender should be submitting their own bugs for their own issues. You will be forgotten if you just try to tag along on someone else's bug report. Tested with blender 2.45, GM965 and mesa master in INTEL_NO_TTM=1 mode (hit some 2D issue in ttm mode that I haven't tracked down yet), and a few passes of render animation didn't reproduce it.
Hi, I met the same crash issue in Ubuntu Hardy beta. Chipset: 965GM uname -a: Linux beta 2.6.24-12-generic #1 SMP Wed Mar 12 22:31:43 UTC 2008 x86_64 GNU/Linux xf86-video-intel: 2.2.1 Xserver: 1.4.0.90 Mesa: 7.0.3-rc2 drm: i915 1.6.0 Here is the reproduce steps: 1. system -> preference -> appearance -> Visual Effects -> "None" 2. start one glxgears 3. start blender 4. system will crash when try to move the glxgears window. I attached some logfiles for this, please let me know if you need more thanks Kevin
Created attachment 15415 [details] Xorg.0.log when crash happened
Created attachment 15416 [details] lspci
I think I experience this bug too when playing 3 animations with freewrl. I'm using a 965GM video card under Mandriva 2008.1 (X Server 1.4.0.90 and x11-driver-video-intel-2.2.1). I've tried with the last intel driver 2.2.99.902, this is the same. Im my Xorg.0.log.old : (WW) intel(0): ESR is 0x00000001 (WW) intel(0): PRB0_CTL (0x0001f001) indicates ring buffer enabled (WW) intel(0): PRB0_HEAD (0x08a0cbe4) and PRB0_TAIL (0x0000ce80) indicate ring buffer not flushed (WW) intel(0): Existing errors found in hardware state. Error in I830WaitLpRing(), timeout for 2 seconds pgetbl_ctl: 0x7ff80001 pgetbl_err: 0x0 ipeir: 0 iphdr: 2000003 LP ring tail: ce88 head: cbe4 len: 1f001 start 0 Err ID (eir): 0 Err Status (esr): 1 Err Mask (emr): ffffffdf instdone: 3fe5fafd instdone_1: ffffd instpm: 0 memmode: 0 instps: 8001e035 HW Status mask (hwstam): fffedffe IRQ enable (ier): a2 imr: fffe0000 iir: 50 acthd: 8a0cbe4 dma_fadd_p: ccc0 ecoskpd: 307 excc: 0 cache_mode: 6800/180 mi_arb_state: 44 IA_VERTICES_COUNT_QW 0/0 IA_PRIMITIVES_COUNT_QW 0/0 VS_INVOCATION_COUNT_QW 0/0 GS_INVOCATION_COUNT_QW 0/0 GS_PRIMITIVES_COUNT_QW 0/0 CL_INVOCATION_COUNT_QW 0/0 CL_PRIMITIVES_COUNT_QW 0/0 PS_INVOCATION_COUNT_QW 0/0 PS_DEPTH_COUNT_QW 0/0 WIZ_CTL 0 TS_CTL 0 TS_DEBUG_DATA fefb7b3c TD_CTL 0 / 0 space: 130388 wanted 131064 Fatal server error: lockup Error in I830WaitLpRing(), timeout for 2 seconds pgetbl_ctl: 0x7ff80001 pgetbl_err: 0x0 ipeir: 0 iphdr: 2000003 LP ring tail: ce90 head: cbe4 len: 1f001 start 0 Err ID (eir): 0 Err Status (esr): 1 Err Mask (emr): ffffffdf instdone: 3fe5fafd instdone_1: ffffd instpm: 0 memmode: 0 instps: 8001e035 HW Status mask (hwstam): fffedffe IRQ enable (ier): a2 imr: fffe0000 iir: 50 acthd: 8a0cbe4 dma_fadd_p: ccc0 ecoskpd: 307 excc: 0 cache_mode: 6800/180 mi_arb_state: 44 IA_VERTICES_COUNT_QW 0/0 IA_PRIMITIVES_COUNT_QW 0/0 VS_INVOCATION_COUNT_QW 0/0 GS_INVOCATION_COUNT_QW 0/0 GS_PRIMITIVES_COUNT_QW 0/0 CL_INVOCATION_COUNT_QW 0/0 CL_PRIMITIVES_COUNT_QW 0/0 PS_INVOCATION_COUNT_QW 0/0 PS_DEPTH_COUNT_QW 0/0 WIZ_CTL 0 TS_CTL 0 TS_DEBUG_DATA fefb7b3c TD_CTL 0 / 0 space: 130380 wanted 131064 FatalError re-entered, aborting lockup
Created attachment 15769 [details] backtrace gdb output
I've tried to update Mesa to 7.0.3, no changes.
So far I have recreated this bug with Blender, Wings3D, OpenArena and Tremulous (last two are games that use the Quake 3 engine). The bug happens on both Gnome and KDE. The bug only happens in windowed mode. The bug does NOT happen when the applications are in fullscreen mode. I guess an implication is that the crash is related to 2D and 3D applications sharing the screen. To recap I am using Fedora 8 x86_64 with the latest updates. glxinfo: OpenGL renderer string: Mesa DRI Intel(R) 965G 4.1.3002 OpenGL version string: 1.4 Mesa 7.0.3 Xorg -version: X Window System Version 1.3.0 Release Date: 19 April 2007 X Protocol Version 11, Revision 0, Release 1.3 Build Operating System: Fedora 8 Red Hat, Inc. Current Operating System: Linux localhost.localdomain 2.6.24.4-64.fc8 #1 SMP Sat Mar 29 09:15:49 EDT 2008 x86_64 Build Date: 14 March 2008 Build ID: xorg-x11-server 1.3.0.0-44.fc8 I am using an Intel Core 2 Duo E6300 processor with an Intel DG965WH motherboard (G965/GMA X3000 graphics). No other graphics hardware is installed in the system. I am using an analogue monitor via the normal 15pin VGA output.
(In reply to comment #34) > So far I have recreated this bug with Blender, Wings3D, OpenArena and Tremulous > (last two are games that use the Quake 3 engine). The bug happens on both Gnome > and KDE. The bug only happens in windowed mode. The bug does NOT happen when > the applications are in fullscreen mode. I guess an implication is that the > crash is related to 2D and 3D applications sharing the screen. > > To recap I am using Fedora 8 x86_64 with the latest updates. > > glxinfo: > > OpenGL renderer string: Mesa DRI Intel(R) 965G 4.1.3002 > OpenGL version string: 1.4 Mesa 7.0.3 > > Xorg -version: > > X Window System Version 1.3.0 > Release Date: 19 April 2007 > X Protocol Version 11, Revision 0, Release 1.3 > Build Operating System: Fedora 8 Red Hat, Inc. > Current Operating System: Linux localhost.localdomain 2.6.24.4-64.fc8 #1 SMP > Sat Mar 29 09:15:49 EDT 2008 x86_64 > Build Date: 14 March 2008 > Build ID: xorg-x11-server 1.3.0.0-44.fc8 > > > I am using an Intel Core 2 Duo E6300 processor with an Intel DG965WH > motherboard (G965/GMA X3000 graphics). No other graphics hardware is installed > in the system. I am using an analogue monitor via the normal 15pin VGA output. > Thanks. What is your libdrm/DRM version? Your DRM module is from kernel or git master?
> Thanks. > What is your libdrm/DRM version? Your DRM module is from kernel or git master? > The modules are from git - I installed the xorg 2D driver, libdrm and the drm kernel module from git master last night and the crash still happens exactly as before. One application that uses 2D and 3D at once that doesn't cause the crash is GtkRadiant, a level editor for quakelike games. This does 3D via gtkglext. It does (sometimes) crash after I run another 3D application though, with the error "radiant: bufmgr_fake.c:1395: bm_fake_NotifyContendedLockTake: Assertion `bmTestFence(intel, block->fence)' failed." but I guess that's a different bug altogether.
(In reply to comment #36) > > Thanks. > > What is your libdrm/DRM version? Your DRM module is from kernel or git master? > > > > The modules are from git - I installed the xorg 2D driver, libdrm and the drm > kernel module from git master last night and the crash still happens exactly as > before. Could you try with the latest mesa_7_0_branch? There are some new fixes for 965. I can't reproduce this issue with blender on my box.
Using the latest mesa git appears to fix this issue. I was unable to recreate the crash in blender. I shall try to recreate the crash with other 3D apps when I next have time.
I tried to use last mesa_7_0_branch (20080621) on Ubuntu Hardy (8.04). I successfully compiled and installed the following sources: git clone git://anongit.freedesktop.org/git/mesa/drm (modules and libdrm) git clone git://anongit.freedesktop.org/git/xorg/driver/xf86-video-intel git clone git://anongit.freedesktop.org/git/mesa/mesa mesa_7_0_branch but after computer reboot, i found the following line in the /var/log/Xorg.0.log file: (EE) AIGLX error: dlsym for __driCreateNewScreen_20050727 failed (/usr/lib/dri/i965_dri.so: undefined symbol: __driCreateNewScreen_20050727) and of course DRI doesn't work. how can i compile mesa_7_0_branch for my system ... is this branch currently unusable? on this Ubuntu bug forum, others has same problem: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/120834
(In reply to comment #39) > I tried to use last mesa_7_0_branch (20080621) on Ubuntu Hardy (8.04). > I successfully compiled and installed the following sources: > > git clone git://anongit.freedesktop.org/git/mesa/drm (modules and libdrm) > git clone git://anongit.freedesktop.org/git/xorg/driver/xf86-video-intel > git clone git://anongit.freedesktop.org/git/mesa/mesa mesa_7_0_branch > > but after computer reboot, i found the following line in the > /var/log/Xorg.0.log file: > > (EE) AIGLX error: dlsym for __driCreateNewScreen_20050727 failed > (/usr/lib/dri/i965_dri.so: undefined symbol: __driCreateNewScreen_20050727) Clearly, /usr/lib/dri/i965_dri.so isn't the one you compiled from mesa_7_0_branch. Please check the install path in configs/default. > and of course DRI doesn't work. > how can i compile mesa_7_0_branch for my system > ... is this branch currently unusable? > > on this Ubuntu bug forum, others has same problem: > https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/120834 >
(In reply to comment #40) Dear haihao, Thank you for your reply. > > (EE) AIGLX error: dlsym for __driCreateNewScreen_20050727 failed > > (/usr/lib/dri/i965_dri.so: undefined symbol: __driCreateNewScreen_20050727) > > Clearly, /usr/lib/dri/i965_dri.so isn't the one you compiled from > mesa_7_0_branch. Please check the install path in configs/default. Yes. I modified INSTALL_DIR and DRI_DRIVER_INSTALL_DIR to proper location before compilation. ----- It's like that __driCreateNewScreen_20050727 function is somehow missing from the i965_dri.so of mesa_7_0_branch #readelf -aW /usr/lib/dri/i965_dri.so |grep CreateNewScreen 214: 00000000000311bd 6 FUNC LOCAL DEFAULT 11 dri2CreateNewScreen 225: 00000000000317e1 586 FUNC LOCAL DEFAULT 11 driCreateNewScreen #ls -al /usr/lib/dri/ -rwxr-xr-x 1 root root 19300387 2008-06-21 15:08 i965_dri.so (The date is: 2008-06-21) ----- If i reinstall the original ubuntu package, i can see this: # readelf -aW /usr/lib/dri/i965_dri.so |grep CreateNewScreen 1027: 000000000003abe0 749 FUNC GLOBAL DEFAULT 11 __driCreateNewScreen_20050727 1848: 000000000002ed40 657 FUNC GLOBAL DEFAULT 11 __driUtilCreateNewScreen #ls -al /usr/lib/dri/ -rw-r--r-- 1 root root 2475432 2008-04-06 00:05 i965_dri.so (2008-04-06 <-- this is the original ubuntu file, compiled from Mesa-7.0.3-rc2 sources) ----- I tried to simple rename the new driCreateNewScreen to __driCreateNewScreen_20050727 in the source, but it didn't help (X crashed), because the parameters are not the same ...etc. ----- In mesa_7_0_branch sources directory: #grep -r 200507 * src/glx/mini/miniglx.c:static const char createNewScreenName[] = "__driCreateNewScreen_20050727"; src/glx/mini/miniglx.c: 20050727, src/egl/drivers/dri/egldri.c: return 20050725; src/egl/drivers/dri/egldri.c:static const char createNewScreenName[] = "__driCreateNewScreen_20050727"; But miniglx.o and egldri.o is not exists after compilation. It means these files are not compiled into i965_dri.so ----- If i try to search any file contains "__driCreateNewScreen_20050727" string in my system, i found: /usr/lib/xorg/modules/extensions/libglx.so Sould i recompile my whole xserver system to use mesa_7_0_branch ? ----- Xorg -version: X.Org X Server 1.4.0.90 Release Date: 5 September 2007 X Protocol Version 11, Revision 0 Build Operating System: Linux Ubuntu (xorg-server 2:1.4.1~git20080131-1ubuntu9.2) Current Operating System: Linux prema 2.6.24-19-rt #1 SMP PREEMPT RT Wed Jun 4 16:31:35 UTC 2008 x86_64 Build Date: 13 June 2008 01:10:57AM
(In reply to comment #41) > > > > (EE) AIGLX error: dlsym for __driCreateNewScreen_20050727 failed > > > (/usr/lib/dri/i965_dri.so: undefined symbol: __driCreateNewScreen_20050727) > > > > Clearly, /usr/lib/dri/i965_dri.so isn't the one you compiled from > > mesa_7_0_branch. Please check the install path in configs/default. > > Yes. I modified INSTALL_DIR and DRI_DRIVER_INSTALL_DIR to proper location > before compilation. > > ----- > It's like that __driCreateNewScreen_20050727 function is somehow > missing from the i965_dri.so of mesa_7_0_branch > > #readelf -aW /usr/lib/dri/i965_dri.so |grep CreateNewScreen > 214: 00000000000311bd 6 FUNC LOCAL DEFAULT 11 dri2CreateNewScreen > 225: 00000000000317e1 586 FUNC LOCAL DEFAULT 11 driCreateNewScreen > Oh, the source you are using is from Mesa master, not mesa_7_0_branch. BTW, we use this bug to track a crash issue on 965. So please submit your own bug for your issue.
(In reply to comment #42) > Oh, the source you are using is from Mesa master, not mesa_7_0_branch. > Yes, you are right... After i checkout mesa_7_0_branch i could compile and use it. Now i can report also, this bug is fixed! Thanks a lot :-)
I too suffer from this bug, but the latest mesa from git doesn't fix it. I tried the mesa_7_0_branch. I can reproduce it very easy if I make a glxgears window bigger and move it around a bit. I get the error: Error in I830WaitLpRing(), timeout for 2 seconds before the crash.
Created attachment 17340 [details] Xorg.0.log from a crash with mesa from mesa_7_0_branch
(In reply to comment #44) > I too suffer from this bug, but the latest mesa from git doesn't fix it. > I tried the mesa_7_0_branch. > I can reproduce it very easy if I make a glxgears window bigger and move it > around a bit. Hi, Giorgos I don't think the issue you encountered is same as this issue, although X server also crashed. The latest xf86-video-driver has a fix for back buffer, please try it. If the server still crashes, please open a new bug to track it.
According to comments #38, #43 and a similar bug #16254, I mark this bug as fixed. If some still experience this issue with blender, please re-open it with your detailed environment.
Mass version move, cvs -> git
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.