kdump regression compared to v2.6.35

Tejun Heo tj at kernel.org
Mon Aug 30 10:55:49 EDT 2010


On 08/30/2010 04:51 PM, CAI Qian wrote:
> kintegrityd   R  running task        0    13      2 0x00000008
>  ffffffffffffff10 ffffffff81078e25 0000000000000010 0000000000000206
>  ffff88046dcf1e40 0000000000000018 ffff88046dc9a440 ffff88046dc9a440
>  ffff88088e231f00 ffff88088e239300 ffff88046dcf1ee0 ffffffff810796e8
> Call Trace:
>  [<ffffffff81078e25>] ? worker_maybe_bind_and_lock+0x55/0xf0
>  [<ffffffff810796e8>] ? rescuer_thread+0x108/0x1d0
>  [<ffffffff810795e0>] ? rescuer_thread+0x0/0x1d0
>  [<ffffffff810795e0>] ? rescuer_thread+0x0/0x1d0
>  [<ffffffff8107fc06>] ? kthread+0x96/0xa0
>  [<ffffffff8100be84>] ? kernel_thread_helper+0x4/0x10
>  [<ffffffff8107fb70>] ? kthread+0x0/0xa0
>  [<ffffffff8100be80>] ? kernel_thread_helper+0x0/0x10
...
> runnable tasks:
>             task   PID         tree-key  switches  prio     exec-runtime         sum-exec        sum-sleep
> ----------------------------------------------------------------------------------------------------------
>          swapper     1       296.512617        23   120       296.512617       282.090606         0.046441 /
>      sync_supers    11       293.512617         2   120       293.512617         0.002502      5354.887736 /
> R    kintegrityd    13      2382.377879         1   100      2382.377879    180846.751167         0.001076 /

Looks like kintegrityd went bonkers.  Maybe it has some busy wait
which doesn't quite work well with how cmwq schedules works.  I'll
look into it.  Can you please attach your .config?

Thanks.

-- 
tejun



More information about the kexec mailing list