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