I found the source of my fpu issue. A single kernel module with two
tasks was also active. I noticed the failure occurred whenever sound
would play. (This is one of the tasks.) It seems the problem is that the
sound task doesn't use the FPU, so I didn't turn on T_FPU. The tone task
(not in use at that time) does, so it has T_FPU. When I turned on T_FPU
for the sound task, I never saw the problem again. With it off, if I
played sound while running the program, I'd regularly see the
corruption.

 

Here is the task code:

 

static void sound_func(void *data)

{       

    for (;;) //go until suspended or thread deletion

    { 

        if (play==stop) //time to stop if this happens

        {

            unsigned long evt = 0;

            

            play=stop=0; // just in case

            rt_event_clear(&sound_event, SOUND, 0);

            rt_task_set_periodic(&sound_task, TM_NOW, TM_INFINITE); /*
disable periodic mode */

            rt_event_wait(&sound_event, SOUND, &evt, EV_ALL,
TM_INFINITE);

            rt_task_set_periodic(&sound_task, TM_NOW,
rt_timer_ns2ticks(ST_AUDIO_PERIOD));

        }

        

#if BUFSIZE != 65536

        if (play==BUFSIZE) play=0;

#endif

        

        if(rt_task_wait_period(0)) rt_task_wait_period(0); //wait for
next tick and ignore overruns (do the best we can)

        // Since the index is incrementd subtract 2 from the size before
comparing the index

        

        outb(buf[play++], DAC_ADDRESS); //send the next byte to the dac

    }

}

 

The buffer is filled with a linux userland process and an appropriate
wait queue. This same code worked fine in RTAI without the FPU flag.

 

I've tested this for several minutes.

 

Any idea?

 

Steven

 

_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help

Reply via email to