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

Authored by adrian on Nov 7 2024, 10:53 PM.

Details

Reviewers

adrian
bz

Group Reviewers

wireless

Commits

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

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.

Diff Detail

Repository

rG FreeBSD src repository

Lint

Lint Skipped

Unit

Tests Skipped

Build Status

Buildable 60440
Build 57324: arc lint + arc unit

Event Timeline

adrian created this revision.Nov 7 2024, 10:53 PM

Herald added a subscriber: imp. · View Herald TranscriptNov 7 2024, 10:53 PM

adrian requested review of this revision.Nov 7 2024, 10:53 PM

Harbormaster completed remote builds in B60440: Diff 146147.Nov 7 2024, 10:53 PM

Update URL

Harbormaster completed remote builds in B60441: Diff 146148.Nov 7 2024, 10:55 PM

adrian added a reviewer: wireless.Nov 7 2024, 10:55 PM

adrian added a project: wireless.

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 {}

feedback from bz@

Harbormaster completed remote builds in B60445: Diff 146165.Nov 8 2024, 4:41 AM

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. :-) )

bz accepted this revision as: bz.Nov 8 2024, 1:06 PM

This revision is now accepted and ready to land.Nov 8 2024, 1:06 PM

Closed by commit rG8838f3c32ac0: rtwn: ensure TX work isn't scheduled during reset / abort (authored by adrian). · Explain WhyNov 8 2024, 4:26 PM

This revision was automatically updated to reflect the committed changes.

adrian added a commit: rG8838f3c32ac0: rtwn: ensure TX work isn't scheduled during reset / abort.