Alan Stern wrote: > On Sat, 5 May 2012, Martin Mokrejs wrote: > >> Hi Alan, >> I am testing how the ASMedia2105 works with USB2 controllers (while being USB3.0 >> capable and doing well with Texas Instruments host while not with NEC uPD720200 >> 3.0.25 nor 3.0.2.8 firmwares at least). I see four different scenarios when testing >> with the eSATA/USB port in my laptop, Dell Vostro3550. Should be the below chip. > > I don't understand. Why did you send this email? Sorry, the sentence is overly complex. I wanted to report the various negotiations against USB2.0 host controller. Just for completeness I noted that is the the USB 3.0 chip, at least sometimes printed on the chip as "ASM1051 A1" at reporting to the host itself as ASM2105. I have one such device which merely works and another which merely does not work at all (against Texas Instruments chip). None of the two devices can talk with NEC controller. So, I wanted to first see what happens at USB2 speeds. I posted the logs for the device which does merely work and was curious what are those benign errors popping up (against the TI host). I did not want to confuse that with the NEC host stuff. > >> It failed for me once but I do not have the corresponding usbmon capture. > > ... >> [10462.609293] hub 1-1:1.0: port 1, status 0101, change 0000, 12 Mb/s >> [10462.689285] usb 1-1.1: new full-speed USB device number 4 using ehci_hcd >> [10462.768925] usb 1-1.1: device descriptor read/64, error -32 >> [10462.958779] usb 1-1.1: device descriptor read/64, error -32 >> [10463.148504] usb 1-1.1: new full-speed USB device number 5 using ehci_hcd >> [10463.228382] usb 1-1.1: device descriptor read/64, error -32 >> [10463.418105] usb 1-1.1: device descriptor read/64, error -32 >> [10463.607817] usb 1-1.1: new full-speed USB device number 6 using ehci_hcd >> [10464.026931] usb 1-1.1: device not accepting address 6, error -32 >> [10464.107070] usb 1-1.1: new full-speed USB device number 7 using ehci_hcd >> [10464.526181] usb 1-1.1: device not accepting address 7, error -32 >> [10464.526459] hub 1-1:1.0: unable to enumerate USB device on port 1 > ... > >> While trying to reproduce the issue I ended up with 4 different dmesg snippets and >> corresponding usbmon traces (attached). >> Maybe it is still of some help? > > Help for what? Do you want to know why the 2105 doesn't work very > well? Yes. And whether ehci_hcd is doing the right thing in each case and whether there is a reason different trajectories were taken. ;-) > > My impression is that it turns on the electrical connection to the > computer before it is fully set up and ready to operate. As a result, > the first one or two times it can't respond properly when the computer > tries to initialize it. You talk about the above dmesg which was in the body of the email, right? That was the case when it failed completely to catch up. Unfortunately, I wasn't able to reproduce but at least I collected traces for 4 distinct situations. So how about those attached files (4 cases, each dmesg + usbmon)? There are also errors but *were overcome*. Still I thought it is good to think of them. Well, stuff for you if you have time and maybe can find that linux could do better. For example, if the eSATA/USB port was used for eSATA stuff it was in a "clean" state I would say and therefore, the USB3.0 bridge caught up seamlessly. That was not the of other cases, when I re-plugged the USB data cable into the very same eSATA/USB socket. Probably because of previous communication the negotiations were different? I like this Manhattan USB3.0 TO SATA dongle (rev. 3.04). I bought because it was reported to have the Sunplus Fujisui MB86C30 but it seems they changed the contents and slightly the design. But it was a nice surprise. If this exact device will work fine for me with TI USB3.0 controller (as it seems so) and work well with USB2.0 hosts, I will keep it. It is really fast. Would it once work with NEC controller, even better. Thanks, Martin Note: Regarding my NEC-based express cards, as I bought several USB bridges I realized with full USB debug options in kernel that when I touch with the male USB plug (from the dongle) the outer metal (grounding?) of the female socket in the express card, a lot of stuff happens (pciehp surprise removal, etc.). Touching the socket for a while leads to many such "removals of the express card" and as I already learned last week,leads to kernel Oops in the sysfs device removal. But because it happens with several USB to SATA bridges I don't think it is their fault. It looks like the Dell problem. Technician should come on Monday. So, this was another reason why I did not want to report anything on the ASM2105 to NEC connection issues and rather stayed with USB2.0 host controller. -- 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
