On Mon, 2019-01-14 at 10:39 +0100, Henning Schild wrote:
> Am Fri, 11 Jan 2019 14:47:13 +0100
> schrieb Mauro Salvini :
>
> > On Fri, 2019-01-11 at 10:40 +0100, Henning Schild wrote:
> > > Am Fri, 11 Jan 2019 09:57:50 +0100
> > > schrieb Mauro Salvini via Xenomai :
> > >
> > > > Hi all,
> > > >
Lookin good! Hope everyone had a happy new year! A great release to start off
the great year of 2019! Cheers!
Alec
clock_decrease_after_periodic_timer_first_tick checks that periodic
interval timers based on CLOCK_REALTIME are not (pathologically)
affected by the epoch going backwards.
To this end, we measure the actual time observed between two ticks of
a periodic timer based on CLOCK_REALTIME with a call to
Disabling round-robin is obtained by passing XN_INFINITE for quantum
to xnthread_set_slice(), which is zero: we don't want to check such
value against the clock gravity.
As a matter of fact, this bug may have prevented the RR mode to be
switched off for years, causing the routine to always fail ea
The token-based approach for detecting preemption while data is being
moved into or out of the ring only protects from read vs read races,
not from races involving a write side. For instance, a reader might
read dirty data being changed by a writer concurrently, or two writers
might compete writing
Non-cobalt kernel code may hook interrupts using ipipe_request_irq()
directly, which means that xnintr_vec_first() cannot assume that
__ipipe_irq_cookie() always returns a valid xnintr struct for all
irqs.
We need to detect those irqs while iterating over the interrupt
namespace when pulling data
We receive the sampling period from the setup struct attached to the
AUTOTUNE_RTIOC_{IRQ,KERN,USER} requests, drop the last copy from user
from autotune_ioctl_nrt() which is spurious.
Signed-off-by: Philippe Gerum
---
kernel/drivers/autotune/autotune.c | 6 +-
1 file changed, 1 insertion(+),
clock_decrease_after_periodic_timer_first_tick checks that periodic
interval timers based on CLOCK_REALTIME are not (pathologically)
affected by the epoch going backwards.
To this end, we measure the actual time observed between two ticks of
a periodic timer based on CLOCK_REALTIME with a call to
An overdue stable release has just been completed. The git repo is
already filled and also provide source download tarballs:
https://gitlab.denx.de/Xenomai/xenomai/tags/v3.0.8
Just those downloads at the usual places () will follow later.
Changes since 3.0.7:
Christophe BLAESS (1):
Add th
On 14.01.19 10:57, Jan Kiszka via Xenomai wrote:
From: Jan Kiszka
That file was removed with f1da4876271d.
Signed-off-by: Jan Kiszka
---
config/Makefile.am | 1 -
1 file changed, 1 deletion(-)
diff --git a/config/Makefile.am b/config/Makefile.am
index 96786b4ac0..9ce4a9c843 100644
--- a/c
Am 13.01.19 um 05:08 schrieb Jan Kiszka:
> On 11.01.19 22:55, Johannes Holtz via Xenomai wrote:
>> Hi,
>>
>> I managed to leave some labeled XDDP and IDDP FDs open after a
segfault.
>> Even though the process is killed the resources/FDs are not freed.
Is there a
>> way to close them or do I ha
From: Jan Kiszka
That file was removed with f1da4876271d.
Signed-off-by: Jan Kiszka
---
config/Makefile.am | 1 -
1 file changed, 1 deletion(-)
diff --git a/config/Makefile.am b/config/Makefile.am
index 96786b4ac0..9ce4a9c843 100644
--- a/config/Makefile.am
+++ b/config/Makefile.am
@@ -4,5 +4
Am Fri, 11 Jan 2019 14:47:13 +0100
schrieb Mauro Salvini :
> On Fri, 2019-01-11 at 10:40 +0100, Henning Schild wrote:
> > Am Fri, 11 Jan 2019 09:57:50 +0100
> > schrieb Mauro Salvini via Xenomai :
> >
> > > Hi all,
> > >
> > > I'm testing same hardware of [1], with kernel 4.9.146 from ipipe-
>
Le dimanche 13 janvier 2019 à 02:33 +, Giulio Moro via Xenomai a
écrit :
> Hi all,
> is there a "cheap", RT-safe call that can be made in order to find
> out if the current thread is a Xenomai thread or a Linux thread?
> Also, to detect whether the Xenomai thread is in primary or secondary
> mo
14 matches
Mail list logo
