From owner-freebsd-current@FreeBSD.ORG Tue Jun 13 02:15:46 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1862416A41F for ; Tue, 13 Jun 2006 02:15:46 +0000 (UTC) (envelope-from jb@what-creek.com) Received: from what-creek.com (what-creek.com [66.111.37.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id D15A843D46 for ; Tue, 13 Jun 2006 02:15:45 +0000 (GMT) (envelope-from jb@what-creek.com) Received: by what-creek.com (Postfix, from userid 102) id 8D01A78C1D; Tue, 13 Jun 2006 02:15:43 +0000 (GMT) Date: Tue, 13 Jun 2006 02:15:43 +0000 From: John Birrell To: current@freebsd.org Message-ID: <20060613021543.GA71283@what-creek.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: Subject: DTrace for FreeBSD - sources available via cvsup X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 02:15:46 -0000 Thanks to our p4 admins and cvsup hosts, the Perforce project containing DTrace changes is now available for CVSup from cvsup10.freebsd.org using the tag: p4-cvs-dtrace This is a full source tree which is updated to reflect CURRENT once or twice a week. **** This only applies to single processor i386 at the moment **** The GENERIC kernel has an additional option called KDTRACE which compiles in just the hooks that the DTrace modules require. Without that option you'll just get a vanilla kernel that should be as reliable as current is. WMMV. The boot loader menu has an extra option that lets you boot with the DTrace modules loaded. This is intended to allow anonymous traces which are still a work in progress. I'm working on getting the anon trace DOF into the kernel environment so that tracing can begin as soon as the modules are initialised by the kernel (which is pretty early on). With the development as it stands at the moment, take care using the FBT provider because you can easily cause the system to go kaboom. I'm still trying to track down the problems there. It's not in FBT itself -- just the fact that the DTrace probe context isn't allowed to call anything that FBT can instrument. If that happens you will either get a reboot or a double fault will leave you in kdb. I recommend only enabling a few FBT probes at a time just so you know which ones could cause a fault. There is no point telling me that you enabled fbt::: and the system went kaboom! If you get a double fault that drops you into kdb, type: p *dtrace_invop_addr and look up the address in an objdump of the kernel to find out what function it was in when the fault occurred. -- John Birrell