[ROM][12Sep][GNU/Linux] Sailfish OS 2.0.5.6 - Dirty Cow fix, add JBD,XFS,iso9660,UDF

[rinigus]

It's great if u get that much SOT! I tried it as stand-alone ROM and Multirom, the results were same . I suspect my battery health now

maybe its still SFOS. Check the following:

1: do you get N4 to sleep? for that, run 'mcetool --get-suspend-stats' as root/devel-su. You are supposed to get suspend time >> 0. if not, you have something keeping it alive. I have something in sfdroid doing it and will look for the cause. mcetool is in mce-tools package (or mce-tool, not sure in package name)

2. what's SOT in android? try to test it in android and see if the SOT is much larger there. I have much better performance in Chroma 6.

The devel version of SFOS is better than gamma4 in battery life terms, I think. I have seen proximity sensor using lots battery (2-4%/h or more) due to lack of suspend. So, you could also try to switch off proximity sensor and see if it helps ( mcetool provides a switch for it ). with proximity disabled, I have seen 1.5%/h battery drain on idle, down from 6%/h.

good luck and let us know if it worked. in general, there are changes coming in and I am sure that SFOS on N4 would be an excellent day driver. just have to help developers to polish the OS.

 

[mdjishadk]

maybe its still SFOS. Check the following:

1: do you get N4 to sleep? for that, run 'mcetool --get-suspend-stats' as root/devel-su. You are supposed to get suspend time >> 0. if not, you have something keeping it alive. I have something in sfdroid doing it and will look for the cause. mcetool is in mce-tools package (or mce-tool, not sure in package name)

2. what's SOT in android? try to test it in android and see if the SOT is much larger there. I have much better performance in Chroma 6.

The devel version of SFOS is better than gamma4 in battery life terms, I think. I have seen proximity sensor using lots battery (2-4%/h or more) due to lack of suspend. So, you could also try to switch off proximity sensor and see if it helps ( mcetool provides a switch for it ). with proximity disabled, I have seen 1.5%/h battery drain on idle, down from 6%/h.

good luck and let us know if it worked. in general, there are changes coming in and I am sure that SFOS on N4 would be an excellent day driver. just have to help developers to polish the OS.

Thanks for replying. Yes, the suspend time is 0.00 itself. I am new to these things, can you help me to figure out the command to turn off proximity sensor. I am attaching those commands i got with mcetool --help



With android rom, chroma 6.0 , I used to get 3.30-4.00 hrs of SOT. I use mobile network for data, hardly use wifi

 

[rinigus]

Thanks for replying. Yes, the suspend time is 0.00 itself. I am new to these things, can you help me to figure out the command to turn off proximity sensor. I am attaching those commands i got with mcetool --help
View attachment 3709721
View attachment 3709722

With android rom, chroma 6.0 , I used to get 3.30-4.00 hrs of SOT. I use mobile network for data, hardly use wifi

its

mcetool --set-ps-mode=disabled

Since you get good SOT with Android, problem is not in hardware, but in OS. That's good news and I am sure bolek1337 will release new version when all details are ready. And hopefully it would get better then

 

[bolek1337]

I released a new gamma5 image, and an OTA from gamma4 to gamma5. Please follow https://wiki.merproject.org/wiki/Adaptations/libhybris/Install_SailfishOS_for_mako OTA section by heart. If you're installing gamma5 as a clean image, same instructions as previously apply.

Changelog:
- Sound recording works - that is, in camera app when capturing video, in the Sound Recorder app, and in other places
- Dual mic is used for voicecalls - that improves the quality of your voice heard by the other party.
- Proximity sensor is used by mce - most visible is that the screen goes off during voicecalls and you can't press stuff with your cheek

I did not investigate the battery issue, be sure to check the troubleshooting steps outlined by rinigus.

 

[Crysis2]

hi!
i got a little problem:
accidentally disabled developer mod and there is no way to enable it again!
can some one guide me to how re-enable it again?
==============================================================================
the phone just hanged on and i lost all contacts and massages!
funny but all applications are still there!
i cant access backup that i made just before phone got made!

 

[vetzki]

I released a new gamma5 image, and an OTA from gamma4 to gamma5. Please follow https://wiki.merproject.org/wiki/Adaptations/libhybris/Install_SailfishOS_for_mako OTA section by heart. If you're installing gamma5 as a clean image, same instructions as previously apply.

