Re: proc_stack for x86_64 (spinning process)

[Nuno Fernandes <npf-mlists@eurotux.com>]

On Tuesday 08 April 2008 12:21:53 Andi Kleen wrote:
> Nuno Pais Fernandes <npf@eurotux.com> writes:
> > Hi,
> >
> > I have a spinning process that it's locking my server (eating 100% CPU).
> > I can't kill it even with kill -9
> >
> > I'm trying to use proc_stack to check what's the problem, compiling the
> > kernel with
> >
> > http://linuxhacker.ru/~nikita/patches/2.6.12-rc6/2005.06.11/vm_07-proc-st
> >ack.patch
> >
> > But this patch is only for x86 as my arch is x86_64. Does anyone know if
> > there's a patch for x86_64?
>
> The standard way to handle that is to just do
>
> echo 1 > /proc/sys/kernel/sysrq
> echo t > /proc/sysrq-trigger
>
> and then look for the process backtrace in the kernel log.
I've already done that but the problem is that the "R" script does not show 
any backtrack. Apparently it's spinning inside kernel and all other processes 
become in D state (uninterrutable sleep) because of that one.

Apr  7 15:22:03 app14 kernel: comentarios   R  running task       0  7615   
8051                     (NOTLB)
Apr  7 15:22:03 app14 kernel: comentarios   D ffffff80e2570030     0  8150   
7328                     (NOTLB)
Apr  7 15:22:03 app14 kernel: ffffff80cc8bfcf8 0000000000000282 
00000000f69539c0 ffffff80eea385b0
Apr  7 15:22:03 app14 kernel:        ffffff80e2570030 000000000011d7be 
001769ecf4f60e59 ffffff8000e26030
Apr  7 15:22:03 app14 kernel:        ffffff80e25702c8 0000000000000000
Apr  7 15:22:03 app14 kernel: Call 
Trace:<ffffffffa011d4fd>{:ocfs2:ocfs2_dentry_revalidate+369}
Apr  7 15:22:03 app14 kernel:        <ffffffff8018149e>{do_lookup+419} 
<ffffffff80292e6b>{__down+147}
Apr  7 15:22:03 app14 kernel:        
<ffffffff8012b177>{default_wake_function+0} 
<ffffffff80187f0a>{lease_alloc+96}
Apr  7 15:22:03 app14 kernel:        <ffffffff802945cf>{__down_failed+53} 
<ffffffff801c9faf>{dummy_inode_permission+0}
Apr  7 15:22:03 app14 kernel:        
<ffffffff801c9faf>{dummy_inode_permission+0} 
<ffffffff80174017>{.text.lock.open+5}
Apr  7 15:22:03 app14 kernel:        <ffffffff8018ba2e>{__d_lookup+287} 
<ffffffff80181096>{get_write_access+62}
Apr  7 15:22:03 app14 kernel:        <ffffffff80182fd4>{may_open+481} 
<ffffffff80183340>{open_namei+788}
Apr  7 15:22:03 app14 kernel:        <ffffffff80173c22>{filp_open+80} 
<ffffffff8018a91d>{dput+56}
Apr  7 15:22:03 app14 kernel:        <ffffffff801e8195>{strncpy_from_user+74} 
<ffffffff8011f62c>{sys32_open+54}
Apr  7 15:22:03 app14 kernel:        <ffffffff8011d178>{ia32_sysret+0}

Thanks,
Nuno Fernandes

> Another alternative is to use crash to take a live dump and then analyse
> that using crash.
>
> -Andi