[Xenomai-help] floating point (int 16) exception

[Xenomai-help] floating point (int 16) exception

[Gabriele Moabiti]

[-- Attachment #1.1: Type: text/plain, Size: 819 bytes --]

Scenario:
Xenomai 2.4.5, kernel 2.6.24-7 (x86)
I have successfully trapped and restored int #0 (it is not reported in the example).
Now I want to trap fpu exceptions (#16) of a Xenomai user task (ring 3).

xfpu_xcpt.c -> kernel module used to intercept and manage fpu (#16) exceptions.
xfpu_user.c -> xenomai user task

The easiest way (it will not be so easy the final fpu exception manager of course!) to do this I knows was to do an fnclex but the example doesn't work (it hangs shortly).
I have tried *many* solutions but nothing works. I think the problem is I can't do a simple fnclex but I can't figure how to solve the problem.

Thank you


      Unisciti alla community di Io fotografo e video, il nuovo corso di fotografia di Gazzetta dello sport:
http://www.flickr.com/groups/iofotografoevideo

[-- Attachment #1.2: Type: text/html, Size: 1159 bytes --]

[-- Attachment #2: xfpu.tar.gz --]
[-- Type: application/x-gzip, Size: 2190 bytes --]

Re: [Xenomai-help] floating point (int 16) exception

[Gilles Chanteperdrix]

Gabriele Moabiti wrote:
> Scenario: Xenomai 2.4.5, kernel 2.6.24-7 (x86) I have successfully
> trapped and restored int #0 (it is not reported in the example). Now
> I want to trap fpu exceptions (#16) of a Xenomai user task (ring 3).
> 
> xfpu_xcpt.c -> kernel module used to intercept and manage fpu (#16)
> exceptions. xfpu_user.c -> xenomai user task
> 
> The easiest way (it will not be so easy the final fpu exception
> manager of course!) to do this I knows was to do an fnclex but the
> example doesn't work (it hangs shortly). I have tried *many*
> solutions but nothing works. I think the problem is I can't do a
> simple fnclex but I can't figure how to solve the problem.

No, simply doing an fnclex will not do the trick.

If you do not know the details of Xenomai and Linux FPU handling on x86,
I advise you to let xenomai handle the fault, it does it without
switching to secondary mode, so, you can use it. I do not want to
explain you how it works because it is rather hairy, so, the only way to
understand, if you really want to, is to read the xenomai and linux
relevant sources.

-- 
                                                 Gilles.

Re: [Xenomai-help] floating point (int 16) exception

[Gabriele Moabiti]

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



>No, simply doing an fnclex will not do the trick.
>
>If you do not know the details of Xenomai and Linux FPU handling on x86,
>I advise you to let xenomai handle the fault, it does it without
>switching to secondary mode, so, you can use it. I do not want to
>explain you how it works because it is rather hairy, so, the only way to
>understand, if you really want to, is to read the xenomai and linux
>relevant sources.

I need to manage exceptions in a different way of the x86 default so I have to unmask fpu exceptions. I have read and follow how it works but in xenomai fpu exceptions invoke a switch to linux... 

int xnpod_trap_fault(xnarch_fltinfo_t *fltinfo)
{
    ...
    if (xnpod_shadow_p()) {
        ...
        xnshadow_relax(xnarch_fault_notify(fltinfo));
    }
    return 0;
}

so there is not in the source code an example on how to trap exception and remain into real time task...


      Unisciti alla community di Io fotografo e video, il nuovo corso di fotografia di Gazzetta dello sport:
http://www.flickr.com/groups/iofotografoevideo

[-- Attachment #2: Type: text/html, Size: 1750 bytes --]

Re: [Xenomai-help] floating point (int 16) exception

[Gilles Chanteperdrix]

Gabriele Moabiti wrote:
> 
>> No, simply doing an fnclex will not do the trick.
>> 
>> If you do not know the details of Xenomai and Linux FPU handling on
>> x86, I advise you to let xenomai handle the fault, it does it
>> without switching to secondary mode, so, you can use it. I do not
>> want to explain you how it works because it is rather hairy, so,
>> the only way to understand, if you really want to, is to read the
>> xenomai and linux relevant sources.
> 
> I need to manage exceptions in a different way of the x86 default so
> I have to unmask fpu exceptions. I have read and follow how it works
> but in xenomai fpu exceptions invoke a switch to linux...
> 
> int xnpod_trap_fault(xnarch_fltinfo_t *fltinfo) { ... if
> (xnpod_shadow_p()) { ... 
> xnshadow_relax(xnarch_fault_notify(fltinfo)); } return 0; }
> 
> so there is not in the source code an example on how to trap
> exception and remain into real time task...

No, you do not read the sources correctly. Xenomai does handle FPU
exception in primary mode. You know, I implemented part of this, so, you
should not assume that I do not know what I am talking about.

int xnpod_trap_fault(xnarch_fltinfo_t *fltinfo)
{
...
#ifdef __KERNEL__
        if (xnarch_fault_fpu_p(fltinfo)) {
#if defined(CONFIG_XENO_OPT_PERVASIVE) && defined(CONFIG_XENO_HW_FPU)
                xnarchtcb_t *tcb = xnthread_archtcb(thread);

                if (xnpod_shadow_p() && !xnarch_fpu_init_p(tcb->user_task)) {
                        /* The faulting task is a shadow using the FPU
for the
                           first time, initialize its FPU. Of course if
Xenomai
is
                           not compiled with support for FPU, such use
of the FP
U
                           is an error. */
                        xnarch_init_fpu(tcb);
			return 1;

So, here the exception was handled in primary mode, and the comments are
rather explicit.

By the way, your mailer is misconfigured and does not trunc lines.

-- 
                                                 Gilles.

Re: [Xenomai-help] floating point (int 16) exception

[Gabriele Moabiti]

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


>No, you do not read the sources correctly. Xenomai does handle FPU
>exception in primary mode. You know, I implemented part of this, so, you
>should not assume that I do not know what I am talking about.

I *REALLY* don't say you don't know what you say
(I ask you 'cause I think you know... :)

ring 3 xenomai task:
void xeno_task(void *cookie)
{
 static long loop_count=0;
  unsigned int cw=0x360;

  /* Unmask all but not precision, the int 7 will be raised */
  __asm__ __volatile__("fldcw %0;"::"m"(cw)); 
  for (;;loop_count++) {
    rt_task_wait_period(NULL);
        rt_printf("Loop number: %ld\n", loop_count);
    /* Let's raise an exception #16*/
    __asm__ __volatile__(
      "fldz;"
      "fld1;"
      "fdivrp %st(0),%st(1);"
      "fwait;"
    ); 
  }
}

xnarch_fault_fpu_p is related to int 7 that It manage the TS bit (fpu handling
of save restore only if the task use fpu) and it works, it doesn't switch to secondary
mode as you say.
If I pass to Xenomai the exception 16 of fdivrp the task end 'cause (i thought) the
switch to secondary mode. Sorry if i bug you but i really need a suggestion.


      Unisciti alla community di Io fotografo e video, il nuovo corso di fotografia di Gazzetta dello sport:
http://www.flickr.com/groups/iofotografoevideo

[-- Attachment #2: Type: text/html, Size: 2072 bytes --]

Re: [Xenomai-help] floating point (int 16) exception

[Gilles Chanteperdrix]

Gabriele Moabiti wrote:
>> No, you do not read the sources correctly. Xenomai does handle FPU
>> exception in primary mode. You know, I implemented part of this, so, you
>> should not assume that I do not know what I am talking about.
> 
> I *REALLY* don't say you don't know what you say
> (I ask you 'cause I think you know... :)
> 
> ring 3 xenomai task:
> void xeno_task(void *cookie)
> {
>  static long loop_count=0;
>   unsigned int cw=0x360;
> 
>   /* Unmask all but not precision, the int 7 will be raised */
>   __asm__ __volatile__("fldcw %0;"::"m"(cw)); 
>   for (;;loop_count++) {
>     rt_task_wait_period(NULL);
>         rt_printf("Loop number: %ld\n", loop_count);
>     /* Let's raise an exception #16*/
>     __asm__ __volatile__(
>       "fldz;"
>       "fld1;"
>       "fdivrp %st(0),%st(1);"
>       "fwait;"
>     ); 
>   }
> }
> 
> xnarch_fault_fpu_p is related to int 7 that It manage the TS bit (fpu handling
> of save restore only if the task use fpu) and it works, it doesn't switch to secondary
> mode as you say.
> If I pass to Xenomai the exception 16 of fdivrp the task end 'cause (i thought) the
> switch to secondary mode. Sorry if i bug you but i really need a suggestion.

You mean you want to handle a division by zero without ending the
program, and without even switching to secondary mode? Then in this
case, I am afraid you are on your own.

-- 
                                                 Gilles.

Re: [Xenomai-help] floating point (int 16) exception

[Gabriele Moabiti]

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


>You mean you want to handle a division by zero without ending the
>program, and without even switching to secondary mode? Then in this
>case, I am afraid you are on your own.

mmm... it's better if i explain the scenario to make sense.

I am developing a driver for a CNC using xenomai.
Now this cnc run on dos/win (and linux) and the real-time is based on nmi (with
a pci card generate the nmi @ 0.125 us - 2ms attached to the peripherals and servodrives).
Now we want to switch to linux only changing the pci cart with an eth card and rtnet to
communicate.

I have already done the ring 0 driver on linux (on windows is very similar) in a the *orrible* way (I know!), 
reprogramming the IDT and using cli and sti and using using xenomai only for small task
but we want to use rtnet so I have to better integrate into the xenomai context and
the only way to do it proper is to shift cnc to user rt domain.
(NOTE: it's a long story but cnc, written in asm x86 (500k) need to take the first 16 MB and this
is done with dirty tricks on gdt on ring 0, absolutely incompatible with linux/xenomai but
in ring 3 with some mapping this problems disappears of course)

The cnc need to take different decisions on fpu exceptions:
1) the intel defaults actions on masked fpu exceptions aren't right for cnc
2) an exception sometimes can occur but this must not stop cnc!
    (the cnc register the problem continue if it can be resumed)
So custom exceptions handling is *really* needed.

However I think a robust hard real time application may need to remain in rt even if an
fpu exception is raised and a custom exception handling is not so strange.

    Gabriele


      Unisciti alla community di Io fotografo e video, il nuovo corso di fotografia di Gazzetta dello sport:
http://www.flickr.com/groups/iofotografoevideo

[-- Attachment #2: Type: text/html, Size: 2419 bytes --]