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

[Joyeau Sylvain]

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 at ozlabs.org [mailto:linuxppc-embedded-bounces at ozlabs.org] On Behalf Of Jeremy Friesner
> Sent: lundi 6 février 2006 17:55
> To: Dan Malek
> Cc: linuxppc-embedded at ozlabs.org
> Subject: Re: Floating point math in kernel interrupt -- am I doing this right?(repost)
> 
> >
> > On Feb 5, 2006, at 9:29 PM, Jeremy Friesner wrote:
> >
> > > ....   and the mixing is done inside an
> > > interrupt routine that runs 6000 times per second, and calculates 8
> > > samples
> > > per interrupt.
> >
> > Bad news.  No Floating Point allowed in the kernel.
> 
> 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:
> 
> http://www.tldp.org/LDP/cpg/html/x295.html
> 
> 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?
> 
> > > In order to do the necessary floating point math, without corrupting
> > > 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
> > > math,
> > > then restores FPU registers again, before returning.
> >
> > Not on 82xx.  All floating point is done in hardware.
> 
> Right; it is the hardware registers' state that I am saving to the stack, and then restoring afterwards.
> 
> > > 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
> > 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.
> 
> 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.
> 
> Jeremy
> 
> 
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded at ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded