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>