From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jean Pihet Subject: Re: cpufreq: weird bug in set_time_scale Date: Thu, 11 Oct 2007 20:48:35 +0200 Message-ID: <200710112048.35567.jpihet@mvista.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: xen-devel@lists.xensource.com, "Langsdorf, Mark" List-Id: xen-devel@lists.xenproject.org Keir, On Thursday 11 October 2007 20:31:53 Keir Fraser wrote: > Yep, that case is not acceptable for the DIV instruction, because it caus= es > 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 <=3D MILLISECS(1000)). Indeed that nicely fixes the problem. > > =A0-- Keir Thanks, Jean > > On 11/10/07 19:14, "Jean Pihet" 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 > > =3D;-) but the result is 0, which does not seem correct. > > > > Should the assert in div_frac be changed to avoid weird results or cras= h? > > > > Regards, > > Jean > > > > On Thursday 11 October 2007 19:43:08 Keir Fraser wrote: > >> That's my code. I'll take a look! > >> > >> =A0K. > >> > >> On 11/10/07 16:55, "Langsdorf, Mark" wrote: > >>> On my test machine, in set_time_scale(), > >>> the following code: > >>> ts->mul_frac =3D div_frac(MILLISECS(1000), tps32); > >>> crashes with a division by zero error if > >>> tps32 =3D=3D 1000000000d. =A0Unfortunately, tps32 is > >>> often that value. > >>> > >>> Does anyone know why this happens? =A0I've > >>> resolved it temporarily by checking for > >>> tps32 =3D=3D 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