Elantech-touchpad related nvidia driver freeze

This particular issue has been covered in https://devtalk.nvidia.com/default/topic/595378/linux/ubuntu-13-10-nvidia-prime-suspend-resume-bug-touchpad-bug/2/?offset=22#4225154 before, however, that thread appears to be about two independent issues (as I do not experience the other one mentioned there). Thus, I decided to collect all available information about this, add my own findings, and make a thread specific to this behaviour.
This bug has also been covered in https://bugs.launchpad.net/ubuntu/+source/nvidia-prime/+bug/1220426, which lists other setups people have encountered it with.

The issue is that Xorg, when using the proprietary nvidia drivers, freezes irregularly, and can only be brought back by switching virtual terminals and then switching back. (e.g. Ctrl+Alt+F1 → Ctrl+Alt+F7)

The issue only appears to occur on systems that use “ETPS/2 Elantech Touchpad” devices, and on those, only if the touchpad is in use. Freezes do not occur if the touchpad is not being touched or is disabled.

While it sounds like an issue specific to the touchpad, it’s not. It does not happen when using the Intel drivers (and with that the Intel GPU in the system). Furthermore, it does not appear to have been encountered in systems without an nvidia GPU.

The following laptop is the one I’m using, which does have the issue described in this thread:
ASUS UX32LN-R4021H

Other laptop models with similar configuration reportedly show the same issue; they are mentioned in the launchpad bug report comments.

After/when the bug occurs, multiple xorg messages are logged, one of which is related to the touchpad. The relevant Xorg messages are reproduced below, as they have not been logged yet at the time at which nvidia-bug-report.sh was run. nvidia-bug-report.sh was run before switching back to the X11 VT.

[  2864.405] (II) Open ACPI successful (/var/run/acpid.socket)
[  2864.405] (II) NVIDIA(0): Setting mode "NULL"
[  2864.405] (EE) NVIDIA(0): Failed to initiate mode change.
[  2864.405] (EE) NVIDIA(0): Failed to complete mode change
[  2864.433] (II) modesetting(G0): EDID vendor "CMN", prod id 4931
[  2864.433] (II) modesetting(G0): Printing DDC gathered Modelines:
[  2864.433] (II) modesetting(G0): Modeline "1920x1080"x0.0  138.78  1920 1966 1996 2080  10
80 1082 1086 1112 -hsync -vsync (66.7 kHz eP)
[  2864.433] (II) modesetting(G0): Modeline "1920x1080"x0.0   92.52  1920 1966 1996 2080  10
80 1082 1086 1112 -hsync -vsync (44.5 kHz e)
[  2864.454] (--) synaptics: ETPS/2 Elantech Touchpad: touchpad found

The following graph shows that the issue does not occur while the computer is not being touched. The data collected comes from a period of seven days. The freezes were logged by grepping the Xorg log file for the above mentioned messages that are logged after it occurs, and ignoring the first two hits which are from boot-up. 325 freezes have been logged over the span of roughly 171 hours. This data has then been thrown in the general direction of a physics graduate, which resulted in a pretty graph.
Note the gaps on the timescale. This is when I’m asleep, and thus don’t touch the device, which appears to result in no freezes.

Attachments:

http://fratti.ch/tmp/nvidia-bug-report.log.gz - The nvidia-bug-report.sh output right after a freeze occurs, before switching back to the X11 VT.

Please let me know if I can provide any additional information to help fix this bug as soon as possible.

BUMP

I see the same behavior, even though I don’t have a pretty graph to show it :), and so do at least 154 other people running various flavors of Ubuntu (https://bugs.launchpad.net/ubuntu/+source/nvidia-prime/+bug/1220426). This bug has been present for over a year now, and is generating some serious bad karma for nvidia hardware among us Linux folks. Does anyone at nvidia care?

I think i noticed this aswell on my UX32VD Laptop!

Not sure if this is it but since I upgraded to latest drivers and KDE5 desktop ive had 2-3 freezes that i had to manually reboot with. Switching TTY’s did help the first time but the second time it happend i just had a black tty. And capslock was not responding.

All i know that i noticed these freezes just recently (~1-2 weeks ago)

It might be interesting to see whether the problem could be worked around by using xf86-input-mtrack instead of synaptics. If so, then this implies the issue could be worked around in the open-source synaptics driver too, and we wouldn’t have to wait on nvidia. I’d still much rather have nvidia actually do their jobs though.

This bug has been largely noticed, me I’m suffering from it. It involved the XServer compositor too. I reported it here: [url]https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1393412[/url]. Please say if it affects you too.

The fix was reviewed, so at this point it’s just waiting for Keith Packard to merge it into the upstream codebase. At that point I’ll nominate it for backporting to the xserver 1.16 branch.

As Aaron Plattner said, I applied the patch and it works really fine. I’ve prepared a quick answer here: [url]http://askubuntu.com/a/550603/349383[/url] if you can’t wait until the update is released.

I’ve been using the patch for over a month on ArchLinux now by applying it myself, and it has been working wonderfully for me. Thanks to everyone who helped fix this!

Hello, where can I find the mentioned patch? I’m having the same issue on my N551JW NVIDIA 960m laptop.

xorg-server-1.17 and newer all have it applied.

I’m successfully running without issues using Linux Mint 17.3 (Rosa) on my Asus N551JW laptop.

It’s i7 4th gen + NVIDIA 960m.

Used NVIDIA Graphics drivers official ppa with Rosa’s default kernel (3.19.0-32-generic).

–

No issues settting it up with the following grub cmdline before installing the driver:

noquiet nosplash nomodeset i915.preliminary_hw_support=1 acpi_osi=

after installing NVIDIA Driver:

noquiet nosplash i915.preliminary_hw_support=1 acpi_osi=

I can run 3D with both Intel and NVIDIA cards.

Hope it helps someone.