Documentation: Update to BUG-HUNTING

Signed-off-by: Ian McDonald <imcdnzl@gmail.com> Signed-off-by: Adrian Bunk <bunk@stusta.de>

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