From: Tschaeche IT-Services <services@domain.hid>
To: Philippe Gerum <rpm@xenomai.org>
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai-help] Handling Linux Signals in primary domain context
Date: Tue, 1 Jun 2010 17:54:04 +0200 [thread overview]
Message-ID: <20100601155403.GA8240@domain.hid> (raw)
In-Reply-To: <1275402757.27918.151.camel@domain.hid>
[-- Attachment #1: Type: text/plain, Size: 1308 bytes --]
On Tue, Jun 01, 2010 at 04:32:37PM +0200, Philippe Gerum wrote:
> Not in the absence of syscall. We thought about this once already, when
> considering how a watchdog preempting a runaway task in primary mode
> could force a secondary mode switch: there is no sane and easy solution
> to this unfortunately.
This is exactly Sigmatek's problem: Our customers develop code
within our debugging/development environment. We want to catch
this situation (the developer implements a while(1)) with a
watchdog throwing SIGTRAP so that our debugger gets active
and can locate the problem according to the stack frame...
Find attached a separated test case (using SIGTERM which
should terminate the application). When pressing space
the system freezes (work_l() is in the while() loop with
pending signal and work_h() does not rt_task_suspend()
anymore (returning EINTR).
Then, we implement a workaround sending a rt-signal
when rt_task_suspend() returns EINTR. In the rt-signal
handler we explicitely migrate the task to secondary
domain, where linux signal handling is triggered...
Thanks,
Olli
--
Tschaeche IT-Services Tel.: +49/9134/9089850
Dr.-Ing. Oliver Tschäche Mobil: +49/176/20435601
Welluckenweg 4 Email: services@domain.hid
91077 Neunkirchen
[-- Attachment #2: signal2xenomai.c --]
[-- Type: text/x-csrc, Size: 1996 bytes --]
/* compile with gcc -Wall -D_GNU_SOURCE -lpthread -o thisfile thisfile.c */
/*
* Simple test app to show pthread api mutex behaviour.
*
* This is compared against the Xenomai native api behaviour.
* See mutex_xeno_native.c
*/
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <sys/mman.h> /* Needed for mlockall() */
#include <limits.h>
#include <pthread.h>
#include "native/task.h"
#define MY_STACK_SIZE (100*1024) /* 100 kB is enough for now. */
static pthread_t ph, pl;
static RT_TASK xh, xl;
static volatile int state = 0;
void *
work_h(void *cookie)
{
if (rt_task_shadow(&xh, "high", 50, 0)) {
printf("failed to shadow high\n");
return NULL;
}
if (rt_task_set_periodic(&xh, TM_NOW, 1000000)) {
printf("failed to set high periodic\n");
return NULL;
}
while (1) {
if (rt_task_wait_period(NULL)) {
printf("wait_period failed\n");
break;
}
switch (state) {
case -1:
if (rt_task_suspend(&xl)) {
/* work around??? */
}
state = 1;
break;
case 1:
rt_task_resume(&xl);
state = -1;
break;
default:
break;
}
}
return NULL;
}
void *
work_l(void *cookie)
{
if (rt_task_shadow(&xl, "low", 25, 0)) {
printf("failed to shadow low\n");
return NULL;
}
if (rt_task_set_mode(0, T_PRIMARY, NULL)) {
printf("failed to migrate low\n");
return NULL;
}
state = -1;
while (1)
;
return NULL;
}
int main(void)
{
pthread_attr_t threadattr;
mlockall(MCL_CURRENT | MCL_FUTURE);
pthread_attr_init(&threadattr);
pthread_attr_setstacksize(&threadattr, MY_STACK_SIZE);
pthread_create(&ph, &threadattr, work_h, NULL);
printf("high prio watchdog started\n");
pthread_create(&pl, &threadattr, work_l, NULL);
printf("low prio work started\n");
printf("Press <ENTER> to send a signal\n");
getc(stdin);
pthread_kill(pl, SIGTERM);
/* you will not get here, because work_l() eats up your CPU */
printf("Press <ENTER> to finish\n");
getc(stdin);
printf("main finished\n");
return 0;
}
next prev parent reply other threads:[~2010-06-01 15:54 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-01 13:50 [Xenomai-help] Handling Linux Signals in primary domain context Tschaeche IT-Services
2010-06-01 13:52 ` Gilles Chanteperdrix
2010-06-01 13:59 ` Gilles Chanteperdrix
2010-06-01 14:32 ` Philippe Gerum
2010-06-01 15:54 ` Tschaeche IT-Services [this message]
2010-06-01 16:52 ` Tschaeche IT-Services
2010-06-01 16:58 ` Jan Kiszka
2010-06-02 8:36 ` Gilles Chanteperdrix
2010-06-02 9:14 ` Jan Kiszka
2010-06-02 9:15 ` Philippe Gerum
2010-06-02 9:20 ` Jan Kiszka
2010-06-02 9:28 ` Philippe Gerum
2010-06-02 9:37 ` Gilles Chanteperdrix
2010-06-02 10:06 ` Philippe Gerum
2010-06-02 10:19 ` Gilles Chanteperdrix
2010-06-02 10:42 ` Philippe Gerum
2010-06-02 10:51 ` Gilles Chanteperdrix
2010-06-02 10:29 ` Gilles Chanteperdrix
2010-06-02 9:21 ` Gilles Chanteperdrix
2010-06-02 9:23 ` Jan Kiszka
2010-06-02 10:19 ` Tschaeche IT-Services
2010-06-02 10:48 ` Gilles Chanteperdrix
2010-06-02 9:34 ` Philippe Gerum
2010-06-02 9:43 ` Gilles Chanteperdrix
2010-06-02 12:02 ` Daniele Nicolodi
2010-06-02 13:47 ` Gilles Chanteperdrix
2010-06-02 15:14 ` Philippe Gerum
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100601155403.GA8240@domain.hid \
--to=services@domain.hid \
--cc=rpm@xenomai.org \
--cc=xenomai@xenomai.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.