From owner-cvs-all Tue Dec 12 8:39:52 2000 From owner-cvs-all@FreeBSD.ORG Tue Dec 12 08:39:47 2000 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id C0A0937B69D; Tue, 12 Dec 2000 08:39:39 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by pike.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id eBCGdQE87551; Tue, 12 Dec 2000 08:39:27 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Tue, 12 Dec 2000 08:39:31 -0800 (PST) From: John Baldwin To: Bruce Evans Subject: Re: cvs commit: src/sys/kern kern_ktr.c Cc: cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 12-Dec-00 Bruce Evans wrote: > On Mon, 11 Dec 2000, John Baldwin wrote: > >> jhb 2000/12/11 16:43:50 PST >> >> Modified files: >> sys/kern kern_ktr.c >> Log: >> - Don't bother taking a trace message if we have panic'd since doing so >> can lead to further panics. >> - Call getnanotime() instead of nanotime() for the timestamp. nanotime() >> is more precise, but it also calls into the timer code, which results >> in mutex operations on the i386 arch. If KTR_LOCK is turned on, then > > Mutex operations actually resulted only on the i386 arch, only if the > i8254 timecounter was used (i.e., mainly on pre-PCI pre-Pentium > systems). Both the alpha and the i386 have an i8254 timecounter which > should use mutex operations, but the alpha version was copied from > the i386 version before mutex operations were added to the latter, > and it has rotted. It would crash both my dual P3-600 and my P3-700 laptop, so it wasn't limited to just pre-PCI. :-/ Granted, I have apm turned on (even though it doesn't work) for my laptop, which is why the TSC isn't used there, and we don't use the TSC on SMP systems at all. The alpha code probably does need to have clock_lock added to it. > High resolution kernel profiling has similar problems. mcount() and > mexitcount() need to be callable from almost anywhere, and they call > timer/counter code (cputime()) which needs to use locks for certain > timer/cointers (i8254, and maybe performance counters). Things > currently sort of work because the necessary locking is missing. > > Bruce -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message