Thanks Alan, On Wed, Apr 25, 2012 at 7:27 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Wed, 25 Apr 2012, [ISO-8859-1] Miguel Ángel Álvarez wrote: > >> Dear all, >> >> First of all let me apologize if this question should be done in other >> list. In that case, if anyone can redirect me I would be very >> thankful. >> >> We have designed a board based on Freescale P2020 in which we have >> implemented linux-2.6.32. >> >> Attached to the P2020 we have an USB3300 (which interfaces UTMI to >> ULPI) and then an SSD with USB interface. >> >> When we boot, we have the USB3300 in a reset state, and when we made >> it leave this state and begin to work, we obtain the following traces. > > ... >> 2005/01/14,00:39:59 nucs kern.debug kernel: fsl-ehci fsl-ehci.0: >> detected XactErr len 0/8 retry 1 >> 2005/01/14,00:39:59 nucs kern.debug kernel: fsl-ehci fsl-ehci.0: >> detected XactErr len 0/8 retry 2 >> 2005/01/14,00:39:59 nucs kern.debug kernel: fsl-ehci fsl-ehci.0: >> detected XactErr len 0/8 retry 3 > ... > > These messages indicate USB communication errors. Most likely the > computer did not receive a response packet from the SSD. > >> I have explored the internet and have found some experiences of this >> kind with different laptops... It seems that removing ehci or >> resetting the device is sometimes the solution, but in my case >> removing ehci is not an option. >> >> The relevant configuration of the kernel (as far as I know) is: >> CONFIG_USB_SUPPORT=y >> CONFIG_USB_ARCH_HAS_HCD=y >> CONFIG_USB_ARCH_HAS_OHCI=y >> CONFIG_USB_ARCH_HAS_EHCI=y >> CONFIG_USB=y >> CONFIG_USB_DEVICEFS=y >> CONFIG_USB_EHCI_HCD=y >> CONFIG_USB_EHCI_ROOT_HUB_TT=y >> CONFIG_USB_EHCI_FSL=y >> CONFIG_USB_EHCI_HCD_PPC_OF=y >> CONFIG_USB_STORAGE=y > > That combination of settings doesn't make sense. If your EHCI root hub > has a built-in TT then there's no reason to have an OHCI controller as > well. Are you sure that's what you want? > I thought it was required to have an OHCI also... I will change the configuration and test again. >> I have also take a look to usbmon.txt and have obtained the following >> traces with usbmon: >> "dfbbdc80 199323393 C Ii:1:001:1 0:2048 1 = 02 >> dfbbdc80 199323420 S Ii:1:001:1 -115:2048 4 < >> df164500 199323575 S Ci:1:001:0 s a3 00 0000 0001 0004 4 < >> df164500 199323601 C Ci:1:001:0 0 4 = 01010100 >> df164500 199323657 S Co:1:001:0 s 23 01 0010 0001 0000 0 >> df164500 199323663 C Co:1:001:0 0 0 >> df164500 199323680 S Ci:1:001:0 s a3 00 0000 0001 0004 4 < >> df164500 199323684 C Ci:1:001:0 0 4 = 01010000 >> df164500 199355049 S Ci:1:001:0 s a3 00 0000 0001 0004 4 < >> df164500 199355060 C Ci:1:001:0 0 4 = 01010000 >> df164500 199387044 S Ci:1:001:0 s a3 00 0000 0001 0004 4 < >> df164500 199387051 C Ci:1:001:0 0 4 = 01010000 >> df164500 199419045 S Ci:1:001:0 s a3 00 0000 0001 0004 4 < >> df164500 199419052 C Ci:1:001:0 0 4 = 01010000 >> df164500 199451050 S Ci:1:001:0 s a3 00 0000 0001 0004 4 < >> df164500 199451057 C Ci:1:001:0 0 4 = 01010000 > > The part above shows a normal connection and debounce. > >> df164500 199451088 S Co:1:001:0 s 23 03 0004 0001 0000 0 >> df164500 199451092 C Co:1:001:0 0 0 >> dfbbdc80 199506111 C Ii:1:001:1 0:2048 1 = 02 >> dfbbdc80 199506118 S Ii:1:001:1 -115:2048 4 < >> df164500 199507054 S Ci:1:001:0 s a3 00 0000 0001 0004 4 < >> df164500 199507062 C Ci:1:001:0 0 4 = 03050000 >> usb 1-1: new high speed USB device using fsl-ehci and address 2 >> df164500 199647083 S Co:1:001:0 s 23 01 0014 0001 0000 0 >> df164500 199647090 C Co:1:001:0 0 0 > > This shows a normal port reset. > >> df164500 199652801 S Ci:1:000:0 s 80 06 0100 0000 0040 64 < >> df164500 199656936 C Ci:1:000:0 -71 0 >> df164500 199658438 S Ci:1:000:0 s 80 06 0100 0000 0040 64 < >> df164500 199662434 C Ci:1:000:0 -71 0 >> df164500 199664958 S Ci:1:000:0 s 80 06 0100 0000 0040 64 < >> df164500 199668934 C Ci:1:000:0 -71 0 > ... Is there any readable documentation that can help me in interpreting the frames? I do not want to disturb you people if I can manage to do it myself. By the way... The Ci does not mean traffic from device to host? > > These and the rest show the computer asking the drive to send its > device descriptor and not getting any response. The attempt is retried > several times, then the port is reset and the computer tries the > inquiry again, and so on. > >> I am not an expert with USB, so I do not really know how to correctly >> interpret this traces or what else to test. > > If you can, you should attach a USB bus analyzer on the connection > leading to the SSD to see whether it really is sending any response > packets back to the computer. Or indeed, whether the computer's > inquiries are getting sent over the USB connection to the drive in the > first place. > >> I am not an expert with USB, so I do not really know how to correctly >> interpret this traces or what else to test. > > If you can, you should attach a USB bus analyzer on the connection > leading to the SSD to see whether it really is sending any response > packets back to the computer. Or indeed, whether the computer's > inquiries are getting sent over the USB connection to the drive in the > first place. > This should be the best way, of course. Any recommendations on USB bus analyzers? Thanks for all, Miguel Ángel -- 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
