On Wed, 25 Apr 2012, [ISO-8859-1] Miguel �gel �varez 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 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 ... 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. Alan Stern -- 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
