[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5153B03E.2050201@gmail.com>
Date: Wed, 27 Mar 2013 19:51:42 -0700
From: Dirk Brandewie <dirk.brandewie@...il.com>
To: Parag Warudkar <parag.lkml@...il.com>
CC: rjw@...k.pl, cpufreq@...r.kernel.org, linux-pm@...r.kernel.org,
linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
dirk.brandewie@...il.com
Subject: Re: intel_pstate_timer_func divide by zero oops
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@...r.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists