Hi Jukka,
>From the last trace it looks like a transmit has been started from the receive worker thread. I notice that both tx and rx use the same workerqueue structure, e.g.
hci_send_xxx
...
queue_work(hdev->workqueue, &hdev->tx_work);
hci_recv_frame
...
queue_work(hdev->workqueue, &hdev->rx_work);
Would this cause problems. I don't know enough about work queues but in workqueue_struct there is a mutex which may be held by the rx worker and if this rx worker start a transmit maybe this would cause the lock? Could test by creating separate queues for rx and tx?
Anyway just a thought.
- Martin.
On 13/10/14 16:09, Jukka Rissanen wrote:
> Hi Martin,
>
> On ma, 2014-10-13 at 15:56 +0100, Martin Townsend wrote:
>> Hi Jukka,
>>
>> Does this patch help?
> Unfortunately no, I still see inconsistent lock state. It would probably
> have been too easy :)
>
>> ---
>> net/bluetooth/l2cap_core.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
>> index b6f9777..fb7b2ff 100644
>> --- a/net/bluetooth/l2cap_core.c
>> +++ b/net/bluetooth/l2cap_core.c
>> @@ -5494,6 +5494,7 @@ static inline int l2cap_le_credits(struct l2cap_conn *conn,
>> if (credits > max_credits) {
>> BT_ERR("LE credits overflow");
>> l2cap_send_disconn_req(chan, ECONNRESET);
>> + l2cap_chan_unlock(chan);
>>
>> /* Return 0 so that we don't trigger an unnecessary
>> * command reject packet.
>
> Cheers,
> Jukka
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
