• State
  • Locked Locked
  • Replies 8 replies
  • Subscribers 102 subscribers
  • Views 8242 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM335X USB babble interrupt

Adam Ruehl
Intellectual 460 points

I am having an issue on board using an AM335X (similar in design to a beaglebone black). The result is sometimes upon reboot, I get a babble interrupt during enumeration of a USB device. This appears to result in MUSB being reset, but after MUSB reset this device doesn't re-enumerate. It is disconnected then never heard from again until the next reboot of the AM335x. Most reboots succeed, it is just the few that do not which are causing problems.

This log message appears after MUSB is reset and after the device is disconnected from the bus.

musb_stage0_irq 498: bogus host RESUME (a_wait_vfall)

This is with Linux-3.18.20

Does anybody have any thoughts on this?

1. Why would I be getting a babble interrupt in the first place

2. Why doesn't it recover?

3. Should the MUSB driver be waiting until after the USB disconnect (of all devices) before resetting the MUSB controller for recover? I see the reverse happening in my log.

4. There seems to be a lot of chatter out there about the babble interrupt and many patches floating around. So the other question is, does TI have a complete list of patches for MUSB in host mode that I need to be sure are applied that could impact this?

Any help will be greatly appreciated.

A more complete log section below:

2016-01-20 12:48:38,072 - S_CONSOLE - IO <-- [ 1.285859] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
2016-01-20 12:48:38,084 - S_CONSOLE - IO <-- [ 1.293004] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
2016-01-20 12:48:38,095 - S_CONSOLE - IO <-- [ 1.300627] usb usb1: Product: MUSB HDRC host driver
2016-01-20 12:48:38,107 - S_CONSOLE - IO <-- [ 1.305868] usb usb1: Manufacturer: Linux 3.18.20-aron-rob musb-hcd
2016-01-20 12:48:38,118 - S_CONSOLE - IO <-- [ 1.312462] usb usb1: SerialNumber: musb-hdrc.1.auto
2016-01-20 12:48:38,129 - S_CONSOLE - IO <-- [ 1.318516] hub 1-0:1.0: USB hub found
2016-01-20 12:48:38,140 - S_CONSOLE - IO <-- [ 1.322529] hub 1-0:1.0: 1 port detected
[ 2.164455] usb 1-1.2: new high-speed USB device number 3 using musb-hdrc
2016-01-20 12:48:38,362 - S_CONSOLE - IO <-- [ 2.194388] tilcdc 4830e000.lcdc: timeout waiting for framedone
2016-01-20 12:48:38,391 - S_CONSOLE - IO <-- [ 2.224616] CAUTION: musb: Babble Interrupt Occurred
2016-01-20 12:48:38,414 - S_ARM - INFO - serialport (/dev/ttyACM1,115200,8N1): Is not open
2016-01-20 12:48:38,493 - S_CONSOLE - IO <-- [ 2.324418] musb-hdrc musb-hdrc.1.auto: Restarting MUSB to recover from Babble
2016-01-20 12:48:38,521 - S_CONSOLE - IO <-- [ 2.354608] usb 1-1: USB disconnect, device number 2
2016-01-20 12:48:38,546 - S_CONSOLE - IO <-- [ 2.380166] EXT4-fs (mmcblk0p1): recovery complete
2016-01-20 12:48:38,558 - S_CONSOLE - IO <-- [ 2.387391] EXT4-fs (mmcblk0p1): mounted filesystem with ordered data mode. Opts: (null)
2016-01-20 12:48:38,569 - S_CONSOLE - IO <-- [ 2.396313] VFS: Mounted root (ext4 filesystem) on device 179:1.
2016-01-20 12:48:38,580 - S_CONSOLE - IO <-- [ 2.410467] devtmpfs: mounted
2016-01-20 12:48:38,591 - S_CONSOLE - IO <-- [ 2.417316] Freeing unused kernel memory: 784K (c0724000 - c07e8000)
2016-01-20 12:48:38,664 - S_CONSOLE - IO <-- - runit: $Id: 25da3b86f7bed4038b8a039d2f8e8c9bbcf0822b $: booting.
2016-01-20 12:48:38,675 - S_CONSOLE - IO <-- - runit: enter stage: /etc/runit/1
2016-01-20 12:48:38,962 - S_CONSOLE - IO <-- [ 2.794626] usb 1-1: new high-speed USB device number 4 using musb-hdrc
2016-01-20 12:48:39,080 - S_CONSOLE - IO <-- [ 2.910494] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null)
2016-01-20 12:48:39,113 - S_CONSOLE - IO <-- [ 2.944868] usb 1-1: New USB device found, idVendor=0424, idProduct=2512
2016-01-20 12:48:39,125 - S_CONSOLE - IO <-- [ 2.952719] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
2016-01-20 12:48:39,136 - S_CONSOLE - IO <-- [ 2.967113] hub 1-1:1.0: USB hub found
2016-01-20 12:48:39,147 - S_CONSOLE - IO <-- [ 2.980446] hub 1-1:1.0: 2 ports detected
2016-01-20 12:48:39,208 - S_CONSOLE - IO <-- /etc/runit/1: line 61: echo: write error: No such device
2016-01-20 12:48:39,220 - S_CONSOLE - IO <-- /etc/runit/1: line 63: echo: write error: No such device
2016-01-20 12:48:39,295 - S_CONSOLE - IO <-- [ 3.128102] bq27x00-battery 1-0055: support ver. 1.2.0 enabled
2016-01-20 12:48:39,306 - S_CONSOLE - IO <-- [ 3.139937] cryptodev: driver 1.6 loaded.
2016-01-20 12:48:39,414 - S_ARM - INFO - serialport (/dev/ttyACM1,115200,8N1): Is not open
2016-01-20 12:48:39,521 - S_CONSOLE - IO <-- [ 3.354742] g_serial gadget: Gadget Serial v2.4
2016-01-20 12:48:39,532 - S_CONSOLE - IO <-- [ 3.359541] g_serial gadget: g_serial ready
2016-01-20 12:48:39,543 - S_CONSOLE - IO <-- [ 3.363966] musb_stage0_irq 498: bogus host RESUME (a_wait_vfall)

  • 0
    TI__Guru**** 161600 points
    Hi,

    I am not familiar with the 3.18 kernel, so I refer to TISDK 1.00.03 (kernel 3.14.43).

    I have a couple of suggestions.

    1. Have a look in drivers/usb/musb/musb-core.c :
    in static int musb_runtime_resume(struct device *dev), you have:
    schedule_delayed_work(&musb->finish_resume_work,
    msecs_to_jiffies(USB_RESUME_TIMEOUT));

    currently USB_RESUME_TIMOEUT is defined in include/linux/usb.h:
    #define USB_RESUME_TIMEOUT 40 /* ms */

    try increasing the value to 60ms.

    2. Try disabling the runtime power management & see if the babble interrupt will be fixed.

    3. See the following thread:
    e2e.ti.com/.../356030

    Best Regards,
    Yordan
  • 0 in reply to Yordan Kovachev
    Intellectual 460 points

    Yordan,

    Thanks for the reply. We will change the timeouts and give that a try. What about the recovery problem though:

    musb_stage0_irq 498: bogus host RESUME (a_wait_vfall)

    After the MUSB reset due to the babble interrupt, it appears as though the device detection is happening in the wrong state (A_WAIT_VFALL) instead of A_WAIT_BCON. It seems like the MUSB host controller is in the wrong state when the device comes back after the USB disconnect. Also, during babble recovery MUSB is reset. Should the USB disconnect for all connected devices come in before MUSB is reset ?

    Regards,

    Adam

  • 0
    Expert 1940 points
    Hello Adam,

    Did you ever determine the problem or a work around for this issue?

    We are having an almost-identical issue. Ours is directly related to the eth0, e.g. if I pull the eth0 while connected, I get

    [13314.062686] musb-hdrc musb-hdrc.1.auto: Babble

    and our one enumerate device is issued a disconnect, which of course removes the driver and all access to it.

    Here is my e2e post on our problem: e2e.ti.com/.../489649
  • 0 in reply to Randy Yates
    TI__Guru**** 161600 points
    Hi,

    Have you tried the proposed workarounds above, to test if they have any effect?

    Best Regards,
    Yordan
  • 0 in reply to Yordan Kovachev
    Expert 1940 points
    Yordan,

    Thanks for responding. No, I haven't yet, to answer your question.

    Do you have any thoughts on which one of the at least three potential changes would be most likely to address our particular problem?
  • 0 in reply to Randy Yates
    Intellectual 460 points

    Randy,

    We increased the resume_timeout and have not seen this issue pop up yet. However, I will caution you that I would consider my testing incomplete. This was an intermittent issue and there are a couple of other unrelated issues blocking our automated test setup from running long enough to get enough test runs to prove that the issue has really gone away. 

    We did not try disabling run time power management. The issue we were having was at power on initialization of the AM335x host so I didn't think we weren't really doing any power management at that point in init where we see the problem. 

    We will update when there are conclusive results.

    Regards,

    Adam

  • 0 in reply to Yordan Kovachev
    Expert 1940 points
    Hi Yordan,

    I looked into the drivers/musb_core.c driver last night (very roughly)
    and it appears that the babble message comes from receiving a babble
    interrupt from the AM335x on-board USB peripheral.

    If that is the case, how can any patch or kernel version fix this
    problem? It appears what we need to do to fix our problem is
    understand what causes the AM335x USB peripheral to generate this
    interrupt, e.g., does it monitor power variations, DM/DP voltages,
    etc., or what?

    Do you agree? If so, do you or anyone at TI know the conditions which
    cause the AM335x USB peripheral to emit a babble interrupt?
  • 0 in reply to Randy Yates
    TI__Guru**** 161600 points

    Hi Randy,

    I am reposting my answer from your original thread:

     "Hi Randy,

    You've referenced another thread about USB babble interrupt: , on which I am still working.

    Also I see you use debian jessie/4.4 linux, with which I am not very well familiar, so I will reference the official TI SDK (kernel 4.1.13).

    Randy Yates said:
    If so, does anyone at TI know the conditions which cause the AM335x USB peripheral

    to emit a babble interrupt?

    See this thread: According to usb specs : "Babble: Unexpected bus activity that persists beyond a specified point in a (micro)frame.". In my experience I've seen reports for babble interrupt when usb is "overly busy", upon hotplugging, when a usb hub with more than one device doing I/O, etc.

    The workarounds I've seen to have positive effect are as stated in the thread you refer to earlier:

    This is what I can comment on this problem. I hope it is of use to you.

    Best Regards,

    Yordan"

    I'd suggest to keep the discussion here. So that it is easier to track.

    Best Regards,

    Yordan