rtwn: ensure TX work isn't scheduled during reset / abort

[adrian]

Summary

Don't schedule work during reset / abort. For USB NICs, work
must not be scheduled during a call to rtwn_usb_abort_xfers(),
as then it'll cause the call to usbd_transfer_drain() to hang.

This fixes a hang I've been seeing where the NIC hits a TX timeout
and then the reset/re-init path is called. If data is scheduled
to be transmitted in that window, the call to usbd_transfer_drain()
would hang and require a hard reboot to recover.

[adrian]

Update URL

[bz]

Could this also be relevant to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268687 (and possibly others if you search for rtwn on bugzilla)?

sys/dev/rtwn/if_rtwn_tx.c

270

No need for {}

[adrian]

feedback from bz@

[adrian]

In D47479#1082886, @bz wrote:

Could this also be relevant to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268687 (and possibly others if you search for rtwn on bugzilla)?

Maybe? This would seem to be a hard hang though. it's possible some other versions of this somehow make SOME forward progress.

I've been debugging WHY the timeouts occur, and it looks like it's something to do with traffic going to multiple TIDs/ACs (and thus queues) at the same time. If I redirect all the output to a single TX queue to the NIC? Everything is stable.
The TX USB code doesn't look like it's at all handling multi-queue transmit right, I'm going to work on a short-term workaround and then try re-doing the USB TX path and see if it improves things.
(But not in this diff. :-) )