[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1460125010.16946.27.camel@gmail.com>
Date: Fri, 08 Apr 2016 16:16:50 +0200
From: Mike Galbraith <umgwanakikbuti@...il.com>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc: Thomas Gleixner <tglx@...utronix.de>,
linux-rt-users@...r.kernel.org, linux-kernel@...r.kernel.org,
Steven Rostedt <rostedt@...dmis.org>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: [PATCH RT 4/6] rt/locking: Reenable migration accross schedule
On Fri, 2016-04-08 at 15:58 +0200, Sebastian Andrzej Siewior wrote:
> On 04/08/2016 03:44 PM, Mike Galbraith wrote:
> > On Thu, 2016-04-07 at 18:47 +0200, Sebastian Andrzej Siewior wrote:
> >
> > > just to be clear: The patch I attached did _not_ work for you.
> >
> > Did you perchance mean with "Reenable migration across schedule"
> > reverted? Figured it would still explode in seconds.. it did.
>
> I meant 4.4.6-rt13 + my patch and nothing else.
>
> > [ 172.996232] kernel BUG at kernel/locking/rtmutex.c:1360!
>
> okay. and how did you trigger this? Just Steven's script or was there
> more to it?
I run stockfish, futextest, hackbench and tbench with it, terminating
and restarting them at random intervals just to make sure nobody gets
into a comfortable little rut. Stockfish and tbench are sized as to
not saturate the box, hackbench runs periodically (and with no args to
turn it into a hog), futextest run.sh just does its normal thing.
Trying to grab an rtmutex while queued on an rtmutex... doesn't matter
much if it's the lock that likes to deadlock us, or the one you added
instead of making that blasted lock really really dead.
-Mike
Powered by blists - more mailing lists