Messages in this thread | | | From | devnull@spaans ... | Date | Wed, 13 Sep 2000 10:00:45 -0400 | Subject | Re: Update Linux 2.4 Status/TODO list |
| |
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/
| |