timeout (110) with bluez usb uhci 2.4.21
The same problem here as the one raported about a week ago by Florian Lohoff. I have two USB bluetooth dongles. One of them (ambicom bt2000) does not like being hotplugged in it gives that timeout message after saying it was an error in interrupt.The other (blue-gene bt320) can be connected/disconncted and it works fine.
The same problem shows with 2.4.22-pre7
If the usb-uhci module is reloaded while the dongle is in it finds it. The problem as shown by debug messages in uhci seems to be error in the interrupt handler for uhci. The status register is 2 which is io/error I think and it says the frame was corrupted.
So I changed the handler to return when that's the status and only go on if status is 1 which I think is normal usb interrupt transfer not an error condition. This way probably the usb stack retries again and the dongle is found after a few seconds and can be plugged in and out. I have seen in other threads that somebody made usb_get_address retry on error to achieve the same effect...
can some workaround by somebody who knows what's happening be put in the kernel because google shows that quite a few people are bitten by this 110 error message with uhci/ohci and various usb devices not only BT.
thanks
Jani
Quoted 11 lines · Jani Monoses
The same problem here as the one raported about a week ago by Florian Lohoff. I have two USB bluetooth dongles. One of them (ambicom bt2000) does not like being hotplugged in it gives that timeout message after saying it was an error in interrupt.The other (blue-gene bt320) can be connected/disconncted and it works fine.
The same problem shows with 2.4.22-pre7
If the usb-uhci module is reloaded while the dongle is in it finds it. The problem as shown by debug messages in uhci seems to be error in the interrupt handler for uhci. The status register is 2 which is io/error I think and it says the frame was corrupted.
So I changed the handler to return when that's the status and only go on
Quoted 8 lines
if status is 1 which I think is normal usb interrupt transfer not an error condition. This way probably the usb stack retries again and the dongle is found after a few seconds and can be plugged in and out. I have seen in other threads that somebody made
usb_get_addressretry on error to achieve the same effect...
can some workaround by somebody who knows what's happening be put in the kernel because google shows that quite a few people are bitten by this 110 error message with uhci/ohci and various usb devices not only BT.
Did you try the trick that I suggested to Florian ? i.e. changing HCI_MAX_BULK_TX from 4 to 1. It did help some people. Also you might want to try usb-uhci driver instead of uhci.
Max