severe lags after updating to 2.1.3.7 (connman-related)

asked 2017-12-20 17:17:21 +0300

Ivan Sorokin
183 ●5 ●7 ●9

updated 2017-12-26 04:14:46 +0300

Hello. I have just updated my phone (Jolla 1) to version 2.1.3.7. Perhaps I skipped a few versions. Since the update I experience severe lags (for ~1 second). During the lag the phone ignores touch actions, so I often have to redo some actions.

Here is the video: https://drive.google.com/file/d/1aKg1emnEzJzdJ0xa6dSo042i7bQIcbh5/view?usp=sharing

At the 4th second you can see that the phone ignored my swipe and at the 7th second you can see a lag for about 1 second. These lags happen while scrolling icons on the home screen, during application minimization/closing, during browsing network related settings.

These lags degrades user experience significantly (because touch actions during them are ignored).

update 1To provide a bit more information to diagnose the issue I did the following: I connected using ssh. Run top -d 0.2 and reproduced the lag. Here is the video: https://drive.google.com/file/d/15H-4euSO_F7S_OtwLqM65KZ7s2BYtGMy/view?usp=sharing as you can see during the lag the processes that eats CPU time are: lipstick (the process where we see the lag), dbus-daemon and connmand. One can only wonder what type of communications is going on between lipstick and connmand during the lag.

update 2 I did another test. I turned on flight mode and the lags disappeared. Turning off the flight mode enables lags.

update 3 I have never debugged dbus-related issues, but I tried using dbus-monitor (--session and --system) to see what messages are send during the lag. dbus-monitor --system shows nothing and dbus-monitor --session show only 2 messages:

signal time=1513789428.243024 sender=:1.19 -> destination=(null destination) serial=841 path=/com/jolla/lipstick; interface=com.jolla.lipstick; member=coverstatus
   int32 1
signal time=1513789428.243085 sender=:1.19 -> destination=(null destination) serial=842 path=/com/jolla/lipstick; interface=com.jolla.lipstick; member=coverstatus
   int32 2

update 4 I tend to think that connmand is the problem. Stopping it by using systemctl stop connman makes system very smooth. I think that perhaps lipstick does some blocking rpc calls to connmand. Profiling connmand show that most of the time is spent on doing dbus serialization/deserialization. Now I need to see somehow what is going on in dbus during the lags.

Tell me if I can provide more information.