From: Michel Rinaldi <automation.03@domain.hid>
To: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai-help] Problems with rt_task_create and rt_task_join
Date: Mon, 24 Jan 2011 17:39:11 +0100 (CET) [thread overview]
Message-ID: <23405065.111295887148359.JavaMail.SYSTEM@PC-MRINALDI> (raw)
In-Reply-To: <22536578.91295887083468.JavaMail.SYSTEM@PC-MRINALDI>
[-- Attachment #1.1: Type: text/plain, Size: 3301 bytes --]
----- Messaggio originale -----
Da: "Gilles Chanteperdrix" <gilles.chanteperdrix@xenomai.org>
A: "Michel Rinaldi" <automation.03@domain.hid>
Cc: xenomai@xenomai.org
Inviato: Lunedì, 24 gennaio 2011 15:27:51 GMT +01:00 Amsterdam/Berlino/Berna/Roma/Stoccolma/Vienna
Oggetto: Re: [Xenomai-help] Problems with rt_task_create and rt_task_join
.....
>You explanations are hard to follow and understand, and what is more,
>ambiguous. Send us a piece of code which allows us to reproduce this
>issue. Trying to make it as simple as possible. For instance seeing if
>registering the interrupt causes any difference (if it does not make any
>difference, then remove it, you get the idea).
My code is really big and complex to reduce, I'll try to simplify it in next days.
>As usual, we do not know what version of Xenomai, Adeos, Linux, etc...
>you are using. See:
>http://www.xenomai.org/index.php/Request_for_information
I post them into firts mail of this thread, anyway they are:
- Linux system with kernel 2.6.35.7
- Xenomai 2.5.5.2
- Adeos ipipe patch 2.7-04
GCC is on version 4.4.3.
.....
>That is bad. One more question: what happens when you run the "latency"
>test, do you get strange results? Also, I see that you have the SMI
>workaround enabled, does it detect your chipset?
Yes, as system log says, Xenomai detect SMI motherboard and disable them.
I run the latency test: without other loads onto system, I observe values like these:
RTT| 00:00:01 (periodic user-mode task, 100 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD| 6.680| 7.157| 12.187| 0| 0| 6.680| 12.187
RTD| 6.277| 6.980| 10.519| 0| 0| 6.277| 12.187
RTD| 1.175| 7.122| 9.315| 0| 0| 1.175| 12.187
RTD| 1.578| 7.112| 9.382| 0| 0| 1.175| 12.187
RTD| 1.635| 7.133| 10.307| 0| 0| 1.175| 12.187
also after long runnings.
But if I launch application contained into attached main_app.c file (that represents my simplified application)
what I observe into latency test is:
RTD| 1.635| 7.133| 10.307| 0| 0| 1.175| 12.187
RTD| 1.591| 20.101| 129847.817| 1298| 0| 1.175| 129847.817
RTD| 1.860| 7.133| 12.814| 1298| 0| 1.175| 129847.817
Then, if I CTRL+C my app:
RTD| 2.091| 7.468| 15.687| 1298| 0| 1.175| 129847.817
RTD| 1.861| 8.397| 8157.893| 1379| 0| 1.175| 129847.817
RTD| 6.282| 7.287| 15.007| 1379| 0| 1.175| 129847.817
In concomitance with first very high latency, I observe into dmesg the clocksource switch message.
In one case I observed an extremely bigger value for lat max: in facts, system freezed for about 2 seconds.
RTD| 2.091| 7.468| 11.687| 0| 0| 1.133| 20.817
RTD| 1.436| 254.870|-1819173.554| 24758| 0| 1.133|-1819173.554
RTD| 1.768| 7.287| 12.007| 24758| 0| 1.133|-1819173.554
I also observed that during same latency test the first application start generates the longest time in comparison to other starts.
To run, my app needs kernel module contained into attached timer_module.c file, that signals a semaphore used by app every 1 ms.
I don't observe some strange variations in latency test values when inserting or removing this kernel module.
Thank you very much for your help, Gilles.
Regards
Mauro
[-- Attachment #1.2: Type: text/html, Size: 6038 bytes --]
[-- Attachment #2: main_app.c --]
[-- Type: application/octet-stream, Size: 2748 bytes --]
#include <native/task.h>
#include <native/timer.h>
#include <native/sem.h>
#include <native/heap.h>
#include <rtdk.h>
#include <signal.h>
#include <unistd.h>
#include <sys/io.h>
#include <sys/mman.h>
#include <bits/local_lim.h>
#define REQMGR_SHM_NAME "R_ST_M"
#define REQMGR_STRUCT_SEM_NAME "R_ST_S"
static unsigned char bBreakReqLoop = 0;
static unsigned char bBreakLoop = 0;
static RT_TASK tMainTask;
static RT_TASK tSchedTask;
static RT_SEM lpTimerSem;
static RT_HEAP main_heap;
typedef struct _tag_ReqStruct
{
RT_SEM lpStartSem;
/* .... */
} ReqStruct;
ReqStruct* lpRequest;
static void SignalHandler ( int signal )
{
rt_printf("sighandler called\n");
bBreakReqLoop = 1;
}
void SchedThreadProc ( void *unused )
{
rt_printf ( "Scheduler thread ready for execution\n" );
while ( !bBreakLoop )
{
rt_sem_p ( &lpTimerSem, TM_INFINITE );
/* do some work */
}
return;
}
int main ( void )
{
int nRet = 0;
mlockall ( MCL_CURRENT | MCL_FUTURE );
rt_print_auto_init(1);
if (rt_task_shadow(&tMainTask,"RTKER",0,0) == 0)
{
nRet = rt_sem_bind( &lpTimerSem, "SEMTIM", TM_NONBLOCK);
if ( nRet == 0 )
{
if (rt_heap_create(&main_heap,REQMGR_SHM_NAME,sizeof(ReqStruct),H_SHARED) == 0)
{
nRet = rt_heap_alloc(&main_heap,sizeof(ReqStruct),TM_NONBLOCK,(void **)&lpRequest);
if ( nRet == 0)
{
if (rt_sem_create ( &lpRequest->lpStartSem, REQMGR_STRUCT_SEM_NAME, 0, S_FIFO ) == 0 )
{
rt_task_create(&tSchedTask, "SKER_T", 0, 99, T_JOINABLE);
signal( SIGTERM , SignalHandler );
signal( SIGINT, SignalHandler );
rt_task_start(&tSchedTask, SchedThreadProc, NULL);
rt_printf ( "Request management thread ready for execution\n" );
while ( !bBreakReqLoop )
{
// check semaphore signalling (signalled
nRet = rt_sem_p_until ( &lpRequest->lpStartSem , 1000000000 );
if ( nRet == 0 )
{
/* work loop */
}
rt_task_sleep ( 10000000 );
} /* end while */
//Request scheduling thread to exit
bBreakLoop = 1;
rt_task_join(&tSchedTask);
rt_sem_delete ( &lpRequest->lpStartSem );
rt_heap_delete(&main_heap);
}
else
{
rt_printf("Semaphore creation error\n");
}
rt_heap_free(&main_heap,(void *)&lpRequest);
}
else
{
rt_printf("Heap alloc error %d\n",nRet);
}
}
else
{
rt_printf("error creating heap\n");
}
rt_sem_unbind(&lpTimerSem);
}
else
{
rt_printf ("unable to find timer semaphore %d\n",nRet );
}
}
else
{
rt_printf("error converting to Xenomai Task\n");
}
munlockall ( );
rt_printf ( "END\n\n" );
return 0;
}
[-- Attachment #3: timer_module.c --]
[-- Type: application/octet-stream, Size: 1176 bytes --]
#include <linux/kernel.h>
#include <linux/module.h>
#include <native/sem.h>
#include <rtdm/rtdm_driver.h>
#define SEM_NAME "SEMTIM"
#define TIMER_PERIOD_NSEC 1000000
#define PERIODIC_TASK_PRIO RTDM_TASK_HIGHEST_PRIORITY
#define PERIODIC_TASK_NAME "T_PER"
#define PERIODIC_STACK_SIZE 8192
MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("Timer module");
static rtdm_task_t tPeriodicTask;
RT_SEM sSchedSem;
static void SwTimerHandler(void* dummy)
{
printk(KERN_INFO "Starting %s\n", __FUNCTION__);
while (1)
{
if( rtdm_task_wait_period() == -ETIMEDOUT ) printk(KERN_WARNING "schedule overrun detected!\n");
rt_sem_v(&sSchedSem);
}
}
int init_module (void)
{
int ErrCode;
ErrCode = rt_sem_create(&sSchedSem, SEM_NAME, 0, S_FIFO);
if ( ErrCode != 0)
{
printk(KERN_ERR "Error creating main semaphore %d!\n",ErrCode);
}
if (rtdm_task_init(&tPeriodicTask, PERIODIC_TASK_NAME, &SwTimerHandler, NULL, PERIODIC_TASK_PRIO, TIMER_PERIOD_NSEC) == 0)
{
printk(KERN_INFO "Periodic Thread created!");
}
return 0;
}
void cleanup_module (void)
{
rtdm_task_destroy(&tPeriodicTask);
rt_sem_delete(&sSchedSem);
printk (KERN_INFO "Timer removed\n" );
}
next parent reply other threads:[~2011-01-24 16:39 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <22536578.91295887083468.JavaMail.SYSTEM@PC-MRINALDI>
2011-01-24 16:39 ` Michel Rinaldi [this message]
2011-01-24 16:44 ` [Xenomai-help] Problems with rt_task_create and rt_task_join Gilles Chanteperdrix
2011-01-24 16:54 ` Gilles Chanteperdrix
[not found] <8701358.01297411757328.JavaMail.SYSTEM@pc-msalvini>
2011-02-11 8:10 ` Mauro Salvini
2011-02-11 9:56 ` Gilles Chanteperdrix
[not found] <21381658.41297350790328.JavaMail.SYSTEM@pc-msalvini>
2011-02-10 15:20 ` Mauro Salvini
2011-02-10 16:14 ` Gilles Chanteperdrix
[not found] <29582899.21296203622078.JavaMail.SYSTEM@PC-MRINALDI>
2011-01-28 8:34 ` Michel Rinaldi
2011-01-28 17:43 ` Gilles Chanteperdrix
[not found] <11269195.111296118370328.JavaMail.SYSTEM@PC-MRINALDI>
2011-01-27 8:58 ` Michel Rinaldi
2011-01-27 13:36 ` Gilles Chanteperdrix
[not found] <20964580.81295961364859.JavaMail.SYSTEM@PC-MRINALDI>
2011-01-25 13:17 ` Michel Rinaldi
2011-01-25 13:26 ` Gilles Chanteperdrix
[not found] <24653571.21295878006500.JavaMail.SYSTEM@PC-MRINALDI>
2011-01-24 14:07 ` Michel Rinaldi
[not found] <14515395.201295629170328.JavaMail.SYSTEM@PC-MRINALDI>
2011-01-21 17:01 ` Michel Rinaldi
2011-01-21 17:11 ` Philippe Gerum
2011-01-22 14:26 ` Mauro
2011-01-22 19:14 ` Gilles Chanteperdrix
2011-01-24 14:05 ` Michel Rinaldi
2011-01-24 14:27 ` Gilles Chanteperdrix
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=23405065.111295887148359.JavaMail.SYSTEM@PC-MRINALDI \
--to=automation.03@domain.hid \
--cc=gilles.chanteperdrix@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.