Control: found -1 5.10.24-1 Hi Antoine,
On Sun, May 02, 2021 at 08:22:07PM -0400, Antoine Beaupré wrote: > On 2021-05-01 07:59:01, Salvatore Bonaccorso wrote: > > Hi Antoine > > > > On Fri, Apr 30, 2021 at 07:34:04PM -0400, Antoine Beaupré wrote: > >> On 2021-04-30 21:04:29, Salvatore Bonaccorso wrote: > >> > Control: tags -1 + moreinfo > >> > > >> > Hi Tollef, Antoine, > >> > > >> > On Wed, Sep 11, 2019 at 08:20:22PM -0400, Antoine Beaupré wrote: > >> >> Control: forcemerge 922666 928189 > >> >> Control: severity 922666 important > >> >> Control: tags 922666 +patch +confirmed > >> >> > >> >> I also see a regression with touchpads and trackpoint on a Thinkpad E431 > >> >> after upgrading from Debian stretch to buster. My research indicates > >> >> this is a kernel regression, as yet to be fixed. > >> >> > >> >> This is the result of my research, as available online at: > >> >> > >> >> https://anarc.at/services/upgrades/buster/#touchpad-trackpoint-freeze-after-sleep > >> >> > >> >> On a Thinkpad E431, the entire mouse interface (touch, trackpoint) > >> >> freezes after sleep. Keyboard still works but not mouse until a > >> >> reboot. > >> >> > >> >> There's [bug 922666][] in Debian buster, without a fix. It also says > >> >> it eventually recovers, which is not our experience. Possible dupe is > >> >> [bug 928189][]. > >> >> > >> >> [bug 928189]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928189 > >> >> [bug 922666]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=922666 > >> >> > >> >> There's also [bug 1791427][] in Ubuntu 18.04 that seems related, and > >> >> which proposes the following workarounds: > >> >> > >> >> * In gsettings: `org.gnome.desktop.peripherals.touchpad click-method > >> >> disabled` > >> >> > >> >> * A .service file: > >> >> > >> >> # /etc/systemd/system/touchpad-sleep.service > >> >> # restore touchpad on suspend > >> >> > >> >> [Unit] > >> >> Description=Restore Touchpad on suspend > >> >> Before=sleep.target > >> >> StopWhenUnneeded=yes > >> >> > >> >> [Service] > >> >> #Type=oneshot > >> >> Type=idle > >> >> RemainAfterExit=yes > >> >> ExecStart=/bin/bash -c 'echo "0000:00:1f.4" > > >> >> /sys/bus/pci/drivers/i801_smbus/unbind' > >> >> ExecStop=/bin/bash -c 'echo "0000:00:1f.4" > > >> >> /sys/bus/pci/drivers/i801_smbus/bind' > >> >> > >> >> [Install] > >> >> WantedBy=sleep.target > >> >> > >> >> * "Maybe try xserver-xorg-input-evdev instead of > >> >> xserver-xorg-input-libinput?" > >> >> > >> >> * reloading `psmouse`: > >> >> > >> >> sudo modprobe -r psmouse > >> >> sudo modprobe psmouse > >> >> > >> >> * "`modprobe i2c-i801` after removing it from the `blacklist.conf` > >> >> seems to solve the issue." > >> >> > >> >> * whatever this is: > >> >> > >> >> # echo 1 > /sys/devices/rmi4-00/nosleep > >> >> > >> >> * "Anyone who still affected by touchpad issues after S3. Please > >> >> switch back to suspend-to-idle in BIOS if s2idle is > >> >> supported. ThinkPad Carbon 6th and Yoga 3rd do support > >> >> suspend-to-idle in BIOS->config->power menu." > >> >> > >> >> [bug 1791427]: > >> >> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1791427 > >> >> > >> >> There's also [bug 1442699][] in Fedora, which suggests those > >> >> workarounds: > >> >> > >> >> * another module reload: > >> >> > >> >> sudo rmmod i2c_hid > >> >> sudo modprobe i2c_hid > >> >> > >> >> * "Just updated to kernel-4.12.5-300.fc26.x86_64 in updates-testing > >> >> and this issue seems to have been resolved (for me)." > >> >> > >> >> * another `/proc` hack: > >> >> > >> >> echo -n "reconnect" > /sys/bus/serio/devices/serio1/drvctl > >> >> > >> >> * "The `psmouse.synaptics_intertouch=0` workaround still works for me." > >> >> > >> >> [bug 1442699]: https://bugzilla.redhat.com/show_bug.cgi?id=1442699 > >> >> > >> >> Also related is this [libinput bug][] that's closed as "not our bug" > >> >> because they claim it's a bug in the kernel. > >> >> > >> >> [libinput bug]: https://bugs.freedesktop.org/show_bug.cgi?id=103149 > >> >> > >> >> There are [two][] [patches][] on the Linux kernel which apparently fix > >> >> the > >> >> issue, still pending approval: > >> >> > >> >> [two]: https://lkml.org/lkml/2019/2/20/700 > >> >> [patches]: https://lkml.org/lkml/2019/2/20/701 > >> >> > >> >> Possibly related: https://lkml.org/lkml/2016/8/18/134 > >> >> > >> >> [5.1rc7][] shipped two fixes against the `synaptics-rmi4` module. A > >> >> [pull request][] has been merged in mainline with two other fixes on > >> >> the module./ [5.0.11][] also has fixes on the module. It's clearly a > >> >> regression from Debian stretch (kernel 4.9) since it was working fine > >> >> before. > >> >> > >> >> Possibly related, [two-finger scrolling bug in Ubuntu][], which > >> >> identifies [this commit][] as the source of the regression. [Upstream > >> >> kernel bug][], still open. > >> >> > >> >> [5.1rc7]: https://lkml.org/lkml/2019/4/28/270 > >> >> [pull request]: https://lkml.org/lkml/2019/7/12/19 > >> >> [5.0.11]: https://lkml.org/lkml/2019/5/2/287 > >> >> [Upstream kernel bug]: > >> >> https://bugzilla.kernel.org/show_bug.cgi?id=196719 > >> >> [this commit]: > >> >> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=e839ffab028981ac77f650faf8c84f16e1719738 > >> >> [two-finger scrolling bug in Ubuntu]: > >> >> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1722478 > >> >> > >> >> I haven't tried any of those workarounds. I hope this helps! > >> > > >> > Can you confirm if this issue is still present with a recent kernel? > >> > >> e.g. buster-backports? > > > > Yes exactly either buster-backports, unsteable or mainline. > > > > Initial goal on asking you back is that the issue as reported for some > > kernels way back, try to find out if the issue is still present or if > > we can close the bug otherwise as maintenance. > > Understood. > > The situation, right now, is this: > > 1. the user of this machine has been running the 5.7.10 kernel since > around August 2020, from buster-backports > > 2. they indeed reported the bug not happening for "a month or two" but, > in their opinion it was "still happening" intermittently, and they > expressed surprise at the idea that the bug was fixed > > 3. i therefore completed the last buster point upgrade and installed the > 5.10.24 Linux kernel, again from backports > > 4. i then rebooted the machine in the new kernel, logged in as said > user, then closed the lid, waited a few seconds, and opened the lid > back up > > The mouse froze. > > I rebooted (because that you can still do, of course, with > control-alt-delete), and again reproduced it. > > So, from my perspective, this bug is definitely not fixed, even with the > latest backported kernel, in Debian buster. > > [I'll note that, interestingly, I'm not actually sure the machine goes to > sleep. The red light on the "i" of the "Thinkpad" lid logo doesn't > actually start flashing slowly like it typically does during sleep. But > from a user perspective, that doesn't matter: it's "close the lid, > computer crashes" kind of experience, which is a pretty nasty regression > from stretch.] Thanks for reporting back, much appreciated you took time again to recheck. So I suspect the problem from Tollef and yours might be different. Do logs (dmesg, X logs) give any helpful hints? Might it be possible for you to (re-)bring the issue to upstream? Regards, Salvatore
