[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090501031320.GA4300@spacedout.fries.net>
Date: Thu, 30 Apr 2009 22:13:20 -0500
From: David Fries <david@...es.net>
To: john stultz <johnstul@...ibm.com>
Cc: Ingo Molnar <mingo@...e.hu>,
linux-kernel <linux-kernel@...r.kernel.org>,
Thomas Gleixner <tglx@...x.de>
Subject: Re: TSC marked unstable on suspend and resume
On Wed, Apr 29, 2009 at 08:37:33PM -0700, john stultz wrote:
> On Wed, 2009-04-29 at 18:25 -0500, David Fries wrote:
> > On Wed, Apr 29, 2009 at 09:45:40AM -0700, john stultz wrote:
> > > On Fri, Feb 20, 2009 at 7:39 PM, David Fries <david@...es.net> wrote:
> > > > I'm getting TSC marked as unsable on hibernate to disk with
> > > > 2.6.29-rc3. ?The last kernel I ran 2.6.24.4 ran 300+ days without a
> > > > problem and does not loose TSC on hibernate.
> > > >
> > > > I'm hibernating with `echo disk > /sys/power/state`.
> > > > These look like the relavant messages,
> > > >
> > > > CPU 0 irqstacks, hard=c0379000 soft=c0378000
> > > > PID hash table entries: 1024 (order: 10, 4096 bytes)
> > > > Fast TSC calibration using PIT
> > > > Detected 300.705 MHz processor.
> > > > Calibrating delay loop (skipped), value calculated using timer frequency.. 601.41 BogoMIPS (lpj=300705)
> > > > hibernate to disk,
> > > > Restarting tasks ... done.
> > > > Clocksource tsc unstable (delta = 499883531 ns)
> > >
> > > Hmm. Seems like the clocksource watchdog is having some problem
> > > handling state around hibernate.
>
> Yea. This seems to be the case here. There's watchdog code and variables
> to handle resume properly, but there isn't a corresponding suspend hook,
> so the resume path doesn't actually change anything.
>
> Here's a patch you can try, I only had time to compile test it today, so
> its untested. Hopefully I didn't miss anything obvious.
>
> Thomas, I suspect you intended to have something like the following?
>
> Signed-off-by: John Stultz <johnstul@...ibm.com>
I added my own patch to verify your changes were being called, no
dice. I do wonder, is it too late when the clocksource_suspend is
called after Suspending consoles? Any theories why this is the only
system I have that is showing the problem? It is an older system.
In the attached dmesg dump I suspended without a swap file, so it
never hibernated or rebooted.
diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c
index 7575f23..387fed4 100644
--- a/kernel/time/clocksource.c
+++ b/kernel/time/clocksource.c
@@ -261,6 +261,7 @@ void clocksource_suspend(void)
spin_lock_irqsave(&clocksource_lock, flags);
clocksource_suspend_watchdog();
spin_unlock_irqrestore(&clocksource_lock, flags);
+ printk("Calling %s\n", __func__);
}
/**
--
David Fries <david@...es.net>
http://fries.net/~david/ (PGP encryption key available)
Download attachment "clocksource_suspend.txt.bz2" of type "application/octet-stream" (4502 bytes)
Powered by blists - more mailing lists