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)
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