Using xorg-server-1.3.0.0 and the new intel driver version 1.2.1 (older versions, too), segfaults occur eventually when doing graphically intensive tasks. For me, it is usually during beryl events such as window switching/minimizing, but it has also happened while playing video. I have not noticed a bug that occurred in the intel driver version 1.2.0, namely segfaulting on VT switching, but this is also possible. The segfaults are not constant and do not usually occur until after the system has been used for a bit. Just guessing, I would say it usually takes at least a half hour. It is also difficult to reproduce with videos/beryl on occasion. The VT switching issue was easy to reproduce but sadly I have not tested it yet, updates on that later. System: current x86 archlinux with kernel 2.6.21.6, xorg-server-1.3.0, mesa 6.5.3, and libgl-dri-6.5.3. Hardware: Dell 1300 laptop with an intel 915gm graphics chip. My xorg.conf and a Xorg.0.log will be included to clarify the bug. To reproduce: Use the same xorg-specific packages/versions I did and presumably a 915gm graphics chip using a similar/the same xorg.conf, use beryl or play a video, and go about your business.
Created attachment 10647 [details] Shirakawasuna's xorg.conf Here's my xorg.conf, the issue still occurs with XAANoOffscreenPixmaps disabled and without Beryl/compositing.
Created attachment 10648 [details] Xorg.0.log (Beryl segfault) Added Xorg.0.log attachment for a Beryl-induced segfault.
Nick, does this still happen with the latest released versions of the Intel 2D driver, the X server and Mesa? This may actually be a server bug. You might also try the "EXA" accleration method. Just add Option "AccelMethod" "EXA" to your xorg.conf intel driver section.
I hadn't been using beryl or the newer xorg for a while, but I just tested it and it again gives me a segfault. I was running xorg-server-1.4, mesa 7.0.1, and the intel driver version 2.1.1, all on archlinux. It took about 4 days for it to happen, with more than one xorg session, but eventually during a window switch it decided to die. Here's the backtrace from the xorg log: Backtrace: 0: /usr/bin/X(xf86SigHandler+0x7e) [0x80d9d9e] 1: [0xb7f25420] 2: /usr/lib/xorg/modules//libxaa.so [0xb7a0657d] 3: /usr/bin/X [0x816d6cf] 4: /usr/bin/X(CompositeGlyphs+0x9a) [0x8154d2a] 5: /usr/bin/X [0x815c5b8] 6: /usr/bin/X [0x8157a45] 7: /usr/bin/X [0x814b22e] 8: /usr/bin/X(Dispatch+0x2bf) [0x808c76f] 9: /usr/bin/X(main+0x48b) [0x8073d9b] 10: /lib/libc.so.6(__libc_start_main+0xe0) [0xb7cf2f90] 11: /usr/bin/X(FontFileCompleteXLFD+0x209) [0x8073111] Fatal server error: Caught signal 11. Server aborting ----- I haven't try the EXA acceleration method, I'll try that next and see how it does. Thanks for the help!
EXA with Beryl/Compiz fusion makes various desktop tasks unacceptably slow, like scrolling, window switching, and fullscreen video. It hasn't crashed with EXA yet, but given that it makes my computer even less usable it isn't exactly a fix.
The backtrace doesn't implicate the Intel driver, so this may be a server bug.
Is there anything else I can do to get more information? I always figure that with enough info, anything can be fixed...
Is this still happening with current versions of X related components?
Crashes in XAA aren't a thing anymore.
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.