Re: Dovetail 7.1-rc6 updates pushed

On Wed, 2026-06-03 at 08:20 +0000, Bezdeka, Florian wrote:
> On Tue, 2026-06-02 at 11:43 +0200, Florian Bezdeka wrote:
> > On Mon, 2026-06-01 at 20:28 +0200, Philippe Gerum wrote:
> > > Florian Bezdeka <[email protected]> writes:
> > > 
> > > > On Mon, 2026-06-01 at 15:43 +0200, Philippe Gerum wrote:
> > > > > Florian Bezdeka <[email protected]> writes:
> > > > > 
> > > > > > Hi all,
> > > > > > 
> > > > > > I just pushed the following branch updates for Dovetail based on 7.1-
> > > > > > rc6:
> > > > > > 
> > > > > > Dovetail:
> > > > > > wip/flo/v7.1-dovetail-rebase
> > > > > > wip/flo/v7.1-dovetail-rebase+riscv
> > > > > > 
> > > > > > Evl:
> > > > > > wip/flo/v7.1-evl-rebase
> > > > > > wip/flo/v7.1-evl-rebase+riscv
> > > > > > 
> > > > > > The +riscv branches are containing v8 of Tobias' riscv enabling series,
> > > > > > maybe we need v9, let's see.
> > > > > > 
> > > > > > Any additional testing on those branches is highly appreciated.
> > > > > > 
> > > > > > @Philippe:
> > > > > > I'm still waiting for some feedback for [1]. That seems now to be a
> > > > > > invalid combination of kconfigs, which is dovetail specific. Upstream
> > > > > > thread at [2].
> > > > > > 
> > > > > > Can you remember why KVM_INTEL is not selecting X86_FRED in case
> > > > > > IRQ_PIPELINE is enabled? I haven't checked the details yet, nor tried to
> > > > > > remove the dovetail specific adjustment.
> > > > > > 
> > > > > 
> > > > > Maybe because the pipeline never supported X86_FRED, doing so would
> > > > > required to rework the irq-entry trampoline macros, which is deemed
> > > > > painful work.
> > > > 
> > > > I sent out a RFC patch for that, input welcome.
> > > > 
> > > > Meanwhile I can provide some updates on the testing part. The following
> > > > problems seem to be reproducible on 7.1-rc5 and 7.1-rc6 - while 7.1-rc4
> > > > was fine (at least once):
> > > > 
> > > > x86   x3: Test timeout. Something seems slower than expected.
> > > > arm64 x4: Same problem
> > > > 
> > > > To rule out problems in our CI setup I spawned some 7.0 tests, which
> > > > were fine, at least twice in a row. Seems someone has to look into that.
> > > > As I'm running out of time: Any resources available?
> > > > 
> > > 
> > > Not here, at least not yet.
> > 
> > I scheduled a couple of overnight test runs on -rc4. Those test are
> > looking OK. Something in -rc5 seems to trigger that. The problem seems
> > qemu/kvm specific, test runs on real hardware were OK.
> > 
> > I found a couple of recent discussions around VMX/SVM regressions, some
> > of them related to the delayed hrtimer arming. As we disable the delayed
> > arming completely, that should not be our problem. Maybe we should just
> > wait for -rc7?
> 
> The last remaining problem for now:
> 
> 2026-06-02T22:14:24 proxy-poll: OK
> 2026-06-02T22:15:07 [  116.129252] bcmgenet fd580000.ethernet end0: NETDEV WATCHDOG: CPU: 2: transmit queue 4 timed out 3700 ms
> 
> That was taken from an evl test on rpi4, the same happens (without
> watchdog warning) on arm64-qemu. Seems the system is dead afterwards.

Short update:

All branches have been updated again. All branches are based on -rc7
now. Tests are looking good now. There was one issue on arm64 remaining.
The entry code got some refactorings which needed some pipelining
adjustments (see patch on the list, [3]).

Pending: Feedback for the arm64 modifications. See [3]. Already part of
the 7.1 branches.

Pending: Feedback for the x86 build failures related to FRED [4].
Already part of the 7.1 branches.

Pending: Feedback for the arm pipelining fixes [5]. Not yet part of any
7.1 branch.

With that I'm considering my part as done. Waiting for some riscv
updates, which should be easy to handle.

Florian

[3] https://lore.kernel.org/xenomai/[email protected]/
[4] https://lore.kernel.org/xenomai/[email protected]/T/
[5] https://lore.kernel.org/xenomai/20260610-wip-flo-v7-1-arm-pipelining-fixes-v2-0-62c9c477f8f2@siemens.com/