> -----Original Message----- > From: Sarah Sharp [mailto:sarah.a.sharp@xxxxxxxxxxxxxxx] > Sent: Wednesday, December 15, 2010 5:24 AM > To: Alan Stern > Cc: Jon 'maddog' Hall; linux-usb@xxxxxxxxxxxxxxx; Xu, Andiry > Subject: Re: The dmesg files requested > > On Tue, Dec 14, 2010 at 09:56:58AM -0500, Alan Stern wrote: > > On Mon, 13 Dec 2010, Jon 'maddog' Hall wrote: > > > > > Alan and Sarah, > > > > > > Tonight I received a Transcend USB 3,0 ExpressCard Adapter. > > > > > > I booted the 2.6.37-rc5-git3 kernel I built, plugged the ExpressCard > > > Adapter into my W510, and the USB2.0 Flash memory stick into one of > the > > > slots of the ExpressCard Adapter. > > > > > > The Transcend USB 3.0 ports work exactly the same as the native W510 > USB > > > 3.0 ports: > > > > > > o the flash drive is mounted and accessable > > > o I click on "remove the drive safely" and the USB 2.0 flash stick > > > unmounts, but continues to flicker > > > o I pull it out and plug it back in and NADA...the port seems to be > > > dead. > > > o I put the flash into the other USB 3.0 port and that one is alive, > > > mounts the stick > > > o I unmount it (it flickers), I pull it out and put it back again, and > > > the port is "dead"....I move it back to the first port and that port > is > > > alive again > > > > > > So the Transcend USB 3.0 ExpressCard Adapter is having exactly the > same > > > characteristics as the built-in controller. > > > > > > The "dead/non-dead" is also exhibited with other devices, not just the > > > flash. > > > > Sarah, you may be able to duplicate this behavior on your own machine. > > All you have to do is unmount the flash drive and then write anything > > to the "remove" attribute in the sysfs directory for the drive's USB > > device. > > Yes, I can reproduce this. I was trying to figure out if it's a > hardware or a software issue, so I looked at the state diagram in figure > 33 of the xHCI 1.0 spec. > > On a write to disable the port, the host state machine should transition > back to the disabled state. When a USB disconnect is detected, the host > should transition to the disconnect state, set CSC = 1, clear CCS, and > clear the port disabled bit. I see an xHCI port status change when > there's a device disconnect, but I'm not sure what the port status is, > as khubd doesn't seem to poll the port status when I kick it for that > port. I get no interrupts when I plug a device in. Perhaps because the > USB core never cleared the connect status change on disconnect? > > In fact, I think this code in handle_port_status() is the problem: > > if ((temp & PORT_CONNECT) && (hcd->state == HC_STATE_SUSPENDED)) { > xhci_dbg(xhci, "resume root hub\n"); > usb_hcd_resume_root_hub(hcd); > } > > khubd is getting kicked because of the disconnect status, but because > the roothub is never resumed, it doesn't do anything with it. Then a > new device is connected, the CSC flag is still not cleared, so the HW > doesn't re-interrupt the system for that port. > > Andiry, why were you only resuming the roothub when something was > connected to the port? If I remove the first conditional, then the > system works as expected and I see a new connect after the 'remove' > sysfs file is written. > Ah... I've reproduced this issue and verify that remove the first conditional resolves it. In my original design I assume that when a new device connects to a suspended hcd, it should be resumed; disconnect a device from a suspended hcd without resume it seems harmless. Apparently I'm wrong and ignore the CSC bit clear... As Alan says, any port status change should resume the root hub. Thanks for catching this. I'm OK with the RFC patch. 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
