On Tue, Apr 05, 2011 at 09:53:14AM -0400, Alan Stern wrote: > On Mon, 4 Apr 2011, Sarah Sharp wrote: > > > On Sat, Apr 02, 2011 at 04:35:17AM -0400, CAI Qian wrote: > > > Hi Sarah, > > > > > > After applied this patch on the top of USB3 hub changes patches in my branch (can also reproduce the original problem), the problem is still existed. > > > > > > Freezing user space processes ... (elapsed 0.01 seconds) done. > > > Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. > > > PM: Preallocating image memory... done (allocated 3924380 pages) > > > PM: Allocated 15697520 kbytes in 2.53 seconds (6204.55 MB/s) > > > hub 8-1:1.0: suspend error -16 > > > pm_op(): usb_dev_freeze+0x0/0x20 returns -16 > > > PM: Device 8-1 failed to freeze: error -16 > > > > So I think the 8-1 device is your roothub. > > No, it can't be. The root hub would be named usb8. 8-1 is the device > plugged into port 1 on the root hub. Hmm, ok, that would probably be the USB 3.0 external hub then. CAI, can you also post the `lsusb -v` output? A second theory I had was about the external hub. I don't know how the xHCI host controller will react to suspending a hub when the devices downstream aren't suspended. The xHC sort of knows which devices are suspended, because the xHCI driver will stop all endpoints with the suspend flag set. Since we're just powering down the port, not calling usb_device_disconnect, the xHCI host controller will still have an internal representation of the hard drive behind the hub (i.e. a slot context with enabled endpoints). I don't know how the host will react to the interrupt endpoint on the USB 3.0 hub being stopped with the suspend bit set when the child devices still have active endpoints. The behavior could be specific to which host controller they are testing under, which is why I was asking about what hardware both Andiry and CAI were using. But all this theorizing is moot until I get more debugging output from CAI. 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
