RE: Floating point math in kernel interrupt -- am I doing this right?(repost)

Jeremy,

What about kernel stack overflow ?
You mention that the occurrence of the crash is proportional to the =
amount of embraced code, which generally use more stack space too... but =
you aren't very accurate about the call context of your DoMix() =
function: it can be called depth enough to tickle the interrupted thread =
control block and issue indirect spurious behavior is userland.
Hope this help.

--
sj

-----Original Message-----
From: linuxppc-embedded-bounces@ozlabs.org =

[mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of Jeremy =
Friesner

Sent: lundi 6 f=E9vrier 2006 17:55
To: Dan Malek
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Floating point math in kernel interrupt -- am I doing =

this right?(repost)

=20

quoted

On Feb 5, 2006, at 9:29 PM, Jeremy Friesner wrote:

quoted

....   and the mixing is done inside an
interrupt routine that runs 6000 times per second, and calculates =

8

quoted

quoted

samples
per interrupt.

Bad news.  No Floating Point allowed in the kernel.

=20
I'm aware of that rule, and also why -- because the Linux kernel =

doesn't want to have to save and restore the state of the

floating point registers on every context switch.  I'm also aware that =

it is nonetheless possible to use floating point in

the kernel if you are careful to manually save and restore the proper =

state yourself, and that in fact floating point is

sometimes used in the kernel as a means of doing 64-bit writes, as =

mentioned here:

=20
http://www.tldp.org/LDP/cpg/html/x295.html
=20
So it seems to me that it is possible to do floating point in the =

kernel, if you are careful to save and restore the proper

context/state before and afterwards.  But if it isn't, can you explain =

to me why it can't be made to work?

=20

quoted

quoted

In order to do the necessary floating point math, without =

corrupting

quoted

quoted

the state
of any other processes that might be using the FPU, the interrupt
routine
first saves the state of the FPU registers to the stack, then does =

the

quoted

quoted

math,
then restores FPU registers again, before returning.

Not on 82xx.  All floating point is done in hardware.

=20
Right; it is the hardware registers' state that I am saving to the =

stack, and then restoring afterwards.

=20

quoted

quoted

So my question is, is there some minor detail that my
FPU-state-save/restore
code is missing, that would cause these sort of symptoms?

Just get all of this out of the kernel.  If you used the standard =

ALSA

quoted

drivers and framework, lots of mixing features are available to you.
If you need some custom mixing, just write a plug-in to do it.
Your data rates are so low they don't justify making any hacks
like this.

=20
I suppose that is an option, but I'd rather understand why my hack =

isn't working before I give up and redesign my

application, which is already working the way I want it to, 99.9999% =

of the time.

=20
Jeremy
=20
=20
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded