perf: hard lockup when using perf-sched
in [Kernel]
|
Prev: How to reserved all the CPU time for the private computing
Next: Need to intercept open&write calls for vdi file when VirtualBox is working.
From: Frederic Weisbecker on 26 Mar 2010 17:50 On Fri, Mar 26, 2010 at 09:22:04PM +0100, Mike Galbraith wrote: > [ 427.931717] <IRQ> > [ 427.931717] [<ffffffff811403f4>] __delay+0xa/0xc > [ 427.931717] [<ffffffff81143e42>] do_raw_spin_lock+0xd2/0x13c > [ 427.931717] [<ffffffff812dbc18>] _raw_spin_lock+0x34/0x3b > [ 427.931717] [<ffffffff81026e03>] ? task_rq_lock+0x7c/0x97 > [ 427.931717] [<ffffffff8105f2b1>] ? trace_hardirqs_on+0xd/0xf > [ 427.931717] [<ffffffff81026e03>] task_rq_lock+0x7c/0x97 > [ 427.931717] [<ffffffff8102d4a5>] try_to_wake_up+0x26/0x266 > [ 427.931717] [<ffffffff8102d704>] wake_up_process+0x10/0x12 > [ 427.931717] [<ffffffff810392f4>] wakeup_softirqd+0x2a/0x2c > [ 427.931717] [<ffffffff81039771>] __do_softirq+0x21e/0x220 > [ 427.931717] [<ffffffff8104b6a0>] ? __task_pid_nr_ns+0x0/0xad > [ 427.931717] [<ffffffff81002e0c>] call_softirq+0x1c/0x28 > [ 427.931717] [<ffffffff81004b73>] do_softirq+0x38/0x81 > [ 427.931717] [<ffffffff8103983a>] irq_exit+0x45/0x87 > [ 427.931717] [<ffffffff81016f86>] smp_apic_timer_interrupt+0x88/0x96 > [ 427.931717] [<ffffffff810028d3>] apic_timer_interrupt+0x13/0x20 > [ 427.931717] <EOI> > [ 427.931717] [<ffffffff8105eae6>] ? lock_acquire+0x108/0x117 > [ 427.931717] [<ffffffff8104b6a0>] ? __task_pid_nr_ns+0x0/0xad > [ 427.931717] [<ffffffff810892f9>] ? perf_output_begin+0x0/0x24d > [ 427.931717] [<ffffffff8104b6dc>] __task_pid_nr_ns+0x3c/0xad > [ 427.931717] [<ffffffff8104b6a0>] ? __task_pid_nr_ns+0x0/0xad > [ 427.931717] [<ffffffff8108668a>] perf_event_tid+0x26/0x28 > [ 427.931717] [<ffffffff8108960f>] perf_event_task_output+0x74/0x9f > [ 427.931717] [<ffffffff81089675>] perf_event_task_ctx+0x3b/0x5b > [ 427.931717] [<ffffffff810896e8>] perf_event_task_event+0x53/0xca > [ 427.931717] [<ffffffff81089695>] ? perf_event_task_event+0x0/0xca > [ 427.931717] [<ffffffff810897da>] perf_event_task+0x7b/0x86 > [ 427.931717] [<ffffffff8108a90e>] perf_event_fork+0x10/0x12 Aaah, I see now. That happens during a fork event! So that looks indeed the right fix. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Li Zefan on 28 Mar 2010 22:10
> This seems to work, in contrast to everything I tried yesterday. Not > exactly a thing of beauty, but at least it's an option, so... > > perf: fix perf sched record forkbomb deadlock > > perf sched record can deadlock a box should the holder of handle->data->lock > take an interrupt, and then attempt to acquire an rq lock held by a CPU trying > to acquire the same lock. Disable interrupts. > This patch fixes the lockup on my box. Thanks! > Signed-off-by: Mike Galbraith <efault(a)gmx.de> > Cc: Ingo Molnar <mingo(a)elte.hu> > Cc: Peter Zijlstra <a.p.zijlstra(a)chello.nl> > Cc: Arnaldo Carvalho de Melo <acme(a)redhat.com> > Cc: Frederic Weisbecker <fweisbec(a)gmail.com> > Reported-by: Li Zefan <lizf(a)cn.fujitsu.com> > LKML-Reference: <new-submission> > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |