Date: Mon, 1 Jan 2001 13:59:55 +0100 From: Alexander Langer <alex@big.endian.de> To: Bruce Evans <bde@zeta.org.au> Cc: arch@FreeBSD.ORG Subject: Re: (fwd) getnanouptime() patch Message-ID: <20010101135955.A4625@cichlids.cichlids.com> In-Reply-To: <Pine.BSF.4.21.0101012348420.9932-100000@besplex.bde.org>; from bde@zeta.org.au on Mon, Jan 01, 2001 at 11:54:36PM %2B1100 References: <20010101133438.A4214@cichlids.cichlids.com> <Pine.BSF.4.21.0101012348420.9932-100000@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Thus spake Bruce Evans (bde@zeta.org.au):
> Actually, timecounters are statically initialized to a dummy timecounter,
> so the lock-up is probably caused by some other bug, possibly an
> uninitialized event handler.
> So the patch has no effect except to slow down nanotime().
Oh. That is not good.
But I'm curious: Isn't the nanotime() function wrong, too, in this
case?
void
nanotime(struct timespec *ts)
{
unsigned count;
u_int64_t delta;
struct timecounter *tc;
nnanotime++;
tc = timecounter;
#ifdef KTR
if (tc == NULL) { /* called before initialization */
ts->tv_sec = 0;
ts->tv_nsec = 0;
return;
}
#endif
[....]
That's where I took the code from.
Alex
--
cat: /home/alex/.sig: No such file or directory
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010101135955.A4625>