Elementary OS freezes

[matekdev]

Hey,

(This issue is due to running the cherry trail fix)

Im running the latest version of Elementary OS and I experience issues running this tool. Specifically, at random times (usually around 3 days) the entire computer will completely freeze up. For example, I was typing using Typora and it froze up. The same key was repeated over and over again and I lost complete control of my mouse. The only option is to press the power button to restart.

Thanks

[heikomat]

Thanks for the report. Do you have some further information?

What version of the patched kernel are you running? 4.17 or 4.18?

I've had similiar things happen to me before (like the mouse not working), but (if i remember correctly) it usually involved the device being put in sleep mode/hybernating/closing the lid.

I could sometimes recover by switching the tty (ctrl+alt+F1, then crtl+alt+F7) or just waiting a minute or two, but this happened so rarely that i didn't investigate further, as it is hard to investigate if you can't consistently trigger the issue.

[matekdev]

If I'm forgetting to post any important information please let me know because I am not the most knowledgeable in terms of working with Linux.

The current Kernal I'm running is 4.18. I haven't found any way to reproduce the issue I've been running into. Next time it comes up (which is pretty randomly) I'll let you know if (ctrl+alt+F1, then crtl+alt+F7) atleast helps me recover.

Some more maybe relevant info Elementary OS Loki Asus-E200HA

[matekdev]

Hey, just some more information

I was loading up a web browser when the touchpad locked instead of the keyboard. I attempted to do ctrl+alt+f1 and ctrl+alt+f7 but didn't seem to fix anything. In this case instead of the keyboard completely locking the computer it was the touchpad that stopped working (the keyboard still worked properly). So it seems like either of the input devices get messed up.

[JacekJagosz]

The good thing: I think this is not a problem specific to this kernel. The bad thing: it is the hardware. I had those problems all the time on Windows, I even put my Netbook on a warranty and they replaced the touchpad, but the problem persisted and is even on Linux.

[matekdev]

I dont think it is related to hardware because when running windows on the machine i experienced zero problems. The only time this "freeze" happens seems to be regarding loading up a webpage or working within typora.

[heikomat]

Ok, if it's somewhat easy to reproduce with loading webpages or typora, I'll probably take a look at it. Might take a couple of days though, because of work and college

[matekdev]

No rush, regardless, thank you so much for your work on this project.

[heikomat]

i can't even download typora before the system freezes up, on a fresh elementary OS install using its default kernel (which is 4.15). looks to me like it instasntly freezes as soon as there is a little more load on the machine. Seems to be an issue with the default browser, because /var/log/kern.log shows an epiphany segfault as its last log entry before freezing. will try to use chromium or firefox to install typora. maybe elementary OS won't crash when i don't use epiphany

[heikomat]

It seems that i cannot get the system to crash, as long as i don't use epiphany. Installed chromium, and its way faster, way smoother and doesn't crash the system.

ok, i did get the system to crash, but only after opening about 10 typora instances and about 25 youtube tabs, after which ram and swap were filled, and the system might have even recovered from that, if i hadn't shut it down.

Will now install the 4.18_cx2072x kernel, and see if i can get it to crash

[matekdev]

Yeah after playing around with it, it seems it mostly just freezes the touchpad/keyboard when the ram/swap are filled. Happens a lot less frequently when just using typora / chromium normally.

[heikomat]

i had the touchpad freeze up on me just now. it repeated the following logs every second:

i2c_designware 808622C1:02: controller timed out
elan_i2c i2c-ELAN0100:00: failed to report data: -110

Just before the first of these logs appeared, this is what was written in syslog. It might or might not have something todo with the touchpad failing:

org.gtk.vfs.Daemon[1884]: A connection to the bus can't be made
pantheon-parental-control-daemon[1363]: ** (pantheon-parental-controls-daemon_1363): CRITICAL **: pc_daemon_session_handler_get_id: assertion 'self != NULL' failed
systemd[1]: Starting Stop ureadahead data collection...
systemd[1]: Stopped Read required files in advance.
systemd[1]: Started Stop ureadahead data collection.

it looks like the system can't talk to some i2c controller or something, which is probably the reason the touchpad isn't working (i wouldn't be suprised if the touchpad uses i2c)

i'd guess that the required piece of software to talk to the touchpad stopped working, and couldn't be restartet on the fly. If so, we'd need to find out

1. why did it stop working
2. why didn't it restart after it stopped working

first instincts on why it (whatever "it" is in this case) stopped working:

• The software contains a bug so it crashed on its own
• something timed out because of a lack of system resources, which made "it" lose connection to the touchpad controller.

These really are just guesses extrapolated from the logs here, i haven't even googled the logs yet. This should be a good start to investigate though, as i'm really sure the i2c-logs are related to the touchpad not working.

The second guess is easy to test: run a stress test and see if the touchpad stops working. I'll do that now, and tomorrow i'll go and see what the internet knows about those logs

[heikomat]

oh, a quick fulltext-search on the kernel-sources tells me, that elan_i2c is indeed a mouse-driver, because the files to it are in the folder drivers/input/mouse

[heikomat]

limited ressources don't seem to be the problem. artificially stressing cpu and ram did not result in the touchpad failing

[Grippy98]

Just wanted to pitch in, try to see what you get from the following: dmesg | grep hid

Could also look at what xinput reports.

There used to be a Git project that happened to also work with this under "hid-asus-dkms" that was mainlined into Kernel 4.10 but might be worth trying to manually install. Hasn't been updated in 2 years but might be worth a look.

[matekdev]

Here is some follow up solutions

Restarting the mouse modules completely fix the issue whenever it occurs. sudo -S modprobe -r elan_i2c && sudo -S modprobe elan_i2c

Also, turning off repeatable keys I think completely gets rid of the keyboard issue (Not for sure yet, but I have yet to experience it).

EDIT : Nvm, repeatable keys doesn't stop the keyboard from completely freezing up.