在 2023-04-30 18:36:50，"Bitterblue Smith" <rtl8821cerfe2@xxxxxxxxx> 写道： >On 29/04/2023 06:35, Yun Lu wrote: >> At 2023-04-29 01:06:03, "Larry Finger" <Larry.Finger@xxxxxxxxxxxx> wrote: >>> On 4/27/23 23:11, wo wrote: >>>> [ 149.595642] [pid:7,cpu6,kworker/u16:0,0]BEFORE: REG_RCR differs from regrcr: >>>> 0x1830613 insted of 0x7000604e >>>> [ 160.676422] [pid:237,cpu6,kworker/u16:5,3]BEFORE: REG_RCR differs from >>>> regrcr: 0x70006009 insted of 0x700060ce >>>> [ 327.234588] [pid:7,cpu7,kworker/u16:0,5]BEFORE: REG_RCR differs from >>> regrcr: 0x1830d33 insted of 0x7000604e >>> >>> >>> My patch was messed up, but it got the information that I wanted, which is shown >>> in the quoted lines above. One of these differs only in the low-order byte, >>> while the other 2 are completely different. Strange! >>> >>> It is possible that there is a firmware error. My system, which does not show >>> the problem, reports the following: >>> >>> [54130.741148] usb 3-6: RTL8192CU rev A (TSMC) romver 0, 2T2R, TX queues 2, >>> WiFi=1, BT=0, GPS=0, HI PA=0 >>> [54130.741153] usb 3-6: RTL8192CU MAC: xx:xx:xx:xx:xx:xx >>> [54130.741155] usb 3-6: rtl8xxxu: Loading firmware rtlwifi/rtl8192cufw_TMSC.bin >>> [54130.742301] usb 3-6: Firmware revision 88.2 (signature 0x88c1) >>> >>> Which firmware does your unit use? >> >> The firmware verion we used is 80.0 (signature 0x88c1) >> [ 903.873107] [pid:14,cpu0,kworker/0:1,2]usb 1-1.2: RTL8192CU rev A (TSMC) 2T2R, TX queues 2, WiFi=1, BT=0, GPS=0, HI PA=0 >> [ 903.873138] [pid:14,cpu0,kworker/0:1,3]usb 1-1.2: RTL8192CU MAC: 08:be:xx:xx:xx:xx >> [ 903.873138] [pid:14,cpu0,kworker/0:1,4]usb 1-1.2: rtl8xxxu: Loading firmware rtlwifi/rtl8192cufw_TMSC.bin >> [ 903.873474] [pid:14,cpu0,kworker/0:1,5]usb 1-1.2: Firmware revision 80.0 (signature 0x88c1) >> >>> >>> Attached is a new test patch. When it logs a CORRUPTED value, I would like to >>> know what task is attached to the pid listed in the message. Note that the two >>> instances where the entire word was wrong came from pid:7. >>> >>> Could improper locking could produce these results? >>> >>> Larry >> >> Apply your new patch, then turn on/off the wireless network switch on the network control panel serverl loops. >> The log shows: >> [ 85.384429] [pid:221,cpu6,kworker/u16:6,5]REG_RCR corrupted in rtl8xxxu_configure_filter: 0x70006009 insted of 0x700060ce >> [ 121.681976] [pid:216,cpu6,kworker/u16:3,0]REG_RCR corrupted in rtl8xxxu_configure_filter: 0x70006009 insted of 0x700060ce >> [ 144.416992] [pid:217,cpu6,kworker/u16:4,1]REG_RCR corrupted in rtl8xxxu_configure_filter: 0x70006009 insted of 0x700060ce >> >> And if we up/down the interface serverl loops as follows: >> ifconfig wlx08bexxxxxx down >> sleep 1 >> ifconfig wlx08bexxxxxx up >> sleep 10 >> The log shows: >> [ 282.112335] [2023:04:29 10:30:34][pid:95,cpu6,kworker/u16:1,3]REG_RCR corrupted in rtl8xxxu_configure_filter: 0x1832e13 insted of 0x7000604e >> [ 293.311462] [2023:04:29 10:30:45][pid:217,cpu7,kworker/u16:4,9]REG_RCR corrupted in rtl8xxxu_configure_filter: 0x1830e72 insted of 0x7000604e >> [ 304.435089] [2023:04:29 10:30:56][pid:217,cpu6,kworker/u16:4,9]REG_RCR corrupted in rtl8xxxu_configure_filter: 0x1830ed3 insted of 0x7000604e >> [ 315.532257] [2023:04:29 10:31:07][pid:95,cpu7,kworker/u16:1,8]REG_RCR corrupted in rtl8xxxu_configure_filter: 0x7000604e insted of 0x7000604e >> [ 324.114379] [2023:04:29 10:31:16][pid:221,cpu6,kworker/u16:6,7]REG_RCR corrupted in rtl8xxxu_configure_filter: 0x1832e14 insted of 0x7000604e >> >> We also update the firmware verion to 88.2, and the test results are the same as above. >> >> Thank you for helping debug this issue, which seems to be related to specific devices. >> >> Yun Lu >> >> >> >> >There was this bug report about phantom MAC addresses with >the RTL8188CUS: >https://lore.kernel.org/linux-wireless/a31d9500-73a3-f890-bebd-d0a4014f87da@xxxxxxxxxxxxxxxxx/ > >See the pcap file. I wonder if it's related? The bug in the link is a high retransmission rate during message transmission, but the problem we encountered is that the nic cannot receive authentication frames, resulting in authentication timeout and inability to connect to WiFi. It seems that these two issues are not related. We also enabled monitor mode and found that the AP has replied to the authentication message, but the nic cannot receive this reply message due to the incorrect RCR register value. Once the RCR register is modified to the correct value, the authentication message can be received normally and the connection to WIFI can be normal. Thanks.
