[Xenomai-core] Questions about pSOS task mode and task priority
Hello, I work together with Thomas Necker on a legacy pSOS project to get it ported to Xenomai. I have already ported a great amount of code and most of it works fine. But we have a pSOS task which (sometimes) works in non-preemptive mode (T_NOPREEMPT). When this task calls ev_receive() it gets back the error code -EPERM from underlying xnpod_unblockable_p(). It seems to be not allowed in Xenomai to call a blockable syscall in non-preemptive mode. With original pSOS this was allowed and "non-preemptive" meant that a runnable task cannot be preempted by other tasks but can block itself. Why is this different in Xenomai and is it possible to implement the same behaviour in Xenomai core? Another problem is that we have a root task creating and starting some other tasks. The new tasks are mostly created with prio 80 and the root task wants to run the new tasks until their first blocking syscall. Therefore the root task lowers its priority to one less the priority of the new task, i.e. 79. Then the root task raise its prio back to 240. Immediately after lowering its prio, the root task should be preempted and the new task should run. But this doesn't happen. Why not? Thank you. Regards Markus ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Antwort: Re: Antwort: Re: [Xenomai-core] Questions about pSOS task mode and task priority
Hi Philippe,
see below a code snippet for demonstration of the task priority problem.
The expected behaviour is that the new task is running immediately after
lowering root's priority.
The log of the reached statements should therefor be: 1, 10, 2, 3, 4, 5
But instead the log is: 1, 2, 3, 4, 10, 5, i.e. the new task is running
only after blocking root task.
About your question regarding the preemtible bit:
The task should always be non-preemtible, also after it is unblocked.
Thank you
Regards
Markus
u_long log_array[10];
u_long log_idx=0;
void task1 (void)
{
for(;;)
{
log_array[log_idx++] = 10; /* we reached this statement, log it */
/* do some stuff which could block, for demo do a tm_wkafter */
tm_wkafter(200);
}
}
void root(void)
{
u_long dummy, tid, i;
/* set root's prio to a very high value */
t_setpri(0, 240, &dummy);
/* confirm that root is preemptible */
t_mode(T_NOPREEMPT, T_PREEMPT, &dummy);
/* create/start all tasks, for demo only one task */
for (i=0; i<1; i++)
{
/* create a new task with prio 80 */
t_create("TSK1", 80, 0x1000, 0, T_LOCAL|T_NOFPU, &tid);
/* start the new task as preemptible */
t_start(tid, T_PREEMPT|T_NOTSLICE|T_SUPV|T_NOASR, (void(*)(u_long,
u_long, u_long, u_long))task1, NULL);
log_array[log_idx++] = 1; /* we reached this statement, log it */
/* lower root's prio to one less than new task's prio */
t_setpri(0, 80-1, &dummy);
log_array[log_idx++] = 2; /* we reached this statement, log it */
/* set root's prio back to the high value */
t_setpri(0, 240, &dummy);
log_array[log_idx++] = 3; /* we reached this statement, log it */
}
/* after starting all tasks, set root's prio to the final value */
t_setpri(0, 220, &dummy);
log_array[log_idx++] = 4; /* we reached this statement, log it */
/* do some stuff which could block, for demo do a tm_wkafter */
tm_wkafter(100);
log_array[log_idx++] = 5; /* we reached this statement, log it */
/* print the log */
for (i=0; i<6; i++)
{
printf("%d ", log_array[i]);
}
printf("\n");
exit(0);
}
On Mon, 2007-01-29 at 14:25 +0100, Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
> > On Fri, 2007-01-26 at 18:16 +0100, Thomas Necker wrote:
> >
> >>Hi Philippe
> >>
> >>
> non-preemptive mode.
> With original pSOS this was allowed and "non-preemptive" meant that a
> runnable task cannot be preempted by other tasks but can block
itself.
> Why is this different in Xenomai and is it possible to implement the
> >>
> >>same
> >>
> behaviour in Xenomai core?
>
> >>>
> >>>Xenomai implements the non-preemptible mode as most RTOSes implement
> >>>scheduling locks. From this POV, allowing a non-preemptible task to
> >>>block makes no sense, and doing so usually either locks up the board,
or
> >>>causes an API error.
> >>>
> >>>It could be possible to switch the preemption bit on before entering a
> >>>blocking state only for pSOS tasks, then reinstate it when the task
> >>>wakes up, though. However, before going down that path, is there any
> >>>pSOS documentation that clearly states that such behaviour is to be
> >>>expected (i.e. that blocking calls _may_ be called in non-preemptible
> >>>mode)?
> >>>
> >>>Or did you benefit from an undocumented and fortunate side-effect of
the
> >>>pSOS implementation when relying on such behaviour?
> >>
> >>Since Markus has already left, I had a quick look in the pSOS System
> >>Concepts Manual:
> >>
> >>Each task has a mode word, with two settable bits that can affect
> >>scheduling.
> >>One bit controls the task's preemptibility. If disabled, then once
the
> >>task
> >>enters the running state, it will stay running even if other tasks
> >>of higher priority enter the ready state. A task switch will occur
> >>only if
> >>the running task blocks, or if it re-enables preemption.
> >>
> >>So it clearly states that a non-preemtible task may block (and
> >>rescheduling occurs in
> >>this case).
> >
> >
> > Ok, so this is a must fix. Will do. Thanks for reporting.
>
> I had a look at the OSEK specification, it also has non-preemptible
> tasks. So, I guess we should add an xnpod_locked_schedule that simply
does
>
> if (xnthread_test_state(xnpod_current_sched()->runthread, XNLOCK)) {
>xnpod_unlock_sched();
>xnpod_lock_sched();
> } else
>xnpod_schedule();
>
> and call this xnpod_locked_schedule() instead of xnpod_schedule() in
> these skins.
Ack, would do. Thomas, could you confirm that the preemptible bit is
raised again for the task when it is scheduled back in?
>
>
>
>
--
Philippe.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
___
Xenomai-core mailing list
Xe
[Xenomai-core] Found bug in pSOS ev_receive()
Hello, in pSOS skin function ev_receive() in file event.c I've found a bug. When ev_receive() is called with EV_WAIT and an event is received, the task is unblocked and everything is okay, then in this case the copy of the actual received events into *events_r is missing. Regards Markus ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Antwort: Re: [Xenomai-core] Found bug in pSOS ev_receive()
In timeout case events_r is don't care.
When using pSOS skin in user space, __ev_receive() in syscall.c copy
events_r to user space only when ev_receive was successful.
But this comply with pSOS manual: "If successful, ev_receive() returns the
actual events captured by the call in the
location pointed to by events_r."
Philippe Gerum
<[EMAIL PROTECTED] An: Markus
Osterried <[EMAIL PROTECTED]>
g> Kopie:
xenomai-core@gna.org
Gesendet von: Blindkopie:
Philippe Gerum Thema: Re:
[Xenomai-core] Found bug in pSOS ev_receive()
07.02.2007
12:15
Bitte antworten
an rpm
On Wed, 2007-02-07 at 11:57 +0100, Philippe Gerum wrote:
> On Wed, 2007-02-07 at 11:36 +0100, Markus Osterried wrote:
> > Hello,
> >
> > in pSOS skin function ev_receive() in file event.c I've found a bug.
> > When ev_receive() is called with EV_WAIT and an event is received, the
> > task is unblocked and everything is okay, then in this case the copy of
the
> > actual received events into *events_r is missing.
>
> Confirmed and fixed, thanks.
>
> --- ksrc/skins/psos+/event.c (revision 2108)
> +++ ksrc/skins/psos+/event.c (working copy)
> @@ -79,9 +79,10 @@
>
>if (xnthread_test_info(&task->threadbase, XNBREAK))
>err = -EINTR;
> - else if (xnthread_test_info(&task->threadbase, XNTIMEO)) {
> + else {
>*events_r = task->waitargs.evgroup.events;
> - err = ERR_TIMEOUT;
> + if (xnthread_test_info(&task->threadbase,
XNTIMEO))
> + err = ERR_TIMEOUT;
>}
>
>unlock_and_exit:
>
Actually, there was a second bug hiding in the timeout case, where the
copy back value was wrong, we should have returned the current state of
the event flag group and we returned the pended event mask instead. The
following patch against 2.3.0 fixes both issues.
--- ksrc/skins/psos+/event.c (revision 2134)
+++ ksrc/skins/psos+/event.c (working copy)
@@ -80,9 +80,10 @@
if (xnthread_test_info(&task->threadbase, XNBREAK))
err = -EINTR;
else if (xnthread_test_info(&task->threadbase, XNTIMEO)) {
+err = ERR_TIMEOUT;
+*events_r = evgroup->events;
+} else
*events_r = task->waitargs.evgroup.events;
-err = ERR_TIMEOUT;
-}
unlock_and_exit:
--
Philippe.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] supervisor/user stack size for pSOS tasks
Hello Philippe, when using t_create() for creating a pSOS task in user space, the parameter sstack is ignored. But when creating the task in kernel space, sstack is added to ustack to create a stack of the combined sizes. The same behaviour as in kernel space should be implemented in user space. Because this is the behaviour of original pSOS for CPU architectures where supervisor and user stacks are not separated, like PowerPC. Thanks Markus ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Arguments in psos t_start()
Hello Phillipe, in __t_start() in /ksrc/skins/psos+/syscall.c the pointer to the (user-space) tasks argument is directly used for the (kernel-space) t_start() call. u_long *argp; argp = (u_long *)__xn_reg_arg4(regs); return t_start((u_long)task, mode, startaddr, argp); I think the arguments must be copied to kernel-space, so isn't it better to do it this way? u_long arg[4]; if (!__xn_access_ok (curr, VERIFY_READ, __xn_reg_arg4(regs), sizeof(u_long[4]))) return -EFAULT; __xn_copy_from_user(curr, arg, (void __user *)__xn_reg_arg4(regs), sizeof(u_long[4])); return t_start((u_long)task, mode, startaddr, arg); Thank you. Markus ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Antwort: Re: Arguments in psos t_start()
Hello Gerum,
sorry for not knowing the details. But there is another question.
Is it okay to move the pointer to the arguments to the newly created task?
Isn't it possible that the task which created the new task is rescheduled?
The old task could change the value of the argument and because the new
task only holds a reference to this argument, the new task is also
affected.
Thank you
Markus
Philippe Gerum
<[EMAIL PROTECTED] An: Markus
Osterried <[EMAIL PROTECTED]>
g> Kopie:
xenomai-core@gna.org
Gesendet von: Blindkopie:
xenomai-core-bo Thema: Re:
[Xenomai-core] Arguments in psos t_start()
[EMAIL PROTECTED]
08.05.2007
16:55
Bitte antworten
an rpm
On Tue, 2007-05-08 at 16:07 +0200, Markus Osterried wrote:
> Hello Phillipe,
>
> in __t_start() in /ksrc/skins/psos+/syscall.c the pointer to the
> (user-space) tasks argument is directly used for the (kernel-space)
> t_start() call.
>
> u_long *argp;
> argp = (u_long *)__xn_reg_arg4(regs);
> return t_start((u_long)task, mode, startaddr, argp);
>
>
> I think the arguments must be copied to kernel-space, so isn't it better
to
> do it this way?
>
> u_long arg[4];
> if (!__xn_access_ok
> (curr, VERIFY_READ, __xn_reg_arg4(regs), sizeof(u_long[4])))
> return -EFAULT;
> __xn_copy_from_user(curr, arg, (void __user *)__xn_reg_arg4(regs),
>sizeof(u_long[4]));
> return t_start((u_long)task, mode, startaddr, arg);
>
Actually, we currently don't need to know anything about the task args
from kernel space, since we only have to relay their address to the task
trampoline code in src/skins/psos/task.c. However, we must not try to
access those args from kernel space. The patch below fixes this bug.
Thanks for pointing this out.
--- ksrc/skins/psos+/task.c (revision 2395)
+++ ksrc/skins/psos+/task.c (working copy)
@@ -197,9 +197,6 @@
xnmode = psos_mode_to_xeno(mode);
-for (n = 0; n < 4; n++)
-task->args[n] = targs ? targs[n] : 0;
-
task->entry = startaddr;
#if defined(__KERNEL__) && defined(CONFIG_XENO_OPT_PERVASIVE)
@@ -214,10 +211,15 @@
XNPOD_ALL_CPUS, (void
(*)(void *))startaddr, targs);
else
#endif /* __KERNEL__ && CONFIG_XENO_OPT_PERVASIVE */
+{
+for (n = 0; n < 4; n++)
+task->args[n] = targs ? targs[n] : 0;
+
xnpod_start_thread(&task->threadbase,
xnmode,
(int)((mode >> 8) &
0x7),
XNPOD_ALL_CPUS,
&psostask_trampoline, task);
+}
unlock_and_exit:
--
Philippe.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Antwort: Re: Antwort: Re: Arguments in psos t_start()
Hello Gerum,
actually, when the task's user function (the function which is given in
t_start()) is entered, the arguments have been copied to the new context
and are passed by value.
This is true for real pSOS and also for Xenomai.
But in Xenomai it's the trampoline which acts as a wrapper/prolog and is
created and ready to run in a concurrent context, while still holding a
reference to the arguments in the creator's context.
Real pSOS is a blackbox, so I don't no whether there is a moment in time,
where a new concurrent context is running while still holding a pointer to
old context.
But it's the fact, we have sometimes seen problems with Xenomai, when our
pSOS application changes the arguments value after t_start().
We have never seen this in pSOS.
It's worth to mention, I haven't seen this problem with the newest Xenomai
branch (there was some changes in scheduling?).
But I'm not sure the problem is 100% solved, because with older Xenomai we
have sometimes seen the problem and sometimes not. :-(
Markus
Philippe Gerum
<[EMAIL PROTECTED] An: Markus
Osterried <[EMAIL PROTECTED]>
g> Kopie:
xenomai-core@gna.org
Gesendet von: Blindkopie:
xenomai-core-bo Thema: Re:
[Xenomai-core] Antwort: Re: Arguments in psos t_start()
[EMAIL PROTECTED]
09.05.2007
09:55
Bitte antworten
an rpm
On Wed, 2007-05-09 at 09:07 +0200, Markus Osterried wrote:
> Hello Gerum,
>
> sorry for not knowing the details. But there is another question.
> Is it okay to move the pointer to the arguments to the newly created
task?
> Isn't it possible that the task which created the new task is
rescheduled?
> The old task could change the value of the argument and because the new
> task only holds a reference to this argument, the new task is also
> affected.
>
Yes, such side-effect would be possible, not necessarily for the
creator, but for the thread calling t_start() though. The worst case
would happen when calling t_start() with args laid into the caller's
stack space, and the caller unwinding the current frame immediately
since it has a higher priority than the started thread.
This boils down to one question: does actually pSOS pass the argument
array by reference, or by value? In the latter case, the current
implementation would be wrong, otherwise, the side-effect would be
admitted.
--
Philippe.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] rtdm_iomap_to_user() with PowerPC
Hello, two months ago I reported a problem with rtdm_iomap_to_user(). Philippe acknowledged the problem and promised to submit a bug fix. Unfortunately, till now I don't have seen this bug fix, or have overlooked it? Can you please give me a hint about the roadmap? Thanks. Markus ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] rtdm_iomap_to_user() with PowerPC
Sorry for being intrusive. I've already done a quick and dirty bug fix, so final bug fix is not urgent. Just wanted to know about time schedule. Markus -Original Message- From: Jan Kiszka [mailto:[EMAIL PROTECTED] Sent: Mittwoch, 7. November 2007 15:46 To: Markus Osterried Cc: Philippe Gerum; Xenomai-core@gna.org Subject: Re: [Xenomai-core] rtdm_iomap_to_user() with PowerPC Markus Osterried wrote: > Hello, > > two months ago I reported a problem with rtdm_iomap_to_user(). > Philippe acknowledged the problem and promised to submit a bug fix. > Unfortunately, till now I don't have seen this bug fix, or have > overlooked it? Please post your bugs to our bugtracker on gna.org if you feel like it is getting/already got lost. Everyone is busy, and I'm afraid this particular issue remained unfixed unintentionally. > Can you please give me a hint about the roadmap? This is surely a must-fix for both 2.4 and the next 2.3 releases, we are only lacking the patch. Unless Philippe is able to come out with something over the next, say, two days, I would suggest to develop a fix along his original suggestions on your own. As far as I understood, we need an arch-specific wrapper for io-remapping in include/asm-powerps/wrappers.h and awareness for this specific solution in asm-generic/wrappers.h. Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Error when exiting pSOS-task with return
Hello, with Xenomai 2.4 on Linux 2.6.18 on PowerPC I have seen the following trace: Feb 26 19:37:25 (none) user.err kernel: BUG: sleeping function called from invalid context at kernel/rwsem.c:20 Feb 26 19:37:25 (none) user.warn kernel: in_atomic():0, irqs_disabled():1 Feb 26 19:37:25 (none) user.warn kernel: Call Trace: Feb 26 19:37:25 (none) user.warn kernel: [C19BFE50] [C000C114] show_stack+0x58/0x188 (unreliable) Feb 26 19:37:25 (none) user.warn kernel: [C19BFEA0] [C00128B0] __might_sleep+0xdc/0xf0 Feb 26 19:37:25 (none) user.warn kernel: [C19BFEC0] [C0032304] down_read+0x24/0x58 Feb 26 19:37:25 (none) user.warn kernel: [C19BFED0] [C00192C8] exit_mm+0x34/0xec Feb 26 19:37:25 (none) user.warn kernel: [C19BFEF0] [C001B000] do_exit+0x21c/0x98c Feb 26 19:37:25 (none) user.warn kernel: [C19BFF30] [C001B810] complete_and_exit+0x0/0x28 Feb 26 19:37:25 (none) user.warn kernel: [C19BFF40] [C00041A0] ret_from_syscall+0x0/0x38 This happens (sometimes) when a pSOS-task exits by returning from its main function. I have changed the return statement into t_delete(0) and there was no error anymore, so this isn't a major issue. But anyway I would like to know whether this is a xenomai bug or it isn't allowed to exit a pSOS-task by returning from main function. I have seen at end of psos_task_trampoline that there is a pthread_exit() instead of a t_delete(). Thanks Markus ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Error when exiting pSOS-task with return
Hello Philippe, sorry for the delay, I was on holiday a few days. > PS: you may want to check whether forcing the task to secondary mode before > calling t_delete(0) does not cause the issue to trigger again. When forcing the task to secondary mode before returning from main function, the issue is triggered. When forcing the task to primary mode before returning from main function, there is no error. When using t_delete(0) there is no error, regardless of primary or secondary mode. Markus -Original Message- From: Philippe Gerum [mailto:[EMAIL PROTECTED] On Behalf Of Philippe Gerum Sent: Samstag, 8. März 2008 18:20 To: Markus Osterried Cc: Xenomai-core@gna.org Subject: Re: [Xenomai-core] Error when exiting pSOS-task with return Markus Osterried wrote: > Hello, > > with Xenomai 2.4 on Linux 2.6.18 on PowerPC I have seen the following trace: > > Feb 26 19:37:25 (none) user.err kernel: BUG: sleeping function called > from invalid context at kernel/rwsem.c:20 Feb 26 19:37:25 (none) > user.warn kernel: in_atomic():0, irqs_disabled():1 Feb 26 19:37:25 > (none) user.warn kernel: Call Trace: > Feb 26 19:37:25 (none) user.warn kernel: [C19BFE50] [C000C114] > show_stack+0x58/0x188 (unreliable) > Feb 26 19:37:25 (none) user.warn kernel: [C19BFEA0] [C00128B0] > __might_sleep+0xdc/0xf0 Feb 26 19:37:25 (none) user.warn kernel: > [C19BFEC0] [C0032304] > down_read+0x24/0x58 > Feb 26 19:37:25 (none) user.warn kernel: [C19BFED0] [C00192C8] > exit_mm+0x34/0xec Feb 26 19:37:25 (none) user.warn kernel: [C19BFEF0] > [C001B000] do_exit+0x21c/0x98c Feb 26 19:37:25 (none) user.warn > kernel: [C19BFF30] [C001B810] > complete_and_exit+0x0/0x28 > Feb 26 19:37:25 (none) user.warn kernel: [C19BFF40] [C00041A0] > ret_from_syscall+0x0/0x38 > > > This happens (sometimes) when a pSOS-task exits by returning from its > main function. > I have changed the return statement into t_delete(0) and there was no > error anymore, so this isn't a major issue. > > But anyway I would like to know whether this is a xenomai bug or it > isn't allowed to exit a pSOS-task by returning from main function. > I have seen at end of psos_task_trampoline that there is a > pthread_exit() instead of a t_delete(). > It is allowed to exit the task body directly. Another possibility is a bug in old Adeos/ppc patch for 2.6.18, that would trigger when the nucleus has to relax the exiting thread. Anyway, this issue is queued for investigation here. Thanks. PS: you may want to check whether forcing the task to secondary mode before calling t_delete(0) does not cause the issue to trigger again. > Thanks > Markus > > > > -- > -- > > ___ > Xenomai-core mailing list > Xenomai-core@gna.org > https://mail.gna.org/listinfo/xenomai-core -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] bug with tm_evevery()
Hello,
there is a bug in the pSOS user-space skin, calling the wrong
kernel-space function for tm_evevery().
The file xenomai/src/skins/psos+/tm.c should be fixed like this:
--- xenomai-2.4/src/skins/psos+/tm.c
+++ xenomai-2.4/src/skins/psos+/tm.c
@@ -71,7 +71,7 @@
u_long tm_evevery(u_long ticks, u_long events, u_long *tmid_r)
{
- return XENOMAI_SKINCALL3(__psos_muxid, __psos_tm_evwhen, ticks,
events, tmid_r);
+ return XENOMAI_SKINCALL3(__psos_muxid, __psos_tm_evevery, ticks,
events, tmid_r);
}
u_long tm_getm(unsigned long long *ns_r) /* Xenomai extension. */
Thank you.
Markus
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] system hangs with "ifconfig eth0 down"
Hi,
I am using Xenomai with pSOS-skin.
The application and the whole system crashes when I call the following
statement from a pSOS-thread:
system("ifconfig eth0 down");
Any other call to system(), e.g. system("ls") works fine.
On the other hand, if I call "ifconfig eth0 down" from a shell outside
the Xenomai-application, it works also fine.
I have reduced the whole application to only one pSOS-thread which only
call system(), it crashes.
If I call system() in the main() function before creating/starting the
pSOS-thread, it works fine.
Anybody any idea why this call to system() doesn't work from inside the
application?
Thanks.
Markus
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] system hangs with "ifconfig eth0 down"
Hi,
thank you for the fast response.
Can you give me a hint which patch this is?
We use kernel 2.6.18 and ipipe 1.5-01, which I think is the latest for
this kernel.
We could backport the ipipe patch, but we don't want to change the
kernel.
Thanks.
Markus
-Original Message-
From: Gilles Chanteperdrix [mailto:[EMAIL PROTECTED]
Sent: Mittwoch, 4. Juni 2008 15:40
To: Markus Osterried
Cc: Xenomai-core@gna.org
Subject: Re: [Xenomai-core] system hangs with "ifconfig eth0 down"
On Wed, Jun 4, 2008 at 3:10 PM, Markus Osterried
<[EMAIL PROTECTED]> wrote:
> Hi,
>
> I am using Xenomai with pSOS-skin.
> The application and the whole system crashes when I call the following
> statement from a pSOS-thread:
>
> system("ifconfig eth0 down");
>
> Any other call to system(), e.g. system("ls") works fine.
> On the other hand, if I call "ifconfig eth0 down" from a shell outside
> the Xenomai-application, it works also fine.
>
> I have reduced the whole application to only one pSOS-thread which
> only call system(), it crashes.
> If I call system() in the main() function before creating/starting the
> pSOS-thread, it works fine.
>
> Anybody any idea why this call to system() doesn't work from inside
> the application?
A similar issue has been fixed in recent I-pipe patches. Could you try a
more recent I-pipe patch ?
--
Gilles
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] system hangs with "ifconfig eth0 down"
Hi, our kernel (along with the device drivers) is specifically adapted to our embedded system, it would be a huge bunch of work to change the kernel. I think to do the ipipe backport is a lot easier. Markus -Original Message- From: Gilles Chanteperdrix [mailto:[EMAIL PROTECTED] Sent: Mittwoch, 4. Juni 2008 16:55 To: Markus Osterried Cc: Xenomai-core@gna.org Subject: Re: [Xenomai-core] system hangs with "ifconfig eth0 down" On Wed, Jun 4, 2008 at 4:35 PM, Markus Osterried <[EMAIL PROTECTED]> wrote: > Hi, > > thank you for the fast response. > Can you give me a hint which patch this is? > We use kernel 2.6.18 and ipipe 1.5-01, which I think is the latest for > this kernel. > We could backport the ipipe patch, but we don't want to change the > kernel. > Thanks. Could you try with the latest kernel first ? We will tell you what to backport if this solves your issue. -- Gilles ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] pSOS skin: bug in tm_ticks_to_date() and tm_date_to_ticks()
Hello,
there is a bug in the pSOS kernel-space skin, calculating calendar time
to ticks and vice versa.
The file xenomai/ksrc/skins/psos+/tm.c should be fixed like this:
--- xenomai-2.4/ksrc/skins/psos+/tm.c
+++ xenomai-2.4/ksrc/skins/psos+/tm.c
@@ -204,8 +204,8 @@
/* Add one day for leap year after February. */
*count += 1;
- for (n = month - 1; month > 0; month--)
- *count += tm_month_sizes[month - 1];
+ for (n = 0; n < month-1; n++)
+ *count += tm_month_sizes[n];
*count += day - 1;
*count *= 24;
@@ -223,9 +223,10 @@
static void tm_ticks_to_date(u_long *date,
u_long *time, u_long *ticks, xnticks_t count)
{
- u_long year, month, day, hour, min, sec, allsecs, rem;
+ u_long year, month, day, hour, min, sec, rem;
+ xnticks_t allsecs;
- allsecs = (u_long)xnarch_ulldiv(count,
xntbase_get_ticks2sec(psos_tbase), &rem);
+ allsecs = xnarch_ulldiv(count, xntbase_get_ticks2sec(psos_tbase),
&rem);
year = 0;
@@ -257,14 +258,14 @@
month++;
}
- day = allsecs / tm_secbyday;
- allsecs -= (day * tm_secbyday);
- day++; /* Days are 1-based. */
- hour = (allsecs / tm_secbyhour);
- allsecs -= (hour * tm_secbyhour);
- min = (allsecs / tm_secbymin);
- allsecs -= (min * tm_secbymin);
sec = allsecs;
+ day = sec / tm_secbyday;
+ sec -= (day * tm_secbyday);
+ day++; /* Days are 1-based. */
+ hour = (sec / tm_secbyhour);
+ sec -= (hour * tm_secbyhour);
+ min = (sec / tm_secbymin);
+ sec -= (min * tm_secbymin);
*date = (year << 16) | (month << 8) | day;
*time = (hour << 16) | (min << 8) | sec;
Thank you
Markus
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] pSOS skin: bug in tm_ticks_to_date() and tm_date_to_ticks()
Sorry, I have not tried 2.4.4 (the same old story, we are a little late with the versions ... ;-) But anyway, as Philippe mentioned, both fixes are not okay in 2.4.4. I hope my fix is correct in both situations. Markus -Original Message- From: Philippe Gerum [mailto:[EMAIL PROTECTED] On Behalf Of Philippe Gerum Sent: Freitag, 13. Juni 2008 17:22 To: Gilles Chanteperdrix Cc: Markus Osterried; Xenomai-core@gna.org Subject: Re: [Xenomai-core] pSOS skin: bug in tm_ticks_to_date() and tm_date_to_ticks() Gilles Chanteperdrix wrote: > On Fri, Jun 13, 2008 at 4:18 PM, Markus Osterried > <[EMAIL PROTECTED]> wrote: >> Hello, >> >> there is a bug in the pSOS kernel-space skin, calculating calendar >> time to ticks and vice versa. >> The file xenomai/ksrc/skins/psos+/tm.c should be fixed like this: > > Have you tried Xenomai 2.4.4 ? It contains a fix in the same file. > Actually, my fix was wrong, it should have read: for (n = month - 1; n > 0; n--) - *count += tm_month_sizes[n]; + *count += tm_month_sizes[n - 1]; The other hunk, which is an overflow issue has been fixed in SOLO recently, but not merged back yet, so this still applies. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] RTDM timeout value
Hi, it seems that in the RTDM API, all the timeout functions which use nanosecs_rel_t have a strange behaviour. The timeout in nanoseconds is converted to ticks and the number of ticks is rounded down. So when we want to wait e.g. 50 nanoseconds and the timertick is 1 ms, xnpod_ns2ticks() rounds down to 0. But 0 is the special value RTDM_TIMEOUT_INFINITE, so we wait forever. I use Xenomai 2.3.1, but I think it's basically the same in trunk. Wouldn't it be better to round up the ticks instead of round it down? Thanks Markus ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] rtdm_iomap_to_user() with PowerPC
Hello, I want to use rtdm_iomap_to_user() to map our device registers to user space. But this doesn't work, our application just crashes when I read from the mapped registers. When I insert the line vma->vm_page_prot = phys_mem_access_prot(filp, paddr>>PAGE_SHIFT, size, vma->vm_page_prot); in rtdm_mmap_buffer() just before calling xnarch_remap_io_page_range() it works fine. This is just like it is done in /drivers/char/mem.c and in /drivers/video/fbmem.c. But I think this is architecture and kernel version dependent and I don't know whether rtdm_mmap_buffer() is the right place. I use Xenomai 2.3.1 and Linux 2.6.18 with PowerPC CPU. What is the best solution? Everyone else seen this problem? Thanks Markus ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
