On Tue, 28 May 2024 at 03:06, Bjoern A. Zeeb <b...@freebsd.org> wrote:
> On Mon, 27 May 2024, Adrian Chadd wrote: > > > On Mon, 27 May 2024 at 15:59, Bjoern A. Zeeb <b...@freebsd.org> wrote: > > > > Last I got fed up by SCAN problems this afternoon and started > >> investigating. Have other people (with iwn/iwm/iwlwifi or others) > noticed > >> the fact that once you are associated with a channel in a band (say > Channel > >> 6) you will not get scan results for 11a/5Ghz anymore? Or that > >> sometimes scanning will "just stop" (way beyond scanvalid interval) and > >> triggering a manual scan (or from wpa_cli) you either just get the old > >> cache > >> or EINPROGRESS? (checking ddb on-off I noticed that the scan got stuck > >> in ACTIVE or BGSCAN was on suddenly despite IEEE80211_FEXT_SCAN_OFFLOAD > >> is set given iwlwifi does hw_scan and we never enable background > >> scanning). > >> I know this has bugged me in the past a lot on iwm(4) on 8xxx chipsets > >> and ifconfig down/ifconifg mode auto/ifconfig up fixed it again. > >> In case more people have observed similar things, please let me know > >> so we can properly track this. > >> > > > > Oh, wow, this is still a problem? Aiee. I remember fixing a WHOLE lot of > > races > > in the non scan offload and the then-new scan full offload paths. > > > > I'll see if I can reproduce it on iwn(4) (which supports full scan > offload) > > You should know better given you introduced this .. > > Reproducing on iwn(4) will be hard unless you change the driver... > supports > (in theory) and "supports" (is implemented and working) .... just saying > ... > oh iwm, not iwn. Yeah, iwn supports it too, but i never got to that. Anyway. > > % grep -r IEEE80211_FEXT_SCAN_OFFLOAD sys/dev/ > sys/dev/iwm/if_iwm.c: ic->ic_flags_ext = IEEE80211_FEXT_SCAN_OFFLOAD; > sys/dev/usb/wlan/if_rsu.c: ic->ic_flags_ext |= > IEEE80211_FEXT_SCAN_OFFLOAD; > > It's a hacked up solution and scrolling through I found at least two > places where the logic seems wrong (and it's only what--8 checks in > total?). I think atomics are the least of my concerns here... > Oh yeah, the checks aren't all that great. A large part of the problem with the scan stuff is how it used to literally /sleep/ in the middle of doing it, rather than defer it into a state machine with callbacks. I'm unsurprised there are still bugs. :( -adrian
