Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758354Ab0GHRhW (ORCPT ); Thu, 8 Jul 2010 13:37:22 -0400 Received: from e7.ny.us.ibm.com ([32.97.182.137]:43362 "EHLO e7.ny.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755328Ab0GHRhU (ORCPT ); Thu, 8 Jul 2010 13:37:20 -0400 Subject: Re: 2.6.33.5 rt23: sleeping function called from invalid context From: john stultz To: Fernando Lopez-Lezcano Cc: Thomas Gleixner , LKML , rt-users , Steven Rostedt , Nick Piggin In-Reply-To: <1278561270.5448.2.camel@localhost.localdomain> References: <1278561270.5448.2.camel@localhost.localdomain> Content-Type: text/plain; charset="UTF-8" Date: Thu, 08 Jul 2010 10:37:04 -0700 Message-ID: <1278610624.3008.2.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1756 Lines: 47 On Wed, 2010-07-07 at 20:54 -0700, Fernando Lopez-Lezcano wrote: > After a suspend/wake up cycle, just after upgrading to fc12 (I did not > see this with the same basic kernel - that is, compiled from the same > source + patches - under fc11). > > BUG: sleeping function called from invalid context at > kernel/rtmutex.c:684 > pcnt: 0 0 in_atomic(): 0, irqs_disabled(): 1, pid: 10582, name: > pm-suspend > Pid: 10582, comm: pm-suspend Not tainted > 2.6.33.5-120.rt23.1.fc11.ccrma.i686.rtPAE #1 > Call Trace: > [] __might_sleep+0xcc/0xd4 > [] rt_spin_lock_fastlock.clone.1+0x26/0x5f > [] rt_spin_lock+0x8/0xa > [] read_persistent_clock+0x11/0x30 > [] timekeeping_suspend+0xe/0x4e > [] sysdev_suspend+0x15c/0x356 > [] ? _mutex_unlock+0x8/0xa > [] suspend_devices_and_enter+0xea/0x17f > [] enter_state+0xc8/0x114 > [] state_store+0x93/0xa7 > [] ? state_store+0x0/0xa7 > [] kobj_attr_store+0x16/0x22 > [] sysfs_write_file+0xbf/0xea > [] ? sysfs_write_file+0x0/0xea > [] vfs_write+0x80/0xdf > [] ? rt_up_read+0x13/0x15 > [] sys_write+0x3b/0x5d > [] sysenter_do_call+0x12/0x28 Huh. Looks like the lock protecting the RTC/CMOS might need to be converted to a raw spinlock, since suspend/resume is probably done with irqs off. A little baffled why the same kernel didn't see this with fc11. Does this reproduce easily? thanks -john -- 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/