Created attachment 42340 [details] Xorg.0.log 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 1.9.3.901 (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 2.4.23 - Linux distro is Arch Linux Will provide more verbose files/logs as attachments.
Created attachment 42341 [details] dmesg output
Created attachment 42342 [details] VBIOS dump
Created attachment 42343 [details] glxinfo output
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)
man xorg.conf: ... MODULE SECTION ... Disable "modulename" 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" Thanks.
(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!
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.