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 your help Paul Mackerras wrote: > > davidastro <davidas...@hotmail.com> 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 >> li r10,-1 # to make it < 2^32, and shifting >> srw r10,r10,r0 # the divisor right the same amount, >> add r9,r4,r10 # rounding up (so the estimate cannot >> andc r11,r6,r10 # ever be too large, only too small) >> andc r9,r9,r10 #THIS CODE COULD STORE A ZERO IN r9 >> or r11,r5,r11 >> rotlw r9,r9,r0 >> rotlw r11,r11,r0 > > That bug was fixed in October 2005 in commit 344480b99730bfd2, and the > fix is in v2.6.15-rc1 and all later kernels. I fixed it a bit > differently to your suggestion though - see > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=344480b99730bfd205e306d3fd168cdcebe83425 > > You must be working from an old kernel tree - which kernel version are > you using? > > Paul. > _______________________________________________ > Linuxppc-dev mailing list > Linuxppc-dev@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-dev > > -- View this message in context: http://www.nabble.com/Fix-for-__div64_32-locks-when-using-some-64-bit-numbers-tp22567864p22665081.html Sent from the linuxppc-dev mailing list archive at Nabble.com. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
