Hi there,
Resubmitting this to try and help others not repeat the mistakes I've made :-)
Signed-off-by: Ian McDonald: <[email protected]>
----
diff --git a/Documentation/BUG-HUNTING b/Documentation/BUG-HUNTING
index ca29242..8b117de 100644
--- a/Documentation/BUG-HUNTING
+++ b/Documentation/BUG-HUNTING
@@ -1,3 +1,56 @@
+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 [email protected] (Larry McVoy)]
This 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 hel
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.
On Thu, 23 Feb 2006 08:47:39 +1300 Ian McDonald wrote:
> Hi there,
Lo,
> +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.
or that you are having problems with.
> +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".
Maybe add this:
You can also take the "Code:" <object code> and feed it as bytes into a
.S (assembly) source file, assemble that, then objdump the .o file.
This is especially useful if the "Code:" line is one of the best clues
that you have. Andi Kleen has a script for doing this. It's called
'decodecode' and it's available from
ftp://ftp.firstfloor.org/pub/ak/shell/decodecode
---
~Randy
On Fri, 24 Feb 2006 12:09:47 +1300 Ian McDonald wrote:
> Randy/Denis,
>
> > > +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.
> > or that you are having problems with.
> >
> >
> Both of your e-mails are excellent extra info and would be useful
> addition. It will take me a little while to merge as focussing on
> other things.
>
> Can we perhaps have this merged and then add to it so we get something
> in? Unless somebody else wants to do it and sort through the advice
> (e.g. we don't need 2.4 tips in a 2.6 kernel...)
OK with me, but it's really up to Adrian or Andrew.
---
~Randy