* Ankita Garg <[email protected]> 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.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