...

The sed command doesn't work

devel-su sed -i -e "s#^adaptation=.*$#adaptation=http://repo.merproject.org/obs/nemo:/testing:/hw:/lge:/mako/sailfish_latest_armv7hl/#" /usr/share/ssu/repos.ini
Password: 
sed: -e expression #1, char 113: unterminated `s' command

What is it supposed to do? (change adaption to http://repo... ? )

edit: without $ it seems to work
(devel-su sed -i -e 's#^adaptation=.*#adaptation=http://repo.merproject.org/obs/nemo:/testing:/hw:/lge:/mako/sailfish_latest_armv7hl/#' /usr/share/ssu/repos.ini)

 

[bolek1337]

The sed command doesn't work

devel-su sed -i -e "s#^adaptation=.*$#adaptation=http://repo.merproject.org/obs/nemo:/testing:/hw:/lge:/mako/sailfish_latest_armv7hl/#" /usr/share/ssu/repos.ini
Password: 
sed: -e expression #1, char 113: unterminated `s' command

What is it supposed to do? (change adaption to http://repo... ? )

edit: without $ it seems to work
(devel-su sed -i -e 's#^adaptation=.*#adaptation=http://repo.merproject.org/obs/nemo:/testing:/hw:/lge:/mako/sailfish_latest_armv7hl/#' /usr/share/ssu/repos.ini)

There. I fixed it. Since it was in double brackets, the $ sign, which was supposed to indicate an end-of-line for sed, was substituted by shell ($#), eating the # sign. It should work without the $ sign too, so you should be fine. Nevertheless, I changed the quotes to single.

 

[radbme]

OTA was easy enough. I'll report back if I have issues. Thanks!

 

[rinigus]

Monitoring battery and CPU sleep

While debugging battery consumption on Nexus 4, I extended SysMon to show battery related stats in extended form (including rates) as well as CPU sleep %. Since SysMon wasn't showing cellular data on N4, this got fixed as well. Pull request is at https://github.com/custodian/harbour-systemmonitor/pull/14 , below I copied the text describing my changes with small changes from pull description. Code is available from https://github.com/rinigus/harbour-systemmonitor and it would take some time to review it and merge with SysMon proper. Note that changes in SysMon are generic and should work on any SFOS, as far as I can tell.

For visual description, see attached screenshot.

To debug battery charge consumption, I introduced the following changes:

1. I added new CPU sleep data stream that is calculated using the difference in CLOCK_BOOTTIME and CLOCK_MONOTONIC. This difference shows the amount of time CPU is in sleep (used by mcetool). By recording relative change in clock times, we can get how much time CPU was in sleep between two measurements. In Nexus 4, that would be between 0 (no sleep) and 98% (only 2% time active) in some conditions. Since its directly related to battery, I added plot as a part of battery detailed information.

2. I added plotting of battery charge rates (charge and discharge) as a part of battery detailed plot. While for charging autoscale of a plot seems reasonable and other settings can be specified in advance, I found that discharging rates could be interesting to study with different settings. Namely, the patch allows user to specify for discharge rate: maximal Y axis value, minimal time between data points used to calculate the rate, minimal changes in values when calculating the rate. The reasonable defaults are provided, user choices are saved as a part of configuration. User can change the parameters by clicking on discharge rate graph.

As you could see on example screenshot, something was keeping CPU from sleep from 4-7 (at the same time there was some system activity) leading to faster discharge. This process stopped as soon as I started using the phone (will have to look into it later).

For interested but not wishing to compile using Sailfish QT Creator, RPM used by myself is attached. Use at your own risk, as usual. Note that RPM has just version info altered to not get into conflict with SysMon proper (this RPM version change is not in Github).

 

[Kubino]

This screenshot is from night while I slept and N4 was in airplane mode. The second screenshot is more interesting, CPU usage went down after I use my N4.

 

[rinigus]

This screenshot is from night while I slept and N4 was in airplane mode. The second screenshot is more interesting, CPU usage went down after I use my N4.

I have seen exactly the same. if sysmon is with my hack, you could click on battery usage graph and see extended stats.

I can confirm that in no network mode, right after charging has finished, cpu usage goes to 25%, cpu sleep is low with 25% as well, and it all drops as soon as you start using the phone.

in my case, journal is filled with

Apr 16 03:47:13 Jolla systemd[1]: Time has been changed
Apr 16 03:47:13 Jolla systemd[1063]: Time has been changed
Apr 16 03:47:14 Jolla systemd[1]: Time has been changed
Apr 16 03:47:14 Jolla systemd[1063]: Time has been changed

I haven't looked further, probably systemd timectl goes crazy. interesting that it happens after charging and airplane or no-network modes.

---------- Post added at 11:53 ---------- Previous post was at 11:06 ----------

Just a quick note: it looks that this 'time has changed' is all over the journal in huge amounts during and after 25% cpu usage. So it maybe unrelated to what Kubino reported

 

[radbme]

So the only thing I have to report is sfdroid wouldn't load after the OTA. A reinstall of sfdroid fixed it.

Sent from my Yotaphone 2 using Tapatalk

 

[radbme]

Any news on an update to solve battery drain? I've put the N4 away for now until then. Just too much drain to drive.

Sent from my Yotaphone 2 using Tapatalk

 

[rinigus]

Battery drain

Any news on an update to solve battery drain? I've put the N4 away for now until then. Just too much drain to drive.

In short: working on it.

State now: frequently I can get ~1:45-2 h of SOT, but this is not guaranteed. Note that my cellular data is poor at home, that might relate to total SOT

When I started looking into it (gamma4), the battery drain was so large that it was impossible to get through the day. Now I don't have to follow the battery % when I go to work, it easily lasts a day. So, progress has been made and I'll try to summarize it below.

1. Check whether your phone is actually sleeping at all. Mine was 100% awake. It can be checked by mcetool . However, mcetool should be relatively new. I am not sure what's the correct version in release (I'm jumping between testing and devel, on devel right now), but when I was on testing after OTA, mcetool was without sleep check (more on alternative below).

2. Mine non-sleeping N4 had sfdroid WITH google services. Now, anecdotal evidence after that -> I tried to debug it by flashing BBS on it and that made it impossible to boot SFOS. So, I made a fresh install Gamma4, OTA to Gamma5, sfdroid WITHOUT google services. <- Anecdotal part finished. Now I had a phone that was able to sleep, as reported by mcetools.

2b. During debugging of non-sleeping N4, it turned out that the proximity sensor was responsible for quite a large chunk of battery consumption [maybe ~50% in idle]. There is a bug that was opened in Mer to look into the state machines and their use of the proximity sensor. Right now, the enabling/disabling is non-automatic and can be done by user only.

3. I had the same issue as reported by Kubino, post http://forum.xda-developers.com/showpost.php?p=66389112&postcount=470 . Mine was evident right after charging using wireless charger. Since this was easily reproducible I debugged that. Turned out that right after the phone was charged [I am using only wireless charger, not expected on USB], it entered the sleep states that were almost immediately interrupted. As a result, CPU was asleep only 25% of the time. Unfortunately, it seems that the same issue is in Android 6 [Chroma]. At least, when I tested it on Android, battery drain after charging was as large as I had in SFOS and BBS reported lots of wakelocks. Fortunately, the problem goes away when you start using the phone. So, I presume its a hardware or Android issue.

4. The current problem I am working on is related to sudden inability of N4 to get to sleeping state. This is harder to reproduce, but may occur once or more a day. Right now I am looking for possible causes.

While working on these issues I have been extending SysMon and I am planning to release my extensions via unofficial SysMon in Openrepos. There is a bug that I'd like to fix before that, but it should not take long. That extended version would allow you to check sleep time of CPU and look if suspend attempts were actually made.

In sum, there is still some work to do, but I hope to get a decent battery life on N4.

 

[rinigus]

As planned, an unofficial version of System Monitor is released. I hope it will be useful for debugging battery issues. If you are interested, note the incompatibility with the official version!

Available at https://openrepos.net/content/rinigus/system-monitor-unofficial-edition

 

[radbme]

Thanks. Grabbed it from warehouse. Cool.

Sent from my Nexus 4 using Tapatalk

 

[radbme]

I've been working with one of the main devs for Rockpool, the Pebble watch app for Sailfish. After a bit of log reading he determined that the issue I was having is because there are no bluetooth adapters available after bluetooth.target on start up. Basically upon first boot the app can't talk to the watch despite bluetooth having established a connection previously. Any dialogue from you guys I can point him to could help.

Sent from my Yotaphone 2 using Tapatalk

 

[radbme]

Hmm. Quiet in here.

So I noticed something that might line up with what Andy from RockPool is talking about. The Gamma 4 and 5 build have pretty good bluetooth save for audio routing but I noticed that on a fresh boot or reboot, bluetooth is off. It seems as though it doesn't remember tha bluetooth toggle state on a reboot or fresh boot. And if the rockpool service starts before bluetooth is enabled that could be causing it. I see two solutions here. 1. RockPool needs a retry upon bluetooth enable = true and 2. the next gamma build needs to remember if bluetooth was on at shutdown or reboot. Thoughts?

 

[rinigus]

Battery drain / cpu sleep

From the following of SFOS on my Nexus 4, I have seen only msyncd (from buteo packages) to cause the condition at which the phone is not sleeping for longer periods of time. So, if you wish to debug your battery drain issues, you could test as follows:

Use the SysMon unofficial (https://openrepos.net/content/rinigus/system-monitor-unofficial-edition or https://github.com/rinigus/harbour-systemmonitor) or check periodically with mcetool whether your phone CPU goes into deep sleep. mcetool should be relatively recent for this.

When not in sleep for an hour or more, its good to investigate the reason. For that, run wakelock.py (attached) in the terminal (or inspect /proc/wakelocks for wakelocks that are active manually). wakelock.py would check /proc/wakelocks for you and list the wakelocks that have been active for all time period between the checks (marked by *** in the beginnig of corresponding wakelock). The scripts sorts wakelocks according to the activity with the most active ones listed LAST (so it's easy to check it in the terminal). The script sleeps for 2 minutes between the checks and, if all is OK and phone sleeps as well, these 2 minutes can take significantly longer. Don't be alarmed, its a sign of the phone sleeping. When sleep is blocked, it will be refreshing every 2 minutes.

The script output would be (for each wakelock): number of times the wakelock has been allocated, number of times per minute the wakelock has been allocated between two last checks (reported as rate), the longest and the current active period of a same wakelock being active as observed by script. If the wakelock is stuck, these times will be increasing (reported in seconds).

If wakelock.py identifies mce_cpu_keepalive as a stuck wakelock (with ***), check the logs and look for the lines like these:

run in devel-su: journalctl | grep mce

...
Jolla mce[571]: modules/cpu-keepalive.c: cka_session_renew(): long session active after 239802 ms; id=359/BlockSuspend-2 name=:1.22 pid=1282 cmd=/usr/bin/msyncd
...

In this example, wakelock was caused by msyncd (from buteo packages). Notice, that in normal operation, it should be followed by

Jolla mce[571]: modules/cpu-keepalive.c: cka_session_finish(): long session lasted 655828 ms; id=318/BlockSuspend-2 name=:1.22 pid=1282 cmd=/usr/bin/msyncd

If its not then you have the same problem as me.

Please, when reporting, specify which accounts do you have (google, caldav, carddav, ...). The list is under Settings/Accounts.

I wouldn't be surprised if the issue is general SFOS one and its just more visible in N4 port. Its possible that N4 has the same bug as in https://together.jolla.com/question/126892/release-notes-201taalojarvi-released/ : Google contact sync may sometimes hang up and drain the battery . If true, for me, "sometimes" is 1-2 times a day for me. By reboot of the phone (maybe just some services would do) you could get the phone to sleep again.

There is a possibility that the issue has been resolved in newer buteo versions and I just don't know it.

 

[rinigus]

Just to give the feedback: during last 3 days I had no problems with the CPU sleep, i.e. phone stuck in non-sleep mode. These days I had Cal/CardDAV automatic sync disabled and I synced this account once or twice manually during this time. At the same time, Google account sync was active. So, it seems, that in my case the problems were caused by syncing with CalDAV or CardDAV.

As it is, I have reasonable battery life on my N4: uses probably ~60% during 24 hours of normal use [hard to define that]. So, while I charge it daily, I can use it easily as a daily driver. As far as I remember, in Android 6, situation was a bit better, but still I mostly had to charge it daily.