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
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
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 calls eventfd_signal() to alert the userspace
On 17.06.22 08:08, Jan Kiszka via Xenomai wrote:
> On 16.06.22 02:18, Hongzhan Chen via Xenomai wrote:
>> 1. When there is clockfreq param passed down via command line, we
>>do not update clockfreq even if we receive event of updating clockfreq.
>>Or else, we update the clockfreq with
On 16.06.22 02:18, Hongzhan Chen via Xenomai wrote:
> When there is refined tsc clock, notify Xenomai to apply it.
> Linux may schedule a delayed work to refine tsc clock and update
> tsc_khz which happen after Xenomai finsih init but tsc_scale and
> tsc_shift still keep the value depending on
On 17.06.22 08:09, Jan Kiszka via Xenomai wrote:
> On 16.06.22 02:18, Hongzhan Chen via Xenomai wrote:
>> When there is refined tsc clock, notify Xenomai to apply it.
>> Linux may schedule a delayed work to refine tsc clock and update
>> tsc_khz which happen after Xenomai finsih init but tsc_scale
On 16.06.22 02:18, Hongzhan Chen via Xenomai wrote:
> When there is refined tsc clock, notify Xenomai to apply it.
> Linux may schedule a delayed work to refine tsc clock and update
> tsc_khz which happen after Xenomai finsih init but tsc_scale and
> tsc_shift still keep the value depending on
On 16.06.22 02:18, Hongzhan Chen via Xenomai wrote:
> 1. When there is clockfreq param passed down via command line, we
>do not update clockfreq even if we receive event of updating clockfreq.
>Or else, we update the clockfreq with notified value.
> 2. At the same time, we would like to
1. When there is clockfreq param passed down via command line, we
do not update clockfreq even if we receive event of updating clockfreq.
Or else, we update the clockfreq with notified value.
2. At the same time, we would like to update clockfreq param showing
in sys filesystem after
When there is refined tsc clock, notify Xenomai to apply it.
Linux may schedule a delayed work to refine tsc clock and update
tsc_khz which happen after Xenomai finsih init but tsc_scale and
tsc_shift still keep the value depending on origianl tsc clock
which is outdated. The difference between
On 15.06.22 17:20, Jan Kiszka via Xenomai wrote:
> From: Jan Kiszka
>
> The signature of switch_fpu_finish changed in stable 5.4.
>
> Signed-off-by: Jan Kiszka
> ---
> kernel/cobalt/arch/x86/ipipe/thread.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git
On 15.06.22 18:00, Jan Kiszka via Xenomai wrote:
> From: Jan Kiszka
>
> This brings changes to image types that are easy to account for. Also
> the image file name changed, so adjust readme and start-qemu.sh.
>
> The update fixes logging issues, thus helps a lot with analyzing failing
> builds,
From: Jan Kiszka
This brings changes to image types that are easy to account for. Also
the image file name changed, so adjust readme and start-qemu.sh.
The update fixes logging issues, thus helps a lot with analyzing failing
builds, specifically in CI.
Signed-off-by: Jan Kiszka
---
README.md
From: Jan Kiszka
The signature of switch_fpu_finish changed in stable 5.4.
Signed-off-by: Jan Kiszka
---
kernel/cobalt/arch/x86/ipipe/thread.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/kernel/cobalt/arch/x86/ipipe/thread.c
b/kernel/cobalt/arch/x86/ipipe/thread.c
Hi!
Many thanks for your response, but unfortunately we're receiving the same error.
I was already using the config file as suggested from the resource you
provided, but still the compilation does not build the device trees
RPi4 needs.
So I compiled the official kernel source [1] (I tried with
Parts of the FPU tests were skipped when one of the following config
options was enabled, shadowing a real test issue that was triggered by
high load on the system. The options:
- CONFIG_X86_USE_3DNOW
- CONFIG_MD_RAID456
- CONFIG_MD_RAID456_MODULE
As the FPU initialization is fixed now, we
On x86 fp_regs_set() expects that the FPU state was initialized by
calling the fninit instruction. When running in kernel space in task
context there is no guarantee that the FPU was initialized. Under
heavy load / scheduling the test might fail and report a FPU
register corruption.
The new
Hi all,
this is the backport of the previously published FPU testing cleanup
series to the stable/3.0.x branch.
Patch 1 has been updated to match the supported architectures in the
3.0.x stable branch, Patch 2 is unmodified.
Best regards,
Florian
Florian Bezdeka (2):
x86:
On 15.06.22 10:30, Philippe Gerum wrote:
>
> 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 userspace an extra
Parts of the FPU tests were skipped when one of the following config
options was enabled, shadowing a real test issue that was triggered by
high load on the system. The options:
- CONFIG_X86_USE_3DNOW
- CONFIG_MD_RAID456
- CONFIG_MD_RAID456_MODULE
As the FPU initialization is fixed now, we
Hi all,
this is the backport of the previously published FPU testing cleanup
series to the stable/3.1.x branch.
Patch 1 has been updated to match the supported architectures in the
3.1.x stable branch, Patch 2 is unmodified.
Best regards,
Florian
Florian Bezdeka (2):
x86: cobalt/switchtest:
On x86 fp_regs_set() expects that the FPU state was initialized by
calling the fninit instruction. When running in kernel space in task
context there is no guarantee that the FPU was initialized. Under
heavy load / scheduling the test might fail and report a FPU
register corruption.
The new
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 userspace an extra simulated pagefault for all
pages is added to
Hi,
Your right, for io memory it does not make sense to do COW.
Nevertheless we see a page fault for each page after mapping on first access.
We also saw this at first when we used Xenomai 2.6 on 32bit arm, where it was
fixed.
It now happened again when porting to Xenomai3. I was hoping the
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 userspace an extra simulated pagefault for all
>>> pages is added to prevent later pagefaults because of
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
On 15.06.22 09:44, Bezdeka, Florian (T CED SES-DE) wrote:
> On Tue, 2022-06-14 at 20:11 +0200, Jan Kiszka wrote:
>> On 08.06.22 18:59, Bezdeka, Florian (T CED SES-DE) wrote:
>>> On Wed, 2022-06-08 at 17:02 +0200, Jan Kiszka wrote:
On 25.05.22 11:56, Florian Bezdeka wrote:
> Parts of the
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),
On 21.05.22 12:48, Philippe Gerum via Xenomai wrote:
>
> 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
On Tue, 2022-06-14 at 20:11 +0200, Jan Kiszka wrote:
> On 08.06.22 18:59, Bezdeka, Florian (T CED SES-DE) wrote:
> > On Wed, 2022-06-08 at 17:02 +0200, Jan Kiszka wrote:
> > > On 25.05.22 11:56, Florian Bezdeka wrote:
> > > > Parts of the FPU tests were skipped when one of the following config
> >
>-Original Message-
>From: Xenomai On Behalf Of Chen, Hongzhan via
>Xenomai
>Sent: Wednesday, June 15, 2022 9:29 AM
>To: Kiszka, Jan ; xenomai@xenomai.org
>Subject: RE: [Cobalt Xenoami3.1 PATCH 1/2] process: update clockfreq when
>receive corresponding event.
>
>
>
>>-Original
We have the Xenomai community call today.
Topics may include but are not limited to upstream/downstream project
plans, status updates, and technical discussions. It's an open online
meeting that anyone can join and ask questions.
Time:
Wednesday, Jun 15, 2022, UTC 7:00 AM
Paris, France CEST
>
>Xenomai is conceptually not known to I-pipe. This patch is about calling
>the well-defined kevent hook when the TSC frequency changes after a
>recalibration. ARM does something similar on frequency changes.
>
>> Linux may schedule a delayed work to refine tsc clock and update
>> tsc_khz which
>-Original Message-
>From: Jan Kiszka
>Sent: Wednesday, June 15, 2022 5:28 AM
>To: Chen, Hongzhan ; xenomai@xenomai.org
>Subject: Re: [Cobalt Xenoami3.1 PATCH 1/2] process: update clockfreq when
>receive corresponding event.
>
>On 27.05.22 08:22, Hongzhan Chen via Xenomai wrote:
>> 1.
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_alloc_block (may be called during realtime
On 27.05.22 08:22, Hongzhan Chen via Xenomai wrote:
> When there is refined tsc clock, notify Xenomai to apply it.
Xenomai is conceptually not known to I-pipe. This patch is about calling
the well-defined kevent hook when the TSC frequency changes after a
recalibration. ARM does something similar
On 27.05.22 08:22, Hongzhan Chen via Xenomai wrote:
> 1. When there is clockfreq param passed down via command line, we
>do not update clockfreq even if we receive event of updating clockfreq.
>Or else, we update the clockfreq with notified value.
> 2. At the same time, we would like to
On 08.06.22 18:59, Bezdeka, Florian (T CED SES-DE) wrote:
> On Wed, 2022-06-08 at 17:02 +0200, Jan Kiszka wrote:
>> On 25.05.22 11:56, Florian Bezdeka wrote:
>>> Parts of the FPU tests were skipped when one of the following config
>>> options was enabled, shadowing a real test issue that was
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 architectures that have defined the
>
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 at some
point in the future with the C2X standard
Signed-off-by:
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
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
> point in the future with
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
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 future with the C2X standard
---
benchmarks/hectic.c| 10 +-
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
> +++
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/benchmarks/hectic.c
@@ -336,7 +336,7 @@ static void *sleeper_switcher(void *cookie)
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
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_fallthrough
On Tue, 2022-06-14 at 11:01 +0200, Philippe Gerum via Xenomai wrote:
> 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
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 Xenomai
>> > > > #define __fallthrough
On Tue, 2022-06-14 at 08:29 +, Julien Blanc via Xenomai wrote:
> 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 Xenomai
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 Xenomai
> > > > #define __fallthrough __attribute__((fallthrough))
> > > >
> > >
> >
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/onlinedocs/gcc/Attribute-Syntax.html#Attribute-Syntax
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/onlinedocs/gcc/Attribute-Syntax.html#Attribute-Syntax
>
Not sure what you mean with
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)
I agree with your proposed fix.
-Original Message-
From: Julien Blanc
Sent: Monday, June 13, 2022 9:17 AM
To: Russell Johnson ; xenomai@xenomai.org
Subject: [External] - Re: compile conflict with Boost
CAUTION: This email originated from outside of the organization. Do not click
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)
>
> /opt/evl/include/evl/compiler.h:64:36:
I have a class that includes both and some boost headers.
Whenever I go to compile it, I get an error that looks like it has to do
with the definition of "fallthrough" in conflicting with the
definition of "fallthrough" in Boost. It compiles fine if there is no Boost
header in the class. I use
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
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 configfs - 2"
Commit linux-evl: 81e5b7be.
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("x86/fpu: Prevent FPU state corruption"), so we will
>>> get
>-Original Message-
>From: Jan Kiszka
>Sent: Thursday, June 9, 2022 1:48 PM
>To: Chen, Hongzhan ; xenomai@xenomai.org
>Subject: Re: [Cobalt Xenoami3.1 PATCH 0/2] notify Xenomai udpated clockfreq.
>
>On 09.06.22 04:06, Chen, Hongzhan wrote:
>>> -Original Message-
>>> From: Jan
On 09.06.22 04:06, Chen, Hongzhan wrote:
>> -Original Message-
>> From: Jan Kiszka
>> Sent: Wednesday, June 8, 2022 11:21 PM
>> To: Chen, Hongzhan ; xenomai@xenomai.org
>> Subject: Re: [Cobalt Xenoami3.1 PATCH 0/2] notify Xenomai udpated clockfreq.
>>
>> On 02.06.22 14:56, Chen, Hongzhan
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("x86/fpu: Prevent FPU state corruption"), so we will
>> get compile error when CONFIG_DOVETAIL is
>-Original Message-
>From: Jan Kiszka
>Sent: Wednesday, June 8, 2022 11:21 PM
>To: Chen, Hongzhan ; xenomai@xenomai.org
>Subject: Re: [Cobalt Xenoami3.1 PATCH 0/2] notify Xenomai udpated clockfreq.
>
>On 02.06.22 14:56, Chen, Hongzhan wrote:
>>
>>
>>> -Original Message-
>>>
On Wed, 2022-06-08 at 17:02 +0200, Jan Kiszka wrote:
> On 25.05.22 11:56, Florian Bezdeka wrote:
> > Parts of the FPU tests were skipped when one of the following config
> > options was enabled, shadowing a real test issue that was triggered by
> > high load on the system. The options:
> > -
On 23.05.22 16:19, Gunter Grau via Xenomai wrote:
> From: Johann Wiens
>
> As described in commit 04fab252f5d2ec3fe47be266f94714c3dda624bd, the
> fec driver was added with the intention to have it working on an
> i.MX8 target.
> But i.MX SoC specific quirks are also handled already since the
On 02.06.22 14:56, Chen, Hongzhan wrote:
>
>
>> -Original Message-
>> From: Jan Kiszka
>> Sent: Thursday, June 2, 2022 5:54 PM
>> To: Chen, Hongzhan ; xenomai@xenomai.org
>> Subject: Re: [Cobalt Xenoami3.1 PATCH 0/2] notify Xenomai udpated clockfreq.
>>
>> On 27.05.22 08:22, Hongzhan
On 27.05.22 23:48, Richard Weinberger via Xenomai wrote:
> On Fri, May 27, 2022 at 11:35 PM Konstantin Smola via Xenomai
> wrote:
>>
>> pci probe was overwriting baud_base with default values, ignoring baud_base
>> arguments passed in while loading driver.
>>
>> Signed-off-by: Konstantin Smola
On 25.05.22 11:56, Florian Bezdeka wrote:
> Parts of the FPU tests were skipped when one of the following config
> options was enabled, shadowing a real test issue that was triggered by
> high load on the system. The options:
> - CONFIG_X86_USE_3DNOW
> - CONFIG_MD_RAID456
> -
On 25.05.22 09:47, Florian Bezdeka wrote:
> FPU usage in kernel space was allowed / enabled with ipipe, but is no
> longer available for dovetail based kernels. That allows us to clean
> up the FPU related tests of the switchtest utility.
>
> fp_kernel_supported() can be removed as all supported
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.
On Fri, May 27, 2022 at 6:14 PM Daniel Wagner wrote:
> > Whoops, old date.
> > 10. June to 12. June 2022 it is.
> Here some more details about this event (hint if you want to attend
> please let us know).
Please prepare for bad weather, in the mountains the situation can
change quickly… The
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
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
---
src/sched.rs | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff
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 specifically is causing the in-band switches on an EVL
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 of it yet
> (clock services based on the
04.06.2022 17:07, Philippe Gerum пишет:
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 пишет:
A series of patches
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 пишет:
> A series of patches extracted from
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 has been applied
to the kernel
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 has been applied
to the kernel version v5.18.1
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
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 architecture is completed successfully.
But for arm:
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 architecture is completed successfully.
But for arm:
arch/arm/kernel/irq.c: In function
>-Original Message-
>From: Jan Kiszka
>Sent: Thursday, June 2, 2022 5:54 PM
>To: Chen, Hongzhan ; xenomai@xenomai.org
>Subject: Re: [Cobalt Xenoami3.1 PATCH 0/2] notify Xenomai udpated clockfreq.
>
>On 27.05.22 08:22, Hongzhan Chen via Xenomai wrote:
>> When there is refined tsc clock,
On 27.05.22 08:22, Hongzhan Chen via Xenomai wrote:
> When there is refined tsc clock, notify Xenomai to apply it.
> Linux may schedule a delayed work to refine tsc clock and update
> tsc_khz which happen after Xenomai finsih init but tsc_scale and
> tsc_shift still keep the value depending on
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 this language. It turned out that
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 this language. It turned out that
> performance was on par with
On 01.06.22 05:22, Chen, Hongzhan via Xenomai wrote:
>
> We have the Xenomai community call today.
>
> Topics may include but are not limited to upstream/downstream project
> plans, status updates, and technical discussions. It's an open online
> meeting that anyone can join and ask questions.
We have the Xenomai community call today.
Topics may include but are not limited to upstream/downstream project
plans, status updates, and technical discussions. It's an open online
meeting that anyone can join and ask questions.
Time:
Wednesday, Jun 1, 2022, UTC 7:00 AM
Paris, France CEST
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
> -Ursprüngliche Nachricht-
> Von: Chen, Hongzhan [mailto:hongzhan.c...@intel.com]
> Gesendet: Montag, 30. Mai 2022 10:44
> An: Prasanna Kannan ;
> xenomai@xenomai.org
> Betreff: RE: Difference between Xenomai timer and Linux clock
>
>
>
> >-Original Message-
> >From: Prasanna
>-Original Message-
>From: Prasanna Kannan
>Sent: Monday, May 30, 2022 3:33 PM
>To: Chen, Hongzhan ; xenomai@xenomai.org
>Subject: AW: Difference between Xenomai timer and Linux clock
>
>> -Ursprüngliche Nachricht-
>> Von: Chen, Hongzhan [mailto:hongzhan.c...@intel.com]
>>
> -Ursprüngliche Nachricht-
> Von: Chen, Hongzhan [mailto:hongzhan.c...@intel.com]
> Gesendet: Montag, 30. Mai 2022 02:56
> An: Prasanna Kannan ;
> xenomai@xenomai.org
> Betreff: RE: Difference between Xenomai timer and Linux clock
>
>
>
> >-Original Message-
> >From: Xenomai On
>-Original Message-
>From: Xenomai On Behalf Of Prasanna Kannan via
>Xenomai
>Sent: Friday, May 27, 2022 9:39 PM
>To: xenomai@xenomai.org
>Subject: Difference between Xenomai timer and Linux clock
>
>Hello Everybody,
>
>I am comparing the Xenomai Timer(rt_timer_read()) and
On Fri, May 27, 2022 at 1:34 AM Richard Weinberger wrote:
> - Ursprüngliche Mail -
> > An update:
> > If the 16550A driver is modprobed with no arguments, it apparently
> > probes the PCI subsystem, gets the irq, and interrupts are enabled OK.
> > The serial port can send/receive data.
>
On Fri, May 27, 2022 at 11:35 PM Konstantin Smola via Xenomai
wrote:
>
> pci probe was overwriting baud_base with default values, ignoring baud_base
> arguments passed in while loading driver.
>
> Signed-off-by: Konstantin Smola
> ---
> kernel/drivers/serial/16550A_pci.h | 3 ++-
> 1 file
pci probe was overwriting baud_base with default values, ignoring baud_base
arguments passed in while loading driver.
Signed-off-by: Konstantin Smola
---
kernel/drivers/serial/16550A_pci.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kernel/drivers/serial/16550A_pci.h
1 - 100 of 26550 matches
Mail list logo
