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 b
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,
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
Philippe Gerum
<[EMAIL PROTECTED] An: Markus
Osterried <[EMAIL PROTECTED]>
g> Kop
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.
B
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 mus
Gerum
<[EMAIL PROTECTED] An: Markus
Osterried <[EMAIL PROTECTED]>
g>
problem and sometimes not. :-(
Markus
Philippe Gerum
<[EMAIL PROTECTED] An: Markus
Osterried <[EMAIL PROTECTED]>
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 Osterri
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) us
alf 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:
>
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
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 ou
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
: 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 yo
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 lea
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 Osterr
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() roun
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
20 matches
Mail list logo