On 2021-05-03 07:37:42, Salvatore Bonaccorso wrote:
> 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?
I'll check again.
> Might it be possible for you to (re-)bring the issue to upstream?
Problem here is: which upstream? I found about half a dozen projects
that could be at fault here... And if it's "Linux kernel", how exactly
do I bring this up? Their bugzilla?
This is a tough nut to crack...
a.
--
Imagination is more important than knowledge.
Knowledge is limited.
Imagination encircles the world.
- Albert Einstein
