Paul,
You are correct. Since it was such a small piece of code, I didn't use diff
between the kernel I am using (2.6.14) and the newest ones (2.6.28 on the
Linux). Also, I do not know how to look in the kernel files commit history.
I guess the link you gave me might be of some help.
Thanks for
davidastro writes:
> Basically, the numbers shown above was causing the 64 by 32 bit algorithm to
> divide by zero making the unit spin and also giving incorrect results.
> Here is the code as it was before.
[snip]
> cntlzw r0,r5 # we are shifting the dividend right
> l
On Fri, 2009-03-20 at 12:33 -0700, davidastro wrote:
> Hi Ben:
>
> I was wondering if you have any change to look into and test the propose fix
> I suggested in my previous post.
> I'd like to know if the fix is correct.
Sorry, I haven't had a chance yet. I will asap.
Ben.
> Thanks for your att
Hi Ben:
I was wondering if you have any change to look into and test the propose fix
I suggested in my previous post.
I'd like to know if the fix is correct.
Thanks for your attention,
Benjamin Herrenschmidt wrote:
>
> On Tue, 2009-03-17 at 14:15 -0700, davidastro wrote:
>> I found a bug when
Benjamin Herrenschmidt wrote:
>
> On Tue, 2009-03-17 at 14:15 -0700, davidastro wrote:
>> I found a bug when using the function __div64_32 in assembly in a 32 bit
>> ppc
>> architecture unit.
>>
>> I tried the numbers 5583456504800 for the dividend and 4294967079 for
>> the divisor. When pa
On Tue, 2009-03-17 at 14:15 -0700, davidastro wrote:
> I found a bug when using the function __div64_32 in assembly in a 32 bit ppc
> architecture unit.
>
> I tried the numbers 5583456504800 for the dividend and 4294967079 for
> the divisor. When passing these two numbers to the function __di
