Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>  > Hi,
>  > 
>  > after receiving SIGXCPU for unexpected context switches in a larger
>  > application, I found out that the T_FPU bit does not seem to be
>  > recognised on x86 during native task creation. Here is a simple test
>  > case, watch out for /proc/xenomai/faults after program start and 5 s later:
>  > 
>  > #include <native/task.h>
>  > #include <sys/mman.h>
>  > 
>  > float x;
>  > 
>  > void task_func(void *p)
>  > {
>  >     rt_task_sleep(5000000000LL);
>  >     x = 3.14 + (int)p;
>  > }
>  > 
>  > main()
>  > {
>  >     RT_TASK task;
>  > 
>  >     mlockall(MCL_CURRENT|MCL_FUTURE);
>  > 
>  >     rt_task_spawn(&task, NULL, 0, 40, T_FPU | T_JOINABLE, task_func, 0);
>  >     rt_task_join(&task);
>  > 
>  >     return 0;
>  > }
>  > 
>  > 
>  > Any immediate ideas?
> 
> User-space threads always have the FPU bit anyway. When a user-space

Yep, I stumbled over this fact meanwhile.

> thread in primary mode uses FPU for the first time on x86, the FPU
> hardware is initialized in the fault handler, this is the expected
> behaviour. This allow the nucleus to not switch FPU context for
> user-space threads that never use the FPU.

But doesn't this lazy scheme introduce the risk of unexpected latencies
for the first FPU usage of a RT task? I mean, there is already the
information available if a task is going to use the FPU (via the flag),
then why not make use of it?

> 
> In case of an abnormal FPU fault, the message "invalid use of FPU" is
> printed on console.
> 

Yeah, I got this unfortunately only once: full alarm, both via kernel
message and SIGXCPU. So far I failed to reproduce it. I tested that
"normal" FPU usage for the first time does not trigger that warnings.
What may have caused this?

Jan