Created attachment 42340 [details]
Please note I'm not at all sure whether this is an Intel driver, X, or hardware bug.
Basically, on my eeepc 900, using the i915 driver (xf86-video-intel) X randomly crashes, usually when the user is doing something (not when the desktop is idle). I've seen the same behavior with X 1.9.2 and 22.214.171.1241 (1.9.4 RC 1) and versions 2.13 and 2.14 of the Intel driver. It's not exactly reproducible, but it can usually be triggered with good likeliness by either watching youtube videos with firefox, or performing a skype call (it also crashed while doing other things).
The common "feature" of these crashes is that there is absolutely nothing at all in any log. I'm just dropped back to the command line.
Here is more information.
- Graphic chip: 00:02.0 VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 04)
- System Architecture: i686
- Kernel version: 2.6.37-ARCH (same problem with 2.6.36-ARCH)
- pkg-config --modversion libdrm
- Linux distro is Arch Linux
Will provide more verbose files/logs as attachments.
Created attachment 42341 [details]
Created attachment 42342 [details]
Created attachment 42343 [details]
Did you check Xorg.0.log.old? Might be worth connecting a second machine and keeping gdb attached.
Created attachment 42344 [details]
intel_gpu_dump output (compressed)
(In reply to comment #4)
> Did you check Xorg.0.log.old? Might be worth connecting a second machine and
> keeping gdb attached.
Since I've restarted X many times, Xorg.0.log.old is the same as Xorg.0.log. I will go ahead and run the debugging tools.
Created attachment 42346 [details]
GDB backtrace upon SIGSEGV
Unfortunately, in Arch Linux it's not so easy to get debugging symbols. Packages have to be specifically rebuilt with debugging information on, and the eeepc is not up to the task of building big programs. If the included backtrace does not help, I will do my best to try to find a way of getting debug info somehow.
Symbols are garbage, but the gist is there: infinite recursion. So what's your setup? Compositing WM using GL or Xrender, or just a plain WM? And the trigger is mostly skype or flash?
(In reply to comment #8)
> Symbols are garbage, but the gist is there: infinite recursion. So what's your
> setup? Compositing WM using GL or Xrender, or just a plain WM? And the trigger
> is mostly skype or flash?
The desktop is vanilla XFCE as installed by Arch Linux. I did not consciously enable compositing, nor do I know how to check whether I'm using GL or Xrender (but I can certainly run commands and paste the output if directed to do so). I'm not using an xorg.conf file, everything is detected automagically.
Since the backtrace had loads of references to librecord.so, as a further test I looked for a way to disable loading the record module (just to see if it made some difference); not finding information, I went the crude way and renamed /usr/lib/xorg/modules/extensions/librecord.so. After that, restarting X gave an error about it being unable to load librecord.so (as expected), but, surprise, the desktop has been stable (knocking wood). I've been able to mess around with youtube videos and skype as much as I could (even both together at the same time) and I haven't been able to crash it again.
Of course, I'm not sure what librecord.so provides, nor do I know whether what I did could cause other problems. One thing I've noted is that without librecord.so I am no longer able to use the eeepc's integrated webcam.
The record issue looks like a dupe of bug#30032.
(In reply to comment #10)
> The record issue looks like a dupe of bug#30032.
Dang! I'm in fact using x11vnc on the eeepc. I couldn't imagine that this could cause problems, so I did not look for that keyword when searching.
I will try to run it with -noxrecord and report back. Thanks!
(I'm still curious as to how to properly tell X to not load certain modules, though)
This instructs the server to not load the module called module‐
name. Some modules are loaded by default in the server, and
this overrides that default. If a Load instruction is given for
the same module, it overrides the Disable instruction and the
module is loaded. The module name given should be the module's
standard name, not the module file name. As with the Load
instruction, the standard name is case-sensitive, and does not
include the "lib" prefix, or the ".a", ".o", or ".so" suffixes.
*** This bug has been marked as a duplicate of bug 30032 ***
(In reply to comment #12)
> man xorg.conf:
> MODULE SECTION
> Disable "modulename"
(In reply to comment #11)
> (In reply to comment #10)
> > The record issue looks like a dupe of bug#30032.
> Dang! I'm in fact using x11vnc on the eeepc. I couldn't imagine that this could
> cause problems, so I did not look for that keyword when searching.
> I will try to run it with -noxrecord and report back. Thanks!
Bingo. With x11vnc -noxrecord I have no crash. Thank you!