Driver gets stuck

[pablo-mendoza]

Hello, I'm trying to use this driver with a 5.15.16 kernel to use a rtl8192du usb based module. The module seems to be loading fine:

[ 2.690421] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[ 2.758103] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[ 2.769567] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2
[ 2.778304] cfg80211: failed to load regulatory.db
[ 2.849514] 8192du: loading out-of-tree module taints kernel.
[ 3.064361] RTL8192DU: module init start
[ 3.068958] RTL8192DU: rtl8192du v4.0.10_25039.20171107
[ 3.307680] RTL8192DU: rtw_ndev_init(wlan0)
[ 3.312931] RTL8192DU: rtw_ndev_init(wlan1)
[ 3.318218] usbcore: registered new interface driver rtl8192du
[ 3.324064] RTL8192DU: module init ret=0

I see two interfaces wlan0 and wlan1 when running ifconfig -a. But as soon as I do ifconfig wlan0 up (or wlan1) the ifconfig gets stucks and never returns no matter if I try to Ctr-C it or kill -9 it from another terminal.

Also any other network related command will get stuck (ifconfig, ip, iwlist, iwconfig) just by runnning it. I have no way to make those commands exist, not even unplugging the rtl8192du device.

No further dmesg output will be shown after running those commands.

Any ideas or help?

[lwfinger]

The locking changes in the kernel routines. That lead to a lock dependency that locked up the CPU. Do a 'git pull' and it should be OK.

[pablo-mendoza]

Thanks for the quick reply @lwfinger.

Something seems to have gone wrong with your commit and deleted the entiere netdev_if2_open function. I restored it and remove the locking as you intended and will report back.

On a general note. Do you think this driver is stable enought to leave a little board running unnatended and expecting the wifi connection to be reliable?

[lwfinger]

Do a pull. I missed part of the changes. After you remove the problematic lock and unlock, netdev_if2_open() is only a call to _netdev_if2_open(), thus it can be removed.

I have no idea how stable this driver would be. If I ever did a long-term test of it, that would have been a long time ago, and I have forgotten the results.

[pablo-mendoza]

Running commit 6c1792c it still gets stuck same as the beginning. Running on kernel 5.15.16

Any debugging I can enable to provide more info?

[pablo-mendoza]

I enabled debugging in the driver and this is what I get up to the point where I do ifconfig wlan0 up and it gets stuck:

