First, go through the basic questions of TroubleShooting.
If you are using packages from your distribution, send the bug reports to your distribution and not directly to us.
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.
Bugs in the 3D driver are under product “Mesa”, component “Drivers/DRI/nouveau” (statistics). 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
add the following to the kernel command line: log_buf_len=1M
- exercise your problem
run the command: dmesg > kernel_log.txt
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.