On Tue, Jul 31, 2012 at 12:16 PM, Tom Gundersen wrote:

On Tue, Jul 31, 2012 at 1:09 PM, Jorge Almeida wrote:

...

Anybody knows how to make sure that the kernel will not mess with the hardware clock every 11 minutes? The proper way would be to use a kernel that doesn't try to do it, but I want to use Arch's standard kernel, which has CONFIG_GENERIC_CMOS_UPDATE=y. Maybe something in /proc?

As far as I know the only thing that will trigger 11-minute-mode is that an ntp client tells the kernel that it is running.

I found in http://www.mail-archive.com/questions@lists.ntp.org/msg02172.html that "echo 0 > /proc/sys/kernel/time/rtc_update" would do it, but we don't have /proc/sys/kernel/time/. Maybe this info is outdated, or it requires the PPSkit patch... Thanks J.A.

* Myra Nelson [31.07.2012 18:43]:

On Tue, Jul 31, 2012 at 6:39 AM, Jorge Almeida wrote:

...

On Tue, Jul 31, 2012 at 12:16 PM, Tom Gundersen wrote:

...

On Tue, Jul 31, 2012 at 1:09 PM, Jorge Almeida wrote:

...

Anybody knows how to make sure that the kernel will not mess with the hardware clock every 11 minutes? The proper way would be to use a kernel that doesn't try to do it, but I want to use Arch's standard kernel, which has CONFIG_GENERIC_CMOS_UPDATE=y. Maybe something in /proc?

As far as I know the only thing that will trigger 11-minute-mode is that an ntp client tells the kernel that it is running.

I found in http://www.mail-archive.com/questions@lists.ntp.org/msg02172.html that "echo 0 > /proc/sys/kernel/time/rtc_update" would do it, but we don't have /proc/sys/kernel/time/. Maybe this info is outdated, or it requires the PPSkit patch...

Thanks

J.A.

This is interesting. My problem isn't every 11 minutes, it's spastic, and it started somewhere in the 3.3 to 3.4 range. I'll look up and my system time is off by a multiple of 11 minutes but sometimes up to an hour and half.

I've been working on the following assumptions:

The problem was a bad cmos battery and waiting to get one ordered Since it occurred more frequently coming out of suspension, it was something to do with my s2ram setup. This is why I (mistakenly) tried the uresume hook in my initramfs image.

The problem was based on hangs during rcu updates. I compiled a debugging kernel and seem to have a large number of them, and I was getting a lot of [ tsc clocksource unstable ]. Not yet sure if that's due to a buggy bios or a hardware problem.

Looks like I've got some more research todo.

Myra

I'm not entirely sure, but I sometimes have skips when playing a video or audio file with mplayer (although the system is idle, no heavy cpu usage) but not if playing an audio file with mpd. Could this be caused by this? I do have ntp running...

On Tue, Jul 31, 2012 at 9:05 PM, Rodrigo Rivas wrote:

On Tue, Jul 31, 2012 at 1:09 PM, Jorge Almeida wrote:

...

Anybody knows how to make sure that the kernel will not mess with the hardware clock every 11 minutes? The proper way would be to use a kernel that doesn't try to do it, but I want to use Arch's standard kernel, which has CONFIG_GENERIC_CMOS_UPDATE=y. Maybe something in /proc?

"Use the source, Luke!"

In the kernel source you can see that this option is only used in kernel/time/ntp.c, and it affects only the system call "adjtimex".

And from "man adjtimex", it looks like it is called from ntp clients of the like... More investigation required...

The contents of Documentation/rtc.txt don't help much, either. And what about adjtime(3), which is used by clockspeed? Does it trigger this imaginative behavior too? This kind of stuff just should be documented... Thanks Jorge