All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frederic Weisbecker <fweisbec@gmail.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: Steven Rostedt <rostedt@goodmis.org>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH 0/5] [GIT PULL] updates for tip/tracing/ftrace
Date: Sat, 21 Mar 2009 18:32:07 +0100	[thread overview]
Message-ID: <20090321173206.GB5956@nowhere> (raw)
In-Reply-To: <20090321165804.GA21366@elte.hu>

On Sat, Mar 21, 2009 at 05:58:04PM +0100, Ingo Molnar wrote:
> 
> * Ingo Molnar <mingo@elte.hu> wrote:
> 
> > 
> > * Steven Rostedt <rostedt@goodmis.org> wrote:
> > 
> > > 
> > > On Fri, 20 Mar 2009, Frederic Weisbecker wrote:
> > > > > >  
> > > > > >  	VERBOSE_PRINTK_STRING("rcu_torture_reader task started");
> > > > > > -	set_user_nice(current, 19);
> > > > > > +	set_user_nice(current, -1);
> > > > > >  	if (irqreader && cur_ops->irqcapable)
> > > > > >  		setup_timer_on_stack(&t, rcu_torture_timer, 0);
> > > > > 
> > > > > i dont have a reproducer right now. Can you trigger it with latest 
> > > > > -tip, which has this commit included:
> > > > > 
> > > > > 04cb9ac: rcu: rcu_barrier VS cpu_hotplug: Ensure callbacks in dead cpu are migrated to o
> > > > > 
> > > > > ?
> > > > > 
> > > > > 	Ingo
> > > > 
> > > > 
> > > > I tested three times the same things but with 04cb9ac and... it didn't triggered
> > > > anymore :-)
> > > 
> > > So lets hope that was the culprit.
> > > 
> > > Great work Frederic!
> > 
> > No new lockups of this nature in overnight -tip testing. It's 
> > still a bit too early to tell for sure but it's promising ;-)
> 
> just got a lockup again :-/ It hangs here:
> 
> calling  init_mmio_trace+0x0/0x12 @ 1
> initcall init_mmio_trace+0x0/0x12 returned 0 after 0 usecs
> calling  init_graph_trace+0x0/0x12 @ 1
> Testing tracer function_graph: 
> 
> and this time i got good stackdumps as well - see below. Config 
> attached.
> 
> 	Ingo
> 
> Testing tracer sched_switch: PASSED
> initcall init_sched_switch_trace+0x0/0x12 returned 0 after 99609 usecs
> calling  init_stack_trace+0x0/0x12 @ 1
> Testing tracer sysprof: .. no entries found ..FAILED!
> initcall init_stack_trace+0x0/0x12 returned -1 after 101562 usecs
> initcall init_stack_trace+0x0/0x12 returned with error code -1 
> calling  init_function_trace+0x0/0x12 @ 1
> Testing tracer function: PASSED
> initcall init_function_trace+0x0/0x12 returned 0 after 104492 usecs
> calling  init_irqsoff_tracer+0x0/0x2c @ 1
> Testing tracer irqsoff: .. no entries found ..FAILED!
> Testing tracer preemptoff: .. no entries found ..FAILED!
> Testing tracer preemptirqsoff: .. no entries found ..FAILED!


It's strange that the {*}_off tracers have failed.


> initcall init_irqsoff_tracer+0x0/0x2c returned 0 after 8789 usecs
> calling  init_wakeup_tracer+0x0/0x58 @ 1
> Testing tracer wakeup: .. no entries found ..FAILED!


