Date: Wed, 11 May 2016 11:54:46 -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: <20160511185446.GF76917@wkstn-mjohnston.west.isilon.com> In-Reply-To: <812C8B41-5996-41E3-9340-3EFC0C2AD5F5@juniper.net> References: <85861491-5F47-4448-B933-E1394C578646@juniper.net> <20160511164945.GB76917@wkstn-mjohnston.west.isilon.com> <812C8B41-5996-41E3-9340-3EFC0C2AD5F5@juniper.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, May 11, 2016 at 06:17:51PM +0000, Abhishek Kulkarni wrote: > Thanks very much Mark. Should I raise a bug about this on freebsd.org? That would be helpful, thanks. > > Regards > Abhishek Kulkarni > > > > > On 5/11/16, 9:49 AM, "Mark Johnston" <markjdb@gmail.com on behalf of markj@FreeBSD.org> wrote: > > >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?20160511185446.GF76917>