Finally came back to this problem, and setting USB to 1.1 (dwc_otg.speed=1 in /boot/cmdline.txt) fixes the problem. So indeed that is a USB problem. Thanks for the help! :) Adam On 20 Mar 2014, at 00:47, Terry Hardie <terryh@xxxxxxxxx> wrote: > 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 > -- Adam Warski http://twitter.com/#!/adamwarski http://www.softwaremill.com http://www.warski.org -- 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
