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