All of lore.kernel.org
 help / color / mirror / Atom feed
From: Parag Warudkar <parag.lkml@gmail.com>
To: rjw@sisk.pl, cpufreq@vger.kernel.org, linux-pm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, torvalds@linux-foundation.org
Subject: intel_pstate_timer_func divide by zero oops
Date: Wed, 27 Mar 2013 21:49:13 -0400 (EDT)	[thread overview]
Message-ID: <alpine.LFD.2.03.1303272103380.8412@gmail.com> (raw)

I get this same oops occassionally - the machine freezes and there doesn't 
seem to be any record of the oops on disk.

I captured it on camera - 
https://lh3.googleusercontent.com/-K0lNbJrZBMQ/UVOU1vv1vvI/AAAAAAAANqI/pY92mWm3caE/s800/20130327_205245.jpg

If I am reading this right, it dies on this instruction -

   0xffffffff8145792d <+349>:   divq   0x18(%rcx)

From the lst file that *seems* to be this inline function -

static inline void intel_pstate_calc_busy(struct cpudata *cpu,
                                        struct sample *sample)
{
        u64 core_pct;
        sample->pstate_pct_busy = 100 - div64_u64(
ffffffff8145791d:       48 8b 41 20             mov    0x20(%rcx),%rax
ffffffff81457921:       48 8d 04 80             lea    (%rax,%rax,4),%rax
ffffffff81457925:       48 8d 04 80             lea    (%rax,%rax,4),%rax
ffffffff81457929:       48 c1 e0 02             shl    $0x2,%rax
ffffffff8145792d:       48 f7 71 18             divq   0x18(%rcx)


That  is -
	sample->pstate_pct_busy = 100 - div64_u64(
					sample->idletime_us * 100,
					sample->duration_us);

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

WARNING: multiple messages have this Message-ID (diff)
From: Parag Warudkar <parag.lkml@gmail.com>
To: rjw@sisk.pl, cpufreq@vger.kernel.org, linux-pm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, torvalds@linux-foundation.org
Subject: intel_pstate_timer_func divide by zero oops
Date: Wed, 27 Mar 2013 21:49:13 -0400 (EDT)	[thread overview]
Message-ID: <alpine.LFD.2.03.1303272103380.8412@gmail.com> (raw)

I get this same oops occassionally - the machine freezes and there doesn't 
seem to be any record of the oops on disk.

I captured it on camera - 
https://lh3.googleusercontent.com/-K0lNbJrZBMQ/UVOU1vv1vvI/AAAAAAAANqI/pY92mWm3caE/s800/20130327_205245.jpg

If I am reading this right, it dies on this instruction -

   0xffffffff8145792d <+349>:   divq   0x18(%rcx)

>From the lst file that *seems* to be this inline function -

static inline void intel_pstate_calc_busy(struct cpudata *cpu,
                                        struct sample *sample)
{
        u64 core_pct;
        sample->pstate_pct_busy = 100 - div64_u64(
ffffffff8145791d:       48 8b 41 20             mov    0x20(%rcx),%rax
ffffffff81457921:       48 8d 04 80             lea    (%rax,%rax,4),%rax
ffffffff81457925:       48 8d 04 80             lea    (%rax,%rax,4),%rax
ffffffff81457929:       48 c1 e0 02             shl    $0x2,%rax
ffffffff8145792d:       48 f7 71 18             divq   0x18(%rcx)


That  is -
	sample->pstate_pct_busy = 100 - div64_u64(
					sample->idletime_us * 100,
					sample->duration_us);

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

             reply	other threads:[~2013-03-28  1:49 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-28  1:49 Parag Warudkar [this message]
2013-03-28  1:49 ` intel_pstate_timer_func divide by zero oops Parag Warudkar
2013-03-28  2:51 ` Dirk Brandewie
2013-03-28  3:13   ` Parag Warudkar
2013-03-28 15:35     ` Dirk Brandewie
2013-03-28 18:25       ` Parag Warudkar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LFD.2.03.1303272103380.8412@gmail.com \
    --to=parag.lkml@gmail.com \
    --cc=cpufreq@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=rjw@sisk.pl \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.