Date: Wed, 27 Mar 2013 18:07:14 -0400 From: "J.R. Oldroyd" <fbsd@opal.com> To: freebsd-current@freebsd.org Subject: DTrace of radeonkms on 9.1 Message-ID: <20130327180714.5beae7d6@shibato>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130327180714.5beae7d6>