Re: Dovetail 7.1-rc6 updates pushed

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.