It is possible that we call ieee80211_new_state_locked() again before
a previous task finished to completion (not run yet or unlocked in
between) since 5efea30f039c4 (and follow-up).
In either case we would overwrite the new state and argument in the vap.
While most drivers somehow deal with that (or not), LinuxKPI 802.11 compat
code has KASSERTs to keep net80211, LinuxKPI and driver/firmware state in
sync and they may trigger due to a missing transition (or more likely a
Enhance the wlandebug +state logging for these cases so they
are easier to debug.
While here remove the unconditional logging to the message buffer;
it has been here for a good decade but not helped to actually identify
and sort the problem.
Sponsored by: The FreeBSD Foundation