Closed labrat97 closed 1 year ago
Hi, you should safe ignore RTW: ERROR [HALMAC][ERR]Dump efuse in suspend
.
That is neither beamforming ee or er!!
often happened when the system try to do a full scan while transfer data.
Maybe you can try use iwd
?
I looked into the source code and it's triggered because rtw_hw_wps_pbc
is default enabled with USB HCI as a #define
. The BSSID is set, and network-manager
is the backbone of my management so NetworkManager isn't going to ask for a rescan during connection. Whats happening (for whatever reason) is the device appears to be responding to a WPS Push-Button-Configuration request then trying to reassociate to the original network. I'm gonna try setting rtw_hw_wps_pbc=0
in my module options and see if it fixes it.
See definition of option: os_dep/linux/os_intfs.c:431
See error location: core/rtw_mlme.c:2502
Here's my new config for reference:
options 88x2bu rtw_switch_usb_mode=1 rtw_pwrtrim_enable=1 rtw_led_ctrl=1 rtw_vht_enable=1 rtw_power_mgnt=0 rtw_wireless_mode=84 rtw_hw_wps_pbc=0
So tested, that was the problem. WPS PBC is essentially a rescan. As a note, the only error/warning/whatever that came up this time is: [ 4.825325] 88x2bu: unknown parameter 'rtw_led_ctrl' ignored
. This is a non-issue to me but it would still be nice to know the proper module parameter.
Full speed ahead with a full dmesg | grep
of:
[ 4.825325] 88x2bu: unknown parameter 'rtw_led_ctrl' ignored
[ 5.266223] RTW: rtw_regsty_chk_target_tx_power_valid return _FALSE for band:0, path:0, rs:0, t:-1
[ 5.300420] RTW: rtw_ndev_init(wlan0) if1 mac_addr=9c:a2:f4:93:c8:81
[ 16.987198] RTW: rtw_set_802_11_connect(wlx9ca2f493c881) fw_state=0x00000008
[ 60.461587] RTW: rtw_set_802_11_connect(wlx9ca2f493c881) fw_state=0x00000008
I am not sure how WPS PBC
got activated where there is no button on it.
Also there is no rtw_led_ctrl
for this driver. You may wanna check this https://github.com/RinCat/RTL88x2BU-Linux-Driver/issues/44#issuecomment-1117276233
WPS PBC
only puts the button on the AP. The actual rtl8822bu radio still needs a way to take in an AD-HOC broadcast, hence the re-auth and disconnect. I can make a pull request for changing the definition if you want, but this is definitely what needs to be changed (at os_dep/linux/os_intfs.c:430-434
):
Old:
#ifdef CONFIG_USB_HCI
int rtw_hw_wps_pbc = 1;
#else
int rtw_hw_wps_pbc = 0;
#endif
New:
int rtw_hw_wps_pbc = 0;
OK, I am going to check old issues and ask if this fixed for them.
Alright, I'm gonna close this one to get it off your plate.
Hey, so I just purchased the dreaded Archer T4U Plus (v1.8) and this is the only driver that works under load for the most part. When pushing it past about 130mbps, usually in a few second window, it hits an error and has to reconnect. It's not a power issue (I don't think, I can apply external bus power in a bit), it's not a bus issue, it's not an overheating issue.
dmesg
is luckily very descriptive in exactly what is happening to the adapter. Eventually it catches on and stops doing the subroutine that crashed it. It is the same warning and error sequence every time using the following options:options 88x2bu rtw_switch_usb_mode=1 rtw_pwrtrim_enable=1 rtw_led_ctrl=1 rtw_vht_enable=1 rtw_power_mgnt=0 rtw_wireless_mode=84
Here is the very first error:
and here is the recurring error:
The
EFUSE
errors happen far before the first access point association, and could be an issue of the server bringing up the 5V rail relatively slow.Also, thanks for your work on this project.