Hello,
I found this regression w.r.t. 2.6.29.
When enabling usb automatic power management for all usb peripherals, with:
> for i in /sys/bus/usb/devices/*/power/level; do echo auto > $i; done
after 2 seconds of inactivity (my autosuspend threshold), the mouse
gets stuck under X.
Pushing a mouse button will revive it (and the event is passed to X).
Disabling automatic power management, with:
> for i in /sys/bus/usb/devices/*/power/level; do echo on > $i; done
removes the problem.
My kernel config is attached.
Thanks,
Corrado
--
__________________________________________________________________________
dott. Corrado Zoccolo mailto:[email protected]
PhD - Department of Computer Science - University of Pisa, Italy
--------------------------------------------------------------------------
[ added Oliver to CC ]
On Thu, 9 Apr 2009, Corrado Zoccolo wrote:
> I found this regression w.r.t. 2.6.29.
> When enabling usb automatic power management for all usb peripherals, with:
> > for i in /sys/bus/usb/devices/*/power/level; do echo auto > $i; done
Well, it's difficult to consider this to be a regression. With default
settings (USB autosuspend turned off), the system behaves the same way as
it did before (ie. no mouse autosuspend).
> after 2 seconds of inactivity (my autosuspend threshold), the mouse
> gets stuck under X.
That's because it got suspended, as you have configured it to do so.
> Pushing a mouse button will revive it (and the event is passed to X).
Which is expected behavior.
Your mouse (as many other mice out there) doesn't emit wakeup event on
movement, it only does on button click. There is nothing kernel can do
about it. This is one of the reasons why autosuspend is disabled by
default (other reason being many devices broken beyond hope when it comes
to waking up).
--
Jiri Kosina
SUSE Labs
On Thu, Apr 16, 2009 at 12:15 PM, Jiri Kosina <[email protected]> wrote:
>
> [ added Oliver to CC ]
>
> On Thu, 9 Apr 2009, Corrado Zoccolo wrote:
>
>> I found this regression w.r.t. 2.6.29.
>> When enabling usb automatic power management for all usb peripherals, with:
>> > for i in /sys/bus/usb/devices/*/power/level; do echo auto > $i; done
>
> Well, it's difficult to consider this to be a regression. With default
> settings (USB autosuspend turned off), the system behaves the same way as
> it did before (ie. no mouse autosuspend).
>
>> after 2 seconds of inactivity (my autosuspend threshold), the mouse
>> gets stuck under X.
>
> That's because it got suspended, as you have configured it to do so.
>
>> Pushing a mouse button will revive it (and the event is passed to X).
>
> Which is expected behavior.
>
> Your mouse (as many other mice out there) doesn't emit wakeup event on
> movement, it only does on button click. There is nothing kernel can do
> about it. This is one of the reasons why autosuspend is disabled by
> default (other reason being many devices broken beyond hope when it comes
> to waking up).
Well, to me it seems a regression since it worked correctly in 2.6.29, i.e.
* it was suspended after inactivity (at least according to powertop),
* it resumed operation when it was moved (no need to push a button to
have it working again).
unless 2.6.29 just lied about suspending the mouse.
BTW, I find autosuspend useful to increase the battery life, so at
least with good devices, we should make sure it works.
Corrado
>
> --
> Jiri Kosina
> SUSE Labs
>
>
--
__________________________________________________________________________
dott. Corrado Zoccolo mailto:[email protected]
PhD - Department of Computer Science - University of Pisa, Italy
--------------------------------------------------------------------------
Am Donnerstag 16 April 2009 14:45:12 schrieb Corrado Zoccolo:
> > Your mouse (as many other mice out there) doesn't emit wakeup event on
> > movement, it only does on button click. There is nothing kernel can do
> > about it. This is one of the reasons why autosuspend is disabled by
> > default (other reason being many devices broken beyond hope when it comes
> > to waking up).
>
> Well, to me it seems a regression since it worked correctly in 2.6.29, i.e.
> * it was suspended after inactivity (at least according to powertop),
This is not the reliable way to check this. Please compile 2.6.29 with
CONFIG_USB_DEBUG and post dmesg for a period of inactivity.
Regards
Oliver
On Thu, Apr 16, 2009 at 3:43 PM, Oliver Neukum <[email protected]> wrote:
> Am Donnerstag 16 April 2009 14:45:12 schrieb Corrado Zoccolo:
> This is not the reliable way to check this. Please compile 2.6.29 with
> CONFIG_USB_DEBUG and post dmesg for a period of inactivity.
Oliver, you were right: 2.6.29 did not attempt at all to suspend the
mouse and its attached hum (2-x):
[ 13.587023] uhci_hcd 0000:00:1d.0: reserve dev 2 ep81-INT, period
8, phase 4, 118 us
[ 13.590044] uhci_hcd 0000:00:1d.0: release dev 2 ep81-INT, period
8, phase 4, 118 us
[ 13.647022] uhci_hcd 0000:00:1d.0: reserve dev 2 ep81-INT, period
8, phase 4, 118 us
[ 23.350008] eth0: no IPv6 routers present
[ 47.177896] usb usb1: usb resume
[ 47.177903] ehci_hcd 0000:00:1d.7: resume root hub
[ 47.219020] hub 1-0:1.0: hub_resume
[ 47.219368] usb usb3: usb resume
[ 47.219375] usb usb3: wakeup_rh
[ 47.219390] hub 1-0:1.0: state 7 ports 8 chg 0000 evt 0000
[ 47.251011] hub 3-0:1.0: hub_resume
[ 47.251162] usb usb4: usb resume
[ 47.251165] usb usb4: wakeup_rh
[ 47.251174] hub 3-0:1.0: state 7 ports 2 chg 0000 evt 0000
[ 47.283014] hub 4-0:1.0: hub_resume
[ 47.283155] usb usb5: usb resume
[ 47.283159] usb usb5: wakeup_rh
[ 47.283250] hub 4-0:1.0: state 7 ports 2 chg 0000 evt 0000
[ 47.315013] hub 5-0:1.0: hub_resume
[ 47.315273] hub 5-0:1.0: state 7 ports 2 chg 0000 evt 0000
[ 48.454020] usb usb3: suspend_rh (auto-stop)
[ 48.454039] usb usb4: suspend_rh (auto-stop)
[ 48.454055] usb usb5: suspend_rh (auto-stop)
[ 49.704028] hub 1-0:1.0: hub_suspend
[ 49.704039] usb usb1: bus auto-suspend
[ 49.704043] ehci_hcd 0000:00:1d.7: suspend root hub
[ 49.704069] hub 3-0:1.0: hub_suspend
[ 49.704073] usb usb3: bus auto-suspend
[ 49.704076] usb usb3: suspend_rh
[ 49.704090] hub 4-0:1.0: hub_suspend
[ 49.704093] usb usb4: bus auto-suspend
[ 49.704095] usb usb4: suspend_rh
[ 49.704108] hub 5-0:1.0: hub_suspend
[ 49.704111] usb usb5: bus auto-suspend
[ 49.704114] usb usb5: suspend_rh
2.6.30-rc2, instead:
[ 189.705618] uhci_hcd 0000:00:1d.0: release dev 2 ep81-INT, period
8, phase 4, 118 us
[ 189.708622] usb 2-1: usb auto-suspend
[ 192.704031] hub 2-0:1.0: hub_suspend
[ 192.704042] usb usb2: bus auto-suspend
[ 192.704046] usb usb2: suspend_rh
* mouse click *
[ 197.057083] usb usb2: usb resume
[ 197.057088] usb usb2: wakeup_rh
[ 197.089011] hub 2-0:1.0: hub_resume
[ 197.089022] uhci_hcd 0000:00:1d.0: port 1 portsc 01a5,01
[ 197.089028] hub 2-0:1.0: port 1: status 0303 change 0004
[ 197.089043] hub 2-0:1.0: state 7 ports 2 chg 0002 evt 0000
[ 197.089050] uhci_hcd 0000:00:1d.0: port 1 portsc 01a5,01
[ 197.089056] usb 2-1: usb wakeup-resume
[ 197.089063] usb 2-1: finish resume
[ 197.096035] uhci_hcd 0000:00:1d.0: reserve dev 2 ep81-INT, period
8, phase 4, 118 us
[ 197.096042] hub 2-0:1.0: resume on port 1, status 0
[ 197.096046] hub 2-0:1.0: port 1, status 0303, change 0004, 1.5 Mb/s
Thanks,
Corrado
>
> Regards
> Oliver
>
>
--
__________________________________________________________________________
dott. Corrado Zoccolo mailto:[email protected]
PhD - Department of Computer Science - University of Pisa, Italy
--------------------------------------------------------------------------
Am Sonntag 19 April 2009 15:29:28 schrieb Corrado Zoccolo:
> On Thu, Apr 16, 2009 at 3:43 PM, Oliver Neukum <[email protected]> wrote:
> > Am Donnerstag 16 April 2009 14:45:12 schrieb Corrado Zoccolo:
> > This is not the reliable way to check this. Please compile 2.6.29 with
> > CONFIG_USB_DEBUG and post dmesg for a period of inactivity.
>
> Oliver, you were right: 2.6.29 did not attempt at all to suspend the
> mouse and its attached hum (2-x):
OK, so this is confirmed to not be a regression.
I am sorry that your mouse doesn't support better power management.
The behavior you report is typical. I suggest that you couple autosuspend
of your mouse with the screensaver, if your desktop supports that. If not,
you might want to talk to the screensaver's developers.
Regards
Oliver