DWC3 runtime role swap

The shape of the wedge — hw_done timed out, drm_modeset_is_locked failures — is identical to a wedge documented from 2026-04-27 in the cross-driver audit. That older wedge was theorised to be DMA stomping a live driver during chip reset. Same theory here: snps_dwc3_reset does GCTL.CORESOFTRESET, which clobbers the chip-side gadget DMA descriptors. The gadget kproc is still running, the gadget IRQ handler is still installed, and there’s a TX watchdog callout — all looking at descriptors that just got rugged.

Write 5db9a9c dwc3: park gadget before chip soft-reset on role swap : dwc3_gadget_quiesce(device_t) — drops D+ via DCTL.RUN_STOP=0, waits for DSTS.DEVCTRLHLT, masks GEVNTSIZ.INTMASK, zeros DEVTEN, drains the TX watchdog, walks sc->eps[] setting started=0, brings the ifnet down. DMA tags and the usbus child stay attached — the cheap version of detach.

Update role_swap to call dwc3_gadget_quiesce before snps_dwc3_reset. Build, deploy, fire.

Same wedge. dwc3_gadget_quiesce: parked makes it to the screen, then the same DRM cascade hits. The DMA-stomping theory was wrong, or at least insufficient.

If quiesce is doing its job, then the wedge happens between quiesce returning and the next visible printf. That gap is snps_dwc3_reset (∼5 ms of DELAYs) + snps_dwc3_configure_host + snps_dwc3_do_quirks + snps_dwc3_attach_xhci. None of those should take 10 seconds. But hw_done timed out is a 10 second timeout. So somebody is blocking the vblank IRQ for ten seconds, or something inside attach_xhci is hanging long enough that an in-flight DRM atomic commit times out waiting for a flip.

A photo from the bench shows a cur_vblank != vblank->last failed at .../drm_vblank.c:348 line right above the role_swap output — vblank counters disagreeing. That fires when the kernel reads the hardware vblank counter and finds it didn’t advance the way the software state expected. Vblank IRQs are being lost. Combined with a separate patch we’d landed earlier ( fb81d0f rk_vop: mask vblank interrupts when idle — rk_vop: mask vblank interrupts when idle), the theory becomes: sway is mid-flip when role_swap fires, the role_swap thread blocks the vblank handler somehow, the flip times out 10 s later, the helper logs the cascade.

Test: SIGSTOP the entire sway tree before triggering role_swap. No compositor → no in-flight commits → no hw_done timeout.

Same wedge. Compositor ruled out. The DRM warnings are a symptom, not the cause.

If it’s not DMA and not the compositor, then it’s something inside the kernel role_swap path itself, blocking long enough that vt(4)‘s own console writes (every WARN, every ERROR) eventually trip the framebuffer atomic-commit path because the console output queue is what’s actually wedged.

Add device_printfs around every step:

device_printf(sc->dev, "role_swap: step 1/5 snps_dwc3_reset\n");
snps_dwc3_reset(sc);
device_printf(sc->dev, "role_swap: step 2/5 configure_host\n");
snps_dwc3_configure_host(sc);
/* ... step 3/5, step 4/5 ... */

And inside snps_dwc3_attach_xhci:

device_printf(dev, "attach_xhci: alloc_irq\n");
sc->sc_irq_res = bus_alloc_resource_any(dev, SYS_RES_IRQ, &rid,
    RF_SHAREABLE | RF_ACTIVE);
device_printf(dev, "attach_xhci: add_child usbus\n");
sc->sc_bus.bdev = device_add_child(dev, "usbus", DEVICE_UNIT_ANY);
device_printf(dev, "attach_xhci: setup_intr\n");
/* ... */

That’s ecedc69 dwc3: instrument role_swap so the next wedge tells us where it hangs . Build, deploy, fire. The bench photo:

role_swap: parking gadget, resetting chip, attaching xhci
dwc3_gadget_quiesce: parking gadget for chip reset
dwc3_gadget_quiesce: parked
role_swap: step 1/5 snps_dwc3_reset
role_swap: step 2/5 configure_host
role_swap: step 3/5 do_quirks
role_swap: step 4/5 attach_xhci
attach_xhci: alloc_irq         ← LAST PRINTF
WARNING list_empty(&lock->head) failed at .../drm_modeset_lock.c:268
... cascade ...

The wedge is between the alloc_irq printf (which runs before bus_alloc_resource_any) and the add_child usbus printf (which runs after it). Two candidates: bus_alloc_resource_any is hanging, or bus_alloc_resource_any returned and device_printf("add_child usbus") itself is hanging because the console path is already blocked behind something.

Tighter: add matching “end” prints ( 7cda476 dwc3: tighter instrumentation — print before AND after each call ):

device_printf(dev, "attach_xhci: alloc_irq begin\n");
sc->sc_irq_res = bus_alloc_resource_any(...);
device_printf(dev, "attach_xhci: alloc_irq end res=%p\n", sc->sc_irq_res);

Bench photo, 7cda476 dwc3: tighter instrumentation — print before AND after each call kernel:

... step 4/5 attach_xhci ...
attach_xhci: alloc_irq begin   ← LAST PRINTF
WARNING ...

alloc_irq end never prints. bus_alloc_resource_any itself is the wedge.