[Xenomai-help] my tick takes a break !!

[Xenomai-help] my tick takes a break !!

[Thomas, Brieuc (GE Healthcare)]

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

Hi every one !

I really don't understand, my porting of application works very well
(under vxworks skin), message, semaphore, timer... Except the task !!
I've got a curious behaviour, when I've got a heavy task, the kernel
tick counter stop during the process!!

And take back when this one is finish.

Therefore the other tasks are freeze and my application crash.

 

have You already seen this case?

 

Ps: I use xenomai-2.1.0 & kernel2.6.14-6


[-- Attachment #2: Type: text/html, Size: 2932 bytes --]

Re: [Xenomai-help] my tick takes a break !!

[Gilles Chanteperdrix]

Thomas, Brieuc \(GE Healthcare\) wrote:
 > Hi every one !
 > 
 > I really don't understand, my porting of application works very well
 > (under vxworks skin), message, semaphore, timer... Except the task !!
 > I've got a curious behaviour, when I've got a heavy task, the kernel
 > tick counter stop during the process!!
 > 
 > And take back when this one is finish.
 > 
 > Therefore the other tasks are freeze and my application crash.
 > 
 >  
 > 
 > have You already seen this case?

I do not know if it is what you mean, but when running Xenomai, your
tasks are supposed to suspend sufficiently frequently to leave Linux
tick normally. This means that if you configured CONFIG_HZ=100, your
real-time activity (including kernel-space tasks and user-space tasks in
primary mode) is supposed to take a break at least once every 1/100
second.

-- 


					    Gilles Chanteperdrix.

RE: [Xenomai-help] my tick takes a break !!

[Thomas, Brieuc (GE Healthcare)]

 
Thomas, Brieuc \(GE Healthcare\) wrote:
 > Hi every one !
 >
 > I really don't understand, my porting of application works very well
> (under vxworks skin), message, semaphore, timer... Except the task !!
 > I've got a curious behaviour, when I've got a heavy task, the kernel
> tick counter stop during the process!!
 >
 > And take back when this one is finish.
 >
 > Therefore the other tasks are freeze and my application crash.
 >
 >
 >
 > have You already seen this case?

I do not know if it is what you mean, but when running Xenomai, your
tasks are supposed to suspend sufficiently frequently to leave Linux
tick normally. This means that if you configured CONFIG_HZ=100, your
real-time activity (including kernel-space tasks and user-space tasks in
primary mode) is supposed to take a break at least once every 1/100
second.

-- 


					    Gilles Chanteperdrix.

Oh no! Sorry, I mean the real-time tick counter!
But if my real-time activity don't take a break during a while (more
than 1/100 second), Is it dangerous for my real-time activity? 

Brieuc THOMAS.

RE: [Xenomai-help] my tick takes a break !!

[Gilles Chanteperdrix]

Thomas, Brieuc \(GE Healthcare\) wrote:
 >  
 > Thomas, Brieuc \(GE Healthcare\) wrote:
 >  > Hi every one !
 >  >
 >  > I really don't understand, my porting of application works very well
 > > (under vxworks skin), message, semaphore, timer... Except the task !!
 >  > I've got a curious behaviour, when I've got a heavy task, the kernel
 > > tick counter stop during the process!!
 >  >
 >  > And take back when this one is finish.
 >  >
 >  > Therefore the other tasks are freeze and my application crash.
 >  >
 >  >
 >  >
 >  > have You already seen this case?
 > 
 > I do not know if it is what you mean, but when running Xenomai, your
 > tasks are supposed to suspend sufficiently frequently to leave Linux
 > tick normally. This means that if you configured CONFIG_HZ=100, your
 > real-time activity (including kernel-space tasks and user-space tasks in
 > primary mode) is supposed to take a break at least once every 1/100
 > second.
 > 
 > -- 
 > 
 > 
 > 					    Gilles Chanteperdrix.
 > 
 > Oh no! Sorry, I mean the real-time tick counter!

If the heavy task is using intLock() then yes, it will prevent the timer
from ticking. If you are observing something else, could you send to
this mailing list a minimal test case illustrating what you are
observing?

 > But if my real-time activity don't take a break during a while (more
 > than 1/100 second), Is it dangerous for my real-time activity? 

