All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@domain.hid>
To: Nicolas BLANCHARD <n.blanchard@domain.hid>
Cc: xenomai@xenomai.org
Subject: Re: Rép. : Re: [Xenomai-help] Switch mode with x86
Date: Tue, 28 Nov 2006 21:27:40 +0100	[thread overview]
Message-ID: <456C9BBC.9050003@domain.hid> (raw)
In-Reply-To: <s56c97a4.096@domain.hid>

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

Nicolas BLANCHARD wrote:
>>>>> Jan Kiszka <jan.kiszka@domain.hid> 28/11/06 19:02 >>>
>> Nicolas BLANCHARD wrote:
>>> Hi ! 
>>>
>>> I'm newbie in xenomai world,
>>> I've write an application which make a lot of switch mode
>>> (Primary->secondary ...)
>>> and sometime tasks are block in secondary mode (/proc/xenomai/sched
> ->
>>> stat X).
>>> (no watchod message in dmesg, it's block in secondary mode).
>>>
>>> I use xenomai 2.2.5, adeos 1.5.02 (same probleme with 2.2.3 et adeos
>>> 1.4)
>>> It' run on x86 (486 vortex 166Mhz).
>>> So, i've write an litle example that failed.  It failed on my x86 (in
>>> less than 2 minutes),
>>> but this example run corectly with a pentium 4 or an Amd processor :
>> How does it fail precisely? Which tasks are stuck? Attach
>> /proc/xenomai/sched output e.g. Already tried to attach gdb to that
>> process after the lock-up?
> 
> I've no "crash", Tasks are blocked :
> 
> /proc/xenomai/stat -> state of TASK_1 (Hight priority) : X
>                    -> state of TASK_2 (Low priority) : R or sometime X
> /proc/xenomai/sched -> period of TASK_1 always 0, CPU 0%
>                     -> period of TASK_2 always 0, CPU 0%
> 
> In my original program, all others tasks which don't switch to secondary
> mode
> are still alive and runs correctly ...
> 
> I've tested gdb, nothing special, it's like if it was normal,
> But block tasks seems to be in a infinite sleep under secondary mode.

I was targeting with gdb on the question "blocked on what?"

> 
>>
>> One difference of vortex vs. P4 might be (besides speed) that for the
>> former Xenomai uses TSC emulation, for the latter the CPU already comes
>> with this support. You can force the high-end systems into that mode by
>> compiling the kernel with CONFIG_M586. Or did you use the same kernel
>> images on all systems?
>>
> 
> No, kernel are not similar(both xenomai 2.2.5 + adeos 1.5-02 + linux
> 2.6.17.13),
>    ->Pentium 4 under windowsXP with Vmware worstation vm ubuntu,
> different kernel config
>      for run with Vmware, it's run fine.
>      In xenomai options there is nothing different.
> 
> I will try CONFIG_M586 (actually 486)

Given the information below, I suspect now it is a race that is more
likely on slow boxes. Anyway, it's worth a test.

> 
>> Your .config would be interesting. You can already check if
>> CONFIG_INPUT_PCSPKR is set. Must be off for TSC emulation (Xenomai 2.2
>> doesn't check for this conflict, 2.3 will do so).
> 
> Ok
> (With Xenomai configure script i've passed options : disable-x86-tsc and
> disable-x86-sep)
> 
>>> #include <sys/mman.h>
>>> #include <stdio.h>
>>> #include <signal.h>
>>> #include <native/task.h>
>>> #include <string.h>
>>>
>>> static int iStop = 0;
>>> RT_TASK Task_1, Task_2;
>>>
> //----------------------------------------------------------------------THREAD
>>> 1
>>> void thread_1(void *arg)
>>> {
>>> 	while(1)
>>> 	{
>>> 		unsigned long overruns;
>>> 		int iErr;
>>>
>>> 		iErr = rt_task_wait_period(&overruns);
>>> 		if (iErr || overruns)
>>> 			printf("Echec wait_period task_1 err %d,
>>> overruns: %lu\n",iErr,overruns);
>>
>> Would have been better to attach the program instead of inlining it. :)
>>
>>> 		//iErr = rt_task_set_mode(T_PRIMARY, 0, NULL);
>>> 		if(iErr)
>>> 			printf("Echec set_mod Secondary task_1\n");
>>> printf("r\n");
>>> 		if(iStop == 1)
>>> 		{
>>> 			iErr = rt_task_delete(&Task_1);
>>> 			if (iErr ) 
>>> 				printf("Echec delete task_1 err %d\n",
>>> iErr);
>>> 			break;
>>> 		}
>>> 	}
>> There is no mode switch in this thread and the second one. Is this not
>> required to cause the lock-up???
>>
>> ...
> 
> There is a switch with printf, if you comment this line and uncomment
> rt_task_set_mode line the probleme is the same.

Ah, uum, just found my glasses.

So there must be two tasks in secondary mode, and they must run at
different prio levels? Then I have two more things to try:

 - CONFIG_XENO_OPT_RPIDISABLE (Nucleus feature to disable prio boosting
   in secondary mode)

 - Xenomai 2.3-rc2 (to check if some recent change improves the
   situation)

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

       reply	other threads:[~2006-11-28 20:27 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <s56c97a4.096@domain.hid>
2006-11-28 20:27 ` Jan Kiszka [this message]
     [not found] <s575af89.064@domain.hid>
2006-12-05 17:15 ` Rép. : Re: [Xenomai-help] Switch mode with x86 Jan Kiszka
2006-12-05 12:33 Nicolas BLANCHARD
     [not found] <s56d88c0.000@domain.hid>
2006-11-29 13:52 ` Jan Kiszka
  -- strict thread matches above, loose matches on Subject: below --
2006-11-29 12:19 Nicolas BLANCHARD
2006-12-03 19:32 ` Jan Kiszka
2006-12-03 19:59   ` Philippe Gerum
2006-12-03 20:10     ` Jan Kiszka
2006-12-03 21:09     ` Jan Kiszka
2006-12-03 23:30       ` Philippe Gerum
2006-12-04  8:13         ` Jan Kiszka
2006-12-04 21:06           ` Jan Kiszka
2006-12-05 22:17             ` Philippe Gerum
2006-12-06  8:37               ` Jan Kiszka
2006-12-06  9:06                 ` Philippe Gerum
2006-12-05 22:18             ` Philippe Gerum
2006-12-04  9:46       ` Gilles Chanteperdrix
2006-12-03 21:02   ` Philippe Gerum
2006-11-29 10:25 Nicolas BLANCHARD
2006-11-28 19:09 Nicolas BLANCHARD

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=456C9BBC.9050003@domain.hid \
    --to=jan.kiszka@domain.hid \
    --cc=n.blanchard@domain.hid \
    --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.