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 _______________________________________________ dtrace-discuss mailing list [email protected]