If you do not let Linux run often enough, it will crash, and this is
dangerous for your real-time activity. 
I do not know exactly how much is "often enough", and it probably
depends on many factors, but if you want Linux timed services to work
normally, you should let Linux timer tick regularly.

-- 


					    Gilles Chanteperdrix.

RE: [Xenomai-help] my tick takes a break !!

[Thomas, Brieuc (GE Healthcare)]

> > Thomas, Brieuc \(GE Healthcare\) wrote:
> >  > Hi every one !
> >  >
> >  > I really don't understand, my porting of application works very
well
> >  > (under vxworks skin), message, semaphore, timer... Except the
task !!
> >  > I've got a curious behaviour, when I've got a heavy task, the
kernel
> >  > tick counter stop during the process!!
> >  >
> >  > And take back when this one is finish.
> >  >
> >  > Therefore the other tasks are freeze and my application crash.
> >  >
> >  >
> >  >
> >  > have You already seen this case?
> >
> > I do not know if it is what you mean, but when running Xenomai, your
>> tasks are supposed to suspend sufficiently frequently to leave Linux
> > tick normally. This means that if you configured CONFIG_HZ=100, your
> > real-time activity (including kernel-space tasks and user-space
tasks in > > primary mode) is supposed to take a break at least once
every 1/100 > > second.
> >
> > --
> >
> > 
> > 					    Gilles Chanteperdrix.
> >
> > Oh no! Sorry, I mean the real-time tick counter!
>
>If the heavy task is using intLock() then yes, it will prevent the
timer from ticking. If >you are observing something else, could you send
to this mailing list a minimal test case >illustrating what you are
observing?
>
> > But if my real-time activity don't take a break during a while (more
> than 1/100 >second), Is it dangerous for my real-time activity? 
>
>If you do not let Linux run often enough, it will crash, and this is
dangerous for your >real-time activity. 
>I do not know exactly how much is "often enough", and it probably
depends on many >factors, but if you want Linux timed services to work
normally, you should let Linux timer >tick regularly.
>-- 
>
>					    Gilles Chanteperdrix.
>

No I don't use intLock().
I use this test to observe the tasks behaviour, with two same priority
tasks.
The first task "testRun1" print the tick number, the number of the task
changed and if it's the same task (between my task) since last
timeslice.
The second one is the heavy task, it's print the tick number, the number
of the task changed and if it's the same task (between my task) since
last timeslice. And also some information about the progression task
(here the number of the loop with the tick number).

void testRun1()
{	printf("Start testRun1 %d taskChanged %d\n", (int)tickGet(),
taskChanged);
	const unsigned int taskId = 1;
	unsigned int startTime1 = tickGet();

	while(1)
	{	taskDelay(100);
		
		if(taskRunning != taskId)
		{
			taskRunning = taskId;
			taskChanged++;
			printf("Run testRun1 %d taskChanged %d\n",
(int)tickGet(), taskChanged);
		}
		else printf("Run testRun1 %d No changed\n",
(int)tickGet());
	}
	printf("End testRun1 %d taskChanged %d\n", (int)tickGet(),
taskChanged);
}

