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.
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.
--
With best wishes
Dmitry
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 :-)
Hi,
2008/3/8, Peter Zijlstra <[email protected]>:
>
> 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.
Unfortunately this happens before modules loading --- it's kernel itself.
>
> 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?
Actually no and yes. IIUC, the call chain looks like this (it's with
modified clk's functions, so
it may be a bit hard to understand. If you wish, search for "clocklib"
patches posted to LKML
nearly a month ago).
kernel -> clk_enable() takes global clock spinlock -> my function
which calls another spin_lock which causes lockdep warning.
If I disable global clocks spinlock locking, I get the lockdep
warning. Otherwise, I see no output. This seems to be related to the
fact that I have pxa serial console enabled which in turn also uses
clk_enable/clk_disable to manage its serial port.
>
> 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 :-)
I have a plenty of modules configured to build, but as I hope this
doesn't count, since they aren't loaded
--
With best wishes
Dmitry