FS#59005 - [linux] 4.16.15 causes a variety of issues on ThinkPad X1 Carbon gen5

Attached to Project: Arch Linux
Opened by Chris Snell (chrissnell) - Thursday, 14 June 2018, 03:24 GMT
Last edited by Andreas Radke (AndyRTR) - Tuesday, 01 March 2022, 21:20 GMT
Task Type Bug Report
Category Kernel
Status Closed
Assigned To Tobias Powalowski (tpowa)
Jan Alexander Steffens (heftig)
Architecture x86_64
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:

Immediately after installing linux-hardened-4.16.15.a-1, I began to experience a variety of strange issues with my machine:

- Trackpad ceased to function (the buttons still worked, however, as did the Trackpoint stick pointer)
- Keyboard stopped working occasionally
- Some sort of keyboard-related failure/timeout when entering the password to decrypt my LUKS root partion
- Strange network failures: I could ping hosts on my local subnet but could not SSH to them. Connections would simply hang. (connected via WiFi)

Downgrading the kernel to linux-hardened-4.16.13.a-2 fixed the issues completely. I tried re-upgrading back to 4.16.15.a-1 and the problems immediately reappeared.

Switching to vanilla Linux kernel package linux-4.16.13-2 also works without any issues.

I believe that this issue is isolated to linux-hardened and that the regression came about in this most recent release.

I will try to follow up with some systemd journal dumps if I can get them before the computer locks up.



Additional info:
* package version(s)
* config and/or log files etc.


Steps to reproduce:
This task depends upon

Closed by  Andreas Radke (AndyRTR)
Tuesday, 01 March 2022, 21:20 GMT
Reason for closing:  Fixed
Additional comments about closing:  no longer applicable
Comment by Chris Snell (chrissnell) - Thursday, 14 June 2018, 03:38 GMT
I just booted back into the troublesome kernel, experienced the issues, and then combed through the logs. I see nothing of interest in the systemd journal, nor in the Xorg server logs. Even 'synclient' seems to be able to query the Trackpad parameters--it's just that the trackpad stopped working.

I'm happy to do any debugging that you might need. Let me know how I can help!
Comment by loqs (loqs) - Thursday, 14 June 2018, 17:08 GMT Comment by Chris Snell (chrissnell) - Thursday, 14 June 2018, 19:13 GMT
@loqs, yes, building/installing/booting that kernel package with 4.16.15 produces the same issues.

I noticed something interesting about the symptoms: the Trackpad actually *does* work, but only the rightmost 1/2" responds to touch. Most of the trackpad is dead. I noticed a few recent commits in 4.16.4 related to trackpad identification that might be relevant.

Comment by loqs (loqs) - Thursday, 14 June 2018, 19:24 GMT
I would suggest trying 4.17.1-1 from testing see if that has the same issue. If it does you could bisect between 4.16 and 4.17 or 4.16.13 and 4.16.15 and find the bad commit.
Comment by Chris Snell (chrissnell) - Thursday, 14 June 2018, 23:21 GMT
Is there a way to bisect kernel commits but still use the Arch Build System for building the kernel packages? I know that I could build a kernel the old fashioned way, by hand, in my home directory...but this is a work laptop and I need to be able to get it running again quickly when things fail.
Comment by Eli Schwartz (eschwartz) - Friday, 15 June 2018, 03:26 GMT
The general process is discussed in https://wiki.archlinux.org/index.php/Bisecting_bugs
Comment by Chris Snell (chrissnell) - Friday, 15 June 2018, 03:52 GMT
I'm pretty comfortable with git bisect but unfamiliar with building *packaged* kernels from git. As I understand it, the packaged version (i.e. built with makepkg) uses a source tarball from kernel.org. I suppose that I will have to build by hand instead unless there is a "linux-git" style kernel package somewhere. EDIT: There is a linux-git AUR package. I'll give that a shot.
Comment by loqs (loqs) - Friday, 15 June 2018, 07:31 GMT
https://bbs.archlinux.org/viewtopic.php?pid=1770162#p1770162 I would suggest starting a topic on the kernel forum if you have issues with the bisection
Comment by Chris Snell (chrissnell) - Saturday, 16 June 2018, 03:33 GMT
I figured out the problem. Somewhere between these kernels, the ThinkPad X1 Carbon gen5's Synaptics touchpad was enabled for the new "RMI4" driver. When this happened, synclient(1) broke or no longer worked in the same way. I had a call to synclient in my Xorg startup like this:

# Desensitize touchpad around edges
synclient AreaLeftEdge=1800 AreaRightEdge=5200 AreaBottomEdge=5000

Commenting this out "fixes" the problem but now I'm left with an overly-sensitive touchpad that's prone to palm-caused mouse movements.

So.... I think we have two bugs now: a synclient bug and a documentation bug. Should I close this and open a new bug for synclient?
Comment by Chris Snell (chrissnell) - Saturday, 16 June 2018, 03:46 GMT
Figured this out: the RMI4 drivers apparently changed the scale of synclient's touchpad dimensions. Whereas my pad was around 7000 "units" wide with the old driver, under the new RMI4 driver, it's around 1860 units. Thus, "synclient AreaLeftEdge=1800" sets the left edge almost near the physical right edge of the trackpad.

I have an upstream bug to determine if this is the intended behavior going forward:

https://bugzilla.kernel.org/show_bug.cgi?id=200077

If this new scale is here to stay, the wiki should get updated because users with hardcoded synclient tweaks will almost certainly run into problems with this new driver.
Comment by Jan Alexander Steffens (heftig) - Monday, 18 June 2018, 14:22 GMT
Have you tried the xf86-input-libinput driver? It does (different) palm detection.
Comment by Chris Snell (chrissnell) - Monday, 18 June 2018, 14:27 GMT
I haven't. Everything seems to be working fine with the synaptics driver now that I have removed the synclient tweeks from my WM startup script. However, I can see this causing problems for users so I'd like to either get a) the scale of the trackpad edge adjustments reverted to where it was on the older driver or b) docs updated to warn users about the changes.
Comment by mattia (nTia89) - Monday, 28 February 2022, 16:44 GMT
Can we close the issue now?

Loading...