[dtrace-discuss] suspend/resume and libdtrace consumers

[Chad Mynhier]

On Tue, Aug 26, 2008 at 2:24 PM, Rafael Vanoni <Rafael.Vanoni at sun.com> wrote:
> Hi all
>
> There was recently a couple of emails at tesla-dev pointing out that
> PowerTOP(1) and intrstat(1M) show 0'ed values after resuming - both are
> libdtrace(3LIB) consumers.
>
> I haven't found a bug against this issue, but unfortunately I'm having a
> bit of a hard time finding a system that supports suspend/resume and
> wouldn't like to file one w/o having some content to back it up.
>
> Does this sound like a libdtrace(3LIB) issue to you or should these
> consumers be a bit smarter ?

Rafael,

I have a system that supports suspend/resume, so I took a look at this.

Stripping this down to just the D script that's being run, I see this
after a suspend/resume:

# dtrace -s ./events_k.d
dtrace: script './events_k.d' matched 4 probes
dtrace: processing aborted: Abort due to systemic unresponsiveness
#

So what's likely happening is that the underlying DTrace invocation is
dying, but that the process is unaware of this.  And looking at the
code for PowerTOP, it appears that it's calling dtrace_status() but
ignoring the return value.  (Note that you can achieve the same effect
by stopping the powertop process for about a minute

I've posted a webrev of a fix here:
http://cr.opensolaris.org/~cmynhier/powertop/.

It looks like intrstat() does something similar.  I don't have a code
fix for this yet, but I've filed a bug.

Chad