From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jean Pihet <jpihet@mvista.com>
Subject: Re: cpufreq: weird bug in set_time_scale
Date: Thu, 11 Oct 2007 20:14:43 +0200
Message-ID: <200710112014.43834.jpihet@mvista.com>
References: <C3341F3C.EBC9%Keir.Fraser@cl.cam.ac.uk>
Mime-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xensource.com>
In-Reply-To: <C3341F3C.EBC9%Keir.Fraser@cl.cam.ac.uk>
Content-Disposition: inline
List-Unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com
To: xen-devel@lists.xensource.com
Cc: "Langsdorf, Mark" <mark.langsdorf@amd.com>
List-Id: xen-devel@lists.xenproject.org

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