All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
To: Steven Seeger <sseeger@domain.hid>
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai-help] fpu issue
Date: Sat, 9 Feb 2008 14:29:41 +0100	[thread overview]
Message-ID: <18349.43717.622653.136257@domain.hid> (raw)
In-Reply-To: <51CAD0CE1504444DBE77CBBE51A0135D376AB6@domain.hid>

Steven Seeger wrote:
 > 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?

An idea is to disassemble the kernel task code and the function it calls
to see if FPU is really never used.

If this task really never calls any function using FPU, it would be nice
if you could (as we always ask, you may have noticed) reduce your test
case to a simple code where only FPU operations and every thing which
causes task switches (blocking calls, and calls waking up other tasks)
is kept.

-- 


					    Gilles Chanteperdrix.


  reply	other threads:[~2008-02-09 13:29 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-09  1:36 [Xenomai-help] fpu issue Steven Seeger
2008-02-09 13:29 ` Gilles Chanteperdrix [this message]
2008-02-10 15:32   ` Steven Seeger
2008-02-10 15:41     ` Gilles Chanteperdrix
2008-02-10 16:36     ` Gilles Chanteperdrix
  -- strict thread matches above, loose matches on Subject: below --
2009-01-20  4:25 Steven Seeger
2009-01-20  7:20 ` Gilles Chanteperdrix
2009-01-20 14:34   ` Steven Seeger
2009-01-20 14:49     ` Gilles Chanteperdrix
2009-01-20 14:55       ` Steven Seeger
2009-01-20 14:56         ` Gilles Chanteperdrix
2009-01-21  0:40           ` Steven Seeger
2009-01-21  9:28             ` Gilles Chanteperdrix
2009-01-21 13:30               ` Steven Seeger
2009-01-21 16:42               ` Steven Seeger
2009-01-21 16:48                 ` Gilles Chanteperdrix
2009-01-21 17:07                   ` Steven Seeger
2009-01-21 17:11                     ` Gilles Chanteperdrix
2009-01-21 17:16                       ` Steven Seeger
2009-01-21 17:42                       ` Steven Seeger
2009-01-21 18:01                         ` Gilles Chanteperdrix
2009-01-21 19:41                           ` Steven Seeger
2009-01-21 19:48                             ` Gilles Chanteperdrix
2009-01-21 20:05                               ` Steven Seeger
2009-01-21 20:08                               ` Steven Seeger
2009-01-21 20:45                               ` Steven Seeger
2009-01-21 20:47                               ` Steven Seeger
2009-01-21 21:13                                 ` Gilles Chanteperdrix
2009-01-21 21:20                                   ` Steven Seeger
2009-01-21 21:26                                     ` Gilles Chanteperdrix
2009-01-21 21:27                                       ` Steven Seeger
2009-01-21 21:44                                       ` Steven Seeger
2009-01-21 21:56                                         ` Gilles Chanteperdrix
2009-01-21 21:57                                           ` Steven Seeger
2009-01-26 16:13                                             ` Gilles Chanteperdrix
2009-01-21 16:43               ` Steven Seeger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=18349.43717.622653.136257@domain.hid \
    --to=gilles.chanteperdrix@xenomai.org \
    --cc=sseeger@domain.hid \
    --cc=xenomai@xenomai.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.