Page MenuHomeFreeBSD

rtw88: try to see if this is the skb leak
Needs ReviewPublic

Authored by bz on Wed, Jan 15, 10:44 PM.
Tags
None
Referenced Files
F107668380: D48474.id.diff
Fri, Jan 17, 10:45 AM
F107666644: D48474.id.diff
Fri, Jan 17, 10:09 AM
F107666205: D48474.id.diff
Fri, Jan 17, 10:02 AM
F107658323: D48474.id.diff
Fri, Jan 17, 7:12 AM
Unknown Object (File)
Thu, Jan 16, 7:46 AM
Unknown Object (File)
Thu, Jan 16, 7:46 AM
Unknown Object (File)
Thu, Jan 16, 6:59 AM
Unknown Object (File)
Wed, Jan 15, 11:10 PM
This revision needs review, but there are no reviewers specified.

Details

Reviewers
None
Summary

The tx_report purge_timer has been a souce of massive logging at times
in the past so it is the best shot in the dark for an endless queuing
of skbs. That would happen if more and more reports come in and the
timer gets pushed further and further and never expires and at the same
time the information is not picked up by rtw_tx_report_handle().

Add a WARN_ONCE to __skb_queue_purge() just to make sure there is no
glitch due to missing locking.

Also add a rolling error reporting for skb allocation failures in
LinuxKPI to gather some more information if possible about queue
states. In the rtw88 case when everything grinds to a halt this will
likely need kern.msgbufsize=1146880 (or 4M) in loader.conf to allow
bringing down wlan0 in time before all information from the beginning
scrolls away.

Sponsored by: The FreeBSD Foundation
MFC after: 1 week
X-MFC: first needs to show to help

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 61745
Build 58629: arc lint + arc unit