On Wed, 2010-04-21 at 14:12 +0200, John Kacur wrote:
quoted text
> 
> On Wed, 21 Apr 2010, Peter Zijlstra wrote:
> 
> > On Wed, 2010-04-21 at 13:12 +0200, John Kacur wrote:
> > > 
> > > Certain configurations that have LOCKDEP turned on, run into the limit
> > > where the MAX_STACK_TRACE_ENTRIES are too small. Rather than simply
> > > turning of the locking correctness validator let the user configure this
> > > value to something reasonable for their system.
> > 
> > I'm not sure its worth having a CONFIG_ value for this, that'll just be
> > yet another random value nobody knows what to do with.
> > 
> > Do you actually have a machine that reproduces this? Can you see how
> > many classes, avg stacktraces per class and the avg entries per
> > stacktrace there are?
> 
> This triggers every single time when I boot my T500 laptop with 
> 2.6.33.2-rt13 with lots of debug options enabled. The problem is not
> specific to this kernel though.
> 

Working from ancient memory here:

I think that this is seen more on the distro side - had the same problem
with SLERT. 

And yes, it did show up more with additional debug options -- when
structs with #ifdef DEBUG_XXX are populated.

IIRC there is another caveat, if MAX_STACK_TRACE_ENTRIES is too large,
you run out of memory uncompressing the Kernel (on 32 bit only?) and it
hangs.

We put patches in place to manually increase to something workable, but
I would ACK this change, allowing tinkering.

Regards,

Sven

--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/