3.10 with bluetooth-next applied - btmon of both sides attached On Tue, Mar 11, 2014 at 4:03 PM, Marcel Holtmann <marcel@xxxxxxxxxxxx> wrote: > Hi Scott, > >> Is this expected behavior for RFCOMM? When using rctest -r on one >> side, and rctest -c (connect/disconnect/connect...) on the other, the >> client side fails to connect a significant percentage of the time: >> >> rctest[23705]: Can't connect: Device or resource busy (16) >> rctest[23705]: Can't connect: Device or resource busy (16) >> rctest[23705]: Can't connect: Device or resource busy (16) >> rctest[23705]: Can't connect: Device or resource busy (16) >> rctest[23705]: Can't connect: Device or resource busy (16) >> rctest[23705]: Can't connect: Device or resource busy (16) >> rctest[23705]: Connected [handle 34817, class 0xff8801, priority 0] >> rctest[23705]: Can't connect: Device or resource busy (16) >> rctest[23705]: Can't connect: Device or resource busy (16) >> rctest[23705]: Can't connect: Device or resource busy (16) >> rctest[23705]: Can't connect: Device or resource busy (16) >> rctest[23705]: Can't connect: Device or resource busy (16) >> rctest[23705]: Can't connect: Device or resource busy (16) > > it is not an expected behavior. Can you create a btmon trace for this and see what error code we get on the HCI level. > > Without any kind of analysis this sound like a race condition in the disconnect handling where the connection is not fully terminated and you try to re-connect too quickly. > > What kernel version is this? And as usual the first question, do you still see this behavior with a bluetooth-next kernel? > > Regards > > Marcel >
Attachment:
connect.btsnoop
Description: Binary data
Attachment:
listen.btsnoop
Description: Binary data
