From owner-freebsd-current@FreeBSD.ORG Wed Mar 27 22:07:25 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 02D0CA02 for ; Wed, 27 Mar 2013 22:07:25 +0000 (UTC) (envelope-from fbsd@opal.com) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by mx1.freebsd.org (Postfix) with ESMTP id CCB21679 for ; Wed, 27 Mar 2013 22:07:24 +0000 (UTC) Received: from pool-141-154-241-44.bos.east.verizon.net ([141.154.241.44] helo=homobox.opal.com) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UKyV4-000Ata-5M for freebsd-current@freebsd.org; Wed, 27 Mar 2013 22:07:18 +0000 Received: from shibato (shibato.opal.com [IPv6:2001:470:8cb8:4:221:63ff:fe5a:c9a7]) (authenticated bits=0) by homobox.opal.com (8.14.4/8.14.4) with ESMTP id r2RM7FxE045868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 27 Mar 2013 18:07:15 -0400 (EDT) (envelope-from fbsd@opal.com) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 141.154.241.44 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/H1NO0TNWKN2YM89/VQ1xZ Date: Wed, 27 Mar 2013 18:07:14 -0400 From: "J.R. Oldroyd" To: freebsd-current@freebsd.org Subject: DTrace of radeonkms on 9.1 Message-ID: <20130327180714.5beae7d6@shibato> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.6; amd64-portbld-freebsd9.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (homobox.opal.com [IPv6:2001:470:8cb8:4::1]); Wed, 27 Mar 2013 18:07:15 -0400 (EDT) X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, RP_MATCHES_RCVD shortcircuit=no autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on homobox.opal.com X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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: Wed, 27 Mar 2013 22:07:25 -0000 Is there any known magic involved in getting DTrace to do its thing on 9.1-release? I am trying to use it to debug a memory leak problem with the radeonkms driver under 9.x. Firstly, the following sequence works normally: boot system kldload drm2 kldload radeonkms start xorg stop xorg kldunload radeonkms kldunload drm2 The problem is that, when using xterm, there is a memory leak which shows as the Free mem counter in "top" reducing rapidly. The usual printf debugging isn't helping because we are in a heavily multi-threaded part of the driver and the printfs are being interleaved in the kernel buffer. DTrace's function boundary probes would be a big help if I could only get them to work. I've built a dtrace kernel per the instructions in the handbook and on the DTrace wiki page. I would now like to do this: boot system kldload dtraceall kldload drm2 dtrace -o dtrace.log -s script.d (the script will use fbt probes on various functions currently in the drm2 module) kldload radeonkms start xorg and do various things that provoke the leak stop xorg kldunload radeonkms kill the dtrace script kldunload drm2 kldunload dtraceall then go look at the log results. But, the system is stopping dead shortly after the radeonkms load. It also stops dead if I load radeonkms without starting the dtrace script. The presence of the dtraceall module appears to be causing the radeonkms module load to fail. Now the radeonkms module does initialize and switch the console to the graphics mode before the system stops. There is about 5-10 sec of what looks like the normal driver init sequence before the system stops. When the system stops there is no panic. It just stops dead. No keyboard/mouse, no netowrk/ssh - dead. A hard power-off and reboot is needed afterwards. It's perhaps worth mentioning that the leak I am trying to trace is probably not a simple malloc/free leak. There are no leak messages in the log after the normal module load/unload sequence. This driver also does VM allocs and manages its own pages and the problem could be there. Any suggestions on how to persuade DTrace to work would be great. Thanks, -jr