This mailing list is temporarily disabled, until the migration to
xeno...@lists.linux.dev [1] is complete.
As mentioned in earlier notices, the existing subscriptions to
xenomai@xenomai.org will NOT be automatically transferred to the new
server. If you want to keep on receiving e-mails from the
Russell Johnson via Xenomai writes:
> The app that I am currently working with has an interrupt scheme as follows:
> device on the PCIe bus sends an interrupt to the CPU, our linux driver then
> has an MSI interrupt handler (will be replaced by the EVL oob interrupt
> handler), the handler then
Jan Kiszka writes:
> On 15.06.22 09:54, Philippe Gerum wrote:
>>
>> Jan Kiszka via Xenomai writes:
>>
>>> On 23.05.22 16:04, Gunter Grau via Xenomai wrote:
>>>> From: Gunter Grau
>>>>
>>>> When mapping io memory into use
Jan Kiszka via Xenomai writes:
> On 23.05.22 16:04, Gunter Grau via Xenomai wrote:
>> From: Gunter Grau
>>
>> When mapping io memory into userspace an extra simulated pagefault for all
>> pages is added to prevent later pagefaults because of copy on write
>> mechanisms. This happens only on a
Russell Johnson writes:
> [[S/MIME Signed Part:Undecided]]
> Apologies. Here you go.
>
> From 452e8b2ca8ecd53571a6b1f5d8b9ab23cd67f99d Mon Sep 17 00:00:00 2001
> From: Russell Johnson
> Date: Tue, 14 Jun 2022 08:10:14 -0600
> Subject: [PATCH] fixing conflict with C++ [[fallthough]], and maybe
Russell Johnson via Xenomai writes:
> Am I correct in assuming that any dynamic allocation in an EVL thread needs
> to use the EVL heap in order to avoid in-band context switching?
>
>
>
> There are 4 calls in particular that I am using from the EVL heap API:
> evl_init_heap (on startup), evl
Jan Kiszka writes:
> On 14.06.22 16:18, Russell Johnson via Xenomai wrote:
>> From 452e8b2ca8ecd53571a6b1f5d8b9ab23cd67f99d Mon Sep 17 00:00:00 2001
>> From: Russell Johnson
>> Date: Tue, 14 Jun 2022 08:10:14 -0600
>> Subject: [PATCH] fixing conflict with C++ [[fallthough]], and maybe at some
Russell Johnson writes:
> [[S/MIME Signed Part:Undecided]]
> From 452e8b2ca8ecd53571a6b1f5d8b9ab23cd67f99d Mon Sep 17 00:00:00 2001
> From: Russell Johnson
> Date: Tue, 14 Jun 2022 08:10:14 -0600
> Subject: [PATCH] fixing conflict with C++ [[fallthough]], and maybe at some
> point in the futu
Russell Johnson writes:
> [[S/MIME Signed Part:Undecided]]
> This is what I have been using. I have tested it and it seems to work fine.
>
> Thanks,
>
> Russell
>
> diff --git a/benchmarks/hectic.c b/benchmarks/hectic.c
> index 6b6b3b5..886f7d2 100644
> --- a/benchmarks/hectic.c
> +++ b/benchm
Julien Blanc writes:
> Le mardi 14 juin 2022 à 09:44 +, Bezdeka, Florian a écrit :
>>
>> Based on the kernel's fallthrough, introducing evl_fallthrough would
>> avoid all kinds of conflicts (IMHO):
>>
>> #ifndev evl_fallthrough
>> #if __has_attribute(__fallthrough__)
>> # define evl_fallt
Julien Blanc writes:
> Le mardi 14 juin 2022 à 10:04 +0200, Philippe Gerum a écrit :
>> Julien Blanc <
>> julien.bl...@sprinte.eu
>> > writes:
>>
>> > Le mardi 14 juin 2022 à 08:54 +0200, Philippe Gerum a écrit :
>> > > Julien Blanc via
Julien Blanc writes:
> Le mardi 14 juin 2022 à 08:54 +0200, Philippe Gerum a écrit :
>> Julien Blanc via Xenomai
>> >
>> > #define __fallthrough __attribute__((fallthrough))
>> >
>>
>> 6.39. attribute syntax
>> https://gcc.gnu.org
Julien Blanc via Xenomai writes:
> Le lundi 13 juin 2022 à 14:39 +, Russell Johnson via Xenomai a
> écrit :
>> I use boost throughout my entire app, so I need
>> to figure how to get both of these libraries to play nice with each
>> other. Any ideas? ( I am using gcc 8.3 and boost 1.70.0)
Based on v5.19-rc1 ATM [1]. The current EVL tree is going to be rebased
on it shortly.
[1] https://source.denx.de/Xenomai/linux-dovetail/-/tree/v5.19-dovetail-rebase
--
Philippe.
Davide Valeri writes:
> Hi!
> We need your help once more.
> We cannot enable SPI in the built kernel. Neither "sudo raspi-config"
> nor manually editing "config.txt" worked.
>
> Using "raspi-config" results in
> "mount: /config/device-tree: mount point does not exist
> * Failed to mount config
Jan Kiszka writes:
> On 26.05.22 18:19, Philippe Gerum wrote:
>>
>> jamiens...@163.com writes:
>>
>>> From: Jamie Huang
>>>
>>> In v5.18-evl-rebase, function kernel_fpu_disabled() has been removed in
>>> commit 59f5ede3bc0f(&qu
Jussi Viiri via Xenomai writes:
> From 2c9979487f50ce3e6d38c7fa69f5ad5de4c60474 Mon Sep 17 00:00:00 2001
> From: Jussi Viiri
> Date: Tue, 7 Jun 2022 21:00:19 +0300
> Subject: [PATCH] Make Sched* struct fields public so they can be constructed
>
Merged, thanks.
--
Philippe.
Russell Johnson via Xenomai writes:
> Hello,
>
>
>
> I am currently working on porting my realtime threads in my app to EVL. I am
> using "evl ps -l" to track whether or not there are any in-band switches on
> my EVL threads. Is there any recommended tool or method for tracking down
> what sp
Philippe Gerum writes:
> Jan Kiszka writes:
>> Do you have some
>> example code somewhere as well?
>>
>
> Not yet. I have started working on the 'revl' crate implementing the EVL
> interface for the Rust language though. There is not much
Philippe Gerum via Xenomai writes:
> Leonid Gasheev via Xenomai via Xenomai writes:
>
>> 03.06.2022 10:01, Philippe Gerum пишет:
>>> Leonid Gasheev via Xenomai via Xenomai writes:
>>>
>>>> 02.06.2022 18:44, Leonid Gasheev via Xenomai пишет:
>>
Leonid Gasheev via Xenomai via Xenomai writes:
> 03.06.2022 10:01, Philippe Gerum пишет:
>> Leonid Gasheev via Xenomai via Xenomai writes:
>>
>>> 02.06.2022 18:44, Leonid Gasheev via Xenomai пишет:
>>>> A series of patches extracted from v5.18-evl-rebase
Leonid Gasheev via Xenomai via Xenomai writes:
> 02.06.2022 18:44, Leonid Gasheev via Xenomai пишет:
>> A series of patches extracted from v5.18-evl-rebase has been applied
>> to the kernel version v5.18.1
>> toolchain/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin
>> Build for the arm64 ar
Jan Kiszka writes:
> On 31.05.22 15:37, Philippe Gerum via Xenomai wrote:
>>
>> I've been getting my feet wet with Rust for a few weeks now, assessing
>> the real-time latency figures I could get from an existing (C++)
>> application once fully rewritten in th
I've been getting my feet wet with Rust for a few weeks now, assessing
the real-time latency figures I could get from an existing (C++)
application once fully rewritten in this language. It turned out that
performance was on par with the original implementation with memory
safety on top, among o
jamiens...@163.com writes:
> From: Jamie Huang
>
> In v5.18-evl-rebase, function kernel_fpu_disabled() has been removed in
> commit 59f5ede3bc0f("x86/fpu: Prevent FPU state corruption"), so we will
> get compile error when CONFIG_DOVETAIL is enabled:
> arch/x86/kernel/fpu/core.c:931:6: error: i
The Xenomai mailing list server will be migrated to [1] on June 18
2022. In the meantime, the current server will be operating as
usual. However, the existing subscriptions to xenomai@xenomai.org will
NOT be automatically transferred to the new server.
This means that:
- The Xenomai mailing lis
"Bezdeka, Florian" writes:
> On Tue, 2022-05-17 at 09:53 +0800, Zqiang via Xenomai wrote:
>> The following modifications are mainly to add TSC function for TGPIO
>> and add intel-ehl-gpio driver divides and initializes the PSE TGPIO
>> resources.
>>
>> Christopher Hall (1):
>> x86/tsc: Add T
Sebastian Blaesing via Xenomai writes:
> Hi all,
>
> what is the best and fastest way to pass critical hardware Irq signal
> to control a semaphore in user space application?
>
> Is it possible that kernel and user space share a semaphore?
>
You do this indirectly: in the kernel driver which i
Roberto Ferri writes:
> Thanks for your fast response!
>
> I compiled with meson but I got this error message:
> ~/git/libevl/tests/observable-unicast.c:168:44: error: ‘EVL_CLONE_UNICAST’
> undeclared (first use in this function); did you mean ‘EVL_CLONE_INPUT’?
>
> Getting the same error in [
Philippe Gerum writes:
> Roberto Ferri via Xenomai writes:
>
>> Hello!
>>
>> My team and I are trying to build an EVL-based application on a *Raspberry
>> Pi 4B* [1] without success. We followed the steps reported in the guide [2]
>> to compile the code in
Philippe Gerum writes:
> Roberto Ferri via Xenomai writes:
>
>> Hello!
>>
>> My team and I are trying to build an EVL-based application on a *Raspberry
>> Pi 4B* [1] without success. We followed the steps reported in the guide [2]
>> to compile the code in
Roberto Ferri via Xenomai writes:
> Hello!
>
> My team and I are trying to build an EVL-based application on a *Raspberry
> Pi 4B* [1] without success. We followed the steps reported in the guide [2]
> to compile the code in [3].
>
> It would be great if you could tell us what we did wrong.
>
>
Kevin Hall via Xenomai writes:
> Hi,
>
>
> Is OOB I/O service a candidate for an EtherNet-based fieldbus protocol? I
> read in a comment that it only applies to VLAN-tagged IP protocols, but I
> don't know how old that is or if things have changed. I am able to send and
> receive packets when u
Giulio Moro via Xenomai writes:
> Hi everyone,
> From /proc/xenomai/sched/stat I infer there must be an internal struct
> somewhere keeping track of how much CPU time is actually used by each
> thread. Is there any way to access this kind of statistics from a
> running Xenomai user space progra
Ashwik John via Xenomai writes:
> Hi,
>
> What is the procedure to build and run the application with EVL? For
> example a fifo thread.
>
> #include
> #include
> #include
> #include
> #include
> #include
>
> int main(int argc, char *argv[])
> {
> struct sched_param param;
> int ret, tfd;
Jerry Huang via Xenomai writes:
> Hi, all guys,
> Now I am using linux-dovetail/v5.15.6-dovetail1-rebase on my RDB board.
> 1 . I am running latency command, but when I running command:
> latency -t 1 -T 30
> I got the negative value:
> RTD| -2.760| -2.654| -1.800| 0| 0|
Ashwik John via Xenomai writes:
> Hi,
>
> I have the same problem when running #evl test.
>
> basic-xbuf: OK
> clock-timer-periodic: OK
> clone-fork-exec: OK
> detach-self: OK
> duplicate-element: OK
> element-visibility: OK
> fault: OK
> fpu-preload: OK
> fpu-stress: OK
> heap-torture: OK
> ma
Philippe Gerum via Xenomai writes:
> Ashwik John via Xenomai writes:
>
>> Hi all,
>>
>> Please can you confirm if the EVL project site is broken? Will the website
>> be fixed soon or do we have another link. Thank you
>
> I'm on it.
Done.
--
Philippe.
Ashwik John via Xenomai writes:
> Hi all,
>
> Please can you confirm if the EVL project site is broken? Will the website
> be fixed soon or do we have another link. Thank you
I'm on it.
--
Philippe.
From: Philippe Gerum
The recent change regarding the tick proxy device [1] introduced a
regression in clockevents_exchange_devices(), causing a corruption of
the device release list.
This does not affect the logic of the previous fix which remains
correct though.
[1] tick: irq_pipeline: fix
Philippe Gerum writes:
> Jan Kiszka writes:
>
>> On 07.04.22 17:24, Philippe Gerum wrote:
>>>
>>> Jan Kiszka writes:
>>>
>>>> Hi Philippe,
>>>>
>>>> does this already ring some bell?
>>>>
>>>
Jan Kiszka writes:
> On 07.04.22 17:24, Philippe Gerum wrote:
>>
>> Jan Kiszka writes:
>>
>>> Hi Philippe,
>>>
>>> does this already ring some bell?
>>>
>>> https://source.denx.de/Xenomai/xenomai-images/-/jobs/419210
>&
Richard Weinberger writes:
> 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
"Bezdeka, Florian via Xenomai" writes:
> Hi Richard,
>
> On Fri, 2022-04-08 at 10:03 +0200, Richard Weinberger via Xenomai
> wrote:
>> +static int __run_extprog(struct smokey_test *t, int argc, char *const
>> argv[])
>> +{
>> +int ret;
>> +char *tst_path;
>> +
>> +ret = asprintf(&t
Jan Kiszka writes:
> On 07.04.22 13:16, Philippe Gerum wrote:
>>
>> Jan Kiszka writes:
>>
>>> On 06.04.22 17:56, Philippe Gerum via Xenomai wrote:
>>>> From: Philippe Gerum
>>>>
>>>> The current implementation does not
Jan Kiszka writes:
> Hi Philippe,
>
> does this already ring some bell?
>
> https://source.denx.de/Xenomai/xenomai-images/-/jobs/419210
>
> Only triggers with qemu-amd64, not on real HW and not with 5.15.
>
I could not reproduce locally, but visual inspection revealed something
fishy in #8e2c0
Philippe Gerum writes:
> a
> Jan Kiszka writes:
>
>> Hi Philippe,
>>
>> does this already ring some bell?
>>
>> https://source.denx.de/Xenomai/xenomai-images/-/jobs/419210
>>
>> Only triggers with qemu-amd64, not on real HW and not with 5.15
a
Jan Kiszka writes:
> Hi Philippe,
>
> does this already ring some bell?
>
> https://source.denx.de/Xenomai/xenomai-images/-/jobs/419210
>
> Only triggers with qemu-amd64, not on real HW and not with 5.15.
>
> Jan
8e2c09ee5323 is most likely causing this. It's a backport of the fix
developed fo
Jan Kiszka writes:
> On 06.04.22 17:56, Philippe Gerum via Xenomai wrote:
>> From: Philippe Gerum
>>
>> Regular threads should be allowed to write to RTIPC sockets provided
>> MSG_DONTWAIT is implicitly set for such a request. This would match
>>
Jan Kiszka writes:
> On 06.04.22 17:56, Philippe Gerum via Xenomai wrote:
>> From: Philippe Gerum
>>
>> Allow for sending a set of event bits to the heading waiter only,
>> instead of broadcasting them to all waiters.
>>
>> This change affects the ABI
Jan Kiszka writes:
> On 06.04.22 17:56, Philippe Gerum via Xenomai wrote:
>> From: Philippe Gerum
>>
>> The current implementation does not atomically consume+clear the event
>> set to be received by the waiter(s), which makes it useless for
>> anything but
From: Philippe Gerum
Regular threads should be allowed to write to RTIPC sockets provided
MSG_DONTWAIT is implicitly set for such a request. This would match
the existing behavior with other synchronization objects, such as
semaphores and events, avoiding unnecessary restrictions on usage
From: Philippe Gerum
cobalt_event_post() is about to be deprecated, rename to
cobalt_event_broadcast().
Signed-off-by: Philippe Gerum
---
lib/copperplate/eventobj.c | 2 +-
testsuite/smokey/events/events.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/lib
From: Philippe Gerum
Signed-off-by: Philippe Gerum
---
include/cobalt/sys/cobalt.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/cobalt/sys/cobalt.h b/include/cobalt/sys/cobalt.h
index 1035a29d52..5dde69da8a 100644
--- a/include/cobalt/sys/cobalt.h
+++ b/include/cobalt/sys
From: Philippe Gerum
The current implementation does not atomically consume+clear the event
set to be received by the waiter(s), which makes it useless for
anything but a plain one-time latch due to the race window this opens
with a consume[A]->signal[B]->clear[A] sequence.
To addres
From: Philippe Gerum
Allow for sending a set of event bits to the heading waiter only,
instead of broadcasting them to all waiters.
This change affects the ABI, since we add a set of operation flags to
the cobalt_event_sync service, to pass the new COBALT_EVENT_BCAST
flag. It also affects the
Sam Daniel via Xenomai writes:
> I recently made several config changes to my Xenomai config (trying to
> move from dev to prod, essentially) and now rtcanrecv issues this
> error:
> # rtcanrecv
>0"006.656| WARNING: [rtcanrecv] alchemy_init: failed to initialize
> Alchemy clock (res=1 ns)
Jan Kiszka writes:
> On 06.04.22 11:13, Wolfgang Denk via Xenomai wrote:
>> Dear Philippe,
>>
>> In message <87ee2colqg@xenomai.org> you wrote:
>>>
BTW: Do you have a Patchwork instance for the Xenomai mailing list?
>>>
>>> Unfortunately not.
>>>
I makes dealing with patch
s
"Chen, Hongzhan" writes:
>>-Original Message-
>>From: Philippe Gerum
>>Sent: Saturday, April 2, 2022 5:11 PM
>>To: Chen, Hongzhan
>>Cc: xenomai@xenomai.org
>>Subject: Re: [linux-dovetail PATCH 2/2] clocksource: GENERIC_CLOCKSOURCE_VDSO
Richard Weinberger via Xenomai writes:
> 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(&work->node.a_flags, flags, flags & ~IRQ_WORK_BUSY);
>
> So, writing to &work->node.a_flags failed.
> a
Richard Weinberger writes:
> - 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: reinstat
Richard Weinberger writes:
> - Ursprüngliche Mail -
>> Von: "Philippe Gerum"
>> An: "xenomai"
>> CC: "Philippe Gerum" , "Richard Weinberger"
>>
>> Gesendet: Sonntag, 3. April 2022 16:43:48
>> Betreff: [
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 tick_check_new_device() accordingly.
Signed-off-by: Philippe Gerum
---
kernel/time
From: Philippe Gerum
We have to fix up the TSS with the proper I/O bitmap settings in
arch_dovetail_switch_finish() when the incoming Dovetail-enabled task
is about to re-enter user mode.
This fixes an application crash observed when such a task would rely
on iopl() to raise its I/O permissions
Richard Weinberger writes:
> 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_inb
Richard Weinberger via Xenomai writes:
> 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
From: Philippe Gerum
The out-of-band switch tail code may need the thread-info work bits to
reinstate the current context appropriately, pass them to
arch_dovetail_switch_finish().
Signed-off-by: Philippe Gerum
---
kernel/sched/core.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions
From: Philippe Gerum
We have to fix up the TSS with the proper I/O bitmap settings in
arch_dovetail_switch_finish() when the current task is about to
re-enter user mode on the out-of-band stage, along with reloading the
fpu context if need be.
This fixes an application crash observed when a
From: Philippe Gerum
Signed-off-by: Philippe Gerum
---
arch/arm64/include/asm/dovetail.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/dovetail.h
b/arch/arm64/include/asm/dovetail.h
index 668679399406..f1c6605972cf 100644
--- a/arch/arm64/include
From: Philippe Gerum
Signed-off-by: Philippe Gerum
---
arch/arm/include/asm/dovetail.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/dovetail.h b/arch/arm/include/asm/dovetail.h
index 8f3a09391d06..ff754ff4d2db 100644
--- a/arch/arm/include/asm
From: Philippe Gerum
Dovetail does not cope well with paravirtualization ATM, which is why
XEN depends on !IRQ_PIPELINE. For the same reason, there is no point
in adding any IRQ trampoline code for XEN_PVHVM.
Also, prevent CONFIG_HYPERV from being built if interrupt pipeling is
enabled, since
From: Philippe Gerum
GENERIC_CLOCKSOURCE_VDSO is currently available for ARM and ARM64, but
some drivers which can export their clocksource via the vDSO can still
be built for unsupported architectures like x86.
Use a weak reverse dependency logic for vDSO-exported clocksources,
enabling
Hongzhan Chen via Xenomai writes:
> When making allyesconfig, there is duplication definication issue.
> To fix it, make them exclusive each other.
>
> Signed-off-by: Hongzhan Chen
> ---
> arch/x86/kernel/irq_pipeline.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --
Hongzhan Chen via Xenomai writes:
> Currently, GENERIC_CLOCKSOURCE_VDSO only supported well on ARM.
> To fix build issue like following when make allyesconfig on x86 platform.
>
> arch/x86/entry/vdso/../../../../lib/vdso/gettimeofday.c:145:14:
> error: implicit declaration of function clock_ope
Jan Kiszka writes:
> Hi Philippe,
>
> likely by accident: 5.10-dovetail-rebase lost disable_irq_if_pipelined /
> enable_irq_if_pipelined macros. 5.16 was affected as well, 5.15 and 5.17
> are not.
>
> Jan
Fixed upstream, thanks.
--
Philippe.
"Steub, Peter via Xenomai" writes:
> Hi all,
>
> I like to get evl running on a quadcore Atom box. I started with a
> standard ubuntu 20.04 installation
Which will almost never work out of the box on x86. Some options
commonly selected there will likely cause issues with any real-time
infrastr
Matt Klass via Xenomai writes:
> Using Xenomai 3.0.10, with kernel 4.9.128-05789, on armv7, we're having
> problems with the functionality of rtdm_waitqueues. The code was written by
> a Xenomai-adept developer who has since left for greener pastures.
>
> We have two functions that use rtdm_wai
Greg Pettit via Xenomai writes:
> I am cross compiling libevl and pass -Dprefix=/usr/evl during meson
> setup. The installed uapi headers are under /usr/evl/include as
> expected; however, the absolute meson build path precedes the uapi
> headers.
>
> For ex:
> /usr/evl/include/home/user/build
Evan Gates via Xenomai writes:
> Commit c70a9d9d536aefcf6574328aaac0fcc86f9ab0f7 added a test for
> $UAPI/include/uapi/evl that was meant to ensure the given $UAPI path was
> correct. That test meant that $UAPI had to point to a linux-evl source
> directory and could not point to installed hea
Richard Weinberger writes:
> 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
>>
Evan Gates via Xenomai writes:
> Commit c70a9d9d536aefcf6574328aaac0fcc86f9ab0f7 added a test for
> $UAPI/include/uapi/evl that was meant to ensure the given $UAPI path was
> correct. That test meant that $UAPI had to point to a linux-evl source
> directory and could not point to installed hea
Evan Gates via Xenomai writes:
> Commit c70a9d9d536aefcf6574328aaac0fcc86f9ab0f7 added a test for
> $UAPI/include/uapi/evl that was meant to ensure the given $UAPI path was
> correct. That test meant that $UAPI had to point to a linux-evl source
> directory and could not point to installed hea
Richard Weinberger via Xenomai writes:
> 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 F
Greg Pettit via Xenomai writes:
> I am setting up evl on a rpi4b using the following tags:
> linux-evl: v5.10.89-evl1-rebase
> libevl: r30
>
> During the install it appears that /uabi/evl/sched.h is getting overwritten
> by /uapi/evl/net/sched.h
> From meson install:
> ...
> Installing /home/pi
Russell Johnson via Xenomai writes:
> Hello,
>
> In my driver that I have been converting to support OOB functionality
> with the EVL core, I have an interrupt handler that handles all
> interrupts from a device sitting on the PCIe bus. I was reading
> through the information on your wiki about
Andrew via Xenomai writes:
> Hi,
>
> I am trying to work on a project that is easiest to accomplish if I base my
> changes on a product that is based on the mainline linux kernel 5.10.83.
>
> I will explain the steps I took to get to the version I am interested in:
>
> - I checkout the v5.10.y
0 X -
> 0.0 00:000.289 evl_dma_thread:12100
>
^^^
Means "relaxed", in-band mode. So the thread does switch out of oob mode
voluntarily for some reason.
> - Russell
>
> -----Original Mess
Russell Johnson via Xenomai writes:
> Hello,
>
> I have added the oob_ioctl file descriptor to my driver, and I have
> made sure that I call the necessary evl functions in the open()
> function in the driver as well. I have a test app in userspace that is
> simply opening the driver and issuing
Jan Kiszka writes:
> Hi Philippe,
>
> oob_trap_notify() only notifies if running oob [1]. But at [2], we are
> always in-band due to the check at [3], no? What was the idea behind
> placing a hook here?
>
As you noticed, [2] and its counterpart notifying about the end-of-trap
condition are sup
Russell Johnson via Xenomai writes:
> Hello,
>
> I currently have a linux driver used by my application that contains
> some global buffers that are updated based on various ioctl calls. If
> I add the EVL ioctl file descriptor to the driver, can I access the
> same buffer that is referenced by
Jan Kiszka writes:
> On 20.01.22 10:15, Bezdeka, Florian (T CED SES-DE) wrote:
>> On Thu, 2022-01-20 at 09:32 +0100, Philippe Gerum wrote:
>>> "Bezdeka, Florian" writes:
>>>
>>>> On Wed, 2022-01-19 at 13:35 +, Bezdeka, Florian via Xenomai
Philippe Gerum writes:
> Jan Kiszka writes:
>
>> On 11.06.21 20:05, Jan Kiszka via Xenomai wrote:
>>> From: Philippe Gerum
>>> Dovetail provides a fast service to escalate the caller to
>>> out-of-band
>>> mode for executing a routine (run_
Jan Kiszka writes:
> On 11.06.21 20:05, Jan Kiszka via Xenomai wrote:
>> From: Philippe Gerum
>> Dovetail provides a fast service to escalate the caller to
>> out-of-band
>> mode for executing a routine (run_oob_call()), which we use to enforce
>> primary mod
"Bezdeka, Florian" writes:
> On Thu, 2022-01-20 at 09:12 +0100, Philippe Gerum wrote:
>> Florian Bezdeka writes:
>>
>> > We have a test within the smokey testsuite which actually does
>> > something like
>> >
>&
"Bezdeka, Florian" writes:
> On Wed, 2022-01-19 at 13:35 +, Bezdeka, Florian via Xenomai wrote:
>> Hi all,
>>
>> after migrating from 4.19-ipipe to 5.10-dovetail internal users are
>> reporting that they receive sporadic SIGXCPUs. The reported reason is
>> "page_fault_user".
>>
>> After
"Bezdeka, Florian" writes:
> Hi all,
>
> after migrating from 4.19-ipipe to 5.10-dovetail internal users are
> reporting that they receive sporadic SIGXCPUs. The reported reason is
> "page_fault_user".
>
> After disabling the huge page support in 5.10 the issue vanished. Tests
> are still runn
Florian Bezdeka writes:
> We have a test within the smokey testsuite which actually does
> something like
>
>cobalt_monitor_init()
>cobalt_monitor_wait()
>cobalt_monitor_enter()
> -> timeout
>cobalt_monitor_exit()
>cobalt_monitor_destroy()
>
> If the posix_m
Jan Kiszka writes:
> On 09.01.22 19:15, Philippe Gerum via Xenomai wrote:
>>
>> Philippe Gerum writes:
>>
>>> From: Philippe Gerum
>>>
>>> With the addition of the Dovetail COW-breaking logic,
>>> page_needs_cow_for_dma() does n
From: Philippe Gerum
COW-disabling for a dovetailed process does not depend on the pinning
status of the source mm considered by copy_present_page(). Decouple
both checks, which fixes the following kernel splat on fork() from a
dovetailed task:
[ 18.376448] [ cut here
From: Philippe Gerum
COW-disabling for a dovetailed process does not depend on the pinning
status of the source mm considered by copy_present_page(). Decouple
both checks, which fixes the following kernel splat on fork() from a
dovetailed task:
[ 18.376448] [ cut here
1 - 100 of 1001 matches
Mail list logo
