linux-kernel - Re: Clock incorrect on 2.6.31-rc2

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1247181779.3259.6.camel@work-vm>
Date:	Thu, 09 Jul 2009 16:22:59 -0700
From:	john stultz <johnstul@...ibm.com>
To:	Stephen Hemminger <shemminger@...tta.com>
Cc:	Thomas Gleixner <tglx@...utronix.de>, linux-kernel@...r.kernel.org
Subject: Re: Clock incorrect on 2.6.31-rc2

On Thu, 2009-07-09 at 15:38 -0700, Stephen Hemminger wrote:
> On Thu, 9 Jul 2009 14:58:37 -0700
> john stultz <johnstul@...ibm.com> wrote:
> 
> > On Thu, Jul 9, 2009 at 2:10 PM, Stephen Hemminger<shemminger@...tta.com> wrote:
> > > My system (desktop Ubuntu 9.0) runs fine with 2.6.30, but with 2.6.31-rc2 it does
> > > not keep time correctly. Also ntptime reports an error.
> > 
> > Can you better describe how it does not keep time? Is time moving too
> > slow? too fast?
> 
> The clock just seemed to stop, or be wildly stuck in past.

Hrmm. And the box continues to function? If the clock stops, so does
timers, which will usually make a box seem to be totally hung.

>>From the messages below, it doesn't seem to be stopped.

> > Could you include output from the following commands with 2.6.31-rc2
> > (and 2.6.30 if you have the time).
> >  $ cat /sys/devices/system/clocksource/clocksource0/current_clocksource
> >  $ cat /sys/devices/system/clocksource/clocksource0/available_clocksource
> >  $ dmesg
> >  $ ntpdc -c peers
> >  $ ntpdc -c kerninfo
> 
> $ cat /sys/devices/system/clocksource/clocksource0/available_clocksource 
> tsc hpet acpi_pm 
> $ cat /sys/devices/system/clocksource/clocksource0/current_clocksource 
> tsc


Ok. One thing to check is if the issue goes away if you either boot with
"clocksource=acpi_pm" or run

echo acpi_pm > /sys/devices/system/clocksource/clocksource0/current_clocksource

> # ntpdc -c peers
>      remote           local      st poll reach  delay   offset    disp
> =======================================================================
> *ussprometheus.r 192.168.1.3      2  128  377 0.09094  0.007730 0.06786

You don't seem to be very far off right now. Only 7ms. And it seems you
have gone into NTP sync state (the * denotes that). 

I'm guessing ntptime no longer gives you errors now?

> # ntpdc -c kerninfo
> pll offset:           0.005107 s
> pll frequency:        155.028 ppm
> maximum error:        0.219122 s
> estimated error:      0.007209 s
> status:               0001  pll
> pll time constant:    7
> precision:            1e-06 s
> frequency tolerance:  500 ppm

This all looks normal.



> $ dmesg
> [    0.000000] Linux version 2.6.31-rc2 (shemminger@...alam) (gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4) ) #149 SMP Tue Jul 7 18:22:50 PDT 2009
[snip]
> [    0.000000] Fast TSC calibration using PIT
> [    0.000000] Detected 2673.143 MHz processor.

You might watch from boot to boot if the above MHz is varying by too
much.

Everything else looks ok.


I'm a little stumped.  Does the problem occur on every reboot? How long
does the box need to be up before you see an issue?  Or does it go away
after a little while?

thanks
-john


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/