On 06/11/2015 10:00 PM, Paul Thomas wrote:
Hello, I just got a TP-LINK TL-WN725N adapter (VID 0bda, PID 8179)The driver in the staging area seems to be working fine, but I get this on startup. I'm using this with a BeagleBone Black. I did a fresh git pull today, so it is with kernel 4.1.0-rc7-00063-gcff100f, I haven't tried it with the wireless-testing branch. Anyway, thought someone might be interested. thanks, Paul [ 22.489564] ============================================= [ 22.495221] [ INFO: possible recursive locking detected ] [ 22.500883] 4.1.0-rc7-00063-gcff100f #3 Tainted: G C [ 22.507266] --------------------------------------------- [ 22.512921] RTW_CMD_THREAD/554 is trying to acquire lock: [ 22.518577] (&(&(pqueue->lock))->rlock){+.-...}, at: [<bf0f4e68>] _rtw_alloc_network+0x14/0xc4 [r8188eu] [ 22.528847] [ 22.528847] but task is already holding lock: [ 22.534969] (&(&(pqueue->lock))->rlock){+.-...}, at: [<bf0f54ec>] rtw_update_scanned_network+0x18/0x234 [r8188eu] [ 22.545910] [ 22.545910] other info that might help us debug this: [ 22.552759] Possible unsafe locking scenario: [ 22.552759] [ 22.558969] CPU0 [ 22.561534] ---- [ 22.564097] lock(&(&(pqueue->lock))->rlock); [ 22.568765] lock(&(&(pqueue->lock))->rlock); [ 22.573433] [ 22.573433] *** DEADLOCK *** [ 22.573433] [ 22.579654] May be due to missing lock nesting notation [ 22.579654] [ 22.586775] 2 locks held by RTW_CMD_THREAD/554: [ 22.591520] #0: (&(&(pmlmepriv->lock))->rlock){+.....}, at: [<bf0f57c8>] rtw_survey_event_callback+0x7c/0x1c4 [r8188eu] [ 22.603094] #1: (&(&(pqueue->lock))->rlock){+.-...}, at: [<bf0f54ec>] rtw_update_scanned_network+0x18/0x234 [r8188eu] [ 22.614481] [ 22.614481] stack backtrace: [ 22.619064] CPU: 0 PID: 554 Comm: RTW_CMD_THREAD Tainted: G C 4.1.0-rc7-00063-gcff100f #3 [ 22.628817] Hardware name: Generic AM33XX (Flattened Device Tree) [ 22.635227] [<c0016b14>] (unwind_backtrace) from [<c0013084>] (show_stack+0x10/0x14) [ 22.643355] [<c0013084>] (show_stack) from [<c05e4184>] (dump_stack+0x84/0x9c) [ 22.650944] [<c05e4184>] (dump_stack) from [<c008eb00>] (__lock_acquire+0x1a44/0x1edc) [ 22.659253] [<c008eb00>] (__lock_acquire) from [<c008f8a0>] (lock_acquire+0xa8/0x124) [ 22.667473] [<c008f8a0>] (lock_acquire) from [<c05ea9fc>] (_raw_spin_lock_bh+0x44/0x54) [ 22.675926] [<c05ea9fc>] (_raw_spin_lock_bh) from [<bf0f4e68>] (_rtw_alloc_network+0x14/0xc4 [r8188eu]) [ 22.685883] [<bf0f4e68>] (_rtw_alloc_network [r8188eu]) from [<bf0f55c0>] (rtw_update_scanned_network+0xec/0x234 [r8188eu]) [ 22.697654] [<bf0f55c0>] (rtw_update_scanned_network [r8188eu]) from [<bf0f5844>] (rtw_survey_event_callback+0xf8/0x1c4 [r8188eu]) [ 22.710069] [<bf0f5844>] (rtw_survey_event_callback [r8188eu]) from [<bf100f08>] (mlme_evt_hdl+0x5c/0xe8 [r8188eu]) [ 22.721110] [<bf100f08>] (mlme_evt_hdl [r8188eu]) from [<bf0ebc24>] (rtw_cmd_thread+0xac/0x2a8 [r8188eu]) [ 22.731191] [<bf0ebc24>] (rtw_cmd_thread [r8188eu]) from [<c005e268>] (kthread+0xd4/0xf0) [ 22.739780] [<c005e268>] (kthread) from [<c000f5b8>] (ret_from_fork+0x14/0x3c)
That is a known problem, but I do not know the fix. The only downside is that this occurrence disables lockdep testing.
FYI, staging drivers are not updated through wireless, but this is a good place to report problems. If you want to try the latest versions of one of these drivers, then you need to use staging-next, which is a branch of the staging repo maintained by GregKH.
Larry -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
