From ee3f81faf899409c5a680b90fe9d4e09c2249473 Mon Sep 17 00:00:00 2001 From: Richard Kennedy Date: Wed, 6 Feb 2008 01:38:01 -0800 Subject: [PATCH] --- yaml --- r: 83479 b: refs/heads/master c: dcc85cb61808098d22792db95f1dfa9c8b3bcf6d h: refs/heads/master i: 83477: 496b40836979934e50d31e062eb89abf24720152 83475: 88964404ed7023c422ee5a706d595b209275f82a 83471: c9cb9c3c32f4b8f3bcdda5fddc4afef72c4e2fc2 v: v3 --- [refs] | 2 +- trunk/Documentation/BUG-HUNTING | 17 +++++++++++++++++ 2 files changed, 18 insertions(+), 1 deletion(-) diff --git a/[refs] b/[refs] index 81c1882c5eae..be250692dd8d 100644 --- a/[refs] +++ b/[refs] @@ -1,2 +1,2 @@ --- -refs/heads/master: 844fcc53962d781aab7c164acbfa46505427375e +refs/heads/master: dcc85cb61808098d22792db95f1dfa9c8b3bcf6d diff --git a/trunk/Documentation/BUG-HUNTING b/trunk/Documentation/BUG-HUNTING index 6c816751b868..65022a87bf17 100644 --- a/trunk/Documentation/BUG-HUNTING +++ b/trunk/Documentation/BUG-HUNTING @@ -214,6 +214,23 @@ And recompile the kernel with CONFIG_DEBUG_INFO enabled: gdb vmlinux (gdb) p vt_ioctl (gdb) l *(0x
+ 0xda8) +or, as one command + (gdb) l *(vt_ioctl + 0xda8) + +If you have a call trace, such as :- +>Call Trace: +> [] :jbd:log_wait_commit+0xa3/0xf5 +> [] autoremove_wake_function+0x0/0x2e +> [] :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
+ 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