Hi, On Wed, Feb 06, 2013 at 05:03:36PM +0200, Roger Quadros wrote: > On 02/06/2013 03:51 PM, Felipe Balbi wrote: > > Hi, > > > > On Wed, Feb 06, 2013 at 05:27:52PM +0530, Vivek Gautam wrote: > >> Hi Tony, > >> > >> > >> On Fri, Oct 5, 2012 at 9:57 PM, Tony Lindgren <tony@xxxxxxxxxxx> wrote: > >>> * Tony Lindgren <tony@xxxxxxxxxxx> [121004 18:41]: > >>>>> > >>>>>> Also on the EHCI port, I've seen issues where unplugging > >>>>>> the cable hangs kernel with an infinite loop. But that happens > >>>>>> only occasionally, sorry does not seem to happen right > >>>>>> now so no output to paste here. Or maybe this issue > >>>>>> has already been fixed? > >>> > >>> Looks like the system eventually recovers from the EHCI issue > >>> after about fivew minutes or so of spamming the logs. It seems > >>> the ehci-omap errors are: > >>> > >>> [62934.201538] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 31 > >>> [62934.201660] ehci-omap ehci-omap.0: devpath 1.3.7 ep0out 3strikes > >>> [62934.201873] ehci-omap ehci-omap.0: reused qh ea5632c0 schedule > >>> > >>> More data below. > >>> > >> > >> Is this issue fixed ? > >> Actually we too are getting very similar issue with samsung exynos5250 hardware. > >> With latest 'usb-next' kernel and supporting arch patches, when i use > >> following test scenerio: > >> Connect a USB 2.0 external hub to USB 2.0 port, and connect mice or > >> keyboard enumeration and > >> functionality is fine but once disconnecting the HID we get to see the > >> error log: > >> hid-generic 0003:04B3:3025.0002: can't reset device, > >> s5p-ehci-1.3/input0, status -71 > >> > >> When i tried to enable CONFIG_USB_DEBUG, get the following log: > > > > looks like it's not OMAP-specific. Alan any tips ? > > > > I can't reproduce the problem on Panda, but I can on Beagle with a slightly > different behaviour. > > 1) connecting/disconnecting device directly to the beagleboard's USB port works fine. > > 2) If I connect a USB Hub to the port and connect a device to it after the hub has > autosuspended, the device is never detected. > doing lsusb after that triggers the detection and produces a lot of transaction errors. > Beagle log is below, before and after 'lsusb' > > I suppose this doesn't affect Panda because it has a hub connected immediately below the > root hub that never suspends (as ethernet is hardwired to it). Roger, try changing hub's autosuspend delay to something greater than 30ms and see if it helps. There was a discussion lately about that. -- balbi
Attachment:
signature.asc
Description: Digital signature