Date: Wed, 13 Sep 2000 08:46:00 +0200
From: Harald Dunkel <harri@synopsys.COM>
How can I submit a bug report to be added to this list?
I *try* to follow bug reports sent to Linux-kernel, but if you want to
be sure, send it directly to me (tytso@mit.edu).
(And now for the standard spiel of developers everywhere.)
[ This has been explicitly cc'ed to Richard Gooch so he can add it to
the linux-kernel FAQ (http://www.tux.org/lkml/). There is a section
about bug reporting, but it's a bit thin. The old-kernel-faq maintained
by Frohwalt Egerer has a lot more to say on this topic; what follows
below has taken some ideas and lists from the old faq. ]
Please follow general good bug reporting guidelines: Remember, the
developers don't have access to your system, and they're not mind
readers. Tell us which kernel version, and what your hardware is (if
you're not sure, more details is better than less). At the very least,
tell us what processor and motherboard you have, how much memory, how
many and what kind of disks (IDE, SCSI, etc.), what kind of disk
controllers you have, what other expansion boards (specify whether
they're PCI or ISA or some other bus). Also useful: what version of gcc
and binutils were used to compile the kernel.
Try to find a simple, reliable way to trigger the problem. Telling the
developer that they have to set up some complicated application
environment (especially if it involves some ghastly expensive
proprietary software like SAP or Oracle :-) may cause the
developer to hit the 'd' key and move on.
In general, raw data is better than jumping to conclusions. If you want
to give your guesses in your bug reports, they're of course welcome, but
this is *not* a substitute for raw data. Many problems are not what
they first seem. A hardware problem can masquerade as a VM problem. A
device driver or VM problem can cause the filesystem code to notice a
discrepancy, and flag a warning. Even if you're *sure* that the problem
isn't a hardware problem, or by some other theory that the developer
advances, the scientific method demands that you do a test to rule these
sorts of things out. Sometimes, you will get surprised.....
If you get a kernel oops message, it's useless unless you give us the
proper symbolic information. This used to mean sending relevant pieces
out of System.map. Fortunately, with the latest syslogd/klogd, this is
much simpler (check the man page of klogd to see if your version has
this feature; if it doesn't, you should upgrade to the latest version,
and probably to a modern distribution). Make sure that you have the
System.map file installed the appropriate place so that klogd can find
it (the standard search path is in the /boot, /, and /usr/src/linux
directories).
If the system oops and then dies without a chance for klogd to record
the information into a syslog file, copy down the oops message exactly,
and then use the ksymoops (see the man page) to get the symbolic
information out. Remember, the raw numbers by themselves will generally
not be useful.
If you can, try to isolate the problem to a specific kernel version.
Knowledge that it worked in version 2.2.17, as well as 2.3.0-test6, but
it stopped working in 2.3.0-test7-pre1, is extremely helpful, and will
save developers a lot of time. (If you're comfortable disecting
patches, fell free, taking apart the individual file changes and try to
isolate to a particular change.)
- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Sep 15 2000 - 21:00:21 EST