[Bug 298238] [rtw88] RTL8822CE TX ring stall under load, hw_scan returns -16, requires full poweroff to recover

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=298238

Bjoern A. Zeeb <bz@FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bz@FreeBSD.org
             Status|New                         |Open
             Blocks|                            |273621

--- Comment #1 from Bjoern A. Zeeb <bz@FreeBSD.org> ---
Thanks for all your debugging and detailed report.  I'll comment below on some.

Have you read up on the history on the wireless list archive, or the man page?

The 15.1 release notes say:

""The rtw88(4) driver..  There are known issues with certain chipsets. ..""

man 4 rtw88 says:

""
BUGS
     Does not seem to work (reliably) on machines with more than 4GB of main
     memory.  See in the LOADER TUNABLES section above.

     At least the 8821CE and 8822BE chipsets have trouble associating, which
     seems to be due to the software scan fallback, the chandef emulation, and
     net80211 interactions, along with a 6s timeout observed in the driver.

     While rtw88 supports 802.11a/b/g/n/ac modes, the compatibility code
     currently only supports 802.11a/b/g modes.  Support for 802.11n/ac is yet
     to come.
""


Related to some of your questions:

There is no BGSCAN support in LinuxKPI.
So -bgscan is the default (and cannot be changed unless there are bugs in
net80211).
If you checked `ifconfig -v wlan0 | grep bgscan` you should have seen this.

The Realtek drivers/chipsets/firmware are using a feature that if a HW SCAN is
not available at a given time they return a specific value to notify the stack
to do a software scan instead, which is a massive pain in the LinuxKPI compat
code as one cannot easily switch scan engines in net80211 if one would want to
do it right. That's at least for anything up to 8822be; I cannot remember from
the top of my head what 8822ce does.   We fixed various bgscan bugs because of
this in the past in net80211 as bgscan would sneakily turn itself on in
net80211 and cause issues.

When it comes to 11n/11ac: the code for that as you noticed is in LinuxKPI by
now but given the driver is not stable there was no point in turning it on (by
the firmware package by default) yet.  So this has nothing to do with USB or
cheap dongles vs. PCI but with the well known state of the driver(s).

I've started working my way backwards from rtw89 chipsets also suffering
problems to make sure they work at the moment;  I have not made it to rtw88 as
I need to test one by one (and ideally for more than 3 minutes or 3 hours).

devctl reset will allow you to do a FLR or a D3 D0 cycle but if the firmware
was gone you may simply risk a different panic unless you can successfully down
and destroy the wlan0 interface and unload the driver.

If you click on the PR I added to blocks and then tree mode [ or just use this
link:
https://bugs.freebsd.org/bugzilla/showdependencytree.cgi?id=273621&hide_resolved=1
] you can see other open PRs for rtw88 and rtw89 to see some other people are
seeing.  There's a knob to also show resolved issues.

There were people running the driver on 15.0 (which is based on a different
Linux version) successfully in a/b/g mode.
There was no LinuxKPI compat support for 11n/11ac in the 15.0 code.
The other alternative is to try wifibox.

Turning on rtw88 debug logging you will find that changes a lot of timings and
problems may simply migrate.

If you want to keep digging let me know and we can see what makes sense the
most; alternatively I'll hopefully get there once I am done with rtw89.
Which version of the Linux kernel are you running on the Artix installation?


Referenced Bugs:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273621
[Bug 273621] rtw88, rtw89 meta-bug
-- 
You are receiving this mail because:
You are the assignee for the bug.