Arch Linux

I found a similar report:

https://ubuntuforums.org/showthread.php?t=2361250&p=13648149#post13648149

I can confirm this bug also for linux 4.12.4 which was just released to core.

Please bisect the kernel https://wiki.archlinux.org/index.php/Bisecting_bugs and report the offending commit upstream.
You might also want to check 4.13-rc3 to see if the issue has already been fixed.

Hey Ioqs,

thanks for the fast response! I’ve used git bisect before, a great thing to find bugs, but the Linux Kernel is too huge to be build on my machine in an finite amount of time. So if I would know how exactly bisect between a patched branch of the linux 4.11.x branch and the 4.12.x branch, it would require way over a month worth of processing time on my machine to hunt the commit down with several dozends of reboots which renders the my daily driver completely useless.

I’m fine with testing the 4.13 rc Kernel, if there’s a binary somewhere.


Best regards


Ruben

I am not aware of anyone producing binary packages for arch for kernel release candidate.
$ git bisect start
$ git bisect good v4.11
$ git bisect bad v4.12
Bisecting: 7831 revisions left to test after this (roughly 13 steps)
So a minimum of 13 steps assuming you could allow six hours overnight to compile then ctrl^c and repeat the next two nights that would be 18 hours of build time.
Assuming you could test on the same day building is complete and 18 hours is enough for a build if the bisect went smoothly would take thirty nice days by that schedule.
The last few iterations should build much quicker but that can be balanced out by commits that need to be skipped.
Yes reboots for each test would be necessary as this is a hardware issue I can not even suggest using a virtual machine to avoid that.
I can not really offer an alternative solution as arch does not provide a public build service and unless the bug can be proven to be an arch issue ie integration or packaging
I would expect no action to be taken on it. Please see other assigned bugs for the linux package as proof of this.

I spent yesterday compiling the 4.13 kernel, it was done after ~9 hours on my machine...

I tried the 4.13 kernel, on my machine, and the touchpad does work. The version is:

4.13.0-rc3-mainline

> Yes reboots for each test would be necessary as this is a hardware issue I can not even suggest using a virtual machine to avoid that.

well, sadly it's a ps/2 touchpad, not an USB one, in this case, I would had used a VM...

After 4.13rc3 works the question is more, which commit fixed it on that branch instead of, which broke it, right? I guess I should bisect in the opposite direction, then we could backport the 4.13 fix on 4.12. :)

Sadly 4.13rc3 isn't consistently working for me, sometimes the touchpad work, sometimes it doesn't. So the fix - whatever they tried, doesn't work that good.

I going to build the kernel on a bigger machine, I think this might work in below 1 month ;)

This bugs has been successfuly solved upstream, please close as it 'works for me' now again. :)

Glad the issue is resolved. Could you please share the version number that works for you or the commit that fixed it?
You can also use the request closure button at the top of the page to request that the issue be closed as fixed.

Well, I cannot provide a exact version which fixed it, I was ill and just started to use my computer some days ago again. Had no trouble for a week, so I wanted to share this information here. :)

Should be
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/log/drivers/input/mouse/synaptics.c?h=v4.12.10&id=38c36f9d1fca5b5e6d2d1be13ab82d1ce714e4b1
https://lkml.org/lkml/2017/5/23/194
https://lkml.org/lkml/2017/5/19/685

Are since those patches are in the claimed broken kernel and there're only two (obvious) patches in the relevant area of the alleged regression¹, are we sure this is fixed and not only worked around by the synaptics_intertouch parameter?


[1] https://bbs.archlinux.org/viewtopic.php?pid=1747894#p1747894

That commit seems to have been in the initial 4.12 release as well, so I don't think that can be the one...

Well, I was obviously wrong, the bug persistent up to the latest stable kernel currently in the repos (4.15.13-1-ARCH). I think I used the wrong machine while writing the latest comment. Sorry for that.

It's a bit messy in this ticket, so I want to do an update from my side:

The latest kernel render my touchpad completely unusable, before it was sometimes working, sometimes don't - so it was "decided" on each boot - which sounds to me like a race condition in software or hardware initialization.

Since 4.11 was the latest version, which was working fine - I gonna try all RC versions of 4.12 on which this bug starts to occour and then bisect the commit which introduce this regression.

I cannot reproduce the issue. Is it still valid?