summaryrefslogtreecommitdiff
path: root/TroubleShooting.mdwn
diff options
context:
space:
mode:
authorJoe Rayhawk <jrayhawk@freedesktop.org>2013-05-13 18:26:44 -0700
committerJoe Rayhawk <jrayhawk@freedesktop.org>2013-05-13 18:26:44 -0700
commit8a40a1534f48c123974dec7398b5470498500483 (patch)
tree8e876d8d8a8db79a7517d693dc091077d726e49b /TroubleShooting.mdwn
parent3a5733ac773de34a4b6e9f612ba1a99f081e5fcf (diff)
moin2mdwn: convert page TroubleShooting
Diffstat (limited to 'TroubleShooting.mdwn')
-rw-r--r--TroubleShooting.mdwn195
1 files changed, 195 insertions, 0 deletions
diff --git a/TroubleShooting.mdwn b/TroubleShooting.mdwn
new file mode 100644
index 0000000..7dbaa7d
--- /dev/null
+++ b/TroubleShooting.mdwn
@@ -0,0 +1,195 @@
+
+
+# Troubleshooting Nouveau
+
+The troubleshooting guide below is generic and not specific to any distribution. Linux distributions may have their own troubleshooting guides, which are easier to work with, if you use the distribution and its features (packages, configuration helpers, etc.) instead of the manual work assumed below.
+
+* [[Ubuntu's Nouveau troubleshooting wiki page|https://wiki.ubuntu.com/X/Troubleshooting/Nouveau]]
+
+## The Basic Questions
+
+If you have any problems with Nouveau, it does not work, it is slow, Xv is not available, or whatever, check these things first, please.
+
+1. Are you clear of other kernel drivers that break Nouveau?
+ * Some kernel drivers make Nouveau misbehave and must not be used, e.g.: `nvidia.ko` (the proprietary driver), rivafb, nvidiafb - more information can be found in [[KernelModeSetting|KernelModeSetting]]. Look in your kernel log and `lsmod` output for any sign of these and disable them. If you cannot find a kernel module anywhere, but it still magically loads, maybe it is in your initramfs.
+1. Is the Nvidia proprietary driver not interfering with Nouveau?
+ * Make sure you do not have the proprietary driver installed. Files, that (may) come from the proprietary driver, are: `nvidia.ko`, `nvidia_drv.so`, `libGL.so`, `libGLcore.so`, `libglx.so`. Uninstall the proprietary driver, and if necessary, reinstall Xorg (`libglx.so`) and Mesa (GL libraries) to get back the standard libraries. The X log (usually `/var/log/Xorg.0.log`) can tell you, if some of the loaded components come from Nvidia. No component should come from the vendor Nvidia. Also see Step 1 for `nvidia.ko`.
+1. Did you compile fbcon into the kernel, or compile it as a module and loaded it?
+ * First make sure you have `CONFIG_FRAMEBUFFER_CONSOLE` enabled in your kernel configuration. If it is a module (it is called `fbcon.ko`), make sure it is loaded. Otherwise activating KMS will make your console screen unusable, but your system should still work otherwise, including X.
+1. Is X using the right driver (DDX)?
+ * Do not use `nv` driver in X. Use `nouveau` instead. If you do not explicitly tell X to use `nouveau` in `xorg.conf`, it will usually default to `nv`, or maybe even `nvidia` (the proprietary driver). Any X driver (e.g. `vesa`) other than `nouveau` or `fbdev` will cause problems with KMS.
+1. Is your X configuration sane?
+ * Try the minimalistic 4-line `xorg.conf` file from [[InstallNouveau|InstallNouveau]] page. That will solve most of the X configuration errors, bad monitor display modes, bad frequencies, etc.
+1. Are you using the latest code?
+ * Make sure you use the latest available Nouveau code from the git repositories listed in [[Source|Source]]: DDX, DRM and Nouveau kernel. And this **really means GIT**, not your just distribution's latest package. ** _GIT_ as of _TODAY_ **. Kernel.org git repositories do not count, use the freedesktop.org repositories. As long as Nouveau is in staging in the Linux kernel, the user space ABI can break. This means that the git version of libdrm or DDX does not work with the kernel.org version of Nouveau code, until the changes flow upstream.
+Nouveau requires at least version 1.8.0 of xorg-server, and [[KernelModeSetting|KernelModeSetting]] (activated by default).
+
+
+## Frequently Encountered Problems
+
+[[!toc ]]
+
+
+### Xorg fails to start with "(EE) [drm] failed to open device"
+
+Your DDX does not work with your current kernel and/or libdrm. There are at least three possible reasons for this: the nouveau DRM kernel module is not loaded, a version mismatch between the Nouveau DRM and libdrm, or [[KMS|KernelModeSetting]] being disabled.
+
+First check, that `lsmod` command lists `nouveau`. If not, do `modprobe nouveau` to load the nouveau DRM kernel module, and check the kernel log for possible errors.
+
+If the kernel module `nouveau` is loaded according to `lsmod` command, but there are no kernel messages about nouveau at all, then most likely Nouveau KMS is disabled. This prevents the driver to work at all. Possible places to disable KMS are:
+
+* kernel command line with: `nomodeset`, `drm.modeset=0`, `nouveau.modeset=0` or similar
+* modprobe.conf or modprobe.d/ adding the module options `drm modeset=0` or `nouveau modeset=0`
+* initramfs carrying the above module options
+Check and remove all those that you may find, and retry.
+
+Libdrm vs. nouveau DRM module version incompatibilites are another source of problems. See that you use compatible versions, or better, everything from git from the same date. For instance, if you are using a 2.6.33 kernel from kernel.org , that nouveau code is not compatible with libdrm 2.4.18 or git. Either upgrade nouveau drm code (see [[InstallDRM|InstallDRM]]) or use an old git version of libdrm and DDX, 2010-02-15 or older.
+
+The problem can also happen the other way around, with a libdrm too old compared to the other components. If you built libdrm yourself, the system' libdrm could still be used to load the nouveau X11 driver. Just run the ldd command on nouveau_drv.so to check the libdrm and libdrm_nouveau libraries listed there are the ones you installed, and not the system ones.
+
+Here is an example with libdrm compiled and installed to /usr/local:
+
+ * [[!format txt """
+$ ldd /usr/lib/xorg/modules/drivers/nouveau_drv.so
+...
+ libdrm_nouveau.so.1 => /usr/local/lib/libdrm_nouveau.so.1 (0x00007f3cca1bc000)
+ libdrm.so.2 => /usr/local/lib/libdrm.so.2 (0x00007f3cc9c5c000)
+...
+"""]]
+
+### Cannot insert drm.ko, "duplicated symbol"
+
+If you're compiling nouveau out-of-tree, make sure that you have not set `CONFIG_DRM` to yes in your kernel config.
+
+
+### Inserting nouveau.ko fails
+
+`drm.ko` needs to be inserted first. Make sure you are inserting the `drm.ko` that was built at the same time as `nouveau.ko`. Your kernel might provide another `drm.ko` which is incompatible.
+
+
+### Compiling xf86-video-nouveau fails: No nouveau_drm.h found.
+
+Make sure that `nouveau_drm.h` lies in a path which can be found by your compiler. You do not have to install it for that. To build the drm tree without installing it, use
+[[!format txt """
+./configure --prefix=$PWD/install
+make install
+export PKG_CONFIG_PATH=$PWD/install
+cd ../your-checkout-of-xf86-videou-nouveau
+sh autogen.sh
+make
+"""]]
+
+### Undefined symbol "GlxSetVisualConfigs"
+
+`X: symbol lookup error: nouveau_drv.so: undefined symbol: GlxSetVisualConfigs`
+ You may need to `Load "glx"`, or you may still have the nvidia GLX driver installed, and need to use the xorg one instead. Often the nvidia module will be /usr/lib/xorg/modules/libglx.so, with the original xorg glx in /usr/lib/xorg/modules/extensions/libglx.so, in which case you can just move the nvidia .so out of the way.
+
+
+### Syntax error near unexpected token RANDR
+
+`syntax error near unexpected token RANDR` when running `./configure` on xf86-video-nouveau means that you are probably missing X development libraries. (On Ubuntu, try `apt-get install xorg-dev`; on Fedora, `yum install xorg-x11-server-sdk`) You may also have to re-run autogen.sh to regenerate configure.
+
+Note! This can also happen if you have built Xorg using git as per [[xorg modular build|http://wiki.x.org/wiki/ModularDevelopersGuide#head-c35264aacf77e77caeca305a1a9a3da3be6e4fa5]] instructions.
+
+The issue arises as automake cannot find the xorg m4 macros as when using the modular build example, the xorg aclocal m4 files will be installed in a non-standard location. To fix up this issue, first locate your default aclocal directory - use this command to find it:
+[[!format txt """
+aclocal --print-ac-dir
+"""]]
+In this directory, create a file called 'dirlist'. This file can contain paths to alternate aclocal directories, one per line. Add the directory location to the xorg aclocal directory, e.g. /usr/X11R7/share/aclocal
+
+automake will now find the xorg m4 macros, and the syntax error should be fixed.
+
+
+### 2D acceleration in Nouveau is unbearably slow
+
+Before Nouveau required xorg-server 1.7 there were few issues, but the only known thing left now is:
+
+* you are using OpenGL: all OpenGL is software rendered, hence slow. If your desktop environment, e.g. KDE4, is using OpenGL to render the window and the desktop, it will be terribly slow. KDE4 can be configured to use Xrender instead of OpenGL.
+If this does not help, see if there are any errors in your kernel or Xorg logs, and consult the [[Bugzilla|http://bugs.freedesktop.org]].
+
+
+### Latest git Xorg (from around April 24th 2008) doesn't build libGLcore.so
+
+This is a slight gotcha. From around the end of April, 2008, libGLcore.so is now built from the latest git mesa tree.
+
+* To build:
+Build xorg normally. Build mesa normally (make linux-dri e.g.). Now to build libGLcore.so in mesa tree:
+
+
+[[!format txt """
+ make glcore
+ make glcore-install
+"""]]
+This creates and installs libGLcore.so in your xorg system location: ...X11R7/lib/modules/dri/libGLcore.so
+
+
+### Xorg: nouveau_dri.so is missing (AIGLX error)
+
+In the Xorg log you get:
+[[!format txt """
+(EE) AIGLX error: dlopen of /usr/lib64/dri/nouveau_dri.so failed (/usr/lib64/dri/nouveau_dri.so: cannot open shared object file: No such file or directory)
+(EE) AIGLX: reverting to software rendering
+"""]]
+This is good, because `nouveau_dri.so` is the Gallium3D driver, and as you know, it is in development and not supported. It would only bring trouble, especially with AIGLX. To silence the harmless warning, you can add the following to xorg.conf `ServerLayout` section:
+[[!format txt """
+Option "AIGLX" "false"
+"""]]
+
+### Kernel mode setting or X sets a bad or non-native display mode
+
+This could be due to your monitor not offering valid or any EDID information. The information is normally read using DDC. If the command `xrandr --prop` does not mention EDID for your monitor (output), then this is the case. Only a conservative default set of modes is available without an EDID.
+
+At the moment there is no manual way to give EDID information to the driver. X should still be able to reach the right display mode. You can try to create a modeline with the command `cvt`, and apply it using the commands `xrandr --newmode` followed by `xrandr --addmode`, and set it with `xrandr --output`. See `man cvt` and `man xrandr` on how to use these commands. See [[Randr12|Randr12]] and also [[here|http://wiki.debian.org/XStrikeForce/HowToRandR12]] for information on how to configure the same to into `xorg.conf` after you have found a suitable setting. If you have no `xorg.conf`, it may suffice to create one containing only the appropriate "Monitor" section.
+
+For the framebuffer console, you can use the `video=` kernel parameter, for instance `video=1280x1024`. For more information, see [[KernelModeSetting|KernelModeSetting]].
+
+Some kernels, possibly 2.6.28 and maybe even 2.6.29, contain a bug, that causes the DDC communication to randomly fail sometimes. In that case it is recommended to update your kernel. Updating DRM modules is not enough.
+
+
+### Kernel mode setting switches off monitor display, no more signal
+
+It means nouveau does not know how to program your video output. Check you do not have this message in kernel log file:
+[[!format txt """
+TMDS table revision x.y not currently supported
+"""]]
+If you have it, unfortunately, you will have to wait for someone to write support for it. For that, we will need you to make a [[dump of your video card bios|DumpingVideoBios]] and send it to mmio.dumps at gmail.com .
+
+
+### I get the "EQ overflowing" error
+
+"EQ overflowing" means the X server's input event queue is overflowing. It is not a bug, it is a symptom of something getting stuck. For a better explanation about what it is, see [[http://marc.info/?l=fedora-devel-list&m=124101535025331&w=2|http://marc.info/?l=fedora-devel-list&m=124101535025331&w=2]].
+
+When diagnosing your problem, you need to get a backtrace from the X server. At minimum, provide the complete X log, which has a backtrace. See [[Bugs|Bugs]].
+
+
+### The computer hangs or crashes
+
+See [[HangDiagnosis|HangDiagnosis]] for suggestions on what to do. The most important thing is to try to get the errors (hopefully) reported by the kernel. Otherwise diagnosing it is near impossible. For regressions, bisecting (with git) might provide valuable information.
+
+
+### Black, garbled, or otherwise useless framebuffer console display
+
+This is usually due to framebuffer driver hand-over failure. See [[KernelModeSetting|KernelModeSetting]] about hand-over and check your kernel configuration and logs as instructed.
+
+
+### 3D or OpenGL problems
+
+See [[MesaDrivers|MesaDrivers]].
+
+
+### Blank monitor, flicker, snow, or other random live image corruption
+
+If you use dual-head (two video outputs in use) or dual-link (a very high resolution monitor), and the VBIOS has too low clocks by default, the video memory bandwitdh will be insufficient for scanout. This can lead to a blank image, or live image corruption, that changes on every vertical refresh, and likely does not show up in screencaptures. For the monitor, this is not a case of an unsupported video mode but random video data.
+
+Raising the card performance mode might help. Ask on IRC, #nouveau channel, how to do that. Instructions are not given here, because in the worst case, it may destroy your card, because power management is still a work in progress.
+
+
+### My custom video mode is not effective
+
+If you use a digital output like DVI, Nouveau will use the monitor's native mode and convert your custom video mode to that, either by stretching or adding black borders. This is undesirable, if you really want to have your custom video mode (e.g. a 24 Hz mode) go to the wire.
+
+The solution is to disable scaling:
+[[!format txt """
+xrandr --output DVI-I-1 --set 'scaling mode' None
+"""]]
+Instead of DVI-I-1, use the output you have.