[    2.995179] RTL8192DU: module init start
[    2.999990] RTL8192DU: rtl8192du v4.0.10_25039.20171107
[    3.005782] RTL8192DU:
[    3.012115] RTL8192DU: bLength=7
[    3.015351] RTL8192DU: bDescriptorType=5
[    3.019332] RTL8192DU: bEndpointAddress=81
[    3.023436] RTL8192DU: wMaxPacketSize=200
[    3.027483] RTL8192DU: bInterval=0
[    3.030893] RTL8192DU: RT_usb_endpoint_is_bulk_in = 1
[    3.035939] RTL8192DU:
[    3.042252] RTL8192DU: bLength=7
[    3.045532] RTL8192DU: bDescriptorType=5
[    3.049502] RTL8192DU: bEndpointAddress=2
[    3.053519] RTL8192DU: wMaxPacketSize=200
[    3.057562] RTL8192DU: bInterval=0
[    3.060973] RTL8192DU: RT_usb_endpoint_is_bulk_out = 2
[    3.066109] RTL8192DU:
[    3.072405] RTL8192DU: bLength=7
[    3.075640] RTL8192DU: bDescriptorType=5
[    3.079604] RTL8192DU: bEndpointAddress=3
[    3.083618] RTL8192DU: wMaxPacketSize=200
[    3.087652] RTL8192DU: bInterval=0
[    3.091059] RTL8192DU: RT_usb_endpoint_is_bulk_out = 3
[    3.096192] RTL8192DU:
[    3.102487] RTL8192DU: bLength=7
[    3.105717] RTL8192DU: bDescriptorType=5
[    3.109677] RTL8192DU: bEndpointAddress=85
[    3.113779] RTL8192DU: wMaxPacketSize=40
[    3.117742] RTL8192DU: bInterval=3
[    3.121156] RTL8192DU: RT_usb_endpoint_is_int_in = 5, Interval = 3
[    3.127362] RTL8192DU: nr_endpoint=4, in_num=2, out_num=2
[    3.134238] RTL8192DU: USB_SPEED_HIGH
[    3.138041] RTL8192DU: CHIP TYPE: RTL8192D
[    3.142185] RTL8192DU: register rtw_netdev_ops to netdev_ops
[    3.148119] RTL8192DU: ReadChipVersion8192D 0xF0 = 0x4411235
[    3.153879] RTL8192DU: Normal CHIP!!!
[    3.158082] RTL8192DU: EEPROM type is E-FUSE
[    3.162365] RTL8192DU: ====> _ReadAdapterInfo8192DU
[    3.167334] RTL8192DU: Boot from EFUSE, Autoload OK !
[    3.392079] RTL8192DU: Unkown CUT!
[    3.396457] RTL8192DU: EEPROMVID = 0x0bda
[    3.400471] RTL8192DU: EEPROMPID = 0x8193
[    3.404477] RTL8192DU: EEPROMCustomerID : 0x00
[    3.408941] RTL8192DU: EEPROMSubCustomerID: 0x00
[    3.413564] RTL8192DU: MAC Address from EFUSE = 44:01:bb:6f:c1:3c
[    3.419678] RTL8192DU: Is D/E cut,Internal PA0 1 Internal PA1 1
[    3.425859] RTL8192DU: PHY_SetPAMode mode 1, c9 = 0xaa cc = 0xaf interface index 0
[    3.434362] RTL8192DU: _ReadMacPhyModeFromPROM92DU(): MacPhyCrValue 10
[    3.441087] RTL8192DU: MacPhyMode: SINGLEMAC_SINGLEPHY
[    3.446456] RTL8192DU: PHY_ConfigMacPhyModeInfo92D(): wireless_mode = 1f
[    3.453155] RTL8192DU: mlmepriv.ChannelPlan = 0x7f
[    3.457965] RTL8192DU: _ReadBoardType(0)
[    3.461885] RTL8192DU: <==== _ReadAdapterInfo8192DU in 300 ms
[    3.467643] RTL8192DU: rtw_wdev_alloc(padapter=(ptrval))
[    3.473984] RTL8192DU: rtw_macaddr_cfg MAC Address  = 44:01:bb:6f:c1:3c
[    3.480657] RTL8192DU: bDriverStopped:1, bSurpriseRemoved:0, bup:0, hw_init_completed:0
[    3.488727] RTL8192DU: register rtw_netdev_ops to netdev_ops
[    3.494387] RTL8192DU: register rtw_netdev_if2_ops to netdev_ops
[    3.500431] RTL8192DU: rtw_wdev_alloc(padapter=(ptrval))
[    3.506234] RTL8192DU: ReadChipVersion8192D 0xF0 = 0x4411235
[    3.512012] RTL8192DU: Normal CHIP!!!
[    3.516663] RTL8192DU: rtw_ndev_init(wlan0)
[    3.520998] RTL8192DU: rtw_ndev_notifier_call(wlan0) state:17
[    3.527468] RTL8192DU: cfg80211_rtw_get_txpower
[    3.532016] RTL8192DU: rtw_ndev_notifier_call(wlan0) state:5
[    3.537732] RTL8192DU: _rtw_drv_register_netdev, MAC Address (if1) = 44:01:bb:6f:c1:3c
[    3.545682] RTL8192DU: rtw_ndev_init(wlan1)
[    3.550012] RTL8192DU: rtw_ndev_notifier_call(wlan1) state:17
[    3.556377] RTL8192DU: cfg80211_rtw_get_txpower
[    3.560920] RTL8192DU: rtw_ndev_notifier_call(wlan1) state:5
[    3.566615] RTL8192DU: _rtw_drv_register_netdev, MAC Address (if2) = 46:01:bb:6f:c1:3c
[    3.574663] usbcore: registered new interface driver rtl8192du
[    3.580520] RTL8192DU: module init ret=0
[  104.828268] RTL8192DU: rtw_ndev_notifier_call(wlan0) state:14
[  104.834058] RTL8192DU: +871x_drv - drv_open, bup=0
[  104.839707] RTL8192DU: MacPhyMode: SINGLEMAC_SINGLEPHY
[  104.957852] RTL8192DU:  ===> FirmwareDownload92D() fw:Rtl8192D_FwImageArray
[  104.964819] RTL8192DU: FirmwareDownload92D accquire FW from embedded image
[  104.971726] RTL8192DU:  FirmwareVersion(0x27), Signature(0x92d3)
[  105.063208] RTL8192DU: _WriteFW Done- for Normal chip.
[  105.068579] RTL8192DU: FirmwareDownload92D writeFW_retry:0, time after fwdl_start_time:90ms
[  105.086518] RTL8192DU: Checksum report OK ! REG_MCUFWDL:0x00078204 .
[  105.093449] RTL8192DU: FW already have download ;
[  105.098953] RTL8192DU: Polling FW ready success!! FW_MAC0_ready:0x31 .
[  105.105793] RTL8192DU: fw download ok!
[  105.205953] RTL8192DU: Enable 92du query RF by FW.
[  105.212200] RTL8192DU:  ===> PHY_ConfigRFWithHeaderFile() intferace = 0, Radio_txt = 0x1000, eRFPath = 0,MaskforPhyAccess:0x0.
[  105.702075] RTL8192DU:  ===> PHY_ConfigRFWithHeaderFile() intferace = 0, Radio_txt = 0x1001, eRFPath = 1,MaskforPhyAccess:0x0.
[  106.216456] RTL8192DU: IQK: final_candidate is 0
[  106.221112] RTL8192DU: IQK: RegE94=ff RegE9C=3f9 RegEA4=105 RegEAC=9 RegEB4=ff RegEBC=3fa RegEC4=104 RegECC=7
[  106.244198] RTL8192DU: IQK: process time 70 ms
[  107.053704] RTL8192DU: LCK: process time 800 ms
[  107.059199] RTL8192DU: PHY_InitPABias92D 0x3FA 0xff
[  107.064166] RTL8192DU: pdmpriv->TxPowerTrackControl = 1
[  107.085824] RTL8192DU: rtl8192du_hal_init in 2240ms
[  107.118456] RTL8192DU: MAC Address = 44:01:bb:6f:c1:3c
[  107.123843] RTL8192DU: rtw_cfg80211_init_wiphy:rf_type=2

[pablo-mendoza]

Any ideas? I never got around to making this work. I build my own kernel so it maybe something in my kernel build.

[lwfinger]

No, the locking changed in nl80211/cfg80211. I have found several places where there is lock contention. At the moment, the call to wiphy_apply_custom_regulatory() is the problem. It sets a lock; however, the thread already has one.

I am trying to set up a separate thread to call rtw_regd_init(), which will not be holding any locks. The problem is that I am not really good with workqueues, and it is taking a lot of learning. I should have a trial later today.