A related but more severe manifestation on the same machine family — one that ends in a kernel panic rather than a display that merely fails to light up. Configuration MacBook Pro Mac17,9, M5 Pro, 48 GB. Reproduced on macOS 27.0 (26A428), 27.0.1 (26A434) and 27.2 (26B123). Ugreen TBT5 Docking Station 17-in-1, firmware 64.64, on receptacle 1 at 80 Gb/s. Two identical 3840x2160@60 Hz DisplayPort monitors on the dock. Their EDIDs carry the same numeric serial number; only the alphanumeric serial string differs. Regression: the same dock and monitors, used identically, never showed this on macOS 26.x. First occurrence was one week after upgrading to macOS 27 (2026-09-15). Not third-party software: it reproduced on 2026-10-26/27 with no display utility running at all. What happens Trigger is a display wake. After waking, both monitors drop and re-assert HPD within a few seconds; at some of these wakes the bandwidth-allocation request for one DP OUT adapter never completes. The adapter is then stuck. The kernel logs this at about 10 Hz, indefinitely: Thunderbolt DP - evaluating for > 1m - DPO [0:0x1:0x13] - UNEXPECTED ERROR! NE=1 NPBWAR=1 NPCU=0 NPHPDS=0 NPNHPDS=0 DDPSNE=0 HPDS=1 NHPDS=0 DPS=2 DDPS=2 T=0 FW=0 Slp=0 EWk=0 LSlp=0 FA=0 FL=0 HPDT=0IORegistry (AppleThunderboltDPOutAdapterOS2) shows the stuck adapter with Evaluation In Progress = Yes, Need Evaluation = Yes, HPD State Needs Processing = Yes, DPI BWAM Support = Yes; its sibling in the same Group ID 1 is queued behind it (Need To Process Connection Up Message = Yes). Where it waits. The stack is: AppleThunderboltDPConnectionManager::evaluateConnections -> DPOutAdapterCM::doSynchronousEvaluation -> sleepGate -> processBandwidthAllocationRequest -> IOThunderboltController::configPollDWordWithMaskThe poll returns dptx_poll_status = 0xe00002d6 (kIOReturnTimeout) and the evaluation keeps going after each timeout instead of giving up. Dock teardown (IOThunderboltConnectionManager::rescan -> terminateInvalidClientsOnPort -> DPOutAdapter::requestTerminate) blocks on the same gate. Per the USB4 register layout the DPTX Request bit lives in the DP IN adapter of the host router, so the handshake that never completes appears to be between the Mac's own display engine and its own DP IN adapter — not the dock. For comparison, Linux usb4_dp_port_wait_and_clear_cm_ack polls the same bit and gives up after 500 ms. Consequences. The monitor that needs re-processing never returns without a reboot. Unplugging the dock leaves ghost displays (they are never removed). About 60 s after the dock is plugged back in — any port — or after the next wake, the system panics: panic: busy timeout[0], (60s): multiple entries holding the registry busy, IOKit termination queue depth 0: 'IOThunderboltPort' (1,400001) ... @IOService.cpp:6140Clearest case (2026-10-28, macOS 27.2). Dock unplugged at 14:01:37 and neither display was removed; plugged into a different port at 14:37:48; panic at 14:38:50. The stackshot has three kernel threads in AppleThunderboltDPOutAdapter / AppleThunderboltDPAdapterFamily / IOThunderboltFamily, all in TH_WAIT. One (tid 863557) has lastRunTime 2232.6 s — it has not run since the second of the unplug. The DPAdapterFamily thread (tid 800266) last ran 1.6 s before the panic and had accumulated 2.66 s of system time, roughly ten times its counterpart in a 14-minute wedge on 10-27, consistent with it spinning for a long time. Relationship to existing reports. This looks like the same machine family and the same identical-pair configuration discussed in thread 814201 (FB21777337 / FB22844211 / FB25242110) and in the macOS 27 fix 176292156 note about "two identical displays (same model and serial number)". In those reports the second display simply fails to light up or is bandwidth-degraded. Here both displays come back, and the failure is that a bandwidth-allocation handshake never completes and holds the connection manager's gate indefinitely. Expected. A bandwidth-allocation handshake that does not complete should time out and fall back (release or re-establish the tunnel, or retry later). It should not hold the connection manager's gate forever, and dock teardown must not block behind it. Filed as FB25346775 with both panic-full reports (10-27 15:36 and 10-28 14:38) and Feedback Assistant system diagnostics. Happy to supply a sysdiagnose captured live during a wedge, or to run any debug profile that would help.