On Thu, 30 Jun 2011, Arkadiusz Miskiewicz wrote: > One new info. suspend/resume from ram is not needed. Fresh boot, I'm running > on battery, plug power, unplug power and these weird thing start to happen > with mouse unsuspend delay. > > Unfortunately turns out that this behaviour is also seen on my rc3 but laptop > has to run on battery. So not a regression. > > Example (on 3.0.0-rc3-00205-gdd34739) > > [ 1155.447146] hub 3-0:1.0: port 1, status 0103, change 0004, 12 Mb/s > [ 1165.970079] uhci_hcd 0000:00:1a.0: release dev 2 ep82-INT, period 2, phase > 1, 17 us > [ 1165.971071] uhci_hcd 0000:00:1a.0: release dev 2 ep81-INT, period 8, phase > 4, 17 us > > mouse works but I don't move it, so it suspends > > [ 1165.973074] usb 3-1: usb auto-suspend > > now from this moment until... > > [ 1167.988114] hub 3-0:1.0: hub_suspend > [ 1167.988132] usb usb3: bus auto-suspend > [ 1167.988138] usb usb3: suspend_rh > [ 1167.988169] uhci_hcd 0000:00:1a.0: uhci_pci_suspend > [ 1167.988191] uhci_hcd 0000:00:1a.0: PCI INT A disabled > [ 1167.988197] uhci_hcd 0000:00:1a.0: hcd_pci_runtime_suspend: 0 > [ 1167.988351] uhci_hcd 0000:00:1a.0: power state changed by ACPI to D3 > > untill this moment every my mouse move causes nothing but after some delay it > resumes Okay, that's interesting. This means it isn't a problem with the mouse. > [ 1170.545790] uhci_hcd 0000:00:1a.0: power state changed by ACPI to D0 > [ 1170.545801] uhci_hcd 0000:00:1a.0: power state changed by ACPI to D0 > [ 1170.545946] uhci_hcd 0000:00:1a.0: power state changed by ACPI to D0 > [ 1170.545954] uhci_hcd 0000:00:1a.0: power state changed by ACPI to D0 > [ 1170.545971] uhci_hcd 0000:00:1a.0: PCI INT A -> GSI 20 (level, low) -> IRQ > 20 > [ 1170.545986] uhci_hcd 0000:00:1a.0: setting latency timer to 64 > [ 1170.545995] uhci_hcd 0000:00:1a.0: uhci_pci_resume > [ 1170.546041] uhci_hcd 0000:00:1a.0: hcd_pci_runtime_resume: 0 The messages above show the host controller being resumed. That may be your real problem. > [ 1170.546052] usb usb3: usb wakeup-resume > [ 1170.546061] usb usb3: usb auto-resume > [ 1170.546066] usb usb3: wakeup_rh > [ 1170.588078] hub 3-0:1.0: hub_resume > [ 1170.588097] uhci_hcd 0000:00:1a.0: port 1 portsc 0095,01 > [ 1170.588108] hub 3-0:1.0: port 1: status 0103 change 0004 > [ 1170.588169] hub 3-0:1.0: state 7 ports 2 chg 0002 evt 0000 > [ 1170.588188] uhci_hcd 0000:00:1a.0: port 1 portsc 0095,01 > [ 1170.604114] usb 3-1: usb wakeup-resume > [ 1170.604133] usb 3-1: finish resume > [ 1170.607134] uhci_hcd 0000:00:1a.0: reserve dev 2 ep81-INT, period 8, phase > 4, 17 us > [ 1170.607150] uhci_hcd 0000:00:1a.0: reserve dev 2 ep82-INT, period 2, phase > 1, 17 us > [ 1170.607162] hub 3-0:1.0: resume on port 1, status 0 > [ 1170.607169] hub 3-0:1.0: port 1, status 0103, change 0004, 12 Mb/s > > and is working fine until another suspend. ... > it is useable again until new suspend happens. So mouse recovers quicker but > only after "power state changed by ACPI to D3" happens. > > Summary: not a regression, unfortunately feature unusable with this mouse on > this laptop. You can try disabling autosuspend for the host controller. Write "on" to /sys/bus/pci/devices/0000:00:1a.0/power/control. > > And now you know why, more or less -- we still have to figure out the > > reason for the hang. Probably something goes wrong when cdc-ether is > > unbound from the wireless device. > > If cdc-ether is not loaded at all then usb works fine after resume from ram on > rc5. So it looks like rc5 introduced a bug into cdc-ether or somewhere else in the networking stack. Bisection seems like the easiest way to find it. You already know that rc4 works okay. > > It's not even clear that autosuspend is a problem. Doesn't 3.0-rc3 > > also autosuspend the mouse? > > The problem with usb not working if cdc-ether is used happens when also on > external power and afaik autosuspend doesn't kick-in in such case, right? The kernel doesn't care whether you are running on external power or battery. However you might have a userspace power daemon that changes the autosuspend settings, depending on the power source. Alan Stern -- 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