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.
next prev parent 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