Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755197AbYLVUjn (ORCPT ); Mon, 22 Dec 2008 15:39:43 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753879AbYLVUjf (ORCPT ); Mon, 22 Dec 2008 15:39:35 -0500 Received: from rn-out-0910.google.com ([64.233.170.185]:44493 "EHLO rn-out-0910.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753783AbYLVUje (ORCPT ); Mon, 22 Dec 2008 15:39:34 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=sQQ1ZYLaMjsmbUIZyTcjYvmIWHtJcv4lla4cAx+U/TolKx2vF66fCqKZXXzwPYqUno F41/OuPdCZMSUqNIOwSc0UX2pJ5LhLtNvnzyyjgeyEoXCLsi+5C+c+if1pJxIy2GW1x1 vHVLQiXw8UCR/VFf+zVTGOlFsSgOXBX9hv5MQ= Message-ID: Date: Mon, 22 Dec 2008 21:39:32 +0100 From: "Fabio Comolli" To: "Thomas Gleixner" Subject: Re: TSC not updating after resume: Bug or Feature? Cc: "Ingo Molnar" , "Rafael J. Wysocki" , "Peter Zijlstra" , "Steven Rostedt" , dsaxena@plexity.net, LKML , "Dave Kleikamp" , toralf.foerster@gmx.de In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20081217172758.GA6010@trantor.hsd1.or.comcast.net> <20081218123924.GH25715@elte.hu> <200812182319.57235.rjw@sisk.pl> <20081222150021.GA13839@elte.hu> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3215 Lines: 104 Hi Thomas. On Mon, Dec 22, 2008 at 9:36 PM, Thomas Gleixner wrote: > On Mon, 22 Dec 2008, Thomas Gleixner wrote: >> On Mon, 22 Dec 2008, Ingo Molnar wrote: >> > * Thomas Gleixner wrote: >> > >> > > > By the way, I don't know if it matters but the problema happened with >> > > > in-kernel hibernation and also in out-of-tree TuxOnIce hibernation. >> > > > Maybe this can help debugging the issue, I don't know. >> > > >> > > Hmm, does not ring a bell here. Can you please apply the patch below to >> > > mainline and retest ? >> > >> > ... and he should send a dmesg after a suspend cycle, right? >> >> Yes :) >> >> I digged more in the bugzillas. Toralf added some debug to >> __update_sched_clock(): >> >> - max_clock = wrap_max(scd->clock, scd->tick_gtod + TICK_NSEC); >> + max_clock = scd->tick_gtod + TICK_NSEC; >> + if (scd->clock > max_clock) >> + printk(KERN_INFO "%d %d\n", scd->clock, max_clock); >> >> The interesting output is: >> >> Dec 14 21:55:55 n22 Back to C! >> Dec 14 21:55:55 n22 Extended CMOS year: 2000 >> Dec 14 21:55:55 n22 Force enabled HPET at resume >> Dec 14 21:55:55 n22 212611283 77 >> >> The 77 is totaly bogus and it's likely not just a truncation of the >> 64bit value because (scd->clock > max_clock) evaluates to true. This >> output is _AFTER_ timekeeping resume because the HPET force enable >> message comes from timekeeping resume. > > Seems I'm talking to myself, but I think I finally decoded the > mystery: > > resume() > cpufreq_resume() > tsc:time_cpufreq_notifier() > set_cyc2ns_scale() > sched_clock_idle_sleep_event() > sched_clock_tick() > ktime_get() > hpet_read() > > This happens _BEFORE_ timekeeping has resumed, so hpet_read() returns > nonsense and the timekeeping code uses the stale pre suspend > xtime/clocksource reference values to calculate the time. So the gtod > reference in sched_clock can result in total crap depending on the > time when the suspend happened. > > Shaggys patch clamps sched_clock to the stale scd->clock value which > might explain the further wreckage. > > The above sequence happens only for CPUs with a CPU frequency coupled > TSC, so on newer machines with CPU frequency invariant TSC this does > not happen. > > /me stomps off to find a box to confirm that. > Ok, just for reference here is my fcomolli@hawking:~> cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 13 model name : Intel(R) Pentium(R) M processor 1.73GHz stepping : 8 cpu MHz : 800.000 cache size : 2048 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe nx up bts est tm2 bogomips : 1596.95 clflush size : 64 power management: Regards, Fabio > Thanks, > > tglx > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/