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.
Maddog, I'll send you a patch to test shortly.
Sarah Sharp
p.s. I can see that Nautilus tries to write to power/level and gets a
deprecated notification when the "Safely Remove" option is selected.
Nautilus then segfaults because of it. Nautilus is probably doing a
similar thing in Maddog's environment, so that's what is auto-suspending
the USB hard drive.
--
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
