lwfinger / rtl8192du

Source code for RTL8192DU device

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Driver gets stuck

pablo-mendoza opened this issue · comments

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?

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.

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?

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.

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?

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

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

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.