Date: Wed, 11 May 2016 09:49:45 -0700 From: Mark Johnston <markj@FreeBSD.org> To: Abhishek Kulkarni <abkulkarni@juniper.net> Cc: "freebsd-dtrace@freebsd.org" <freebsd-dtrace@freebsd.org> Subject: Re: Regarding Dtrace on Arm Message-ID: <20160511164945.GB76917@wkstn-mjohnston.west.isilon.com> In-Reply-To: <85861491-5F47-4448-B933-E1394C578646@juniper.net> References: <85861491-5F47-4448-B933-E1394C578646@juniper.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, May 07, 2016 at 08:55:56PM +0000, Abhishek Kulkarni wrote: > Hello All, > > I was using Dtrace using the FBT provider on an arm platform with witness enabled. When FBT is used with the kernel module, it generates a kernel panic or the system becomes unresponsive. Is this problem know or seen before. I am copying the kernel backtrace below for reference. The issue seems to be with a blockable sleep lock(kld_sx) acquired which is conflicting with the td->td_critnest positive value. Unfortunately, I think this is expected. The ARM port of DTrace will call into the kernel linker from probe context to perform stack unwinding. This is a bug since the kernel linker cannot be entered in arbitrary contexts - the thread might already hold the linker lock, or might hold a critical section as in your example. This is a known issue, but I'm not sure if anyone is working on fixing it. -Mark
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160511164945.GB76917>