Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753649Ab3FJVZY (ORCPT ); Mon, 10 Jun 2013 17:25:24 -0400 Received: from mail-qc0-f176.google.com ([209.85.216.176]:60230 "EHLO mail-qc0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752950Ab3FJVZV (ORCPT ); Mon, 10 Jun 2013 17:25:21 -0400 MIME-Version: 1.0 In-Reply-To: References: Date: Mon, 10 Jun 2013 14:25:20 -0700 X-Google-Sender-Auth: v0M-NcOi37pRRDNThOfFi26Icak Message-ID: Subject: Re: [RFC PATCHv2 1/2] drivers: power: Add watchdog timer to catch drivers which lockup during suspend/resume. From: Colin Cross To: Alan Stern Cc: Zoran Markovic , "Rafael J. Wysocki" , lkml , Linux PM list , Benoit Goby , Android Kernel Team , Todd Poynor , San Mehat , John Stultz , Pavel Machek , Len Brown , Greg Kroah-Hartman Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2338 Lines: 46 On Thu, Jun 6, 2013 at 7:12 AM, Alan Stern wrote: > On Wed, 5 Jun 2013, Zoran Markovic wrote: > >> > It does block in my environment, AFAICS. Looking a bit further in the >> > code, it looks like dpm_suspend() does an async_synchronize_full() >> > which would wait for all async tasks to complete. This is a >> > show-stopper because (under the circumstances) the assumption that >> > every async suspend routine eventually completes doesn't hold. >> > >> > We could possibly select which async tasks to wait for, but this would >> > add unnecessary complexity to a feature targeted for debugging. It >> > seems that this approach - although sounding reasonable - needs to >> > wait until we have a mechanism to cancel an async task. >> >> Looks like the implementation of proposal for an async suspend + >> wait_for_completion_timeout is quite complex due to above limitations. >> How do we proceed from here? We have the following options: >> 1. Give up on the idea of having a suspend/resume watchdog. >> 2. Use the timer implementation (with possible modifications). >> 3. Wait for the implementation of (or implement) killing of an already >> running async work. >> >> Are there any other ideas floating around? > > In general, the kernel is not designed to operate when kernel threads > get killed at random times. It's also not designed to operate normally > while in the middle of a system suspend. > > This means there is basically no hope of recovering from a hung async > suspend task. (In much the same way, there is no hope of recovering > from any hung kernel thread.) The best you can accomplish is to store > some useful information somewhere and either panic or force a reboot. > > Given that the usual storage media may be inaccessible, it may not be > easy to find a place to store the information. > > (By the way, what do you do if a _synchronous_ suspend routine hangs? > The two problems are fairly similar.) This is why the original patch dumped a stack trace of the offending task and panic'd. There is nothing else useful you can do. -- 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/