lkml.org 
[lkml]   [2015]   [May]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: suspend regression in 4.1-rc1
On Mon, May 18, 2015 at 04:41:37PM +0200, Michal Hocko wrote:
> On Mon 18-05-15 10:26:07, Don Zickus wrote:
> > On Mon, May 18, 2015 at 06:56:46AM -0400, Ulrich Obergfell wrote:
> > >
> > > > There further appears to be a distinct lack of serialization between
> > > > setting and using watchdog_enabled, so perhaps we should wrap the
> > > > {en,dis}able_all() things in watchdog_proc_mutex.
> > >
> > > As I understand it, the {en,dis}able_all() functions are only called early
> > > at kernel startup, so I do not see how they could be racing with watchdog
> > > code that is executed in the context of write() system calls to parameters
> > > in /proc/sys/kernel. Please see also my earlier reply to Michal for further
> > > details: http://marc.info/?l=linux-pm&m=143194387208250&w=2
> > >
> > > Do we really need synchronization here?
> >
> > As Peter said we have to focus on doing things correctly and not based on
> > what is currently.
> >
> > During s2ram, I believe all the threads get parked and then unparked during
> > resume. I am wondering if the race happens there, threads get unparked and
> > stomp on each other when watchdog_nmi_enable_all() is called.
>
> Wouldn't that cause an issue during freezer mode of pm_test? I can see
> it much later in the processors mode.

I am not familiar with the freeze mode of pm_test. But I believe the
race only happens with cpu0. I would have thought cpu0 is slower to stop in
freezer mode than in s2ram. Again, this was just my initial guess at the
race problem. :-(

Peter seems to have a patch (and Uli too) that addresses this problem, so
not sure how much time to focus on figuring this out.

Cheers,
Don


\
 
 \ /
  Last update: 2015-05-18 18:21    [W:0.237 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site