X Strike Force XFree86 SVN commit: r2185 - in trunk/debian: . local
Author: branden
Date: 2005-02-10 16:48:16 -0500 (Thu, 10 Feb 2005)
New Revision: 2185
Modified:
trunk/debian/CHANGESETS
trunk/debian/changelog
trunk/debian/local/FAQ.xhtml
Log:
Add two entries to the FAQ:
+ How can I help debug the XFree86 X server?
+ How can I help debug 3D acceleration problems?
Modified: trunk/debian/CHANGESETS
===================================================================
--- trunk/debian/CHANGESETS 2005-02-10 08:36:40 UTC (rev 2184)
+++ trunk/debian/CHANGESETS 2005-02-10 21:48:16 UTC (rev 2185)
@@ -310,4 +310,9 @@
(also used by xserver-xfree86-dbg).
2184
+Add two entries to the FAQ:
++ How can I help debug the XFree86 X server?
++ How can I help debug 3D acceleration problems?
+ 2185
+
vim:set ai et sts=4 sw=4 tw=80:
Modified: trunk/debian/changelog
===================================================================
--- trunk/debian/changelog 2005-02-10 08:36:40 UTC (rev 2184)
+++ trunk/debian/changelog 2005-02-10 21:48:16 UTC (rev 2185)
@@ -242,8 +242,12 @@
* Write and ship a "presubj" bug message for the xserver-xfree86 package
(also used by xserver-xfree86-dbg).
- -- Branden Robinson <branden@debian.org> Thu, 10 Feb 2005 03:08:21 -0500
+ * Add two entries to the FAQ:
+ + How can I help debug the XFree86 X server?
+ + How can I help debug 3D acceleration problems?
+ -- Branden Robinson <branden@debian.org> Thu, 10 Feb 2005 16:47:23 -0500
+
xfree86 (4.3.0.dfsg.1-10) unstable; urgency=medium
* Upload urgency set to medium due to fix for stable-release-critical bugs
Modified: trunk/debian/local/FAQ.xhtml
===================================================================
--- trunk/debian/local/FAQ.xhtml 2005-02-10 08:36:40 UTC (rev 2184)
+++ trunk/debian/local/FAQ.xhtml 2005-02-10 21:48:16 UTC (rev 2185)
@@ -166,6 +166,9 @@
windows; what's happening?</a></li>
<li><a href="#precompiledkeymap">How can I set up my X server or X terminal to
use XKB without any X libraries or XKB data installed?</a></li>
+<li><a href="#debugxserver">How can I help debug the XFree86 X server?</a></li>
+<li><a href="#debugmesadri">How can I help debug 3D acceleration
+problems?</a></li>
</ul>
<h2><a href="#acknowledgements">Acknowledgements</a></h2>
@@ -3259,13 +3262,252 @@
<p>See <code class="manpage">xkbcomp(1x)</code> and <code
class="manpage">Xserver(1x)</code> for more information.</p>
+<h3><a id="debugxserver">How can I help debug the XFree86 X server?</a></h3>
+
+<p>You can often help Debian and upstream driver maintainers fix problems by
+narrowing down exactly where a crash or lockup is. You don't need to do this
+when filing an initial bug report — you can do it for any problem you can
+reproduce and follow-up to an existing bug report. The <code
+class="program">reportbug</code> program will give you the opportunity to add
+information to an already-filed report when it displays the list of bugs already
+filed against a package.</p>
+
+<p>The first thing to do is to see if you can reproduce the problem with the
+<code class="package">xserver-xfree86-dbg</code> package. Install the
+package and tell <code class="other">debconf</code> you want to use that X
+server. Then restart the X server and try to reproduce the bug (hopefully, this
+is easy). If it doesn't crash, let us know. If a bug is in the XFree86 X
+server's ELF module loader, you likely won't see it when you use the debugging
+server. Debian still wants to know that information. If it does crash, become
+<code class="other">root</code>, enable core dumps (<kbd>ulimit -c
+unlimited</kbd> in <code class="program">bash</code>), start the X server as
+<code class="other">root</code> and reproduce the crash again:</p>
+
+<p><kbd>startx $(which x-terminal-emulator) -- :1</kbd></p>
+
+<p>If no X server is running at server number 0 (<code
+class="other">DISPLAY=:0</code>), you can leave off the <kbd>-- :1</kbd>
+arguments.</p>
+
+<p>This will launch the X server running a lone terminal client with no window
+manager. Run the client that provokes the crash from the terminal prompt.
+If you can only reproduce the crash with a more elaborate environment, then
+go ahead and produce that environment. Be sure to tell us what you did to
+get it (e.g., launching GNOME or KDE, setting up a particular screensaver,
+running an SDL game — whatever it takes). It is not wise to run X clients
+as <code class="other">root</code> except when absolutely necessary, so if the
+session doesn't crash, don't leave it running. Shut it down as soon as you can.
+It might also be a good idea to scrub out root's home directory (<code
+class="filespec">/root</code>) of hidden files and directories created by
+desktop environments and whatever X clients you attempted to reproduce the crash
+with. Look for <code class="filespec">/root/.gnome</code>, <code
+class="filespec">/root/.kde</code>, and so forth.</p>
+
+<p>If the X server crashes, it should leave a core dump file called <code
+class="filespec">core</code> in <code class="filespec">/etc/X11</code>.</p>
+
+<p>Next, run the GNU Debugger, GDB (from the <code class="package">gdb</code>
+package), on the <code class="filespec">core</code> file and <code
+class="filespec">XFree86-debug</code> executable. The information of most
+interest to us is a backtrace of execution. The X server has a signal handler
+in it so it can do things like exit gracefully (restoring the text console, and
+so forth), so we're not actually interested in all the stack frames — just
+those "above" the signal handler.</p>
+
+<p>Here's an example GDB session I logged after provoking an artificial server
+crash (with <kbd>kill -SEGV</kbd>).</p>
+
+<pre> % gdb $(which XFree86-debug) core
+ GNU gdb 6.1-debian
+ Copyright 2004 Free Software Foundation, Inc.
+ GDB is free software, covered by the GNU General Public License, and you are
+ welcome to change it and/or distribute copies of it under certain conditions.
+ Type "show copying" to see the conditions.
+ There is absolutely no warranty for GDB. Type "show warranty" for details.
+ This GDB was configured as "i386-linux"...Using host libthread_db library "/lib/libthread_db.so.1".
+
+ Core was generated by `/usr/X11R6/bin/X :1'.
+ Program terminated with signal 6, Aborted.
+ Reading symbols from /usr/lib/libfreetype.so.6...done.
+ Loaded symbols for /usr/lib/libfreetype.so.6
+ Reading symbols from /usr/lib/libz.so.1...done.
+ Loaded symbols for /usr/lib/libz.so.1
+ Reading symbols from /lib/libm.so.6...done.
+ Loaded symbols for /lib/libm.so.6
+ Reading symbols from /lib/libc.so.6...done.
+ Loaded symbols for /lib/libc.so.6
+ Reading symbols from /lib/ld-linux.so.2...done.
+ Loaded symbols for /lib/ld-linux.so.2
+ #0 0x400f2721 in kill () from /lib/libc.so.6
+ (gdb) bt
+ #0 0x400f2721 in kill () from /lib/libc.so.6
+ #1 0x400f24c5 in raise () from /lib/libc.so.6
+ #2 0x400f39e8 in abort () from /lib/libc.so.6
+ #3 0x08464b8c in ddxGiveUp () at xf86Init.c:1173
+ #4 0x08464c6b in AbortDDX () at xf86Init.c:1224
+ #5 0x08508bd7 in AbortServer () at utils.c:436
+ #6 0x0850a563 in FatalError (f=0x8a26ea0 "Caught signal %d. Server aborting\n") at utils.c:1421
+ #7 0x0847fbf5 in xf86SigHandler (signo=11) at xf86Events.c:1198
+ #8 <signal handler called>
+ #9 0x40199dd2 in select () from /lib/libc.so.6
+ #10 0x401f8550 in ?? () from /lib/libc.so.6
+ #11 0x400164a0 in ?? () from /lib/ld-linux.so.2
+ #12 0xbffff8f0 in ?? ()
+ #13 0x08502520 in WaitForSomething (pClientsReady=0xbffff944) at WaitFor.c:350
+ #14 0x084cff54 in Dispatch () at dispatch.c:379
+ #15 0x084e763c in main (argc=2, argv=0xbffffe04, envp=0xbffffe10) at main.c:469
+ (gdb) bt full -7
+ #9 0x40199dd2 in select () from /lib/libc.so.6
+ No symbol table info available.
+ #10 0x401f8550 in ?? () from /lib/libc.so.6
+ No symbol table info available.
+ #11 0x400164a0 in ?? () from /lib/ld-linux.so.2
+ No symbol table info available.
+ #12 0xbffff8f0 in ?? ()
+ No symbol table info available.
+ #13 0x08502520 in WaitForSomething (pClientsReady=0xbffff944) at WaitFor.c:350
+ i = 2
+ waittime = {tv_sec = 118, tv_usec = 580000}
+ wt = (struct timeval *) 0xbffff910
+ timeout = 599999
+ standbyTimeout = 1199999
+ suspendTimeout = 1799999
+ offTimeout = 2399999
+ clientsReadable = {fds_bits = {0 <repeats 32 times>}}
+ clientsWritable = {fds_bits = {1, 146318192, -1073743800, 140704020, 147350456, 147350040, 2, 312, 1, 1075418973, -1073743800, 139461033, 147374816, 1, -1073743680, 9, 1073833120, -1073742332,
+ -1073743784, 139526463, 9, -1073743680, 1, 139458611, 147350456, 147350040, -1073743752, 139529154, 147339744, -1073743680, 1, 1074655182}}
+ curclient = 147556952
+ selecterr = 3
+ nready = 0
+ devicesReadable = {fds_bits = {1, 1, 6, 146327832, 147350508, 0, 315, 302, 9, 3, 315, 302, 9, 3, 0, 0, 146318192, 1075807568, -1073743880, 137843170, 146125816, 3, 313, 147556952, 0, 15066597, 3,
+ -1, 147350500, 1, 0, 146319268}}
+ now = 16069
+ someReady = 0
+ #14 0x084cff54 in Dispatch () at dispatch.c:379
+ clientReady = (int *) 0xbffff944
+ result = 0
+ client = 0x8c8c2e0
+ nready = -1
+ icheck = (HWEventQueuePtr *) 0x8b45c68
+ start_tick = 940
+ #15 0x084e763c in main (argc=2, argv=0xbffffe04, envp=0xbffffe10) at main.c:469
+ i = 1
+ j = 2
+ k = 2
+ error = -1073742332
+ xauthfile = 0xbfffffba "/root/.Xauthority"
+ alwaysCheckForInput = {0, 1}
+ (gdb) quit</pre>
+
+<p>In the example above, you can see I used <kbd>bt full -7</kbd> to get the
+"outermost" seven stack frames, complete with local variable information,
+where available. Your stack trace may vary. We want to see all the stack
+frames <em>below</em> (numbered greater than) <code class="other"><signal
+handler called></code> in the list. If you get confused, just send us the
+output of <kbd>bt full</kbd> (with no number after it) and we'll sort it
+out.</p>
+
+<p>Generally speaking, such stack traces are extremely helpful for finding the
+cause of server crashes.</p>
+
+<h3><a id="debugmesadri">How can I help debug 3D acceleration
+problems?</a></h3>
+
+<p><em>Thanks to Michel Dänzer for his help writing this entry.</em></p>
+
+<p>Sometimes it's not always clear where the cause of a given problem lies,
+especially when it comes to 3D-accelerated applications. This is because the X
+server, the Mesa GL library, and the Linux kernel must all cooperate to
+implement DRI (Direct Rendering Infrastructure) correctly.</p>
+
+<p>To help narrrow down which piece of technology is reponsible for the problem,
+try the following steps:</p>
+
+<ol>
+ <li>
+ <p>Try to reproduce the problem by running the troublesome application from
+ a shell prompt in a terminal window with the following environment variables
+ set:</p>
+ <pre>LIBGL_ALWAYS_INDIRECT=1; export LIBGL_ALWAYS_INDIRECT
+LIBGL_DEBUG=verbose; export LIBGL_DEBUG</pre>
+ <p>Setting <code class="other">LIBGL_DEBUG=verbose</code> helps to ensure
+ that indirect rendering is actually being used. Note that if it is, there
+ will <em>not</em> be any special output, whereas if it's not (that is, if
+ DRI is being used), you will see output like:</p>
+ <pre>libGL: XF86DRIGetClientDriverName: 4.0.1 r200 (screen 0)
+libGL: OpenDriver:
+trying /home/michdaen/src/mesa-cvs/Mesa/lib/r200_dri.so
+drmOpenByBusid: Searching for BusID pci:0000:00:10.0
+drmOpenDevice: node name is /dev/dri/card0
+drmOpenDevice: open result is 4, (OK)
+drmOpenByBusid: drmOpenMinor returns 4
+drmOpenByBusid: drmGetBusid reports pci:0000:00:10.0</pre>
+ <p>If the problem is reproducible with indirect rendering, then there is
+ likely a problem with the GL library itself. Use the command <kbd>dpkg -S
+ /usr/lib/libGL.so.1</kbd> to determine which package provides your GL
+ library, and file a bug report against it (or skip the middleman and use
+ <kbd>reportbug --file /usr/lib/libGL.so.1</kbd>).</p>
+ <p>On the other hand, if the problem goes away when indirect rendering is
+ used, then one of the following is at fault:</p>
+ <ul>
+ <li>the hardware-neutral parts of DRI</li>
+ <li>the Mesa DRI module for your display adapter</li>
+ <li>the Linux DRM module for your display adapter</li>
+ <li>your display adapter (i.e., a hardware bug that either Mesa or Linux
+ should try to work around, if possible)</li>
+ </ul>
+ </li>
+ <li>
+ <p>To rule out problems with the hardware-neutral parts of DRI, remove the
+ <code class="package">xlibmesa-dri</code> package if it is installed, and
+ disable the <code class="other">Load "dri"</code> line in your <code
+ class="filespec">/etc/X11/XF86Config-4</code> file. There are two ways to
+ do the latter; you can run <kbd>dpkg-reconfigure xserver-xfree86</kbd> and
+ remove <code class="other">dri</code> from the list of modules to be loaded,
+ or you can simply open <code class="filespec">/etc/X11/XF86Config-4</code>
+ with your favorite text editor and comment the line out by putting a hash
+ mark (<kbd>#</kbd>) at the beginning of it.</p>
+ <p>If doing the above resolves the problem but the previous step did not,
+ you have found a problem in the hardware-neutral part of DRI; file a bug
+ against <code class="package">xserver-xfree86</code> and report your
+ findings.</p>
+ <p>You can of course reinstall the <code class="package">xlibmesa-dri</code>
+ package if you removed it, and if you so desire.</p>
+ </li>
+ <li>
+ <p>Occassionally people find that problems with 3D acceleration appear and
+ disappear as they switch between Linux kernel versions. (This has
+ particularly been seen in the 2.6.<em>x</em> kernel series.) While
+ aggressive switching of kernel versions is not a process for the faint of
+ heart, if you have upgraded your kernel recently but have not upgraded
+ XFree86, and are finding that X has "suddenly broken" despite not being
+ upgraded, you're most likely dealing with a Linux kernel problem. Try
+ downgrading your Linux kernel to the version you were using before to
+ confirm the fact; if you can confirm it, file a bug against <code
+ class="package">kernel</code> and report your findings.</p>
+ </li>
+ <li>
+ <p>If the problem does not appear to be Linux-kernel-related (or you can't
+ determine this one way or the other), the problem is not reproducible
+ with DRI disabled, and:</p>
+ <ul>
+ <li>you have the <code class="package">xlibmesa-dri</code> package
+ installed, then file your bug report against <code
+ class="package">xlibmesa-dri</code>.</li>
+ <li>you don't have the <code class="package">xlibmesa-dri</code> package
+ installed, then file your bug report against <code
+ class="package">xserver-xfree86</code>.</li>
+ </ul>
+ </li>
+</ol>
+
<h2><a id="acknowledgements">Acknowledgements</a></h2>
<p>The author would like to thank Andreas Metzler, Guillem Jover, Ingo Saitz,
Osamu Aoki, Matthew Arnison, Colin Walters, Steve Swales, Adam Jackson, Thomas
Dickey, Paul Gotch, Albert Cahalan, Denis Barbier, Jeff Licquia, Fabio Massimo
-Di Nitto, Andrew Suffield, Frank Murphy, Marc-Aurèle Darche, and "ulisses" for
-their contributions to this document.</p>
+Di Nitto, Andrew Suffield, Frank Murphy, Marc-Aurèle Darche, Michel Dänzer
+and "ulisses" for their contributions to this document.</p>
<hr />
<p class="x-small">$Id$</p>
Reply to: