[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 10:06 AM, Donald Allen
> 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
>> 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.
The system has been up almost four hours and time-keeping is working
fine, so your suggestion to switch to another source of ticks has
fixed my problem.
I'd also like to mention that I've had this machine for a few years
now, and, in addition to Linux, I have tried OpenBSD and FreeBSD on it
(both of which were abandoned for good reasons, which I won't go into
here). I had no problems with time-keeping with them, either. So
you've got a couple of BSD references, in addition to Linux, for ideas
on working around the TSC issue.
Again, thanks very much for your help.
> Thanks for your help.
>> 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
Main Index |
Thread Index |