[Xenomai-help] invalid use of FPU in Xenomai context

[Xenomai-help] invalid use of FPU in Xenomai context

[Jeff Webb]

I made some more progress in porting my RTLinux application, but now I'm spinning my wheels trying to track down the source of the following error:

  "invalid use of FPU in Xenomai context at ..."

I am doing floating point calculations inside a real-time POSIX thread in kernel-space.  I am puzzled because I can create a simple test program that uses floating point operations in a real-time thread without any errors.  I create the task with something like this:

      pthread_attr_init(&attr);
      pthread_attr_setfp_np(&attr, 1);
      result = pthread_create(&fptest_task, &attr, &fptest_routine, NULL);

In fact, it seems that the fp attribute is already 1 by default, because I get no floating point errors if I leave out the pthread_attr_setfp_np line.  I do get an error if I do this:

  pthread_attr_setfp_np(&attr, 0);

I am doing the same thing in my much more complicated real-time application.  In fact, I can even insert a loop with some floating-point code at the beginning of my thread, and it works fine.  The problem is that something in my application code is triggering the "invalid use of FPU" error.

Does anyone have any ideas of what could trigger this besides not setting the fp attribute for the thread?

Thanks,

Jeff

Re: [Xenomai-help] invalid use of FPU in Xenomai context

[Philippe Gerum]

On Thu, 2006-09-14 at 17:47 -0500, Jeff Webb wrote:
> I made some more progress in porting my RTLinux application, but now I'm spinning my wheels trying to track down the source of the following error:
> 
>   "invalid use of FPU in Xenomai context at ..."

This message also gives the faulty location/symbol+offset. Where does it
point to?

-- 
Philippe.

Re: [Xenomai-help] invalid use of FPU in Xenomai context

[Jeff Webb]

Philippe Gerum wrote:
> On Thu, 2006-09-14 at 17:47 -0500, Jeff Webb wrote:
>> I made some more progress in porting my RTLinux application, but now I'm spinning my wheels trying to track down the source of the following error:
>>
>>   "invalid use of FPU in Xenomai context at ..."
> 
> This message also gives the faulty location/symbol+offset. Where does it
> point to?

It's coming from some simple floating point operations in my application code.  The relevant code snippet is:

  print_msg(TRACE_MSG, "rt_delay_sim\n");
  print_msg(INFO_MSG, "jeff rt_delay: 1\n");
  actual_dt = sim_dt / rt_speed_factor + rt_skew_correction;
  print_msg(INFO_MSG, "jeff rt_delay: 2\n");

The kernel message output is:

  Sep 15 09:17:34 kernel: rt_delay_sim
  Sep 15 09:17:34 kernel: jeff rt_delay: 1
  Sep 15 09:17:34 kernel: invalid use of FPU in Xenomai context at [fc264152]
  Sep 15 09:17:34 kernel: Xenomai: suspending kernel thread c1ca3730 ('c1ca3730') at
  0xfc264152 after exception #7

The variables in question are doubles.  The faulty location offset is somewhere in the rt_delay_sim routine, as you would expect from the output above.  This specific code does not appear to be the problem, though.  If I remove the call to the rt_delay_sim routine, I simply get a floating point exception in another location.

The strange thing is that I can do a loop of floating point operations at the beginning of my real-time thread without any problem:

  for (i=0; i<1001; i++)
    {
      f = f * 1.0 + 0.1;
    };  
  print_msg(INFO_MSG, "f = %d\n", (int)f);

but once I get into my real application code, I get the above error after executing several floating point operations.  My 'real application code' is actually a linked list of routines that reside in other kernel modules.  I wish I could come up with a simple example that caused the same problem...  I will keep trying.

As I said before, I am porting an application that works properly under RTLinux GPL, and am making some small changes to compile with Xenomai POSIX threads/timers and RTAI FIFOs.

Thanks,

Jeff

Re: [Xenomai-help] invalid use of FPU in Xenomai context

