Hi Sarah,
Sorry for the delay. I am in conference (LSF & Collab Summit) this week, but will come back to you as soon as I have a chance.
CAI Qian
Sent from my iPhone
On 2011-4-4, at 10:39, Sarah Sharp <sarah.a.sharp@xxxxxxxxxxxxxxx> 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. There's a couple different
> places the code could return -EBUSY (which is what -16 is).
>
> 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`?
>
> 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?
>
> 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.
>
> Sarah Sharp
> <0001-xhci-Clear-internal-resume-state-on-reset.patch>
--
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
