Anything special with 64 Bit Operations in Kernel?

Anything special with 64 Bit Operations in Kernel?

[Wolfgang Wegner]

Hi,

sorry if this is off-topic because "a bit" x86-centric, but i have some
problems since using 64-bit operations in kernel-space (especially: in
interrupt context), and am wondering if there might be any special issues.

What i do quite often is a 64-bit/32-bit division, and also some other
calculations, and now i found out that my code hangs the machine because
of a "divide error" (that's what the oops prints to the console prior
to the halt, sysrq keeps working). All "division by zero" errors are from
my knowledge avoided correctly.

It *seems* that more/other problems happen when the code is running on
an athlon, but unfortunately there are also different distribution
releases (and thus gcc versions) involved, so i am still unsure there.
(And don't have all machines under my control to make it uniform)

I did not find any references on problems specific to 64-bit operations,
so in case anyone also experienced strange behaviour - be it processor,
compiler or kernel - or knows a place where i could look, please let
me know!
My main problem is that these events occur only occasionally, so it is
a bit difficult to give an accurate example.

Thanks,
Wolfgang

P.S.:
Another point: we had to change
static s64 st_pll_mult(s32 var1, s32 var2, s8 frac1, s8 frac2, s8 frac_res)
to
static void st_pll_mult(s64 * retval, s32 var1, s32 var2, s8 frac1, s8 frac2, s8 frac_res)
because else the resulting s64 is sometimes overwritten by something else,
depending on the code around the function call.
(don't know all compiler versions, but i was using gcc-2.95.3 from SuSE 7.3
and can reproduce this)
Should i release the kernel from the suspicion and try another compiler? :)

Re: Anything special with 64 Bit Operations in Kernel?

[george anzinger]

Wolfgang Wegner wrote:
> 
> Hi,
> 
> sorry if this is off-topic because "a bit" x86-centric, but i have some
> problems since using 64-bit operations in kernel-space (especially: in
> interrupt context), and am wondering if there might be any special issues.
> 
> What i do quite often is a 64-bit/32-bit division, and also some other
> calculations, and now i found out that my code hangs the machine because
> of a "divide error" (that's what the oops prints to the console prior
> to the halt, sysrq keeps working). All "division by zero" errors are from
> my knowledge avoided correctly.

This is caused by overflow.  The div results in a number
that will not fit in 32-bits.

In all archs, there is a file (.../include/asm/div64.h) that
defines a function (do_div(n,base)) that does a (64-bit
n)/(32-bit base) with a 64-bit result.  Watch out, however,
as the result is returned in "n" with the function value
being the remainder (32-bit).  This will not overflow, but
when you take the low 32-bits of the result, you are
ignoring the fact that the result is bigger than 32-bits.

-g
> 
> It *seems* that more/other problems happen when the code is running on
> an athlon, but unfortunately there are also different distribution
> releases (and thus gcc versions) involved, so i am still unsure there.
> (And don't have all machines under my control to make it uniform)
> 
> I did not find any references on problems specific to 64-bit operations,
> so in case anyone also experienced strange behaviour - be it processor,
> compiler or kernel - or knows a place where i could look, please let
> me know!
> My main problem is that these events occur only occasionally, so it is
> a bit difficult to give an accurate example.
> 
> Thanks,
> Wolfgang
> 
> P.S.:
> Another point: we had to change
> static s64 st_pll_mult(s32 var1, s32 var2, s8 frac1, s8 frac2, s8 frac_res)
> to
> static void st_pll_mult(s64 * retval, s32 var1, s32 var2, s8 frac1, s8 frac2, s8 frac_res)
> because else the resulting s64 is sometimes overwritten by something else,
> depending on the code around the function call.
> (don't know all compiler versions, but i was using gcc-2.95.3 from SuSE 7.3
> and can reproduce this)
> Should i release the kernel from the suspicion and try another compiler? :)
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
George Anzinger   george@mvista.com
High-res-timers: 
http://sourceforge.net/projects/high-res-timers/
Preemption patch:
http://www.kernel.org/pub/linux/kernel/people/rml