On Wed, 27 Aug 2025, Andriy Gapon wrote:
It seems that on the latest CURRENT, ifconfig wlan0 scan, executed while
associated, just hangs indefinitely.
I recall that it used to work in the past (possibly losing association while
scanning).
ifconfig's stack looks like it's waiting to receive something (over
netlink?):
PID TID COMM TDNAME KSTACK
43416 100469 ifconfig - mi_switch+0x188
sleepq_switch+0xec sleepq_catch_signals+0x2bc sleepq_wait_sig+0xc
_sleep+0x260 soreceive_generic_locked+0x1cc soreceive_generic+0xa8
soreceive+0x48 dofileread+0x74 kern_readv+0x4c sys_read+0x88
do_el0_sync+0x618 handle_el0_sync+0x4c
Looks like it regressed in April/May time frame.
Just in case, the hardware is rtwn on USB.
We used to leak BGSCANs even when disabled (32af70fae827ec) but with rtwn
that shouldn't be the problem as it is enabled by default if I do not
misremeber.
But the problem isn't new; even with iwm years ago scans sometimes used
to hang. ^c works, sometimes with multiple persuasions and waiting a
few seconds.
What you are saying is basically that there's more paths we leak some
scan state most likely and will scan "forever" without scanning.
If you try to scan from wpa_cli you get a BUSY back?
If you could break to ddb when in that state and do
show all vaps
show com /a <vap pointer>
I think it is (from memory) and gather the full state, that would be
great, at least to see if I am correctly guessing.
/bz
--
Bjoern A. Zeeb r15:7
