Re: CONFIG_NO_HZ_FULL = y but still have arch-timer on isolation CPUs

Dear Hongzhan： My kernel is 4.19.165, indeed remove xenomai, the phenomenon is the same. Maybe it’s a bug in this kernel, and how can I trace this bug if it is fixed in some patch? Thank you. Ivan 在 2022/3/16 11:30，“Chen, Hongzhan” 写入: Hi Ivan Hope that what

RE: CONFIG_NO_HZ_FULL = y but still have arch-timer on isolation CPUs

Hi Ivan Hope that what discussed in https://stackoverflow.com/questions/60322119/completely-eliminating-the-timer-tick-in-modern-linux-5-0 may help you. Seems that there need do more settings for kernel parameters per your requirement but I have not tried myself. When you remove Xenomai,

Re: waitqueue vs. mutex behavior

On 15.03.22 19:27, Matt Klass via Xenomai wrote: > 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

Re: [PATCH] arm64: ipipe: Fix section mismatch of __ipipe_tsc_register

On Tue, Mar 15, 2022 at 3:00 PM Jan Kiszka wrote: > From: Jan Kiszka > > The kernel warns: > > The function dw_apb_clocksource_register() references > the function __init __ipipe_tsc_register(). > This is often because dw_apb_clocksource_register lacks a __init > annotation or the annotation of

Re: [PATCH] arm64: ipipe: Make erratum_1418040_thread_switch compatible with I-pipe

On Tue, Mar 15, 2022 at 2:56 PM Jan Kiszka wrote: > From: Jan Kiszka > > First of all, this erratum hook is called from __switch_to, thus > potentially also from the primary domain. Some of the functions it calls > check if preemption was disabled under Linux - which may not be the case > when

[PATCH] arm64: ipipe: Fix section mismatch of __ipipe_tsc_register

From: Jan Kiszka The kernel warns: The function dw_apb_clocksource_register() references the function __init __ipipe_tsc_register(). This is often because dw_apb_clocksource_register lacks a __init annotation or the annotation of __ipipe_tsc_register is wrong. Signed-off-by: Jan Kiszka ---

[PATCH] arm64: ipipe: Make erratum_1418040_thread_switch compatible with I-pipe

From: Jan Kiszka First of all, this erratum hook is called from __switch_to, thus potentially also from the primary domain. Some of the functions it calls check if preemption was disabled under Linux - which may not be the case when invoked from primary domain. Rather than adding a costly check

waitqueue vs. mutex behavior

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_waitqueue_lock/unlock on the same

Re: ipipe-5.4: arm64 regression

On 14.03.22 14:02, Greg Gallagher wrote: > > > On Mon, Mar 14, 2022 at 8:33 AM Jan Kiszka > wrote: > > On 04.03.22 00:45, Greg Gallagher wrote: > > > > > > On Thu, Mar 3, 2022 at 1:20 PM Jan Kiszka > >

Re: ipipe-5.4: arm64 regression

On 14.03.22 14:02, Greg Gallagher wrote: > > > On Mon, Mar 14, 2022 at 8:33 AM Jan Kiszka > wrote: > > On 04.03.22 00:45, Greg Gallagher wrote: > > > > > > On Thu, Mar 3, 2022 at 1:20 PM Jan Kiszka > >

Re: System hang on first PCIe MSI interrupt with I-pipe kernels newer than 4.14.62

On 3/15/22 7:32 AM, Jan Kiszka wrote: On 14.03.22 18:45, Scott Reed wrote: On 3/11/22 2:13 PM, Scott Reed via Xenomai wrote: On 3/11/22 12:38 PM, Jan Kiszka wrote: On 11.03.22 11:12, Scott Reed via Xenomai wrote: Hello, I am seeing an apparent issue with PCIe MSI interrupts and I-pipe

Re: [PATCH v8 0/4] Kernel-Shark and libtraceevent plugins

On 15.03.22 02:32, Chen, Hongzhan wrote: > Looks good to me. Thanks for your help. > Thanks for your effort! The last "few percentages" to get autoconf/automake integration were indeed tougher than I thought. Jan > Regards > > Hongzhan Chen > > -Original Message- > From: Jan Kiszka

Re: [PATCH] cobalt/sched: Use nr_cpumask_bits instead of BITS_PER_LONG

On 14.03.22 22:13, Bezdeka, Florian via Xenomai wrote: > On Mon, 2022-03-14 at 21:05 +, Bezdeka, Florian via Xenomai wrote: >> Hi Richard, >> >> On Mon, 2022-03-14 at 21:38 +0100, Richard Weinberger via Xenomai >> wrote: >>> BITS_PER_LONG is too broad, the max number of usable bits is limited

Re: System hang on first PCIe MSI interrupt with I-pipe kernels newer than 4.14.62

On 14.03.22 18:45, Scott Reed wrote: > > > On 3/11/22 2:13 PM, Scott Reed via Xenomai wrote: >> >> On 3/11/22 12:38 PM, Jan Kiszka wrote: >>> On 11.03.22 11:12, Scott Reed via Xenomai wrote: Hello, I am seeing an apparent issue with PCIe MSI interrupts and I-pipe when trying