(→‎All bug reports: Two more journalctl instances to adjust for Fedora 22)

(23 intermediate revisions by 4 users not shown)

Line 9:

Line 9:

=== What driver am I using? ===

=== What driver am I using? ===

−

If you do not know already, try to find out what video driver you are using. Examine the file {{filename|/var/log/Xorg.0.log}}. Quite early on, you will see some lines like this:

+

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>

<pre>

(II) VESA(0): initializing int10

(II) VESA(0): initializing int10

Line 21:

Line 21:

* 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.

* 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.

−

−

* Several drivers in Fedora use kernel mode setting (whereby the detection and selection of the output resolution and refresh rate is done in the kernel rather than the video card driver) by default. Some of those can also function without kernel mode setting. As of Fedora 13, only the ''radeon'' driver still allows both kernel and userspace mode setting. For Fedora 12, the ''intel'' and ''nouveau'' drivers also allowed both modes of operation. If you are using the ''radeon'' driver in Fedora 13, or the ''intel'', ''nouveau'' or ''radeon'' driver in Fedora 12, you can switch to userspace mode setting by booting with the parameter <tt>nomodeset</tt> added to the kernel command line. If this improves matters, your problem is a ''KMS-related issue'', and you should include the information outlined in the [[Xorg/Debugging#KMS|appropriate section]] further down this page. If booting with the parameter <tt>nomodeset</tt> added to the kernel command line worsens matters, please do not file a report on this, as the userspace mode setting path is no longer actively supported for drivers which use KMS by default.

* If you experience a "lockup", please distinguish what kind of lockup you are seeing. There are three major categories:

* If you experience a "lockup", please distinguish what kind of lockup you are seeing. There are three major categories:

Line 36:

Line 34:

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

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

−

* All of the X server log file(s): {{filename|/var/log/Xorg.*.log}}

+

* All of the X server log messages: {{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). 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 and run {{command|<nowiki>journalctl -e _COMM=gdm-x-session</nowiki>}} (Fedora 22+), {{command|<nowiki>journalctl -b-1 -e _COMM=Xorg.bin</nowiki>}} (Fedora 21) or {{command|<nowiki>journalctl -b-1 -e _COMM=Xorg</nowiki>}} (Fedora 20 and earlier). The {{code|-b-1}} asks for the output from the previous boot; you can adjust it as desired if you need logs from more than one boot ago, {{code|-b-2}} etc.

−

* Your [http://smolts.org/ smolt profile]. You can dump it to {{filename|/tmp/smoltprofile.txt}} with the following command: {{command|smoltSendProfile -p > /tmp/smoltprofile.txt}}

+

* 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.

+

* 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}}

−

* {{filename|/var/log/Xorg.0.log}} from a trial run where you move your {{filename|xorg.conf}} aside and let Xorg autodetect your hardware (if you have such a file).

+

* 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 (please add <code>drm.debug=14 log_buf_len=16M</code> as boot parameters and reboot) especially in case of crashes and using KMS.

+

* 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

−

* content of {{filename|/var/log/gdm/}} ''only'' in cases there is nothing interesting in {{filename|/var/log/Xorg.*.log}} and {{command|dmesg}} 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...) ===

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

Line 49:

Line 47:

* A screenshot showing the problem if at all possible.

* A screenshot showing the problem if at all possible.

−

{{Anchor|KMSInfo}}

+

==== Intel-specific ====

−

=== KMS-related issues ===

+

−

As well as the information from [[Xorg/Debugging#AllInfo|the 'all bug reports' section]], include the following information:

* Boot with the parameters <code>drm.debug=14 log_buf_len=16M</code> added to the kernel command line, reboot and attach {{filename|/var/log/messages}}, output of the {{command|dmesg}} command, and {{filename|/var/log/Xorg.0.log}} to your bug report.

+

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).

−

* Also, if the driver for your card supports it (currently only radeon), boot with the parameter <code>nomodeset</code> added to the kernel command line and attach {{filename|/var/log/Xorg.0.log}} to your bug report.

+

−

* Explain how the behaviour differs when KMS is disabled, and whether both cases are problematic (but different), or whether the non-KMS case is what you consider to be the correct behavior.

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.

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).

+

{{Anchor|3DInfo}}

{{Anchor|3DInfo}}

Line 76:

Line 70:

* 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)

* 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.

* 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 ==

== 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.

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.

−

−

== Debugging problems with Intel graphics adapters ==

−

−

If you are suffering from problems with an Intel graphics adapter such as failure of X to start at all, hangs or freezes or crashes in the graphical environment, display corruption, failure of 3D accelerated applications to work properly or similar problems, and your issue is not specifically covered elsewhere on this page, the following general advice may be of use.

−

−

First, make sure you have applied all system updates, in case the problem has already been fixed.

−

−

In Fedora 12 and earlier, several such issues may be worked around by disabling kernel mode setting. To do this, add

−

<pre>

−

nomodeset

−

</pre>

−

as a kernel parameter. If this solves your problem, please check whether a bug has already been reported for it, and if not, [https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=xorg-x11-drv-intel file a new bug report] on the ''xorg-x11-drv-intel'' component, explaining your symptoms, and providing all the usual information required for X.org bug reports, as indicated above. In Fedora 13 and later kernel mode setting will be the only available method, and so we wish to ensure all problems caused by kernel mode setting are fixed.

−

−

If this does not resolve your issue, one other potential workaround (for Fedora 12 only) is to change to a different acceleration method. To do this, add a line:

−

<pre>

−

Option "AccelMethod" "EXA"

−

</pre>

−

or:

−

<pre>

−

Option "AccelMethod" "XAA"

−

</pre>

−

to the Device section of {{filename|/etc/X11/xorg.conf}}. If that file does not exist, see [[How_to_create_xorg.conf]] for instructions on how to create it. Again, if doing this works around the problem you are experiencing, please check whether a bug report on the problem has already been filed, and if not, please [https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=xorg-x11-drv-intel file a new bug report] on the ''xorg-x11-drv-intel'' component, explaining your symptoms, and providing all the usual information required for X.org bug reports as indicated above. These legacy acceleration methods will be removed in future, so any bugs in the new acceleration method (UXA) need to be fixed.

−

−

== Debugging ATI / AMD graphics adapters ==

−

−

If you are experiencing failure to start the graphical desktop, hanging or freezing, corruption, or slow performance with an ATI / AMD graphics adapter, you may try the following.

−

−

First, make sure you have applied all system updates; some known bugs have been fixed.

−

−

Some issues may be worked around by disabling kernel mode setting. To do this, add

−

<pre>

−

nomodeset

−

</pre>

−

as a kernel parameter. If this solves your problem, please check whether a bug has already been reported for it, and if not, [https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=xorg-x11-drv-ati file a new bug report] on the ''xorg-x11-drv-ati'' component, explaining your symptoms, and providing all the usual information required for X.org bug reports. In future kernel mode setting will be the only available method, and so we wish to ensure all problems caused by kernel mode setting are fixed.

−

−

If this does not resolve your issue, one other potential workaround is to change to a different acceleration method. To do this, add a line:

−

<pre>

−

Option "AccelMethod" "XAA"

−

</pre>

−

to the Device section of {{filename|/etc/X11/xorg.conf}}. If that file does not exist, see [[How_to_create_xorg.conf]] for instructions on how to create it. Again, if doing this works around the problem you are experiencing, please check whether a bug report on the problem has already been filed, and if not, please [https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=xorg-x11-drv-ati file a new bug report] on the ''xorg-x11-drv-ati'' component, explaining your symptoms, and providing all the usual information required for X.org bug reports, as indicated above. These legacy acceleration methods will be removed in future, so any bugs in the new acceleration method (EXA) need to be fixed.

−

−

If this does not resolve your issue, there is another configuration option to try. Add a line:

−

<pre>

−

Option "AccelDFS" "off"

−

</pre>

−

to the Device section of {{filename|/etc/X11/xorg.conf}}. If that file does not exist, see [[How_to_create_xorg.conf]] for instructions on how to create it. Again, if doing this works around the problem you are experiencing, please check whether a bug report on the problem has already been filed, and if not, please [https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=xorg-x11-drv-ati file a new bug report] on the ''xorg-x11-drv-ati'' component, explaining your symptoms, and providing all the usual information required for X.org bug reports as indicated above.

−

−

Finally, if this still does not resolve your issue, try adding this line:

−

<pre>

−

Option "DRI" "off"

−

</pre>

−

to the Device section of {{filename|/etc/X11/xorg.conf}}. Again, if doing this works around the problem you are experiencing, please check whether a bug report on the problem has already been filed, and if not, please [https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=xorg-x11-drv-ati file a new bug report] on the ''xorg-x11-drv-ati'' component, explaining your symptoms, and providing all the usual information required for X.org bug reports, as indicated above.

== Input devices ==

== Input devices ==

Line 139:

Line 82:

== Stack traces ==

== Stack traces ==

−

You will need a stack trace if your X server crashes. You should be able to submit one to bugzilla by running <code>abrt-gui</code> ''as root'' and selecting the relevant crash (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.

+

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]]

[[Category:Debugging|X]] [[Category:How to]]

Latest revision as of 09:44, 3 March 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.

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.

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).

All of the X server log messages: journalctl -e _COMM=gdm-x-session (Fedora 22+), journalctl -e _COMM=Xorg.bin (Fedora 21) or journalctl -e _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 and run journalctl -e _COMM=gdm-x-session (Fedora 22+), journalctl -b-1 -e _COMM=Xorg.bin (Fedora 21) or journalctl -b-1 -e _COMM=Xorg (Fedora 20 and earlier). The -b-1 asks for the output from the previous 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

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).

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

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.