From: Peter Zijlstra <peterz@infradead.org>
To: Luca Tettamanti <kronos.it@gmail.com>
Cc: linux-kernel@vger.kernel.org, mingo@redhat.com
Subject: Re: [2.6.27] early exception - lockdep related?
Date: Wed, 03 Sep 2008 08:52:01 +0200 [thread overview]
Message-ID: <1220424721.8609.74.camel@twins> (raw)
In-Reply-To: <20080902210646.GA10925@dreamland.darkstar.lan>
On Tue, 2008-09-02 at 23:06 +0200, Luca Tettamanti wrote:
> Hello,
> I'm seeing an early exception (0e) - which seems related to lockdep - at
> boot with many 2.6.27 kernels and I'm having troubles to track it down.
Does it print one of these nice stack traces?
> The strange thing is that it comes and goes with different kernel
> versions
What kernel version did you generate the below with - and what config.
> , but a "bad" kernel consistently fails across reboots. It also
> seems to be sensitive to the configuration (attached)
you seem to have forgotten that attachment.
> , at least in one
> case the difference between a non-working kernel and a working one is
> CONFIG_DEBUG enabled in the latter.
>
> The address printed is inside the function __lock_acqurie:
>
> in __lock_acquire (/home/kronos/src/linux-2.6.git/kernel/lockdep.c:727).
> 722
> 723 /*
> 724 * We can walk the hash lockfree, because the hash only
> 725 * grows, and we are careful when adding entries to the end:
> 726 */
> 727 list_for_each_entry(class, hash_head, hash_entry) {
> 728 if (class->key == key) {
> 729 WARN_ON_ONCE(class->name != lock->name);
> 730 return class;
> 731 }
Right - except this isn't in __lock_acquire, its from
look_up_lock_class, which probably gets inlined.
> And the disassembly (faulting address is 0xffffffff80253b66)
<snip asm>
> I actually tried to bisect it using an early working kernel and this first
> (read: the first pull from Linus' tree that gave me a broken kernel). The
> result is inconclusive, the commit pointed out was:
>
> e5f363e358cf16e4ad13a6826e15088c5495efe9 is first bad commit
> commit e5f363e358cf16e4ad13a6826e15088c5495efe9
> Author: Ingo Molnar <mingo@elte.hu>
> Date: Mon Aug 11 12:37:27 2008 +0200
>
> lockdep: increase MAX_LOCKDEP_KEYS
>
> certain configs produce:
>
> [ 70.076229] BUG: MAX_LOCKDEP_KEYS too low!
> [ 70.080230] turning off the locking correctness validator.
>
> tune them up.
>
> Signed-off-by: Ingo Molnar <mingo@elte.hu>
>
> but reverting it didn't make any difference.
>
> Is there any other action that I can take to debug this issue? Btw, do you
> think that kgdb can be usefull? I can give it a try in the weekend...
Might - I've never tried it..
next prev parent reply other threads:[~2008-09-03 6:52 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-02 21:06 Luca Tettamanti
2008-09-03 6:52 ` Peter Zijlstra [this message]
2008-09-03 8:28 ` Luca Tettamanti
2008-09-03 8:37 ` Peter Zijlstra
2008-09-03 8:54 ` Luca Tettamanti
2008-09-03 9:01 ` Peter Zijlstra
2008-09-03 9:03 ` Peter Zijlstra
2008-09-03 19:21 ` Luca Tettamanti
2008-09-04 14:25 ` Peter Zijlstra
2008-09-04 20:51 ` Luca Tettamanti
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=1220424721.8609.74.camel@twins \
--to=peterz@infradead.org \
--cc=kronos.it@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.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