lkml.org 
[lkml]   [2008]   [Mar]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Lockdep problem
From
Date

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 :-)



\
 
 \ /
  Last update: 2008-03-08 18:33    [W:0.047 / U:0.248 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site