Note: No installation zip available now because of issues in the 3rd party server I have used for hosting the images. If anyone needs an image send me a private message and I can provide a temporary link to the image.
Important notes for updating from old Sailfish OS releases (3.0.1.11 beta4 or older)! Because of enabling on-demand proximity sensor support all users can now flash the modem partition from Fairphone Open OS 18.04 release using fastboot. Please check wiki for detailed instructions.
Important notes for updating from Sailfish OS releases before 2.1.3.7 (alpha5)! Please be very careful when during update about flashing the Android system.img. During update process Android system.img needs to be flashed right after updating Sailfish OS and shutting down the device. Do not flash system.img before Sailfish OS update.
Known issues:
If anyone still notices the previous issue that updating camera configuration fails during camera module change, update or installation please report it to me and use the fix mentioned in earlier release notes (Sailfish OS 3.0.2.8 beta5 release)
Thanks for an other upate @mal.
I was a bit late with the previous update, I did that only last weekend. Since the update I barely get 2 days of (low) usage out of a full battery which used to be about 4 days. Now i’m in doubt if I should update again (and hope it solves the problem) or troubleshoot the battery usage before updating.
Do you have an advice on that?
From which version did update? During the usage which features do you use? A lot of WLAN or mobile data or other such things? Also check what “top” tells in terminal to see if some process is using too much cpu. I haven’t noticed any issues with battery life on my device.
You could have a look at output of “dmesg” and look for “suspend entry” and “suspend exit” messages to see how long it suspended. Also installing mce-tools package and checking “mcetool --get-suspend-stats” should tell if it suspends properly or not.
I updated from beta6 to beta7. The phone is completely idle (no open apps, no data connection(s), no calls or other things. If i run top in the terminal on the phone sensorfwd and sensors.qcom are in the top5 continuously, if i run it via ssh they aren’t, i don’t know if this is normal behavior.
dmesg | grep -i suspend tells me this:
[80182.803567] PM: suspend entry 2019-11-27 18:13:49.198463679 UTC
[80182.859038] Suspending console(s) (use no_console_suspend to debug)
[80182.911496] PM: suspend of devices complete after 47.569 msecs
[80182.915013] PM: late suspend of devices complete after 3.499 msecs
[80182.918444] PM: noirq suspend of devices complete after 3.417 msecs
[80183.149213] PM: suspend exit 2019-11-27 18:13:58.630396800 UTC
[80185.803214] PM: suspend entry 2019-11-27 18:14:01.284353977 UTC
[80185.850934] Suspending console(s) (use no_console_suspend to debug)
[80185.895657] PM: suspend of devices complete after 42.211 msecs
[80185.897466] PM: late suspend of devices complete after 1.798 msecs
[80185.899811] PM: noirq suspend of devices complete after 2.335 msecs
[80186.142643] PM: suspend exit 2019-11-27 18:14:16.565145860 UTC
[80188.803297] PM: suspend entry 2019-11-27 18:14:19.225762696 UTC
[80188.846370] Suspending console(s) (use no_console_suspend to debug)
[80188.884112] PM: suspend of devices complete after 35.452 msecs
[80188.885527] PM: late suspend of devices complete after 1.404 msecs
[80188.887556] PM: noirq suspend of devices complete after 2.020 msecs
[80189.119294] PM: suspend exit 2019-11-27 18:14:34.476366299 UTC
[80191.714907] PM: suspend entry 2019-11-27 18:14:37.071915397 UTC
[80191.754385] Suspending console(s) (use no_console_suspend to debug)
[80191.875272] PM: suspend of devices complete after 118.793 msecs
[80191.882374] PM: late suspend of devices complete after 7.068 msecs
[80191.890975] PM: noirq suspend of devices complete after 8.572 msecs
[80192.137061] PM: suspend exit 2019-11-27 18:15:02.832870523 UTC
[80194.803643] PM: suspend entry 2019-11-27 18:15:05.499333051 UTC
[80194.861168] Suspending console(s) (use no_console_suspend to debug)
[80194.902074] PM: suspend of devices complete after 37.965 msecs
[80194.903921] PM: late suspend of devices complete after 1.835 msecs
[80194.906281] PM: noirq suspend of devices complete after 2.350 msecs
[80195.148771] PM: suspend exit 2019-11-27 18:15:34.646735379 UTC
[80197.803389] PM: suspend entry 2019-11-27 18:15:37.301291092 UTC
[80197.854290] Suspending console(s) (use no_console_suspend to debug)
[80197.894882] PM: suspend of devices complete after 38.151 msecs
[80197.896526] PM: late suspend of devices complete after 1.633 msecs
[80197.898844] PM: noirq suspend of devices complete after 2.308 msecs
[80198.131378] PM: suspend exit 2019-11-27 18:16:06.733536386 UTC
[80200.803650] PM: suspend entry 2019-11-27 18:16:09.405724288 UTC
[80200.863141] Suspending console(s) (use no_console_suspend to debug)
[80200.907628] PM: suspend of devices complete after 41.917 msecs
[80200.912596] PM: late suspend of devices complete after 4.938 msecs
[80200.919251] PM: noirq suspend of devices complete after 6.631 msecs
[80201.170075] PM: suspend exit 2019-11-27 18:16:22.665868607 UTC
[80203.704177] PM: suspend entry 2019-11-27 18:16:25.199890673 UTC
[80203.764956] Suspending console(s) (use no_console_suspend to debug)
[80203.807707] PM: suspend of devices complete after 40.214 msecs
[80203.812571] PM: late suspend of devices complete after 4.834 msecs
[80203.819145] PM: noirq suspend of devices complete after 6.549 msecs
[80204.059728] PM: suspend exit 2019-11-27 18:17:00.403956622 UTC
During this time i did not use the phone at all. I don’t know if this is normal or how this does compare to beta6.
The mce-tools package seems not to be available, pkcon install mce-tools says it can’t find the package. To be sure i also tried mcetool, mcetools and mce-tool with the same result.
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.
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.
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.
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.
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.
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 1
These 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:
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.
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.
