X Troubleshooting Scenarios

The following scenarios represent just a small sample of what users can experience with the X server. The overall goal in any X troubleshooting situation is to break down the X server into its individual layers to isolate the problem.

Scenario 15-1: Xauthority

A user uses ssh with the -X option, which is supposed to enable X forwarding. However, when the user connects to the remote machine and issues the command to start his application, he receives an error regarding authentication failure. To troubleshoot the issue, we use the best-known testing program, which in this case is an X native command such as xterm, xclock, xosview, or another located in /usr/bin/x.

The user connects to a remote machine through ssh and attempts to start his application.

[root@local ]# ssh -X -l root remote Last login: Fri Aug 19 10:43:37 2005 from 15.50.74.102 [root@remote root]#  xclock X11 connection rejected because of wrong authentication. X connection to localhost:11.0 broken (explicit kill or server shutdown).

Notice that the connection is to localhost:11.0. With ssh forwarding, it uses display 11 for all X forwarding; however, the problem is not with ssh. The problem is with "authentication." Checking the man page on Xsecurity, the only file that really deals with security at this layer is .Xauthority, which is located in the user's home directory.

Upon using the xuath command to list the contents of the file, we see the problem:

xauth> info Authority file:       /root/.Xauthority File new:             no File locked:          no Number of entries:    0 Changes honored:      yes Changes made:         no Current input:        (stdin):3 The file has no entries?

After using the command mkxauth -c to re-create the MIT-MAGIC-COOKIE-1 entries for the host, we see the following:

xauth> info Authority file:       /root/.Xauthority File new:             no File locked:          no Number of entries:    2 Changes honored:      yes Changes made:         no Current input:        (stdin):2 xauth> list remote/unix:0  MIT-MAGIC-COOKIE-1  1eb06f066004088c76e619255ac28cfd remote:0  MIT-MAGIC-COOKIE-1  1eb06f066004088c76e619255ac28cfd

When we retry the xclock program, it shows up on our local display.

Scenario 15-2: The X Server Does Not Start on the Second Head of a Dual-Display Video Card

The user tries to get the X server to start and use both heads of the dual-head video card, but she receives an error. When attempting to start the X server, she receives the following message:

# X X Window System Version 6.8.1 Release Date: 17 September 2004 X Protocol Version 11, Revision 0, Release 6.8.1 Build Operating System: Linux 2.6.3-4 i686 [ELF] Current Operating System: Linux gamer 2.6.3-4 #1 Tue Mar 2 07:26:13 CET 2004 i686 ...  (==) Log file: "/var/log/Xorg.0.log", Time: Mon Aug 15 00:35:19 2005 (==) Using config file: "/etc/X11/xorg.conf" (EE) MGA: Failed to load module "mga_hal" (module does not exist, 0) (EE) MGA: Failed to load module "mga_hal" (module does not exist, 0) (EE) MGA(1): This card requires the "mga_hal" module for dual-head operation         It can be found at the Matrox web site <http://www.matrox.com> (EE) MGA(0): [drm] DRIScreenInit failed.  Disabling DRI. Could not init font path element /usr/X11R6/lib/X11/fonts/local, removing from list! Could not init font path element /usr/X11R6/lib/X11/fonts/CID, removing from list!

Just in reading the standard output from the server, we can see that there are two problems: The dual display is not working because of missing drivers, and hardware acceleration is not working (Direct Rendering Infrastructure).

Because this user is trying to run the latest Xorg X server, we download the latest kernel, kernel source, and X server source. Further research proves that the latest Matrox drivers are included with the Xorg server release. The README file states that we must make modifications to the xc/config/cf/ xf86site.def file. We also install the latest kernel and go to work on compiling the X server.

The following is a small portion of the file that we must uncomment:

... /*  * If you have the HALlib source code installed in    xfree86/drivers/mga/hallib,  * uncomment this:  */ #define BuildMatroxHal          YES ... Executed: # make World > compiling.out 2>&1

Thirty-plus minutes later, with no errors the compile is complete. We perform a make install, which installs the latest compiled version of the Xorg server. An example of the new X server follows.

# X X Window System Version 6.8.2 Release Date: 9 February 2005 X Protocol Version 11, Revision 0, Release 6.8.2 Build Operating System: Linux 2.6.8-24-default i686 [ELF] Current Operating System: Linux gamer 2.6.8-24-default #1 Wed Oct 6 09:16:23 UTC 2004 i686 Build Date: 17 August 2005         Before reporting problems, check http://wiki.X.Org         to make sure that you have the latest version. Module Loader present Markers: (--) probed, (**) from config file, (==) default setting,         (++) from command line, (!!) notice, (II) informational,         (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Thu Aug 18 00:48:59 2005 (==) Using config file: "/etc/X11/xorg.conf" (EE) MGA(0): [drm] DRIScreenInit failed.  Disabling DRI. (EE) MGA(1): Not initializing the DRI on the second head

The user states that now she has the display on the second head and that she would like to have better performance through hardware acceleration. Taking a look at the log file, we find the answer to why we could not get hardware acceleration to work when running in dual-head mode.

# cat /var/log/Xorg.0.log ... (II) MGA(0): [drm] bpp: 32 depth: 24 (II) MGA(0): [drm] Sarea 2200+664: 2864 (WW) MGA(0): Direct rendering is not supported when Xinerama is enabled (EE) MGA(0): [drm] DRIScreenInit failed.  Disabling DRI. ...

In the current release, direct rendering simply is not supported when operating dualhead display, or Xinerama. To give some idea of how much performance the hardware acceleration would bring, we run the famous test program called glxgears, which runs at around 312 frames per second when Xinerama is enabled. After disabling it and restarting the X server, we enable DRI and the Matrox card, and the user achieves over 750 frames per second. There are other ways to measure X performance. One common way is by using the x11perf command in combination with the Xmark script to interrupter the x11perf results.