Date: Wed, 11 May 2016 18:17:51 +0000 From: Abhishek Kulkarni <abkulkarni@juniper.net> To: Mark Johnston <markj@FreeBSD.org> Cc: "freebsd-dtrace@freebsd.org" <freebsd-dtrace@freebsd.org> Subject: Re: Regarding Dtrace on Arm Message-ID: <812C8B41-5996-41E3-9340-3EFC0C2AD5F5@juniper.net> In-Reply-To: <20160511164945.GB76917@wkstn-mjohnston.west.isilon.com> References: <85861491-5F47-4448-B933-E1394C578646@juniper.net> <20160511164945.GB76917@wkstn-mjohnston.west.isilon.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Thanks very much Mark. Should I raise a bug about this on freebsd.org? 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?812C8B41-5996-41E3-9340-3EFC0C2AD5F5>