The mce-tools package should be always available, maybe you need to run “pkcon refresh” first? The suspend times in that small part if your log seem quite short assuming you had display off and USB disconnected. As a comparison in dmesg from last night on my fp2 I mostly saw suspend times of about 30 minutes when the device was idle. The sensorfwd and sensors.qcom processes always use some cpu if you have display on so those can be ignored in that case. Maybe you should get the whole dmesg and send it to me so I can have a look if it would show something.
Assuming the timestamps in the dmesg are correct i did nothing with the phone at that time. It was idle and not connected to anything.
You can download the complete dmesg here:
https://ernstagn.home.xs4all.nl/fairphone/dmesg.2019-11-27
After i saved that, the phone crashed 
After that, things got a bit strange. I lost all network connectivity, even after disconnecting/connecting and rebooting a few times. Somehow something had set the default policy on the iptables input chain to drop without adding any accept rules, effectively breaking every network connection. After i changed that back to an accept policy it worked again and i could run the pkcon refresh and install mce-tools.
The suspend stats were not that helpful, since in that process my phone crashed again , so there had been no time in suspend, i’ll report back on that later.
I’m willing to give this a last chance, but if anything else happens i’ll just try the new beta or rollback to the previous one. This is just not ok for a phone i use on a regular basis.
Such crashes sound very unusual, not sure what could cause that. I haven’t heard anyone else having that kind of issues. Wondering if something went wrong in your previous update and it was just partially done or something but just guessing. Does “cat /proc/last_kmsg” show anything after such crash?
Battery usage seems to be back to normal, after a day with some text messages and about an hour of media player usage to play music it’s 30% down, which seems normal to me. Mcetool shows 91671 for uptime, 85362 fpr suspend time.
Could it be that the firewall rule also caused the battery issue? It also blocked loopback traffic which is often used for inter-process communication.
/proc/last_kmsg doesn’t exist, so there is no info there. The crashes seem to be triggered a lot by typing on the on-screen keyboard, for example when using the terminal or writing a text message, often when i type a few characters quickly after eachother, for example when typing in the terminal and you place your finger on a place where you touch multiple letters at the same time.
Those suspend times seem quite normal. In theory the firewall could cause issues but not familiar enough in that area to know if that was the real reason. “/proc/last_kmsg” is only there if a kernel panic was cause for the reboot. Is that on-screen keyboard crash still happening? I have never seen that but I will try to see if I can make that happen.
I don’t think the crashes are due to kernel panics. Usually the screen freezes or goes black, and after some time it reboots and i see the fairphone logo. Sometimes the vibrator motor (which activates with every character i type) keeps running.
To me it seems more like the watchdog triggering the reboot.
So far the crash while typing happened once in a while (but keep in mind that was with the previous release), two times a day is a rare occasion.
Quick update:
Issues seem to be resolved now, behavior is similar to before the update. Next weekend i’ll try the beta8 update.
Since yesterday my phone started draining it’s battery again. I charged it yesterday morning and it’s already down to 19% now.
In top i noticed the connection manager popping up every now and then, even while it’s not connected to data, wifi or bluetooth.
mcetool gives uptime: 708750.410 and suspend_time: 647487.431, but keep in mind that this also includes a few days of normal behavior.
1 Like
I would suggest you update to latest version. Not really sure what could cause the battery drain, full output of “dmesg” might help but not sure. I haven’t seen anything like that on my device.
I agree with you @mal, so i just did the update to beta8. I hope it’s solved now, i’ll let you know in a few days.
Update was nice and clean by the way, thanks!
After a night where the phone was just idle it lost 20% of battery charge, so power consumption still seems to be high.
Full dmesg can be found here: https://ernstagn.home.xs4all.nl/fairphone/dmesg.2019-12-08
mcetool reports:
uptime: 47556.421
suspend_time: 40884.911
If these numbers are seconds that means it has been active for about two hours during this 13 hour period, that seems like a lot to me.
Succesfully upgraded from 3.0.0.8 (beta3) to 3.2.0.12 (beta8) using SSH.
,---
| Sailfish OS 3.2.0.12 (Torronsuo)
'---
Thank you for making that possible, @mal 
In an attempt to troubleshoot this further i took a look at journalctl -f while the phone was running and i noticed this:
Dec 10 18:59:53 Sailfish systemd-udevd[6955]: Process '/bin/chmod 0664 /sys//devices/system/cpu/cpu2/cpufreq/scaling_min_freq' failed with exit code 1.
Dec 10 18:59:53 Sailfish systemd-udevd[6955]: Process '/bin/chown system:system /sys//devices/system/cpu/cpu2/cpufreq/scaling_min_freq' failed with exit code 1These messages, are repeated over and over again for cpu 1 and 2, about twice a minute.
Looking at the location it reports i see a difference between cpu1 and cpu2 and the rest:
[nemo@Sailfish cpu]$ find /sys/devices/system/cpu/ -type d
/sys/devices/system/cpu/
/sys/devices/system/cpu/cpu0
/sys/devices/system/cpu/cpu0/cpufreq
/sys/devices/system/cpu/cpu0/cpufreq/stats
/sys/devices/system/cpu/cpu0/cpuidle
/sys/devices/system/cpu/cpu0/cpuidle/state0
/sys/devices/system/cpu/cpu0/cpuidle/state1
/sys/devices/system/cpu/cpu0/cpuidle/state2
/sys/devices/system/cpu/cpu0/cpuidle/state3
/sys/devices/system/cpu/cpu0/power
/sys/devices/system/cpu/cpu0/topology
/sys/devices/system/cpu/cpu0/rq-stats
/sys/devices/system/cpu/cpu1
/sys/devices/system/cpu/cpu1/cpuidle
/sys/devices/system/cpu/cpu1/cpuidle/state0
/sys/devices/system/cpu/cpu1/cpuidle/state1
/sys/devices/system/cpu/cpu1/cpuidle/state2
/sys/devices/system/cpu/cpu1/cpuidle/state3
/sys/devices/system/cpu/cpu1/power
/sys/devices/system/cpu/cpu2
/sys/devices/system/cpu/cpu2/cpuidle
/sys/devices/system/cpu/cpu2/cpuidle/state0
/sys/devices/system/cpu/cpu2/cpuidle/state1
/sys/devices/system/cpu/cpu2/cpuidle/state2
/sys/devices/system/cpu/cpu2/cpuidle/state3
/sys/devices/system/cpu/cpu2/power
/sys/devices/system/cpu/cpu3
/sys/devices/system/cpu/cpu3/cpufreq
/sys/devices/system/cpu/cpu3/cpufreq/stats
/sys/devices/system/cpu/cpu3/cpuidle
/sys/devices/system/cpu/cpu3/cpuidle/state0
/sys/devices/system/cpu/cpu3/cpuidle/state1
/sys/devices/system/cpu/cpu3/cpuidle/state2
/sys/devices/system/cpu/cpu3/cpuidle/state3
/sys/devices/system/cpu/cpu3/power
/sys/devices/system/cpu/cpu3/topology
/sys/devices/system/cpu/cpufreq
/sys/devices/system/cpu/cpufreq/interactive
/sys/devices/system/cpu/cpuidle
/sys/devices/system/cpu/powerNotice the missing cpufreq directory for cpu 1 and 2.
Those udev errors are known issue but should only appear when some cpus are turned off for power saving and the paths are removed but the udev rule is missing the check if the path exists so it tries to run the commands for the removed paths. There is already a pull request which fixes it for all devices but but that needs some more testing, I will include it in next release. That should not affect battery life.
If possible could you send me (as private message or via email) full output of both dmesg and /usr/libexec/droid-hybris/system/bin/logcat which you get after you first reboot the device, then leave the device with display, bluetooth and wlan off and without any usb cable connected for at least a few minutes and then get the logs so I can see how it attempts to suspend.
@mal:
I just sent you a PM with the requested logs, please let me know if you need more information.
I started testing next release Sailfish OS 3.2.1.20 for FP2 and so far I have not seen any issues when using the existing Android base. Related to Android base version I have to decide whether to change the Android base to Android 7 as Fairphone finally released the sources for that. I have already built Sailfish OS on top of Android 7 also and have only observed one regression, broken hardware video decoding. Not sure how difficult that is to fix because based on initial debugging I couldn’t figure out why it happens so trying to fix that could delay the release whereas releasing using the current Android 6 base would be easy and fast.
Please let me know if anyone has preferences which way I should continue.
1 Like
Security wise i would say newer is better. For me personally the hardware video decoding is not relevant.
Do you have any ideas for my battery drain problem? I know a lot of people have to charge their phones on a daily basis, but if you’re used to have 3-4 days it’s really annoying.
I am not using your build (yet), but I would say release it with Android 6 first. From Ubuntu Touch, I know that hardware decoding bugs can be long to solve, see the Nexus 5 which still doesn’t have hardware acceleration for example. So solving this could delay the release for some time, and I see no reason to do so.
I guess you also want to release an “alpha” image based on Android 7 to some power user before pushing that to OTA, no?
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.