From owner-freebsd-arch Mon Jan 1 4:54:13 2001 From owner-freebsd-arch@FreeBSD.ORG Mon Jan 1 04:54:12 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 B31A237B400 for ; Mon, 1 Jan 2001 04:54:10 -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 XAA30442; Mon, 1 Jan 2001 23:53:44 +1100 Date: Mon, 1 Jan 2001 23:54:36 +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: <20010101133438.A4214@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: > [per suggestion by Chris Faulhaber, I'm forwarding this to -arch] > > Hello! > > I have this old mail from BDE sitting here about the print_uptime() > bugs. One of these bugs is: > > - the implementation is buggy. getnanouptime() accesses uninitialized > pointers when it is called before timecounters have been > initialized. > This causes recursive panics which lock up at least my systems (boot > with -d and decide you didn't want to boot this kernel after all, > and type "panic" at the debugger prompt -- this locks up the system). 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(). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message