cpufreq: weird bug in set_time_scale

cpufreq: weird bug in set_time_scale

[Langsdorf, Mark]

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

Re: cpufreq: weird bug in set_time_scale

[Keir Fraser]

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

Re: cpufreq: weird bug in set_time_scale

[Jean Pihet]

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

Re: cpufreq: weird bug in set_time_scale

[Keir Fraser]

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)).

 -- Keir

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
> 
> 

Re: cpufreq: weird bug in set_time_scale

[Jean Pihet]

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

RE: cpufreq: weird bug in set_time_scale

[Langsdorf, Mark]

> 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)).

Thanks, that fixed it.

-Mark Langsdorf
Operating System Research Center
AMD