Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754121Ab2BVIpj (ORCPT ); Wed, 22 Feb 2012 03:45:39 -0500 Received: from e23smtp01.au.ibm.com ([202.81.31.143]:48565 "EHLO e23smtp01.au.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750788Ab2BVIph (ORCPT ); Wed, 22 Feb 2012 03:45:37 -0500 Message-ID: <4F44AB09.9000606@linux.vnet.ibm.com> Date: Wed, 22 Feb 2012 14:14:57 +0530 From: "Srivatsa S. Bhat" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0) Gecko/20120131 Thunderbird/10.0 MIME-Version: 1.0 To: John Stultz CC: "Rafael J. Wysocki" , Linux PM list , LKML , Magnus Damm , markgross@thegnar.org, Matthew Garrett , Greg KH , =?UTF-8?B?QXJ2ZSBIasO4bm5ldsOlZw==?= , Brian Swetland , Neil Brown , Alan Stern , Dmitry Torokhov Subject: Re: [RFC][PATCH 0/7] PM: Implement autosleep and "wake locks", take 2 References: <201202070200.55505.rjw@sisk.pl> <201202220031.46219.rjw@sisk.pl> <1329886179.2229.2.camel@js-netbook> In-Reply-To: <1329886179.2229.2.camel@js-netbook> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit x-cbid: 12022122-1618-0000-0000-000000DDAF98 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4915 Lines: 120 On 02/22/2012 10:19 AM, John Stultz wrote: > On Wed, 2012-02-22 at 00:31 +0100, Rafael J. Wysocki wrote: >> Hi all, >> >> After the feedback so far I've decided to follow up with a refreshed patchset. >> The first two patches from the previous one went to linux-pm/linux-next >> and I included the recent evdev patch from Arve (with some modifications) >> to this patchset for completness. > > Hey Rafael, > Thanks again for posting this! I've started playing around with it in a > kvm environment, and got the following warning after echoing off > > autosleep: > ... > PM: resume of devices complete after 185.615 msecs > PM: Finishing wakeup. > Restarting tasks ... done. > PM: Syncing filesystems ... done. > PM: Preparing system for mem sleep > Freezing user space processes ... > Freezing of tasks failed after 20.01 seconds (1 tasks refusing to freeze, wq_busy=0): > bash D ffff880015714010 Ah.. I think I know what is the problem here.. The kernel was freezing userspace processes and meanwhile, you wrote "off" to autosleep. So, as a result, this userspace process (bash) just now entered kernel mode. Unfortunately, the autosleep_lock is held for too long, that is, something like: acquire autosleep_lock modify autosleep_state <============== "A" pm_suspend or hibernate() release autosleep_lock At point marked "A", we should have released the autosleep lock and only then entered pm_suspend or hibernate(). Since the current code holds the lock and enters suspend/hibernate, the userspace process that wrote "off" to autosleep (or even userspace process that writes to /sys/power/state will end up waiting on autosleep_lock, thus failing the freezing operation.) So the solution is to always release the autosleep lock before entering suspend/hibernation. Regards, Srivatsa S. Bhat > =============================== > [ INFO: suspicious RCU usage. ] > 3.3.0-rc3john+ #131 Not tainted > ------------------------------- > kernel/sched/core.c:4784 suspicious rcu_dereference_check() usage! > > other info that might help us debug this: > > > rcu_scheduler_active = 1, debug_locks = 0 > 5 locks held by kworker/u:1/10: > #0: (autosleep){.+.+.+}, at: [] process_one_work+0x2d8/0x8c0 > #1: (suspend_work){+.+.+.}, at: [] process_one_work+0x2d8/0x8c0 > #2: (autosleep_lock){+.+.+.}, at: [] try_to_suspend+0x2d/0xe0 > #3: (pm_mutex){+.+.+.}, at: [] pm_suspend+0x8c/0x210 > #4: (tasklist_lock){.+.+..}, at: [] try_to_freeze_tasks+0x2d1/0x400 > > stack backtrace: > Pid: 10, comm: kworker/u:1 Not tainted 3.3.0-rc3john+ #131 > Call Trace: > [] ? vprintk+0x242/0x530 > [] lockdep_rcu_suspicious+0xeb/0x100 > [] sched_show_task+0x121/0x180 > [] try_to_freeze_tasks+0x3c5/0x400 > [] ? pm_autosleep_set_state+0x80/0x80 > [] freeze_processes+0x3b/0xb0 > [] pm_suspend+0x13d/0x210 > [] try_to_suspend+0x4d/0xe0 > [] process_one_work+0x422/0x8c0 > [] ? process_one_work+0x2d8/0x8c0 > [] ? put_lock_stats+0xe/0x40 > [] worker_thread+0x476/0x550 > [] ? rescuer_thread+0x200/0x200 > [] kthread+0xae/0xc0 > [] kernel_thread_helper+0x4/0x10 > [] ? retint_restore_args+0x13/0x13 > [] ? __init_kthread_worker+0x70/0x70 > [] ? gs_change+0x13/0x13 > 0 1981 1980 0x00020004 > ffff880015715d88 0000000000000046 ffff880015715c88 ffffffff8102c22b > ffff880015714010 ffff880015715fd8 ffff880015714010 ffff880015714000 > ffff880015715fd8 ffff880015714000 ffff880015c4e3c0 ffff88001342e540 > Call Trace: > [] ? kvm_clock_read+0x6b/0x90 > [] ? mark_held_locks+0xad/0x150 > [] schedule+0x3f/0x60 > [] mutex_lock_nested+0x1cb/0x4c0 > [] ? pm_autosleep_set_state+0x1e/0x80 > [] ? pm_autosleep_set_state+0x1e/0x80 > [] pm_autosleep_set_state+0x1e/0x80 > [] autosleep_store+0x3b/0x80 > [] kobj_attr_store+0x17/0x20 > [] sysfs_write_file+0xec/0x170 > [] vfs_write+0x11f/0x1b0 > [] sys_write+0x54/0xa0 > [] sysenter_dispatch+0x7/0x26 > [] ? trace_hardirqs_on_thunk+0x3a/0x3f > > Restarting tasks ... done. > > > -- 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/