Re: [BUG] linux-next: April 10 - kernel oops at kmem_cache_alloc () regression from April 9 kernel

!MAILaRCHIVE_VOTE_RePLACE
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Suresh Siddha <suresh.b.siddha@...>
Cc: Stephen Rothwell <sfr@...>, <linux-next@...>, LKML <linux-kernel@...>, Ingo Molnar <mingo@...>, Andy Whitcroft <apw@...>, <akpm@...>
Date: Monday, April 14, 2008 - 9:14 am

Suresh Siddha wrote:
Hi,

When I tried reproducing the problem on another machine with gcc 4.1.2, the goes into a loop with 
the following call trace. Will try and reproduce on the same machine, which was causing the panic.

[    0.000000] Initializing cgroup subsys cpuset

[    0.000000] Linux version 2.6.25-rc8-next-20080411-autokern1 (root@elm3b63.beaverton.ibm.com) (gcc version 4.1.2 20071124 (Red Hat 4.1.2-41)) #1 SMP PREEMPT Mon Apr 14 08:31:54 EDT 2008
.
.
.
<snip>
.
.
[    3.059347] request_module: runaway loop modprobe binfmt-464c
[    3.065238] request_module: runaway loop modprobe binfmt-464c
[    3.071106] request_module: runaway loop modprobe binfmt-464c
[    3.077242] request_module: runaway loop modprobe binfmt-464c
[    3.085556] request_module: runaway loop modprobe binfmt-464c
[    3.169430] khelper used greatest stack depth: 2884 bytes left
[    3.224149] khelper used greatest stack depth: 2864 bytes left
[    3.358136] khelper used greatest stack depth: 2844 bytes left
[    3.384146] khelper used greatest stack depth: 2780 bytes left
[    3.692012] khelper used greatest stack depth: 2744 bytes left
[    4.470665] khelper used greatest stack depth: 2716 bytes left
[    4.714540] khelper used greatest stack depth: 2700 bytes left
[    5.632645] khelper used greatest stack depth: 2616 bytes left
[   37.306789] khelper used greatest stack depth: 2596 bytes left
[  279.173966] INFO: task swapper:1 blocked for more than 240 seconds.
[  279.180375] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  279.188421] swapper       D 00000001  2376     1      0
[  279.196385]        f7844cc0 00000046 f7844c78 00000001 c06ed24c f7880000 f7846000 f7846190 
[  279.205829]        c4ab1700 00000007 00000000 fffeddc1 c0511054 373dd61a 000000ab ffffffff 
[  279.215036]        ffffffff ffffffff ffffffff 00000000 00000000 00000000 7fffffff 7fffffff 
[  279.224236] Call Trace:
[  279.227087]  [<c03c2c36>] schedule_timeout+0x16/0x8b
[  279.233650]  [<c023f674>] trace_hardirqs_on+0xb/0xd
[  279.240270]  [<c023f648>] trace_hardirqs_on_caller+0xe1/0x102
[  279.246470]  [<c023f674>] trace_hardirqs_on+0xb/0xd
[  279.254471]  [<c03c2423>] wait_for_common+0xda/0x139
[  279.259650]  [<c021ba97>] default_wake_function+0x0/0xd
[  279.266715]  [<c03c2504>] wait_for_completion+0x12/0x14
[  279.273332]  [<c0230e90>] call_usermodehelper_exec+0x7f/0xbf
[  279.279212]  [<c023119e>] request_module+0xce/0xe0
[  279.285587]  [<c023da76>] put_lock_stats+0xd/0x21
[  279.292211]  [<c023dada>] lock_release_holdtime+0x50/0x56
[  279.298064]  [<c028250f>] search_binary_handler+0x189/0x1c2
[  279.306064]  [<c02a5388>] load_script+0x0/0x188
[  279.311048]  [<c02a54fd>] load_script+0x175/0x188
[  279.315960]  [<c0208268>] __cycles_2_ns+0x14/0x35
[  279.322499]  [<c023da76>] put_lock_stats+0xd/0x21
[  279.329116]  [<c023dada>] lock_release_holdtime+0x50/0x56
[  279.334967]  [<c02823fc>] search_binary_handler+0x76/0x1c2
[  279.342968]  [<c0282404>] search_binary_handler+0x7e/0x1c2
[  279.348668]  [<c02a5388>] load_script+0x0/0x188
[  279.355034]  [<c02835ff>] do_execve+0x125/0x17b
[  279.359763]  [<c020273b>] sys_execve+0x29/0x4d
[  279.366382]  [<c0203c36>] syscall_call+0x7/0xb
[  279.371027]  [<c028007b>] set_anon_super+0x2d/0xa0
[  279.376268]  [<c0206b83>] kernel_execve+0x17/0x1c
[  279.382811]  [<c0201147>] run_init_process+0x17/0x19
[  279.389438]  [<c02011a8>] init_post+0x5f/0xc3
[  279.394243]  [<c0203c8e>] restore_nocheck_notrace+0x0/0xe
[  279.401485]  [<c0204833>] kernel_thread_helper+0x7/0x10
[  279.408103]  =======================



-- 
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
--
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
linux-next: Tree for April 10, Stephen Rothwell, (Thu Apr 10, 4:14 am)
Re: linux-next: Tree for April 10 (arch/x86), Randy Dunlap, (Thu Apr 10, 6:09 pm)
Re: linux-next: Tree for April 10 (arch/x86), Ingo Molnar, (Fri Apr 11, 3:46 am)
Re: linux-next: Tree for April 10 (arch/x86), Randy Dunlap, (Fri Apr 11, 11:19 am)
Re: linux-next: Tree for April 10 (arch/x86), Jakub Jelinek, (Mon Apr 14, 4:40 am)
Re: linux-next: Tree for April 10 (arch/x86), Randy Dunlap, (Mon Apr 14, 6:28 pm)
Re: linux-next: Tree for April 10 (arch/x86), Al Viro, (Fri Apr 11, 11:26 am)
Re: linux-next: Tree for April 10 (arch/x86), Ingo Molnar, (Mon Apr 14, 4:12 am)
Re: linux-next: Tree for April 10 (arch/x86), Al Viro, (Mon Apr 14, 4:22 am)
Re: linux-next: Tree for April 10 (arch/x86), Ingo Molnar, (Mon Apr 14, 4:34 am)
Re: linux-next: Tree for April 10 (arch/x86), Jakub Jelinek, (Mon Apr 14, 4:43 am)
Re: linux-next: Tree for April 10 (arch/x86), Al Viro, (Mon Apr 14, 5:30 am)
Re: linux-next: Tree for April 10 (arch/x86), David Miller, (Mon Apr 14, 5:37 am)
Re: linux-next: Tree for April 10 (ftrace), Randy Dunlap, (Thu Apr 10, 6:07 pm)
Re: linux-next: Tree for April 10: generic pci_enable_resour..., Mariusz Kozlowski, (Thu Apr 10, 3:34 pm)
Re: linux-next: Tree for April 10: generic pci_enable_resour..., Stephen Rothwell, (Mon Apr 14, 12:49 am)
[BUG] linux-next: April 10 - kernel oops at kmem_cache_all..., Kamalesh Babulal, (Thu Apr 10, 2:07 pm)
Re: [BUG] linux-next: April 10 - kernel oops at kmem_cache..., Kamalesh Babulal, (Mon Apr 14, 9:14 am)
Re: linux-next: Tree for April 10, Greg KH, (Thu Apr 10, 1:42 pm)
Re: [BUG] linux-next: Tree for April 10 - kernel panic while..., Bartlomiej Zolnierkiewicz..., (Thu Apr 10, 8:03 am)
Re: [BUG] linux-next: Tree for April 10 - kernel panic while..., Bartlomiej Zolnierkiewicz..., (Thu Apr 10, 1:14 pm)
Re: [BUG] linux-next: Tree for April 10 - kernel panic while..., Bartlomiej Zolnierkiewicz..., (Thu Apr 10, 3:16 pm)