From Fedora Project Wiki

fp-wiki>ImportUser
(Imported from MoinMoin)
 
(revise X log stuff again to account for Xorg.0.log still existing in some cases)
 
(85 intermediate revisions by 14 users not shown)
Line 1: Line 1:
== Xorg Debugging ==
'''Foreword'''


If you are experiencing a problem with Xorg, please see the [[Bugs/Common|common bugs]] document before filing a bug. Some easy configuration tweaks that fix a wide range of issues are listed there. If the problem you are seeing is not listed there or none of the workarounds seem to help, please consider filing a bug to help us make Fedora run better on your hardware.


Did you know, that all of the modular X packages now come with
Be prepared to include some information (logs) about your system as well. These should be complete (no snippets please), not in an archive, uncompressed, with MIME type set as text/plain.
full debuginfo packages, including the X server and driver modules?


The X server uses dlopen now also, so it can be debugged using
== Identifying your problem area ==
the stock gdb that comes with Fedora.


In order to debug the running X server, install the debuginfo
=== What driver am I using? ===
packages for it, and any drivers you are loading.  You then
need to have 2 computers[1]  networked together, or using a serial
port or some other remote access method.


Edit the xorg.conf file, and enable the option:
If you do not know already, try to find out what video driver you are using. Examine the output of {{command|<nowiki>journalctl -e _COMM=gdm-x-session</nowiki>}} (Fedora 22+), {{command|<nowiki>journalctl -e _COMM=Xorg.bin</nowiki>}} (Fedora 21) or {{command|<nowiki>journalctl -e _COMM=Xorg</nowiki>}} (Fedora 20 and earlier). Quite early on, you will see some lines like this:
<pre>
(II) VESA(0): initializing int10
(II) VESA(0): Bad V_BIOS checksum
</pre>
The word in capital letters after (II) is the name of the driver in use (so, in this case, the word is VESA, indicating the ''vesa'' driver is in use). Drivers are packaged with the name ''xorg-x11-drv-(name)'', so the ''vesa'' driver is in the package {{package|xorg-x11-drv-vesa}}.


Option "NoTrapSignals"
If you are using a driver with the name ''nvidia'' (not ''nv'' or ''nouveau'') or ''fglrx'', you are using a proprietary third-party video driver (respectively, the proprietary drivers provided by NVIDIA and AMD/ATI). Please do not report any bugs in these drivers to Fedora, as we do not provide or support these drivers. Report bugs either to the place where you got these drivers, or to NVIDIA or AMD.


Then, enable coredumps on the system, if you have not done so
=== What area might the problem be in? ===
already, by using "ulimit -c unlimited" in a script dropped into
/etc/profile.d/enable-coredumps.sh  or whatever.  Be sure to run
the script or log out and back in.


