Messages in this thread | | | Date | Tue, 12 Jul 2016 06:12:04 -0700 | From | Viresh Kumar <> | Subject | Re: [Query] Preemption (hogging) of the work handler |
| |
+Rafael and linux-pm to this thread :)
On 12-07-16, 14:52, Petr Mladek wrote: > On Tue 2016-07-12 18:38:05, Sergey Senozhatsky wrote: > > Hello, > > > > On (07/11/16 15:35), Viresh Kumar wrote: > > [..] > > > Sometimes, the platform doesn't come back after suspend. I have tried > > > enabling no-console-suspend and the last line it prints is: > > > > > > Disabling non-boot CPUs > > I guess that the printk() kthread is not longer scheduled when there > is only one CPU left.
Yeah, so I tried debugging this more and I am able to get printing done to just before arch_suspend_disable_irqs() in suspend.c and then it stops because of the async nature.
I get to this point for both successful suspend/resume (where system resumes back successfully) and in the bad case (where the system just hangs/crashes).
FWIW, I also tried commenting out following in suspend_enter():
error = suspend_ops->enter(state);
so that the system doesn't go into suspend at all, and just resume back immediately (similar to TEST_CORE) and I saw the hang/crash then as well one of the times.
> We might try to explicitly flush the consoles in suspend_console().
That wouldn't happen as I have disabled console-suspend.
> But I am not sure if we always want to do so because it might take > a while. Also it need not help if someone already owns the > console_sem. Note the console_unlock() calls the cond_resched() > when in safe context. > > Well, we might do the best effort when no_console_suspend is enabled.
Hmm.. I have no reasoning yet on why the system comes to a complete stop and a forceful reboot only makes it work :(
-- viresh
| |