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:
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
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 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
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
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,
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
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
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
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
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
> >
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
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: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
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 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
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),
23 matches
Mail list logo
