ts_to_ct flood on 8.1-STABLE

[Andrew J. Caines]

Since installing 8.1-RC2 and now on up-to-date RELENG_8 I am frequently
getting kern.crit messages like

ts_to_ct(1281661818.743348859) = [2010-08-13 01:10:18]

and have been unable so far to determine their origin or purpose. I saw
no such messages while running 7.x or earlier releases.

AFAICT the system[1] is running fine. Athlon XP, 2GB, nVidia mobo and
GPU, Intel and Realtek NICs, various ATA and USB disks all in a custom
kernel. I've posted details of the system configuration[2].

Advice would be appreciated.

[1] http://halplant.com:2001/systems.html#HAL10000
[2] http://halplant.com:2001/server/config/HAL10000/

--
-Andrew J. Caines- Unix Systems Engineer A.J.C...@halplant.com
FreeBSD/Linux/Solaris, Web/Mail/Proxy/... http://halplant.com:2001/
"Machines take me by surprise with great frequency" - Alan Turing
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stabl...@freebsd.org"

[Jeremy Chadwick]

On Fri, Aug 13, 2010 at 06:16:01PM -0400, Andrew J. Caines wrote:
> Since installing 8.1-RC2 and now on up-to-date RELENG_8 I am frequently
> getting kern.crit messages like
>
> ts_to_ct(1281661818.743348859) = [2010-08-13 01:10:18]
>
> and have been unable so far to determine their origin or purpose. I saw
> no such messages while running 7.x or earlier releases.
>
> AFAICT the system[1] is running fine. Athlon XP, 2GB, nVidia mobo and
> GPU, Intel and Realtek NICs, various ATA and USB disks all in a custom
> kernel. I've posted details of the system configuration[2].
>
> Advice would be appreciated.
>
>
> [1] http://halplant.com:2001/systems.html#HAL10000
> [2] http://halplant.com:2001/server/config/HAL10000/

The source/responsible code for the printing is in function
clock_ts_to_ct() in:

src/sys/kern/subr_clock.c

181 void
182 clock_ts_to_ct(struct timespec *ts, struct clocktime *ct)
183 {
..
214 if (ct_debug) {
215 printf("ts_to_ct(%ld.%09ld) = ",
216 (long)ts->tv_sec, (long)ts->tv_nsec);
217 print_ct(ct);
218 printf("\n");
219 }

So what's ct_debug?

52 #define ct_debug bootverbose

Are your systems booting verbosely?

--
| Jeremy Chadwick j...@parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |

[Andrew J. Caines]

Jeremy,

Thanks for the quick response.

> The source/responsible code for the printing is in function
> clock_ts_to_ct() in: src/sys/kern/subr_clock.c

I took a look at the code in an attempt to divine the reason for the
frequent messages, without success.

Any idea why I see so many? I'm not aware of any special timing related
configuration. I do run ntpd, of course. In examples I've found, others
seem to get just the one ts_to_ct message.

> 52 #define ct_debug bootverbose Are your systems booting verbosely?

By default, yes. I'd like to keep it that way without having to hack the
source. Is there another option?

--
-Andrew J. Caines- Unix Systems Engineer A.J.C...@halplant.com
FreeBSD/Linux/Solaris, Web/Mail/Proxy/... http://halplant.com:2001/
"Machines take me by surprise with great frequency" - Alan Turing

[Jung-uk Kim]

On Friday 13 August 2010 06:50 pm, Andrew J. Caines wrote:
> Jeremy,
>
> Thanks for the quick response.
>
> > The source/responsible code for the printing is in function
> > clock_ts_to_ct() in: src/sys/kern/subr_clock.c
>
> I took a look at the code in an attempt to divine the reason for
> the frequent messages, without success.
>
> Any idea why I see so many? I'm not aware of any special timing
> related configuration. I do run ntpd, of course. In examples I've
> found, others seem to get just the one ts_to_ct message.
>
> > 52 #define ct_debug bootverbose Are your systems booting
> > verbosely?
>
> By default, yes. I'd like to keep it that way without having to
> hack the source. Is there another option?

If you are really annoyed by the messages, you may increase
'machdep.rtc_save_period' sysctl value to something larger. Default
is 1,800 seconds or 30 minutes. Also, you can completely disable it
by setting it to zero or 'machdep.disable_rtc_set' to non-zero value
but I would not recommend it. Still, it doesn't explain why you are
seeing the message more often, however. :-(

Jung-uk Kim