From: Jean Pihet <jpihet@mvista.com>
To: Keir Fraser <Keir.Fraser@cl.cam.ac.uk>
Cc: xen-devel@lists.xensource.com, "Langsdorf,
Mark" <mark.langsdorf@amd.com>
Subject: Re: cpufreq: weird bug in set_time_scale
Date: Thu, 11 Oct 2007 20:48:35 +0200 [thread overview]
Message-ID: <200710112048.35567.jpihet@mvista.com> (raw)
In-Reply-To: <C3342AA9.EBDA%Keir.Fraser@cl.cam.ac.uk>
Keir,
On Thursday 11 October 2007 20:31:53 Keir Fraser wrote:
> Yep, that case is not acceptable for the DIV instruction, because it causes
> overflow of the quotient. It's fixed by xen-unstable changeset 16098.
>
> It's a one-char fix: the loop on (tps32 < MILLISECS(1000)) needs to be
> (tps32 <= MILLISECS(1000)).
Indeed that nicely fixes the problem.
>
> -- Keir
Thanks,
Jean
>
> On 11/10/07 19:14, "Jean Pihet" <jpihet@mvista.com> wrote:
> > Hi,
> >
> > The problem is in divl instruction which throws a 'Floating point
> > exception'. In the case below the dividend and the divisor are equal. Is
> > that allowed by the instruction?
> >
> > On the ARM code that we are currently implementing, there is no crash
> > =;-) but the result is 0, which does not seem correct.
> >
> > Should the assert in div_frac be changed to avoid weird results or crash?
> >
> > Regards,
> > Jean
> >
> > On Thursday 11 October 2007 19:43:08 Keir Fraser wrote:
> >> That's my code. I'll take a look!
> >>
> >> K.
> >>
> >> On 11/10/07 16:55, "Langsdorf, Mark" <mark.langsdorf@amd.com> wrote:
> >>> On my test machine, in set_time_scale(),
> >>> the following code:
> >>> ts->mul_frac = div_frac(MILLISECS(1000), tps32);
> >>> crashes with a division by zero error if
> >>> tps32 == 1000000000d. Unfortunately, tps32 is
> >>> often that value.
> >>>
> >>> Does anyone know why this happens? I've
> >>> resolved it temporarily by checking for
> >>> tps32 == 1000000000 and changing the
> >>> value slightly (101000010d works fine
> >>> on my test machine), but I'm not sure
> >>> if that's the approved approach for Xen.
> >>>
> >>> -Mark Langsdorf
> >>> Operating System Research Center
> >>> AMD
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> Xen-devel mailing list
> >>> Xen-devel@lists.xensource.com
> >>> http://lists.xensource.com/xen-devel
> >>
> >> _______________________________________________
> >> Xen-devel mailing list
> >> Xen-devel@lists.xensource.com
> >> http://lists.xensource.com/xen-devel
next prev parent reply other threads:[~2007-10-11 18:48 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-11 15:55 cpufreq: weird bug in set_time_scale Langsdorf, Mark
2007-10-11 17:43 ` Keir Fraser
2007-10-11 18:14 ` Jean Pihet
2007-10-11 18:31 ` Keir Fraser
2007-10-11 18:48 ` Jean Pihet [this message]
2007-10-11 19:45 ` Langsdorf, Mark
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=200710112048.35567.jpihet@mvista.com \
--to=jpihet@mvista.com \
--cc=Keir.Fraser@cl.cam.ac.uk \
--cc=mark.langsdorf@amd.com \
--cc=xen-devel@lists.xensource.com \
/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.