On 22.12.2011 18:39, Greg KH wrote: > On Thu, Dec 22, 2011 at 12:48:45PM +0100, Matthias Fuchs wrote: >> Hi, >> >> I ran into trouble when using the MPC5121 with full speed >> USB devices. I've seen the issue with USB serial converters >> based on FTDI and Prolific chips. >> >> After connecting the device they first work fine. But when >> I stress the converter communications stalls. I can even force >> this behavior when doing a flood ping against the device. >> Then it only takes a few seconds until USB gets weird. >> >> After some time and several CTRL-C to stop the application >> that uses the ttyUSBx port I get a kernel message: >> >> ftdi_sio ttyUSB0: error from flowcontrol urb >> >> The only thing that reanimates the USB port is doing a reboot. > > Not removing and inserting the device again? unloading the ftdi_sio > driver and reloading it? Right. First I used a monolithic kernel with ftdi_sio and ehci_hcd build in. Now I did the test again with fsl_mph_dr_of, ehci_hcd, usbserial and ftdi_sio loaded as modules. After the error occured, I removed the device and unloaded the modules. After reloading them USB is still weird. usb 1-1: new full-speed USB device number 2 using fsl-ehci usb 1-1: device descriptor read/64, error -110 usb 1-1: device descriptor read/64, error -110 usb 1-1: new full-speed USB device number 3 using fsl-ehci usb 1-1: device descriptor read/64, error -110 > If you look at the data using usbmon, does anything look odd? As long as everything works fine usbmon outputs data like this. It stops a short time after I started the flood ping to the board. df9c16c0 697164417 C Bi:1:002:1 0 2 = 0160 df9c16c0 697164436 S Bi:1:002:1 -115 512 < df9c16c0 697165417 C Bi:1:002:1 0 2 = 0160 df9c16c0 697165441 S Bi:1:002:1 -115 512 < df9c16c0 697166417 C Bi:1:002:1 0 2 = 0160 df9c16c0 697166435 S Bi:1:002:1 -115 512 < df9c16c0 697167417 C Bi:1:002:1 0 9 = 01605f54 48452051 55 df9c16c0 697167450 S Bi:1:002:1 -115 512 < df9c16c0 697168417 C Bi:1:002:1 0 14 = 01604943 4b204252 4f574e20 464f df9c16c0 697168450 S Bi:1:002:1 -115 512 < df9c16c0 697169420 C Bi:1:002:1 0 13 = 01605820 4a554d50 53204f56 45 df9c16c0 697169453 S Bi:1:002:1 -115 512 < df9c16c0 697170418 C Bi:1:002:1 0 14 = 01605220 54484520 4c415a59 2044 df9c16c0 697170451 S Bi:1:002:1 -115 512 < df9c16c0 697171417 C Bi:1:002:1 0 14 = 01604f47 20313233 34353637 3839 df9c16c0 697171450 S Bi:1:002:1 -115 512 < Then I try to abort my application. This result in df9c1340 712766944 S Co:1:002:0 s 40 02 0000 0000 0000 0 df9c1340 717776208 C Co:1:002:0 -2 0 df9c1340 717776503 S Co:1:002:0 s 40 01 0300 0000 0000 0 df9c1340 722786213 C Co:1:002:0 -2 8 > df9c16c0 722796202 C Bi:1:002:1 -2 0 And finally I try to restart my application: df9c12c0 791192447 S Co:1:002:0 s 40 00 0000 0000 0000 0 df9c12c0 796202240 C Co:1:002:0 -2 0 df9c12c0 796203289 S Co:1:002:0 s 40 02 0000 0000 0000 0 df9c12c0 801213213 C Co:1:002:0 -2 0 df9c16c0 801213518 S Bi:1:002:1 -115 512 < df9c12c0 801213560 S Co:1:002:0 s 40 01 0303 0000 0000 0 df9c12c0 806223208 C Co:1:002:0 -2 0 df9c12c0 806223411 S Co:1:002:0 s 40 02 0000 0000 0000 0 df9c12c0 811233210 C Co:1:002:0 -2 0 df9c1440 821344904 S Co:1:002:0 s 40 02 0000 0000 0000 0 df9c1440 826354209 C Co:1:002:0 -2 8 > df9c1440 826354515 S Co:1:002:0 s 40 01 0300 0000 0000 0 df9c1440 831364204 C Co:1:002:0 -2 0 df9c16c0 831374203 C Bi:1:002:1 -2 0 > And what kernel version are you using here? Now I switched to 3.2.0 with only minimal changes for our hardware. But (as expected) I get the same problems. For my eyes it does not really look like a general USB issue. It looks like a problem with the Freescale EHCI implementation that is influenced by high interrupt or internal bus load caused by the flood ping. I put linuxppc-dev on CC. Perhaps soneone in that community can double check it on a Freescale evaluation board. Matthias -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
