X-Git-Url: https://git.openpandora.org/cgi-bin/gitweb.cgi?p=pandora-kernel.git;a=blobdiff_plain;f=Documentation%2FBUG-HUNTING;h=65022a87bf17902f9e04fe5ecff611a41ffaf4d8;hp=35f5bd243336aeb1927f42483e26fa7586bcb205;hb=155b62716478a9328601cdd693824db0fc83aa6e;hpb=8269cc4e2b0ddcdcb9e7f2034c464ef8613737a1

diff --git a/Documentation/BUG-HUNTING b/Documentation/BUG-HUNTING
index 35f5bd243336..65022a87bf17 100644
--- a/Documentation/BUG-HUNTING
+++ b/Documentation/BUG-HUNTING
@@ -53,7 +53,7 @@ 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.  
+This is how to track down a bug if you know nothing about kernel hacking.
 It's a brute force approach but it works pretty well.
 
 You need:
@@ -66,12 +66,12 @@ You will then do:
 
         . Rebuild a revision that you believe works, install, and verify that.
         . Do a binary search over the kernels to figure out which one
-          introduced the bug.  I.e., suppose 1.3.28 didn't have the bug, but 
+          introduced the bug.  I.e., suppose 1.3.28 didn't have the bug, but
           you know that 1.3.69 does.  Pick a kernel in the middle and build
           that, like 1.3.50.  Build & test; if it works, pick the mid point
           between .50 and .69, else the mid point between .28 and .50.
         . You'll narrow it down to the kernel that introduced the bug.  You
-          can probably do better than this but it gets tricky.  
+          can probably do better than this but it gets tricky.
 
         . Narrow it down to a subdirectory
 
@@ -81,27 +81,27 @@ You will then do:
             directories:
 
                 Copy the non-working directory next to the working directory
-                as "dir.63".  
+                as "dir.63".
                 One directory at time, try moving the working directory to
-                "dir.62" and mv dir.63 dir"time, try 
+                "dir.62" and mv dir.63 dir"time, try
 
                         mv dir dir.62
                         mv dir.63 dir
                         find dir -name '*.[oa]' -print | xargs rm -f
 
                 And then rebuild and retest.  Assuming that all related
-                changes were contained in the sub directory, this should 
-                isolate the change to a directory.  
+                changes were contained in the sub directory, this should
+                isolate the change to a directory.
 
                 Problems: changes in header files may have occurred; I've
-                found in my case that they were self explanatory - you may 
+                found in my case that they were self explanatory - you may
                 or may not want to give up when that happens.
 
         . Narrow it down to a file
 
           - You can apply the same technique to each file in the directory,
-            hoping that the changes in that file are self contained.  
-            
+            hoping that the changes in that file are self contained.
+
         . Narrow it down to a routine
 
           - You can take the old file and the new file and manually create
@@ -130,7 +130,7 @@ You will then do:
             that makes the difference.
 
 Finally, you take all the info that you have, kernel revisions, bug
-description, the extent to which you have narrowed it down, and pass 
+description, the extent to which you have narrowed it down, and pass
 that off to whomever you believe is the maintainer of that section.
 A post to linux.dev.kernel isn't such a bad idea if you've done some
 work to narrow it down.
@@ -214,6 +214,23 @@ And recompile the kernel with CONFIG_DEBUG_INFO enabled:
   gdb vmlinux
   (gdb) p vt_ioctl
   (gdb) l *(0x<address of vt_ioctl> + 0xda8)
+or, as one command
+  (gdb) l *(vt_ioctl + 0xda8)
+
+If you have a call trace, such as :-
+>Call Trace:
+> [<ffffffff8802c8e9>] :jbd:log_wait_commit+0xa3/0xf5
+> [<ffffffff810482d9>] autoremove_wake_function+0x0/0x2e
+> [<ffffffff8802770b>] :jbd:journal_stop+0x1be/0x1ee
+> ...
+this shows the problem in the :jbd: module. You can load that module in gdb
+and list the relevant code.
+  gdb fs/jbd/jbd.ko
+  (gdb) p log_wait_commit
+  (gdb) l *(0x<address> + 0xa3)
+or
+  (gdb) l *(log_wait_commit + 0xa3)
+
 
 Another very useful option of the Kernel Hacking section in menuconfig is
 Debug memory allocations. This will help you see whether data has been