aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation/BUG-HUNTING
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation/BUG-HUNTING')
-rw-r--r--Documentation/BUG-HUNTING113
1 files changed, 113 insertions, 0 deletions
diff --git a/Documentation/BUG-HUNTING b/Documentation/BUG-HUNTING
index ca29242dbc38..65b97e1dbf70 100644
--- a/Documentation/BUG-HUNTING
+++ b/Documentation/BUG-HUNTING
@@ -1,3 +1,56 @@
1Table of contents
2=================
3
4Last updated: 20 December 2005
5
6Contents
7========
8
9- Introduction
10- Devices not appearing
11- Finding patch that caused a bug
12-- Finding using git-bisect
13-- Finding it the old way
14- Fixing the bug
15
16Introduction
17============
18
19Always try the latest kernel from kernel.org and build from source. If you are
20not confident in doing that please report the bug to your distribution vendor
21instead of to a kernel developer.
22
23Finding bugs is not always easy. Have a go though. If you can't find it don't
24give up. Report as much as you have found to the relevant maintainer. See
25MAINTAINERS for who that is for the subsystem you have worked on.
26
27Before you submit a bug report read REPORTING-BUGS.
28
29Devices not appearing
30=====================
31
32Often this is caused by udev. Check that first before blaming it on the
33kernel.
34
35Finding patch that caused a bug
36===============================
37
38
39
40Finding using git-bisect
41------------------------
42
43Using the provided tools with git makes finding bugs easy provided the bug is
44reproducible.
45
46Steps to do it:
47- start using git for the kernel source
48- read the man page for git-bisect
49- have fun
50
51Finding it the old way
52----------------------
53
1[Sat Mar 2 10:32:33 PST 1996 KERNEL_BUG-HOWTO lm@sgi.com (Larry McVoy)] 54[Sat Mar 2 10:32:33 PST 1996 KERNEL_BUG-HOWTO lm@sgi.com (Larry McVoy)]
2 55
3This is how to track down a bug if you know nothing about kernel hacking. 56This is how to track down a bug if you know nothing about kernel hacking.
@@ -90,3 +143,63 @@ it does work and it lets non-hackers help fix bugs. And it is cool
90because Linux snapshots will let you do this - something that you can't 143because Linux snapshots will let you do this - something that you can't
91do with vendor supplied releases. 144do with vendor supplied releases.
92 145
146Fixing the bug
147==============
148
149Nobody is going to tell you how to fix bugs. Seriously. You need to work it
150out. But below are some hints on how to use the tools.
151
152To debug a kernel, use objdump and look for the hex offset from the crash
153output to find the valid line of code/assembler. Without debug symbols, you
154will see the assembler code for the routine shown, but if your kernel has
155debug symbols the C code will also be available. (Debug symbols can be enabled
156in the kernel hacking menu of the menu configuration.) For example:
157
158 objdump -r -S -l --disassemble net/dccp/ipv4.o
159
160NB.: you need to be at the top level of the kernel tree for this to pick up
161your C files.
162
163If you don't have access to the code you can also debug on some crash dumps
164e.g. crash dump output as shown by Dave Miller.
165
166> EIP is at ip_queue_xmit+0x14/0x4c0
167> ...
168> Code: 44 24 04 e8 6f 05 00 00 e9 e8 fe ff ff 8d 76 00 8d bc 27 00 00
169> 00 00 55 57 56 53 81 ec bc 00 00 00 8b ac 24 d0 00 00 00 8b 5d 08
170> <8b> 83 3c 01 00 00 89 44 24 14 8b 45 28 85 c0 89 44 24 18 0f 85
171>
172> Put the bytes into a "foo.s" file like this:
173>
174> .text
175> .globl foo
176> foo:
177> .byte .... /* bytes from Code: part of OOPS dump */
178>
179> Compile it with "gcc -c -o foo.o foo.s" then look at the output of
180> "objdump --disassemble foo.o".
181>
182> Output:
183>
184> ip_queue_xmit:
185> push %ebp
186> push %edi
187> push %esi
188> push %ebx
189> sub $0xbc, %esp
190> mov 0xd0(%esp), %ebp ! %ebp = arg0 (skb)
191> mov 0x8(%ebp), %ebx ! %ebx = skb->sk
192> mov 0x13c(%ebx), %eax ! %eax = inet_sk(sk)->opt
193
194Another very useful option of the Kernel Hacking section in menuconfig is
195Debug memory allocations. This will help you see whether data has been
196initialised and not set before use etc. To see the values that get assigned
197with this look at mm/slab.c and search for POISON_INUSE. When using this an
198Oops will often show the poisoned data instead of zero which is the default.
199
200Once you have worked out a fix please submit it upstream. After all open
201source is about sharing what you do and don't you want to be recognised for
202your genius?
203
204Please do read Documentation/SubmittingPatches though to help your code get
205accepted.