From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: John Stultz <john.stultz@linaro.org>,
Daniel Lezcano <daniel.lezcano@linaro.org>,
linux-kernel@vger.kernel.org
Subject: Re: RCU lockup in the SMP idle thread, help...
Date: Fri, 14 Sep 2012 10:53:22 -0700 [thread overview]
Message-ID: <20120914175322.GI4257@linux.vnet.ibm.com> (raw)
In-Reply-To: <CACRpkdatjfk_eUof5G4fwa-Qf8SoF_NvSUJQAZ7U8yjcSYFuTA@mail.gmail.com>
On Fri, Sep 14, 2012 at 09:27:32AM +0200, Linus Walleij wrote:
> On Thu, Sep 13, 2012 at 6:58 PM, Paul E. McKenney
> <paulmck@linux.vnet.ibm.com> wrote:
> > On Thu, Sep 13, 2012 at 09:49:14AM -0700, John Stultz wrote:
> >> I saw this once as well testing the fix to Daniel's deep idle hang
> >> issue (also on 32 bit).
>
> John, what system was this? If it's not Snowball/ux500 we can atleast
> conclude that
> it's a generic bug, not machine-specific...
>
> >> Really briefly looking at the code in rcutree.c, I'm curious if
> >> we're hitting a false positive on the 5 minute jiffies overflow?
> >
> > Hmmm... Might be. Does the patch below help?
>
> Sorry, nope, I get this:
Could you please try reproducing with CONFIG_RCU_CPU_STALL_INFO=y?
Thanx, Paul
> root@ME:/
> root@ME:/ INFO: rcu_preempt detected stalls on CPUs/tasks: { 0}
> (detected by 1, t=29545 jiffies)
> [<c0014710>] (unwind_backtrace+0x0/0xf8) from [<c00686fc>]
> (rcu_check_callbacks+0x6e0/0x76c)
> [<c00686fc>] (rcu_check_callbacks+0x6e0/0x76c) from [<c0029cbc>]
> (update_process_times+0x38/0x4c)
> [<c0029cbc>] (update_process_times+0x38/0x4c) from [<c0055088>]
> (tick_sched_timer+0x80/0xe4)
> [<c0055088>] (tick_sched_timer+0x80/0xe4) from [<c003c120>]
> (__run_hrtimer.isra.18+0x44/0xd0)
> [<c003c120>] (__run_hrtimer.isra.18+0x44/0xd0) from [<c003cae0>]
> (hrtimer_interrupt+0x118/0x2b4)
> [<c003cae0>] (hrtimer_interrupt+0x118/0x2b4) from [<c0013658>]
> (twd_handler+0x30/0x44)
> [<c0013658>] (twd_handler+0x30/0x44) from [<c00638c8>]
> (handle_percpu_devid_irq+0x80/0xa0)
> [<c00638c8>] (handle_percpu_devid_irq+0x80/0xa0) from [<c00603b8>]
> (generic_handle_irq+0x20/0x30)
> [<c00603b8>] (generic_handle_irq+0x20/0x30) from [<c000ef58>]
> (handle_IRQ+0x4c/0xac)
> [<c000ef58>] (handle_IRQ+0x4c/0xac) from [<c00084bc>] (gic_handle_irq+0x24/0x58)
> [<c00084bc>] (gic_handle_irq+0x24/0x58) from [<c000dc80>] (__irq_svc+0x40/0x70)
> Exception stack(0xcf865f88 to 0xcf865fd0)
> 5f80: 00000020 c05c0a20 00000001 00000000 cf864000 cf864000
> 5fa0: c05dfe48 c02de0bc c05c3e90 412fc091 cf864000 00000000 01000000 cf865fd0
> 5fc0: c000f234 c000f238 60000013 ffffffff
> [<c000dc80>] (__irq_svc+0x40/0x70) from [<c000f238>] (default_idle+0x28/0x30)
> [<c000f238>] (default_idle+0x28/0x30) from [<c000f438>] (cpu_idle+0x98/0xe4)
> [<c000f438>] (cpu_idle+0x98/0xe4) from [<002d3094>] (0x2d3094)
> INFO: rcu_preempt detected stalls on CPUs/tasks: { 0} (detected by 1,
> t=30029 jiffies)
> [<c0014710>] (unwind_backtrace+0x0/0xf8) from [<c00686fc>]
> (rcu_check_callbacks+0x6e0/0x76c)
> [<c00686fc>] (rcu_check_callbacks+0x6e0/0x76c) from [<c0029cbc>]
> (update_process_times+0x38/0x4c)
> [<c0029cbc>] (update_process_times+0x38/0x4c) from [<c0055088>]
> (tick_sched_timer+0x80/0xe4)
> [<c0055088>] (tick_sched_timer+0x80/0xe4) from [<c003c120>]
> (__run_hrtimer.isra.18+0x44/0xd0)
> [<c003c120>] (__run_hrtimer.isra.18+0x44/0xd0) from [<c003cae0>]
> (hrtimer_interrupt+0x118/0x2b4)
> [<c003cae0>] (hrtimer_interrupt+0x118/0x2b4) from [<c0013658>]
> (twd_handler+0x30/0x44)
> [<c0013658>] (twd_handler+0x30/0x44) from [<c00638c8>]
> (handle_percpu_devid_irq+0x80/0xa0)
> [<c00638c8>] (handle_percpu_devid_irq+0x80/0xa0) from [<c00603b8>]
> (generic_handle_irq+0x20/0x30)
> [<c00603b8>] (generic_handle_irq+0x20/0x30) from [<c000ef58>]
> (handle_IRQ+0x4c/0xac)
> [<c000ef58>] (handle_IRQ+0x4c/0xac) from [<c00084bc>] (gic_handle_irq+0x24/0x58)
> [<c00084bc>] (gic_handle_irq+0x24/0x58) from [<c000dc80>] (__irq_svc+0x40/0x70)
> Exception stack(0xcf865f88 to 0xcf865fd0)
> 5f80: 00000020 c05c0a20 00000001 00000000 cf864000 cf864000
> 5fa0: c05dfe48 c02de0bc c05c3e90 412fc091 cf864000 00000000 01000000 cf865fd0
> 5fc0: c000f234 c000f238 60000013 ffffffff
> [<c000dc80>] (__irq_svc+0x40/0x70) from [<c000f238>] (default_idle+0x28/0x30)
> [<c000f238>] (default_idle+0x28/0x30) from [<c000f438>] (cpu_idle+0x98/0xe4)
> [<c000f438>] (cpu_idle+0x98/0xe4) from [<002d3094>] (0x2d3094)
>
> I'm all confused ..
>
> Yours,
> Linus Walleij
>
next prev parent reply other threads:[~2012-09-14 17:54 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-13 12:36 RCU lockup in the SMP idle thread, help Linus Walleij
2012-09-13 16:49 ` John Stultz
2012-09-13 16:58 ` Paul E. McKenney
2012-09-14 7:27 ` Linus Walleij
2012-09-14 17:53 ` Paul E. McKenney [this message]
2012-09-17 9:10 ` Linus Walleij
2012-09-20 0:03 ` Paul E. McKenney
2012-09-20 8:46 ` Linus Walleij
2012-09-20 17:49 ` Nicolas Pitre
2012-09-20 9:07 ` Linus Walleij
2012-09-20 14:10 ` Paul E. McKenney
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=20120914175322.GI4257@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=daniel.lezcano@linaro.org \
--cc=john.stultz@linaro.org \
--cc=linus.walleij@linaro.org \
--cc=linux-kernel@vger.kernel.org \
/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.