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
] 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
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
: 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
: 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
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
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
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
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
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,
paddrPAGE_SHIFT, size, vma-vm_page_prot);
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()
[EMAIL PROTECTED] An: Markus
Osterried [EMAIL PROTECTED]
g Kopie:
xenomai
Philippe Gerum
[EMAIL PROTECTED] An: Markus
Osterried [EMAIL PROTECTED]
g
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
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.
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
[EMAIL PROTECTED] An: Markus
Osterried [EMAIL PROTECTED]
g Kopie:
xenomai-core@gna.org
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,
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
19 matches
Mail list logo
