nouveau/ Bugs

First, go through the basic questions of TroubleShooting.

If you are using packages from your distribution and are unable/unwilling to test the latest versions of all the pieces of nouveau, send the bug reports to your distribution and not directly to us. If you're using an out-of-date software version, our first question will probably be "does it still happen on latest".

We use Gitlab issues. Bugs in the 2D driver and the Nouveau DRM (kernel) part are filed under drm/nouveau. Feel free to submit bugs about 2D implementation, but please search the issue list before submitting new bugs. If you are not sure your bug is a manifestation of an existing bug report, do open a new bug.

Bugs in the 3D driver are filed under mesa/mesa (see all nouveau issue reports). Please, check MesaDrivers page before submitting any reports.

How to report?

  • Attach complete, unfiltered, untrimmed kernel log from the boot up to and including the problem, and a complete X log if the problem manifests with X. Note, that /var/log/messages is not a kernel log. Running dmesg is the best way to get a kernel log, but assuming, that the log buffer has not wrapped around.
  • Please, do not compress files you attach to bug reports, especially plain text files such as logs, unless the file is so huge bugzilla refuses to take it. Gzipping files makes taking a quick look impossible
  • Make sure the mime-type of text files really is set to text/plain, and not e.g. application/octet-stream or text/x-log. This makes life a little easier for people reading bug reports. The point is to let people read text files directly in a web browser.
  • Please include version numbers or checkout dates for all relevant components. This could be the kernel and DRM, x-server, xf86-video-nouveau, libdrm and possibly mesa.
  • Do not use links that go invalid in time (e.g., pastebins, image bins, your web server at home), attach your files to the bug instead. Bug reports may be useful even after years.
  • If the bug is related to modesetting, output configuration, etc, please attach VBIOS from your card. We also have a mailing list where you can ask questions, discuss patches or whatever is related to nouveau and its tools.

Getting a kernel log

Quick guide

  1. add the following to the kernel command line: log_buf_len=1M
  2. exercise your problem
  3. run the command: dmesg > kernel_log.txt
  4. use the file kernel_log.txt created above in your bug report, remember to set the MIME type to text/plain in bugzilla/email attachment

Explanation

The best way is to use dmesg command and direct the output to a file. A problem with dmesg is, that it uses the kernel log buffer, which may wrap around. Therefore, use log_buf_len=1M on the kernel command line to increase the log buffer size to 1MB. The wraparound can be noticed by looking at the first lines in a dmesg output, it should be something like this (may vary according to kernel version): 

[    0.000000] Linux version 2.6.34-gentoo-r1 (root@localhost) (gcc version 4.3.4 (Gentoo 4.3.4 p1.1, pie-10.1.5) ) #1 PREEMPT Mon Aug 2 16:04:12 EEST 2010
[    0.000000] Command line: root=/dev/sda5
[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
[    0.000000]  BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)

The benefits of using dmesg command are:

  • you get all kernel messages, also from debug level
  • you get only kernel messages, without noise from user space like in system logger files
  • you get messages from this boot only, no need to cut other boots out of the file
  • it is what the developers expect to see It is really the command dmesg to be used. A file like /var/log/dmesg.log or similar is not what we need.