On 26.10.20 10:22, Jan Kiszka via Xenomai wrote:
> On 26.10.20 10:21, Q. Gylstorff wrote:
>> From: Quirin Gylstorff
>>
>> Add the variable CCACHE_DIR to the build to move the ccache from ~/.ccache
>> to the current directory and upload the cache from each build.
>
On 26.10.20 10:21, Q. Gylstorff wrote:
> From: Quirin Gylstorff
>
> Add the variable CCACHE_DIR to the build to move the ccache from ~/.ccache
> to the current directory and upload the cache from each build.
>
> Each job uses a separate cache.
>
> Signed-off-by: Quirin Gylstorff
> ---
>
>
On 26.10.20 10:15, Fino Meng wrote:
> On Mon, Oct 26, 2020 at 09:38:34AM +0100, Jan Kiszka wrote:
>> On 26.10.20 09:26, Fino Meng wrote:
>>> On Mon, Oct 26, 2020 at 09:20:20AM +0100, Jan Kiszka wrote:
On 26.10.20 09:12, Fino Meng wrote:
> On Mon, Oct 26, 2020 at 08:35:10AM +0100, Jan
On 26.10.20 09:26, Fino Meng wrote:
> On Mon, Oct 26, 2020 at 09:20:20AM +0100, Jan Kiszka wrote:
>> On 26.10.20 09:12, Fino Meng wrote:
>>> On Mon, Oct 26, 2020 at 08:35:10AM +0100, Jan Kiszka wrote:
On 23.10.20 11:04, Fino Meng wrote:
> be aware of RTNET and RTIPC part still have
On 26.10.20 09:20, Jan Kiszka via Xenomai wrote:
> On 26.10.20 09:12, Fino Meng wrote:
>> On Mon, Oct 26, 2020 at 08:35:10AM +0100, Jan Kiszka wrote:
>>> On 23.10.20 11:04, Fino Meng wrote:
>>>> be aware of RTNET and RTIPC part still have compile error, I didn't
&
On 26.10.20 09:12, Fino Meng wrote:
> On Mon, Oct 26, 2020 at 08:35:10AM +0100, Jan Kiszka wrote:
>> On 23.10.20 11:04, Fino Meng wrote:
>>> be aware of RTNET and RTIPC part still have compile error, I didn't
>>> enable them in .config yet. hope can fix them next week.
>>
>> Do you have patches
Hi all,
a brief update on the porting status to 5.4:
- new noarch ipipe/master is ready:
https://gitlab.denx.de/Xenomai/ipipe-noarch/-/commits/ipipe/master
I've regenerated the queue from Fino's work, reviewing conflict
resolutions once again. No issues found, well done! I've only done a
On 23.10.20 11:04, Fino Meng wrote:
> be aware of RTNET and RTIPC part still have compile error, I didn't
> enable them in .config yet. hope can fix them next week.
Do you have patches for RTnet and Analogy already? RTIPC is fixed in
next. I'm currently trying to get CI fully running.
Jan
--
On 23.10.20 16:02, Philippe Gerum wrote:
>
> Jan Kiszka writes:
>
>> On 23.10.20 14:29, Philippe Gerum wrote:
>>>
>>> Jan Kiszka writes:
>>>
Hi Philippe,
a merge conflict in 5.4-stable requires me to look into [1]. It states:
> Revisit: Further COW breaking in
On 23.10.20 14:29, Philippe Gerum wrote:
>
> Jan Kiszka writes:
>
>> Hi Philippe,
>>
>> a merge conflict in 5.4-stable requires me to look into [1]. It states:
>>
>>> Revisit: Further COW breaking in copy_user_page() and copy_pte_range()
>>> may be useless once
On Thu, Oct 22, 2020 at 09:26:59AM +0200, Jan Kiszka wrote:
>>>>>> On 22.10.20 08:27, Jan Kiszka via Xenomai wrote:
>>>>>>> On 21.10.20 13:43, Fino Meng wrote:
>>>>>>>> On Wed, Oct 21, 2020 at 08:36:04AM +0200, Jan Kiszka wro
Hi Philippe,
a merge conflict in 5.4-stable requires me to look into [1]. It states:
> Revisit: Further COW breaking in copy_user_page() and copy_pte_range()
> may be useless once __ipipe_disable_ondemand_mappings() has run for a
> co-kernel task, since all of its mappings have been
On 22.10.20 17:22, Jan Kiszka via Xenomai wrote:
> On 22.10.20 15:25, Fino Meng wrote:
>> On Thu, Oct 22, 2020 at 02:15:23PM +0200, Jan Kiszka wrote:
>>> On 22.10.20 13:49, Fino Meng wrote:
>>>> On Thu, Oct 22, 2020 at 09:26:59AM +0200, Jan Kiszka wrote:
>>&
On 22.10.20 15:25, Fino Meng wrote:
> On Thu, Oct 22, 2020 at 02:15:23PM +0200, Jan Kiszka wrote:
>> On 22.10.20 13:49, Fino Meng wrote:
>>> On Thu, Oct 22, 2020 at 09:26:59AM +0200, Jan Kiszka wrote:
>>>> On 22.10.20 08:27, Jan Kiszka via Xenomai wrote:
>>&g
On 22.10.20 13:49, Fino Meng wrote:
> On Thu, Oct 22, 2020 at 09:26:59AM +0200, Jan Kiszka wrote:
>> On 22.10.20 08:27, Jan Kiszka via Xenomai wrote:
>>> On 21.10.20 13:43, Fino Meng wrote:
>>>> On Wed, Oct 21, 2020 at 08:36:04AM +0200, Jan Kiszka wrote:
>>&
On 22.10.20 08:27, Jan Kiszka via Xenomai wrote:
> On 21.10.20 13:43, Fino Meng wrote:
>> On Wed, Oct 21, 2020 at 08:36:04AM +0200, Jan Kiszka wrote:
>>> On 18.10.20 23:41, Jan Kiszka via Xenomai wrote:
>>>> On 16.10.20 05:36, Fino Meng wrote:
>>>>>
On 21.10.20 13:43, Fino Meng wrote:
> On Wed, Oct 21, 2020 at 08:36:04AM +0200, Jan Kiszka wrote:
>> On 18.10.20 23:41, Jan Kiszka via Xenomai wrote:
>>> On 16.10.20 05:36, Fino Meng wrote:
>>>> On Thu, Oct 15, 2020 at 04:20:11PM +0200, Jan Kiszka wrote:
>>&g
On 20.10.20 10:10, chensong wrote:
Hi Jan;
i talked to arnd Bergmann about how to build a 32bit 2038-safe process,
he told me that neither gcc nor glibc can fully support 64bit timespec
yet, he suggested me to use musl(https://wiki.musl-libc.org/), and he
also suggested me to use kernel5.4.
On 18.10.20 23:41, Jan Kiszka via Xenomai wrote:
> On 16.10.20 05:36, Fino Meng wrote:
>> On Thu, Oct 15, 2020 at 04:20:11PM +0200, Jan Kiszka wrote:
>>> On 14.10.20 15:25, Fino Meng wrote:
>>>> hi team,
>>>>
>>>> I just updated the scripts t
On 16.10.20 05:36, Fino Meng wrote:
> On Thu, Oct 15, 2020 at 04:20:11PM +0200, Jan Kiszka wrote:
>> On 14.10.20 15:25, Fino Meng wrote:
>>> hi team,
>>>
>>> I just updated the scripts to build the WIP version xenomai porting to
>>> kernel 5.4, just follow the steps:
>>>
>>> git clone
On 15.10.20 16:20, Jan Kiszka via Xenomai wrote:
> On 14.10.20 15:25, Fino Meng wrote:
>> hi team,
>>
>> I just updated the scripts to build the WIP version xenomai porting to
>> kernel 5.4, just follow the steps:
>>
>> git clone https://github.com/finom
On 15.10.20 07:02, hongzha1 wrote:
> create and register RESCHEDULE_OOB_IPI interrupt handler
>
> Signed-off-by: hongzha1
>
> diff --git a/kernel/cobalt/sched.c b/kernel/cobalt/sched.c
> index f39becb90..1d40925b6 100644
> --- a/kernel/cobalt/sched.c
> +++ b/kernel/cobalt/sched.c
> @@ -30,6
On 14.10.20 15:25, Fino Meng wrote:
> hi team,
>
> I just updated the scripts to build the WIP version xenomai porting to
> kernel 5.4, just follow the steps:
>
> git clone https://github.com/finomeng/xenomai-mirror.git
> /tmp/xenomai-mirror.next-5.4
> cd /tmp/xenomai-mirror.next-5.4
> git
On 15.10.20 08:02, Edward Liao via Xenomai wrote:
> Hi, Xenomai Team:
>
> We have a problem when using PEAK real-time CAN deploy with a virtualization
> project called ACRN, which is an open source project, the primary contributor
> are Intel Team.
>
>
On 14.10.20 10:43, François Legal via Xenomai wrote:
> Anybody can help on this ?
>
I'm unfortunately not familiar with the armv7 details of copy-from-user,
not too speak of how spectre contributed to it. Greg, Philippe, did you
come across this already?
Jan
> François
>
> Le Mercredi,
On 13.10.20 09:45, hongzha1 wrote:
> Before calling irq_post_oob, interrupts must be hard disabled
> in the cpu. But irq_inject_pipeline would handle it internally.
>
> Signed-off-by: hongzha1
>
> diff --git a/kernel/cobalt/arch/x86/include/asm/xenomai/thread.h
>
On 29.09.20 15:25, Philippe Gerum via Xenomai wrote:
> From: Philippe Gerum
>
> vfile_snapshot_open() may re-run the data collection loop in case we
> detected a race by checking the revision tag of the data
> set. Unfortunately, the seq_file is already open at this point,
> causing a leakage as
On 29.09.20 00:27, Vitaly Chikunov wrote:
> Enable soname suffix with --enable-so-suffix configure option (Mercury
> core only).
>
> This will allow (for users) installing both versions of libs into the
> same system and (for distributions) having them without conflicts in
> the same repository.
On 13.10.20 11:35, Gylstorff Quirin wrote:
>
>
> On 10/12/20 12:36 PM, Jan Kiszka wrote:
>> On 07.10.20 10:10, Gylstorff Quirin wrote:
>>> Hi,
>>>
>>> Here is some data to the caching.
>>>
>>> during my test it reduced the build times from around 45min to around
>>> 25min.
>>
>> In travis, a
On 12.10.20 12:56, Deniz Uğur wrote:
> Yes that’s correct. I might be not clear enough, I meant how could I
> modify the config options similar to “make menuconfig”
Assuming you are talking about the kernel config used by xenomai-images:
You can edit the one shipped with the layer (see
On 12.10.20 12:46, Deniz Ugur wrote:
> Thanks Jan. Without going more off-topic, may I ask you how would one
> configure the config using xenomai-images?
>
If you look at the readme, it suggest to build like this e.g.:
kas-docker --isar build kas.yml:board-qemu-amd64.yml
To build for latest
On 12.10.20 05:06, hongzha1 wrote:
> alloc escalate irq with dovetail synthetic_irq_domain and init and
> raise it with irq_post_oob
>
> Signed-off-by: hongzha1
>
> diff --git a/kernel/cobalt/arch/x86/include/asm/xenomai/thread.h
> b/kernel/cobalt/arch/x86/include/asm/xenomai/thread.h
> index
On 30.09.20 05:00, hongzha1 wrote:
> schedule irq_work to execute xnselector_destroy_loop instead of
> calling __xnapc_schedule, which is to replace APC
>
> Signed-off-by: hongzha1
>
> diff --git a/kernel/cobalt/select.c b/kernel/cobalt/select.c
> index c3a3d34b7..3cde6e163 100644
> ---
On 08.10.20 18:31, Per Oberg via Xenomai wrote:
>
>
> - Den 8 okt 2020, på kl 14:47, xenomai xenomai@xenomai.org skrev:
>
>> Hi to all,
>> I have an ARM board (iMX6SX).
>> - kernel 4.9.88
>> - xenomai 3.0.9
>> - ipipe-core-4.9.51-arm-4
>
>> I have run a simple xenomai alchemy test :
>> - a
On 12.10.20 01:18, Deniz Uğur via Xenomai wrote:
> Hi Giulio,
>
> Thanks for your detailed response. I’ve checked all of the links you sent.
> They helped me a lot.
>
> Do you know if xenomai-images pulls master head?
> I believe CONFIG_XENO_DRIVERS_SPI_OMAP2_MCSPI_RT is just added on January.
On 07.10.20 10:10, Gylstorff Quirin wrote:
> Hi,
>
> Here is some data to the caching.
>
> during my test it reduced the build times from around 45min to around
> 25min.
In travis, a warm rebuild was ~10 min. in the end.
> The size of the cache is for each build is around 500k.
500K? It used
On 29.09.20 08:27, chensong wrote:
>
>
> On 2020年09月29日 00:52, Jan Kiszka wrote:
>> On 23.09.20 03:40, song wrote:
>>>
>>>
>>> On 2020/9/22 下午11:16, Jan Kiszka wrote:
On 21.09.20 14:32, chensong wrote:
> Upstream has used timespec64 to replace timespec inside kernel and
> used
On 25.09.20 09:03, hongzha1 wrote:
> call irq_work_queue to schedule registry_proc_work instead of
> calling __xnapc_schedule
>
> Signed-off-by: hongzha1
>
> ---
> this patch is for wip/dovetail
>
> diff --git a/kernel/cobalt/registry.c b/kernel/cobalt/registry.c
> index 813dae3fb..5570a4ca5
On 24.09.20 08:54, hongzha1 wrote:
> schedule irq_work which is to schedule work to execute heavy
> xnselector_destroy_loop instead of calling __xnapc_schedule.
>
> Signed-off-by: hongzha1
>
> ---
> this patch is for wip/dovetail. This is new version. It would
> schedule irq_work which is to
On 20.09.20 21:21, Vitaly Chikunov wrote:
> When building Cobalt core ALT rpmbuild QA script detects that libmodechk
> is linked improperly:
>
> verify-elf: ERROR: ./usr/lib64/libmodechk.so.0.0.0: undefined symbol:
> cobalt_assert_nrt
>
> Signed-off-by: Vitaly Chikunov
> ---
>
From: Jan Kiszka
They only break building outside of the tree.
Signed-off-by: Jan Kiszka
---
demo/alchemy/altency.c | 2 --
demo/posix/cyclictest/cyclictest.c | 1 -
2 files changed, 3 deletions(-)
diff --git a/demo/alchemy/altency.c b/demo/alchemy/altency.c
index
On 25.09.20 22:57, Vitaly Chikunov via Xenomai wrote:
> Hi,
>
> While making Xenomai packages for ALT Linux I try to test various use
> cases, but found some troubles:
>
> There is `demo/alchemy/altency.c` source. It compiles OK for Mercury,
> but fails for Cobalt.
>
> Page
>
>
>
From: Jan Kiszka
Makes the demo more portable.
Signed-off-by: Jan Kiszka
---
demo/posix/cobalt/eth_p_all.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/demo/posix/cobalt/eth_p_all.c b/demo/posix/cobalt/eth_p_all.c
index 91aef9fbdb..c4cf0d696f 100644
---
On 28.09.20 18:54, Jan Kiszka via Xenomai wrote:
> On 24.09.20 04:58, Vitaly Chikunov wrote:
>> Error message:
>>
>> In file included from eth_p_all.c:43:
>> /usr/include/xenomai/boilerplate/ancillaries.h:56:17: error: expected ‘=’,
>> ‘,’, ‘;’, ‘asm’ or ‘__a
On 24.09.20 04:58, Vitaly Chikunov wrote:
> Error message:
>
> In file included from eth_p_all.c:43:
> /usr/include/xenomai/boilerplate/ancillaries.h:56:17: error: expected ‘=’,
> ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘__early_panic’
>56 | void __noreturn __early_panic(const char *fn,
>
On 23.09.20 03:40, song wrote:
>
>
> On 2020/9/22 下午11:16, Jan Kiszka wrote:
>> On 21.09.20 14:32, chensong wrote:
>>> Upstream has used timespec64 to replace timespec inside kernel and
>>> used __kernel_timespec to replace timespect in syscalls, therefore
>>> we must keep aligned with upstream.
On 20.09.20 21:28, Vitaly Chikunov wrote:
> This will allow (for users) installing both versions of libs into the
> same system and (for distributions) having them without conflicts in
> the same repository.
>
> Such script is used to change Makefile.am-s:
>
> for lib in copperplate alchemy
On 21.09.20 15:51, Vitaly Chikunov wrote:
On Sun, Sep 20, 2020 at 10:28:08PM +0300, Vitaly Chikunov wrote:
This will allow (for users) installing both versions of libs into the
same system and (for distributions) having them without conflicts in
the same repository.
I forgot we need to
On 21.09.20 15:49, Martin Haag via Xenomai wrote:
Dear list members,
I am porting a Linux PCI character device driver to Xenomai 2.6.5.
I can not find a RTDM expression for the "parameters" argument of the
struct file_operations read callback.
struct file_operations:
ssize_t aim_read(struct
On 21.09.20 14:32, chensong wrote:
Upstream has used timespec64 to replace timespec inside kernel and
used __kernel_timespec to replace timespect in syscalls, therefore
we must keep aligned with upstream.
clock_settime is a point to get started at, it involves 2 parts:
1, syscall in
On 21.09.20 08:15, Jan Kiszka wrote:
On 20.09.20 18:52, Philippe Gerum wrote:
Philippe Gerum writes:
SPI, DMA, and GPIOs are a no brainer for this and are already available
in such form, serial and network need more analysis because their
execution contexts are either more clumsy/complex. I
On 18.09.20 08:32, Fino Meng wrote:
Out of tree build will fail after porting xenomai to Linux kernel 5.4.y,
update Makefiles and scripts to fix it.
Signed-off-by: Fino Meng
---
kernel/cobalt/arch/arm/Makefile | 2 +-
kernel/cobalt/arch/arm64/Makefile
On 20.09.20 18:52, Philippe Gerum wrote:
Philippe Gerum writes:
SPI, DMA, and GPIOs are a no brainer for this and are already available
in such form, serial and network need more analysis because their
execution contexts are either more clumsy/complex. I also got the PCM
portion of the Alsa
On 19.09.20 16:38, carver4lio--- via Xenomai wrote:
Hello,
I noticed that ipipe has been adapted to various architectures such as ARM,
x86, powerPC, but does not include MIPS. Is this an issue left over from
history? Or is it technically inappropriate for arch MIPS?
A couple of downstream
On 18.09.20 18:17, Philippe Gerum wrote:
- how to solve the general issue of driver bit rotting over Cobalt/RTDM?
(e.g. can, uart, spi, rtnet)
Drivers for hardware that deceased a decade ago or so should probably be
removed (RTnet hosts several candidates). The rest depends on users
On 18.09.20 08:32, Fino Meng wrote:
compat_timex related definitions moved from compat code into normal timekeeping
code.
see 4d5f007e in upstream Linux kernel.
Signed-off-by: Fino Meng
Signed-off-by: Mingliang Hu
---
include/cobalt/kernel/compat.h | 4 ++--
kernel/cobalt/posix/compat.c
On 18.09.20 08:32, Fino Meng wrote:
Signed-off-by: Fino Meng
Signed-off-by: Mingliang Hu
---
include/cobalt/kernel/stat.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/cobalt/kernel/stat.h b/include/cobalt/kernel/stat.h
index b857cd19f..be529ad72 100644
---
When I'm asking questions on the code, there was a need for a commit
message.
On 18.09.20 08:29, Fino Meng wrote:
Signed-off-by: Fino Meng
Signed-off-by: Mingliang Hu
---
kernel/cobalt/arch/x86/thread.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git
From: Jan Kiszka
This not just traces garbage, it usually crashes the system one the
tracepoint is enabled.
Signed-off-by: Jan Kiszka
---
kernel/cobalt/posix/sem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/cobalt/posix/sem.c b/kernel/cobalt/posix/sem.c
index
On 17.09.20 14:01, Harco Kuppens wrote:
On 17/09/2020 13:51, Jan Kiszka wrote:
On 16.09.20 20:12, Harco Kuppens via Xenomai wrote:
Hi,
I found a problem with rt_task_set_priority function which does not
increase priority of another task.
However it works fine if you increase the priority of
On 16.09.20 20:12, Harco Kuppens via Xenomai wrote:
Hi,
I found a problem with rt_task_set_priority function which does not
increase priority of another task.
However it works fine if you increase the priority of another task.
Below is an en example program and its output, and we run this
On 17.09.20 04:49, hongzha1 wrote:
fix implicit declaration of function error when compile other cobalt
drivers calling rtdm_nrtsig_init
---
this patch is for wip/dovetail branch
Signed-off-by: hongzha1
Signed off needs to be above the "---" separator.
diff --git
On 15.09.20 14:19, Lange Norbert wrote:
On debian, dh_shlibdeps (dpkg-shlibdeps) should be able to diagnose this aswell.
Then we must be missing something, or it only warns, because we are
performing package builds regularly for it.
Jan
--
Siemens AG, Corporate Technology, CT RDA IOT
On 15.09.20 08:45, Philippe Gerum via Xenomai wrote:
Vitaly Chikunov via Xenomai writes:
On Mon, Sep 14, 2020 at 02:06:40PM -0500, Per Oberg via Xenomai wrote:
- Den 14 sep 2020, på kl 20:20, xenomai xenomai@xenomai.org skrev:
I wish to create two sets of packages for ALT Linux for
On 15.09.20 09:05, song wrote:
Hi guys,
After going through Arnd Bergmann's patch
list(https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git/log/?h=y2038-syscalls),
i'm going to get started at 64bit-xenomai y2038-safe(#1 in below list).
1, timespec to __kernel_timespec in
On 12.09.20 18:40, Philippe Gerum wrote:
Jan Kiszka writes:
On 11.09.20 18:32, Philippe Gerum wrote:
Jan Kiszka via Xenomai writes:
Hi all,
to permit sharing the work of porting Xenomai over dovetail, I finally
pushed my baseline hacks to [1]. You can "use" that o
On 14.09.20 23:52, Vitaly Chikunov wrote:
ALT rpmbuild QA script detects that libsmokey and libcopperplate is improperly
linked (when built for Mercury core).
Excerpt from the error message:
verify-elf: ERROR: ./usr/lib64/libsmokey.so.0.0.0: undefined symbol:
get_mem_size
verify-elf:
On 14.09.20 17:40, Meng, Fino via Xenomai wrote:
Hi all,
A updated patchset was updated to this branch:
https://github.com/intel/linux-stable-xenomai/tree/review/5.4.59/stable/ipipe/xenomai-3.1
this version is more clean than previous, only one more patch for IPIPE part,
and one more patch for
On 11.09.20 18:32, Philippe Gerum wrote:
>
> Jan Kiszka via Xenomai writes:
>
>> Hi all,
>>
>> to permit sharing the work of porting Xenomai over dovetail, I finally
>> pushed my baseline hacks to [1]. You can "use" that on [2] (use
>> fa1e9b
On 11.09.20 11:43, Jan Leupold via Xenomai wrote:
> __open_2() and __open64_2() from glibc add runtime precondition tests for the
> 'oflag' parameter to the functionality of open()/open64(). They may be used
> when
> the macro _FORTIFY_SOURCE is defined when compiling the application code.
>
On 07.09.20 17:18, Philippe Gerum wrote:
>
> Philippe Gerum writes:
>
>> Jan Kiszka writes:
>>
>>> On 07.09.20 15:09, Philippe Gerum wrote:
From: Philippe Gerum
Signed-off-by: Philippe Gerum
---
arch/x86/kernel/ipipe.c | 1 +
1 file changed, 1 insertion(+)
Please consider for v3:
On 10.09.20 16:46, Jan Leupold via Xenomai wrote:
> __open_2() and __open64_2() from glibc add runtime precondition tests for the
> 'oflag' parameter to the functionality of open()/open64(). They may be used
> when
> the macro _FORTIFY_SOURCE is defined when compiling the
On 11.09.20 10:32, Jan Leupold via Xenomai wrote:
> If Xenomai itself is not compiled with FORTIFY_SOURCE then the function
> declarations for __open_2() and __open64_2() are not available.
> __STD(__open_2(...)) will not link in this case (would be a very special
> use case anyway?).
>
That
On 11.09.20 08:22, Jan Leupold via Xenomai wrote:
> Am 10.09.20 um 18:27 schrieb Jan Kiszka:
>> On 10.09.20 18:14, Jan Kiszka via Xenomai wrote:
>>> On 10.09.20 16:46, Jan Leupold via Xenomai wrote:
>>>> __open_2() and __open64_2() from glibc
Hi all,
to permit sharing the work of porting Xenomai over dovetail, I finally
pushed my baseline hacks to [1]. You can "use" that on [2] (use
fa1e9ba5e822, 0d68e5607286 leaks evl bits and is broken) just like you
would for an I-pipe kernel (prepare-kernel.sh). The thing builds for me,
it even
On 10.09.20 18:14, Jan Kiszka via Xenomai wrote:
> On 10.09.20 16:46, Jan Leupold via Xenomai wrote:
>> __open_2() and __open64_2() from glibc add runtime precondition tests for the
>> 'oflag' parameter to the functionality of open()/open64(). They may be used
>> when
>>
On 10.09.20 16:46, Jan Leupold via Xenomai wrote:
> __open_2() and __open64_2() from glibc add runtime precondition tests for the
> 'oflag' parameter to the functionality of open()/open64(). They may be used
> when
> the macro _FORTIFY_SOURCE is defined when compiling the application code.
>
On 10.09.20 16:32, Jan Leupold via Xenomai wrote:
> Am 10.09.20 um 16:19 schrieb Jan Kiszka:
>> On 10.09.20 15:48, Jan Leupold via Xenomai wrote:
>>> __open_2() from glibc adds a runtime precondition test for the 'oflag'
>>> parameter to the functionality of open(). It may be used when the macro
On 10.09.20 15:48, Jan Leupold via Xenomai wrote:
> __open_2() from glibc adds a runtime precondition test for the 'oflag'
> parameter to the functionality of open(). It may be used when the macro
> _FORTIFY_SOURCE is defined when compiling the application code. Added this
> wrapper to cover that
On 10.09.20 12:37, Jan Leupold via Xenomai wrote:
> Hi all,
>
> I just had a long debugging session and wanted to comment the result here
> on the list.
>
> When using -D_FORTIFY_SOURCE=2 the first ioctl() after open() suddenly
> failed. This is due to an inline function "open()" (in
On 10.09.20 08:34, Peter Wong wrote:
> The plan is to have new xenomai socket API for send RT traffic to
> xenomai core network stack -> then to linux driver?
>
> There is switching overhead between cobalt and linux ?
No, the plan is not using the Linux drivers for the dataplane as that
would
On 07.09.20 18:54, Lakshmi Dhanaraj wrote:
> Hi Jan,
>
> Using RTNET_RTIOC_XMITPARAMS & SOCK_XMIT_PARAMS I setted the priority
> and slot ID for Multi-slot configuration.And it is working.
> As per my understanding, the slots are used for writing out-going
> packets in the priority queue, not for
On 07.09.20 03:45, Peter Wong via Xenomai wrote:
> Is there any plan for support qdisc, zero copy, XDP in RTnet?
>
Plans aren't concrete yet, but renovation (or replacement) of RTnet is
needed, specifically to support TSN. Ideally, we do that with maximum
reuse of kernel infrastructure, "just"
On 09.09.20 07:23, gopi ratnakaram via Xenomai wrote:
> Team,
>
> I am working with xenomai patched with kernel 4.19.59 on an Industrial
> motherboard which has an SMBus. After patching during my testing it was
> observed that the SMbus got some issues and the bus is locking immediately
> after
On 07.09.20 15:09, Philippe Gerum wrote:
> From: Philippe Gerum
>
> IRQs chained from a parent interrupt (e.g. cascaded interrupts from
> chained GPIO irqchips) do not have any assigned vector. Therefore, we
> cannot expect __ipipe_get_ioapic_irq_vector() to return anything
> sensible for those
On 07.09.20 15:09, Philippe Gerum wrote:
> From: Philippe Gerum
>
> Signed-off-by: Philippe Gerum
> ---
> arch/x86/kernel/ipipe.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/x86/kernel/ipipe.c b/arch/x86/kernel/ipipe.c
> index 3f3afcecc1b9..c5ebfdf2dfb3 100644
> ---
On 04.09.20 13:23, Jan Kiszka wrote:
> On 04.09.20 12:37, Jan Kiszka via Xenomai wrote:
>> On 04.09.20 12:32, Q. Gylstorff wrote:
>>> From: Quirin Gylstorff
>>>
>>>
>>> This patch adds a gitlab-ci.yml to support ci builds on gitlab. The
>>>
On 04.09.20 12:37, Jan Kiszka via Xenomai wrote:
> On 04.09.20 12:32, Q. Gylstorff wrote:
>> From: Quirin Gylstorff
>>
>>
>> This patch adds a gitlab-ci.yml to support ci builds on gitlab. The
>> build is derived from .travis.yml.
>>
>> An executed p
On 04.09.20 10:00, 孙世龙 sunshilong via Xenomai wrote:
> Hi, list
>
> There are several host timers that could be seen through the virtual
> file named as /proc/xenomai/timer/coreclk,i.e:
>
> ~ # cat /proc/xenomai/timer/coreclk
> CPU SCHED/SHOT TIMEOUT INTERVALNAME
> 0
On 04.09.20 12:32, Q. Gylstorff wrote:
> From: Quirin Gylstorff
>
>
> This patch adds a gitlab-ci.yml to support ci builds on gitlab. The
> build is derived from .travis.yml.
>
> An executed pipeline can be found at [1].
>
> Changes V2:
> - adapt git remote ls syntax to git version 2.20 from
On 04.09.20 03:26, 孙世龙 sunshilong wrote:
>>> We want to make Xenomai-3.0.9 work on Linux-4.19
>>> (as far as I know, the latest version that it supports is Linux-4.14 and
>>> Xenomai-3.1 supports Linux-4.19).
>>>
>>> Is it possible?
>>> Could you give me some advice on how to make Xenomai-3.0.9
On 03.09.20 19:51, Gylstorff Quirin wrote:
>
>
> On 9/3/20 4:05 PM, Jan Kiszka wrote:
>> On 03.09.20 15:57, Q. Gylstorff wrote:
>>> From: Quirin Gylstorff
>>>
>>> Derive .gitlab-ci.yml from .travis.yml to allow ci build on
>>> denx.gitlab.de.
>>>
>>> Changes:
>>> - The base image is switched
On 03.09.20 15:57, Q. Gylstorff wrote:
> From: Quirin Gylstorff
>
> Derive .gitlab-ci.yml from .travis.yml to allow ci build on denx.gitlab.de.
>
> Changes:
> - The base image is switched to debian:buster.
>
> Signed-off-by: Quirin Gylstorff
> ---
> .gitlab-ci.yml | 254
On 02.09.20 11:12, 孙世龙 sunshilong wrote:
> Hi,
>
>> That is a (reasonable) design decision because you would otherwise risk
>> that a handler registered for low-prio task can block the delivery of an
>> event for a high-prio task. I would just be a mess, at least in a more
>> complex RT
On 01.09.20 11:11, 孙世龙 sunshilong via Xenomai wrote:
> Hi,
>
> I found that the timer-internal thread is set with the
> THREADOBJ_IRQCONTEXT flag.
> Here is the related code snippet:
> static int server_prologue(void *arg)
> {
>svpid = get_thread_pid();
>
On 01.09.20 19:08, Lakshmi Dhanaraj via Xenomai wrote:
> Hi,
>
> My System is configured with Xenomai-3.0.5 on Linux-4.9.38 kernel under
> Ubuntu 18.04.1 LTS. I am using I210 Ethernet Controller with the capability
> of 1Gbps.
>
> Configured Master and Slave TDMA slot 0 with offset 0 and 400
On 01.09.20 11:37, Meng, Fino via Xenomai wrote:
> Hi all,
>
> Today I uploaded a new version that can build and run,
>
> https://github.com/intel/linux-stable-xenomai/commits/review/5.4.58/stable/ipipe/xenomai-3.1
>
> step to build after clone:
>
> cp kernel_config_xenomai .config
> make
On 31.08.20 11:17, 孙世龙 sunshilong via Xenomai wrote:
> Hi, list
>
> Our project depends on Xenomai-3.0.9. And we can't upgrade it to
> Xenomai-3.1 indeed.
>
> We want to make Xenomai-3.0.9 work on Linux-4.19
> (as far as I know, the latest version that it supports is Linux-4.14 and
> Xenomai-3.1
On 27.08.20 16:24, Q. Gylstorff wrote:
> From: Quirin Gylstorff
>
> If the ci system with artifacts is execute on a system without
> the necessary infrastructure the gitlab-ci.yml is invalid.
> Fix this by setting the default build to ci/no-artifacts.yml
> and remove the dependency to
On 27.08.20 09:55, 孙世龙 sunshilong wrote:
> Thank you for your attention to my question.
>
>>> Which one has a higher priority, the thread named by "main" that is
>>> created by rt_task_create or the
>>> one named by "timer-internal" that is created internally?
>>>
>>> As far as I know, the
1301 - 1400 of 2528 matches
Mail list logo
