On Mi, 2018-10-31 at 12:32 +0800, Morikazu Fumita wrote: > > My test procedure is below (assuming Bluetooth devices are already paired). > > 1. Adding a network bridge for PAN using "brctl". > 2. Link the bridge up. > 3. Run "hciconfig hci0 up" to power the USB Bluetooth dongle up. > 4. Register "nap" service and the network bridge to > "org.bluez.NetworkServer1" > via d-bus using a Python script. > 5. Bluez makes "bnep0" virtual network interface automatically. > 6. Connect to the PAN-NAP server from the client. Network is working > fine at > this point. > (Note: The hang does not happen even if turning promiscuous mode off at > this > point by running "ip link set bnep0 promisc off") > 7. Disconnect PAN from the client or make the "bnep0" virtual network > adapter > down by running "ip link set bnep0 down". > 8. The hang happens with "Bluetooth: hci0: command 0xXXXX tx timeout" > errors. > 9. No response from the USB Bluetooth dongle anymore. > For example, running "discoverable on" from "bluetoothctl" fails with error > message of "Failed to set discoverable on: org.bluez.Error.Failed". > The timeout error is logged in "dmesg" as well. > > From this fact, I believe this issue is related to Bluez but not to USB. > What do you think? Hi, you are using a slightly less common HC, are you not? Anyway, it seems to me that you can narrow this down a bit further. You are using bridging. You can try to remove that. And after that you can take an usbmon trace right as you give the command that crashes the device. The procedure is described in the kernel's Documentation directory. That will allow to determine which exact command is the problem. HTH Oliver
