Re: [Powertop] RH Bugzilla [Bug 1482649] Logitech USB Unified Receiver+M570 need 'waking' up by click after kernel update
by Mike Simms
Out of courtesy, just a quick message thank you for your help
and pointing me in the right direction with this issue. I'm closing it
after further consultation with linux-usb contributors. Here is the
reason copied from my RH Bugzilla submission:
I've been collaborating the last 6 days with powertop and linux-usb
contributors upstream over this issue. They have been very helpful.
What we've managed to do is establish exactly what has changed and
where using a number of different trace methods.
There's basically not a bug as such, it is a setting that has been
fixed in 4.12 and above that never worked before.
The value for power stored in
the /sys/bus/usb/devices/2.1.3/power/control file for this device was
being ignored when set to auto (Good) by powertop with kernel 4.11 and
instead a non-existent setting of ON is used. ON means no autosuspend
as power saving is 'Bad' in powertop tunable terms.
with 4.12 it is not being ignored. So what I'm going to do now is
investigate masking that setting with powertop by removing it as a
system service and coding a script (found something similar done for
another distribution so I'm going to at least try it) to autostart
powertop at boot ignoring the pointing device. OR using something else
like tlp which I have no experience with. Either way, this is clearly
not a bug after further investigation upstream so I'm closing it. I
will post the powertop solution if I can get it worked but this should
remain closed from here on in.
5 years
[PATCH 0/4 v1] lib and tuning cleanup series
by Joe Konno
From: Joe Konno <joe.konno(a)intel.com>
This series could be split in two, one for the libpci stuff in "lib",
and another for "tuning" cleanups. The cleanups in "lib" are not
dependent on the cleanups in "tuning" and vice-versa. There should be
no changes to PowerTOP operations or usage as a result of these
patches-- code cleanups only.
I was re-learning libpci a while back and, during my walks along various
PCI buses, spotted a trivial refactor for the libpci functionality in
"lib". This is to make it (slightly) more tempting to embark on future
changes to walk PCI buses with libpci instead of sysfs-- especially in
"tuning" cases.
While looking into additional runtime PM tunables, I stumbled upon
#defines used for tunable states. Implemented those states in an enum
instead. Proved easy as those defines were not used as factors in math
operations, so they were acting as enum entries to begin with. After the
enum was implemented, gcc warned about unhandled states in
tunable::result_string()'s switch statement, so I fixed it.
Joe Konno (4):
lib: refactor pci_access checks
lib: have check_pci_access() scan the entire bus
tuning: use tunable_state enum instead of defines
tuning: complete tunable result switch
src/lib.cpp | 14 ++++++++++----
src/tuning/bluetooth.cpp | 6 +++---
src/tuning/bluetooth.h | 2 +-
src/tuning/ethernet.cpp | 4 ++--
src/tuning/ethernet.h | 2 +-
src/tuning/runtime.cpp | 2 +-
src/tuning/runtime.h | 2 +-
src/tuning/tunable.h | 26 +++++++++++++++++---------
src/tuning/tuningi2c.cpp | 2 +-
src/tuning/tuningi2c.h | 2 +-
src/tuning/tuningsysfs.cpp | 2 +-
src/tuning/tuningsysfs.h | 2 +-
src/tuning/tuningusb.cpp | 2 +-
src/tuning/tuningusb.h | 2 +-
src/tuning/wifi.cpp | 2 +-
src/tuning/wifi.h | 2 +-
16 files changed, 44 insertions(+), 30 deletions(-)
--
2.13.5
5 years
Re: [Powertop] RH Bugzilla [Bug 1482649] Logitech USB Unified Receiver+M570 need 'waking' up by click after kernel update
by Mike Simms
Auke, no that autotune has always been set to good. It's been discussed
already in the RH bug thread I linked to in my 1st post here. I didn't
want to duplicate everything already gone through because it's quite
lengthy. I'm asking here in case someone has any better suggestions
because it should still work the same in theory. No settings have been
changed in powertop. It autodetects and sets good for both kernel
versions with regards the Logitech unified receiver.
To summarise for people who don't want to read the RH bugzilla thread:
Autotune service for both kernels tunes the same devices to Good.
Nothing is set to Bad.
With kernel 4.11.11-300 there is no wake up lag when the receiver and
connected device has entered low power state
With kernel 4.12.x and 4.13 release candidate there is lag you can
measure in seconds and it's extremely frustrating. It causes missed
clicks, keyboard characters, duplicate form submissions on websites.
Setting the autosuspend for the receiver to Bad is an obvious
workaround but it isn't the solution we're looking for. There is a
regression here that needs addressing. Hopefully the HID driver contact
I found thanks to Joe will be able to advise further on this.
5 years
RH Bugzilla [Bug 1482649] Logitech USB Unified Receiver+M570 need 'waking' up by click after kernel update
by Mike Simms
Description of problem: For some reason the trackball is no longer able
to respond to user input immediately. it only responds when I click a
button to wake it up or roll the ball about a bit first. With earlier
kernels this was not necessary. Booting from the previous kernel
4.11.11-300.fc26 and it still works fine.
Version-Release number of selected component (if
applicable):4.12.5-300.fc26.x86_64
Also affected Fedora 27 4.13 rc kernel
How reproducible: consistently
Steps to Reproduce:
1. start notebook computer with the unified receiver attached
2. login and use the computer as normal
Actual results: trackball works initially but if left for a few seconds
to type or read for example, it needs waking up with movement or a
click of a button.
Expected results: should respond normally without this lag or waking up
nonsense
Additional info:the unified receiver is plugged into the same USB 2
port it has always been.
powertop is using the autotune profile and the usb autosuspend entry is
Good.
Something in the kernel code has caused a power management regression.
I'm not sure what and the bug I opened so far has drawn a blank. The
kernel maintainer is not able to help as they don't know about power
management or powertop. please give some guidance as to where to look
and how to resolve this if possible. Full information so far here,
including dmesg, lspci, lsusb output, dumps for comparison of power
profiles etc.
I'm an end user, not a developer or maintainer so please keep it in
relatively simple terms I can relay back to the maintainers please and
understand at the same time.
https://bugzilla.redhat.com/show_bug.cgi?id=1482649
Thanks
Mike Simms
5 years