On Wed, Apr 06, 2011 at 07:32:29PM -0400, CAI Qian wrote: > ----- 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) ... > USB Controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 03) > and VIA Labs, Inc. 4-Port USB 3.0 Hub Oh, so 8-1 is the USB 2.0 portion of the VIA hub. Interesting. Ah, I think I might know what the problem is. Can you post the output of `lsusb -v` (not lsusb.py, please)? I know that some early VIA hubs didn't have remote wakeup enabled, and Linux will refuse to suspend them, since they can't wakeup the system when a device is plugged in. That could be why the system refuses to hibernate. Maybe we need to disable the power for the USB 2.0 port that the VIA hub is attached to? I Andiry and I probably have VIA hubs that do report remote wakeup capabilities, which would explain why Andiry's patchset worked for him. Does your system hibernate with the VIA hub plugged into an EHCI port? Or when the hub is plugged in behind a high speed hub that's attached to xHCI? > > 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 The xHCI debugging over-wrote most of your dmesg buffer, so that file wasn't very helpful. I really need to get rid of most of that debugging... Can you run `tail -f /var/log/kern.log | tee dmesg`, try to hibernate the system, and then send me the dmesg file? > > > 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. You mean Greg's tree has a resume-from-hibernate issue or Linus' tree still has that issue? If Linus' tree still has an issue, you probably want to send email to lkml about it. 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
