I’m using my Beaglebone Black with a USB temperature sensor. It works very well, however I noticed monitoring stopped last night after roughly 35 days uptime. This morning I looked more closely into the log file and noticed:
I wasn’t able to successfully reset the USB device and before I was able to restart the BBB stopped responding. I power-cycled it and it was back to normal again. Any ideas what caused this kernel message?
Exactly same thing happen to me.
USB sensor, beagleboneblack running for 10 days and today I found it in a 5h loop “CAUTION: musb: Babble Interrupt Occurred”, then it restart.
Have you confirmed that this patch works? I’m running Debian Wheezy and getting the same issue myself. Wifi dongle drops out and will not come back up unless i power cycle.
Would this kernel fix work with Debian? Or just Anstrom?
I often get another message as well:
[92458.978265] CAUTION: musb: Babble Interrupt Occurred
[92459.049531] gadget: high-speed config #1: Multifunction with RNDIS
These two almost always travel in pairs. Sometimes multiples of them will appear.
Running an rtl819cu wifi chipset. The one adafruit sells.
That patch was first enabled with the "3.8.13-bone28" release..
I'm running Debian Wheezy and
getting the same issue myself. Wifi dongle drops out and will not come back
up unless i power cycle.
Would this kernel fix work with Debian? Or just Anstrom?
I often get another message as well:
[92458.978265] CAUTION: musb: Babble Interrupt Occurred
[92459.049531] gadget: high-speed config #1: Multifunction with RNDIS
These two almost always travel in pairs. Sometimes multiples of them will
appear.
Running an rtl819cu wifi chipset. The one adafruit sells.
Btw, as long as you are not using any capes, you can also give
v3.12-rc6 a try as usb seems to be working a lot better with these
wifi devices..
Not surprised. I’ve had all sorts of problems with USB when using a hub chip. It all seems to point to a software/driver glitch. I really wish I could help out to fix it, but I’m more of an application developer.
Ditto here, application/solutions developer skills, not driver/kernel stuff.
This ‘CAUTION: musb: Babble Interrupt Occurred’ error is an unfortunate deal-breaker for me, and that’s a real shame considering that we were going to deploy ~28+ of these for our factory automation needs. The form-factor is a tremendous asset, and it’s ability to leverage python and external resources is spot-on.
Would easily pay for a solution to get this resolved.
I resolved my issue by installing and using Ubuntu 13.04 on the BBB. It’s been up and running the python scanning script for over 24 hours, which is roughly 23 hours longer than it has before. I used the instructions at http://shrkey.com/setting-up-beaglebone-black-to-boot-off-the-microsd-card/ to get the installation squared away.
A few more updates. I’ve read in a number of other locations that this might be due to a grounding issue or a power draw issue. Starting with tackling the power draw issue, it appears that the system bus outputs different power to the USB device depending on its CPU throttling status. The lower the CPU speed, the (slightly) lower the USB output.
Still using Ubuntu 13.04, I’ve removed both the S99ondemand startup script from the rc2.d folder, as well as placed the line "
echo ‘on’ | tee /sys/bus/usb/devices/usb1/power/control" in the /etc/rc.local script (no quotes) to try and mitigate the issue. The former, from what I understand, keeps the CPU running at full speed, and does not let it slow down based on demand, the latter works to keep USB power on to the port at all times, rather than letting the BBB decide whether to power it off/on.
At this point, the BBB has not thrown any more Babble errors through multiple power off/on events, nor through any extensive scanning or quiet time.
Of note, there may also be some merit in the grounding issue, as walking across the floor and then touching the BBB case will occasionally cause the Babble issue to appear and the Symbol device to power off. The device is connected to a DC power supply, but there is no grounding plug with the brick, so it stands to reason that the device is not grounded.
Hope this helps someone… although I’m sure that at this point I have no concrete solutions to the problem.
In my case I have a cape that connects via USB (besides the usual headers). And I have a TP on VBUS, sometimes just inserting a tester on the test point generates a Babble Interrupt.
Mine isn’t properly grounded.
You can always check the governor and cpu frequency with:
Bummer, despite all of the research, the musb: Babble Interrrupt issue continues to plague. In the hopes that there’s a hardware dev out there listening. The board I’m using is A5C.
Work as an independent linux consultant, and I think I can fix this problem.
Offered TI to do this, but they said it would be fixed in 3.12, so no interest.
Well, 3.12 is here and no fix as far as I can see in the code.
I estimate 2 days work to fix with testing.
Ulf, many thanks for the mention. If I hit the last brick wall, I’ll hire you to make the fix available.
Meanwhile, some interesting developments. Curious about the grounding conversation, I removed the BBB from the metal case in which it was enclosed, and placed it on a non-conductive mat. Powered it on with the scanner attached, and it works as it should. BUT, I have not had the Babble Interrupt issue again. Even handling the bare board, the USB wire, the scanner, all of which might have triggered the interrupt before, the scanner continues to work. After 2 days, and still no interruption, I power-cycled the BBB, and again, it has run perfectly with no interruptions for another 2 days, even with the continued attempts to cause the interrupts to occur. By now, I would have had easily a dozen Babble Interrupts with the metal case.
I’m going to restore the ondemand startup script and power control settings to ‘normal’ and continue testing.
The scanner does not power back on if disconnected. The BBB has to be power cycled before the scanner is usable.
The relevant DMESG entries are below:
[15104.176465] hub 1-0:1.0: state 7 ports 1 chg 0000 evt 0002
[15104.176536] hub 1-0:1.0: port 1, status 0100, change 0001, 12 Mb/s
[15104.176555] usb 1-1: USB disconnect, device number 2
[15104.176566] usb 1-1: unregistering device
[15104.176579] usb 1-1: unregistering interface 1-1:1.0
[15104.176809] musb-hdrc musb-hdrc.1.auto: shutdown urb df5da6c0 ep1in-intr
[15104.177785] usb 1-1: usb_disable_device nuking all URBs
[15104.290606] hub 1-0:1.0: debounce: port 1: total 100ms stable 100ms status 0x100
[15104.290694] hub 1-0:1.0: hub_suspend
[15104.290724] usb usb1: bus auto-suspend, wakeup 1