As the X server is a setuid root process, and the kernel will not
* If the problem in question occurs when using 3D-accelerated applications - for instance, Blender, or 3D-accelerated games - the problem is a ''3D acceleration issue'', and you should include the information outlined in the [[Xorg/Debugging#3DInfo|appropriate section]] further down this page.
allow coredumps of SUID processes by default, you have 2 choices.


You can tweak the kernel to permit SUID coredumps by doing:
* If you experience a "lockup", please distinguish what kind of lockup you are seeing.  There are three major categories:
** Mouse moves, and cursor still changes when moving over window borders.  This is usually a bug in the window manager's state machine where it doesn't let go of a grab in the X server.
** Mouse moves, but cursor does not change.  This is usually the X server being stuck far away from the dispatch loop (position updates happen asynchronously, but glyph updates do not), either waiting on the kernel or in an infinite loop.  The X server will probably print a message in the log about the event queue overflowing when this happens; this is _not_ the bug, it is merely the symptom.
** Mouse doesn't move.  This is the X server being stuck, usually in the kernel (which will not show a backtrace in the X log, but will probably show something in dmesg) but occasionally in an internal deadlock with the cursor update code disabled (which will often show up as a backtrace in the X log).


echo 1 > /proc/sys/kernel/core_setuid_ok
== Information to include in your report ==


or you can run the X server as root.  If you enable the kernel to
{{Anchor|AllInfo}}
allow SUID coredumps as per above, just be sure to disable it
=== All bug reports ===
afterwards by echoing '0' to the same file, to avoid potential
security issues.


Now you are ready to break things and debug them.  I prefer to
In all cases, the following should be attached to your bug report:
start the X server with "startx" all the time, but particularly
when debugging.  I recommend doing the same, unless the problem
you are debugging only occurs when using gdm/kdm/xdm, as it tends
to be much simpler to debug with startx.  YMMV however.


If the server crashes, you can gdb the coredump now. Assuming
* All of the X server log messages. Depending on your login manager, these may be in the system journal or in the file {{filename|/var/log/Xorg.0.log}}. If {{filename|/var/log/Xorg.0.log}} exists and has a recent date stamp, attach it. Otherwise, you can find the messages from the journal with:
you installed debuginfo packages for the server (make sure the
** {{command|<nowiki>journalctl -b _COMM=gdm-x-session</nowiki>}} (Fedora 22+)
debuginfo package is the same version-release as the server that
** {{command|<nowiki>journalctl -b _COMM=Xorg.bin</nowiki>}} (Fedora 21)
is installed), you should get useful backtraces, etc.
** {{command|<nowiki>journalctl -b _COMM=Xorg</nowiki>}} (Fedora 20 and earlier)
** If you cannot use the system in the affected configuration, but you can use it some other way (e.g. with {{code|nomodeset}} or a different kernel), first boot the affected configuration and reproduce the bug, then boot the unaffected configuration. If your system logs to {{filename|/var/log/Xorg.0.log}}, boot to runlevel 3 the second time, so the file does not get overwritten, and attach it. If your system logs to the journal, run the command given above, except with {{code|-b-1}} instead of {{code|-b}}. {{code|-b-1}} asks for the output from the previous boot rather than the output from the current boot; you can adjust it as desired if you need logs from more than one boot ago, {{code|-b-2}} etc.
* The output of the command {{command|su -c 'lspci -nn'}}
* If you use a {{filename|xorg.conf}}, please include it in the bug report, otherwise, please specify in the bug report that it does not exist. Usually this would be located at {{filename|/etc/X11/xorg.conf}}, but see the xorg.conf manpage - {{command|man xorg.conf}} - for other standard locations. Also include any files in the directory {{filename|/etc/X11/xorg.conf.d}}
* X log messages from a trial run where you move your {{filename|xorg.conf}} aside and let Xorg autodetect your hardware (if you have such a file)
* output of the {{command|dmesg}} command after adding the boot parameters {{code|<nowiki>drm.debug=14 log_buf_len=16M</nowiki>}} and rebooting, especially in case of crashes. If you cannot run {{command|dmesg}} in the affected configuration, but you can boot an unaffected configuration, boot the affected configuration with the parameters, then boot the unaffected configuration, run {{command|journalctl -b-1}} and attach that output
* Details of your monitor configuration: what monitors you have connected to what ports (e.g. VGA, DVI, HDMI...). Please note if you are using a display switcher


If you want to debug the running server, single step it, etc.,
=== Rendering problems (unreadable text, corrupted display...) ===
you need the second computer[1]  mentioned above. Do all the same
steps as above, but this time, ssh in from the remote computer
(or use minicom on serial port or whatever), and get the PID
of the X server with 'pidof X'.  Then attach gdb to the X server:


gdb --pid=$(pidof X)
As well as the information from [[Xorg/Debugging#AllInfo|the 'all bug reports' section]], include the following information:


Now go to town!  Find the bug, install the X server/driver sources,
* A screenshot showing the problem if at all possible.
fix the bug, generate a patch with gendiff, and attach it to a bug
report. It's really that simple!!!  ;oP


This informative message has been brought to you by the Red Hat
==== Intel-specific ====
X Development team, and Frank's Red Hot Chile & Lime Hot Sauce.


Have fun!
For intel display setup issues (outputs shaky or not lighting up):
* collect and attach the video ROM for the chip: {{command|<nowiki>su -c 'dd if=/dev/mem of=/tmp/rom bs=64k skip=12 count=1'</nowiki>}}
* collect and attach the opregion data: {{command|su -c 'mount -t debugfs debugfs /sys/kernel/debug' ; cp /sys/kernel/debug/dri/*/i915_opregion /tmp/opregion}}
* Collect and attach a register snapshot from the broken configuration: {{command|su -c 'intel_reg_snapshot > /tmp/snapshot'}}


The command {{command|intel_reg_snapshot}} is provided by the {{package|intel-gpu-tools}} package.  Note that you may need to {{command|ssh}} into the machine in order to collect this information. In some cases {{command|intel_reg_snapshot}} might fail to run, then please provide output of {{filename|intel_reg_dumper}} (if possible, both before and after you see the issue).


[1]  The reason that 2 computers are required, is that if you start
For errors indicating a GPU hang:
the X server, open an xterm and run gdb on the running X server,
* collect and attach the GPU error state: {{command|su -c 'mount -t debugfs debugfs /sys/kernel/debug' ; cp /sys/kernel/debug/dri/0/i915_error_state /tmp}}
gdb will stop the X server, and try to print to stdout.  Since
stdout is your xterm, and xterm is displaying to the X server which
is now no longer responding because gdb stopped it, you are screwed.
It's kindof like trying to stand on a carpet, and then pull it out
from under yourself.  You can't really do it.  This is why you
need[2]  2 computers.


[2] Ok, it is technically possible to do it with one computer too,
You may find [https://01.org/linuxgraphics/documentation/how-report-bugs-0 the upstream intel driver bug filing instructions] useful - much of the information from them is contained here, but there may be additional ideas there.
but it is complex enough to not really bother trying to do, so
 
don't even waste time thinking of it. If you don't have 2
{{Anchor|3DInfo}}
computers, go dumpster diving at 3am in the garbage dumpster of
 
a computer store. They throw out good stuff I'm told, and you
=== 3D acceleration issues ===
can have a "X server debugging terminal" in no time, like everyone
 
else on the block. Alternatively, surf ebay.com for a bargain, or
As well as the information from [[Xorg/Debugging#AllInfo|the 'all bug reports' section]], include the following information:
hang out at a computer recycling shop.
 
* Output of the command {{command|glxinfo}} (if this is not installed, install the package {{package|glx-utils}})
* A screenshot, if possible (if the system has crashed but the display on screen is something other than just blank, take a picture with a digital camera and attach that)
* Information as to whether or not other OpenGL applications are able to run without problems.
* Console output from running the application with LIBGL_DEBUG=verbose. For instance, if the bug is in the application ''glxgears'', you would run {{command|LIBGL_DEBUG<nowiki>=</nowiki>verbose glxgears}} from a console, reproduce the problem, and attach any output from the console
 
== Creating a xorg.conf ==
 
If you need to make manual changes to X configuration, you will need to [[How_to_create_xorg.conf|create a xorg.conf]] file if it doesn't already exist.
 
== Input devices ==
 
Debugging of input devices is covered by [[Xorg/Input_Triage_Algorithm|a special wiki page]].
 
== Stack traces ==
 
You will need a stack trace if your X server crashes. You should be able to submit one to bugzilla by running '''Automatic Bug Reporting Tool''' ({{command|gnome-abrt}}) and selecting the relevant crash from '''System''' crashes (if abrtd was running and noticed the crash). If not, see the [http://wiki.x.org/wiki/Development/Documentation/ServerDebugging documentation] on the upstream wiki.
 
[[Category:Debugging|X]] [[Category:How to]]

Latest revision as of 01:10, 14 April 2015

Foreword

If you are experiencing a problem with Xorg, please see the common bugs document before filing a bug. Some easy configuration tweaks that fix a wide range of issues are listed there. If the problem you are seeing is not listed there or none of the workarounds seem to help, please consider filing a bug to help us make Fedora run better on your hardware.

Be prepared to include some information (logs) about your system as well. These should be complete (no snippets please), not in an archive, uncompressed, with MIME type set as text/plain.

Identifying your problem area

What driver am I using?

If you do not know already, try to find out what video driver you are using. Examine the output of journalctl -e _COMM=gdm-x-session (Fedora 22+), journalctl -e _COMM=Xorg.bin (Fedora 21) or journalctl -e _COMM=Xorg (Fedora 20 and earlier). Quite early on, you will see some lines like this: 

(II) VESA(0): initializing int10
(II) VESA(0): Bad V_BIOS checksum

The word in capital letters after (II) is the name of the driver in use (so, in this case, the word is VESA, indicating the vesa driver is in use). Drivers are packaged with the name xorg-x11-drv-(name), so the vesa driver is in the package xorg-x11-drv-vesa.

If you are using a driver with the name nvidia (not nv or nouveau) or fglrx, you are using a proprietary third-party video driver (respectively, the proprietary drivers provided by NVIDIA and AMD/ATI). Please do not report any bugs in these drivers to Fedora, as we do not provide or support these drivers. Report bugs either to the place where you got these drivers, or to NVIDIA or AMD.

What area might the problem be in?

  • If the problem in question occurs when using 3D-accelerated applications - for instance, Blender, or 3D-accelerated games - the problem is a 3D acceleration issue, and you should include the information outlined in the appropriate section further down this page.
  • If you experience a "lockup", please distinguish what kind of lockup you are seeing. There are three major categories:
    • Mouse moves, and cursor still changes when moving over window borders. This is usually a bug in the window manager's state machine where it doesn't let go of a grab in the X server.
    • Mouse moves, but cursor does not change. This is usually the X server being stuck far away from the dispatch loop (position updates happen asynchronously, but glyph updates do not), either waiting on the kernel or in an infinite loop. The X server will probably print a message in the log about the event queue overflowing when this happens; this is _not_ the bug, it is merely the symptom.
    • Mouse doesn't move. This is the X server being stuck, usually in the kernel (which will not show a backtrace in the X log, but will probably show something in dmesg) but occasionally in an internal deadlock with the cursor update code disabled (which will often show up as a backtrace in the X log).

Information to include in your report

All bug reports

In all cases, the following should be attached to your bug report:

  • All of the X server log messages. Depending on your login manager, these may be in the system journal or in the file /var/log/Xorg.0.log. If /var/log/Xorg.0.log exists and has a recent date stamp, attach it. Otherwise, you can find the messages from the journal with:
    • journalctl -b _COMM=gdm-x-session (Fedora 22+)
    • journalctl -b _COMM=Xorg.bin (Fedora 21)
    • journalctl -b _COMM=Xorg (Fedora 20 and earlier)
    • If you cannot use the system in the affected configuration, but you can use it some other way (e.g. with nomodeset or a different kernel), first boot the affected configuration and reproduce the bug, then boot the unaffected configuration. If your system logs to /var/log/Xorg.0.log, boot to runlevel 3 the second time, so the file does not get overwritten, and attach it. If your system logs to the journal, run the command given above, except with -b-1 instead of -b. -b-1 asks for the output from the previous boot rather than the output from the current boot; you can adjust it as desired if you need logs from more than one boot ago, -b-2 etc.
  • The output of the command su -c 'lspci -nn'
  • If you use a xorg.conf, please include it in the bug report, otherwise, please specify in the bug report that it does not exist. Usually this would be located at /etc/X11/xorg.conf, but see the xorg.conf manpage - man xorg.conf - for other standard locations. Also include any files in the directory /etc/X11/xorg.conf.d
  • X log messages from a trial run where you move your xorg.conf aside and let Xorg autodetect your hardware (if you have such a file)
  • output of the dmesg command after adding the boot parameters drm.debug=14 log_buf_len=16M and rebooting, especially in case of crashes. If you cannot run dmesg in the affected configuration, but you can boot an unaffected configuration, boot the affected configuration with the parameters, then boot the unaffected configuration, run journalctl -b-1 and attach that output
  • Details of your monitor configuration: what monitors you have connected to what ports (e.g. VGA, DVI, HDMI...). Please note if you are using a display switcher

Rendering problems (unreadable text, corrupted display...)

As well as the information from the 'all bug reports' section, include the following information:

  • A screenshot showing the problem if at all possible.

Intel-specific

For intel display setup issues (outputs shaky or not lighting up):

  • collect and attach the video ROM for the chip: su -c 'dd if=/dev/mem of=/tmp/rom bs=64k skip=12 count=1'
  • collect and attach the opregion data: su -c 'mount -t debugfs debugfs /sys/kernel/debug' ; cp /sys/kernel/debug/dri/*/i915_opregion /tmp/opregion
  • Collect and attach a register snapshot from the broken configuration: su -c 'intel_reg_snapshot > /tmp/snapshot'

The command intel_reg_snapshot is provided by the intel-gpu-tools package. Note that you may need to ssh into the machine in order to collect this information. In some cases intel_reg_snapshot might fail to run, then please provide output of intel_reg_dumper (if possible, both before and after you see the issue).

For errors indicating a GPU hang:

  • collect and attach the GPU error state: su -c 'mount -t debugfs debugfs /sys/kernel/debug' ; cp /sys/kernel/debug/dri/0/i915_error_state /tmp

You may find the upstream intel driver bug filing instructions useful - much of the information from them is contained here, but there may be additional ideas there.

3D acceleration issues

As well as the information from the 'all bug reports' section, include the following information:

  • Output of the command glxinfo (if this is not installed, install the package glx-utils)
  • A screenshot, if possible (if the system has crashed but the display on screen is something other than just blank, take a picture with a digital camera and attach that)
  • Information as to whether or not other OpenGL applications are able to run without problems.
  • Console output from running the application with LIBGL_DEBUG=verbose. For instance, if the bug is in the application glxgears, you would run LIBGL_DEBUG=verbose glxgears from a console, reproduce the problem, and attach any output from the console

Creating a xorg.conf

If you need to make manual changes to X configuration, you will need to create a xorg.conf file if it doesn't already exist.

Input devices

Debugging of input devices is covered by a special wiki page.

Stack traces

You will need a stack trace if your X server crashes. You should be able to submit one to bugzilla by running Automatic Bug Reporting Tool (gnome-abrt) and selecting the relevant crash from System crashes (if abrtd was running and noticed the crash). If not, see the documentation on the upstream wiki.

Retrieved from "https://fedoraproject.org/w/index.php?title=How_to_debug_Xorg_problems&oldid=409755"