dtrace discuss - Nov 2005 - Abort due to systemic unresponsiveness

What is causing this error:

dtrace: processing aborted: Abort due to systemic unresponsiveness


It happens to my script which shows all the NFS operations coming 
through common_dispatch() on a server.

I wasn''t the one running the test, so I don''t know how long it
ran
before it died.
The script uses a couple of static probes and a couple fbt.

Thanks,

jim
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20051117/47fa8adf/attachment.html>

Jim Wahlig wrote:
> What is causing this error:
> dtrace: processing aborted: Abort due to systemic unresponsiveness
> It happens to my script which shows all the NFS operations coming 
> through common_dispatch() on a server.
> I wasn''t the one running the test, so I don''t know how
long it ran
> before it died.
> The script uses a couple of static probes and a couple fbt.
Jim,
your script is causing DTrace to hit its internal safety valves.
I''ve seen this when following an interrupt on my x64 motherboard
and while causing an interrupt storm :|


Was your server busy?


James C. McPherson
--
Solaris Datapath Engineering
Data Management Group
Sun Microsystems

On Thu, Nov 17, 2005 at 03:55:39PM -0600, Jim Wahlig
wrote:
> What is causing this error:
> 
> dtrace: processing aborted: Abort due to systemic unresponsiveness
This is the dtrace deadman timer;  if dtrace thinks that it may
be causing the system to become unresponsive, it will turn itself off. 
The criteria is:

	- an interrupt can fire once a second
	- The dtrace(1M) consumer can run once every thirty seconds

You can turn it off by enabling destructive actions (add a -w).

Cheers,
- jonathan

-- 
Jonathan Adams, Solaris Kernel Development

On Fri, Nov 18, 2005 at 09:12:39AM +1100, James C. McPherson
wrote:
> Jim Wahlig wrote:
> >What is causing this error:
> >dtrace: processing aborted: Abort due to systemic unresponsiveness
> >It happens to my script which shows all the NFS operations coming 
> >through common_dispatch() on a server.
> >I wasn''t the one running the test, so I don''t know
how long it ran
> >before it died.
> >The script uses a couple of static probes and a couple fbt.
> 
> Jim,
> your script is causing DTrace to hit its internal safety valves.
> I''ve seen this when following an interrupt on my x64 motherboard
> and while causing an interrupt storm :|
If this is a busy NFS server, it''s possible that it''s _so_
busy that
dtrace(1M) can''t run.  If dtrace(1M) can''t run for 40 seconds,
dtrace(7D)
will get nervous and abort the enabling.  If you believe that the machine
is otherwise functional, you can try running dtrace(1M) in the RT
scheduling class:

	# priocntl -e -c RT dtrace -s ./myscript.d
	...

This will allow dtrace(1M) to preempt your in-kernel NFS activity.  If
this still fails, then you have a very, very busy machine -- and if you
still believe that this is in error, you can enable destructive actions
(thereby disabling the deadman).  But (and this should go without saying)
be very careful doing this...

	- Bryan

--------------------------------------------------------------------------
Bryan Cantrill, Solaris Kernel Development.       http://blogs.sun.com/bmc