Rafael Vanoni <> wrote: > Sebastien Roy wrote: >> I'm generally confused about the state of power management and my >> Toshiba Portege r500 running build 122. There's a parallel thread >> discussing this on indiana-discuss, but I'm moving here as suggested >> by Aubrey. >> >> I have two possibly related issues: >> >> 1. When my cpupm setting is set to "enable" (without poll-mode), the >> P-State is always at its highest level as observed by powertop. >> When I add "poll-mode" to cpupm, it goes into lower P-States when >> the system is idle. >> >> 2. When my cpupm setting is set to "enable" (without poll-mode), the >> system refuses to suspend. It blanks the screen and stays up forever >> until I power it down manually. When I set it to "poll-mode", it >> suspends just fine. >> >> On a related note, when the system is idle, powertop reports that >> between 3-10% of events (over 100 per second) causing wakeups are >> due to <xcalls> unix`dtrace_xcall_func (presumably from powertop >> itself since it's the only thing using dtrace(?)). Does that make >> any sense? > > Yes, that's a long standing issue with powertop(1). The probe firings > from the idle state transitions happen very often, which fill up the > per CPU DTrace buffers. DTrace uses xcalls to sync these, and that's > displayed in the event report. We're working on fixing this problem. >
PowerTOP should not be the case that causes 100% highest p-state residency in idle. We have this bug "6818514 Event based CPUPM too easily shifts into high gear" fixed and putback since build 117 by rev#. 9802. It looks like it does not fix the problem. But if you always didn't see the lowest frequency residency when idle, there is probably another bug here. It would be great if Seb can post the powertop report here. Thanks, -Aubrey
