public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Pavel Machek <pavel@suse.cz>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Fabio Comolli <fabio.comolli@gmail.com>,
	Ingo Molnar <mingo@elte.hu>, "Rafael J. Wysocki" <rjw@sisk.pl>,
	Steven Rostedt <srostedt@redhat.com>,
	dsaxena@plexity.net, LKML <linux-kernel@vger.kernel.org>,
	Dave Kleikamp <shaggy@linux.vnet.ibm.com>,
	toralf.foerster@gmx.de
Subject: Re: TSC not updating after resume: Bug or Feature?
Date: Fri, 26 Dec 2008 09:47:21 +0100	[thread overview]
Message-ID: <1230281241.9487.266.camel@twins> (raw)
In-Reply-To: <20081224140900.GA1624@ucw.cz>

On Wed, 2008-12-24 at 15:09 +0100, Pavel Machek wrote:
> Hi!
> > > >
> > > > Can please you revert the last patch and apply the following ? Does
> > > > the WARN_ON trigger ?
> > > >
> > 
> > > Yes, it does:
> >  
> > > [  159.768005]  [<c01389a2>] getnstimeofday+0x21/0xcd
> > > [  159.768005]  [<c0135e26>] ktime_get_ts+0x1d/0x3f
> > > [  159.768005]  [<c0135e57>] ktime_get+0xf/0x2b
> > > [  159.768005]  [<c013736b>] sched_clock_tick+0x46/0x83
> > > [  159.768005]  [<c01373ad>] sched_clock_idle_wakeup_event+0x5/0xa
> > > [  159.768005]  [<c0108670>] set_cyc2ns_scale+0x3f/0x5e
> > > [  159.768005]  [<c01088af>] time_cpufreq_notifier+0xf9/0x103
> > > [  159.768005]  [<c0136782>] notifier_call_chain+0x2a/0x52
> > > [  159.768005]  [<c0136866>] __srcu_notifier_call_chain+0x35/0x4a
> > > [  159.768005]  [<c0136884>] srcu_notifier_call_chain+0x9/0xc
> > > [  159.768005]  [<c031cbca>] cpufreq_resume+0xf3/0x112
> > > [  159.768005]  [<c028c3f3>] __sysdev_resume+0x24/0x34
> > > [  159.768005]  [<c028c421>] sysdev_resume+0x1e/0x50
> > 
> > Thanks for testing. It's exaclty the code path I described :)
> > 
> > So my code analysis holds and your test confirms my suspicion that
> > Shaggy's patch just unearthed some other weirdness in the
> > suspend/resume code.
> > 
> > Can you please apply the following hack^Wpatch and retest ? It
> > restores Shaggys patch, but prevents the sched_clock_tick() call when
> > timekeeping is not resumed. The WARN_ON should not longer trigger
> > except there is some other code path which fiddles with that as well.
> > 
> > If I'm not completely nuts then this should solve your suspend/resume
> > problem really instead of papering over the root cause.
> 
> Should we move timekeeping resume before cpufreq resume, instead of this?

That seems a sensible suggestion (but I've got no clue on how practical
that is). A quick look at the boot code suggests that regular bootups
have that sequence as well, so mirroring that in the resume code seems
like the best all-round solution.

  reply	other threads:[~2008-12-26  8:47 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-17 17:27 TSC not updating after resume: Bug or Feature? Deepak Saxena
2008-12-17 17:50 ` Steven Rostedt
2008-12-18  9:24   ` Peter Zijlstra
2008-12-18 12:39     ` Ingo Molnar
2008-12-18 22:19       ` Rafael J. Wysocki
2008-12-18 22:25         ` Dave Kleikamp
2008-12-18 23:39           ` Rafael J. Wysocki
2008-12-21 16:26         ` Thomas Gleixner
2008-12-21 19:43           ` Thomas Gleixner
2008-12-21 22:43             ` Fabio Comolli
2008-12-22 14:48               ` Thomas Gleixner
2008-12-22 15:00                 ` Ingo Molnar
2008-12-22 18:47                   ` Thomas Gleixner
2008-12-22 20:36                     ` Thomas Gleixner
2008-12-22 20:39                       ` Fabio Comolli
2008-12-22 21:13                         ` Thomas Gleixner
2008-12-22 21:35                           ` Fabio Comolli
2008-12-22 22:05                             ` Thomas Gleixner
2008-12-22 22:12                               ` Fabio Comolli
2008-12-22 22:16                                 ` Thomas Gleixner
2008-12-22 22:29                                   ` Fabio Comolli
2008-12-22 22:33                                     ` Thomas Gleixner
2008-12-23  0:28                                       ` Rafael J. Wysocki
2008-12-23 19:42                                       ` Fabio Comolli
2008-12-24 14:09                               ` Pavel Machek
2008-12-26  8:47                                 ` Peter Zijlstra [this message]
2008-12-22 20:19                 ` Fabio Comolli
2008-12-21 20:54           ` Thomas Gleixner
2008-12-23  0:47           ` Rafael J. Wysocki
2008-12-23  7:03             ` Thomas Gleixner
2008-12-23 14:15               ` Rafael J. Wysocki
2008-12-21 21:19 ` Thomas Gleixner
2008-12-23 22:03   ` Deepak Saxena

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1230281241.9487.266.camel@twins \
    --to=peterz@infradead.org \
    --cc=dsaxena@plexity.net \
    --cc=fabio.comolli@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=pavel@suse.cz \
    --cc=rjw@sisk.pl \
    --cc=shaggy@linux.vnet.ibm.com \
    --cc=srostedt@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=toralf.foerster@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox