On Fri, 2011-08-19 at 11:38 -0700, Sarah Sharp wrote: > 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). > OK, I have tried with a USB3 external hub, and observed the warm reset issue you described: the sleeping time is too short for xHC host to report a BH reset change. However, later the BH reset change handling code in hub_events() did it for me, so the port is still alive. Not sure why it does not work in your case. Anyway, warm reset logic needs to be modified and I'm trying to make hub_port_reset() handles warm reset too, but the function becomes too big and its readability becomes lower. So I decide to keep the hub_port_warm_reset() function, introduce longer sleep with periodically port status check, just like hub_port_wait_reset() does. Is that acceptable? Do you think several retry for BH reset is necessary? 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
