[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20140708130239.GF6758@twins.programming.kicks-ass.net>
Date: Tue, 8 Jul 2014 15:02:39 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Mike Galbraith <umgwanakikbuti@...il.com>
Cc: Jan Kara <jack@...e.cz>, Sasha Levin <sasha.levin@...cle.com>,
Peter Hurley <peter@...leysoftware.com>, pmladek@...e.cz,
Andrew Morton <akpm@...ux-foundation.org>,
Jet Chen <jet.chen@...el.com>,
LKML <linux-kernel@...r.kernel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: console: lockup on boot
On Thu, Jun 12, 2014 at 10:54:22AM +0200, Mike Galbraith wrote:
> On Thu, 2014-06-12 at 10:26 +0200, Jan Kara wrote:
> > On Wed 11-06-14 23:07:04, Sasha Levin wrote:
>
> > > The first patch fixed it (I assumed that there's no need to try the second).
> > Good. So that shows that it is the increased lockdep coverage which is
> > causing problems - with my patch, lockdep is able to identify some problem
> > because console drivers are now called with lockdep enabled. But because
> > the problem was found in some difficult context, lockdep just hung the
> > machine when trying to report it... Sadly the stacktraces you posted don't
> > tell us what lockdep found.
> >
> > Adding Peter Zijlstra to CC. Peter, any idea how lockdep could report
> > problems when holding logbuf_lock? One possibility would be to extend
> > logbuf_cpu recursion logic to every holder of logbuf_lock. That will at
> > least avoid the spinlock recursion killing the machine but we won't be able
> > to see what lockdep found...
>
> Could tell lockdep to use trace_printk().
lkml.kernel.org/r/20111221111143.401184003@...llo.nl
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists