Is there any way to capture the beginning of this trace? pid_param_set() is on the stack which means that something is changing the debugfs parameters or the stack is FUBAR. On 03/27/2013 06:49 PM, Parag Warudkar wrote:
I get this same oops occassionally - the machine freezes and there doesn't seem to be any record of the oops on disk.
That is - sample->pstate_pct_busy = 100 - div64_u64( sample->idletime_us * 100, sample->duration_us);
I don't see how duration_us can be zero unless somehow I am getting back-to-back timer callbacks which seems unlikely since the timer is not re-armed until the timer function is about to return and the driver has done all its work for the sample period --Dirk
So looks like sample->duration_us is 0? If so, that implies that ktime_us_delta(now, cpu->prev_sample) is zero. I am not entirely sure how to handle this case - return if sampling too early, or if there is some other bug making the delta calculation go poof. Thanks, Parag -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
-- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
