> -----Original Message----- > From: Sarah Sharp [mailto:sarah.a.sharp@xxxxxxxxxxxxxxx] > Sent: Saturday, August 20, 2011 2:39 AM > To: Xu, Andiry > Cc: jerome huang; linux-usb@xxxxxxxxxxxxxxx > Subject: Re: Problem with usb3 flash drive > > 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). > I see, I'll double check warm reset logic. And - Happy Birthday! :) Thanks, Andiry -- 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