void testRun2()
{	printf("Start testRun2 %d taskChanged %d\n", (int)tickGet(),
taskChanged);
	const unsigned int taskId = 2;
	unsigned int startTime1 = tickGet();
	taskDelay(100);

	while( //ten times for example )
	{	
		printf("Start while tick: %d \n",(int)tickGet());
		while(//var)	// take around one second
		{	// workout
			if(taskRunning != taskId)
			{
				taskRunning = taskId;
				taskChanged++;
				printf("Run testRun2 %d taskChanged
%d\n", (int)tickGet(), taskChanged);
			}
		}
	}
	printf("End testRun2 %d taskChanged %d\n", (int)tickGet(),
taskChanged); 
}
***
The result see below:
***
Start testRun1 0 taskChanged 0    <--
Start testRun2 0 taskChanged 0      |
Run testRun1 100 taskChanged 1      |
Start while 1 tick: 100 NO changed  |- Changing OK, every 100ms
Run testRun2 100 taskChanged 2      |
Run testRun1 200 taskChanged 3      |
Run testRun2 200 taskChanged 4    <--  
Start while 2 tick: 200     <--
Start while 3 tick: 200       |
Start while 4 tick: 200       |
Start while 5 tick: 200       |- ticks break, while 10 second 
Start while 6 tick: 200       | 
Start while 7 tick: 200       | 
Start while 8 tick: 200       |
Start while 9 tick: 200     <--       |
End testRun2 200 taskChanged 4
Run testRun1 300 taskChanged 5
End testRun2 30010 taskChanged 5

RE: [Xenomai-help] my tick takes a break !!

[Gilles Chanteperdrix]

[-- Attachment #1: message body and .signature --]
[-- Type: text/plain, Size: 166 bytes --]

Thomas, Brieuc \(GE Healthcare\) wrote:
 > Oh no! Sorry, I mean the real-time tick counter!

Could you try the attached patch ?

-- 


					    Gilles Chanteperdrix.

[-- Attachment #2: uvm-prio.diff --]
[-- Type: text/plain, Size: 562 bytes --]

--- include/asm-uvm/system.h~	2006-04-05 15:08:08.000000000 +0200
+++ include/asm-uvm/system.h	2006-04-21 15:54:24.000000000 +0200
@@ -594,7 +594,7 @@ static void *xnarch_thread_trampoline (v
 	{
 	pthread_setcanceltype(PTHREAD_CANCEL_ASYNCHRONOUS, NULL);
 	param.sched_priority = sched_get_priority_min(SCHED_FIFO) + 1;
-	sched_setscheduler(0,SCHED_FIFO,&param);
+        pthread_setschedparam(pthread_self(), SCHED_FIFO, &param);
 	uvm_thread_create(tcb->name,tcb,&tcb->completion,&tcb->khandle);
 	err = uvm_thread_barrier();	/* Wait for start. */
 	if (err)

RE: [Xenomai-help] my tick takes a break !!

[Thomas, Brieuc (GE Healthcare)]

I tried it, but there isn't any change !
I've got the same behaviour.

Brieuc.

-----Message d'origine-----
De : Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org
Envoyé : vendredi 21 avril 2006 15:57
À : Thomas, Brieuc (GE Healthcare)
Cc : xenomai@xenomai.org
Objet : RE: [Xenomai-help] my tick takes a break !! 

Thomas, Brieuc \(GE Healthcare\) wrote:
 > Oh no! Sorry, I mean the real-time tick counter!

Could you try the attached patch ?

-- 


					    Gilles Chanteperdrix.

RE: [Xenomai-help] my tick takes a break !!

[Gilles Chanteperdrix]

Thomas, Brieuc \(GE Healthcare\) wrote:
 > I tried it, but there isn't any change !
 > I've got the same behaviour.

I could reproduce your bug here. The uvm-timer thread is blocked in W
state, just as if the interrupts were locked.

-- 


					    Gilles Chanteperdrix.

RE: [Xenomai-help] my tick takes a break !!

[Thomas, Brieuc (GE Healthcare)]

 > -----Message d'origine-----
 > De : Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org
 > Envoyé : dimanche 23 avril 2006 14:54
 > À : Thomas, Brieuc (GE Healthcare)
 > Cc : xenomai@xenomai.org
 > Objet : RE: [Xenomai-help] my tick takes a break !! 
 > 
 > Thomas, Brieuc \(GE Healthcare\) wrote:
 >  > I tried it, but there isn't any change !
 >  > I've got the same behaviour.
 > 
 > I could reproduce your bug here. The uvm-timer thread is blocked in W state, just as if the interrupts were locked.
 > 
 > -- 
 > 
 > 
 > 					    Gilles Chanteperdrix.
 > 

Yes but, I've allowed the interrupts from the compile, and I never used intLock() or something like that!
By the way, I made some test: and if I add a taskLock() before the heavy while() and a taskUnlock() just after this while, my tick number is updated. But the task behaviour is the same; the task doesn't give the priority to the other task.
The second test is: I've added a takdelay() before the heavy while(). The tick counter work's, the task behaviour is fine, but evidently the workout takes a long time!  

In fact, I think than I never seen working the schedule without delay() (like taskdelay() or msqReceive(WAIT)...)  I've got probably a bad configuration somewhere!
Then I tried the trunk version, and I've got an error message during the launch, either:    

When I compile a periodic timer mode:
Xenomai: UVM skin init failed, code -16
Xenomai: starting Vxworks services
Or, in aperiodic mode:
Xenomai: starting UVM services
Xenomai: incompatible timer mode(aperiodic found, need periodic).
Xenomai: Vxworks skin init failed, code -16

Perhaps my first problem, come from to the timer mode? Normally my configuration is status=oneshot:setup=202:tickval=1... 

Any idea?
 
	Brieuc THOMAS.

RE: [Xenomai-help] my tick takes a break !!

[Gilles Chanteperdrix]

Thomas, Brieuc \(GE Healthcare\) wrote:
 > 
 >  > -----Message d'origine-----
 >  > De : Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org] 
 >  > Envoyé : dimanche 23 avril 2006 14:54
 >  > À : Thomas, Brieuc (GE Healthcare)
 >  > Cc : xenomai@xenomai.org
 >  > Objet : RE: [Xenomai-help] my tick takes a break !! 
 >  > 
 >  > Thomas, Brieuc \(GE Healthcare\) wrote:
 >  >  > I tried it, but there isn't any change !
 >  >  > I've got the same behaviour.
 >  > 
 >  > I could reproduce your bug here. The uvm-timer thread is blocked in W state, just as if the interrupts were locked.
 > 
 > Yes but, I've allowed the interrupts from the compile, and I never used intLock() or something like that!

Neither your code, nor your setup is wrong, the error come from vxworks
uvm. Printing uvm_irqlock shows that the interrupts got disabled
somehow.

 > Then I tried the trunk version, and I've got an error message during the launch, either:    
 > 
 > When I compile a periodic timer mode:
 > Xenomai: UVM skin init failed, code -16
 > Xenomai: starting Vxworks services
 > Or, in aperiodic mode:
 > Xenomai: starting UVM services
 > Xenomai: incompatible timer mode(aperiodic found, need periodic).
 > Xenomai: Vxworks skin init failed, code -16
 > 
 > Perhaps my first problem, come from to the timer mode? Normally my configuration is status=oneshot:setup=202:tickval=1... 

UVM and vxworks are separated skins, that require incompatible timer
setting. Since you are using UVM (I guess), select only uvm in kernel
configuration, or select vxworks skin as a module that you do not load
when running applications using the UVM skin.

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-help] my tick takes a break !!

[Philippe Gerum]

Gilles Chanteperdrix wrote:
> Thomas, Brieuc \(GE Healthcare\) wrote:
>  > 
>  >  > -----Message d'origine-----
>  >  > De : Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.orgt] 
>  >  > Envoyé : dimanche 23 avril 2006 14:54
>  >  > À : Thomas, Brieuc (GE Healthcare)
>  >  > Cc : xenomai@xenomai.org
>  >  > Objet : RE: [Xenomai-help] my tick takes a break !! 
>  >  > 
>  >  > Thomas, Brieuc \(GE Healthcare\) wrote:
>  >  >  > I tried it, but there isn't any change !
>  >  >  > I've got the same behaviour.
>  >  > 
>  >  > I could reproduce your bug here. The uvm-timer thread is blocked in W state, just as if the interrupts were locked.
>  > 
>  > Yes but, I've allowed the interrupts from the compile, and I never used intLock() or something like that!
> 
> Neither your code, nor your setup is wrong, the error come from vxworks
> uvm. Printing uvm_irqlock shows that the interrupts got disabled
> somehow.
> 
>  > Then I tried the trunk version, and I've got an error message during the launch, either:    
>  > 
>  > When I compile a periodic timer mode:
>  > Xenomai: UVM skin init failed, code -16
>  > Xenomai: starting Vxworks services
>  > Or, in aperiodic mode:
>  > Xenomai: starting UVM services
>  > Xenomai: incompatible timer mode(aperiodic found, need periodic).
>  > Xenomai: Vxworks skin init failed, code -16
>  > 
>  > Perhaps my first problem, come from to the timer mode? Normally my configuration is status=oneshot:setup=202:tickval=1... 
> 
> UVM and vxworks are separated skins, that require incompatible timer
> setting. Since you are using UVM (I guess), select only uvm in kernel
> configuration, or select vxworks skin as a module that you do not load
> when running applications using the UVM skin.
> 

If you feel lucky, the 3rd option coming with v2.2 is to get rid of the 
UVM and use the new direct call interface now available from user-space 
for the VxWorks skin. In such a case, you need 1) the development 
trunk/, 2) to load xeno_vxworks, 3) work with the new VxWorks interface 
from user-space exactely the way one would use the existing native or 
POSIX skin.

-- 

Philippe.

Re: [Xenomai-help] my tick takes a break !!

[Gilles Chanteperdrix]

Philippe Gerum wrote:
 > If you feel lucky, the 3rd option coming with v2.2 is to get rid of the 
 > UVM and use the new direct call interface now available from user-space 
 > for the VxWorks skin. In such a case, you need 1) the development 
 > trunk/, 2) to load xeno_vxworks, 3) work with the new VxWorks interface 
 > from user-space exactely the way one would use the existing native or 
 > POSIX skin.

