On 2014-03-18 07:07, Anderson Lizardo wrote:
And the same as before, after a short amount of time I start getting
similar (not exactly the same [2]) errors. So it's not the dongle :)
The logs seem to show the same behaviour as the other dongle:
seemingly "random" packets with nonsense parameters (simply because
the HCI packet was assembled incorrectly).
I still blame the USB controller in RPi/Beaglebone for not feeding all
USB fragments to the bluetooth subsystem... at least is my
interpretation from Terry's logs (which are from USB sniffing).
What I have no clue is why this is happenning: both of you tried
powered USB hubs, and this was my only guess (insufficient power on
the bus). If you could find a kernel version for your boards that are
not causing any problems, then we can rule out HW related issues...
I agree that it looks like the USB controller's fault. It seems highly
unlikely, though. A few reasons why I think so:
1. The 2 boards use completely different USB controllers.
2. Both those platforms talk to other USB devices pushing much higher
data rates without any issue.
3. The problem doesn't show up when the bus is forced to USB 1.1 (Full
speed instead of high speed)
4. The problem doesn't only show up during non-duplicate-filtered scans.
I can reproduce it (although it takes a lot longer) with LE
Advertisement packets only coming in once per second.
Let me ask another question:
Are there any other USB devices that ever send a bunch of data with no
polling from the host? IE, if the host has no buffer space to accept an
INT transaction, it will just be lost, and all other USB devices wait
for the INT to be processed by getting an acknowledgement before
generating another INT? Apologies for my lack of in-depth knowledge for
the workings of USB bus transactions.
My suspicion is that if you follow the Bluetooth spec for HCI over USB
(which all of these vendors making these USB devices should) then if the
host USB controller is not fast enough, it can be overwhelmed. Forcing
the bus to full-speed mode, means the bluetooth receiver is forced to
buffer on its end, since it simply cannot transfer data to the host fast
enough to overwhelm it. If my suspicion is true, then that means any
packets of this type could overflow a host if it is busy enough,
although much less likely to happen if the host is more powerful (in
terms of processing power).
Regards,
Terry
--
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
