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

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

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: [Xenomai-help] Howto catch SEGV signals in Xenomai

[Gilles Chanteperdrix]

Philippe Gerum wrote:
> 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.

Ok, but since I already had a case of trying to relax a kicked thread, I
would vote for leaving the XENO_ASSERT.

-- 
                                                 Gilles Chanteperdrix

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

[Philippe Gerum]

On Wed, 2007-03-14 at 14:26 +0100, Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
> > 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.
> 
> Ok, but since I already had a case of trying to relax a kicked thread, I
> would vote for leaving the XENO_ASSERT.
> 

Ack.

-- 
Philippe.

[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: [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.