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 FreeDesktop Bugzilla. Bugs in the 2D driver and the Nouveau DRM (kernel) part are filed under product “xorg”, component “Driver/nouveau” (statistics). Feel free to submit bugs about 2D implementation, but please search the bugzilla before submitting new bugs. If you are not sure your bug is a manifestation of an existing bug report, do open a new bug.
- 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/messagesis not a kernel log. Running
dmesgis 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.
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
- add the following to the kernel command line:
- exercise your problem
- run the command:
dmesg > kernel_log.txt
- use the file
kernel_log.txtcreated above in your bug report, remember to set the MIME type to
text/plainin bugzilla/email attachment
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
dmesgto be used. A file like
/var/log/dmesg.logor similar is not what we need.