From: Jan Kiszka
This is not a runtime tool, it's for development. And as libxenomai-dev
has no dependency on xenomai-runtime (as there should be none), it is
missed in build-only installations.
Reported-by: Florian Bezdeka
Fixes: 6e77fe2b8d3f ("debian: drop xeno-config from -dev package")
Just a heads-up and reminder:
I've just added some obvious or less obvious issues regarding the 3.2
milestone to https://gitlab.com/Xenomai/xenomai-hacker-space/-/issues.
If you run into something (unsolved bug, feature request etc.), related
to Dovetail or beyond, do not hesitate to use that
On 12.04.21 19:37, Q. Gylstorff wrote:
> From: Quirin Gylstorff
>
> The 5.4-arm64 build[1] needs a cache size greater than 400M.
>
> [1]: https://gitlab.com/Xenomai/xenomai-hacker-space/-/jobs/1171197811
>
> Signed-off-by: Quirin Gylstorff
> ---
> .gitlab-ci.yml | 2 +-
> 1 file changed, 1
On 12.04.21 09:45, Bezdeka, Florian (T RDA IOT SES-DE) wrote:
> On Thu, 2021-04-08 at 19:24 +0200, Jan Kiszka wrote:
>> On 08.04.21 17:12, Florian Bezdeka wrote:
>>> Trying to boot up the example image on an x86 board with UEFI failed
>>> because vfat support was missing. The x86 defconfig has
From: Jan Kiszka
We better exclude this code path due to unknown impact on RT.
Signed-off-by: Jan Kiszka
---
kernel/drivers/net/drivers/igb/igb.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/drivers/net/drivers/igb/igb.h
b/kernel/drivers/net/drivers/igb/igb.h
index
From: Jan Kiszka
Signed-off-by: Jan Kiszka
---
kernel/drivers/net/drivers/experimental/e1000/e1000_main.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/drivers/net/drivers/experimental/e1000/e1000_main.c
b/kernel/drivers/net/drivers/experimental/e1000/e1000_main.c
index
Philippe,
you may want to include this into your trees:
https://lkml.org/lkml/2021/4/11/48
Jan
From: Jan Kiszka
Signed-off-by: Jan Kiszka
---
kernel/cobalt/include/asm-generic/xenomai/wrappers.h | 4
kernel/drivers/net/drivers/e1000e/netdev.c | 2 +-
kernel/drivers/net/drivers/igb/igb_main.c| 4 ++--
3 files changed, 7 insertions(+), 3 deletions(-)
diff --git
From: Jan Kiszka
Provided by linux/crc32.h as well, now causing build errors. But it was
unused anyway.
Signed-off-by: Jan Kiszka
---
kernel/drivers/net/drivers/r8169.c | 24
1 file changed, 24 deletions(-)
diff --git a/kernel/drivers/net/drivers/r8169.c
From: Jan Kiszka
Follows upstream commit c4cb99185b4c.
Signed-off-by: Jan Kiszka
---
kernel/drivers/net/drivers/igb/igb_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/drivers/net/drivers/igb/igb_main.c
b/kernel/drivers/net/drivers/igb/igb_main.c
index
Mostly for post 5.4 kernels, just the peak_canfd is relevant for older
ones as well.
Jan
CC: Jan Kiszka
Jan Kiszka (4):
drivers/can/peak_canfd: Fix building out-of-tree
drivers/net: Account for renaming of
pci_cleanup_aer_uncorrect_error_status in 5.7
drivers/net/igb: Replace
From: Jan Kiszka
Signed-off-by: Jan Kiszka
---
kernel/drivers/can/peak_canfd/Makefile | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/kernel/drivers/can/peak_canfd/Makefile
b/kernel/drivers/can/peak_canfd/Makefile
index 22670a9c46..f56f451562 100644
---
On 08.04.21 17:12, Florian Bezdeka wrote:
> Trying to boot up the example image on an x86 board with UEFI failed
> because vfat support was missing. The x86 defconfig has been
> re-synchronized with the arm64 defconfig to enable UEFI boot support.
>
> Signed-off-by: Florian Bezdeka
> ---
>
On 08.04.21 10:19, Chen, Hongzhan via Xenomai wrote:
>> From: Xenomai On Behalf Of Wang, Rick Y via
>> Xenomai
>> Sent: Thursday, April 8, 2021 8:52 AM
>> To: xenomai@xenomai.org
>> Subject: Xenomai Community Call Minutes - April 7, 2021
>>
>> Attendees:
>>
>> Jan Kiszka, Florian Bezdeka,
On 08.04.21 08:57, Philippe Gerum via Xenomai wrote:
>
> Hello Rick,
>
> At what time did that meeting take place yesterday? I tried to connect
> several times to the usual 'teams' room from 7:55 to 8:10, but nobody
> was there.
CEST mess: The meeting moved to 9am our time due to daylight
On 27.03.21 10:54, Philippe Gerum wrote:
> From: Florian Bezdeka
>
> The helper used for copying the timeout values (=mutex_fetch_timeout())
> was always copying sizeof(struct timespec64) from user to kernel space.
> For applications with time_t being 4 bytes only (like for native 32 bit
>
On 27.03.21 11:35, Philippe Gerum wrote:
> From: Philippe Gerum
>
> Jan Kiszka (1):
> cobalt/intr: dovetail: Don't do anything in xnintr_enable/disable
>
> Philippe Gerum (4):
> cobalt/syscall: dovetail: do not expose clock frequency to user
> cobalt/sched: dovetail: disable separate
On 07.04.21 13:55, Philippe Gerum wrote:
>
> Jan Kiszka writes:
>
>> On 27.03.21 11:35, Philippe Gerum wrote:
>>> From: Philippe Gerum
>>>
>>> This feature should be available directly from Dovetail.
>>>
>>
>> What is the corresponding kernel option of Dovetail? Can't we select it
>> here for
On 27.03.21 11:35, Philippe Gerum wrote:
> From: Philippe Gerum
>
> This feature should be available directly from Dovetail.
>
What is the corresponding kernel option of Dovetail? Can't we select it
here for compat reasons?
Jan
> Signed-off-by: Philippe Gerum
> ---
> kernel/cobalt/Kconfig
On 27.03.21 11:35, Philippe Gerum wrote:
> From: Jan Kiszka
>
> As we are using regular request/free_irq under dovetail, there is no
> extra task to be done in the interrupt enable/disable services. In fact,
> calling enable_irq will rather trigger "Unbalanced enable for IRQ ..."
> errors.
>
>
On 27.03.21 11:19, Philippe Gerum wrote:
> From: Philippe Gerum
>
> More wrappers and other changes required to build for the kernel v5.x
> series.
>
> Philippe Gerum (7):
> cobalt/memory: fix __vmalloc() calls
> cobalt/debug: switch to mmap_lock interface
> cobalt/kernel: convert to
On 27.03.21 11:19, Philippe Gerum wrote:
> From: Philippe Gerum
>
> set_fs() is on its way out, so we cannot open code a file read
> operation by calling the VFS handler directly anymore, faking a user
> address space.
>
> We do have kernel interfaces for loading files though, particularly
>
On 27.03.21 11:19, Philippe Gerum wrote:
> From: Philippe Gerum
>
> Signed-off-by: Philippe Gerum
> ---
> kernel/drivers/net/stack/ipv4/icmp.c | 16 ++--
> 1 file changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/drivers/net/stack/ipv4/icmp.c
>
On 27.03.21 11:19, Philippe Gerum wrote:
> From: Philippe Gerum
>
> Since v5.9-rc1, csum_partial_copy_nocheck() forces a zero seed as its
> last argument to csum_partial(). According to #cc44c17baf7f3, passing
> a non-zero value would not even yield the proper result on some
> architectures.
>
On 27.03.21 11:19, Philippe Gerum wrote:
> From: Philippe Gerum
>
> Signed-off-by: Philippe Gerum
> ---
> .../include/asm-generic/xenomai/wrappers.h| 20 ++
> kernel/cobalt/vfile.c | 26
> kernel/drivers/analogy/device.c | 12 ++--
>
From: Jan Kiszka
Signed-off-by: Jan Kiszka
---
recipes-kernel/linux/linux-xenomai_latest.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/recipes-kernel/linux/linux-xenomai_latest.bb
b/recipes-kernel/linux/linux-xenomai_latest.bb
index 9dd4c93..91b4743 100644
---
Hi all,
as we discussed today in the community call how to use a network link to
benchmark Xenomai I/O, here is the link to our work for a different
activity that we shared with the dpdk community:
http://mails.dpdk.org/archives/dev/2020-September/181035.html
Being DPDK, this comes without
On 24.03.21 10:22, Bezdeka, Florian (T RDA IOT SES-DE) wrote:
> On Wed, 2021-03-24 at 09:20 +0100, Jan Kiszka wrote:
>> On 24.03.21 08:34, Bezdeka, Florian (T RDA IOT SES-DE) wrote:
>>> Hi Jan,
>>>
>>> I would migrate the Y2038 wiki pages to the hackerspace if you like
>>> that. In order to do
> - fbezdeka (myself)
> - chensong-kylin (Song)
>
Will do that - but could you first check if that is already possible? I
changed to wiki access level to "everyone with access", and I'd like to
understand what that effectively means.
Jan
> Thanks,
> Florian
>
> On We
On 23.03.21 14:56, Jan Kiszka wrote:
> On 23.03.21 11:32, Philippe Gerum wrote:
>>
>> Philippe Gerum writes:
>>
>>> Hi,
>>>
>>> I will not be able to attend the next meeting planned tomorrow. Here is
>>> the update from my side since the last time we met:
>>>
>>> - The Xenomai/arm64 port to
On 23.03.21 11:32, Philippe Gerum wrote:
>
> Philippe Gerum writes:
>
>> Hi,
>>
>> I will not be able to attend the next meeting planned tomorrow. Here is
>> the update from my side since the last time we met:
>>
>> - The Xenomai/arm64 port to Dovetail is complete, available from my
>>
On 19.03.21 04:15, Chen, Hongzhan wrote:
>>
>>
>> -Original Message-
>> From: Xenomai On Behalf Of Philippe Gerum via
>> Xenomai
>> Sent: Friday, March 19, 2021 12:33 AM
>> To: Jan Kiszka
>> Cc: Xenomai
>> Subject: Re: RTDM vs. "dovetail: implement interrupt management, handling"
>>
>>
From: Jan Kiszka
As we are using regular request/free_irq under dovetail, there is no
extra task to be done in the interrupt enable/disable services. In fact,
calling enable_irq will rather trigger "Unbalanced enable for IRQ ..."
errors.
Signed-off-by: Jan Kiszka
---
Hi Philippe,
with that patch, namely
void xnintr_enable(struct xnintr *intr)
{
secondary_mode_only();
enable_irq(intr->irq);
}
RTDM drivers stumble when using MSI and MSI-X, possibly also other
interrupts types:
[64630.529207] Unbalanced enable for IRQ 145
[64630.529207]
Hi all,
in order to make central project resources more accessible to
contributors, I've set up a mirror of the main Xenomai repository on
gitlab.com:
https://gitlab.com/Xenomai/xenomai-hacker-space
This hacker space shall not replace the official project page but
augment it. Users with
On 16.03.21 14:51, Matúš Olekšák via Xenomai wrote:
> udelay() should not be used with values over 20 000. But the first calling of
> udelay() in e1000e_phy_has_link_generic(), does not check delay value. It
> causes compile-time trap __bad_udelay() to occur. Bug is present on all
> Xenomai
On 16.03.21 06:51, Vitaly Chikunov wrote:
> Jan,
>
> On Sun, Mar 14, 2021 at 10:45:56AM +0100, Jan Kiszka wrote:
>> On 12.03.21 09:00, Vitaly Chikunov wrote:
>>> On Fri, Mar 12, 2021 at 08:19:30AM +0100, Jan Kiszka wrote:
> If you wish, you can extract built kernel from RPM with rpm2cpio and
On 15.03.21 18:19, steve freyder via Xenomai wrote:
> Greetings Xenomai list,
>
>
> We are seeing the following stack trace when we 'ifup' the e1000e
> adapter. 4.19 exhibits same failure, 4.14.96 also fails but with a
> different stack trace. Last working version is 4.14.85.
>
> Thanks in
From: Jan Kiszka
This macro may unroll to instantiating 'date' twice. If that is a call
to some get-time function, as via xnstat_exectime_switch, we needlessly
do that twice.
Signed-off-by: Jan Kiszka
---
include/cobalt/kernel/stat.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
From: Jan Kiszka
In contrast to real RTDM devices, message queues have no fallback path
to Linux in userspace. Thus, EADV is neither needed nor detected by
libcobalt. Avoid leaking it from RTDM to the mq syscall interface.
Fixes: 2db562ad62ec ("cobalt: switch hand over status to -EADV for
On 06.03.21 15:58, Philippe Gerum wrote:
>
> Jan Kiszka writes:
>
>> On 05.03.21 12:38, Jan Kiszka via Xenomai wrote:
>>> From: Jan Kiszka
>>>
>>> This is still needed to avoid that a real-time parent seems minor faults
>>> after forki
On 15.03.21 10:47, Philippe Gerum wrote:
>
> Jan Kiszka writes:
>
>> On 15.03.21 10:00, Philippe Gerum wrote:
>>>
>>> Jan Kiszka writes:
>>>
>>>> On 14.03.21 18:14, Philippe Gerum wrote:
>>>>>
>>>>> Jan K
On 15.03.21 10:00, Philippe Gerum wrote:
>
> Jan Kiszka writes:
>
>> On 14.03.21 18:14, Philippe Gerum wrote:
>>>
>>> Jan Kiszka via Xenomai writes:
>>>
>>>> From: Jan Kiszka
>>>>
>>>> This is only called during ear
From: Jan Kiszka
I-pipe makes sure that arguments of compat calls are ordered just like
native calls. Dovetail does not. But it is better to use the kernel's
syscall_get_arguments for retrieving the arguments anyway. Introduce
pipeline_get_syscall_args to abstract that difference.
On 15.03.21 07:19, Jan Kiszka via Xenomai wrote:
> On 14.03.21 18:14, Philippe Gerum wrote:
>>
>> Jan Kiszka via Xenomai writes:
>>
>>> From: Jan Kiszka
>>>
>>> This is only called during early init, e.g. for switching alternatives.
>
From: Jan Kiszka
Make the package set arch-specific to save some bytes and seconds.
Signed-off-by: Jan Kiszka
---
.gitlab-ci.yml | 34 ++
1 file changed, 18 insertions(+), 16 deletions(-)
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index
On 15.03.21 08:59, Jan Kiszka via Xenomai wrote:
> On 15.03.21 08:57, François Legal wrote:
>> Le Lundi, Mars 15, 2021 08:16 CET, Jan Kiszka a
>> écrit:
>>
>>> On 12.03.21 23:21, François Legal via Xenomai wrote:
>>>> Hello,
>>>>
>
On 12.03.21 20:53, Henning Schild wrote:
> Am Fri, 12 Mar 2021 20:46:30 +0100
> schrieb Henning Schild :
>
>> Am Fri, 12 Mar 2021 19:18:14 +0100
>> schrieb Henning Schild via Xenomai :
>>
>>> Am Fri, 12 Mar 2021 12:32:54 +0100
>>> schrieb Jan Kiszka :
>>>
On 12.03.21 08:22, Jan Kiszka
On 15.03.21 08:57, François Legal wrote:
> Le Lundi, Mars 15, 2021 08:16 CET, Jan Kiszka a
> écrit:
>
>> On 12.03.21 23:21, François Legal via Xenomai wrote:
>>> Hello,
>>>
>>> working on a data recorder application, I would need to get access to each
>>> packet receive timestamp (populated
On 12.03.21 23:21, François Legal via Xenomai wrote:
> Hello,
>
> working on a data recorder application, I would need to get access to each
> packet receive timestamp (populated during packet reception ISR generally in
> network drivers).
>
> I figured out, the cleanest way to do it would be
On 12.03.21 15:01, Stephane Grosjean wrote:
> This patch includes the driver that supports the CANFD interfaces of
> the PCAN-PCIe FD family. This driver is largely inspired by the peak_pciefd
> driver included in the kernel since version 4.12. Except for the
> differences related to the RTDM
On 14.03.21 18:14, Philippe Gerum wrote:
>
> Jan Kiszka via Xenomai writes:
>
>> From: Jan Kiszka
>>
>> This is only called during early init, e.g. for switching alternatives.
>> Still, switch_mm_irqs_off would complain without this, and we are better
&g
From: Jan Kiszka
When ipipe_handle_syscall signals "do not pass, return via slow path",
we must not run syscall_slow_exit_work. So far, this case was detected
by checking the syscall number. However, this missed the case that an
invalid syscall was passed down, forwarded by ipipe_handle_syscall,
From: Jan Kiszka
This is only called during early init, e.g. for switching alternatives.
Still, switch_mm_irqs_off would complain without this, and we are better
safe than sorry.
Signed-off-by: Jan Kiszka
---
4.19 is not affected. Dovetail solves this differently, via
local_irq_save_full
From: Jan Kiszka
cpu_buffer->current_context is supposed to be protected by irq
disabling, just like in dovetail.
Signed-off-by: Jan Kiszka
---
No-arch branches updated with this already.
kernel/trace/ring_buffer.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
On 12.03.21 09:00, Vitaly Chikunov wrote:
> On Fri, Mar 12, 2021 at 08:19:30AM +0100, Jan Kiszka wrote:
>>> If you wish, you can extract built kernel from RPM with rpm2cpio and
>>> try boot on your system:
>>>
>>>
On 12.03.21 08:22, Jan Kiszka wrote:
> On 11.03.21 17:35, Henning Schild wrote:
>> Am Mon, 22 Feb 2021 16:35:30 +0100
>> schrieb Henning Schild via Xenomai :
>>
>>> Am Sun, 31 Jan 2021 17:06:21 +0100
>>> schrieb Philippe Gerum via Xenomai :
>>>
The initial port of the Cobalt core to
On 12.03.21 03:49, Vitaly Chikunov wrote:
> Jan,
>
> On Thu, Mar 11, 2021 at 04:10:03PM +0100, Jan Kiszka wrote:
>> On 11.03.21 12:49, Jan Kiszka via Xenomai wrote:
>>> On 10.03.21 23:46, Vitaly Chikunov via Xenomai wrote:
>>>> On Mon, Mar 08, 2021 at 07:1
On 11.03.21 17:35, Henning Schild wrote:
> Am Mon, 22 Feb 2021 16:35:30 +0100
> schrieb Henning Schild via Xenomai :
>
>> Am Sun, 31 Jan 2021 17:06:21 +0100
>> schrieb Philippe Gerum via Xenomai :
>>
>>> The initial port of the Cobalt core to Dovetail/x86 is available
>>> from [1]. Ports to
On 11.03.21 16:53, Philippe Gerum wrote:
>
> Jan Kiszka writes:
>
>> On 20.02.21 13:45, Philippe Gerum wrote:
>>> From: Philippe Gerum
>>>
>>> Signed-off-by: Philippe Gerum
>>> ---
>>> .../cobalt/kernel/dovetail/pipeline/trace.h | 123 ++
>>> 1 file changed, 123
On 11.03.21 12:49, Jan Kiszka via Xenomai wrote:
> On 10.03.21 23:46, Vitaly Chikunov via Xenomai wrote:
>> Hi,
>>
>> On Mon, Mar 08, 2021 at 07:12:26AM +0100, xenomai--- via Xenomai wrote:
>>> Release tag: ipipe-core-4.19.177-cip44-x86-16
>>
>>
On 10.03.21 23:46, Vitaly Chikunov via Xenomai wrote:
> Hi,
>
> On Mon, Mar 08, 2021 at 07:12:26AM +0100, xenomai--- via Xenomai wrote:
>> Release tag: ipipe-core-4.19.177-cip44-x86-16
>
> This is not appeared first on this release, but (this release too)
> crashes when boot on x86_64 with audit
On 11.03.21 11:46, Jan Kiszka via Xenomai wrote:
> On 11.03.21 11:38, Florian Bezdeka wrote:
>> On 11.03.21 10:12, Jan Kiszka wrote:
>>> On 08.03.21 13:46, Jan Kiszka via Xenomai wrote:
>>>> On 08.03.21 13:42, Bezdeka, Florian (T RDA IOT SES-DE) wrote:
>>>&g
On 11.03.21 10:58, chensong via Xenomai wrote:
>
>
> On 2021年03月11日 17:29, chensong via Xenomai wrote:
>>
>>
>> On 2021年03月11日 17:03, florian.bezd...@siemens.com wrote:
>>> On Thu, 2021-03-11 at 10:46 +0800, chensong wrote:
Adding a new syscall clock_settime64 specific for timespec64,
On 11.03.21 11:38, Florian Bezdeka wrote:
> On 11.03.21 10:12, Jan Kiszka wrote:
>> On 08.03.21 13:46, Jan Kiszka via Xenomai wrote:
>>> On 08.03.21 13:42, Bezdeka, Florian (T RDA IOT SES-DE) wrote:
>>>> On Mon, 2021-03-08 at 11:42 +0100, Jan Kiszka wrote:
>>&g
On 08.03.21 13:46, Jan Kiszka via Xenomai wrote:
> On 08.03.21 13:42, Bezdeka, Florian (T RDA IOT SES-DE) wrote:
>> On Mon, 2021-03-08 at 11:42 +0100, Jan Kiszka wrote:
>>> On 04.03.21 19:33, florian.bezdeka--- via Xenomai wrote:
>>>> On Thu, 2021-03-04 at 14:18
On 10.03.21 17:49, Philippe Gerum wrote:
>
> Jan Kiszka writes:
>
>> On 09.03.21 05:45, hongzha1 via Xenomai wrote:
>>> Ask for switching back to oob mode once ptrace core tell that
>>> current is resuming from a stopped state, leaving space for
>>> other runnable RT threads of the process to
On 10.03.21 17:15, Philippe Gerum wrote:
>
> Jan Kiszka writes:
>
>> From: Jan Kiszka
>>
>> I-pipe makes sure that arguments of compat calls are ordered just like
>> native calls. Dovetail does not. But it is better to use the kernel's
>> syscall_get_arguments for retrieving the arguments
On 09.03.21 05:45, hongzha1 via Xenomai wrote:
> Ask for switching back to oob mode once ptrace core tell that
> current is resuming from a stopped state, leaving space for
> other runnable RT threads of the process to take over.
>
> Signed-off-by: hongzha1
>
> diff --git
From: Jan Kiszka
Analogously to do_syscall_64.
Signed-off-by: Jan Kiszka
---
arch/x86/entry/common.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/x86/entry/common.c b/arch/x86/entry/common.c
index c93d6be8f3ac..dc90c7fb4b9b 100644
---
From: Jan Kiszka
I-pipe makes sure that arguments of compat calls are ordered just like
native calls. Dovetail does not. But it is better to use the kernel's
syscall_get_arguments for retrieving the arguments anyway. Introduce
pipeline_get_syscall_args to abstract that difference.
On 10.03.21 09:32, Jan Kiszka via Xenomai wrote:
> Hi Philippe,
>
> as already reported in the call today: Current dovetail, namely [1],
> does not take the different argument mappings into account when entering
> from a 32-bit app.
>
> I-pipe has [2] in the arch-spe
On 10.03.21 01:57, hongzha1 via Xenomai wrote:
> Initialise and start a real-time task on specified cpu or current
> cpu.
>
> Signed-off-by: hongzha1
>
> diff --git a/include/cobalt/kernel/rtdm/driver.h
> b/include/cobalt/kernel/rtdm/driver.h
> index 733c49df8..42daaa5b2 100644
> ---
Hi Philippe,
as already reported in the call today: Current dovetail, namely [1],
does not take the different argument mappings into account when entering
from a 32-bit app.
I-pipe has [2] in the arch-specific path to achieve that, but Dovetail
hooks into the generic path - too late for that. As
On 09.03.21 10:43, Stéphane Grosjean wrote:
> Hi,
>
> Thank you very much for your review.
>
>>> --- /dev/null
>>> +++ b/kernel/drivers/can/peak_canfd/Kconfig
>>> @@ -0,0 +1,7 @@
>>> +config XENO_DRIVERS_CAN_PEAK_CANFD
>>> + depends on XENO_DRIVERS_CAN && PCI
>>> + tristate "PEAK driver
On 08.03.21 18:02, Florian Bezdeka wrote:
> Implementation is heavily inspired by the sem_timedwait syscall,
> but expecting time64 based timespec / timeout.
>
> We need two new syscall handlers:
> - The native one (COBALT_SYSCALL()) to get 32 bit kernels time64
> aware. This handler is
On 08.03.21 18:02, Florian Bezdeka wrote:
> Introducing a new smokey plugin that can be extended for all kind of
> y2038 tests.
And what does this version test? Some more words on how the new syscall
is stressed would be valuable here.
>
> Signed-off-by: Florian Bezdeka
> ---
> configure.ac
On 08.03.21 19:11, Bezdeka, Florian (T RDA IOT SES-DE) wrote:
> On Mon, 2021-03-08 at 18:12 +0100, Jan Kiszka wrote:
>> On 08.03.21 18:02, Florian Bezdeka wrote:
>>> On systems using 32 bit for time_t the sem_timedwait syscall was broken
>>> because the function used for copying the timeout value
On 08.03.21 18:02, Florian Bezdeka wrote:
> On systems using 32 bit for time_t the sem_timedwait syscall was broken
> because the function used for copying the timeout value from userspace
> to kernel (=sem_fetch_timeout()) was always copying
> sizeof(struct timespec64).
>
> A 32 bit application
On 08.03.21 15:01, Philippe Gerum wrote:
>
> Jan Kiszka writes:
>
>> On 22.02.21 10:08, Philippe Gerum via Xenomai wrote:
>>>
>>> florian.bezd...@siemens.com writes:
>>>
On Sun, 2021-02-21 at 16:27 +0100, Philippe Gerum via Xenomai wrote:
> chensong via Xenomai writes:
>
>>>
From: Jan Kiszka
The former is not a target for latest Xenomai anymore, and the latter is
unmaintained by now.
Signed-off-by: Jan Kiszka
---
.gitlab-ci.yml | 32
1 file changed, 32 deletions(-)
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index
On 04.03.21 11:08, Philippe Gerum wrote:
>
> Philippe Gerum writes:
>
>> florian.bezd...@siemens.com writes:
>>
>>> On Thu, 2021-03-04 at 10:35 +0100, Philippe Gerum wrote:
florian.bezd...@siemens.com writes:
> On Sat, 2021-02-20 at 16:18 +0100, Philippe Gerum via Xenomai wrote:
On 08.03.21 13:42, Bezdeka, Florian (T RDA IOT SES-DE) wrote:
> On Mon, 2021-03-08 at 11:42 +0100, Jan Kiszka wrote:
>> On 04.03.21 19:33, florian.bezdeka--- via Xenomai wrote:
>>> On Thu, 2021-03-04 at 14:18 +, florian.bezdeka--- via Xenomai
>>> wrote:
Hi,
the attached kernel
On 22.02.21 10:08, Philippe Gerum via Xenomai wrote:
>
> florian.bezd...@siemens.com writes:
>
>> On Sun, 2021-02-21 at 16:27 +0100, Philippe Gerum via Xenomai wrote:
>>> chensong via Xenomai writes:
>>>
> +/*
> + * Our representation of time at the kernel<->user interface boundary
On 08.03.21 12:48, Jan Kiszka wrote:
> On 20.02.21 13:45, Philippe Gerum wrote:
>> From: Philippe Gerum
>>
>> Since the low-level tick management code is pipeline specific, we may
>> flatten the call stack by using the underlying pipeline API directly.
>>
>> At this chance, fix a uniprocessor
On 20.02.21 13:45, Philippe Gerum wrote:
> From: Philippe Gerum
>
> Since the low-level tick management code is pipeline specific, we may
> flatten the call stack by using the underlying pipeline API directly.
>
> At this chance, fix a uniprocessor build issue with IPIs.
>
> Signed-off-by:
On 20.02.21 13:45, Philippe Gerum wrote:
> From: Philippe Gerum
>
> In the same move, fix places which depend on such inclusion but fail
> to pull the related headers directly.
>
> Signed-off-by: Philippe Gerum
> ---
> include/cobalt/kernel/assert.h | 3 ---
> kernel/cobalt/heap.c |
On 20.02.21 13:45, Philippe Gerum wrote:
> From: Philippe Gerum
>
> Signed-off-by: Philippe Gerum
> ---
> .../cobalt/kernel/dovetail/pipeline/trace.h | 123 ++
> 1 file changed, 123 insertions(+)
> create mode 100644 include/cobalt/kernel/dovetail/pipeline/trace.h
>
> diff
On 20.02.21 13:45, Philippe Gerum wrote:
> From: Philippe Gerum
>
> In order to intimately connect Cobalt to the kernel, Dovetail allows
> us to extend the latter with data and procedures we need:
>
> - we can embed our own context information into a set of critical
> kernel data structures.
On 04.03.21 19:33, florian.bezdeka--- via Xenomai wrote:
> On Thu, 2021-03-04 at 14:18 +, florian.bezdeka--- via Xenomai
> wrote:
>> Hi,
>>
>> the attached kernel log was taken form a local qemu machine with
>> Xenomai build from the wip/dovetail branch. There is a failing selftest
>> (mixed
On 04.03.21 14:45, Stephane Grosjean via Xenomai wrote:
> This patch includes the driver that supports the CANFD interfaces of
> the PCAN-PCIe FD family. This driver is largely inspired by the peak_pciefd
> driver included in the kernel since version 4.12. Except for the
> differences related to
On 06.03.21 23:13, Vitaly Chikunov wrote:
> This is similar to upstream commit 9e6c3b63399dd ("e1000e: fix compiler
> warnings" by David Ertman). Fix compile error:
>
> ERROR: "__bad_udelay" [drivers/xenomai/net/drivers/e1000e/rt_e1000e.ko]
> undefined!
>
> Signed-off-by: Vitaly Chikunov
>
On 03.03.21 15:45, Leandro Bucci via Xenomai wrote:
> Hi, I noticed a very strange but also interesting fact. When a certain
> periodic task is executed, if the period is small (for example 0.5ms) I
> have that the execution times are more or less constant (about 5 micro
> seconds). If, on the
On 06.03.21 15:58, Philippe Gerum wrote:
> >
> > Jan Kiszka <mailto:jan.kis...@siemens.com>> writes:
> >
> >> On 05.03.21 12:38, Jan Kiszka via Xenomai wrote:
> >>> From: Jan Kiszka <mailto:jan
On 06.03.21 15:58, Philippe Gerum wrote:
>
> Jan Kiszka writes:
>
>> On 05.03.21 12:38, Jan Kiszka via Xenomai wrote:
>>> From: Jan Kiszka
>>>
>>> This is still needed to avoid that a real-time parent seems minor faults
>>> after forki
On 05.03.21 12:38, Jan Kiszka via Xenomai wrote:
> From: Jan Kiszka
>
> This is still needed to avoid that a real-time parent seems minor faults
> after forking for shared pages until they are finally unshared.
>
> This missing support became visible in Xenomai when ru
Hi Greg,
the pipeline is getting greener again but I just ran into this new issue:
https://source.denx.de/Xenomai/xenomai-images/-/jobs/234340
Seen before?
Quirin, Florian, as we were discussing whether such a warning would be
caught already: this answers it. We just need to see it on the
From: Jan Kiszka
A missing volatile caused some compiler versions (e.g. gcc-8) to skip
updating the variable inside the loop. At this chance, drop the
pointless and misleading usage of atomic_t for this variable.
Signed-off-by: Jan Kiszka
---
testsuite/smokey/sched-quota/sched-quota.c | 11
From: Jan Kiszka
Signed-off-by: Jan Kiszka
---
README.md | 2 +-
ci/gitlab-ci-base.yml | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/README.md b/README.md
index 19d39dd..69b3e13 100644
--- a/README.md
+++ b/README.md
@@ -13,7 +13,7 @@ from scratch.
From: Jan Kiszka
gitlab-ci does not tell us the value of the variables used in a job.
Print them explicitly so that they are easier to grab for local
reproduction.
Signed-off-by: Jan Kiszka
---
ci/artifacts.yml| 1 +
ci/no-artifacts.yml | 1 +
2 files changed, 2 insertions(+)
diff --git
1001 - 1100 of 2528 matches
Mail list logo
