Periodically when I'm flying around, my X server will crash hard and do something untoward with the video hardware to the point where I cannot restart X, and I need to reboot the machine to be able to start X again.

The best recipe for reproduction I've found is to go into Verasi I-5, and try to dock with the station at the deepest port. I'll almost always get a crash then. It seems to happen more often in fogged-in sectors, but I've had several instances of it happening at random, when I'm just cruising around in normal space. It's not related to time in game; I've been running for days before without a problem, then I'll get several crashes in the course of a couple of hours. Never had any problems running any other 3D program (although to be fair I don't do a lot of 3D gaming).

I've diffed a normal Xorg log and one when it fails to start, and included that output below. I can send the entire Xorg log to anyone who feels they can make use of it.

System specs:

Vendetta 1.8.61 (though has been happening with every Vendetta version I've use so far -- 1.8.60 and 1.8.59)
Debian GNU/Linux 5.0, amd64
Lenovo Thinkpad T61
Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller rev 12
4GB RAM
Not sure what else will be helpful...

Happy to try test builds or whatever to try and track this thing down.

---[BEGIN log diff]---
@@ -713,6 +705,8 @@
(II) intel(0): 0x02d88000-0x0366ffff: depth buffer (9120 kB) Y tiled
(II) intel(0): 0x03670000-0x0566ffff: classic textures (32768 kB)
(II) intel(0): 0x10000000: end of aperture
+(WW) intel(0): ESR is 0x00000001
+(WW) intel(0): Existing errors found in hardware state.
(II) intel(0): Selecting standard 18 bit TMDS pixel format.
(II) intel(0): Output configuration:
(II) intel(0): Pipe A is off
@@ -801,3 +795,45 @@
(II) XINPUT: Adding extended input device "Configured Mouse" (type: MOUSE)
(II) Configured Mouse: ps2EnableDataReporting: succeeded
Could not init font path element /usr/share/fonts/X11/cyrillic, removing from list!
+Error in I830WaitLpRing(), timeout for 2 seconds
+pgetbl_ctl: 0xbff80001 pgetbl_err: 0x00000000
+ipeir: 0x00000000 iphdr: 0x60020100
+LP ring tail: 0x0001fff0 head: 0 len: 0x0001f001 start 0x00000000
+Err ID (eir): 0x00000000
+Err Status (esr): 0x00000001
+Err Mask (emr): 0xffffffdf
+instdone: 0xffe5fafd instdone_1: 0x000ffffc
+instpm: 0x00000000
+memmode: 0x00000000 instps: 0x0409f02e
+HW Status mask (hwstam): 0xfff8dffe
+IRQ enable (ier): 0x00000002 imr: 0xfff80000 iir: 0x00000020
+acthd: 0x03f35c08 dma_fadd_p: 0x03f35c08
+ecoskpd: 0x00000307 excc: 0x00000000
+cache_mode: 0x00006800/0x00000180
+mi_arb_state: 0x00000044
+IA_VERTICES_COUNT_QW 0x00000000/0x00000000
+IA_PRIMITIVES_COUNT_QW 0x00000000/0x00000000
+VS_INVOCATION_COUNT_QW 0x00000000/0x00000000
+GS_INVOCATION_COUNT_QW 0x00000000/0x00000000
+GS_PRIMITIVES_COUNT_QW 0x00000000/0x00000000
+CL_INVOCATION_COUNT_QW 0x00000000/0x00000000
+CL_PRIMITIVES_COUNT_QW 0x00000000/0x00000000
+PS_INVOCATION_COUNT_QW 0x00000000/0x00000000
+PS_DEPTH_COUNT_QW 0x00000000/0x00000000
+WIZ_CTL 0x00000000
+TS_CTL 0x00000000 TS_DEBUG_DATA 0x377f63fe
+TD_CTL 0x00000000 / 0x00000000
+space: 8 wanted 32
+(II) intel(0): [drm] removed 1 reserved context for kernel
+(II) intel(0): [drm] unmapping 8192 bytes of SAREA 0x2efff000 at 0x7f953f3e6000
+(II) intel(0): [drm] Closed DRM master.
+
+Fatal server error:
+lockup

Still happening, though I've narrowed it down to definitely being caused by fog. Basically, I can fly around for days and days and never have a problem, but once I enter a fog sector I can guarantee that I'll have a crash within an hour or so.

Can I please have some developer assistance in running this thing to ground, or at least mitigating it's effects? It's putting an annoying restriction on my in-game activities.

If it can crash the X server, then it's a driver bug... Not sure if the devs will be able to fix it for you...

Have you tried turning off shaders?

I have no idea what's wrong. Are you using the latest drivers for your video card?
Try doing what roguelazer said.
There are some things you can try to change in the config.ini file, but I'll have to get back to you on that.

OK, turning off shaders appears to have fixed it -- at least, I've been cruising around and in and out of I-5 for a while now without it blowing up on me. Interestingly, I also no longer get any bright yellow roids in fog or storms.

As far as it being a driver bug, yes, ultimately if a userspace program can crash X it's a bug in the driver, but since nothing else crashes, and VO's a closed-source program, I've got little hope of finding the source of the bug without dev assistance.

Even with the source, it's difficult to track down a driver crash like that. From my experience, driver crashes aren't caused exclusively by the calling function, but by a combination of functions that called in a certain way eventually leads to a crash.

The dump you posted doesn't really give a useful set of data. If you were able to record a stack dump of the game, then maybe i can help track it down. Do you have the source to the drivers? Maybe strace or something like that could help. I think there's some OpenGL shim library that records every opengl call to a file, and that could help find what function triggers the lock-up.

"Even with the source, it's difficult to track down a driver crash like that. From my experience, driver crashes aren't caused exclusively by the calling function, but by a combination of functions that called in a certain way eventually leads to a crash."

Sure, but it's a lot easier to work out what's being done differently in fog sectors with shaders on vs shaders off if you've got the source code than if you don't.

"The dump you posted doesn't really give a useful set of data. If you were able to record a stack dump of the game, then maybe i can help track it down."

It crashes X, which takes down vendetta as a consequence. I could try attaching a debugger to vendetta on a console, but as you say, the likely root cause of the problem (some incorrect shader-related call in fog sectors) will be long gone by the time the thing crashes.

"Do you have the source to the drivers?"

Yes, Intel's pretty good about releasing source to their Linux drivers.

"Maybe strace or something like that could help. I think there's some OpenGL shim library that records every opengl call to a file, and that could help find what function triggers the lock-up."

If you can point me at such a library, I'll try it out and do a diff on the shader-on vs shader-off behaviour in fog. Google is giving me no love on such a beast, though.

GLtrace is one example. It may not trace more recent extensions, though.

gDEBugger is another, but it's not fully free.

The game uses a different set of shaders depending on whether fog is being rendered or not. The difference is the presence or absence of "OPTION ARB_fog_linear;"