On 05.11.18 12:06, Petr Červenka via Xenomai wrote:
Hello.
I'm continuing to test newest Xenomai (git clone).
If I configure Xenomai without --enable-pshared, I will always get an
segmentation error 6 in rt_heap_create() call. It doesn't matter, if I use NULL
as heap name or not.
With
The mayday mechanism exists in order to kick a xenomai userspace task
into secondary mode while it is running userspace code. For that, we ask
I-pipe to call us back when the task was interrupted and is about to
return to userspace.
So far we defer the relaxation from that callback via a
On 05.11.18 14:48, Steven Seeger wrote:
> On Monday, November 5, 2018 7:20:33 AM EST Jan Kiszka wrote:
>>
>> I would appreciate if you could test ARM64 and PowerPC for me. Until we
>> have QEMU test images for both, it's still tricky for me to do that.
>
> I have something I've got to get done
On 05.11.18 14:31, Petr Červenka wrote:
>>
>> stable or master (or both)?
> >
> > Jan
> >
>
> master
>
Only? Sorry for insisting, but it may help to reduce the search space, and it's
also important as I'd like to release a new stable version - without known
issues.
Thanks,
Jan
--
On 05.11.18 14:03, Mauro Salvini via Xenomai wrote:
make cast explicit to avoid warning when user code is compiled with
-Wconversion
Signed-off-by: Mauro Salvini
---
include/copperplate/clockobj.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On 02.11.18 11:07, Henning Schild via Xenomai wrote:
Am Thu, 1 Nov 2018 18:38:47 +0100
schrieb Philippe Gerum :
On 11/1/18 5:59 PM, Petr Červenka wrote:
Hello.
Is it really finished?
I have problems to compile the patched kernel.
At first, when it compiles machine.c, there is such
On 02.11.18 14:20, Petr Červenka via Xenomai wrote:
You are right.
The errors were because of version 3.0.7. I didn't realize, that
prepare-kernel.sh script doesn't only apply the patch. But it also copies part
of the xenomai to the kernel.
Meanwhile I tried the latest git (probably master
Hi all,
I think it would be good to release a new stable version, now that we have
updated x86 I-pipe patches that require changes from it. I'm currently only
aware of one open issue affecting also stable, and that's [1]. I think we should
resolve that prior to the release. If there is more,
On 02.11.18 17:19, Christoph Müllner wrote:
Hi Jan,
I was wondering if there are any plans for a Xenomai release,
which includes arm64.
Yes, there are. The exact timeline is not settled yet, but somewhere within the
next month, I would say.
I'm familiar with the next branch, but I'd love
On 02.11.18 17:21, Sebastian Smolorz wrote:
Hi Jan,
Jan Kiszka wrote:
Hi all,
I think it would be good to release a new stable version, now that we
have updated x86 I-pipe patches that require changes from it. I'm
currently only aware of one open issue affecting also stable, and
that's [1].
Hard to find a UP target these days, and we definitely want to be
generic with Debian packages.
Signed-off-by: Jan Kiszka
---
debian/rules | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/debian/rules b/debian/rules
index 99ed8982ce..883ae3ed8c 100755
--- a/debian/rules
+++
Hi all,
as I was (and still am) in the need to test also non-x86 from time to time, I
hacked up a little framework for generating bootable Debian images with Xenomai
pre-installed. It's currently hosted on my personal github space:
https://github.com/jan-kiszka/xenomai-images
I think we should
On 06.11.18 11:00, Sebastian Smolorz via Xenomai wrote:
> A bug in rt_tcp_recvmsg() prevented an application to receive data
> over an RTTCP socket. Data was not copied back to the application's
> buffer but rather into a temporary kernel buffer.
>
> Signed-off-by: Sebastian Smolorz
> ---
>
On 30.11.17 12:27, Leopold Palomo-Avellaneda wrote:
> Hi,
>
>
> if someone is interested I have been working a bit with the debian directory
> in
> xenomai3.
>
> I have changed the approach to the libraries. I think that now it has not
> sense
> to have a libxenomai1 so I have changed it to
On 05.11.18 16:48, Petr Červenka wrote:
>> Only? Sorry for insisting, but it may help to reduce the search space, and
>> it's
>> also important as I'd like to release a new stable version - without known
>> issues.
> >
>> Thanks,
>> Jan
> >
>
> I can confirm now, that the problem happens
On 08.11.18 14:05, Philippe Gerum wrote:
On 11/5/18 1:20 PM, Jan Kiszka wrote:
The mayday mechanism exists in order to kick a xenomai userspace task
into secondary mode while it is running userspace code. For that, we ask
I-pipe to call us back when the task was interrupted and is about to
On 08.11.18 13:42, Henning Schild via Xenomai wrote:
xeno-test-run always returned SUCCESS, even if its children exited with
non zero. So xeno-test can not be used programmatically i.e. in CI.
This patch adds some more verbosity and makes xeno-test-run exit FAILURE
if at least one child
On 06.11.18 11:00, Sebastian Smolorz via Xenomai wrote:
This patch series makes RTnet's tcp module usable again. It was not
working due to several bugs which showed up in combination with reworked
RTDM of Xenomai 3.
Tests on real hardware (little endian) were successful. A test on big
endian is
Signed-off-by: Jan Kiszka
---
debian/control | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/debian/control b/debian/control
index 3427987e15..477b16d9fd 100644
--- a/debian/control
+++ b/debian/control
@@ -8,7 +8,7 @@ Homepage: http://www.xenomai.org/
Package:
On 09.11.18 10:14, Henning Schild via Xenomai wrote:
The test often asserted. This patch gives the thread a priority,
introduces a 25us margin and prints the value in case we still fail.
Signed-off-by: Henning Schild
---
testsuite/smokey/posix-clock/posix-clock.c | 15 ++-
1
On 08.11.18 12:08, Fazio Maurizio via Xenomai wrote:
Hello,
i'm trying to integrate some software written in ADA language. I compiled it
using gnatmake and i created an archive using ar. The archive is linked in my
xenomai application.
Is there some problems in using the libgnat with
On 14.11.18 11:41, Philippe Gerum wrote:
Signed-off-by: Philippe Gerum
---
lib/vxworks/memPartLib.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/lib/vxworks/memPartLib.c b/lib/vxworks/memPartLib.c
index 22d77bdcf..c8eeb3617 100644
---
On 16.11.18 09:14, Per Oberg via Xenomai wrote:
Hi everyone
I'm confused over the xeno-config use of DESTDIR and cross-compiling. In the
documentation (1) it is claimed that it follows the GNU coding standards.
Snippet:
"If DESTDIR was set when installing Xenomai - typically after
On 07.11.18 11:04, Philippe Gerum wrote:
> On 11/6/18 7:57 PM, Jan Kiszka wrote:
>> On 04.11.18 17:17, Philippe Gerum wrote:
>>> On 6/21/18 4:57 PM, Jan Kiszka wrote:
On 2018-06-21 15:41, Jan Kiszka wrote:
> On 2018-06-21 13:55, Jan Kiszka wrote:
>> On 2018-06-21 13:20, Pintu Kumar
On 07.11.18 11:31, Philippe Gerum wrote:
> On 11/7/18 11:19 AM, Jan Kiszka wrote:
>> On 07.11.18 11:04, Philippe Gerum wrote:
>>> Would be nice. How would that cope with rt_ip_build_xmit_slow() in case
>>> the packet size exceeds the MTU? AFAICT, the header and payload data are
>>> sent over the
On 07.11.18 07:15, Manikanta Mylavarapu via Xenomai wrote:
> Dear all,
>
> I am trying to run 32bit applications on 64bit xenomai. I installed xenomai
> 2.6.0 on fedora 13 x86_64. I installed all 32bit GCC lib & c librarys
> (glibc-devel.i686 & going.i686).
>
> I made one hello world sample
ch QEMU target would be best to start with (as many of us
> will likely not have any board in reach). But I do want this see this working
> as
> well.
>
> Jan
>
> [1] https://groups.google.com/forum/#!topic/isar-users/AvDmjp2z9Zo
>
>> -Greg
>>
>> On Tue
On 24.12.18 11:06, Philippe Gerum via Xenomai wrote:
On 12/23/18 10:34 PM, Alec Ari via Xenomai wrote:
Hello,
I'm not sure if the patch generator was believed to be fixed yet or not, but
files for other arches (arch/arm/include/asm/arch_timer.h) are still included.
If this still being
On 18.01.19 12:58, Philippe Gerum via Xenomai wrote:
On 1/17/19 1:56 PM, Philippe Gerum wrote:
On 12/18/18 7:46 AM, Jan Kiszka via Xenomai wrote:
On 14.12.18 12:22, Jan Kiszka via Xenomai wrote:
Do not add rtskbs to the rtskb_list which are not mappend because
rtdev_unmap_rtskb
On 15.01.19 15:23, Josef Holzmayr wrote:
Hi Jan,
On Mon, Jan 14, 2019 at 04:12:32PM +0100, Jan Kiszka via Xenomai wrote:
An overdue stable release has just been completed.
Do you see any value in a test cycle comparable to the CIP kernel on the BBB?
If your other test was using master
On 14.01.19 18:35, Philippe Gerum wrote:
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
On 14.01.19 18:35, Philippe Gerum wrote:
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.
Is there an out-of-tree use case for that
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
On 15.01.19 19:06, Philippe Gerum wrote:
On 1/15/19 6:14 PM, Jan Kiszka wrote:
On 14.01.19 18:35, Philippe Gerum wrote:
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.
On 14.12.18 12:22, Jan Kiszka via Xenomai wrote:
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
On 19.12.18 19:26, Auel, Kendall via Xenomai wrote:
Jan,
I'm very much in favor of providing a way to prevent Xenomai modules from using
features which can result in deadlock, if there is a clean way to detect such a
situation.
We used gettimeofday in one of our modules and it mostly worked
On 20.12.18 13:29, Lange Norbert via Xenomai wrote:
On 19.12.18 19:26, Auel, Kendall via Xenomai wrote:
Jan,
I'm very much in favor of providing a way to prevent Xenomai modules
from using features which can result in deadlock, if there is a clean way to
detect such a situation.
We used
Hi all,
just a quick note that I started a 4.4-cip based I-pipe tree:
https://gitlab.denx.de/Xenomai/ipipe/tree/ipipe-4.4.y-cip
So far it's just a merge of ipipe-4.4.y @ipipe-core-4.4.166-x86-12 with the CIP
tree @4.4.166-cip29. I'm not yet sure whether to switch 4.4 completely to -cip
or
On 19.11.18 14:52, Henning Schild wrote:
Am Mon, 19 Nov 2018 10:52:34 +0100
schrieb Philippe Gerum :
On 11/19/18 10:40 AM, Henning Schild wrote:
Am Fri, 16 Nov 2018 07:23:47 +0100
schrieb Jan Kiszka :
On 09.11.18 10:14, Henning Schild via Xenomai wrote:
The test often asserted. This
On 21.12.18 14:44, Henning Schild via Xenomai wrote:
From: Henning Schild
We should mark the current task as not owning the fpu anymore if it does
actually own the fpu, not if the fpu itself is active.
Fixes cb52e6c7438fa
Reported-by: Mauro Salvini
Signed-off-by: Henning Schild
---
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
---
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
This drops the naming of each release, lowering the creative effort for
the release manager and, thus, potentially raising the motivation to
release more often.
Signed-off-by: Jan Kiszka
---
I'm inclined to backport this to stable as well because I strongly
suspect that no one outside of the
This encodes
- updating version-code/label
- committing the changes
- tagging the result
Signed-off-by: Jan Kiszka
---
scripts/make-release.sh | 35 +++
1 file changed, 35 insertions(+)
create mode 100755 scripts/make-release.sh
diff --git
On 20.12.18 09:59, duanwujie wrote:
Hi, Phi and Jan:
The correct handler is handle_percpu_irq !
Hi, Phi and Jan:
I try to port the ipipe to mips arch according the
https://gitlab.denx.de/Xenomai/xenomai/wikis/Porting_Xenomai_To_A_New_Arm_SOC#terminology
Now it
On 20.12.18 09:28, Mauro Salvini via Xenomai wrote:
Hi all,
I'm testing Xenomai 3 on an Intel Braswell board (Atom x5-E8000).
I'm using ipipe kernel at last commit from [1], branch ipipe-4.9.y,
64bit build on a Debian Stretch 9.6 64bit.
Xenomai library is from [2], branch stable/v3.0.x on
On 13.12.18 17:21, Jan Kiszka wrote:
On 13.12.18 10:55, Pintu Agarwal wrote:
On Tue, Dec 4, 2018 at 10:30 PM Jan Kiszka via Xenomai
wrote:
On 31.10.18 18:10, Philippe Gerum wrote:
On 10/30/18 11:28 AM, Jan Kiszka wrote:
Hi all,
just testing new kernels with smokey, and one of them had
On 13.12.18 10:55, Pintu Agarwal wrote:
On Tue, Dec 4, 2018 at 10:30 PM Jan Kiszka via Xenomai
wrote:
On 31.10.18 18:10, Philippe Gerum wrote:
On 10/30/18 11:28 AM, Jan Kiszka wrote:
Hi all,
just testing new kernels with smokey, and one of them had RTnet on. This
triggered a bug
On 28.11.18 09:58, Philippe Gerum wrote:
On 11/28/18 7:56 AM, Jan Kiszka wrote:
On 27.11.18 19:54, Philippe Gerum wrote:
On 11/27/18 6:44 PM, Jan Kiszka wrote:
On 08.11.18 14:24, Philippe Gerum wrote:
On 11/8/18 2:14 PM, Jan Kiszka wrote:
On 08.11.18 14:05, Philippe Gerum wrote:
On 11/5/18
On 28.11.18 10:05, Henning Schild wrote:
Am Fri, 16 Nov 2018 07:28:51 +0100
schrieb Jan Kiszka :
On 08.11.18 13:42, Henning Schild via Xenomai wrote:
xeno-test-run always returned SUCCESS, even if its children exited
with non zero. So xeno-test can not be used programmatically i.e.
in CI.
This I-pipe hook reports the desired resumption mode to the subscriber:
resume all process tasks or just single-step a particular one? The use
case is to enable synchronous stopping / resuming of all head tasks of
a ptraced real-time process.
Signed-off-by: Jan Kiszka
---
This adds the x86-specific bits to implement the userspace return
notifier.
Signed-off-by: Jan Kiszka
---
arch/x86/entry/common.c| 12
arch/x86/include/asm/thread_info.h | 2 ++
2 files changed, 14 insertions(+)
diff --git a/arch/x86/entry/common.c
Grr, I forgot the
From: Jan Kiszka
in all I-pipe patches. Please adjust that before applying to avoid that the
wrong author (the list) is recorded.
On 30.11.18 21:07, Jan Kiszka via Xenomai wrote:
A little bit inspired by the kernel's user return notifier, this
introduces an I-pipe hook
From: Jan Kiszka
Add a test case for advanced gdb-based debugging of real-time processes.
It currently checks three aspects:
- Do we resume an RT thread in primary mode after hitting a breakpoint
in that mode?
- Do we stop all RT threads immediately when one process thread hits a
From: Jan Kiszka
Track threads on a per-process basis again to make walking through them
cheaper.
Signed-off-by: Jan Kiszka
---
kernel/cobalt/posix/process.c | 3 ++-
kernel/cobalt/posix/process.h | 3 ++-
kernel/cobalt/posix/thread.c | 4 +++-
kernel/cobalt/posix/thread.h | 2 +-
4 files
These patches are sticking in my queue for more than 3 years now which
is bad. The good thing is that they were able to mature, at least on
x86, over that time because we are actually using them.
Two issues are addressed with these changes:
1. Ensure that threads that were stopped for debugging
From: Jan Kiszka
If a task relaxes on its own, before processing a mayday request, clear
this request to avoid redundant calls of the machinery. This is
particularly important for ensuring XNCONTHI works as expected after
ptrace resumption.
Signed-off-by: Jan Kiszka
---
kernel/cobalt/thread.c
On 30.11.18 21:09, Jan Kiszka via Xenomai wrote:
Something moved the value of this constant but didn't update the
hard-coded instances. Fix this and avoid future problems by using the
proper symbolic value.
That just requires harding asm/ipipe_base.h for assembly use.
Signed-off-by: Jan Kiszka
From: Jan Kiszka
When a thread in primary mode currently hits a breakpoint, it will
immediately be relaxed, leaving space for other runnable RT threads of
the process to take over. This can delay gdb to finally take control and
stop the whole process.
To prevent this unexpected and often
From: Jan Kiszka
Given that registration can run asynchronously to deregistration, better
put testing for XNSSTEP and the latter under nklock. This is likely
overkill for task termination but it's more consistent.
While at it, move up the functions and add a cobalt_ prefix. We will
need them
From: Jan Kiszka
When a thread is stopped in primary mode for debugging, make sure it
will migrate back before resuming in user space. This is a building
block for making real-time process debugging more deterministic.
The information if a thread should resume in primary is transported via
a
From: Jan Kiszka
This Introduces an additional blocking state for threads. It is used to
hold back threads after resumption by the debugger in primary mode for
coordinated continuation.
Signed-off-by: Jan Kiszka
---
include/cobalt/kernel/thread.h | 2 +-
CONFIG_DEBUG_SECTION_MISMATCH=y reports:
The function dw_apb_clocksource_register() references
the function __init __ipipe_tsc_register().
Signed-off-by: Jan Kiszka
---
arch/arm/kernel/ipipe_tsc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/kernel/ipipe_tsc.c
Something moved the value of this constant but didn't update the
hard-coded instances. Fix this and avoid future problems by using the
proper symbolic value.
That just requires harding asm/ipipe_base.h for assembly use.
Signed-off-by: Jan Kiszka
---
arch/arm/include/asm/ipipe_base.h | 6 ++
On 05.12.18 10:32, Johannes Holtz wrote:
Am 04.12.18 um 14:46 schrieb Jan Kiszka:
On 04.12.18 12:04, Johannes Holtz via Xenomai wrote:
Hello,
When I request a socket with AF_RTIPC I get an EAFNOSUPPORT in return.
int sock = socket(AF_RTIPC, SOCK_DGRAM, IPCPROTO_IDDP);
You likely didn't
On 04.12.18 12:04, Johannes Holtz via Xenomai wrote:
Hello,
When I request a socket with AF_RTIPC I get an EAFNOSUPPORT in return.
int sock = socket(AF_RTIPC, SOCK_DGRAM, IPCPROTO_IDDP);
You likely didn't wrap this posix application to link against the Xenomai libs,
rather than normal libc.
On 04.12.18 12:40, Evandro Sestrem via Xenomai wrote:
Hello,
Is it possible to use CMake to compile a Xenomai program?
I want to use Xenomai in a ROS 2 node. To do this, I need to be able to
compile it with CMake.
I'm trying to compile a HelloWorld Xenomai program using CMake.
I put this
On 04.12.18 18:21, Lange Norbert wrote:
-Original Message-
From: Jan Kiszka
Sent: Dienstag, 4. Dezember 2018 17:30
To: Lange Norbert
Cc: Xenomai ; Philippe Gerum
Subject: Re: improve and provide a header for bootstrapping
E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE,
On 04.12.18 16:53, Lange Norbert wrote:
So any update on this.
Do you have something similar to patchwork to keep up on those loose
email-threads?
This was less a patch tracking issue than the missing decision how to address
the topic.
On the one hand, I see a desire to control
On 04.12.18 16:51, Lange Norbert via Xenomai wrote:
To close this up,
is there anything expected from my side? I am not able to fix up the kernel
side, esp. with the x32 API,
and my disagreement with long vs void*/uintptr_t likely won't end up getting us
anywhere.
The chosen userspace type
On 05.12.18 16:29, Philippe Gerum wrote:
In order to prevent unexpected truncation of pointer args in userland
with the LP64 data model, libcobalt's fcntl() wrapper should accept a
long (3rd) argument.
Anticipate this change in the corresponding syscall implementation in
the Cobalt core. The
This adds the arm-specific bits to implement the userspace return
notifier.
Signed-off-by: Jan Kiszka
---
arch/arm/include/asm/thread_info.h | 2 ++
arch/arm/kernel/entry-common.S | 17 +
2 files changed, 19 insertions(+)
diff --git a/arch/arm/include/asm/thread_info.h
On 05.12.18 16:29, Philippe Gerum wrote:
In order to prevent unexpected truncation of pointer args in userland
with the LP64 data model, libcobalt's fcntl() wrapper should accept a
long (3rd) argument.
Anticipate this change in the corresponding syscall implementation in
the Cobalt core. The
On 05.12.18 16:25, Philippe Gerum wrote:
Signed-off-by: Philippe Gerum
---
drivers/scsi/scsi_devinfo_tbl.c | 25 -
1 file changed, 25 deletions(-)
delete mode 100644 drivers/scsi/scsi_devinfo_tbl.c
diff --git a/drivers/scsi/scsi_devinfo_tbl.c
On 05.12.18 16:24, Philippe Gerum wrote:
On 11/4/18 11:52 AM, Philippe Gerum via Xenomai wrote:
On 11/2/18 9:22 AM, Jan Kiszka wrote:
On 02.11.18 04:34, Alec Ari wrote:
This isn't just for x86, this patch includes ppc and arm64 as well. I
was wondering why it was so big! Same story on the
On 06.12.18 06:45, limingyu via Xenomai wrote:
I have used this patch(ipipe-core-4.9.135-x86-7.patch) for a test usage and I
got a machine halt after I run the latency test program of Xenomai.The problem
seems caused by the fpu_restore function. Could you please fix it in the next
patch
On 06.12.18 08:04, duanwujie wrote:
It seem to forget port the arch/x86/include/asm/fpu/internal.h in the
ipipe-core-4.9.135-x86-7.patch
You mean that file is missing in the generated patch?
Jan
在 2018/12/6 下午3:00, Jan Kiszka via Xenomai 写道:
On 06.12.18 06:45, limingyu via Xenomai wrote
On 06.12.18 08:24, duanwujie wrote:
We use the xenomai 3.0.7 stable version. Is okay for this ?
No, as I said. You need the latest stable/3.0.x branch because you need
adjustments to the FPU changes.
Jan
在 2018/12/6 下午3:21, Jan Kiszka 写道:
On 06.12.18 08:18, duanwujie wrote:
I am not so
On 06.12.18 08:18, duanwujie wrote:
I am not so sure, bellow code exist in ipipe-core-4.9.51-x86-2.patch but
ipipe-core-4.9.135-x86-7.patch didn't。
arch/x86/include/asm/fpu/internal.h:
#ifdef CONFIG_IPIPE
static inline union fpregs_state *active_fpstate(struct fpu *fpu)
{
return
On 06.12.18 08:42, duanwujie wrote:
Okay we will try and do other's test! thank you!
Could you do me a favor and check if your patched kernel tree (without Xenomai
preparation) is identical to the corresponding git tree on gitlab.denx.de?
If so, we would then need your kernel config and
On 06.12.18 13:22, limingyu via Xenomai wrote:
Sorry, Jan, I have rechecked the patched kernel tree and found that I forgot to
patch the Xenomai(stable/v3.0.x branch) to the kernel source, that's just the
reason why I meet the problem. I repatched the kernel and everything works fine
now.
On 10.12.18 10:51, duanwujie wrote:
/Hi Philippe and Jan, I want to test //mayday mechanism,but we can't find any smoke test case about it.where can i
find it? /
The sigdebug test in smokey stresses that path. It makes the watchdog fire by
running an RT thread in a userspace-only loop.
On 29.11.18 09:03, 梁权 via Xenomai wrote:
> hi，
> i'm work on a customed board with TI am335X; i have installed xenomai 3 on it
> correcttly , and can run the latency test.
> On this board, an interrupt which cannot be masked and delayed will be
> generated every millicsecond by a FPGA ;
> to
On 29.11.18 16:15, 梁权 wrote:
The linux 4.14.67 which i used is from the latest TI Linux Processor SDK for
AM335x; when i patch it with the /ipipe-core-4.14.71-arm-4.patch，/
i did not need to do any change except that telling where the file dmtimer.c
is;
i guess it is because that in linux
On 29.11.18 14:54, Philippe Gerum wrote:
We need policy-specific scheduling parameters to be checked early and
unconditionally before applying them in xnsched_setparam(), even if
the current scheduling policy does not change for the target thread
(i.e. sched_declare() is not called).
Hi Sepp,
On 23.11.18 13:27, Josef Holzmayr via Xenomai wrote:
Hello!
To improve the testing situation for the 4.4 Kernel family on ARM32, I
created a set of layers [1] for OpenEmbedded. Currently the features are
rather limited:
- only the Morty branch exists, as this one natively includes
From: Giulio Moro
This is to avoid namespace conflicts (e.g.: with Clang's arm_acle.h)
Signed-off-by: Giulio Moro
[Jan: back-ported to 3.0.x]
Signed-off-by: Jan Kiszka
---
include/boilerplate/compiler.h| 2 +-
lib/copperplate/heapobj-pshared.c | 3 ++-
2 files changed, 3 insertions(+), 2
From: Jan Kiszka
Refer to Xenomai upstream for community and contribution. Add a
top-level COPYING with the MIT license and explain the licensing scheme
also in the README.
Signed-off-by: Jan Kiszka
---
COPYING | 17 +
README.md | 21 +++--
2 files changed,
From: Jan Kiszka
This allows to drop the local patch, requires to set uid:gid on chroot
and set LAYERSERIES_COMPAT_xenomai.
Signed-off-by: Jan Kiszka
---
conf/layer.conf| 2 ++
...m-Update-isar-apt-prior-to-installing-bui.patch | 38 --
From: Jan Kiszka
By now merged even into master.
Signed-off-by: Jan Kiszka
---
...dd-config-folder-to-xenomai-kernel-source.patch | 28 --
...2-debian-Add-arm64-as-target-architecture.patch | 44 --
...03-debian-Enable-SMP-in-userspace-package.patch | 30
See patches for details.
Jan Kiszka (3):
xenomai: Remove patches
Update to latest Isar next
Improve README, add COPYING
COPYING| 17 +
README.md | 21 ++-
conf/layer.conf
On 23.11.18 16:04, Philippe Gerum wrote:
On 11/23/18 12:41 PM, Jan Kiszka wrote:
On 23.11.18 12:29, Philippe Gerum wrote:
On 11/23/18 12:26 PM, Philippe Gerum via Xenomai wrote:
On 11/23/18 12:11 PM, Jan Kiszka wrote:
On 23.11.18 11:56, Philippe Gerum wrote:
On 11/22/18 6:57 PM, Jan Kiszka
On 22.11.18 13:41, Giulio Moro via Xenomai wrote:
From 398a77d3d172c10cda9826a7cc2a15266ff4c6a9 Mon Sep 17 00:00:00 2001
From: Giulio Moro
Date: Sat, 10 Nov 2018 20:23:10 +
Subject: [PATCH] Rename __clz to xenomai_count_leading_zeros.
This is to avoid namespace conflicts (e.g.: with
On 23.11.18 18:03, Philippe Gerum wrote:
On 11/23/18 12:41 PM, Jan Kiszka wrote:
On 23.11.18 12:29, Philippe Gerum wrote:
On 11/23/18 12:26 PM, Philippe Gerum via Xenomai wrote:
On 11/23/18 12:11 PM, Jan Kiszka wrote:
On 23.11.18 11:56, Philippe Gerum wrote:
On 11/22/18 6:57 PM, Jan Kiszka
Copy mistake, plus outdated path structure by now.
Signed-off-by: Jan Kiszka
---
README.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/README.md b/README.md
index 44d056d..f7efbe4 100644
--- a/README.md
+++ b/README.md
@@ -33,7 +33,7 @@ installed.
Physical targets will
This allows to drop the local patch, requires to set uid:gid on chroot
and set LAYERSERIES_COMPAT_xenomai. Also, image deployment paths
changed.
Signed-off-by: Jan Kiszka
---
Changes in v2:
- also account for image deployment patch change
That means: It's now even tested, at least
On 23.11.18 12:29, Philippe Gerum wrote:
On 11/23/18 12:26 PM, Philippe Gerum via Xenomai wrote:
On 11/23/18 12:11 PM, Jan Kiszka wrote:
On 23.11.18 11:56, Philippe Gerum wrote:
On 11/22/18 6:57 PM, Jan Kiszka via Xenomai wrote:
This allows to remove the user-triggerable XENO_BUG from
On 22.11.18 21:43, Josef Holzmayr wrote:
If DISPLAY is not set and therefore the SDL-based
GUI of QEMU is most likely to fail, we resort to the
-nographic variant.
Signed-off-by: Josef Holzmayr
---
start-qemu.sh | 4
1 file changed, 4 insertions(+)
diff --git a/start-qemu.sh
On 23.11.18 11:56, Philippe Gerum wrote:
On 11/22/18 6:57 PM, Jan Kiszka via Xenomai wrote:
This allows to remove the user-triggerable XENO_BUG from
xnsched_quota_setparam().
Could you elaborate on the user trigger point you detected in the code?
pthread_setschedparam_ex(pthread_self
1 - 100 of 2528 matches
Mail list logo
