I have half-a-dozen+ examples of the xdm server crashing and not restarting, most since early 2008 seeming to involve various versions of the Intel driver on a Intel 915 chip. There are 2 specific problems. 1) The server crashes. 2) The system does not auto-restart the xdm server and does not allow switching to any of the virtual consoels (tty1, tty2, etc) and requires a hard system reboot which generally requires 30+ minutes to return to the state the system was in prior to the crash (restarting 7 workspaces with dozens of windows and hundreds of open URLs/files is non-trivial). See attachments for examples from the xdm.log files. These are running under Gentoo Linux with the most up-to-date driver releases from Gentoo. These problems are taking place on Dell LCD monitor where 915resolution has been used to reconfigure the BIOS (copy?) to run at 1680x1050 resolution (which commonly works fine as it can take 1-2 weeks of active use between instances of this problem).
Created attachment 16239 [details] xdm.log for xdm crash Crash of xdm. In general the most recent driver versions with this crash result in a highly blured screen in the top 2-3" of the monitor and the rest of the monitor will be black. It is impossible to switch to the non-X system virtual consoles as would normally be the case so a hard reboot is required.
Created attachment 16240 [details] Xorg.0.log Xorg.0.log file which pairs with previous xdm.log file (Attachment #16239 [details]).
Created attachment 16241 [details] xdm.log for another example of xdm crashing
Created attachment 16242 [details] Xorg.0.log for another example of xdm crashing
Created attachment 16243 [details] xdm.log from yet another example of xdm crashing
From the logs it appears that xdm itself is not crashing - the Xorg server is crashing, and when xdm tries to restart it, Xorg fails to restart.
Created attachment 16244 [details] Xorg.0.log from yet another example of xdm crashing It would also be very nice if more testing were done with the Intel driver involving multiple X terminals (Xorg.[0123].log) simultaneously as there appears to be a somewhat different problem with the X server crashing when one tries to run multiple sessions, particularly if one session may be running 45+ Firefox windows (300+ tabs) and potentially an mplayer session playing TV directly from a Hauppauge PVR-150 card. One should be able to switch back and forth between a complex X terminal like this and simpler X terminal instances without crashing xdm. One should also be able to restart xdm and have it reset the video card properly in an instance when one does crash xdm.
Alan, I am not an expert on how X works (e.g. xdm vs. Xorg, etc.). In general I agree with your comments. I think the crash of Xorg leaves the software/hardware of the 915 chip in an undefined state. When xdm tries to restart Xorg on xterm 0 it finds it cannot do so and hangs the entire system (both Xterms and virtual consoles). It used to be the case that I could run 3-4 xterms and have separate sessions on each of them (and have no problems switching to the virtual consoles) but the problems with the collective X system on the Intel hardware have become so severe over the last 4-6 months (I will admit I am pushing the system a bit harder) that I have cut back to only running a single X terminal and avoid switching to the virtual consoles if at all possible. Usually the only reason I would use the virtual consoles is to view the log files and/or attempt to reboot xdm by hand. But IMO, there is a real problem with testing Xterm failures. There should be a test as a standard part of the system which kills Xterms "randomly" (across all of the various hardware drivers) such that xdm is required to restart them. That stress tests the terminals/drivers being in "random" states and would tend to reveal cases where the software & hardware aren't handling various "unusual" conditions.
Robert, please provide required logs according to http://www.intellinuxgraphics.org/how_to_report_bug.html. thanks.
Robert, can you try the xf86-video-intel git master branch? A new log with below commit will be useful for debugging: commit c8ae3b781f0d8e325876a74c91cd0a685d34454b Author: Keith Packard <keithp@keithp.com> Date: Sun Apr 20 02:11:15 2008 -0700 Add a bunch of 965 ring stuff to the debug dump
Created attachment 16261 [details] dmesg associated with attachments 16239/16240 The output of uname -a is: Linux frodo 2.6.24-gentoo-r4 #1 PREEMPT Sun Apr 6 12:31:00 EDT 2008 i686 Intel(R) Pentium(R) 4 CPU 2.80GHz GenuineIntel GNU/Linux Previous crashes could go back to 2.6.23 and perhaps even 2.6.22 versions of Linux. The machine is a HP Pavilion a630n which appears to contain an ASUS PTGD1-LA (Grouper-UL8E) motherboard with an Intel 915G Express (Grantsdale) chipset. An edited log from the build of the Gentoo driver, includes version information as follows: >>> Emerging (1 of 1) x11-drivers/xf86-video-i810-2.2.99.903-r1 to / * xf86-video-intel-2.2.99.903.tar.bz2 RMD160 SHA1 SHA256 size ;-) ... [ ok ] * checking xf86-video-intel-2.2.99.903.tar.bz2 ;-) ... [ ok ] >>> Unpacking source... * Checking for direct rendering capabilities ... >>> Unpacking xf86-video-intel-2.2.99.903.tar.bz2 to /root2/var/tmp/portage/x11-drivers/xf86-video-i810-2.2.99 .903-r1/work * Applying xf86-video-i810-2.2.99.903-fix-panel-resize-on-i8xx.patch ... [ ok ] * Running eautoreconf in '/root2/var/tmp/portage/x11-drivers/xf86-video-i810-2.2.99.903-r1/work/xf86-video-intel-2.2.99.903' ... * Running elibtoolize in: xf86-video-intel-2.2.99.903 Will work on the driver/debug suggestions, but as mentioned the bug does not appear to have easy-to-reproduce pattern for the problem. It is usually when I am pushing Firefox very hard (40+ windows, 300+ tabs). In the last (first filed) crash I might have been running (but not using) GoogleEarth in one of my workspaces, but I do not believe that is the case with all of the crashes. As previously mentioned, the problem did seem to occur more frequently when I was running 3-4 X terminals and I was switching between the terminals.
Ok guys, after crashing the driver yet again (attempting to bring up multiple virtual terminals, bug report to be filed) I attempted to build a driver from xorg (vs. from gentoo). The only drivers I could find (via FTP, not "git" which is a language I have no interest in speaking [1]) were an 2007 "xf86-video-i810-1.7.4.tar.bz2" and an Apr 23 2007 "xf86-video-intel-2.3.0.tar.bz2". It appears from examining the source that the errors being produced are coming from i830_debug.c and i830_driver.c but as the modification dates on those files are Mar 25 2008 and Apr 21 2008 which predate this bug report I would assume these are not the files which you would like me to compile. Word to the wise, do not always assume that everyone filing a bug report is an X guru (or even comfortable using "current" tools). I was working on UNIX systems in 1974, was producing C compiler code generators in the 1980s and was for 4 years Oracle's UNIX product development manager. I can give you the information you need to debug this. But it annoys me no end to spend several hours googling on how to "git" X sources (esp drivers which arguably are not really part of "X" itself) -- you lose points fast when I have to do that and get nowhere. It is a better use of my time to be debugging genomes instead of X drivers. Facilitate the process of people downloading and testing your code (as it appears you have failed to perform reasonable stress testing yourselves). 1. Files were downloaded from: ftp://xorg.freedesktop.org//pub/xorg/individual/driver/
I believe multiple session issue has been fixed by Eric and currently be in git master and stable branch. For git usage, you may see http://www.x.org/wiki/Development/git, or wait for 2.3.1 tarball (I'd hopefully release it within several days.)
Robert, 2.3.1 has been available at http://xorg.freedesktop.org/releases/individual/driver/. Would you give it a try? Or maybe checking if the driver in your distribution has been updated too.
we even have 2.3.2 now. last ping for update from bug reporter.
Created attachment 17890 [details] Intelfb ring buffer space exhausted This is a subset of the contents of the debug log file. It shows the error of running out of space in the ring buffer. Scenario. Linux 2.6.26-gentoo #5, 3 X servers running. Attempting to switch (somewhat rapidly) between logged in VTs running Gnome. System is compiled with intelfb and booted with video=intelfb. Full set of log files is available on request.
Attachment 17890 [details] was generated (as were several similar ring buffer space exhaustion "crashes") while attempting to configure the console ttys to be running a 48+ line screen under Linux 2.6.26 using intelfb rather than uvesafb which was what was previously being used. This is on a Prescott CPU running at 2.8 GHz with i915 graphics hardware. Switching between X terminals involves noticeable delays (several seconds). If the graphics hardware is too slow for the size of the ring buffer then the documentation needs to reflect (or a Linux/X configuration option supplied to expand the size of the ring buffer. I have switched back to a single X terminal and the problem has not shown up again. This leads me to suspect there is *still* a problem running multiple X terminals with the Intel drivers.
Robert, you didn't mention intelfb before. Can you only see the crash when using intelfb? what if you remove it from kernel ( need to recompile as you said it's built-in )?
For many months I ran with uvesafb. The precise line option in grub was: video=uvesafb:1280x1024-32@60,mtrr:3,ywrap I have only started using intelfb (video=intelfb vga=0x31B) with the release of Linux 2.6.26. I have seen the space allocation problem with uvesafb as well as intelfb. Intelfb did not seem to properly display text if I simply changed "uvesafb" to "intelfb" (on a linux compiled with intelfb instead of uvesafb). I'm using small fonts and while uvesafb would give me something like 64 lines on the consoles, intelfb (as configured above) will only give me something like 48 lines. Not what I would like but better than the standard 24 lines. Though I normally use X, that has been troublesome due to the problem of switching between VTs crashing X. I was working towards being able to run mplayer on the consoles (through a frame buffer interface which I believe is necessary) and switching back and forth between the consoles and a single X windows session. And yes, I know this is a rather strange thing to do but I have a tendency to push the envelope.
Robert, I appreciate your detailed explanation, but I can't see a direct answer from your comment. :) does it crash or not if you do _not_ use intelfb or other framebuffer kernel driver?
try to close due to no response from bug reporter in long time...
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.