[REGRESSION] mt7925: MLO connectivity silently stalls with 6GHz link active

[Devin Wittmayer]

On Mon, 2026-08-24 at 08:18 +0000, Jonas Hort wrote:
> Setup is still up and I can build and test whatever is useful.

Your bisect holds here, on a different machine and a different access
point, running your June firmware. Three states, each replicated:

  both commits reverted        clean, two runs of six minutes
  only the later one reverted  stalls, two runs
  neither reverted             stalls, three runs

Tail welded and head climbing, which is your signature. The tree is
7.2-rc5 with one unrelated ACPI patch of mine, nowhere near this path.

db134691924f lands fifteen commits after ff643b81bc38, and reverting it
alone still stalls, so the builder rewrite is the one that matters.
Reverting the builder on its own is not available either: v7.0's version
dereferences a link pointer that the later commit leaves unpublished
until after the firmware call, so it would need a check neither version
has.

A correction to my last message. I pointed you at the link count, since
the new code reports one link whenever the update concerns the primary.
That undercount is real but it's not the cause. Telling firmware one
link always is clean over two six-minute runs. Skipping the
undercounting update entirely, so firmware is never told anything wrong,
stalls on both runs. Writing the entries in v7.0's order stalls on all
three.

On the August firmware, stock still stalls, twice, the detector firing
95 and 141 seconds into the run.

The band pair matters. Same driver, same August firmware, two runs each:

  5 GHz + 6 GHz     stalls
  2.4 GHz + 5 GHz   clean, full duration
  2.4 GHz + 6 GHz   clean, full duration

Not the channel width. Narrowing the 5 GHz link to 40 MHz, so that pair
carries the same narrow-plus-wide mix as the clean ones, still stalls on
both runs.

The sharpest pair there is the two runs where the iperf3 stream never
established, leaving only the UDP pressure: 5 plus 6 stalled with the
queue peaking at 187, and 2.4 plus 6 stayed clean at 186. The other
three clean runs peaked above 1000.

Sean, the two things I can't see from out here: what firmware does with
a multi-link record naming one link while a second is associated, and
why 5 plus 6 should differ from 2.4 plus 6.

Jonas, thank you for the bisect. Five steps, every bad verdict confirmed
on the queue signature.

Devin