[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20100917180553.GC11576@localhost>
Date: Fri, 17 Sep 2010 20:05:53 +0200
From: Nils Radtke <lkml@...nk-future.de>
To: Maciej Rutecki <maciej.rutecki@...il.com>
Cc: Linux Kernel-Liste <linux-kernel@...r.kernel.org>
Subject: Re: INFO: inconsistent lock state
Hi,
That msg appeared on one of our notebooks, one which is very
prone to panic. Because of that I switched the lock checking
on for .35.4 . The machine tends to die of sucking the batts
empty while sleeping over night (that batt is ok..). Or it dies
when resuming from suspend or when using Xorg (submitted already
a bunch of reports on various issues, this beast is picky).
.35.4 is the first .35 running on this machine. Sorry, I just
checked, I only activated it for .35.4 . Config for .34 had
it still disabled.
Amongst others, those are now active:
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_MUTEXES=y
CONFIG_DEBUG_LOCK_ALLOC=y
CONFIG_PROVE_LOCKING=y
Would you mind giving advice on which else debug parameter
to activate w/o performance loss (it's a productive work place)?
Cheers,
Nils
On Thu 2010-09-16 @ 08-18-16PM +0200, Maciej Rutecki wrote:
# On poniedziałek, 13 września 2010 o 16:51:02 Nils Radtke wrote:
# > Hi,
# >
# > Got this in the logs:
# >
# > PM: Adding info for No Bus:vcs7
# > PM: Adding info for No Bus:vcsa7
# > initialized framebuffer f62c8580 with backing bo f62c0080
# >
# > =================================
# > [ INFO: inconsistent lock state ]
# > 2.6.35.4 #11
#
# Older versions works OK? eg. 2.6.35 or 2.6.34?
#
# --
# Maciej Rutecki
# http://www.maciek.unixy.pl
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists