[nos-bbs] Potential Timer Issue in JNOS
fish810
fish810 at yahoo.com
Sun Aug 1 23:15:22 EDT 2010
Looking more at msclock() in the NO_GETTOD section. Even though NO_GETTOD is
normally not defined, if it is defined:
struct timeb.millitm is defined as an unsigned short int (16 bits).
I'm pretty sure it's not a good idea to multiply it by 1000 and then add 100000
:-)
FiSH
#ifdef NO_GETTOD
static struct timeb t;
ftime(&t);
t.millitm *= 1000;
if (t.millitm < Starttime.tv_usec)
{
t.millitm += 1000000;
t.time--;
}
return (t.time - Starttime.tv_sec) * 1000 +
(t.millitm - Starttime.tv_usec) / 1000;
#else
________________________________
From: fish810 <fish810 at yahoo.com>
To: Maiko Langelaar (ve4klm) <maiko at pcs.mb.ca>
Cc: TAPR xNOS Mailing List <nos-bbs at tapr.org>
Sent: Sun, August 1, 2010 5:20:21 PM
Subject: Re: [nos-bbs] Potential Timer Issue in JNOS
Hi Maiko,
I just happened to notice that msclock(), defined in unix.c returns an
'int32'. msclock() computes the number of milliseconds since JNOS was started,
right? When that value rolls over, after ~24 days- could that cause what we
are seeing??
Sure hope it turns out to be that simple :-)
Regards,
FiSH
________________________________
From: Maiko Langelaar <maiko at pcs.mb.ca>
To: TAPR xNOS Mailing List <nos-bbs at tapr.org>
Sent: Sat, July 31, 2010 4:23:15 PM
Subject: Re: [nos-bbs] Potential Timer Issue in JNOS
Evening to all,
I'm working on it. I want it fixed too ...
Unfortunately it's not just a matter of setting the linux
clock ahead by 24 days and voila - problem surfaces. It's
a bit more complicated than that.
Maiko
_______________________________________________
nos-bbs mailing list
nos-bbs at tapr.org
https://www.tapr.org/cgi-bin/mailman/listinfo/nos-bbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/nos-bbs_lists.tapr.org/attachments/20100801/b21a9983/attachment.html>
More information about the nos-bbs
mailing list