[Gilles Chanteperdrix]

Jeff Webb wrote:
 > Does anyone have any ideas of what could trigger this besides not setting the fp attribute for the thread?

What version of Xenomai do you use ? I have updated the FPU support very
recently, so it would be interesting to know if you also get the error
when applying or reverting this change.

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-help] invalid use of FPU in Xenomai context

[Jeff Webb]

Gilles Chanteperdrix wrote:
> Jeff Webb wrote:
>  > Does anyone have any ideas of what could trigger this besides not setting the fp attribute for the thread?
> 
> What version of Xenomai do you use ? I have updated the FPU support very
> recently, so it would be interesting to know if you also get the error
> when applying or reverting this change.

I am using Xenomai-2.2.2 with the two RTAI FIFO patches posted by Philippe a few days ago.  Do you have a patch that undoes the changes?  I could probably figure out how to generate one from subversion, if you know the revision of the change.  I do need the recent FIFO patches for the rest of my application to work properly, or I would just try an old version.  

I am using the 2.4 x86 UP kernel, if that makes any difference.

Thanks,

-Jeff

 

Re: [Xenomai-help] invalid use of FPU in Xenomai context

[Jeff Webb]

Gilles Chanteperdrix wrote:
> Jeff Webb wrote:
>  > Gilles Chanteperdrix wrote:
>  > > Jeff Webb wrote:
>  > >  > Does anyone have any ideas of what could trigger this besides not setting the fp attribute for the thread?
>  > > 
>  > > What version of Xenomai do you use ? I have updated the FPU support very
>  > > recently, so it would be interesting to know if you also get the error
>  > > when applying or reverting this change.
>  > 
>  > I am using Xenomai-2.2.2 with the two RTAI FIFO patches posted by Philippe a few days ago.  Do you have a patch that undoes the changes?  I could probably figure out how to generate one from subversion, if you know the revision of the change.  I do need the recent FIFO patches for the rest of my application to work properly, or I would just try an old version.  
>  > 
>  > I am using the 2.4 x86 UP kernel, if that makes any difference.
> 
> Sorry, sent the wrong patch. Try this one.

Unfortunately, I get the same results with this patch applied.  I haven't been able to isolate the problem yet.  I did discover that putting in a clock_nanosleep call at certain points in my simulation loop allowed the loop to execute to completion without any FPU errors.  Maybe this is a clue...  I do still get an FPU error message at some point after the main simulation loop is done, though.

Any more ideas regarding the source of my problem?  In my main loop, I am doing a few floating point calculations, stuffing some data to an RTAI FIFO, and then calling clock_nanosleep to wait for the next cycle.

Thanks,

Jeff

Fw: [Fwd: Re: [Xenomai-help] invalid use of FPU in Xenomai context]

[Jeff Webb]

