[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f0fa028b-b690-2b85-ca01-3642ff883e30@arm.com>
Date: Wed, 2 Aug 2017 09:44:14 +0100
From: Marc Zyngier <marc.zyngier@....com>
To: Will Deacon <will.deacon@....com>,
Pratyush Anand <panand@...hat.com>
Cc: linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
open list <linux-kernel@...r.kernel.org>,
Peter Zijlstra <peterz@...radead.org>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
mark.rutland@....com
Subject: Re: rcu_sched stall while waiting in csd_lock_wait()
On 02/08/17 09:08, Will Deacon wrote:
> Hi Pratyush,
>
> On Wed, Aug 02, 2017 at 09:01:19AM +0530, Pratyush Anand wrote:
>> I am observing following rcu_sched stall while executing `perf record -a --
>> sleep 1` with one of the arm64 platform. It looks like that stalled cpu was
>> waiting in csd_lock_wait() from where it never came out,and so the stall.
>> Any help/pointer for further debugging would be very helpful. Problem also
>> reproduced with 4.13.0-rc3.
>
> When you say "also", which other kernel(s) show the problem? Is this a
> recent regression? Which platform are you running on?
>
> It would be interesting to know what the other CPUs are doing, in particular
> the target of the cross-call. Either it crashed spectacularly and didn't
> unlock the csd lock, or the IPI somehow wasn't delivered.
>
> Do you see any other splats if you enable lock debugging?
Also, is that in a guest, or bare metal? If that's a guest, what's the
host's kernel version?
Thanks,
M.
--
Jazz is not dead. It just smells funny...
Powered by blists - more mailing lists