But round-robin scheduling will not work for threads in secondary mode,
whereas it works with UVM.

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-help] my tick takes a break !!

[Philippe Gerum]

Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
>  > If you feel lucky, the 3rd option coming with v2.2 is to get rid of the 
>  > UVM and use the new direct call interface now available from user-space 
>  > for the VxWorks skin. In such a case, you need 1) the development 
>  > trunk/, 2) to load xeno_vxworks, 3) work with the new VxWorks interface 
>  > from user-space exactely the way one would use the existing native or 
>  > POSIX skin.
> 
> But round-robin scheduling will not work for threads in secondary mode,
> whereas it works with UVM.
> 

Sorry, I don't get the point. If it works in secondary mode under the 
UVM, it will work outside the UVM too, since we have shadow threads 
scheduled by Linux, in any case.

-- 

Philippe.

Re: [Xenomai-help] my tick takes a break !!

[Gilles Chanteperdrix]

Philippe Gerum wrote:
 > Gilles Chanteperdrix wrote:
 > > Philippe Gerum wrote:
 > >  > If you feel lucky, the 3rd option coming with v2.2 is to get rid of the 
 > >  > UVM and use the new direct call interface now available from user-space 
 > >  > for the VxWorks skin. In such a case, you need 1) the development 
 > >  > trunk/, 2) to load xeno_vxworks, 3) work with the new VxWorks interface 
 > >  > from user-space exactely the way one would use the existing native or 
 > >  > POSIX skin.
 > > 
 > > But round-robin scheduling will not work for threads in secondary mode,
 > > whereas it works with UVM.
 > > 
 > 
 > Sorry, I don't get the point. If it works in secondary mode under the 
 > UVM, it will work outside the UVM too, since we have shadow threads 
 > scheduled by Linux, in any case.

A thread in secondary mode in Xenomai kernel-space nucleus, is seen as
the root thread, which never has the XNRRB bit set.

The UVM nucleus, on the other hand, has no notion of primary or
secondary mode, when a thread is running in secondary mode it still is
the current thread, so may have the XNRRB bit set.

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-help] my tick takes a break !!

[Philippe Gerum]

Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
>  > Gilles Chanteperdrix wrote:
>  > > Philippe Gerum wrote:
>  > >  > If you feel lucky, the 3rd option coming with v2.2 is to get rid of the 
>  > >  > UVM and use the new direct call interface now available from user-space 
>  > >  > for the VxWorks skin. In such a case, you need 1) the development 
>  > >  > trunk/, 2) to load xeno_vxworks, 3) work with the new VxWorks interface 
>  > >  > from user-space exactely the way one would use the existing native or 
>  > >  > POSIX skin.
>  > > 
>  > > But round-robin scheduling will not work for threads in secondary mode,
>  > > whereas it works with UVM.
>  > > 
>  > 
>  > Sorry, I don't get the point. If it works in secondary mode under the 
>  > UVM, it will work outside the UVM too, since we have shadow threads 
>  > scheduled by Linux, in any case.
> 
> A thread in secondary mode in Xenomai kernel-space nucleus, is seen as
> the root thread, which never has the XNRRB bit set.
> 
> The UVM nucleus, on the other hand, has no notion of primary or
> secondary mode, when a thread is running in secondary mode it still is
> the current thread, so may have the XNRRB bit set.
> 

Indeed, but as a user, you must _not_ rely on this internal knowledge of 
such "UVM over shadow mapping", never, ever. The UVM must been seen as 
having the very same semantics than direct call interfaces, except that 
almost every nucleus action is occuring/confined within a single process 
context when possible, hence the virtual machine thingy. The fact you 
describe is a hidden side-effect which must never be taken for granted, 
otherwise, transitioning from the UVM to direct call interfaces is going 
to be extremely painful...

-- 

Philippe.