All of lore.kernel.org
 help / color / mirror / Atom feed
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..


  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 [2.6.27] early exception - lockdep related? 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.