[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#922666: confirmed bug report



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


Reply to: