On Thu, Jun 03, 2010 at 04:09:38AM -0400, stephane ancelot wrote:
> Hi,
>
> tryied in v2.4.10 :
>
>
> I have opened a /dev/rtp7 pipe , and deleted it.
>
> if I launch again the same program, rt_pipe_open replies with -EBUSY
>
Can you describe the sequence how you are invoking
rt_pipe_op
I think, "Hear, Hear" is appropriate for Canada as there is still the queen on
the dollar bills.
Andreas
From: xenomai-core-boun...@gna.org [xenomai-core-boun...@gna.org] On Behalf Of
Peter Soetens [pe...@thesourceworks.com]
Sent: Thursday, January 07, 20
> We had the problem that one of our threads, which we initially assigned
> priority 29, ended up having priority 89.
> I know that PI is the reason why the priority of the thread was first bumped
> up to 89 and then to 90 because
> two higher priority threads started blocking on two different mu
Hi,
We had the problem that one of our threads, which we initially assigned
priority 29, ended up having priority 89.
I know that PI is the reason why the priority of the thread was first bumped up
to 89 and then to 90 because
two higher priority threads started blocking on two different mutexes
> >
> > > > > > > - powerpc32 updates for 2.6.30. Mainly to merge the once
> > > > > > > experimental
> > > > > > > bits that prevent most alignment faults from triggering a
> > > > > > > secondary mode
> > > > > > > switch. Andreas told me this works like a charm on 83xx, and I
> > > > > > > di
Hi,
Our legacy code has two functions to disable and enable interrupts going
to the CPU core like cli() and sti() in the Linux kernel. Those function pairs
are used to avoid interruptions in critical code sections by the scheduler
or interrupts. Interruptions in those code sections can potentially
Hi Philippe,
Back at work. See inline replies below.
> > > > > - powerpc32 updates for 2.6.30. Mainly to merge the once experimental
> > > > > bits that prevent most alignment faults from triggering a secondary
> > > > > mode
> > > > > switch. Andreas told me this works like a charm on 83xx, an
On Fri, 2009-10-02 at 21:00 +0200, Philippe Gerum wrote:
> On Fri, 2009-10-02 at 14:01 -0400, Andreas Glatz wrote:
> > >
> > > - powerpc32 updates for 2.6.30. Mainly to merge the once experimental
> > > bits that prevent most alignment faults from triggering a second
>
> - powerpc32 updates for 2.6.30. Mainly to merge the once experimental
> bits that prevent most alignment faults from triggering a secondary mode
> switch. Andreas told me this works like a charm on 83xx, and I did not
> see any issue on 52xx, 85xx or 86xx either.
>
Can I get a version of th
Hi,
> full of energy after this tremendous first XUM, I would like to start a
> discussion about what people would like to see in the 2.5 branch.
True, it was an great opportunity to see and talk to you guys.
Here is a first list, please feel free to criticize it:
- signals in primary domain (s
Hi,
>
> Whenever possible, please post patches inline (I had to manually copy it
> to allow commenting).
Sure, no problem.
>
> You cannot bluntly call release() here. You may not run in Linux context
> while that handler demands this.
It's also called in xnpipe_disconnect() (if I follow 'g
Hi,
Currently, you can destroy RT_PIPE while a non-rt application is
connected. If that happens the pipe won't be fully closed but
some parts will be leftover for cleanup when closing the RT_PIPE
from the non-rt application (lingering close).
For us it would be very convenient if we didn't have t
Hi Philippe,
On Fri, 2009-08-21 at 18:00 +0200, Philippe Gerum wrote:
> On Fri, 2009-08-21 at 11:44 -0400, Andreas Glatz wrote:
> > Hi,
> >
> > Is there a reason why the following patch didn't make it into 2.4.9?
> >
>
> Yes, unless I'm mistaken, no
Hi,
Is there a reason why the following patch didn't make it into 2.4.9?
See: https://mail.gna.org/public/xenomai-help/2009-08/msg00023.html
I included it into our system. I didn't see any problems so far...
Regards,
Andreas
On Wed, 2009-08-19 at 17:46 +0200, Philippe Gerum wrote:
> Here is
On 17 Jul 2009, at 12:24, Jan Kiszka wrote:
Andreas Glatz wrote:
Hi,
I have some questions about the future of Xenomai:
1) I read that in Xenomai 3 you will add support to switch between
the native Xenomai scheduler
and the Linux scheduler patched with the RT_PREEMPT patchset.
When
Hi,
I have some questions about the future of Xenomai:
1) I read that in Xenomai 3 you will add support to switch between
the native Xenomai scheduler
and the Linux scheduler patched with the RT_PREEMPT patchset.
When are you planning to
start this development?
2) Is it right to
On Wed, 2009-03-18 at 23:01 +0100, Philippe Gerum wrote:
> Philippe Gerum wrote:
> > Andreas Glatz wrote:
> >> Hi,
> >>
> >> I got a kernel crash because inside xnheap_test_and_free a
> >> invalid pointer contained in variable 'nextpage' is d
The last source code I sent is outdated.
The newest version with a sighandler for SIGINT is attached here.
Sorry for that,
Andreas
#include
#include
#include
#include
#include
#include
#include
#include
#include
static RT_TASK m_task;
static RT_PIPE m_pipe;
static volatile int
Hi,
I got a kernel crash because inside xnheap_test_and_free a
invalid pointer contained in variable 'nextpage' is dereferenced:
free_pages:
/* Mark the released pages as free in the extent's page map. */
for (pagecont = 0; pagecont < npages; pagecont++)
extent->pagemap[pagenum + pag
Hi,
On Mon, 2009-03-09 at 18:02 +0100, Philippe Gerum wrote:
> Andreas Glatz wrote:
> > Hi,
> >
> > On Mon, 2009-03-09 at 17:08 +0100, Philippe Gerum wrote:
> >> Andreas Glatz wrote:
> >>> Hi,
> >>>
> >>> Calling rt_queue_cre
Hi,
On Mon, 2009-03-09 at 17:08 +0100, Philippe Gerum wrote:
> Andreas Glatz wrote:
> > Hi,
> >
> > Calling rt_queue_create in a real-time task is supposed to fail
> > according to the documentation.
> >
>
> It fails from kernel space, otherwise, fro
worry me too much.
> You may consider redesigning your applications to use pre-allocated
> queues as it would be better overall.
Agreed. I consider it as last resort.
>
> Regards,
> Steven
Thanks,
Andreas
>
> On Mar 9, 2009, at 10:20 AM, Andreas Glatz wrote:
>
>
Hi,
Calling rt_queue_create in a real-time task is supposed to fail
according to the documentation.
I found out, that the reason for this is, that the memory for
the queue memory pool is allocated with vmalloc/kmalloc.
Is there another reason?
I still would like to be able to call rt_queue_cr
Hi,
I'm using linux-2.6.26 with Freescale patches and the
adeos-ipipe-2.6.26-powerpc-DENX-2.2-04.patch from xenomai-2.4.5 on a
Freescale PowerPC MPC8360.
I was calling 'vprintk' (kernel/printk.c) from within a Xenomai task
which lead to a Linux freeze.
After some investigation, I found out that
24 matches
Mail list logo
