Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758078AbZGGP7t (ORCPT ); Tue, 7 Jul 2009 11:59:49 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754669AbZGGP7m (ORCPT ); Tue, 7 Jul 2009 11:59:42 -0400 Received: from mail-fx0-f218.google.com ([209.85.220.218]:52954 "EHLO mail-fx0-f218.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754144AbZGGP7l convert rfc822-to-8bit (ORCPT ); Tue, 7 Jul 2009 11:59:41 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=Ms3ep6BHg/biY5OjV7f/wA+FsnRow0oFgFELMIOzos0r11ivekD9jme+NmY5IQ+t4n aH1wYBOgK4MA+oBx+VEjmLT97l7ogG8VPUT6CnTI6SM9VkHKmsNR9LApbPb1GSJjZ0gr 3zczbkfHnSFRXa2nH/BYFwTW9LB+lNw6Jk5gY= MIME-Version: 1.0 In-Reply-To: <1246982101.9777.15.camel@twins> References: <1246980836.9777.5.camel@twins> <1246981444.9777.11.camel@twins> <1246982101.9777.15.camel@twins> From: Joao Correia Date: Tue, 7 Jul 2009 16:59:18 +0100 Message-ID: Subject: Re: [PATCH 1/3] Increase lockdep limits: MAX_STACK_TRACE_ENTRIES To: Peter Zijlstra Cc: LKML , =?ISO-8859-1?Q?Am=E9rico_Wang?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4023 Lines: 93 On Tue, Jul 7, 2009 at 4:55 PM, Peter Zijlstra wrote: > On Tue, 2009-07-07 at 16:50 +0100, Joao Correia wrote: > >> >> Yes. Anything 2.6.31 forward triggers this immediatly during init >> >> process, at random places. >> > >> > Not on my machines it doesn't.. so I suspect its something weird in >> > your .config or maybe due to some hardware you have that I don't that >> > triggers different drivers or somesuch. >> >> I am not the only one reporting this, and it happens, for example, >> with a stock .config from a Fedora 11 install. >> >> It may, of course, be a funny driver interaction yes, but other than >> stripping the box piece by piece, how would one go about debugging >> this otherwise? > > One thing to do is stare (or share) at the output > of /proc/lockdep_chains and see if there's some particularly large > chains in there, or many of the same name or something. > > /proc/lockdep_stats might also be interesting, mine reads like: > > [root@opteron ~]# cat /proc/lockdep_stats > ?lock-classes: ? ? ? ? ? ? ? ? ? ? ? ? ?641 [max: 8191] > ?direct dependencies: ? ? ? ? ? ? ? ? ?3794 [max: 16384] > ?indirect dependencies: ? ? ? ? ? ? ? ?7557 > ?all direct dependencies: ? ? ? ? ? ? 73254 > ?dependency chains: ? ? ? ? ? ? ? ? ? ?3716 [max: 32768] > ?dependency chain hlocks: ? ? ? ? ? ? 10167 [max: 163840] > ?in-hardirq chains: ? ? ? ? ? ? ? ? ? ? ?21 > ?in-softirq chains: ? ? ? ? ? ? ? ? ? ? 353 > ?in-process chains: ? ? ? ? ? ? ? ? ? ?3342 > ?stack-trace entries: ? ? ? ? ? ? ? ? 91035 [max: 262144] > ?combined max dependencies: ? ? ? ?26035284 > ?hardirq-safe locks: ? ? ? ? ? ? ? ? ? ? 28 > ?hardirq-unsafe locks: ? ? ? ? ? ? ? ? ?460 > ?softirq-safe locks: ? ? ? ? ? ? ? ? ? ?114 > ?softirq-unsafe locks: ? ? ? ? ? ? ? ? ?373 > ?irq-safe locks: ? ? ? ? ? ? ? ? ? ? ? ?123 > ?irq-unsafe locks: ? ? ? ? ? ? ? ? ? ? ?460 > ?hardirq-read-safe locks: ? ? ? ? ? ? ? ? 0 > ?hardirq-read-unsafe locks: ? ? ? ? ? ? ?45 > ?softirq-read-safe locks: ? ? ? ? ? ? ? ? 8 > ?softirq-read-unsafe locks: ? ? ? ? ? ? ?39 > ?irq-read-safe locks: ? ? ? ? ? ? ? ? ? ? 8 > ?irq-read-unsafe locks: ? ? ? ? ? ? ? ? ?45 > ?uncategorized locks: ? ? ? ? ? ? ? ? ? 106 > ?unused locks: ? ? ? ? ? ? ? ? ? ? ? ? ? ?1 > ?max locking depth: ? ? ? ? ? ? ? ? ? ? ?14 > ?max recursion depth: ? ? ? ? ? ? ? ? ? ?10 > ?debug_locks: ? ? ? ? ? ? ? ? ? ? ? ? ? ? 1 > > > I have definitly much higher numbers than those: [root@hightech git]# cat /proc/lockdep_stats lock-classes: 1793 [max: 8191] direct dependencies: 12032 [max: 16384] indirect dependencies: 126642 all direct dependencies: 1310382 dependency chains: 28387 [max: 65536] dependency chain hlocks: 100117 [max: 327680] in-hardirq chains: 3029 in-softirq chains: 7585 in-process chains: 17773 stack-trace entries: 417613 [max: 1048576] combined max dependencies: 523805800 hardirq-safe locks: 1074 hardirq-unsafe locks: 575 softirq-safe locks: 1171 softirq-unsafe locks: 445 irq-safe locks: 1184 irq-unsafe locks: 575 hardirq-read-safe locks: 0 hardirq-read-unsafe locks: 68 softirq-read-safe locks: 17 softirq-read-unsafe locks: 55 irq-read-safe locks: 17 irq-read-unsafe locks: 68 uncategorized locks: 103 unused locks: 0 max locking depth: 16 max recursion depth: 11 debug_locks: 1 -- 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/