On Thu, Jul 26, 2007 at 09:35:20AM +0200, Ingo Molnar wrote: > > * Ankita Garg <ankita@xxxxxxxxxx> wrote: > > > The probe point did get triggered, and soon after that I had the > > following in dmesg, leading to system hang... > > > > BUG: scheduling while atomic: softirq-rcu/3/0x00000004/52, CPU#3 > > > > Call Trace: > > <#DB> [<ffffffff81033555>] __schedule_bug+0x4b/0x4f > > [<ffffffff8128b414>] __sched_text_start+0xcc/0xaaa > > [<ffffffff8100b574>] dump_trace+0x248/0x25d > > [<ffffffff81068334>] print_traces+0x9/0xb > > [<ffffffff8100b5e5>] show_trace+0x5c/0x64 > > [<ffffffff8128c1c2>] schedule+0xe4/0x104 > > [<ffffffff8128d10c>] rt_spin_lock_slowlock+0xfc/0x19e > > [<ffffffff8128d9de>] __rt_spin_lock+0x1f/0x21 > > [<ffffffff8128d9e9>] rt_spin_lock+0x9/0xb > > [<ffffffff88387dcc>] > > :stap_c1a10b1292b5f87a563f56d89ddfc765_606:_stp_print_flush+0x5f/0xdf > > [<ffffffff88389e41>] > > :stap_c1a10b1292b5f87a563f56d89ddfc765_606:probe_1493+0x1f6/0x257 > > [<ffffffff8838bdc3>] > > I'd suggest to not put a probe into a preempt-off section - put it to > the beginning and to the end of schedule() to capture context-switches. > _stp_print_flush() is in the systemtap-generated module, right? Maybe > the problem is resolved by changing that spinlock to use raw_spinlock_t > / DEFINE_RAW_SPIN_LOCK. Yes, _stp_print_flush is in the systemtap-generated kprobe module. Placing the probe at the beginning of schedule() also has the same effect. Will try by changing the spinlock to raw_spinlock_t... > > > Ingo -- Regards, Ankita Garg (ankita@xxxxxxxxxx) Linux Technology Center IBM India Systems & Technology Labs, Bangalore, India - To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