[-- Attachment #1: Type: text/plain, Size: 2216 bytes --]

Jeff Webb wrote:
> Unfortunately, I get the same results with this patch applied.  I 
> haven't been able to isolate the problem yet.  I did discover that 
> putting in a clock_nanosleep call at certain points in my simulation 
> loop allowed the loop to execute to completion without any FPU errors.  
> Maybe this is a clue...  I do still get an FPU error message at some 
> point after the main simulation loop is done, though.

Okay...  I have found a simple example that exhibits the problem on my
linux-2.4 system (see attached).  I am running xenomai 2.2.2 with the two RTAI
FIFO patches (and the latest FPU-related patch).  I get two unresolved
math-related symbols when I try to insert this module on my FC5 2.6 machine,
so I can't comment on the linux-2.6 behavior at this time.  But that's a
puzzle for another day...

When I insert the attached module, I get the following kernel log output:

Sep 15 17:30:08 kernel: fptest_init
Sep 15 17:30:08 kernel: rtf_create returned: 1
Sep 15 17:30:08 kernel: invalid use of FPU in Xenomai context at [f1f410a4]
Sep 15 17:30:08 kernel: Xenomai: suspending kernel thread efe22d30
('efe22d30') at 0xf1f410a4 after exception #7
Sep 15 17:30:08 kernel: spawned task

Removing the module yields:

Sep 15 17:30:13 kernel: fptest_cleanup
Sep 15 17:30:13 kernel: rtf_destroy returned: 0
Sep 15 17:30:13 kernel: f = 1

If I change the rtf_put command to output 500 bytes instead of 5000, the
program works as expected:

Sep 15 17:29:54 simhost kernel: fptest_init
Sep 15 17:29:54 simhost kernel: rtf_create returned: 1
Sep 15 17:29:54 simhost kernel: loop 0, f=1
Sep 15 17:29:54 simhost kernel: spawned task
Sep 15 17:29:55 simhost kernel: loop 1, f=2
Sep 15 17:29:56 simhost kernel: loop 2, f=3
Sep 15 17:29:57 simhost kernel: loop 3, f=4
Sep 15 17:29:58 simhost kernel: loop 4, f=5
Sep 15 17:29:59 simhost kernel: loop 5, f=6
Sep 15 17:30:00 simhost kernel: fptest_cleanup
Sep 15 17:30:00 simhost kernel: rtf_destroy returned: 0
Sep 15 17:30:00 simhost kernel: f = 6

Does this mean there is some FPU-related problem in the RTAI FIFO code?

Thanks,

Jeff


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


[-- Attachment #2: fptest3k.c --]
[-- Type: text/x-csrc, Size: 1965 bytes --]


/* Linux kernel includes */
#include <linux/module.h>

/* Xenomai includes */
#include <pthread.h>
#include <time.h>
#include <rtai/fifo.h>

/* RTAI FIFO numbers /dev/rtf? */
#define FIFO1 3

/* Global variables */
pthread_t fptest_task = NULL;
double f = 0.0;

/* Real-time task */
void * fptest_routine (void *cookie)
{  
  struct timespec dt_ts;

  int i;
  char c[6000];

  for (i=0; i<101; i++)
    {
      /* Do a floating point calclation */
      f = f * 1.0 + 1.1;

      /* Stuff some (garbage) data in a FIFO */
      rtf_put(FIFO1, c, 5000);

      /* Print message to the kernel log */
      if (i % 1 == 0)
	{
	  printk("loop %d, f=%d\n", i, (int)f);
	}

      /* Sleep for 1 second */
      dt_ts.tv_sec  = 1;
      dt_ts.tv_nsec = 0;      
      clock_nanosleep(CLOCK_REALTIME, 0, &dt_ts, NULL);
    };

  return NULL;
}

static int fptest_init(void)
{
  int err;
  pthread_attr_t attr;
 
  printk("fptest_init\n");

  /* Create an FIFO */
  err = rtf_create(FIFO1, 1024*1024*1);
  printk("rtf_create returned: %d\n", err);
  if (err < 0)
    {
      printk("could not create FIFO\n");
      return -1;
    }

  /* Create a real-time task */
  pthread_attr_init(&attr);
  pthread_attr_setfp_np(&attr, 1);
  err = pthread_create(&fptest_task, &attr, &fptest_routine, NULL);
  if (err)
    {
      printk("could not create thread (error code: %d)\n", err);
      err = rtf_destroy(FIFO1);
      printk("rtf_destroy returned: %d\n", err);
      return -1;
    }
  else
    {
      printk("spawned task\n");
    };

  return 0;
}

static void fptest_cleanup(void)
{
  int err;

  printk("fptest_cleanup\n");
  
  /* Shut down the real-time thread */
  pthread_cancel (fptest_task);
  pthread_join (fptest_task, NULL);  

  /* Destroy the fifo */
  err = rtf_destroy(FIFO1);
  printk("rtf_destroy returned: %d\n", err);

  /* Print the floating point result */
  printk("f = %d\n", (int)f);  
}

module_init(fptest_init);
module_exit(fptest_cleanup);

Re: [Xenomai-help] invalid use of FPU in Xenomai context

[Jeff Webb]

Jeff Webb wrote:
> Okay...  I have found a simple example that exhibits the problem on my
> linux-2.4 system (see attached).  I am running xenomai 2.2.2 with the two RTAI
> FIFO patches (and the latest FPU-related patch).  

I still get the same error with xenomai-2.2.3 on my 2.4.33.3 and 2.6.17.13 x86 machines.  Did anyone get a chance to try the sample kernel module I posted?

  https://mail.gna.org/public/xenomai-help/2006-09/msg00143.html

Perhaps this is related to the FPU bug Jan just reported?

  https://mail.gna.org/public/xenomai-core/2006-09/msg00138.html

If so, then maybe the problem is related to the rt-pipe changes...

> I get two unresolved
> math-related symbols when I try to insert this module on my FC5 2.6 machine,
> so I can't comment on the linux-2.6 behavior at this time.  But that's a
> puzzle for another day...

FYI, I added "-ffast-math -mhard-float" to the CFLAGS to get rid of the unresolved symbols.

Thanks,

-Jeff

Re: [Xenomai-help] invalid use of FPU in Xenomai context

[Philippe Gerum]

On Mon, 2006-09-18 at 15:40 -0500, Jeff Webb wrote:
> Jeff Webb wrote:
> > Okay...  I have found a simple example that exhibits the problem on my
> > linux-2.4 system (see attached).  I am running xenomai 2.2.2 with the two RTAI
> > FIFO patches (and the latest FPU-related patch).  
> 
> I still get the same error with xenomai-2.2.3 on my 2.4.33.3 and 2.6.17.13 x86 machines.  Did anyone get a chance to try the sample kernel module I posted?
> 
>   https://mail.gna.org/public/xenomai-help/2006-09/msg00143.html
> 
> Perhaps this is related to the FPU bug Jan just reported?

There's a good chance that both issues are related. Several heads are
currently banging on proper walls to precisely spot the issue, since it
seems that not all x86 setups are affected.

> 
>   https://mail.gna.org/public/xenomai-core/2006-09/msg00138.html
> 
> If so, then maybe the problem is related to the rt-pipe changes...
> 
> > I get two unresolved
> > math-related symbols when I try to insert this module on my FC5 2.6 machine,
> > so I can't comment on the linux-2.6 behavior at this time.  But that's a
> > puzzle for another day...
> 
> FYI, I added "-ffast-math -mhard-float" to the CFLAGS to get rid of the unresolved symbols.
> 
> Thanks,
> 
> -Jeff
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
-- 
Philippe.

Re: [Xenomai-help] invalid use of FPU in Xenomai context

[Jeff Webb]

[-- Attachment #1: Type: text/plain, Size: 1078 bytes --]

If I run the attached program, I get the following result:

  [root]# ./mqtest2
  CPU time limit exceeded

The kernel log contains:

  Oct 25 14:13:03 kernel: invalid use of FPU in Xenomai context at 0x80492f6

If I change the WRITE_SIZE #define at the top of the program to 511 instead of 512, I do not get an error message, and the program works as expected.

I have tried this under two versions of Xenomai with the same result:
  1) Xenomai 2.2.3 with the FPU patch posted here:
     https://mail.gna.org/public/xenomai-help/2006-09/msg00157.html
     (adeos-ipipe-2.6.17-i386-1.4-00.patch)
  2) Xenomai 2.2.4 (adeos-ipipe-2.6.17-i386-1.5-00.patch)

Other details:
  Linux version 2.6.17.13
  AMD Athlon(tm)64 X2 Dual Core Processor  4400+
  Fedora Core 5
  SMP kernel

This is very similar to a problem I described last month that affected my linux-2.4 system: https://mail.gna.org/public/xenomai-help/2006-09/msg00143.html .  Perhaps these problems are related.

Does anyone see a problem with what I'm doing here?  If not, can you reproduce the problem?

Thanks,

Jeff
 

[-- Attachment #2: mqtest2.c --]
[-- Type: text/x-csrc, Size: 5436 bytes --]


/* Standard includes */
#include <stdio.h>
#include <errno.h>
#include <pthread.h>  /* POSIX threads and timers */
#include <stdlib.h>   /* Exit status macros and atexit */
#include <signal.h>   /* POSIX signals (sigaction) */
#include <sys/mman.h> /* Memory management (mlockall) */
#include <sys/stat.h> /* File creation modes (for mq_open) */
#include <mqueue.h>   /* POSIX message queues */
#include <error.h>    /* GNU error function */
#include <string.h>   /* String manipulation (strlen) */

/* Constants */
#define STACK_SIZE 1024*1024*8
#define QUEUE_MSG_SIZE 1024
#define QUEUE_MAX_MSGS 10
#define QUEUE_NAME "/queue1"
#define PRIORITY 10
#define WRITE_SIZE 512

/* Global variables */
sig_atomic_t abort_program = 0;
pthread_t rt_thread;
mqd_t queue1;
mqd_t queue1_rt;
int count = 0;
char send_buffer[QUEUE_MSG_SIZE];
char receive_buffer[QUEUE_MSG_SIZE];

/* Real-time thread cleanup routines */

void rt_thread_cleanup_queue1_rt (void * arg)
{
  mq_close(queue1_rt);
}

/* Real-time periodic thread code */
void * rt_loop(void * arg)
{
  double f = 0.0;

  /* Open the message queue */
  queue1_rt = mq_open(QUEUE_NAME, O_WRONLY | O_NONBLOCK);
  if (queue1_rt == (mqd_t) -1)
    error(0, errno, "could not open message queue '%s'", QUEUE_NAME);
  pthread_cleanup_push(rt_thread_cleanup_queue1_rt, NULL);

  pthread_set_mode_np(0, PTHREAD_WARNSW);
  
  /* Loop until the thread is cancelled */
  while (1)
    {
      /* Count the number of times this loop is executed */
      count++;
      
      /* Sleep for 1 second */
      {
        struct timespec dt_ts;
        dt_ts.tv_sec  = 1;
        dt_ts.tv_nsec = 0;
        clock_nanosleep(CLOCK_REALTIME, 0, &dt_ts, NULL);
      }

      /* Send a message to the non-rt thread */
      {
        int err;

        snprintf(send_buffer, QUEUE_MSG_SIZE, "count: %d %f", count, f);
        err = mq_send(queue1_rt, send_buffer, WRITE_SIZE, PRIORITY);
        if (err)
          error(0, errno, "could not write to message queue '%s'", 
                QUEUE_NAME);
        f = f + 0.1*count;
      }
    }

  /* Clean up thread resources */
  pthread_cleanup_pop(1);

  return NULL;
}

/* Handle POSIX signals */
void signal_handler(int sig)
{
  abort_program = 1;
}

/* Cleanup routines */

void cleanup_queue1(void)
{
  /* Close the message queue */
  mq_close(queue1);

  /* Delete the message queue */
  mq_unlink(QUEUE_NAME);
}

void cleanup_rt_thread(void)
{
  /* Tell the real-time thread to terminate */
  pthread_cancel(rt_thread);

  /* Wait for the real-time thread to terminate */
  pthread_join(rt_thread, NULL);
}


/* Main program */
int main(void)
{
  int err;

  /* Disable paging for this program's memory */
  err = mlockall(MCL_CURRENT | MCL_FUTURE);
  if (err)
    error(EXIT_FAILURE, errno,
          "could not disable memory paging for this program");

  /* Set the scheduling policy of the main program */
  {
    struct sched_param sparam;

    sparam.sched_priority = 0; /* Must be zero for SCHED_OTHER */
    err = pthread_setschedparam(pthread_self(), SCHED_OTHER, &sparam);
    if (err)
      error(EXIT_FAILURE, err,
            "error setting schedule parameters for main program");
  }

  /* Install POSIX signal handlers */
  {
    struct sigaction new_action;
    int * sig_ptr;
    int signals[] = {SIGTERM, SIGQUIT, SIGHUP, SIGINT, 0};
    
    new_action.sa_handler = signal_handler;
    sigemptyset(&new_action.sa_mask);
    new_action.sa_flags = 0;

    for (sig_ptr = signals; *sig_ptr != 0; sig_ptr++)
      {
        err = sigaction(*sig_ptr, &new_action, NULL);
        if (err)
          error(EXIT_FAILURE, errno, 
                "could not install signal handler for signal %d", *sig_ptr);
      }
  }

  /* Create a message queue */
  {
    struct mq_attr attr;

    attr.mq_flags = 0;
    attr.mq_maxmsg = QUEUE_MAX_MSGS;
    attr.mq_msgsize = QUEUE_MSG_SIZE;

    mq_unlink(QUEUE_NAME);
    queue1 = mq_open(QUEUE_NAME, O_RDONLY | O_CREAT | O_EXCL,
                     S_IRUSR | S_IWUSR | S_IXUSR, &attr);
    if (queue1 == (mqd_t) -1)
      error(EXIT_FAILURE, errno, "could not create message queue '%s'", 
            QUEUE_NAME);
    atexit(cleanup_queue1);
  }

  /* Create the real-time task */
  {
    pthread_attr_t attr;
    size_t stacksize = STACK_SIZE;
    struct sched_param sparam;

    pthread_attr_init(&attr);
    pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_JOINABLE);
    pthread_attr_setstacksize (&attr, stacksize);
    pthread_attr_setinheritsched(&attr, PTHREAD_EXPLICIT_SCHED);
    pthread_attr_setschedpolicy(&attr, SCHED_FIFO);
    sparam.sched_priority = 99; /* High priority */
    pthread_attr_setschedparam(&attr, &sparam);
    pthread_create(&rt_thread, &attr, &rt_loop, NULL);
    pthread_attr_destroy(&attr);
    if (err)
      error(EXIT_FAILURE, err, "could not create thread");
    atexit(cleanup_rt_thread);
  }

  /* Wait for program to be aborted with <ctrl-c> */
  while(!abort_program)
    {
      int err;

      /* Wait for data from the rt thread */
      err = mq_receive(queue1, receive_buffer, QUEUE_MSG_SIZE, NULL);
      if (err < 0)
        error(0, errno, "error reading from message queue '%s'", QUEUE_NAME);
      else
        /* Print the message */
        printf("received message: %s\n", receive_buffer);
    }

  /* Print the final loop count */
  printf("final count = %d\n", count);

  /* Cleanup is handled by atexit functions */
  return EXIT_SUCCESS;
}

Re: [Xenomai-help] invalid use of FPU in Xenomai context

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1409 bytes --]

