On Thu, Jun 6, 2013 at 7:12 AM, Alan Stern <st...@rowland.harvard.edu> 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
