----- Original Message -----
> 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. There's a couple different
> places the code could return -EBUSY (which is what -16 is).
]# ./lsusb.py
usb1 1d6b:0002 09 2.00 480MBit/s 0mA 1IFs (ehci_hcd 0000:00:1a.7) hub
usb2 1d6b:0002 09 2.00 480MBit/s 0mA 1IFs (ehci_hcd 0000:00:1d.7) hub
usb3 1d6b:0001 09 1.10 12MBit/s 0mA 1IFs (uhci_hcd 0000:00:1a.0) hub
usb4 1d6b:0001 09 1.10 12MBit/s 0mA 1IFs (uhci_hcd 0000:00:1a.1) hub
usb5 1d6b:0001 09 1.10 12MBit/s 0mA 1IFs (uhci_hcd 0000:00:1d.0) hub
5-2 04b3:4010 02 2.00 12MBit/s 100mA 2IFs (IBM RNDIS/CDC ETHER)
usb6 1d6b:0001 09 1.10 12MBit/s 0mA 1IFs (uhci_hcd 0000:00:1d.1) hub
usb7 1d6b:0001 09 1.10 12MBit/s 0mA 1IFs (uhci_hcd 0000:00:1d.2) hub
7-2 0624:0307 00 1.10 1.5MBit/s 100mA 2IFs (Avocent Avocent DSRIQ-USB)
usb8 1d6b:0002 09 2.00 480MBit/s 0mA 1IFs (xhci_hcd 0000:1a:00.0) hub
8-1 2109:3431 09 2.00 480MBit/s 100mA 1IFs () hub
usb9 1d6b:0003 09 3.005000MBit/s 0mA 1IFs (xhci_hcd 0000:1a:00.0) hub
9-1 2109:0810 09 3.005000MBit/s 2mA 1IFs (VIA Labs, Inc. 4-Port USB 3.0 Hub) hub
9-1.2 0bc2:50a1 00 3.005000MBit/s 0mA 1IFs (Seagate FA GoFlex Desk NA0JRATK)
> In xhci-hub.c, there's
>
> if (hcd->self.root_hub->do_remote_wakeup) {
> port_index = max_ports;
> while (port_index--) {
> if (bus_state->resume_done[port_index] != 0) {
> spin_unlock_irqrestore(&xhci->lock, flags);
> xhci_dbg(xhci, "suspend failed because "
> "port %d is resuming\n",
> port_index + 1);
> return -EBUSY;
> }
> }
> }
>
> There's also various places in the USB core on the device, bus, and
> host
> controller suspend patch that can return -EBUSY. Can you enable
> CONFIG_USB_DEBUG and CONFIG_USB_XHCI_HCD_DEBUGGING and give me the
> dmesg
> output after you run `dmesg -n 8`?
I have uploaded dmesg here,
http://people.redhat.com/qcai/dmesg
> That will allow me to see if the bus suspend function in the xHCI
> driver
> is failing. If so, that could indicate something is wrong with the
> resume_done handling with the new split roothub code.
>
> I'm wondering if you're running into an issue I had trouble
> reproducing.
> I thought there might be an issue with resume_done in the xHCI code,
> but
> Andiry Xu and Alan Stern convinced me my reasoning had to be wrong
> about
> the cause of the bug, so I never included the bug fix patch in the
> final
> patchset. The patch is attached. The patch only fixes the resume_done
> issue for a high speed hub, but I could either modify the patch to
> work
> for USB 3.0 hubs, or perhaps your resume_done issue is with the high
> speed portion of your USB 3.0 hub.
>
> If, after you enable xHCI debugging and try to hibernate the system,
> you
> see a message from the xHCI driver about a particular port resuming,
> then try to apply that patch and see if it allows you suspend.
>
> > Restarting tasks ... done.
> >
> > Unfortunately, the latest Linus tree had a regression that prevent
> > hibernate/resume from working even without those patches.
>
> CIA, what host controller are you running under? What brand of hub are
> you using?
USB Controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 03)
and VIA Labs, Inc. 4-Port USB 3.0 Hub
> Andiry, you said the simpler patched allowed your system to suspend
> and
> hibernate. Which host are you using? Which hub?
>
> > It is now failing to resume every time tried after hibernate.
> >
> > PM: Starting manual resume from disk
> > Freezing user space processes ...
> > EXT4-fs (dm-0): INFO: recovery required on readonly filesystem
> > EXT4-fs (dm-0): write access will be enabled during recovery
> > EXT4-fs (dm-0): recovery complete
> > EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts:
> > (null)
> > (elapsed 0.18 seconds) done.
> > Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
> > PM: Loading and decompressing image data (301765 pages) ... done
> > PM: Read 1207060 kbytes in 6.47 seconds (186.56 MB/s)
> > serial 00:08: disabled
> >
> > After applied this patch and the rest of Andiry's larger USB 3.0 hub
> > power management patches on the top of linus tree, there is a
> > conflict with patch [5/5] here.
> >
> > http://marc.info/?l=linux-usb&m=130136847804961&w=2
> >
> > --- drivers/usb/core/hub.c
> > +++ drivers/usb/core/hub.c
> > @@ -2305,7 +2305,13 @@
> > }
> >
> > /* see 7.1.7.6 */
> > - status = set_port_feature(hub->hdev, port1,
> > USB_PORT_FEAT_SUSPEND);
> > + if (hub_is_superspeed(hub->hdev))
> > + status = set_port_feature(hub->hdev,
> > + port1 | (USB_SS_PORT_LS_U3 << 3),
> > + USB_PORT_FEAT_LINK_STATE);
> > + else
> > + status = set_port_feature(hub->hdev, port1,
> > + USB_PORT_FEAT_SUSPEND);
> > if (status) {
> > dev_dbg(hub->intfdev, "can't suspend port %d, status
> > %d\n",
> > port1, status);
> >
> >
> > Do you have suggestion on which git tree/branch is the best to test
> > those?
>
> Those patches should apply against the usb-next branch of Greg's tree:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6.git
>
> However, he doesn't track Linus' tree very closely, so I don't think
> that branch is up-to-date right now. If you let me know when the other
> resume regression is fixed, then I can create apply the patchset on
> top
> of Linus' tree and create a branch for you to test.
Unfortunately, this git tree also had the same resume regression problem.
CAI Qian
--
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
