On Fri, Aug 19, 2011 at 06:03:56PM +0800, Xu, Andiry wrote: > > -----Original Message----- > > From: linux-usb-owner@xxxxxxxxxxxxxxx [mailto:linux-usb- > > owner@xxxxxxxxxxxxxxx] On Behalf Of jerome huang > > Sent: Friday, August 19, 2011 5:48 PM > > To: Xu, Andiry > > Cc: linux-usb@xxxxxxxxxxxxxxx; sarah.a.sharp@xxxxxxxxxxxxxxx > > Subject: Re: Problem with usb3 flash drive > > > > Hi Andiry, > > > > here are the dmesg log and lsusb log. > > Although this device does not exist in lsusb -t, but it can be found > in > > lsusb -v. > > > > The last git hash of this test kernel is > > 338d0f0a6fbc82407864606f5b64b75aeb3c70f2 > > > > Just as I thought, xHC reports the device under HS port and reports its > speed as High Speed. > So it will be initialized as a HS device and put under the USB2 root > hub. > > It looks like a HW/FW issue, because driver's behavior relies on the > port register status report. Let's see if Sarah(xHCI maintainer) has > some suggestions. Yeah, there's nothing terribly interesting in the logs. It just shows that the device didn't come up as a SuperSpeed device. Perhaps it just fails to link train at boot? I would just chalk it up to a buggy device. However, Jerome reminded me of something I wanted to get your opinion on, Andiry. I've been seeing an issue with USB 3.0 ports seeming "dead" after I unplug and replug in a USB 3.0 device. I don't think it's related to Jerome's failure, just to be clear. :) I saw this issue with a USB 3.0 hub that would connect as SuperSpeed once, but come back as a high speed device when plugged in a second time. After that first unplug, any other USB 3.0 device plugged into the port would come up as a high speed device. I think this was cased by the USB core not clearing the BH reset change bit properly. When I unplugged the device, the port was reported to be in the Inactive state, and the hub driver initiated a BH reset. The timeout for the reset was too small, so the hub driver just freed the usb_device structure before the reset completed. (As a side note, we should probably change hub_port_warm_reset to be similar to hub_port_reset, with an increasing amount of delay with several retries. We probably should just change hub_port_reset to take a parameter to say which type of reset to try.) Later, the BH reset completed and the xHCI driver reported the port status change to the USB core. Despite reading the port status three times, the USB core did not call into the xHCI driver to clear the BH reset change bit. Since the xHCI host controller specification says a host shouldn't send a port status change event until after all the port status change bits are cleared, this means a new device connection doesn't get noticed. After that, the USB 3.0 port seems "dead" and SuperSpeed devices will connect at high speed. I played around with increasing the msleep in hub_port_warm_reset from 20 to 100, and that was long enough for the BH reset to complete and hub_port_warm_reset to notice the change bit and clear it. I'm not sure why the code in hub_port_warm_reset detects the change bit and the code that handled the port status change (which I assume is hub_events) does not. I'm traveling today, and I don't have access to the logs on the box that was failing. I'll send them on Monday (or possibly Tuesday, since Monday is my birthday and I may take the day off). Sarah Sharp -- 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
