[Xenomai-help] T_WARNSW ignored?

[Xenomai-help] T_WARNSW ignored?

[Kolja Waschk]

Hi,

I'm trying to detect some remaining unwanted mode switches in an
application using the native Xenomai app. In one task (that is meant to
stay in RT domain all the time) I set the T_WARNSW bit and run the
program via gdb, but - although /proc/xenomai/stat shows some 1000 MSW
per second for that task - no SIGXCPU ever occurs. Only after I interrupt
it in the terminal where gdbserver was started, the gdb client shows
SIGINT, and after "cont", SIGXPCU.

I also tried the examples/native/sigxcpu.c with the same compiler flags.
There, SIGXCPU occurs and is reported by GDB immediately. What may cause
this, did I miss something?

It's on Blackfin, uclinux-dist 2009R1-RC2, Xenomai 2.4.7, Kernel 2.6.28.10 with
adeos-ipipe-2.6.28.10-blackfin.git-1.10-00.patch.

This is how it looks when the program is interrupted after some time:

Program received signal SIGINT, Interrupt.
[Switching to Thread 270]
0x00710042 in rt_sem_p (sem=0xf69028, timeout=81067177008952732) at
../../../../xenomai-2.4.7/src/skins/native/sem.c:43
43		return XENOMAI_SKINCALL2(__native_muxid, __native_sem_p,
sem, &timeout);
Current language:  auto; currently c
(gdb) cont
Continuing.

Program received signal SIGXCPU, CPU time limit exceeded.
[Switching to Thread 273]
0x0070fc20 in rt_dev_ioctl (fd=0, request=4) at
../../../../xenomai-2.4.7/src/skins/rtdm/core.c:60
60		return XENOMAI_SKINCALL3(__rtdm_muxid,
(gdb)

Kolja

Re: [Xenomai-help] T_WARNSW ignored?

[Gilles Chanteperdrix]

Kolja Waschk wrote:
> Hi,
> 
> I'm trying to detect some remaining unwanted mode switches in an
> application using the native Xenomai app. In one task (that is meant to
> stay in RT domain all the time) I set the T_WARNSW bit and run the
> program via gdb, but - although /proc/xenomai/stat shows some 1000 MSW
> per second for that task - no SIGXCPU ever occurs. Only after I interrupt
> it in the terminal where gdbserver was started, the gdb client shows
> SIGINT, and after "cont", SIGXPCU.
> 
> I also tried the examples/native/sigxcpu.c with the same compiler flags.
> There, SIGXCPU occurs and is reported by GDB immediately. What may cause
> this, did I miss something?
> 
> It's on Blackfin, uclinux-dist 2009R1-RC2, Xenomai 2.4.7, Kernel 2.6.28.10 with
> adeos-ipipe-2.6.28.10-blackfin.git-1.10-00.patch.
> 
> This is how it looks when the program is interrupted after some time:
> 
> Program received signal SIGINT, Interrupt.
> [Switching to Thread 270]
> 0x00710042 in rt_sem_p (sem=0xf69028, timeout=81067177008952732) at
> ../../../../xenomai-2.4.7/src/skins/native/sem.c:43
> 43		return XENOMAI_SKINCALL2(__native_muxid, __native_sem_p,
> sem, &timeout);
> Current language:  auto; currently c
> (gdb) cont
> Continuing.
> 
> Program received signal SIGXCPU, CPU time limit exceeded.
> [Switching to Thread 273]
> 0x0070fc20 in rt_dev_ioctl (fd=0, request=4) at
> ../../../../xenomai-2.4.7/src/skins/rtdm/core.c:60
> 60		return XENOMAI_SKINCALL3(__rtdm_muxid,
> (gdb)

I do not know if that may be your issue, but gdb cause mode switches,
and you are not notified for these ones. So, the only relevant test is
to run your application outside gdb and see if the MSW increments.

-- 
                                          Gilles

Re: [Xenomai-help] T_WARNSW ignored?

[Kolja Waschk]

> I do not know if that may be your issue, but gdb cause mode switches,

That explains the SIGXCPU after SIGINT.

> to run your application outside gdb and see if the MSW increments.

It does. But no XCPU occurs, neither when started via GDB nor when run
standalone...

Kolja

Re: [Xenomai-help] T_WARNSW ignored?

[Philippe Gerum]

On Fri, 2009-08-14 at 12:08 +0200, Kolja Waschk wrote:
> > I do not know if that may be your issue, but gdb cause mode switches,
> 
> That explains the SIGXCPU after SIGINT.
> 
> > to run your application outside gdb and see if the MSW increments.
> 
> It does. But no XCPU occurs, neither when started via GDB nor when run
> standalone...
> 

What does /proc/xenumai/faults say? Does any counter value increase
while the app is running?

> Kolja
> 
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
-- 
Philippe.

Re: [Xenomai-help] T_WARNSW ignored?

[Kolja Waschk]

> What does /proc/xenumai/faults say? Does any counter value increase
> while the app is running?

faults displays nothing. stat shows increasing MSW/CSW count for the
thread in question:

/ # cat /proc/xenomai/faults 
TRAP         CPU0
/ # cat /proc/xenomai/stat 
CPU  PID    MSW        CSW        PF    STAT       %CPU  NAME
   0  0      0          2392559    0     00400080   82.8  ROOT
   0  274    38         652599     0     00300186   11.0  main
   0  276    12         71461      0     00300186    1.4  logger
> 0  277    10210      20412      0     00320186    2.5  Head_UDP_Thread
   0  0      0          3824071    0     00000000    1.9  IRQ6: [timer]
   0  0      0          10040      0     00000000    0.1  IRQ14: rmiisport_rx
   0  0      0          0          0     00000000    0.0  IRQ15: rmiisport_tx
   0  0      0          159        0     00000000    0.0  IRQ46: rmiisport_err

Re: [Xenomai-help] T_WARNSW ignored?

[Philippe Gerum]

On Fri, 2009-08-14 at 12:26 +0200, Kolja Waschk wrote:
> > What does /proc/xenumai/faults say? Does any counter value increase
> > while the app is running?
> 
> faults displays nothing. stat shows increasing MSW/CSW count for the
> thread in question:
> 
> / # cat /proc/xenomai/faults 
> TRAP         CPU0
> / # cat /proc/xenomai/stat 
> CPU  PID    MSW        CSW        PF    STAT       %CPU  NAME
>    0  0      0          2392559    0     00400080   82.8  ROOT
>    0  274    38         652599     0     00300186   11.0  main
>    0  276    12         71461      0     00300186    1.4  logger
> > 0  277    10210      20412      0     00320186    2.5  Head_UDP_Thread

UDP, like... socket() interface?

>    0  0      0          3824071    0     00000000    1.9  IRQ6: [timer]
>    0  0      0          10040      0     00000000    0.1  IRQ14: rmiisport_rx
>    0  0      0          0          0     00000000    0.0  IRQ15: rmiisport_tx
>    0  0      0          159        0     00000000    0.0  IRQ46: rmiisport_err
> 
> 
> 
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
> 
> +----------------------------------------------------------------------+
> | ETAS Mail Security - http://intranet.etasgroup.com/encryption        |
> +----------------------------------------------------------------------+
> | - The message was not encrypted and not digitally signed             |
> +----------------------------------------------------------------------+
-- 
Philippe.

Re: [Xenomai-help] T_WARNSW ignored?

[Waschk,Kolja]

>>> 0  277    10210      20412      0     00320186    2.5  Head_UDP_Thread
> UDP, like... socket() interface?

No. There's a custom RTDM driver with a DMA completion ISR and an IOCTL_RT that
can be used by the application to fetch a pointer to received data.  The thread
has "UDP" in its name because the data comes in UDP-like packets over a
Blackfin SPORT interface, and on other platforms (PC) the code indeed uses
Ethernet and real sockets for reception.

Hmm, the solution to my question may be very simple. In the past I had to
enclose the ioctl call to the driver with explicit mode switches, because
otherwise the application would always crash (remember my previous problem with
the xnshadow_relax() symptom). They're still there. I somehow expected the
SIGXCPU to occur even before the first ioctl is made. But if that doesn't
happen, and an explicit call to rt_task_set_mode doesn't cause SIGXCPU, that
may be the (silly) cause... Unfortunately I can't check right now. Will report
if that's it...

Kolja

Re: [Xenomai-help] T_WARNSW ignored?

[Philippe Gerum]

On Fri, 2009-08-14 at 21:52 +0200, Waschk,Kolja wrote:
> >>> 0  277    10210      20412      0     00320186    2.5  Head_UDP_Thread
> > UDP, like... socket() interface?
> 
> No. There's a custom RTDM driver with a DMA completion ISR and an IOCTL_RT that
> can be used by the application to fetch a pointer to received data.  The thread
> has "UDP" in its name because the data comes in UDP-like packets over a
> Blackfin SPORT interface, and on other platforms (PC) the code indeed uses
> Ethernet and real sockets for reception.
> 

Ok.

> Hmm, the solution to my question may be very simple. In the past I had to
> enclose the ioctl call to the driver with explicit mode switches, because
> otherwise the application would always crash (remember my previous problem with
> the xnshadow_relax() symptom). They're still there. I somehow expected the
> SIGXCPU to occur even before the first ioctl is made. But if that doesn't
> happen, and an explicit call to rt_task_set_mode doesn't cause SIGXCPU,

Indeed, it does not, since clearing the T_PRIMARY bit this way is an
action which is supposed to be done willingly by the application code,
so there is normally no point in notifying it about the mode switch it
just asked for.

>  that
> may be the (silly) cause... Unfortunately I can't check right now. Will report
> if that's it...
> 
> Kolja
> 
> 
-- 
Philippe.

Re: [Xenomai-help] T_WARNSW ignored?

[Waschk,Kolja]

Hi,

well my guess was correct, the quickly increasing MSW without SIGXCPU was just
due to a forced mode switch with rt_task_set_mode... how silly, sorry for
bothering!

Kolja

Re: [Xenomai-help] T_WARNSW ignored?

[Philippe Gerum]

On Sat, 2009-08-15 at 15:14 +0200, Waschk,Kolja wrote:
> Hi,
> 
> well my guess was correct, the quickly increasing MSW without SIGXCPU was just
> due to a forced mode switch with rt_task_set_mode... how silly, sorry for
> bothering!

No problem. I'm rather concerned by the fact that
rt_task_set_mode(...T_PRIMARY...) is still being used for the wrong
purpose, but this bug is mine originally. The point is that there should
be no valid reason to switch modes explicitly in any user level code,
Xenomai knows better in any case, and only does it internally when
required.

Explicit switching is currently required by a few skin libraries for
internal purpose, I should have exported some hidden syscall to provide
this anti-feature, instead of crippling the rt_task_set_mode() interface
with the wacky T_PRIMARY mode bit. Anyway...

The xnshadow_relax() issue on Blackfin led to use it the wrong way as a
workaround; please report this kind of bug before applying any
workaround, so that a proper fix could be found in parallel. TIA,

> 
> Kolja
> 
> 
-- 
Philippe.