CAUTION: musb: Babble Interrupt Occurred

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:

kernel: [2892926.929555] CAUTION: musb: Babble Interrupt Occurred

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.

Any ideas?

You could try this patch… it may help with the Babble Interrupt errors. I haven’t tried it myself, but I hope to tomorrow.
https://github.com/beagleboard/kernel/commit/46505ea7162720ee8805c8443bf7f10052b9ee7f

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.

Have you confirmed that this patch works?

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..

Regards,

That’s what I’m running, so then maybe that’s not the answer :slight_smile:

Any other ideas as to why the USB drops out?

Regards,
Rune

I’ve got the same ‘CAUTION: musb: Babble Interrupt Occurred’ error in dmesg. Running the latest Angstrom on the Black with a Symbol DS457 attached.

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.

I have a powered USB hub “Plugable” branded. Every time I plug it on my bones I got the Babble Interrupt.

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.

Same problem here. Im also willing to pay for a solution

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.

Crap. On third reboot (full power off/on), the device is experiencing the same musb: Babble Interrupt error as before.

So… this is a hardware issue? The BBB is powered by a separate adapter (not USB), so power shouldn’t be the problem.

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:

juanjo@balin:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
ondemand
juanjo@balin:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
300000

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

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.

What happens if you remove the scanner, and plug it in again?

Best Regards
Ulf Samuelsson

20 nov 2013 kl. 17:56 skrev Philippe Laurent <pbl@ideos.com>:

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