On Fri, May 27, 2022 at 6:14 PM Daniel Wagner wrote:
> > Whoops, old date.
> > 10. June to 12. June 2022 it is.
> Here some more details about this event (hint if you want to attend
> please let us know).
Please prepare for bad weather, in the mountains the situation can
change quickly… The
On Fri, May 27, 2022 at 11:35 PM Konstantin Smola via Xenomai
wrote:
>
> pci probe was overwriting baud_base with default values, ignoring baud_base
> arguments passed in while loading driver.
>
> Signed-off-by: Konstantin Smola
> ---
> kernel/drivers/serial/16550A_pci.h | 3 ++-
> 1 file
- Ursprüngliche Mail -
> An update:
> If the 16550A driver is modprobed with no arguments, it apparently
> probes the PCI subsystem, gets the irq, and interrupts are enabled OK.
> The serial port can send/receive data.
> But, if a port= or irq= argument is passed into the 16550A driver,
>
On Thu, May 26, 2022 at 2:08 AM C Smith wrote:
>
> On Wed, May 25, 2022 at 1:07 AM Richard Weinberger
> wrote:
> >
> > On Wed, May 25, 2022 at 2:18 AM C Smith via Xenomai
> > wrote:
> > > We are using Xenomai 3.1.2 on kernel 4.19.229, X86 CPU
> > > We have a (Moxa CP-104ul) serial card on an
On Wed, May 25, 2022 at 2:18 AM C Smith via Xenomai wrote:
> We are using Xenomai 3.1.2 on kernel 4.19.229, X86 CPU
> We have a (Moxa CP-104ul) serial card on an isolated PCI bus interrupt 17.
> lspci -v confirms that the serial card is isolated and that no other
> peripheral uses this interrupt.
- Ursprüngliche Mail -
> Von: "Jan Kiszka"
>> Hm, I thought (hoped?) --help is auto generated by autoconf.
>> Will check.
>>
>
> You series did not touch configure.ac.
But 54f69549266b ("configure.ac: Enable SMP by default") did.
Now I see that the help text is part of the
- Ursprüngliche Mail -
> Von: "Jan Kiszka"
> On 05.05.22 22:06, Richard Weinberger via Xenomai wrote:
>> ping? :-)
>>
>
> Thanks for the reminder - merged.
Did you also apply "[PATCH 2/2] doc: Remove references to --enable-smp"?
>
ping? :-)
On Wed, Apr 13, 2022 at 2:05 PM Richard Weinberger via Xenomai
wrote:
>
> SMP is now enabled by default for all architectures.
> No need to use --enable-smp anymore.
>
> Signed-off-by: Richard Weinberger
> ---
> debian/rules | 1 -
> 1 file changed, 1 de
On Thu, May 5, 2022 at 4:56 PM Grau, Gunter via Xenomai
wrote:
>
>
> Hi,
>
> We are trying to port our application to Xenomai 3.2.
> The source is c++ and we use in some parts C++11 elements. Therefore the
> compile switch is set to -std=c++11.
Since Xenomai uses GNU extensions you need to use
On Thu, May 5, 2022 at 7:47 AM C Smith via Xenomai wrote:
>
> In my serial_config which I pass to the ioctl() that sets up my
> 16550A.ko serial port
> I have set .rx_timeout = 50
> and I am doing non-blocking reads.
>
> This indeed results in a 500us delay when reading a serial port with
Florian,
- Ursprüngliche Mail -
> Von: "Florian Bezdeka"
> it seems that I'm able to reproduce a register (or stack) corruption on
> x86.
>
> The problem does not appear when running the Xenomai testsuite
> (especially switchtest) without any additional load. Stressing Linux
> with
It's coreclk not coreclck.
Signed-off-by: Richard Weinberger
---
doc/asciidoc/MIGRATION.adoc | 6 +++---
doc/asciidoc/man1/autotune.adoc | 8
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/doc/asciidoc/MIGRATION.adoc b/doc/asciidoc/MIGRATION.adoc
index
On Fri, Apr 29, 2022 at 9:04 AM C Smith via Xenomai wrote:
> int Lp_port_handler(rtdm_irq_t *irq_handle_p)
> {
>static int err;
>unsigned long next;
>rtdm_irq_t *handle_p;
>
>handle_p = rtdm_irq_get_arg(irq_handle_p, rtdm_irq_t);
>
>next = rtdm_clock_read();
>// do some
On Thu, Apr 28, 2022 at 12:34 PM Ivan Jiang via Xenomai
wrote:
>
> Dear Xenomais’
>
>
>
>I know how to use RTDM Skin in makefile wich --rtdm in CFLAGS LFLAGS.
>
>But if some cpp threads should use CMAKE and I really don’t know how
> to edit cmakelists with this skin.
xeno-config
On Fri, Apr 22, 2022 at 5:02 AM Jae Hyun Park wrote:
> Then can I understand that tasks made with rt_task_create work similarly to
> multi-threading?
>
> And I wonder if there is any difference in real-time guarantee performance
> between pthread
>
> of posix skin and xnthread of realtime
On Thu, Apr 21, 2022 at 8:21 AM Jae Hyun Park via Xenomai
wrote:
> I have been used rt_task_create from Xenomai 2.
>
> In the Xenomai 3 cobalt example, it seemed to use only pthread_create.
It depends on the skin. rt_task_create is part of the native/alchemy skin.
While pthread_create is part of
On Tue, Apr 19, 2022 at 9:59 AM Daniel Wagner via Xenomai
wrote:
> What: High altitude realtime workshop 2022 edition
> When: 2020-06-05 to 2020.06.07
Whoops, old date.
10. June to 12. June 2022 it is.
- Ursprüngliche Mail -
>> Did the nucleus CPU scheduler guarantee that giving another task
>> the same priority of the calling task will favour the caller?
>> Now the gifted task seems to win.
>
> Did you configure with --enable-lazy-setsched? If not, set_prio should
> send the caller to
- Ursprüngliche Mail -
> Von: "Jan Kiszka"
>> task5 fails:
>> [9] at task-5.c:79
>> [1] at task-5.c:23
>> [10] at task-5.c:87
>> [3] at task-5.c:40
>> [11] at task-5.c:95
>> [4] at task-5.c:45
>> [5] at task-5.c:50
>> [6] at task-5.c:55
>>
- Ursprüngliche Mail -
> Von: "Florian Bezdeka"
>> ...same does marking both variables as volatile.
>
> I don't have much context here, but volatile sounds like a valid
> solution (assuming that safety is written by a different thread)
Both variables are written by the very same thread.
- Ursprüngliche Mail -
> Von: "Jan Kiszka"
> An: "richard" , "xenomai"
> Gesendet: Donnerstag, 14. April 2022 13:18:59
> Betreff: Re: [PATCH v2 0/9] Revive alchemy, pSOS and VxWorks tests
> On 13.04.22 23:58, Richard Weinberger via Xenomai w
- Ursprüngliche Mail -
> Von: "Jan Kiszka"
>> alchemytest_driver uses smokey and runs each test as new process.
>
> Maybe rather call this "wrapper" or "loader" - driver reminded my first
> of a kernel driver.
Sure. Or "runner"?
Thanks,
//richard
- Ursprüngliche Mail -
>> Ah, alchemytest_driver.c comes in a follow up patch.
>> Will be fixed in a later series.
>
> Upps, this was on v1 - but it seems v2 was not different in this regard.
I meant v3, which I'll prepare soon.
v2 is just v1 plus sSOS/VxWorks.
> I would have to dig
- Ursprüngliche Mail -
> Von: "Jan Kiszka"
> Seems we need to fix those at least.
Agreed.
>>
>> If Xenomai was configured with --enable-lores-clock, tests mq1, mutex1,
>> pip1 and
>> sem1 fail due to:
>> undefined symbol: __clockobj_ticks_to_timeout
>
> Missing lib
On Thu, Apr 14, 2022 at 1:12 PM Jan Kiszka via Xenomai
wrote:
> With only up to here applied:
>
> make[2]: Entering directory 'xenomai/build/testsuite/alchemytests'
> make[2]: *** No rule to make target 'alchemytest_driver.c', needed by
> 'alchemytest_driver.o'. Stop.
Ah, alchemytest_driver.c
On Thu, Apr 14, 2022 at 9:24 AM FanJun Kong via Xenomai
wrote:
>
> Hi, developer
> I met this on Arm64 and I am using 5.10.89 + xenomai3.2.1
Can you please share the full error message you get?
I'd like to know which function/object needs udp_sock.
--
Thanks,
//richard
Make it static, no prototype needed anymore.
Fixes:
task-9.c:13:6: error: no previous prototype for ‘sighandler’
[-Werror=missing-prototypes]
void sighandler(int sig)
Signed-off-by: Richard Weinberger
---
testsuite/alchemytests/task-9.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Test case for the following regression:
https://www.xenomai.org/pipermail/xenomai/2022-March/047451.html
Signed-off-by: Richard Weinberger
---
Changes since v1:
- Make sure to restore SA upon failure.
---
configure.ac | 2 +
testsuite/smokey/Makefile.am | 7
This patch series is a first attempt to integrate the currently abandoned
alchemy, pSOS and VxWorks tests into Xenomai's test suite.
Since each test assumes running as own process a test driver is needed
which executes each tests separately.
The driver makes use of the smokey framework.
Test
In their current shape, every alchemy test has to be a single
program and does not use the smokey test framework.
alchemytest_driver uses smokey and runs each test as new process.
Signed-off-by: Richard Weinberger
---
testsuite/alchemytests/Makefile.am | 11 +++
This is the very first step to have the alchemy tests embedded
into our testsuite.
Signed-off-by: Richard Weinberger
---
{lib/alchemy/testsuite => testsuite/alchemytests}/alarm-1.c | 0
{lib/alchemy/testsuite => testsuite/alchemytests}/buffer-1.c | 0
{lib/alchemy/testsuite =>
Build them using Xenomai's build system.
Signed-off-by: Richard Weinberger
---
configure.ac | 1 +
testsuite/Makefile.am | 6 +-
testsuite/alchemytests/Makefile.am | 148 +
3 files changed, 153 insertions(+), 2 deletions(-)
Same as for alchemy and pSOS.
Signed-off-by: Richard Weinberger
---
configure.ac | 1 +
lib/vxworks/testsuite/Makefile| 43
testsuite/Makefile.am | 6 +-
testsuite/vxworkstests/Makefile.am| 100
Make n an unsigned integer, such that gcc realizes that "%.2d" cannot
become negative and will fit into our 3 bytes buffer.
Fixes:
buffer-1.c:64:15: error: ‘%.2d’ directive writing between 2 and 10 bytes into a
region of size 3 [-Werror=format-overflow=]
sprintf(s, "%.2d", 11 * n);
Just like for alchemy tests, integrate them into our test suite.
Signed-off-by: Richard Weinberger
---
configure.ac | 1 +
lib/psos/testsuite/Makefile | 49 --
testsuite/Makefile.am | 6 +-
Just like for alchemytests.
Signed-off-by: Richard Weinberger
---
testsuite/psostests/Makefile.am | 15 -
testsuite/psostests/psostest_driver.c | 85 +++
2 files changed, 99 insertions(+), 1 deletion(-)
create mode 100644 testsuite/psostests/psostest_driver.c
Signed-off-by: Richard Weinberger
---
lib/alchemy/testsuite/Makefile | 70 --
1 file changed, 70 deletions(-)
delete mode 100644 lib/alchemy/testsuite/Makefile
diff --git a/lib/alchemy/testsuite/Makefile b/lib/alchemy/testsuite/Makefile
deleted file mode 100644
- Ursprüngliche Mail -
> Von: "Jan Kiszka"
> An: "richard" , "xenomai"
> Gesendet: Mittwoch, 13. April 2022 14:56:16
> Betreff: Re: [PATCH 0/6] Revive alchemy tests
> On 08.04.22 10:03, Richard Weinberger via Xenomai wrote:
>>
SMP is now enabled by default for all architectures.
No need to use --enable-smp anymore.
Signed-off-by: Richard Weinberger
---
debian/rules | 1 -
1 file changed, 1 deletion(-)
diff --git a/debian/rules b/debian/rules
index 3fe6bece93c9..60094734630d 100755
--- a/debian/rules
+++
SMP is enabled by default, remove usage of --enable-smp
and document how to disable SMP, if needed.
Signed-off-by: Richard Weinberger
---
doc/asciidoc/README.INSTALL.adoc | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/doc/asciidoc/README.INSTALL.adoc
- Ursprüngliche Mail -
> + if (!__Terrno(ret, sigaction(SIGSEGV, , _sa)))
> + goto out;
> +
> + if (!__Terrno(ret, iopl(3)))
> + goto out;
> +
> + if (!__T(ret, pthread_create(, NULL, tfn, NULL)))
> + goto out;
> +
> + if (!__T(ret,
Test case for the following regression:
https://www.xenomai.org/pipermail/xenomai/2022-March/047451.html
Signed-off-by: Richard Weinberger
---
configure.ac | 2 +
testsuite/smokey/Makefile.am | 7 +++
testsuite/smokey/x86io/Makefile.am | 7 +++
- Ursprüngliche Mail -
> Von: "Philippe Gerum"
>> So the tests have assumptions about the scheduling order of threads?
>> I always thought even with a single CPU such assumptions can break.
>
> Not if the scheduling core Xenomai provides does its job properly.
I see.
Thanks,
//richard
Philippe,
- Ursprüngliche Mail -
> Von: "Philippe Gerum"
>> Why is this "special" cpu-affinity necessary? What would happen if we
>> remove that? Asking because I want to make sure that we do not miss any
>> concurrency problems by adding this constraint.
>>
>
> The reason to pin the
Florian,
- Ursprüngliche Mail -
> Why is this "special" cpu-affinity necessary? What would happen if we
> remove that? Asking because I want to make sure that we do not miss any
> concurrency problems by adding this constraint.
I don't know. I copied it as-is from the old Makefile.
In 2022 it is hard to find ARM or x86 systems without SMP.
Other CPU architectures are no longer supported by Xenomai.
So, make SMP support opt-out.
Signed-off-by: Richard Weinberger
---
configure.ac | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/configure.ac
This is the very first step to have the alchemy tests embedded
into our testsuite.
Signed-off-by: Richard Weinberger
---
{lib/alchemy/testsuite => testsuite/alchemytests}/alarm-1.c | 0
{lib/alchemy/testsuite => testsuite/alchemytests}/buffer-1.c | 0
{lib/alchemy/testsuite =>
Make n an unsigned integer, such that gcc realizes that "%.2d" cannot
become negative and will fit into our 3 bytes buffer.
Fixes:
buffer-1.c:64:15: error: ‘%.2d’ directive writing between 2 and 10 bytes into a
region of size 3 [-Werror=format-overflow=]
sprintf(s, "%.2d", 11 * n);
In their current shape, every alchemy test has to be a single
program and does not use the smokey test framework.
alchemytest_driver uses smokey and runs each test as new process.
Signed-off-by: Richard Weinberger
---
testsuite/alchemytests/Makefile.am | 11 +++
This patch series is a first attempt to integrate the currently abandoned
alchemy tests into Xenomai's test suite.
Since each test assumes running as own process a test driver is needed
which executes each tests separately.
The driver makes use of the smokey framework.
Richard Weinberger (6):
Build them using Xenomai's build system.
Signed-off-by: Richard Weinberger
---
configure.ac | 1 +
testsuite/Makefile.am | 6 +-
testsuite/alchemytests/Makefile.am | 148 +
3 files changed, 153 insertions(+), 2 deletions(-)
Signed-off-by: Richard Weinberger
---
lib/alchemy/testsuite/Makefile | 70 --
1 file changed, 70 deletions(-)
delete mode 100644 lib/alchemy/testsuite/Makefile
diff --git a/lib/alchemy/testsuite/Makefile b/lib/alchemy/testsuite/Makefile
deleted file mode 100644
Make it static, no prototype needed anymore.
Fixes:
task-9.c:13:6: error: no previous prototype for ‘sighandler’
[-Werror=missing-prototypes]
void sighandler(int sig)
Signed-off-by: Richard Weinberger
---
testsuite/alchemytests/task-9.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
On Thu, Apr 7, 2022 at 10:03 AM Bezdeka, Florian via Xenomai
wrote:
>
> Hi Richard,
>
> On Wed, 2022-04-06 at 23:06 +0200, Richard Weinberger via Xenomai
> wrote:
> > ipipe took a copy of the queued work, __work was used to determine how much
> > bytes had to get copied
ipipe took a copy of the queued work, __work was used to determine how much
bytes had to get copied.
With dovetail no copy as taken and the __work parameter is no longer
useful, so we can get rid of it.
Signed-off-by: Richard Weinberger
---
include/cobalt/kernel/dovetail/pipeline/inband_work.h
- Ursprüngliche Mail -
>> How about additionally widening the suspected race window by adding a
>> delay to lostage_task_wakeup?
>
> Excellent idea! :-)
Yeah, with a dealy in lostage_task_wakeup() my WARN_ON_ONCE() triggers
very quickly.
[ 123.237698] [ cut here
- Ursprüngliche Mail -
> Von: "Jan Kiszka"
>> But I fear this might take some time. The KASAM spat happened only once
>> and also only after the test ran for almost 5 days.
>
> How about additionally widening the suspected race window by adding a
> delay to lostage_task_wakeup?
- Ursprüngliche Mail -
> Von: "Jan Kiszka"
> I would like to have an explanation or prove points (traces, assertions)
> that we actually see xnthread_relax overtaking the delivery of its own
> wakework.
I can re-test with something like that:
diff --git a/kernel/cobalt/thread.c
On Tue, Apr 5, 2022 at 3:02 PM Bezdeka, Florian via Xenomai
wrote:
> I'm not sure if waiting is really what we want. I like the idea of
> moving the work into struct xnthread as Jan already suggested
> internally.
Well, the wait is cheap, it does not involve scheduling.
I'm not sure whether
While testing some workload the following KASAN splat arose.
irq_work_single+0x70/0x80 is the last line of irq_work_single():
(void)atomic_cmpxchg(>node.a_flags, flags, flags & ~IRQ_WORK_BUSY);
So, writing to >node.a_flags failed.
atomic_read() and atomic_set() right before work->func(work)
On Sun, Apr 3, 2022 at 4:48 PM Philippe Gerum via Xenomai
wrote:
>
> From: Philippe Gerum
>
> When a proxy device is taking control of a (real) broadcast device, we
> have to:
>
> - remove the real device from the clockevents_list
> - keep that device ticking, i.e. no shutdown
>
> Fix
- Ursprüngliche Mail -
> Von: "Philippe Gerum"
> It seems unlikely that kernel.org would consider hosting us since the
> project does not upstream patches to the mainline kernel.
lore hosts many projects that are not directly related to the upstream
kernel.
e.g.
- Ursprüngliche Mail -
> Von: "Jan Kiszka"
> An: "Richard Weinberger" , "Florian Bezdeka"
>
> CC: "richard" , "xenomai"
> Gesendet: Montag, 4. April 2022 13:20:55
> Betreff: Re: [PATCH] Alchemy: Fix rt_task_unblock
- Ursprüngliche Mail -
> Von: "Jan Kiszka"
>> Uff yes. Just tried building with --with-core=mercury and it failed. ;-\
>>
>> So, when mercury is enabled, alchemy will use NPTL.
>> This means rt_task_unblock() cannot work on mercury because
>> pthread_mutex_lock() will not return EINTR
- Ursprüngliche Mail -
> Von: "Jan Kiszka"
> An: "richard" , "xenomai"
> Gesendet: Montag, 4. April 2022 13:21:45
> Betreff: Re: [PATCH] Alchemy: Fix rt_task_unblock() for RT_MUTEX
> On 30.03.22 22:16, Richard Weinberger via Xenomai wrote:
On Fri, Apr 1, 2022 at 9:16 AM Bezdeka, Florian via Xenomai
wrote:
> > With my changes at least the application works again and the tests
> > on the customer side pass.
>
> We would need such / similar tests as well inside the Xenomai testsuite
> to make sure we don't break it again.
I'm a bit
- Ursprüngliche Mail -
> Von: "Philippe Gerum"
> These are the two remaining patches in the final series, ok for both?
>
> tick: irq_pipeline: fix proxying of a broadcast device
> x86: dovetail: reinstate I/O bitmap on user entry
I meant this patches;
[PATCH 1/4] sched: dovetail: pass
- Ursprüngliche Mail -
> Von: "Florian Bezdeka"
> An: "Philippe Gerum" , "richard"
> CC: "xenomai"
> Gesendet: Sonntag, 3. April 2022 21:41:51
> Betreff: Re: [PATCH v2] x86: dovetail: reinstate I/O bitmap on user entry
>>> For the whole series:
>>> Reviewed-by: Richard Weinberger
>
- Ursprüngliche Mail -
> Von: "Philippe Gerum"
> An: "xenomai"
> CC: "Philippe Gerum" , "Richard Weinberger"
>
> Gesendet: Sonntag, 3. April 2022 16:43:48
> Betreff: [PATCH v2] x86: dovetail: reinstate I/O bitmap on user entry
> From: Philippe Gerum
>
> We have to fix up the TSS
On Sat, Apr 2, 2022 at 4:23 PM Philippe Gerum via Xenomai
wrote:
> - arch_dovetail_switch_finish(leave_inband);
> + ti_work = READ_ONCE(current_thread_info()->flags);
> + arch_dovetail_switch_finish(leave_inband, ti_work);
Why are you passing ti_work as parameter? AFAIU you
- Ursprüngliche Mail -
> Von: "Florian Bezdeka"
> I can't say much about the alchemy skin. Never used that myself. Have
> you checked the history if such a change was / could be intentional?
> CCing Jan...
Well, an application that relies on rt_task_unblock() now no longer works
with
Starting with Xenomai 3, RT_MUTEX is based on libcobalt's pthread mutex
implementation.
POSIX requires that pthread_mutex_lock() shall not return EINTR,
this requirement breaks rt_task_unblock() if a RT_TASK blocks on
a RT_MUTEX.
To restore the functionality provide a new function,
Hi!
The following test works fine on 5.4.180 (ipipe) but fails on 5.15.9 (dovetail).
$ ./iotest
Segmentation fault
$ dmesg
[Xenomai] switching iotest to secondary mode after exception #13 from
user-space at 0x400b8d (pid 14574)
traps: iotest[14574] general protection fault ip:400b8d
- Ursprüngliche Mail -
> Von: "Florian Bezdeka"
>> Where do you see a problem?
>
> I'm fine with the implementation. Just struggled with the wording /
> commit message. Sorry for the race in the mail thread...
No need to worry. :-)
Thanks,
//richard
- Ursprüngliche Mail -
> Von: "Florian Bezdeka"
> I agree, BITS_PER_LONG seems wrong. But couldn't it be too small as
> well? It depends on NR_CPUS which might be > BITS_PER_LONG.
Hmm, nr_cpumask_bits is defined as:
#ifdef CONFIG_CPUMASK_OFFSTACK
/* Assuming NR_CPUS is huge, a runtime
BITS_PER_LONG is too broad, the max number of usable bits is limited
by nr_cpumask_bits.
Found while debugging a system with CONFIG_DEBUG_PER_CPU_MAPS enabled.
Signed-off-by: Richard Weinberger
---
kernel/cobalt/sched.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
Philippe,
- Ursprüngliche Mail -
> Von: "Philippe Gerum"
>> I did some more experiments. The system was already autotuned.
>> But raising the base interval from 1000 (default) to 5000 made the issue
>> go away.
>>
>
> Does the issue persist at any freq when resetting the clock gravity
Philippe,
- Ursprüngliche Mail -
> Von: "Philippe Gerum"
> Florian pointed in the right direction when mentioning autotune: if the
> core timer is not calibrated properly, Cobalt might try to compensate
> for the basic latency of the platform too much, leading to early timer
> shots. If
Florian,
- Ursprüngliche Mail -
> Von: "Florian Bezdeka"
> An: "xenomai" , "richard"
> Gesendet: Freitag, 4. März 2022 13:01:08
> Betreff: Re: Questiion on commit: demo/cyclictest: fix time delta calculation
> Hi Richard,
>
> On Fri
Hello,
I'm investigating into a cyclictest issue where it reports negative values just
like this commit states:
https://source.denx.de/Xenomai/xenomai/-/commit/3069a7bbc48559f4d2a6184d6159b771f193a4e9
Since I'm on Xenomai 3.1.2 the said commit is already included.
But I have a hard time to
On Tue, Jul 20, 2021 at 3:56 PM Philippe Gerum wrote:
> > But maybe it can offer enough to implement signal delivery for exceptions?
> >
> > The signal approach also allows us to use the very same signal
> > handlers in userspace
> > for realtime as provided by Xenomai and PREEMPT_RT.
>
> You
On Tue, Jul 20, 2021 at 12:53 PM Jan Kiszka wrote:
> > I've heard that with dovetail Xenomai no longer sees exceptions.
> > So this is a set in stone concept?
>
> Xenomai can no longer declare exceptions resolved. It still sees them.
Understood.
> If we come up with a reasonable use case, I
On Tue, Jul 20, 2021 at 11:27 AM Jan Kiszka wrote:
> Then look at dovetail - ipipe will vanish. I'm pretty sure now your
> approach faces the same issue like we do /wrt not delivering fixed-up
> faults.
>
> If that is the case, we should first of all ensure that the foundation
> is provided by
On Mon, Jul 19, 2021 at 4:42 PM Jan Kiszka wrote:
> We have kind of a similar case in our backlog. The application expects
> to handle certain FPU-related faults gracefully, i.e. without falling
> out of RT with the causing thread, using a context update to bring it on
> the road again.
>
> We
On Thu, Jul 8, 2021 at 10:48 PM Jan Kiszka via Xenomai
wrote:
> The model chosen for this is dedicating a real-time thread to this task.
> This has the advantage of isolating the thread a bit from the debugged
> contexts and also avoids having to introduce any kind of asynchronous
> signaling
On Fri, Jul 9, 2021 at 12:05 AM Richard Weinberger
wrote:
> Hmm.
> I see cobalt_thread_harden() being called long before threadobj_init().
> cobalt_thread_trampoline() calls it too.
> Same for pthread_setschedparam_ex() if the task in question is main().
Correction: It is always
On Thu, Jul 8, 2021 at 2:51 PM Philippe Gerum wrote:
> > Then it needs to be understood what technically triggers this and
> > resolved, likely via an explicit migration.
> >
>
> Sure, good exercise for the reader to get ones feet wet with libalchemy.
> If somebody wants to tackle this: check
On Thu, Jul 8, 2021 at 11:54 AM Jan Kiszka wrote:
>
> On 08.07.21 11:51, Richard Weinberger wrote:
> > On Thu, Jul 8, 2021 at 11:25 AM Jan Kiszka wrote:
> >> The general philosophy of Xenomai is that applications should not rely
> >> on the exact switching behavior. So the question would be why
On Thu, Jul 8, 2021 at 11:25 AM Jan Kiszka wrote:
> The general philosophy of Xenomai is that applications should not rely
> on the exact switching behavior. So the question would be why your
> application needs one or the other behavior?
In this particular case the application uses the ioctl()
Hi!
An application I'm working on assumes that rt_task_shadow() with prio
being 0 returns in secondary mode. This seems to be the case on
Xenomai 2.6 but no longer on 3.1.
Is this a known/desired change?
--
Thanks,
//richard
Since 10.2 gcc it sets __ILP32__ even for i386.
To check for x32 we need to check for __x86_64__ being set too.
Signed-off-by: Richard Weinberger
---
While x32 is gone in master, 3.x stable still has it.
Without this patch it is not possible to build Xenomai for i386
with a recent gcc toolchain.
It is not obvious why cobalt_machine.prefault is needed
and why only for ARM.
One would expect that mlockall() would do it too.
Signed-off-by: Richard Weinberger
---
Note: I think we can make mach_arm_prefault() a no-op on arm64
if cpu_has_hw_af() returns true.
But I need to test it first. B-)
We proudly announce the co-hosted Alpine Linux Persistence and Storage
Summit (ALPSS) + Alpine Real Time Treffen (ART), which will be held
October 2nd to October 4th 2020 at the Lizumerhuette [1][2] in Austria.
This is a scaled down replacement event for ALPSS and The Realtime
Community summit,
- Ursprüngliche Mail -
>>> First of all, your driver is apparently not reacting on the close
>>> request that it receives in that case. This leads the the stall you see.
>>
>> Huh? rmmmod triggers close of what?
>> *confused*
>>
>
> rmmod -> module cleanup -> rtdm_dev_unregister ->
Hi!
I'm working on a kernel module which is used on plain Linux and
Xenomai (RTDM), while reviewing RTDM to understand refcounting I found
something that is not entirely clear to me.
Why does __rtdm_dev_open() not grab a reference on the RTDM module owner?
This leads to the case where one can
On Thu, Apr 16, 2020 at 4:08 PM 孙世龙 wrote:
>
> >> What puzzled me is that i could not locate the corresponding source
> >> code.
> >>
> >>For example.
> >> The log to locate the system call named as cobalt_sched_yield.
> > >$ grep -inr cobalt_sched_yield
>
> >Grep for
On Thu, Apr 16, 2020 at 2:45 PM 孙世龙 via Xenomai wrote:
>
> Could give me some guideline on how to locate the source code of
> the xenomai system calls.
>
> I confirm that there is corresponding binary file after compiling
> the source code which include xenomai and linux.You can see the
On Tue, Apr 14, 2020 at 1:02 PM Jan Kiszka wrote:
>
> On 14.04.20 12:56, Richard Weinberger wrote:
> > On Tue, Apr 14, 2020 at 12:44 PM Jan Kiszka wrote:
> >
> >>> While we are here, is there a guarantee that rt_task_unblock() can unblock
> >>> a thread in every situation?
> >>> I have a large
On Tue, Apr 14, 2020 at 12:44 PM Jan Kiszka wrote:
> > While we are here, is there a guarantee that rt_task_unblock() can unblock
> > a thread in every situation?
> > I have a large Xenomai 2 application on my desk which seems to assumes that.
>
> IIRC, it does so for the native/alchemy API.
>
>
On Tue, Apr 14, 2020 at 12:29 PM Jan Kiszka wrote:
> > This interrupts the Linux syscall, yes. Does this also work when the
> > thread blocks on the Xenomai/Cobalt side?
> >
>
> That ::read is a Xenomai syscall, being handled in the end by
> timerfd_read in the core. So, yes.
True that, once
1 - 100 of 148 matches
Mail list logo
