RH Bugzilla [Bug 1482649] Logitech USB Unified Receiver+M570 need 'waking' up by click after kernel update
11:32 p.m.
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
3:30 a.m.
New subject: [Powertop] RH Bugzilla [Bug 1482649] Logitech USB Unified Receiver+M570 need 'waking' up by click after kernel update
This is indicative of enabling usb suspend for the trackball device, and
common to mice, touchpads and trackballs.
The only solution is to disable usb suspend for these devices, and
remember not to enable it for the device in powertop.
Auke
On 09/07/2017 06:32 AM, Mike Simms wrote:
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
_______________________________________________
PowerTop mailing list
PowerTop(a)lists.01.org
https://lists.01.org/mailman/listinfo/powertop
4:09 a.m.
New subject: [Powertop] RH Bugzilla [Bug 1482649] Logitech USB Unified Receiver+M570 need 'waking' up by click after kernel update
Then explain why it was never an issue before kernel 4.12 please
On Thu, 7 Sep 2017 10:30:34 -0700
Auke Kok <auke-jan.h.kok(a)intel.com> wrote:
This is indicative of enabling usb suspend for the trackball device,
and common to mice, touchpads and trackballs.
The only solution is to disable usb suspend for these devices, and
remember not to enable it for the device in powertop.
Auke
On 09/07/2017 06:32 AM, Mike Simms wrote:
> 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
> _______________________________________________
> PowerTop mailing list
> PowerTop(a)lists.01.org
> https://lists.01.org/mailman/listinfo/powertop
>
6:03 a.m.
New subject: [Powertop] RH Bugzilla [Bug 1482649] Logitech USB Unified Receiver+M570 need 'waking' up by click after kernel update
On Thu, 7 Sep 2017 18:09:59 +0000
Mike Simms <micsim2007(a)outlook.com> wrote:
Then explain why it was never an issue before kernel 4.12 please
That's a question for the maintainer of the kernel USB HID driver driver
community. The Linux kernel is a very large piece of software with many, many
device drivers supporting still more devices. These drivers can and do change,
for myriad reasons, from kernel release to kernel release.
Particular device power management behaviors are implemented by kernel device
drivers. PowerTOP gives you the ability to toggle (or tune) low-level,
power-sensitive settings for each device. If by toggling a setting for a
particular device that device behaves in an undesirable way, you may have a
kernel device driver bug.
USB HID-- human interface device-- drivers, which include mice and the like,
have an upstream kernel maintainer. In this specific case, the linux-usb
mailing list would be a good starting point, or the kernel.org bugzilla.
In the general case, consulting the kernel MAINTAINERS file for the device in
question should provide a mailing list starting point when issues like these
arise.
Here I can only offer general advice, nothing specific. Hope it helps!
6:11 a.m.
New subject: [Powertop] RH Bugzilla [Bug 1482649] Logitech USB Unified Receiver+M570 need 'waking' up by click after kernel update
On 09/07/2017 11:09 AM, Mike Simms wrote:
Then explain why it was never an issue before kernel 4.12 please
I can only take a guess, based on the info you provided, most
importantly I lack the hardware that you have.
Joe's comments are obviously important - there may be several points of
failure. The one that I spotted, is this one:
>> powertop is using the autotune profile and the usb
autosuspend
>> entry is Good.
Turn it to "Bad" and see if it resolves the problem.
I am wondering if powertop autotuning was recently turned on in your
distro, and the trackpoint isn't properly blacklisted as a device that
shouldn't be put into usb autosuspend (if that is actually a thing in
code, it's been a while since I last worked on it).
Auke
1837
days inactive
1837
days old
4 comments
3 participants
participants (3)
-
Auke Kok -
Joe Konno -
Mike Simms