From owner-freebsd-arch Mon Jan 1 10:47:42 2001 From owner-freebsd-arch@FreeBSD.ORG Mon Jan 1 10:47:39 2001 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id E77C137B400 for ; Mon, 1 Jan 2001 10:47:37 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id FAA06655; Tue, 2 Jan 2001 05:47:22 +1100 Date: Tue, 2 Jan 2001 05:48:14 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Alexander Langer Cc: arch@FreeBSD.ORG Subject: Re: (fwd) getnanouptime() patch In-Reply-To: <20010101135955.A4625@cichlids.cichlids.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 1 Jan 2001, Alexander Langer wrote: > 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 This is bogus at best. `timecounter' is never NULL unless there is a bug switching it. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message