Jeff Webb wrote:
> If I run the attached program, I get the following result:
> 
>  [root]# ./mqtest2
>  CPU time limit exceeded
> 
> The kernel log contains:
> 
>  Oct 25 14:13:03 kernel: invalid use of FPU in Xenomai context at 0x80492f6

Can you do a backtrace in gdb?

> 
> If I change the WRITE_SIZE #define at the top of the program to 511
> instead of 512, I do not get an error message, and the program works as
> expected.
> 
> I have tried this under two versions of Xenomai with the same result:
>  1) Xenomai 2.2.3 with the FPU patch posted here:
>     https://mail.gna.org/public/xenomai-help/2006-09/msg00157.html
>     (adeos-ipipe-2.6.17-i386-1.4-00.patch)
>  2) Xenomai 2.2.4 (adeos-ipipe-2.6.17-i386-1.5-00.patch)
> 
> Other details:
>  Linux version 2.6.17.13
>  AMD Athlon(tm)64 X2 Dual Core Processor  4400+
>  Fedora Core 5
>  SMP kernel
> 
> This is very similar to a problem I described last month that affected
> my linux-2.4 system:
> https://mail.gna.org/public/xenomai-help/2006-09/msg00143.html . 
> Perhaps these problems are related.
> 
> Does anyone see a problem with what I'm doing here?  If not, can you
> reproduce the problem?
> 

