On 12/14/18 2:16 PM, Julien Blanc wrote:
> Le vendredi 14 décembre 2018 à 12:07 +0100, Philippe Gerum a écrit :
>>
>> You could use non-rt Xenomai threads on the linux side with policies
>> SCHED_FIFO+prio=0 or SCHED_WEAK, allowing the thread to issue
>> blocking
>> Xenomai syscalls (such as
On Fri, Dec 14, 2018 at 2:48 PM Philippe Gerum wrote:
>
> On 12/13/18 12:13 PM, Pintu Agarwal wrote:
> > Dear Philippe,
> >
> > Currently I am working on Xenomai-3.0.6 bring up on QualComm Dragon
> > Board 410c using QualComm Linux Kernel 4.9.xxx
> >
> > First I wanted to know if this part
Le vendredi 14 décembre 2018 à 12:07 +0100, Philippe Gerum a écrit :
>
> You could use non-rt Xenomai threads on the linux side with policies
> SCHED_FIFO+prio=0 or SCHED_WEAK, allowing the thread to issue
> blocking
> Xenomai syscalls (such as waiting on a Cobalt sema4).
>
> But, since this
Hi all,
while debugging that list corruption in Rtnet I noticed that the related
smokey tests are in a rather improvable state. First of all, they are
never working automatically unless the rtnet core is built into the
kernel. When it is just a model, the corectl check will always fail
because
On 14.12.18 10:14, duanwujie wrote:
Hi, Phi and Jan:
I have question about synchronization object.Consider under condition.
*
*
*Thread A*
mutex_lock(lock) //O1
...
...
mutex_unlock(lock)//O2
*Thread B*
mutex_lock(lock) //O3
Do not add rtskbs to the rtskb_list which are not mappend because
rtdev_unmap_rtskb will not remove such rtskbs again (buf_dma_addr ==
RTSKB_UNMAPPED). In fact, rtskb_list should be called rtskb_mapped_list,
so refactor this while at it.
Signed-off-by: Jan Kiszka
---
On 12/14/18 11:48 AM, Julien Blanc via Xenomai wrote:
> Hi,
>
> We’re currently using semaphores and a shared buffer to allow
> communication between a xenomai cobalt thread and a linux regular
> thread (the xddp interface has been tested and does not perform well
> for our use case, which is
On 12/14/18 11:48 AM, Julien Blanc via Xenomai wrote:
> Hi,
>
> We’re currently using semaphores and a shared buffer to allow
> communication between a xenomai cobalt thread and a linux regular
> thread (the xddp interface has been tested and does not perform well
> for our use case, which is
Hi,
We’re currently using semaphores and a shared buffer to allow
communication between a xenomai cobalt thread and a linux regular
thread (the xddp interface has been tested and does not perform well
for our use case, which is exchanging a lot a very small messages).
While this works fine most
On 12/13/18 12:13 PM, Pintu Agarwal wrote:
> Dear Philippe,
>
> Currently I am working on Xenomai-3.0.6 bring up on QualComm Dragon
> Board 410c using QualComm Linux Kernel 4.9.xxx
>
> First I wanted to know if this part already available.
> So, for the initial search, I came across this:
> -
Hi, Phi and Jan:
I have question about synchronization object.Consider under condition.
*
*
*Thread A*
mutex_lock(lock) //O1
...
...
mutex_unlock(lock)//O2
*Thread B*
mutex_lock(lock) //O3
mutex_unlock(lock);
O1: become xnsynch's owner.
11 matches
Mail list logo
