On 11.10.19 19:25, Rob Miller via Xenomai wrote:
Things were working well with my server but when I went to a VM, it fails
complaining about no high-res timers.
I figure it must be a CPU that I have chosen and am wondering what others
are using. I googled for quite a while but can't seem to
Things were working well with my server but when I went to a VM, it fails
complaining about no high-res timers.
I figure it must be a CPU that I have chosen and am wondering what others
are using. I googled for quite a while but can't seem to find any info so I
thought I would post here for some
On 10/8/19 7:52 PM, Jan Kiszka wrote:
> On 08.10.19 19:31, Philippe Gerum wrote:
>> On 10/8/19 5:25 PM, Jan Kiszka wrote:
>>> On 08.10.19 17:21, Jan Kiszka wrote:
Hi Philippe,
just a note, probably harmless (instrumentation issue), but it may
prevent debugging real issues.
On 11.10.19 11:05, Norbert Lange via Xenomai wrote:
Signed-off-by: Norbert Lange
---
testsuite/smokey/gdb/gdb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/testsuite/smokey/gdb/gdb.c b/testsuite/smokey/gdb/gdb.c
index 33c16fe87..4f39f3f6c 100644
---
From: Jan Kiszka
Fixes module usage.
Reported-by: Lange Norbert
Signed-off-by: Jan Kiszka
---
kernel/drivers/testing/heapcheck.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/drivers/testing/heapcheck.c
b/kernel/drivers/testing/heapcheck.c
index 447cc13fec..4eb6a5aae2 100644
Hello,
I built the xeno_*test components as loadable modules, but it seems
xeno_heapcheck is either broken or can’t be built as module?
Version is Xenomai v3.1-rc2
~# modprobe xeno_rtdmtest
~# modprobe xeno_heapcheck
[57980.549627] xeno_heapcheck: Unknown symbol xnthread_relax (err -2)
Jan,
On Fri, Oct 11, 2019 at 8:50 AM Jan Kiszka wrote:
> > if (likely(p->coflags & __IPIPE_TRAP_E)) {
> > p->coflags |= __IPIPE_TRAP_R;
> > hard_local_irq_restore(flags);
> > data.exception = exception;
> > data.regs =
On 10.10.19 22:37, Richard Weinberger via Xenomai wrote:
I'm pretty sure I miss something obvious,but let's try.. :-)
Documentation/ipipe.rst says:
The notification is issued by a call to :c:func:`__ipipe_notify_trap`
which in turn invokes the :c:func:`ipipe_trap_hook` routine the
real-time