Could you also try if this patch changes anything:

https://mail.gna.org/public/xenomai-core/2006-10/msg00069.html

(Could be the case if you happen to use some FPU-touching Linux driver.)

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] invalid use of FPU in Xenomai context

[Jeff Webb]

Jan Kiszka wrote:
> Jeff Webb wrote:
>> If I run the attached program, I get the following result:
>>
>>  [root]# ./mqtest2
>>  CPU time limit exceeded
>>
>> The kernel log contains:
>>
>>  Oct 25 14:13:03 kernel: invalid use of FPU in Xenomai context at 0x80492f6
> 
> Can you do a backtrace in gdb?
> 

# gdb ./mqtest2
GNU gdb Red Hat Linux (6.3.0.0-1.122rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1".

(gdb) r
Starting program: mqtest2
Reading symbols from shared object read from target memory...done.
Loaded system supplied DSO at 0xffffe000
[Thread debugging using libthread_db enabled]
[New Thread -1208785216 (LWP 3484)]
[New Thread -1208788064 (LWP 3487)]
received message: count: 1 0.000000

Program received signal SIGXCPU, CPU time limit exceeded.
[Switching to Thread -1208788064 (LWP 3487)]
rt_loop (arg=0x0) at mqtest2.c:74
74              f = f + 0.1*count;
(gdb) bt
#0  rt_loop (arg=0x0) at mqtest2.c:74
#1  0xb7f53545 in __pthread_trampoline ()
   from /usr/xenomai/lib/libpthread_rt.so.0
#2  0x0092940b in start_thread () from /lib/libpthread.so.0
#3  0x00757b7e in clone () from /lib/libc.so.6
(gdb)

Re: [Xenomai-help] invalid use of FPU in Xenomai context

[Jeff Webb]

Jan Kiszka wrote:
> Jeff Webb wrote:
>> If I run the attached program, I get the following result:
>>
>>  [root]# ./mqtest2
>>  CPU time limit exceeded
>>
>> The kernel log contains:
>>
>>  Oct 25 14:13:03 kernel: invalid use of FPU in Xenomai context at 0x80492f6
> 
> Could you also try if this patch changes anything:
> 
> https://mail.gna.org/public/xenomai-core/2006-10/msg00069.html
> 
> (Could be the case if you happen to use some FPU-touching Linux driver.)

The patch would not apply to xenomai 2.2.4, so I checked out the svn trunk (rev 1749), and then applied this patch.  I get the same behavior.

Thanks,

-Jeff

Re: [Xenomai-help] invalid use of FPU in Xenomai context

[Jeff Webb]

Jeff Webb wrote:
> Jan Kiszka wrote:
>> Jeff Webb wrote:
>>> If I run the attached program, I get the following result:
>>>
>>>  [root]# ./mqtest2
>>>  CPU time limit exceeded
>>>
>>> The kernel log contains:
>>>
>>>  Oct 25 14:13:03 kernel: invalid use of FPU in Xenomai context at 
>>> 0x80492f6
>>
>> Could you also try if this patch changes anything:
>>
>> https://mail.gna.org/public/xenomai-core/2006-10/msg00069.html
>>
>> (Could be the case if you happen to use some FPU-touching Linux driver.)
> 
> The patch would not apply to xenomai 2.2.4, so I checked out the svn 
> trunk (rev 1749), and then applied this patch.  I get the same behavior.

I tried my mqtest2 example with a stock xenomai 2.2.4 UP kernel (instead of SMP), and I still get the FPU error message and SIGXCPU signal.  I also went back to xenomai 2.2.1 SMP and still have the problem there.

Has anyone tried the example on some other hardware?

-Jeff