Created attachment 1314863 [details] dmesg | less 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 How reproducible: consistently Steps to Reproduce: 1. start 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.
Created attachment 1314864 [details] verbose lspci output
Created attachment 1314865 [details] verbose lsusb output
I believe I'm seeing the same issue with my M325 mouse. I don't have any issues when I switch back to the previous 4.11 kernel (kernel-4.11.11-300.fc26.x86_64)
Same here (4.12.5-300.fc26.x86_64) with the same mouse. I also have a Logitech K800 keyboard paired with the same Unifying receiver and it's affected as well, making normal typing impossible. If I stop typing for a few seconds, it stops accepting input for the next few seconds, leading to missed characters in input. I noticed some new entries in dmesg compared to 4.11.11: psmouse serio1: synaptics: Your touchpad (PNP: FOX0015 PNP0f13) says it can support a different bus. If i2c-hid and hid-rmi are not used, you might want to try setting psmouse.synaptics_intertouch to 1 and report this to linux-input.org. [...] logitech-hidpp-device 0003:046D:2010.0005: HID++ 1.0 device connected. [...] logitech-hidpp-device 0003:046D:400A.0006: HID++ 2.0 device connected. Going back to 4.11.11-300.fc26.x86_64 makes the issue go away.
Another workaround is to disable USB autosuspend for the Unifying Receiver. In my configuration, it's: echo 'on' > /sys/bus/usb/devices/2-2.1.4/power/control This can be done from powertop, too.
thanks for the workarounds but I'll stick with 4.11.11-300 for the time being. I've emailed upstream with a brief description of the issue linking to this thread and the attachments it contains.
no joy with the email. it was rejected by the email server
I'll try to open a bug report at bugzilla.kernel.org tonight unless someone beats me to it.
still present with kernel release 4.12.8-300.fc26.x86_64
Still haven't opened a report, because existing bugzilla reports redirect to linux-usb mailing list. I've had pcie_aspm=force in my kernel command line since forever. After removing it, I no longer see the issue described here, because powertop --auto-tune doesn't enable autosuspend for some USB devices by default anymore, including the Logitech Unifying Receiver. As expected, after enabling autosuspend for the receiver, the issue returns.
I've never used that kernel command but do use powertop with the autotune settings. with 4.11 and exactly the same powertop settings this never happened for me. it's only started happening with kernel 4.12 and there hasn't been a powertop update recently which would alter behaviour either.
Can you compare your powertop "Tunables" tab under kernel 4.11 and 4.12? In my case, I have all "Good" under 4.11, but some (including the Unifying Receiver) as "Bad" under 4.12.
all displayed options in the tunables tab of powertop v2.9 are showing as "Good" for both kernels. that's why I'm not sure what has changed and why regarding this particular receiver because I haven't altered anything personally: >> Good NMI watchdog should be turned off Good Bluetooth device interface status Good Enable Audio codec power management Good Enable SATA link power management for host2 Good Enable SATA link power management for host4 Good Enable SATA link power management for host1 Good Enable SATA link power management for host3 Good Enable SATA link power management for host5 Good Enable SATA link power management for host0 Good VM writeback timeout Good Runtime PM for I2C Adapter i2c-5 (i915 gmbus dpd) Good Runtime PM for I2C Adapter i2c-1 (i915 gmbus vga) Good Runtime PM for I2C Adapter i2c-4 (i915 gmbus dpb) Good Runtime PM for I2C Adapter i2c-2 (i915 gmbus panel) Good Runtime PM for I2C Adapter i2c-0 (i915 gmbus ssc) Good Runtime PM for I2C Adapter i2c-7 (SMBus I801 adapter at efa0) Good Autosuspend for USB device Ultra Fit [SanDisk] Good Autosuspend for unknown USB device 2-1.4 (8087:07da) Good Autosuspend for unknown USB device 2-1 (8087:0024) Good Autosuspend for USB device xHCI Host Controller [usb3] Good Autosuspend for USB device EHCI Host Controller [usb2] Good Runtime PM for I2C Adapter i2c-3 (i915 gmbus dpc) Good Autosuspend for unknown USB device 1-1 (8087:0024) Good Autosuspend for USB device xHCI Host Controller [usb4] Good Autosuspend for USB device USB Receiver [Logitech] Good Autosuspend for USB device EHCI Host Controller [usb1] Good Autosuspend for USB device FJ Camera [Chicony Electronics Co., Ltd.] Good Runtime PM for PCI Device Intel Corporation 7 Series/C216 Chipset Family MEI Controller #1 Good Runtime PM for PCI Device Intel Corporation 7 Series/C216 Chipset Family High Definition Audio Controller Good Runtime PM for PCI Device Intel Corporation Centrino Wireless-N 2230 Good Runtime PM for PCI Device Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller Good Runtime PM for PCI Device Intel Corporation HM75 Express Chipset LPC Controller Good Runtime PM for PCI Device Intel Corporation 7 Series/C216 Chipset Family PCI Express Root Port 1 Good Runtime PM for PCI Device NEC Corporation uPD720200 USB 3.0 Host Controller Good Runtime PM for PCI Device Intel Corporation 7 Series Chipset Family 6-port SATA Controller [AHCI mode] Good Runtime PM for PCI Device Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 3 Good Runtime PM for PCI Device Intel Corporation 3rd Gen Core processor Graphics Controller Good Runtime PM for PCI Device Intel Corporation 7 Series/C216 Chipset Family USB Enhanced Host Controller #1 Good Runtime PM for PCI Device Intel Corporation 7 Series/C216 Chipset Family USB Enhanced Host Controller #2 Good Runtime PM for PCI Device Intel Corporation 3rd Gen Core processor DRAM Controller Good Runtime PM for PCI Device Intel Corporation 7 Series/C216 Chipset Family SMBus Controller Good Runtime PM for PCI Device Intel Corporation 7 Series/C216 Chipset Family PCI Express Root Port 4 Good Wake-on-lan status for device enp2s0 Good Wake-on-lan status for device wlp1s0
the unknown usb device is the intel bluetooth adaptor 8087:07da, and an Integrated Intel Rate matching hub 8087:0024
THIS IS A CRITICAL USER FUNCTIONALITY ISSUE 4.12.9-300.fc26.x86_64 uploaded to koji by jforbes is affected as well what is a user who cannot unplug and replug the adaptor due to a disability because it is out of reach for them at the back of a tower on or under a desk to do? Put up and shut up 'for the greater good'? Not that they'd be able to use the damn thing long enough to report a problem without it cutting out on them half way through anyhow. ANY keyboard or mouse which uses a Logitech Unified Receiver stops working properly, period. I've deliberately kept removing the oldest 4.12 kernel version to retain kernel 4.11.11 as it is the last that works properly. I can reach the receiver but don't see why I should wear it or the USB connection out because of a buggy kernel. Please fix asap or report upstream if you cannot do so I'm glad I don't have nvidia proprietary blobs because then I'd be even further up the creek without a paddle as you or someone upstream has removed a symbol from the kernel which breaks the 304.xx drivers seems no one learned from the entire mtrr_add and mtrr_del fiasco back in November of 2015 did they?
Disabling USB autosuspend for the Logitech Unifying Receiver works for me too, otherwise I have to stay on kernel-4.11.11-300.fc26.x86_64.
Mike, Tom, could you compare the output of egrep -v '^#' /sys/bus/usb/devices/*/power/autosuspend_delay_ms between 4.11 and 4.12? I'll do the same when I get the chance at home. I was also told (in #fedora-devel on IRC) that enabling autosuspend for keyboards and mice/touchpads is a bad idea in general.
Created attachment 1319405 [details] comparison of kernel autosuspend value output Thanks for carrying on looking into this Dominik. However, please don't waste your time when you get home running the command as it doesn't turn anything up, the output is identical across both kernel branches. I really wish these Project contributors would stop talking out their backsides, using autosuspend is valid with these devices, I can't vouch for any other make but Logitech have one of the most developed USB receivers available. The Logitech Receiver and devices are designed to autosuspend and wake up immediately as they have always done so until 4.12 was installed. with the same values there is no such lag with kernel 4.11. I don't see how they cannot understand it is an issue they have introduced with the new kernel and nothing the user has configured in the wrong manner. I'm fast losing faith and patience in the current direction Fedora Project is taking. They even managed to screw up the FESCo elections - something which could be construed a deliberate ploy to minimise the chances of getting voted off? Fedora Maintainers have dropped the ball regarding quality and attention to user feedback. not just because of this issue but it doesn't help at all. Fedora in 2017 is far less stable than I've ever experienced with it in the last 7 releases I've used. Not just because of hardware support, but also the software side. There are far more bugs compromising workflow and taking up my time chasing them down and reporting when necessary (just to be ignored). Fedora is fast becoming an OS I'm only willing to give passing interest to and disk space to in VM.
4.11.11 kernel was removed by the update but here's the data for the current kernel I'm using. # uname -r 4.12.9-300.fc26.x86_64 [root@crankarm ~]# egrep -v '^#' /sys/bus/usb/devices/*/power/autosuspend_delay_ms /sys/bus/usb/devices/1-1.4/power/autosuspend_delay_ms:2000 /sys/bus/usb/devices/1-1/power/autosuspend_delay_ms:0 /sys/bus/usb/devices/2-1.1/power/autosuspend_delay_ms:2000 /sys/bus/usb/devices/2-1.2/power/autosuspend_delay_ms:2000 /sys/bus/usb/devices/2-1.6/power/autosuspend_delay_ms:2000 /sys/bus/usb/devices/2-1/power/autosuspend_delay_ms:0 /sys/bus/usb/devices/usb1/power/autosuspend_delay_ms:0 /sys/bus/usb/devices/usb2/power/autosuspend_delay_ms:0
(In reply to Mike Simms from comment #18) [...] > Fedora is fast becoming an OS I'm only willing to give passing interest to > and disk space to in VM. Mike, please refrain from ranting in bugzilla tickets, it doesn't help at all.
That's not a rant, it's a comment. Tough luck if you don't find it helpful, I'm allowed to express my opinion as I see fit
I can confirm with an m570, but it's not exclusively that either. I have a k360 keyboard that also had intermittent unresponsive issues (connected _WITH_ the m570 - haven't tried it by itself) At one point it even killed the controller temporarily: Sep 02 20:54:12 icarus kernel: xhci_hcd 0000:00:14.0: xHCI host controller not responding, assume dead Sep 02 20:54:12 icarus kernel: xhci_hcd 0000:00:14.0: HC died; cleaning up Sep 02 20:54:12 icarus kernel: usb 2-2: USB disconnect, device number 2 Sep 02 20:54:13 icarus kernel: usb 2-6: USB disconnect, device number 4 Can also confirm that reverting to 4.11.11-300.f26 works fine. Initially I thought this was all caused by interference or bad signal, then after that message I figured the internal host controller was going bad and my hardware was hosed. Really glad I found this bug.
To add another data point: Unifying Receiver DeviceID: /sys/devices/pci0000:00/0000:00:14.0/usb2/2-2 Guid: 77d843f7-682c-57e8-8e29-584f5b4f52a1 Guid: 9d131a0c-a606-580f-8eda-80587250b8d6 Plugin: unifying Flags: allow-online|supported DeviceVendor: Logitech DeviceVendorId: USB:0x046D Version: RQR12.07_B0029 VersionBootloader: BOT01.02_B0014 Created: 2017-09-03 Is the adapter info from `fwupdmgr get-devices` - i HAVE updated the firmware to RQR12.07_B0029 with this tool. I wonder if it's an interaction with 4.12 and that firmware version, but sadly I've updated all my adapters.
Hi Mike, it isn't firmware specific by the looks of it because I believe I have an older build still on my device. This is what mine has, I've never knowingly updated the firmware but it may well have been done by Windows Update since that installed an updated driver relating to the receiver. Unifying Receiver DeviceID: /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.3 Guid: 77d843f7-682c-57e8-8e29-584f5b4f52a1 Guid: 9d131a0c-a606-580f-8eda-80587250b8d6 Plugin: unifying Flags: allow-online DeviceVendor: Logitech DeviceVendorId: USB:0x046D Version: RQR12.03_B0025 VersionBootloader: BOT01.02_B0015 Created: 2017-09-03 the command I used was fwupdmgr get-devices -v I got this error when I tried the command you posted Mike: bash: M570: command not found
@Mike Simms: Not sure why you typed "M570" as a command, since that's the model number of the trackball mouse. (nor did I ever even type it in caps?) ----- I'd wager we're all powertop users? I noticed that when I disabled powertop.service and rebooted the Logitech Unifying receiver and my ELAN touchscreen were the _only_ USB devices already configured for not autosuspending (I do have tuned running with the desktop profile)..... Bad Autosuspend for USB device Touchscreen [ELAN] Bad Autosuspend for USB device USB Receiver [Logitech] Everything else was. Seems strange that it was set that way by default.... Can someone explain why/how? I checked all the udev rules in /usr/lib/udev/rules.d and nothing explicitly targets the unifying receiver to set autosuspend off, so I'm not really sure how that's happening. So what I'm trying to say is that it seems deliberate (as in not coincidental) that this is in a set of USB devices with autosuspended by default, and perhaps someone was aware of this issue but we're overriding the fix by enabling powertop, which overrides this?
I meant that "bash: M570: command not found" is what I got as output after entering `fwupdmgr get-devices` - i
granted, it is possible to disable powertop so it isn't running and the lag disappears. this doesn't get away from the fact that with kernel 4.11.11 and previous kernels, powertop autosuspend being set to good for these logitech devices was not an issue. That is why I'm going to try installing F27 with kernel 4.13 branch to another external drive and see how the receiver behaves with powertop auto settings applied. i've never used tuned daemon, only powertop so there were no conflicting power settings.
the same problem happens with Fedora 27 when using powertop 2.9.3 and kernel 4.13.0-0.rc7.git0.1.fc27.x86_64. tested with nightly compose dated 2nd September 2017 installed to USB 3 HDD.
Autosuspend settings don't change between 4.11.11 and 4.12.9 in my case, either.
I am going to have to guess this is directly related to powertop settings. Every kernel I build is tested on a box using a K800 keyboard and m570 through the unifying receiver, and I have not been able to reproduce in general usage. I don't use powertop though, as my concern is the kernel as we build/ship/support it. If anyone can is reproducing this without having ever run powertop, I am willing to keep it as kernel, but otherwise, it should be moved to powertop.
I'll re-assign it to powertop on the proviso you are willing to acknowledge the fact this only started happening with your 4.12 and 4.13 kernel releases and work closely supporting the powertop maintainers to resolve it and not just dismiss as their issue, not your problem.
You guys have it wrong. This isn't a powertop bug, as powertop is doing its job, tuning everything that it can to good. That's its job. This is a correlation to causation error you're making... meaning that while powertop being enabled exposes the problem, it _didn't occur_ prior to the _kernel upgrade_, ergo the problem is in the kernel, not powertop. Something is wrong with USB suspend starting in 4.12 and it's _ODD_ that for some reason Logitech unifying receivers are set to _not suspend_ by default. Why is that? Where is that? This is not a powertop bug, it's a bug with auto-suspending.
I have been making that exact point (it is kernel change related) from the outset but Justin obviously wants to hand off ownership to powertop because his 'test box' is not a notebook where using powertop is necessary so isn't that concerned. I'm beyond caring who deals with it at this point as long as they work together and fix the issue.
(In reply to Mike Simms from comment #31) > I'll re-assign it to powertop on the proviso you are willing to acknowledge > the fact this only started happening with your 4.12 and 4.13 kernel releases > and work closely supporting the powertop maintainers to resolve it and not > just dismiss as their issue, not your problem. I understand the value of powertop, and I am quite sure that the kernel is behaving differently in how it responds to certain settings. My point is, powertop likely needs to change in how it tunes based on this. Powertop is a kernel tuner at the core, and needs to know how to properly tune newer kernels. I am glad to help in any way I can, but I certainly do not have the powertop knowledge to do so. I last ran powertop a couple of years ago, and even then it was just to take a look at something out of curiosity. It is the same way that selinux, nvidia drivers, and other packages who exist solely to interface with the kernel must follow upstream kernel releases and make adjustments to support newer releases.
I've sent this request to Intel Opensource for further guidance because debating ownership and who must do what about changes to the kernel they may or may not be aware of isn't going to get us anywhere nearer a fix. https://lists.01.org/pipermail/powertop/2017-September/001991.html
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.
Workaround courtesy of https://www.kirsle.net/wiki/PowerTOP-and-USB-Autosuspend Make a shell script that starts on user log-in, that undoes PowerTOP's change to the USB device. Run sudo powertop and go to the Tunables tab. Find the entry like "Autosuspend for Logitech Unified Receiver", and toggle it into a "Bad" state (meaning it doesn't auto-suspend now). When toggling it, PowerTOP shows a message of what it did to toggle it, which looks like: echo 'on' > '/sys/bus/usb/devices/2-1.3/power/control' Create a shell script that does that job. I made mine at /bin/powertop-fix: #!/bin/sh # Disable USB auto-suspend for my mouse on startup sleep 5; MOUSE="/sys/bus/usb/devices/2-1.3/power/control"; if [ -f "$MOUSE" ]; then echo 'on' > $MOUSE; fi Edit your sudoers file (/etc/sudoers) to allow running that script with no password: yourusernamehere ALL=(ALL) NOPASSWD: /bin/powertop-fix Make sudo /bin/powertop-fix start automatically using your desktop's session management settings (e.g. Xfce Sessions and Startup -> Application Autostart).
How did we lose sight of the real issue here? Autosuspend is broken with this device! This has _nothing_ to do with powertop past the fact that it enables autosuspend for this device and that setting is _no longer ignored by the kernel_ (why?) Think of it this way... if the user runs: echo "auto" > '<path_to_unifying_device>/power/control' every time he/she starts their computer, is the user the bug? That's effectively what you're blaming powertop for doing. Most importantly: Who's responsibility is it to fix the fact that autosuspend is broken with logitech unifying devices? Reopened.
actually, as explained in my post #37 above it turned out from evidence gathered in the various traces that autosuspend was not working with kernel 4.11 or earlier ones but is working now. the delay of 2000ms (2 seconds) is adhered to by the system and that causes the lag. disabling the autosuspend restores normal peripheral response times. should you want to continue chasing this one please post to this linux-usb mailing list via plain text mode email. if your email address is rejected use a gmail one. you don't have to subscribe, just do reply to all if anyone responds: linux-usb.org cc addresses: linux-input.org jikos benjamin.tissoires stern.edu email subject:Re: RH Bugzilla - Bug 1482649 - Logitech USB Unified Receiver+M570 need 'waking' up by click after kernel update archive to date: https://marc.info/?l=linux-input&m=150528972824717&w=2