Chad Mynhier wrote: > On Tue, Aug 26, 2008 at 2:24 PM, Rafael Vanoni <[EMAIL PROTECTED]> 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
Thanks for looking into this Chad, I'm moving this thread to tesla-dev to discuss the patch. Rafael _______________________________________________ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