This one too. (sysprof doesn't count, it fails for some weeks, I think
it's not a hard deal to fix).


> initcall init_wakeup_tracer+0x0/0x58 returned -1 after 298828 usecs
> initcall init_wakeup_tracer+0x0/0x58 returned with error code -1 
> calling  stack_trace_init+0x0/0xc7 @ 1
> initcall stack_trace_init+0x0/0xc7 returned 0 after 0 usecs
> calling  init_mmio_trace+0x0/0x12 @ 1
> initcall init_mmio_trace+0x0/0x12 returned 0 after 0 usecs
> calling  init_graph_trace+0x0/0x12 @ 1
> Testing tracer function_graph: <3>INFO: RCU detected CPU 0 stall (t=4294678940/10000 jiffies)
> Pid: 1, comm: swapper Not tainted 2.6.29-rc8-tip-02752-g47b1aea-dirty #3264
> Call Trace:
>  <IRQ>  [<ffffffff8020c79d>] return_to_handler+0x0/0x73
>  [<ffffffff80211150>] print_context_stack+0xa0/0xd3
>  [<ffffffff8020c79d>] return_to_handler+0x0/0x73
>  [<ffffffff8020fb26>] dump_trace+0x22d/0x2cc
>  [<ffffffff8020c79d>] return_to_handler+0x0/0x73
>  [<ffffffff80211008>] show_trace_log_lvl+0x51/0x5d
>  [<ffffffff8020c79d>] return_to_handler+0x0/0x73
>  [<ffffffff80211029>] show_trace+0x15/0x17
>  [<ffffffff8020c79d>] return_to_handler+0x0/0x73
>  [<ffffffff802111fa>] dump_stack+0x77/0x81
>  [<ffffffff8020c79d>] return_to_handler+0x0/0x73
>  [<ffffffff8029e6dd>] print_cpu_stall+0x40/0xa4
>  [<ffffffff8020c79d>] return_to_handler+0x0/0x73
>  [<ffffffff8029e8be>] check_cpu_stall+0x49/0x76
>  [<ffffffff8020c79d>] return_to_handler+0x0/0x73
>  [<ffffffff8029e902>] __rcu_pending+0x17/0xfc
>  [<ffffffff8020c79d>] return_to_handler+0x0/0x73
>  [<ffffffff8029ea13>] rcu_pending+0x2c/0x5e
>  [<ffffffff8020c79d>] return_to_handler+0x0/0x73
>  [<ffffffff8026abef>] update_process_times+0x3c/0x77
>  [<ffffffff8020c79d>] return_to_handler+0x0/0x73
>  [<ffffffff802875dd>] tick_periodic+0x6e/0x70


Still hanging in the timer interrupt.
I guess it makes the timer interrupt servicing too slow and then
once it is serviced, another one is raised.

But the cause is perhaps more complex

I think you have had too much hanging of this type.
I'm preparing a fix that checks periodically if the function graph
tracer is spending too much time in an interrupt.

I guess I could count the number of function executed between the irq entry
and its exit.

That's the best: if we are hanging in an interrupt, it could be whatever
interrupt and the jiffies could not be progressing so I can't rely
on time but only on number of functions executed.

May be 10000 calls is a good threshold before killing the function graph
inside an interrupt?

Let's try, I will also provide a way to dump the function graph traces from
the ring-buffer on the screen, it could help to debug it in this case.

Thanks,
Frederic.



  parent reply	other threads:[~2009-03-21 17:32 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-18  3:14 [PATCH 0/5] [GIT PULL] updates for tip/tracing/ftrace Steven Rostedt
2009-03-18  3:14 ` [PATCH 1/5] ring-buffer: add api to allow a tracer to change clock source Steven Rostedt
2009-03-18  3:14 ` [PATCH 2/5] tracing: add global-clock option to provide cross CPU clock to traces Steven Rostedt
2009-03-18  3:14 ` [PATCH 3/5] tracing: optimization of branch tracer Steven Rostedt
2009-03-18  3:14 ` [PATCH 4/5] tracing: make sched_switch stop/start light weight Steven Rostedt
2009-03-18  3:14 ` [PATCH 5/5] tracing: make power tracer start/stop methods lighter weight Steven Rostedt
2009-03-18  5:59 ` [PATCH 0/5] [GIT PULL] updates for tip/tracing/ftrace Ingo Molnar
2009-03-18  7:39   ` Ingo Molnar
2009-03-19  7:33     ` Ingo Molnar
2009-03-19 17:21       ` Steven Rostedt
2009-03-20 17:43         ` Paul E. McKenney
2009-03-20 18:36           ` Ingo Molnar
2009-03-20 18:38             ` Ingo Molnar
2009-03-20 19:19               ` Paul E. McKenney
2009-03-20 19:27                 ` Ingo Molnar
2009-03-20 19:41                   ` Paul E. McKenney
2009-03-20 19:46                   ` Frederic Weisbecker
2009-03-20 19:54                     ` Ingo Molnar
2009-03-20 20:48                       ` Frederic Weisbecker
2009-03-20 21:05                         ` Steven Rostedt
2009-03-21 10:01                           ` Ingo Molnar
2009-03-21 16:58                             ` Ingo Molnar
2009-03-21 17:25                               ` Steven Rostedt
2009-03-21 19:07                                 ` Paul E. McKenney
2009-03-21 20:09                                   ` Ingo Molnar
2009-03-21 21:01                                     ` Paul E. McKenney
2009-03-22 14:24                                       ` Ingo Molnar
2009-03-22 15:06                                         ` Ingo Molnar
2009-03-22 17:02                                           ` Ingo Molnar
2009-03-22 18:33                                             ` Steven Rostedt
2009-03-22 19:52                                               ` Ingo Molnar
2009-03-23 18:44                                           ` Steven Rostedt
2009-03-21 17:32                               ` Frederic Weisbecker [this message]
2009-03-21 17:44                                 ` Steven Rostedt
2009-03-21 17:53                                   ` Frederic Weisbecker
2009-03-21 18:17                                     ` Steven Rostedt
2009-03-21 20:03                                       ` Frederic Weisbecker
2009-03-21 18:18                                 ` Ingo Molnar
2009-03-21 20:09                                   ` Frederic Weisbecker
2009-03-21 20:46                                     ` Frederic Weisbecker
2009-03-22 19:41                               ` Ingo Molnar
2009-03-22 20:41                                 ` Ingo Molnar
2009-03-20 21:39                         ` Paul E. McKenney
2009-03-20 17:05       ` Frederic Weisbecker
2009-03-20 17:57         ` Frederic Weisbecker
2009-03-20 18:22           ` Steven Rostedt
2009-03-20 18:39             ` Frederic Weisbecker
2009-03-20 18:42             ` Ingo Molnar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090321173206.GB5956@nowhere \
    --to=fweisbec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.