NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: kern/45626: System time does not advance correctly when noatime is specified for /var



On Fri, Nov 18, 2011 at 9:33 AM, Manuel Bouyer 
<bouyer%antioche.eu.org@localhost> wrote:
>
> On Fri, Nov 18, 2011 at 01:25:03PM +0000, Donald Allen wrote:
> >  [...]
> >  sysctl -a | grep kern.timecounter
> >
> >  which I did:
> >
> >  kern.timecounter.choice = TSC(q=3000, f=67750617510 Hz) clockinterrupt(q=0,
> >  f=100 Hz) ichlpcib0(q=1000, f=3579545 Hz) hpet0(q=2000, f=14318179 Hz)
> >  ACPI-Fast(q=1000, f=3579545 Hz) lapic(q=-100, f=266097187 Hz) i8254(q=100,
> >  f=1193182 Hz) dummy(q=-1000000, f=1000000 Hz)
> >  kern.timecounter.hardware = TSC
> >  kern.timecounter.timestepwarnings = 0
>
> TSC is clearly wrong here, I'm sure you don't have a 67Ghz CPU :)

That's certainly true.

I've got NetBSD installed next to Slackware Linux on this machine,
running the 3.0.8 kernel from kernel.org. I've had no problem with
time-keeping in Linux on the machine, so out of curiosity, I brought
Linux up and had a look at the dmesg:

dca@salome:~$ sudo dmesg | fgrep TSC
[    0.000000] Fast TSC calibration failed
[    0.000000] TSC: PIT calibration matches HPET. 1 loops
[    1.336163] Refined TSC clocksource calibration: 2393.976 MHz.

I could be wrong, but that suggests to me that the Linux kernel
noticed the TSC oddness and somehow compensated. Perhaps a look at
what they're doing is in order.
>
> >
> >  He also suggested trying
> >
> >  sysctl -w kern.timecounter.hardware=hpet0
> >  >
> >  > and see if that fixes it.
> >  >
> >
> >  It does:
> > [...]
> >  However, after doing this, the system behaved in odd ways. I had trouble
> >  shutting X down, the system seemed not to be hearing the (USB) keyboard (I
> >  couldn't log in after doing ctrl-alt-f2). I finally got it shut down and
> >  rebooted, ending this experiment.
> >
> >  I then decided to try a newer kernel, and installed the kernel from the
> >  11/17 snapshot. Upon booting the system this morning (with all the file
> >  systems, including /var, mounted async,noatime), I quickly observed the
> >  clock problem.
>
> You should try setting
> kern.timecounter.hardware=hpet0
> in /etc/sysctl.conf, so that the change is applied at boot.
> The odd behavior you see may be caused by processes started before
> the timecounter change.

That makes sense.

I've made the change you suggested to /etc/sysctl.conf and brought the
system back up. I will use it for my work today and keep an eye on the
time-keeping. So far it's working fine.

Thanks for your help.

/Don

>
> You can also try other available timecounters (try ichlpcib0 or i8254
> for exampe).
>
> --
> Manuel Bouyer <bouyer%antioche.eu.org@localhost>
>     NetBSD: 26 ans d'experience feront toujours la difference
> --


Home | Main Index | Thread Index | Old Index