All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Dmitry <dbaryshkov@gmail.com>
Cc: mingo@redhat.com, linux-kernel@vger.kernel.org
Subject: Re: Lockdep problem
Date: Sat, 08 Mar 2008 18:30:57 +0100	[thread overview]
Message-ID: <1204997457.6241.314.camel@lappy> (raw)
In-Reply-To: <bc64b4640803080910w3c2905d6gd17357aafa7b2db9@mail.gmail.com>


On Sat, 2008-03-08 at 20:10 +0300, Dmitry wrote:
> Hi,
> 
> I've ran into the lockdep problem: I'm hitting the condition at the
> lockdep.c:2437:
>        if (DEBUG_LOCKS_WARN_ON(id >= MAX_LOCKDEP_KEYS))
>                 return 0;
> 
> What does it mean and how to overcome it? Dumbly increasing constants
> at kernel/lockdep_internals.h didn't help.

It means you have more lockdep classes (lock instantiation sites,
explicit class keys etc..) that we have static storage reserved for.

One way to quickly achieve this is load/unload modules. Zapping the
classes on module unload does not make the space available again.

Sadly most setups these days try to load every module under the sun,
wasting valuable boot time, and causing this head-ache.

Someone reported to me increasing MAX_LOCKDEP_KEYS_BITS to 15 (IIRC)
made his distro build work again. Of course, cycle reloading a module
will eventually run you out of space anyway.

> The warning is pretty fatal for me because it happens when I'm locking
> clocks lock, so when serial console output calls
> clk_enable/clk_disable the kernel deadlocks.

Not sure I fully understand what you mean here, but I've never seen this
result in anything but a warning, the kernel will just continue..

Or are you trying to debug a deadlock and can't because lockdep runs out
of classes before it gets to the offending code?

Something you can do is build a kernel without (or very few modules) - a
good idea anyway as turning off all that unused stuff will significantly
improve build times too :-)


  reply	other threads:[~2008-03-08 17:31 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-08 17:10 Lockdep problem Dmitry
2008-03-08 17:30 ` Peter Zijlstra [this message]
2008-03-08 19:00   ` Dmitry
  -- strict thread matches above, loose matches on Subject: below --
2014-01-07 18:28 Larry Finger
2014-01-09 16:24 ` Stanislaw Gruszka
2014-01-09 19:14   ` Larry Finger

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=1204997457.6241.314.camel@lappy \
    --to=peterz@infradead.org \
    --cc=dbaryshkov@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.