(Applies to current Linus tree, as of 2.6.31-rc2)
A third limit becomes apparent as being too low after raising
MAX_STACK_TRACE_ENTRIES and MAX_LOCK_DEPTH, although this one is more
elusive to trigger.
Signed-off-by: Joao Correia <[email protected]>
---
kernel/lockdep_internals.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kernel/lockdep_internals.h b/kernel/lockdep_internals.h
index 699a2ac..93af1f1 100644
--- a/kernel/lockdep_internals.h
+++ b/kernel/lockdep_internals.h
@@ -56,7 +56,7 @@ enum {
*/
#define MAX_LOCKDEP_ENTRIES 16384UL
-#define MAX_LOCKDEP_CHAINS_BITS 15
+#define MAX_LOCKDEP_CHAINS_BITS 16
#define MAX_LOCKDEP_CHAINS (1UL << MAX_LOCKDEP_CHAINS_BITS)
#define MAX_LOCKDEP_CHAIN_HLOCKS (MAX_LOCKDEP_CHAINS*5)
---
On Tue, 2009-07-07 at 16:25 +0100, Joao Correia wrote:
> (Applies to current Linus tree, as of 2.6.31-rc2)
>
> A third limit becomes apparent as being too low after raising
> MAX_STACK_TRACE_ENTRIES and MAX_LOCK_DEPTH, although this one is more
> elusive to trigger.
Hrmm, I really wonder what takes all these chains, I never run into this
stuff. We recently fixed the dma-debug code to generate less classes,
could there be more such bugs?
> Signed-off-by: Joao Correia <[email protected]>
>
> ---
> kernel/lockdep_internals.h | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/kernel/lockdep_internals.h b/kernel/lockdep_internals.h
> index 699a2ac..93af1f1 100644
> --- a/kernel/lockdep_internals.h
> +++ b/kernel/lockdep_internals.h
> @@ -56,7 +56,7 @@ enum {
> */
> #define MAX_LOCKDEP_ENTRIES 16384UL
>
> -#define MAX_LOCKDEP_CHAINS_BITS 15
> +#define MAX_LOCKDEP_CHAINS_BITS 16
> #define MAX_LOCKDEP_CHAINS (1UL << MAX_LOCKDEP_CHAINS_BITS)
>
> #define MAX_LOCKDEP_CHAIN_HLOCKS (MAX_LOCKDEP_CHAINS*5)
> ---
On Tue, 2009-07-07 at 16:25 +0100, Joao Correia wrote:
> (Applies to current Linus tree, as of 2.6.31-rc2)
>
> A third limit becomes apparent as being too low after raising
> MAX_STACK_TRACE_ENTRIES and MAX_LOCK_DEPTH, although this one is more
> elusive to trigger.
Would this involve reloading modules a lot?
On Wed, Jul 8, 2009 at 7:34 PM, Peter Zijlstra<[email protected]> wrote:
> On Tue, 2009-07-07 at 16:25 +0100, Joao Correia wrote:
>> (Applies to current Linus tree, as of 2.6.31-rc2)
>>
>> A third limit becomes apparent as being too low after raising
>> MAX_STACK_TRACE_ENTRIES and MAX_LOCK_DEPTH, although this one is more
>> elusive to trigger.
>
> Would this involve reloading modules a lot?
>
>
All the other limits were triggered immediatly upon boot. This one
happens during regular system usage, after a couple of hours. Not
loading more modules than needed, the system stays at around 45
modules loaded, give or take. I do have qemu running, if that helps
anything.
Joao Correia
On Wed, Jul 8, 2009 at 8:32 PM, Joao Correia<[email protected]> wrote:
> On Wed, Jul 8, 2009 at 7:34 PM, Peter Zijlstra<[email protected]> wrote:
>> On Tue, 2009-07-07 at 16:25 +0100, Joao Correia wrote:
>>> (Applies to current Linus tree, as of 2.6.31-rc2)
>>>
>>> A third limit becomes apparent as being too low after raising
>>> MAX_STACK_TRACE_ENTRIES and MAX_LOCK_DEPTH, although this one is more
>>> elusive to trigger.
>>
>> Would this involve reloading modules a lot?
>>
>>
>
> All the other limits were triggered immediatly upon boot. This one
> happens during regular system usage, after a couple of hours. Not
> loading more modules than needed, the system stays at around 45
> modules loaded, give or take. I do have qemu running, if that helps
> anything.
>
> Joao Correia
>
qemu running as a -host-, not the system running inside it. Just to clear it up.
Joao Correia
On Wed, Jul 08, 2009 at 08:33:37PM +0100, Joao Correia wrote:
> On Wed, Jul 8, 2009 at 8:32 PM, Joao Correia<[email protected]> wrote:
> > On Wed, Jul 8, 2009 at 7:34 PM, Peter Zijlstra<[email protected]> wrote:
> >> On Tue, 2009-07-07 at 16:25 +0100, Joao Correia wrote:
> >>> (Applies to current Linus tree, as of 2.6.31-rc2)
> >>>
> >>> A third limit becomes apparent as being too low after raising
> >>> MAX_STACK_TRACE_ENTRIES and MAX_LOCK_DEPTH, although this one is more
> >>> elusive to trigger.
> >>
> >> Would this involve reloading modules a lot?
> >>
> >>
> >
> > All the other limits were triggered immediatly upon boot. This one
> > happens during regular system usage, after a couple of hours. Not
> > loading more modules than needed, the system stays at around 45
> > modules loaded, give or take. I do have qemu running, if that helps
> > anything.
> >
> > Joao Correia
> >
>
> qemu running as a -host-, not the system running inside it. Just to clear it up.
Could you upload your /proc/lockdep someplace ? Maybe there's some obvious
clues in there like the ones we saw in mine.
Dave