Messages in this thread | | | Date | Wed, 6 Nov 2013 17:00:37 -0500 (EST) | From | Vince Weaver <> | Subject | Re: a different perf tracepoint bug |
| |
On Wed, 6 Nov 2013, Steven Rostedt wrote:
> > [11559.476002] <<EOE>> <IRQ> [<ffffffff8104acaa>] ? __send_signal+0xd8/0x26f > > Can you find the exact location of __send_signal()?
I'm not sure what you mean, but:
addr2line -e ./vmlinux ffffffff8104acaa linux-kernel/linux-3.12/kernel/signal.c:1095
which is
q = __sigqueue_alloc(sig, t, GFP_ATOMIC | __GFP_NOTRACK_FALSE_POSITIVE, override_rlimit); --> if (q) { list_add_tail(&q->list, &pending->list); switch ((unsigned long) info) { case (unsigned long) SEND_SIG_NOINFO: ...
though this might just be a case where tracepoints are happening too quickly and the kernel gets stuck and can't keep up. Previously I was using a hacked kernel that made the watchdog continually print rather than just warn once, the better to see if any progress was being made.
Vince
| |