From: Peter Zijlstra <peterz@infradead.org>
To: Mike Galbraith <umgwanakikbuti@gmail.com>
Cc: Jan Kara <jack@suse.cz>, Sasha Levin <sasha.levin@oracle.com>,
Peter Hurley <peter@hurleysoftware.com>,
pmladek@suse.cz, Andrew Morton <akpm@linux-foundation.org>,
Jet Chen <jet.chen@intel.com>,
LKML <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: console: lockup on boot
Date: Tue, 8 Jul 2014 15:02:39 +0200 [thread overview]
Message-ID: <20140708130239.GF6758@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <1402563262.5171.2.camel@marge.simpson.net>
[-- Attachment #1: Type: text/plain, Size: 1140 bytes --]
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@chello.nl
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2014-07-08 13:02 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-30 13:11 Sasha Levin
2014-05-30 13:58 ` Peter Hurley
2014-05-30 14:07 ` Jan Kara
2014-06-06 19:05 ` Sasha Levin
2014-06-10 15:59 ` Peter Hurley
2014-06-11 14:55 ` Sasha Levin
2014-06-11 15:34 ` Peter Hurley
2014-06-11 20:31 ` Jan Kara
2014-06-11 17:38 ` Linus Torvalds
2014-06-11 17:44 ` Linus Torvalds
2014-06-11 20:34 ` Jan Kara
2014-06-11 21:31 ` Jan Kara
2014-06-12 3:07 ` Sasha Levin
2014-06-12 8:26 ` Jan Kara
2014-06-12 8:54 ` Mike Galbraith
2014-07-08 13:02 ` Peter Zijlstra [this message]
2014-06-19 17:28 ` Jan Kara
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=20140708130239.GF6758@twins.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=jack@suse.cz \
--cc=jet.chen@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=peter@hurleysoftware.com \
--cc=pmladek@suse.cz \
--cc=sasha.levin@oracle.com \
--cc=torvalds@linux-foundation.org \
--cc=umgwanakikbuti@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome