[Xenomai-help] Howto catch SEGV signals in Xenomai

[Xenomai-help] Howto catch SEGV signals in Xenomai

[M. Koehrer]

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

Hi all,

I have a problem to catch segment violations with Xenomai:
For demonstration I use the following program:
------------------------------------------
#include <stdio.h>
#include <sys/mman.h>

#include <native/task.h>
#include <native/sem.h>
RT_TASK taska_desc;
volatile int *pointer = 0;

void mytaska(void *cookie)
{
    int i;
    for (i=0; i < 50; i++)
    {
        rt_task_sleep(50000000);
        if (i > 20)
        {
            *pointer = 123;
        }
        printf("Hello %i\n", i);
    }
    printf("Hi, this is task A\n");
}

int main(void)
{
    mlockall(MCL_CURRENT|MCL_FUTURE);

    rt_task_create(&taska_desc, "mytaska", 0, 81, T_JOINABLE);
    rt_task_start(&taska_desc, &mytaska, NULL);

    rt_task_join(&taska_desc);
    printf("Main: A joined\n");

    return 0;
}
---------------------------------------
Whenever i is greater than 20 a segment violation occurs, as I must not write
to address 0 (the pointer is always NULL).
However, what happens is, that my system freezes after printing out 18 or 19.
I have to reset the PC to continue.
When I write a printf() directly before the invalid assignment I get the usual linux
"segmentation fault" error message.

How can I catch a signal in a Xenomai real time task?

I am running Xenomai 2.3.0 + NOCOW patch.

I have enclosed the .c file and a Makefile in a .tgz file.

Thanks for any feedback on that issue

Regards

Mathias
~
~



-- 
Mathias Koehrer
mathias_koehrer@domain.hid


Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren
ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT JETZT bei Arcor: günstig
und schnell mit DSL - das All-Inclusive-Paket für clevere Doppel-Sparer,
nur  39,85 €  inkl. DSL- und ISDN-Grundgebühr!
http://www.arcor.de/rd/emf-dsl-2

[-- Attachment #2: signal.tgz --]
[-- Type: application/octet-stream, Size: 697 bytes --]

Re: [Xenomai-help] Howto catch SEGV signals in Xenomai

[Philippe Gerum]

On Tue, 2007-03-13 at 15:51 +0100, M. Koehrer wrote:
> Hi all,
> 
> I have a problem to catch segment violations with Xenomai:
> For demonstration I use the following program:
> ------------------------------------------
> #include <stdio.h>
> #include <sys/mman.h>
> 
> #include <native/task.h>
> #include <native/sem.h>
> RT_TASK taska_desc;
> volatile int *pointer = 0;
> 
> void mytaska(void *cookie)
> {
>     int i;
>     for (i=0; i < 50; i++)
>     {
>         rt_task_sleep(50000000);
>         if (i > 20)
>         {
>             *pointer = 123;
>         }
>         printf("Hello %i\n", i);
>     }
>     printf("Hi, this is task A\n");
> }
> 
> int main(void)
> {
>     mlockall(MCL_CURRENT|MCL_FUTURE);
> 
>     rt_task_create(&taska_desc, "mytaska", 0, 81, T_JOINABLE);
>     rt_task_start(&taska_desc, &mytaska, NULL);
> 
>     rt_task_join(&taska_desc);
>     printf("Main: A joined\n");
> 
>     return 0;
> }
> ---------------------------------------
> Whenever i is greater than 20 a segment violation occurs, as I must not write
> to address 0 (the pointer is always NULL).
> However, what happens is, that my system freezes after printing out 18 or 19.
> I have to reset the PC to continue.
> When I write a printf() directly before the invalid assignment I get the usual linux
> "segmentation fault" error message.

This would be the the sign that a problem exists at the I-pipe level
with your current patch. The fault should have been propagated form
primary to secondary domain, and obviously it's not.

> 
> How can I catch a signal in a Xenomai real time task?
> 

There is no difference with any regular Linux application.

> I am running Xenomai 2.3.0 + NOCOW patch.
> I have enclosed the .c file and a Makefile in a .tgz file.

Can't reproduce the issue with 1.7-03 here.
Please make sure to use a recent and official I-pipe patch if it's not
already the case, and not a testing patch as published on this list, so
that we don't start chasing wild gooses.
http://download.gna.org/adeos/patches/v2.6/

> Thanks for any feedback on that issue
> 
> Regards
> 
> Mathias
> ~
> ~
> 
> 
> 
> -- 
> Mathias Koehrer
> mathias_koehrer@domain.hid
> 
> 
> Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren
> ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT JETZT bei Arcor: günstig
> und schnell mit DSL - das All-Inclusive-Paket für clevere Doppel-Sparer,
> nur  39,85 €  inkl. DSL- und ISDN-Grundgebühr!
> http://www.arcor.de/rd/emf-dsl-2
> _______________________________________________ Xenomai-help mailing list Xenomai-help@domain.hid https://mail.gna.org/listinfo/xenomai-help
-- 
Philippe.

Re: [Xenomai-help] Howto catch SEGV signals in Xenomai

[Gilles Chanteperdrix]

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

M. Koehrer wrote:
> Hi all,
> 
> I have a problem to catch segment violations with Xenomai:
> For demonstration I use the following program:
> ------------------------------------------
> #include <stdio.h>
> #include <sys/mman.h>
> 
> #include <native/task.h>
> #include <native/sem.h>
> RT_TASK taska_desc;
> volatile int *pointer = 0;
> 
> void mytaska(void *cookie)
> {
>     int i;
>     for (i=0; i < 50; i++)
>     {
>         rt_task_sleep(50000000);
>         if (i > 20)
>         {
>             *pointer = 123;
>         }
>         printf("Hello %i\n", i);
>     }
>     printf("Hi, this is task A\n");
> }
> 
> int main(void)
> {
>     mlockall(MCL_CURRENT|MCL_FUTURE);
> 
>     rt_task_create(&taska_desc, "mytaska", 0, 81, T_JOINABLE);
>     rt_task_start(&taska_desc, &mytaska, NULL);
> 
>     rt_task_join(&taska_desc);
>     printf("Main: A joined\n");
> 
>     return 0;
> }
> ---------------------------------------
> Whenever i is greater than 20 a segment violation occurs, as I must not write
> to address 0 (the pointer is always NULL).
> However, what happens is, that my system freezes after printing out 18 or 19.
> I have to reset the PC to continue.
> When I write a printf() directly before the invalid assignment I get the usual linux
> "segmentation fault" error message.
> 
> How can I catch a signal in a Xenomai real time task?
> 
> I am running Xenomai 2.3.0 + NOCOW patch.
> 
> I have enclosed the .c file and a Makefile in a .tgz file.
> 
> Thanks for any feedback on that issue

It looks like the "relaxing a kicked thread" issue again. Could you try
the attached patch ?


-- 
                                                 Gilles Chanteperdrix

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: xeno-relax-kicked-thread.diff --]
[-- Type: text/x-patch; name="xeno-relax-kicked-thread.diff", Size: 627 bytes --]

Index: ksrc/nucleus/pod.c
===================================================================
--- ksrc/nucleus/pod.c	(révision 2293)
+++ ksrc/nucleus/pod.c	(copie de travail)
@@ -1398,7 +1398,7 @@
 		   and return immediately. Note: a relaxed shadow never has
 		   the KICKED bit set, so that xnshadow_relax() is never
 		   prevented from blocking the current thread. */
-		if (xnthread_test_info(thread, XNKICKED)) {
+		if (xnthread_test_info(thread, XNKICKED) && !xnthread_test_info(thread, XNRELAX)) {
 			xnthread_clear_info(thread, XNRMID | XNTIMEO);
 			xnthread_set_info(thread, XNBREAK);
 			if (wchan)

Re: Re: [Xenomai-help] Howto catch SEGV signals in Xenomai

[M. Koehrer]

Hi Philippe,

thanks for your mail.
I retried everything with all the files that are in the official Xenomai 2.3.0 tar.bz2 file.
I.e. I used kernel 2.6.19.2 and the adeos-ipipe-2.6.19-i386-1.6-03.patch that is in this version.
The same result.
It is a SMP kernel on a Dual Core Pentium. I use a isolcpus=1 kernel command line.

I am about to try the latest svn version of Xenomai and a 2.6.20.2 kernel.

I will let you know when I have found out more...

Regards

Mathias
> 
> This would be the the sign that a problem exists at the I-pipe level
> with your current patch. The fault should have been propagated form
> primary to secondary domain, and obviously it's not.
> 
> > 
> > How can I catch a signal in a Xenomai real time task?
> > 
> 
> There is no difference with any regular Linux application.
> 
> > I am running Xenomai 2.3.0 + NOCOW patch.
> > I have enclosed the .c file and a Makefile in a .tgz file.
> 
> Can't reproduce the issue with 1.7-03 here.
> Please make sure to use a recent and official I-pipe patch if it's not
> already the case, and not a testing patch as published on this list, so
> that we don't start chasing wild gooses.
> http://download.gna.org/adeos/patches/v2.6/
> 


-- 
Mathias Koehrer
mathias_koehrer@domain.hid


Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren
ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT JETZT bei Arcor: günstig
und schnell mit DSL - das All-Inclusive-Paket für clevere Doppel-Sparer,
nur  39,85 €  inkl. DSL- und ISDN-Grundgebühr!
http://www.arcor.de/rd/emf-dsl-2

Re: [Xenomai-help] Howto catch SEGV signals in Xenomai

[Philippe Gerum]

On Tue, 2007-03-13 at 16:25 +0100, Gilles Chanteperdrix wrote:
> M. Koehrer wrote:
> > Hi all,
> > 
> > I have a problem to catch segment violations with Xenomai:
> > For demonstration I use the following program:
> > ------------------------------------------
> > #include <stdio.h>
> > #include <sys/mman.h>
> > 
> > #include <native/task.h>
> > #include <native/sem.h>
> > RT_TASK taska_desc;
> > volatile int *pointer = 0;
> > 
> > void mytaska(void *cookie)
> > {
> >     int i;
> >     for (i=0; i < 50; i++)
> >     {
> >         rt_task_sleep(50000000);
> >         if (i > 20)
> >         {
> >             *pointer = 123;
> >         }
> >         printf("Hello %i\n", i);
> >     }
> >     printf("Hi, this is task A\n");
> > }
> > 
> > int main(void)
> > {
> >     mlockall(MCL_CURRENT|MCL_FUTURE);
> > 
> >     rt_task_create(&taska_desc, "mytaska", 0, 81, T_JOINABLE);
> >     rt_task_start(&taska_desc, &mytaska, NULL);
> > 
> >     rt_task_join(&taska_desc);
> >     printf("Main: A joined\n");
> > 
> >     return 0;
> > }
> > ---------------------------------------
> > Whenever i is greater than 20 a segment violation occurs, as I must not write
> > to address 0 (the pointer is always NULL).
> > However, what happens is, that my system freezes after printing out 18 or 19.
> > I have to reset the PC to continue.
> > When I write a printf() directly before the invalid assignment I get the usual linux
> > "segmentation fault" error message.
> > 
> > How can I catch a signal in a Xenomai real time task?
> > 
> > I am running Xenomai 2.3.0 + NOCOW patch.
> > 
> > I have enclosed the .c file and a Makefile in a .tgz file.
> > 
> > Thanks for any feedback on that issue
> 
> It looks like the "relaxing a kicked thread" issue again. Could you try
> the attached patch ?
> 

Gasp. This patch would contradict what's going on into
do_sigwake_event(); well, if you are right, we would have entered the
twilight zone with full ignition of the auxiliary boosters.

Btw, XNRELAX is a state bit, not an information one. i.e.

-               if (xnthread_test_info(thread, XNKICKED)) {
+               if (xnthread_test_info(thread, XNKICKED) && !xnthread_test_state(thread, XNRELAX)) {

-- 
Philippe.

Re: [Xenomai-help] Howto catch SEGV signals in Xenomai

[Gilles Chanteperdrix]

Philippe Gerum wrote:
 > On Tue, 2007-03-13 at 16:25 +0100, Gilles Chanteperdrix wrote:
 > > M. Koehrer wrote:
 > > > Hi all,
 > > > 
 > > > I have a problem to catch segment violations with Xenomai:
 > > > For demonstration I use the following program:
 > > > ------------------------------------------
 > > > #include <stdio.h>
 > > > #include <sys/mman.h>
 > > > 
 > > > #include <native/task.h>
 > > > #include <native/sem.h>
 > > > RT_TASK taska_desc;
 > > > volatile int *pointer = 0;
 > > > 
 > > > void mytaska(void *cookie)
 > > > {
 > > >     int i;
 > > >     for (i=0; i < 50; i++)
 > > >     {
 > > >         rt_task_sleep(50000000);
 > > >         if (i > 20)
 > > >         {
 > > >             *pointer = 123;
 > > >         }
 > > >         printf("Hello %i\n", i);
 > > >     }
 > > >     printf("Hi, this is task A\n");
 > > > }
 > > > 
 > > > int main(void)
 > > > {
 > > >     mlockall(MCL_CURRENT|MCL_FUTURE);
 > > > 
 > > >     rt_task_create(&taska_desc, "mytaska", 0, 81, T_JOINABLE);
 > > >     rt_task_start(&taska_desc, &mytaska, NULL);
 > > > 
 > > >     rt_task_join(&taska_desc);
 > > >     printf("Main: A joined\n");
 > > > 
 > > >     return 0;
 > > > }
 > > > ---------------------------------------
 > > > Whenever i is greater than 20 a segment violation occurs, as I must not write
 > > > to address 0 (the pointer is always NULL).
 > > > However, what happens is, that my system freezes after printing out 18 or 19.
 > > > I have to reset the PC to continue.
 > > > When I write a printf() directly before the invalid assignment I get the usual linux
 > > > "segmentation fault" error message.
 > > > 
 > > > How can I catch a signal in a Xenomai real time task?
 > > > 
 > > > I am running Xenomai 2.3.0 + NOCOW patch.
 > > > 
 > > > I have enclosed the .c file and a Makefile in a .tgz file.
 > > > 
 > > > Thanks for any feedback on that issue
 > > 
 > > It looks like the "relaxing a kicked thread" issue again. Could you try
 > > the attached patch ?
 > > 
 > 
 > Gasp. This patch would contradict what's going on into
 > do_sigwake_event(); well, if you are right, we would have entered the
 > twilight zone with full ignition of the auxiliary boosters.
 > 
 > Btw, XNRELAX is a state bit, not an information one. i.e.
 > 
 > -               if (xnthread_test_info(thread, XNKICKED)) {
 > +               if (xnthread_test_info(thread, XNKICKED) && !xnthread_test_state(thread, XNRELAX)) {

The code in do_sigwake_event() prevents a relaxed thread from being
kicked, but not the other way around. Who knows in what order
things get done on an SMP system ?

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-help] Howto catch SEGV signals in Xenomai

[Philippe Gerum]

On Tue, 2007-03-13 at 20:21 +0100, Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
>  > On Tue, 2007-03-13 at 16:25 +0100, Gilles Chanteperdrix wrote:
>  > > M. Koehrer wrote:
>  > > > Hi all,
>  > > > 
>  > > > I have a problem to catch segment violations with Xenomai:
>  > > > For demonstration I use the following program:
>  > > > ------------------------------------------
>  > > > #include <stdio.h>
>  > > > #include <sys/mman.h>
>  > > > 
>  > > > #include <native/task.h>
>  > > > #include <native/sem.h>
>  > > > RT_TASK taska_desc;
>  > > > volatile int *pointer = 0;
>  > > > 
>  > > > void mytaska(void *cookie)
>  > > > {
>  > > >     int i;
>  > > >     for (i=0; i < 50; i++)
>  > > >     {
>  > > >         rt_task_sleep(50000000);
>  > > >         if (i > 20)
>  > > >         {
>  > > >             *pointer = 123;
>  > > >         }
>  > > >         printf("Hello %i\n", i);
>  > > >     }
>  > > >     printf("Hi, this is task A\n");
>  > > > }
>  > > > 
>  > > > int main(void)
>  > > > {
>  > > >     mlockall(MCL_CURRENT|MCL_FUTURE);
>  > > > 
>  > > >     rt_task_create(&taska_desc, "mytaska", 0, 81, T_JOINABLE);
>  > > >     rt_task_start(&taska_desc, &mytaska, NULL);
>  > > > 
>  > > >     rt_task_join(&taska_desc);
>  > > >     printf("Main: A joined\n");
>  > > > 
>  > > >     return 0;
>  > > > }
>  > > > ---------------------------------------
>  > > > Whenever i is greater than 20 a segment violation occurs, as I must not write
>  > > > to address 0 (the pointer is always NULL).
>  > > > However, what happens is, that my system freezes after printing out 18 or 19.
>  > > > I have to reset the PC to continue.
>  > > > When I write a printf() directly before the invalid assignment I get the usual linux
>  > > > "segmentation fault" error message.
>  > > > 
>  > > > How can I catch a signal in a Xenomai real time task?
>  > > > 
>  > > > I am running Xenomai 2.3.0 + NOCOW patch.
>  > > > 
>  > > > I have enclosed the .c file and a Makefile in a .tgz file.
>  > > > 
>  > > > Thanks for any feedback on that issue
>  > > 
>  > > It looks like the "relaxing a kicked thread" issue again. Could you try
>  > > the attached patch ?
>  > > 
>  > 
>  > Gasp. This patch would contradict what's going on into
>  > do_sigwake_event(); well, if you are right, we would have entered the
>  > twilight zone with full ignition of the auxiliary boosters.
>  > 
>  > Btw, XNRELAX is a state bit, not an information one. i.e.
>  > 
>  > -               if (xnthread_test_info(thread, XNKICKED)) {
>  > +               if (xnthread_test_info(thread, XNKICKED) && !xnthread_test_state(thread, XNRELAX)) {
> 
> The code in do_sigwake_event() prevents a relaxed thread from being
> kicked, but not the other way around. Who knows in what order
> things get done on an SMP system ?
> 

I still don't find any obvious issue there. I mean, if a thread is
kicked, then it must have been unblocked from a sleep state in primary
mode; that's the purpose of the related checks in do_sigwake_event().
Since relaxing is a self-targeted operation (i.e. only a thread may
relax itself, and no thread may direct a relaxing request to another
one), then the unblocked thread must go through
request_syscall_restart() first, on its way back from the blocking
syscall, to the high stage syscall dispatcher. And all this exclusively
runs in primary mode until request_syscall_restart() eventually relaxes
the signaled thread.

IOW, I still don't see how a kicked thread would resume execution on a
different CPU without first relaxing in request_syscall_restart(), which
clears the XNKICKED bit in the first place, and as such would prevent
the situation addressed by the previous patch.

Additionally, in case of a page fault causing the signal, the latter
would be sent over the context of the faulting thread, i.e. on the same
CPU, since we can't migrate threads at this point.

The best way to prove or contradict this analysis is to run the test
code, pulling the brake in case I'm wrong. Please Mathias, could you try
this on your system:

--- ksrc/nucleus/pod.c	(revision 2293)
+++ ksrc/nucleus/pod.c	(working copy)
@@ -1420,6 +1420,11 @@
 		   the KICKED bit set, so that xnshadow_relax() is never
 		   prevented from blocking the current thread. */
 		if (xnthread_test_info(thread, XNKICKED)) {
+			XENO_ASSERT(NUCLEUS, (mask & XNRELAX) != 0,
+				    xnpod_fatal("Relaxing a kicked thread"
+						"(thread=%s, mask=%lx)?!",
+						thread->name, mask);
+				);
 			xnthread_clear_info(thread, XNRMID | XNTIMEO);
 			xnthread_set_info(thread, XNBREAK);
 			goto unlock_and_exit;


-- 
Philippe.

Re: [Xenomai-help] Howto catch SEGV signals in Xenomai

[Philippe Gerum]

On Tue, 2007-03-13 at 23:34 +0100, Philippe Gerum wrote:
> On Tue, 2007-03-13 at 20:21 +0100, Gilles Chanteperdrix wrote:
> > Philippe Gerum wrote:
> >  > On Tue, 2007-03-13 at 16:25 +0100, Gilles Chanteperdrix wrote:
> >  > > M. Koehrer wrote:
> >  > > > Hi all,
> >  > > > 
> >  > > > I have a problem to catch segment violations with Xenomai:
> >  > > > For demonstration I use the following program:
> >  > > > ------------------------------------------
> >  > > > #include <stdio.h>
> >  > > > #include <sys/mman.h>
> >  > > > 
> >  > > > #include <native/task.h>
> >  > > > #include <native/sem.h>
> >  > > > RT_TASK taska_desc;
> >  > > > volatile int *pointer = 0;
> >  > > > 
> >  > > > void mytaska(void *cookie)
> >  > > > {
> >  > > >     int i;
> >  > > >     for (i=0; i < 50; i++)
> >  > > >     {
> >  > > >         rt_task_sleep(50000000);
> >  > > >         if (i > 20)
> >  > > >         {
> >  > > >             *pointer = 123;
> >  > > >         }
> >  > > >         printf("Hello %i\n", i);
> >  > > >     }
> >  > > >     printf("Hi, this is task A\n");
> >  > > > }
> >  > > > 
> >  > > > int main(void)
> >  > > > {
> >  > > >     mlockall(MCL_CURRENT|MCL_FUTURE);
> >  > > > 
> >  > > >     rt_task_create(&taska_desc, "mytaska", 0, 81, T_JOINABLE);
> >  > > >     rt_task_start(&taska_desc, &mytaska, NULL);
> >  > > > 
> >  > > >     rt_task_join(&taska_desc);
> >  > > >     printf("Main: A joined\n");
> >  > > > 
> >  > > >     return 0;
> >  > > > }
> >  > > > ---------------------------------------
> >  > > > Whenever i is greater than 20 a segment violation occurs, as I must not write
> >  > > > to address 0 (the pointer is always NULL).
> >  > > > However, what happens is, that my system freezes after printing out 18 or 19.
> >  > > > I have to reset the PC to continue.
> >  > > > When I write a printf() directly before the invalid assignment I get the usual linux
> >  > > > "segmentation fault" error message.
> >  > > > 
> >  > > > How can I catch a signal in a Xenomai real time task?
> >  > > > 
> >  > > > I am running Xenomai 2.3.0 + NOCOW patch.
> >  > > > 
> >  > > > I have enclosed the .c file and a Makefile in a .tgz file.
> >  > > > 
> >  > > > Thanks for any feedback on that issue
> >  > > 
> >  > > It looks like the "relaxing a kicked thread" issue again. Could you try
> >  > > the attached patch ?
> >  > > 
> >  > 
> >  > Gasp. This patch would contradict what's going on into
> >  > do_sigwake_event(); well, if you are right, we would have entered the
> >  > twilight zone with full ignition of the auxiliary boosters.
> >  > 
> >  > Btw, XNRELAX is a state bit, not an information one. i.e.
> >  > 
> >  > -               if (xnthread_test_info(thread, XNKICKED)) {
> >  > +               if (xnthread_test_info(thread, XNKICKED) && !xnthread_test_state(thread, XNRELAX)) {
> > 
> > The code in do_sigwake_event() prevents a relaxed thread from being
> > kicked, but not the other way around. Who knows in what order
> > things get done on an SMP system ?
> > 
> 
> I still don't find any obvious issue there. I mean, if a thread is
> kicked, then it must have been unblocked from a sleep state in primary
> mode; that's the purpose of the related checks in do_sigwake_event().
> Since relaxing is a self-targeted operation (i.e. only a thread may
> relax itself, and no thread may direct a relaxing request to another
> one), then the unblocked thread must go through
> request_syscall_restart() first, on its way back from the blocking
> syscall, to the high stage syscall dispatcher. And all this exclusively
> runs in primary mode until request_syscall_restart() eventually relaxes
> the signaled thread.
> 
> IOW, I still don't see how a kicked thread would resume execution on a
> different CPU without first relaxing in request_syscall_restart(), which
> clears the XNKICKED bit in the first place, and as such would prevent
> the situation addressed by the previous patch.
> 
> Additionally, in case of a page fault causing the signal, the latter
> would be sent over the context of the faulting thread, i.e. on the same
> CPU, since we can't migrate threads at this point.
> 
> The best way to prove or contradict this analysis is to run the test
> code, pulling the brake in case I'm wrong. Please Mathias, could you try
> this on your system:
> 

Sorry, that one is better:

> --- ksrc/nucleus/pod.c	(revision 2293)
> +++ ksrc/nucleus/pod.c	(working copy)
> @@ -1420,6 +1420,11 @@
>  		   the KICKED bit set, so that xnshadow_relax() is never
>  		   prevented from blocking the current thread. */
>  		if (xnthread_test_info(thread, XNKICKED)) {
> +			XENO_ASSERT(NUCLEUS, (mask & XNRELAX) != 0,

+			XENO_ASSERT(NUCLEUS, (mask & XNRELAX) == 0,

> +				    xnpod_fatal("Relaxing a kicked thread"
> +						"(thread=%s, mask=%lx)?!",
> +						thread->name, mask);
> +				);
>  			xnthread_clear_info(thread, XNRMID | XNTIMEO);
>  			xnthread_set_info(thread, XNBREAK);
>  			goto unlock_and_exit;
> 
> 
-- 
Philippe.

Re: Re: [Xenomai-help] Howto catch SEGV signals in Xenomai

[M. Koehrer]

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

Hi all,

thanks for all the feedback on that issue.
Since yesterday I did a couple of tests on kernel 2.6.19.2
1. I used the adeos patch provided with xenomai-2.3.0 
SMP mode => freeze with my program. I have enclosed the kernel config for this one
UP mode => freeze with my program

2. I added the patch from Philippe (the second one):

--- ksrc/nucleus/pod.c		 (revision 2293)
+++ ksrc/nucleus/pod.c		 (working copy)
@@ -1420,6 +1420,11 @@
 		 		    the KICKED bit set, so that xnshadow_relax() is never
 		 		    prevented from blocking the current thread. */
 		 		 if (xnthread_test_info(thread, XNKICKED)) {
+		 		 		 XENO_ASSERT(NUCLEUS, (mask & XNRELAX) == 0,
+		 		 		 		     xnpod_fatal("Relaxing a kicked thread"
+		 		 		 		 		 		 "(thread=%s, mask=%lx)?!",
+		 		 		 		 		 		 thread->name, mask);
+		 		 		 		 );
 		 		 		 xnthread_clear_info(thread, XNRMID | XNTIMEO);
 		 		 		 xnthread_set_info(thread, XNBREAK);
 		 		 		 goto unlock_and_exit;

I used this patch on the UP kernel 2.6.19.2. Same adeos version as before.
The result  was the same => PC freeze

3. I tried kernel 2.6.20.2 and the same (SMP) configuration as with 2.6.19.2
I used the Xenomai subversion #2292 and the adeos patch that is in subversion
(adeos-ipipe-2.6.20-i386-1.7-02.patch).
And with that combination it is working! I get the expected "Segmentation fault" message.
I don't know why, but it seems to be working!

I will try to use the same Xenomai svn version on the 2.6.19.2 to see if this is a 2.6.19 issue...

Regards

Mathias




-- 
Mathias Koehrer
mathias_koehrer@domain.hid


Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren
ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT JETZT bei Arcor: günstig
und schnell mit DSL - das All-Inclusive-Paket für clevere Doppel-Sparer,
nur  39,85 €  inkl. DSL- und ISDN-Grundgebühr!
http://www.arcor.de/rd/emf-dsl-2

[-- Attachment #2: linux_config.gz --]
[-- Type: application/x-gzip, Size: 8480 bytes --]

Re: Re: [Xenomai-help] Howto catch SEGV signals in Xenomai

[M. Koehrer]

Hi all,

one additional thing I found out:
I used the Xenomai SVN version not on a 2.6.20.2 but on the 2.6.19.2 kernel.
And here I had the freeze again. 
As I have written in my previous mail, it worked fine with 2.6.20.2
It seems as if kernel 2.6.19.2 is causing the trouble...
No idea why...
For me it is fine to switch over to 2.6.20, however I'd like to use a "stable" version
of Xenomai for it.
Is there a schedule for the next "stable" xenomai version that supports 2.6.20?

Thanks for all support!

Regards

Mathias
> thanks for all the feedback on that issue.
> Since yesterday I did a couple of tests on kernel 2.6.19.2
> 1. I used the adeos patch provided with xenomai-2.3.0 
> SMP mode => freeze with my program. I have enclosed the kernel config for
> this one
> UP mode => freeze with my program
> 
> 2. I added the patch from Philippe (the second one):
> 
> --- ksrc/nucleus/pod.c		 (revision 2293)
> +++ ksrc/nucleus/pod.c		 (working copy)
> @@ -1420,6 +1420,11 @@
>  		 		    the KICKED bit set, so that xnshadow_relax() is never
>  		 		    prevented from blocking the current thread. */
>  		 		 if (xnthread_test_info(thread, XNKICKED)) {
> +		 		 		 XENO_ASSERT(NUCLEUS, (mask & XNRELAX) == 0,
> +		 		 		 		     xnpod_fatal("Relaxing a kicked thread"
> +		 		 		 		 		 		 "(thread=%s, mask=%lx)?!",
> +		 		 		 		 		 		 thread->name, mask);
> +		 		 		 		 );
>  		 		 		 xnthread_clear_info(thread, XNRMID | XNTIMEO);
>  		 		 		 xnthread_set_info(thread, XNBREAK);
>  		 		 		 goto unlock_and_exit;
> 
> I used this patch on the UP kernel 2.6.19.2. Same adeos version as before.
> The result  was the same => PC freeze
> 
> 3. I tried kernel 2.6.20.2 and the same (SMP) configuration as with
> 2.6.19.2
> I used the Xenomai subversion #2292 and the adeos patch that is in
> subversion
> (adeos-ipipe-2.6.20-i386-1.7-02.patch).
> And with that combination it is working! I get the expected "Segmentation
> fault" message.
> I don't know why, but it seems to be working!
> 
> I will try to use the same Xenomai svn version on the 2.6.19.2 to see if
> this is a 2.6.19 issue...
> 
> Regards
> 
> Mathias
> 
> 
> 
> 
> -- 
> Mathias Koehrer
> mathias_koehrer@domain.hid
> 
> 
> Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren
> ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT JETZT bei Arcor: günstig
> und schnell mit DSL - das All-Inclusive-Paket für clevere Doppel-Sparer,
> nur  39,85 €  inkl. DSL- und ISDN-Grundgebühr!
> http://www.arcor.de/rd/emf-dsl-2

-- 
Mathias Koehrer
mathias_koehrer@domain.hid


Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren
ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT JETZT bei Arcor: günstig
und schnell mit DSL - das All-Inclusive-Paket für clevere Doppel-Sparer,
nur  39,85 €  inkl. DSL- und ISDN-Grundgebühr!
http://www.arcor.de/rd/emf-dsl-2

Re: Re: [Xenomai-help] Howto catch SEGV signals in Xenomai

[Philippe Gerum]

On Wed, 2007-03-14 at 09:47 +0100, M. Koehrer wrote:
> Hi all,
> 
> one additional thing I found out:
> I used the Xenomai SVN version not on a 2.6.20.2 but on the 2.6.19.2 kernel.
> And here I had the freeze again. 
> As I have written in my previous mail, it worked fine with 2.6.20.2
> It seems as if kernel 2.6.19.2 is causing the trouble...

Could you confirm that, Adeos-wise, you tried both 2.6.19-1.6-03 (not
working) and 2.6.20-1.7-02 (working)? if so, does 2.6.19-1.7-02 (or -03)
also work in your configuration?

> No idea why...
> For me it is fine to switch over to 2.6.20, however I'd like to use a "stable" version
> of Xenomai for it.
> Is there a schedule for the next "stable" xenomai version that supports 2.6.20?
> 

2.3.1 is scheduled on 3/19.

> Thanks for all support!
> 
> Regards
> 
> Mathias
> > thanks for all the feedback on that issue.
> > Since yesterday I did a couple of tests on kernel 2.6.19.2
> > 1. I used the adeos patch provided with xenomai-2.3.0 
> > SMP mode => freeze with my program. I have enclosed the kernel config for
> > this one
> > UP mode => freeze with my program
> > 
> > 2. I added the patch from Philippe (the second one):
> > 
> > --- ksrc/nucleus/pod.c		 (revision 2293)
> > +++ ksrc/nucleus/pod.c		 (working copy)
> > @@ -1420,6 +1420,11 @@
> >  		 		    the KICKED bit set, so that xnshadow_relax() is never
> >  		 		    prevented from blocking the current thread. */
> >  		 		 if (xnthread_test_info(thread, XNKICKED)) {
> > +		 		 		 XENO_ASSERT(NUCLEUS, (mask & XNRELAX) == 0,
> > +		 		 		 		     xnpod_fatal("Relaxing a kicked thread"
> > +		 		 		 		 		 		 "(thread=%s, mask=%lx)?!",
> > +		 		 		 		 		 		 thread->name, mask);
> > +		 		 		 		 );
> >  		 		 		 xnthread_clear_info(thread, XNRMID | XNTIMEO);
> >  		 		 		 xnthread_set_info(thread, XNBREAK);
> >  		 		 		 goto unlock_and_exit;
> > 
> > I used this patch on the UP kernel 2.6.19.2. Same adeos version as before.
> > The result  was the same => PC freeze
> > 
> > 3. I tried kernel 2.6.20.2 and the same (SMP) configuration as with
> > 2.6.19.2
> > I used the Xenomai subversion #2292 and the adeos patch that is in
> > subversion
> > (adeos-ipipe-2.6.20-i386-1.7-02.patch).
> > And with that combination it is working! I get the expected "Segmentation
> > fault" message.
> > I don't know why, but it seems to be working!
> > 
> > I will try to use the same Xenomai svn version on the 2.6.19.2 to see if
> > this is a 2.6.19 issue...
> > 
> > Regards
> > 
> > Mathias
> > 
> > 
> > 
> > 
> > -- 
> > Mathias Koehrer
> > mathias_koehrer@domain.hid
> > 
> > 
> > Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren
> > ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT JETZT bei Arcor: günstig
> > und schnell mit DSL - das All-Inclusive-Paket für clevere Doppel-Sparer,
> > nur  39,85 €  inkl. DSL- und ISDN-Grundgebühr!
> > http://www.arcor.de/rd/emf-dsl-2
> 
-- 
Philippe.

Re: Re: [Xenomai-help] Howto catch SEGV signals in Xenomai

[Philippe Gerum]

On Wed, 2007-03-14 at 09:17 +0100, M. Koehrer wrote:
> Hi all,
> 
> thanks for all the feedback on that issue.
> Since yesterday I did a couple of tests on kernel 2.6.19.2
> 1. I used the adeos patch provided with xenomai-2.3.0 
> SMP mode => freeze with my program. I have enclosed the kernel config for this one
> UP mode => freeze with my program
> 
> 2. I added the patch from Philippe (the second one):
> 
> --- ksrc/nucleus/pod.c		 (revision 2293)
> +++ ksrc/nucleus/pod.c		 (working copy)
> @@ -1420,6 +1420,11 @@
>  		 		    the KICKED bit set, so that xnshadow_relax() is never
>  		 		    prevented from blocking the current thread. */
>  		 		 if (xnthread_test_info(thread, XNKICKED)) {
> +		 		 		 XENO_ASSERT(NUCLEUS, (mask & XNRELAX) == 0,
> +		 		 		 		     xnpod_fatal("Relaxing a kicked thread"
> +		 		 		 		 		 		 "(thread=%s, mask=%lx)?!",
> +		 		 		 		 		 		 thread->name, mask);
> +		 		 		 		 );
>  		 		 		 xnthread_clear_info(thread, XNRMID | XNTIMEO);
>  		 		 		 xnthread_set_info(thread, XNBREAK);
>  		 		 		 goto unlock_and_exit;
> 
> I used this patch on the UP kernel 2.6.19.2. Same adeos version as before.
> The result  was the same => PC freeze
> 

Make sure to switch on the nucleus debug option, so that this code
triggers if appropriate.

-- 
Philippe.

Re: Re: [Xenomai-help] Howto catch SEGV signals in Xenomai

[M. Koehrer]

Hello Philippe,

here is a table of the test I have done:
With the Xenomai SVN (#2292) I used the patches in the SVN repository:
2.6.19.2 with adeos-ipipe-2.6.19-i386-1.7-02.patch
2.6.20.2 with adeos-ipipe-2.6.20-i386-1.7-02.patch

With Xenomai-2.3.0 I used 
2.6.19.2 with adeos-ipipe-2.6.19-i386-1.6-03.patch

The result was, that with 2.6.20.2 it was working as expected,
with 2.6.19.2 there was the PC freeze.

Regards

Mathias
> Could you confirm that, Adeos-wise, you tried both 2.6.19-1.6-03 (not
> working) and 2.6.20-1.7-02 (working)? if so, does 2.6.19-1.7-02 (or -03)
> also work in your configuration?
> 


-- 
Mathias Koehrer
mathias_koehrer@domain.hid


Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren
ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT JETZT bei Arcor: günstig
und schnell mit DSL - das All-Inclusive-Paket für clevere Doppel-Sparer,
nur  39,85 €  inkl. DSL- und ISDN-Grundgebühr!
http://www.arcor.de/rd/emf-dsl-2

Re: Re: [Xenomai-help] Howto catch SEGV signals in Xenomai

[Philippe Gerum]

On Wed, 2007-03-14 at 12:18 +0100, M. Koehrer wrote:
> Hello Philippe,
> 
> here is a table of the test I have done:
> With the Xenomai SVN (#2292) I used the patches in the SVN repository:
> 2.6.19.2 with adeos-ipipe-2.6.19-i386-1.7-02.patch
> 2.6.20.2 with adeos-ipipe-2.6.20-i386-1.7-02.patch
> 
> With Xenomai-2.3.0 I used 
> 2.6.19.2 with adeos-ipipe-2.6.19-i386-1.6-03.patch
> 
> The result was, that with 2.6.20.2 it was working as expected,
> with 2.6.19.2 there was the PC freeze.

Ok, could you activate the nmi watchdog for the kernel (nmi_watchdog=2
added to the bootparams) and CONFIG_FRAME_POINTER, and also the nucleus
watchdog (CONFIG_XENO_OPT_WATCHDOG), in the failing case? Maybe one of
them would trigger. TIA,

> 
> Regards
> 
> Mathias
> > Could you confirm that, Adeos-wise, you tried both 2.6.19-1.6-03 (not
> > working) and 2.6.20-1.7-02 (working)? if so, does 2.6.19-1.7-02 (or -03)
> > also work in your configuration?
> > 
> 
> 
-- 
Philippe.

Re: Re: [Xenomai-help] Howto catch SEGV signals in Xenomai

[M. Koehrer]

Hi Philippe,

I tried with nmi_watchdog
However with nmi_watchdog=1 I am not able to load my module xeno_native as 
the PC resets during the modprobe command...
I remember that I had this strange issue a while ago with the 2.6.19 kernel...

With nmi_watchdog=2 I can modprobe xeno_native, however I do see any change.
The PC is still freezing.

Regards

Mathias
----- Original Nachricht ----
Von:     Philippe Gerum <rpm@xenomai.org>
An:      "M. Koehrer" <mathias_koehrer@domain.hid>
Datum:   14.03.2007 14:32
Betreff: Re: Re: [Xenomai-help] Howto catch SEGV signals in Xenomai

> On Wed, 2007-03-14 at 12:18 +0100, M. Koehrer wrote:
> > Hello Philippe,
> > 
> > here is a table of the test I have done:
> > With the Xenomai SVN (#2292) I used the patches in the SVN repository:
> > 2.6.19.2 with adeos-ipipe-2.6.19-i386-1.7-02.patch
> > 2.6.20.2 with adeos-ipipe-2.6.20-i386-1.7-02.patch
> > 
> > With Xenomai-2.3.0 I used 
> > 2.6.19.2 with adeos-ipipe-2.6.19-i386-1.6-03.patch
> > 
> > The result was, that with 2.6.20.2 it was working as expected,
> > with 2.6.19.2 there was the PC freeze.
> 
> Ok, could you activate the nmi watchdog for the kernel (nmi_watchdog=2
> added to the bootparams) and CONFIG_FRAME_POINTER, and also the nucleus
> watchdog (CONFIG_XENO_OPT_WATCHDOG), in the failing case? Maybe one of
> them would trigger. TIA,
> 
> > 
> > Regards
> > 
> > Mathias
> > > Could you confirm that, Adeos-wise, you tried both 2.6.19-1.6-03 (not
> > > working) and 2.6.20-1.7-02 (working)? if so, does 2.6.19-1.7-02 (or
> -03)
> > > also work in your configuration?
> > > 
> > 
> > 
> -- 
> Philippe.
> 
> 
> 

-- 
Mathias Koehrer
mathias_koehrer@domain.hid


Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren
ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT JETZT bei Arcor: günstig
und schnell mit DSL - das All-Inclusive-Paket für clevere Doppel-Sparer,
nur  39,85 €  inkl. DSL- und ISDN-Grundgebühr!
http://www.arcor.de/rd/emf-dsl-2

Re: Re: [Xenomai-help] Howto catch SEGV signals in Xenomai

[Philippe Gerum]

On Wed, 2007-03-14 at 13:36 +0100, M. Koehrer wrote:
> Hi Philippe, 
> 
> I applied again the patch to the 2.6.19.2 (adeos-ipipe-2.6.19-i386-1.6-03.patch)
> and also enabled the nucleus debug option.
> But there is no change. The system still freezes.
> 

Ok, thanks. So we did no enter the twilight zone, yet.

> Regards
> 
> Mathias
> > > I used this patch on the UP kernel 2.6.19.2. Same adeos version as
> > before.
> > > The result  was the same => PC freeze
> > > 
> > 
> > Make sure to switch on the nucleus debug option, so that this code
> > triggers if appropriate.
> > 
> > -- 
> > Philippe.
> > 
> > 
> > 
> 
> 
-- 
Philippe.

Re: Re: [Xenomai-help] Howto catch SEGV signals in Xenomai

[M. Koehrer]

Hi Philippe, 

I applied again the patch to the 2.6.19.2 (adeos-ipipe-2.6.19-i386-1.6-03.patch)
and also enabled the nucleus debug option.
But there is no change. The system still freezes.

Regards

Mathias
> > I used this patch on the UP kernel 2.6.19.2. Same adeos version as
> before.
> > The result  was the same => PC freeze
> > 
> 
> Make sure to switch on the nucleus debug option, so that this code
> triggers if appropriate.
> 
> -- 
> Philippe.
> 
> 
> 


-- 
Mathias Koehrer
mathias_koehrer@domain.hid


Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren
ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT JETZT bei Arcor: günstig
und schnell mit DSL - das All-Inclusive-Paket für clevere Doppel-Sparer,
nur  39,85 €  inkl. DSL- und ISDN-Grundgebühr!
http://www.arcor.de/rd/emf-dsl-2