[1.0.4.20] Stability problems - findings [not relevant]

Question

24

[1.0.4.20] Stability problems - findings [not relevant]

asked 2014-03-20 13:39:21 +0200

targon
911 ●10 ●14 ●20

updated 2014-03-31 09:07:21 +0200

Update. This original question is not totally valid from every points (It wasn't final fix, and openrepos is not much to blame on reported issues, i think). See updates in 'answer' I marked as 'correct' with green checkmark below. I will still add some updates there after I complete tests running throughout the weekend

I didn't find other posts quite in subject. All previous updates have been pretty stable for me, except networking and e-mail syncing reliability. Typically I even didn't need reboot my phone for a whole month.

After successfully updating 1.0.4.20 following these steps my Jolla was stable first hours of usage, but went haywire after some activities:
-Become heated in pocket, and when I opened ui was normal, but setup app cover was fluctuating between normal and total pixelsh...t and short refresh sequence. Power button to shut down caused red led to blink in 3 series in quick freq. reboot helped.
-Next morning double tapping was slow to wake up UI. Settings app cover was seen among others, but failed to bring ap to full, instead 'dropped' back to minimized. Other apps could be somehow maximized but failed on network connection. Finally getting into settings failed to change network connections/flight mode states. Reboot helped.
-Whole yesterday battery consumption was at least two times higher than normally and after one phone calls and few sms exchange phone again stucked in dark glowing screen only green led blinking in quick succession.

This is probably half of the problems I actually encountered (and 5 must reboots). All seemed to me be leading to same theory - zombie process eating up resources (and battery). So after some study I tracked _possible_ cause into one source: I had forgotten re-enable openrepos after update, and when I had tried to use warehouse app, something there got hanging (couldn't update apps form there etc.) Maybe after each try zombie slowly consumed all resources. During problems 'crest' app showed some app (if remember correctly harbour-warehouse or something) eating 10% cpu.

Then I tried fix:
1) After fresh reboot issued missed command (from instructions):

for i in $(ssu lr 2>&1 | grep openre | cut -d" "  -f3); do  ssu er $i ; done

2) and then: warehouse->pull down menu->'Refresh cache' or something, my Jolla has been nice and smooth again (99->94% battery level during 8h sleep) and no stability problems. Updating apps from warehouse works fluently now also.

I don't know which one of the two was actual cause.

So if you got stability or battery problems after update, try to re-enable openrepos if you forgot to do that and referesh warehouse cache before trying to install/update apps from there. And would be nice if you comment below if this has helped your case, or if you can give more exact instructions.

edit retag flag offensive reopen delete

The question has been closed for the following reason "question is not relevant or outdated" by molan
close date 2015-08-19 18:04:34.768064

Comments

2

I can confirm the symptoms. The reboots became ever more frequent, and as I deinstalled more or less all apps, I couldn't re-enable updating from warehouse. When reboots came every 15 minutes, I decided to take the phone back to factory settings. Sw back to 1.0.0.5....

Lasse ( 2014-03-20 15:29:35 +0200 )edit

1

My frequent symptoms totally gone now after doing 1) and 2) and nothing else AFAIK. So possibly one of those IS A FIX, I just don't know which one. After reading many questions from last few days I recognize many of those before applying this 'fix'.

targon ( 2014-03-20 16:06:37 +0200 )edit

1

I don't know if it can be of help but before the upgrade I disabled openrepos and I re-enabled it immediately afterwards... and I have not noticed any of these battery drain symptoms.

simosagi ( 2014-03-20 16:52:29 +0200 )edit

Fix 1) is going to terminal and type the command with or without devel-su? (Not a techie, so would be nice to have a more "for dummies" kind of instruction on howto, thx.

spacenewt ( 2014-03-21 18:00:10 +0200 )edit

As devel-su but not sure either was it mandatory. I was following these instructions

targon ( 2014-03-21 18:25:19 +0200 )edit

I can confirm the symptoms. The reboots became ever more frequent, and as I deinstalled more or less all apps, I couldn't re-enable updating from warehouse. When reboots came every 15 minutes, I decided to take the phone back to factory settings. Sw back to 1.0.0.5....
Lasse ( 2014-03-20 15:29:35 +0200 )edit
My frequent symptoms totally gone now after doing 1) and 2) and nothing else AFAIK. So possibly one of those IS A FIX, I just don't know which one. After reading many questions from last few days I recognize many of those before applying this 'fix'.
targon ( 2014-03-20 16:06:37 +0200 )edit
I don't know if it can be of help but before the upgrade I disabled openrepos and I re-enabled it immediately afterwards... and I have not noticed any of these battery drain symptoms.
simosagi ( 2014-03-20 16:52:29 +0200 )edit
Fix 1) is going to terminal and type the command with or without devel-su? (Not a techie, so would be nice to have a more "for dummies" kind of instruction on howto, thx.
spacenewt ( 2014-03-21 18:00:10 +0200 )edit
As devel-su but not sure either was it mandatory. I was following these instructions
targon ( 2014-03-21 18:25:19 +0200 )edit

Answer 1

3

answered 2014-03-21 10:26:32 +0200

targon
911 ●10 ●14 ●20

updated 2014-03-21 10:41:38 +0200

Update: After the 'fix' above 36 hours testing, my Jolla works fluently:

not consuming battery,
no booting problems,
no lost internet connections
> 62% battery
6 apps open overnight (Settings, browser, tweetian, tidings, mitäkuuluu, calendar).
Normal day usage yesterday (few short calls, SMS:es, browsing, twitter, RSS, Mail reading)
Two e-mail accounts updated every 30 minutes.
BT on, 3gData ON, WLAN ON

I'm not saying the following list can be explained by memory/resource exhaustion by runaway process, but before this 'fix' I had at least these problems (which now all are gone):

Connection/syncing failed when other open Not exactly same but connection failures, dropped connections showing yellow notifications even I have strong enough signals in my Home office.
Lost call history Naturally fix didn't bring them back though.
Various led blinking and inconsistency problems Not constant white, but quickly blinking red, and other time green as described above
Numerous reboots/hangs in various situations Reboots fixed problems for a while until few applications were tried out (one reboot came freshly after trying just Warehouse, view Settings, Tweetian and then mostly idling on table)
Couldn't access app Exactly as described here. Sometimes couldn't activate form cover, sometimes from app grid either.
UI flicking problem Exactly as shown in this at 0:23 mark

So these were only part of the issues I encountered during first 3 days also, so my point is they seriously points to direction that Sailfish runs out of resources (free memory/cpu?) for some reason. Unfortunately I cannot reproduce these any more (after 'fix' above), so if any of reader hits some of these or similar, screenshot from 'top' command output in shell or 'Crest' app could maybe lead to misbehaving process (which itself maybe is not the root cause).

I also urge @JollaHQ to take a note and post proper instructions here how user could better track this issue to help them to iron it out.

edit flag offensive delete publish link

Comments

i have the issue with: 1. (no have openrepos app) but how did you repair without developer mode ?

redge73 ( 2014-03-28 23:05:37 +0200 )edit

@redge73 Sorry I have so many bullets that to make sure which one you mean, could you please describe in more detail your question.

targon ( 2014-03-30 23:27:35 +0200 )edit

Answer 2

1

answered 2014-03-27 10:15:59 +0200

targon
911 ●10 ●14 ●20

OK I continue 'my journal' as new answer to keep it readable (if that is even possible with my lenghty rally english...) As listed in my previous comment above, I had to reboot yesterday (Wed) around 13:15. Opened mitäkuuluu, disconnected and quitted. And verified from command line that either of mitäkuuluu processes are running. As of 9.00 am today I have 71% battery (so consumption is in limits imo)

Started again smoothly with full battery and 7 apps running all the time. Did absolutely minimal usage except checking that can I tease connection problem by disabling and enabling wlan from settings shortcut at the same time with refreshing browser from cover view. Also occasionally verified that camera glitch is gone. At 17:52 I went Jogging Jolla covered in plastic bag in waist belt inner pocket (Not too cold, no moisture, but probably hopping signal levels/quality and handovers between 3G masts).

After an hour run I arrived back home immediately seeing WLAN icon greyed out and white star in it (as indication of connection problem?). That's fine since I have seen it before after run with previous releases also in same situation, I didn't do anything to fix the problem to see what happens next. Nothing special other that no network connection -> no refresh of mails, tweets etc. even both WLAN, 3G (and BT) was allowed in settings.

Later in the evening I tried out to replicate camera problem and succeeded with the first try (=blank camera screen, camera button greyed out settings and focus square responsive, no grid shown). I don't know was 1) the connectivity problem described above the perquisite for the problem, or )2 was it because I opened the camera, and just when it showed overview image, I quickly closed it with swipe down (so probably camera closed in the middle of initiating sequence...). I want to remind: no single camera problem before 1.0.4.20.

After the night without fixing connection problem, battery 71% but settings app doesn't allow me disble/enable the connections to fix the situation (flight profile indicator half grey, wlan half grey, 3G data full grey, BT half grey).

So my conclusions: No 'mitäkuuluu' involved to these problems, connection switcher under my suspicion, rest of the experience (maybe except camera) is just because I didn't restore connections manually, running, e-mail, tweetian, tidings etc, was eating all resources trying to reconnect and rest is because of that? I'm half ok that when things go havoc even Linux can not fully protect itself if situation continues. But if connection fails, shouldn't app/Sailfish be smart enough to _clean up the garbage_ and try again? Or as a quick and dirty fix, would some kind of 'auto-recovery'/watchdog whatever in conman have prevented rest of the problems. As a comparison my Ubuntu desktop auto-recovers nicely after many network failures without me doing anything.

I had to reboot to recover this situation, but took some logs, and screenshots, will comment below if I find any interesting after analysing them. Shutdown took almost a minute with rd led constantly on, possibly, because lack of free resources?.

After reboot I again shut down mitäkuuluu and totally removed two failing XMPP accounts I spotted from logs (sp2sip.info and iptel.org had these to test if new release supports chat via those). Lets see it that makes a difference.

edit flag offensive delete publish link

Comments

After reboot (did it twice, removed battery second try). WLAN failed to make connection. I had to totally remove WLAN ap and recreate it in order to make it work (again points to settings/cache or whatever going messy as I suspected before). Of course this can be just consequence of running out of resource situation reported above. As a comparison, connection from laptop to same WLAN has been clean all time since I have net radio on throughout the day.

I went through short log I managed to save before I had to reboot. And only suspicious bit is around time when I hit the camera problem (not sure is this from first or subsequent tries of failing to open camera since log starts from there). To save room here, I uploaded that part to pastebin .

Later throughout the night every 30 minutes mail tries to sync (as scheduled) with error:

Mar 27 04:45:45 localhost msyncd[992]: [W] Buteo::NetworkManager::connectSession:105 - No network reply received after 10 seconds, emitting session error. 
Mar 27 04:45:45 localhost msyncd[992]: [W] Buteo::NetworkManager::slotSessionError:216 -    QNetworkSession::UnknownSessionError 
Mar 27 04:52:28 localhost jolla-email[1721]: [D] unknown:0 - Messaging :  closing database

And then few mail syncing messages. There are later Glib ('doesn't implement property...') and Dbus errors ('System rejected send message...') And camera erros from my continued camera testing. I'm unsure to post full log to pastebin, since sometimes spotted keystrings and other sensitive material, but can send it to Jolla by request if that is of any help.

Continue testing same scenario without whatsapp and android apps. PS. Android support seems to get started automatically even I don't start any andoid apps. Didn't know that, but really hoping that if I don't see android suport in coverpage it guarantees that no Android app 'is trying to use my device'. Mar 27 10:31:58 localhost start_alien.sh[1335]: 03-27 08:31:58.024 1401 1401 E PhonePolicy: Could not preload class for phone policy: com.android.internal.policy.impl.PhoneWindow$ContextMenuCallback

targon ( 2014-03-27 12:03:21 +0200 )edit

1

Camera bug reproduced Ok tried to reproduce camera bug and did quite accurately the following:

Open camera, swipe left to gallery and back (probably not needed to cause a crash)
Open camera and close it with swipe down to close before camera is settled
Position phone to landscape and repeat 2) few times and you will see black camera screen only (with responsive icons, but without grid and camera button is greyed out)

Added log from previous sequence to http://pastebin.com/ycd6vLz4

targon ( 2014-03-27 12:26:48 +0200 )edit

Tethering unreliability
Ok tried native tethering support first time introduced in 1.0.4.20. This is what I did:

Enable tethering from settings (fill in password and enable)
Disconnect laptop from WLAN and connect it to Jolla access point you just enabled.
Run 'Saunamittari' from saunalaht (or any other network speed meter it doesn't matter as log you get lots of data)
After 3:rd test round laptop gives 'Disconnected from jolla' and is not able to reopen the connection anymore.
Stop tethering and your jolla is able to open both connections again.
I added log to http://pastebin.com/HYdnrDmr (updated link)
'Saunalahti' in log means mobile data access point and I marked WLAN router AP as '<*>' (name edited to make it easier to spot from log)

Propably I will not do more this kind of specific tests, since these are basic things that Jolla could continue to do when finishing next update.

PS. Quite a lot 'alien*' log entries even I have not even started any android apps after reboot. If I get rid of those by uninstalling Android support, I'm fine.

targon ( 2014-03-27 13:29:27 +0200 )edit

Thanks for your efforts to track these down, I just encounter the camera bug yesterday. I tried to open a few times after seeing the black screen, but it just broke to a level when camera wouldn't even open anymore. AFTER reboot the UI froze so needed another reboot to get the device in a usable state.

fasza2mobile ( 2014-03-30 05:16:17 +0200 )edit

Accepted Answer

1

answered 2014-03-28 11:09:33 +0200

targon
911 ●10 ●14 ●20

OK I add one more answer and try to list all findings of this 9 day testing session.
Blackbox view:

1. Connection manager (or connection switcher or whatever component) might have something to improve when device enters into poor field and needs to do switchover to other connection means (both directions should be considered)
2. 'mitäkuuluu' (native whatssapp application) hits most badly. At least v0.2-2, I didn't test later versions yet, see my previous answer. By starting to eat >98%cpu time from one core, after some occurrences of case 1). That finally kills the battery and resources forcing user to reboot. Keep in mind that I had forced reboots in case 1) also without mitäkuuluu, so it is not only party in this, and in my guess not root cause either. (see my previous answer from yesterday).
Additional note: app seems to poll whatsapp server quite often in background (isn't there any kind of idling mode or could it just prolong the period by some algorithm?).
3. Camera app definitely has its black screen bug as I reported yesterday. It is reproducible, and I again succeeded in first 3 opening/closing sequence tried again this morning using steps I documented yesterday.
4. New Native WLAN tethering is limited to light load as I reported yesterday above. Actually I had the same problem with separate tethering app before this Sailfish release.
5. Latest very initial finding: Failing XMPP accounts might have their part in resource hog reboot caused by case 1) See my speculation below, as this is very initial yet.

Yesterday after clean reboot (after tehering and camera failures) I again shut down mitäkuuluu processes and had removed two (test) XMPP accounts that had no app attached and at least one of them was failing to connect (see log below). I went out for few hours. Not exactly same conditions that typically during my running, and when I returned home, WLAN icon was only greyed out, but without white star! Tweetian etc. was nicely refreshing using mobile data, an at some point Jolla switched to our (hidden)WLAN when it recognized that it is in reach. I don't remember have this happened ever before no nicely. Mostly remember seeing this white star. Testing continued to this morning and no problems detected (went through log also an nothing alarming there).

Additional note. I have had Facebook precence set to green/available state whole week of testing. Didn't peek and verify was I seen as available though, but isn't that using XMPP: If yes, and then if problems stays away during weekend, case 5) is quite viable. I might report it back before monday if anybody interested. It would be nice to hear comments has anybody experienced the same, and what has fixed their problems if possible. Especially I'm interested in theory that what if case 1) happends because my (Dlink DIR-615) WLAN router acts badly in that situation. So if you have same router but none of the connection derived problems, or other router but same problems, your response would be valuable.

Also I'm considering finally to finish this effort, since I have put quite a lot effort and own time and don't see much bug reporting activity on these cases, I interpret it as only few have still problems, and seems that I know now how to work around them while waiting for next release.

Here is bit of the old log before case 5) 'fix' when I had configured few test XMPP accounts waiting for suitable app to become implemented (When you see any star '*' in log below I masked those).

Mar 26 12:23:47 localhost contactsd[1207]: [W] Tp::Debug::invokeDebugCallback:149 - tp-qt 0.9.3 WARN: Nested PendingReady for true failed with "org.freedesktop.Telepathy.Error.NetworkError" : "G_IO_ERROR_CONNECTION_REFUSED (#39): couldn't connect to server specified by SRV record: Could not connect to sip2sip.info: Connection refused"  
Mar 26 12:23:47 localhost contactsd[1207]: [W] Tp::Debug::invokeDebugCallback:149 - tp-qt 0.9.3 WARN: Building connection "/org/freedesktop/Telepathy/Connection/gabble/jabber/**_40sip2sip_2einfo_2fJolla" failed with "org.freedesktop.Telepathy.Error.NetworkError" - "G_IO_ERROR_CONNECTION_REFUSED (#39): couldn't connect to server specified by SRV record: Could not connect to sip2sip.info: Connection refused"  
Mar 26 12:23:47 localhost invoker[1256]: QDBusConnection: name 'org.freedesktop.Telepathy.Connection.gabble.jabber.**_40sip2sip_2einfo_2fJolla' had owner ':1.5**' but we thought it was ''
Mar 26 12:23:47 localhost contactsd[1207]: [W] Tp::Debug::invokeDebugCallback:149 - tp-qt 0.9.3 WARN: Nested PendingReady for true failed with "org.freedesktop.DBus.Error.NameHasNoOwner" : "Could not get owner of name 'org.freedesktop.Telepathy.Connection.gabble.jabber.**_40sip2sip_2einfo_2fJolla': no such name"  
Mar 26 12:23:47 localhost contactsd[1207]: [W] Tp::Debug::invokeDebugCallback:149 - tp-qt 0.9.3 WARN: Building connection "/org/freedesktop/Telepathy/Connection/gabble/jabber/**_40sip2sip_2einfo_2fJolla" failed with "org.freedesktop.DBus.Error.NameHasNoOwner" - "Could not get owner of name 'org.freedesktop.Telepathy.Connection.gabble.jabber.**_40sip2sip_2einfo_2fJolla': no such name"  
Mar 26 12:23:48 localhost ofonod[840]: voice registration status is 1
Mar 26 12:23:48 localhost start_alien.sh[31754]: OfonoNetworkRegistration::propertyChanged
Mar 26 12:23:48 localhost alien_bridge_se[31795]: WifiModel::updateServiceList

edit flag offensive delete publish link

Comments

Ok, Qiock update after weekend testing. All in all I'm starting to conclude that most of the instability problems points to connection/connection manager failures. There are also separate isolated bugs like camera and maybe tethering I reported below, in addition to others in other users questions.

During weekend after reboot on Friday, disconnecting mitäkuuluu, and removing any extra XMPP accounts still leaving facebook account online (green indicator on notifications view). Phone was stable, quick and didn't consume battery (I tried to tease phone so it is hard to tell).

On Saturday I went out, with Jolla in pocket, to do stuff with my car in front yard, in WLAN coverage borderline. During 3 hours (=6 e-mail syncs x 2), I reqularily checked connection indicators which indicated 0...1 bar of WLAN strength. Whatismy IP indicated WLAN ip alone, or both WLAN and mobile data IP. AFAICT everything was normal and fluent, but during last 20 minutes something happened, was it grand old connman problem or physical pressure to TOH (Sim connection problem suspected elsewhere). Mobile network strength indicator in stand by screen went greyed (with darker stripes i think and no 3G icon). Indicator stayed there whole evening, but still I could initiate a phone call normally. Also BT indicator in settings went greyed out and I couldn't enable/disable it AND it didn't found any BT devices when I tried to discover. Everything else was normal (AFAICT) whole evening even used tweetian, tidings and extra mail sync more heavily than normal.

Left charger ON in Saturday evening and ON Sunday morning disconnected the charger (and after checking battery level&time, left the phone, i think), and after 10 minutes busy green led flashing, display was black, not possible to open up. I had to reboot with power key. This was 2. or 3. time this green led bug comes immediately or soon after disconnecting the charger so either Saturdays weak coverage test, accidental pressing TOH, or disconnecting the charger was the cause or youtellme. Log didn't reveal any clue since it started from reboot. (BT fails first in boot, but succeeds later, which I interpret as boot order misconf or something similar).

Rest of the Sunday was normal, and on Monday morning everything normal with very minimal battery consumption during the night. Log indicated only regular e-mail syncs There are some weird log entries like:
Mar 31 05:27:16 localhost dbus-daemon[924]: Activating service name='com.google.code.AccountsSSO.SingleSignOn' Even I have absolutely zero G* account in my device. Also 'vpn' service gets booted up (for whom?), even I didn't know my device has configured one, start_alien.sh is run (doing lots of service registrations and listeners) even I haven't started any android app after reboots (wouldn't that be better to start when user first time starts some android app?).

All in all after limiting amount of background connections (disconnecting mitakuuluu, and removing extra/failing XMPP accounts) also chances to get rebooting/connection problems go lower. That is e-mail sync every 30 minutes rarely hits just in handover or other critical event in connman, whereas every few minutes refrehing mitäkuuluu or XMPP increases the possibility. So again I think it has been proven that mitäkuuluu is not root of the problems but merely badly behaving victim, eventhough its syncing frequency is quite high IMO, and it goes to bogus loop (at least old v0.2-2) after connection problem eating lots of battery and possibly other resources.
It is still not proven what is the actual resource eater causing reboot/led bllinking/unresponsive connection settings in settings app/star in WLAN icon etc., but my vote goes to connection manager or closely related service. Second best guess would be app, but didn't have one to suspect and still lost BT and ended up green led boot

As i saw some tweet by Jolla crew member during weekend, they seems to be working hard to improve connection reliability, so I put this case on rest and wait for next update (If needed, avoiding frequent backgroud connections meanwhile). I also thought that we do this _together_ as name indicates, but maybe Jolla crew is busy in other forums.

targon ( 2014-03-31 10:53:31 +0200 )edit

Hi,

Firstly, thanks for the detailed logging. It really is helpful to have information like this, and we do read it, even if we're sometimes lax in responding in a timely fashion.

com.google.code.AccountsSSo.SingleSignOn is not a reference to a Google account, but rather to the Accounts&SSO framework, whose code repository is hosted on code.google.com (so its fully qualified name, used for dbus path etc, is com.google.code.AccountsSSo). So, you'll see it whenever anything on device signs into an account (eg, sync adaptors).

I have managed to reproduce a problem related to flaky network connectivity while syncs are occurring, which I have submitted a fix for. Hopefully it gets into the upcoming update. That might be one culprit for problems, but shouldn't affect XMPP.

Yes, network connectivity is of course something which a lot of effort is being expended on - but I can't comment too much on that, as I'm not personally involved.

Cheers, Chris.

chris.adams ( 2014-04-01 11:48:36 +0200 )edit

Hi @chris.adams thank for your reply. Great to hear that you have spotted and fixed connectivity bug, really looking forward to get the update where it is included.
I din't do any specific tests anymore, but yesterday was my jogging day, which means 1h out of WLAN coverage (=2 mail sync tries) and I did indeed again encountered the failing-not restoring WLAN symptom, with the difference to last week that it is still only symptom after about 17h even I did nothing to fix it. As compared to last week where device went haywire within next 10-14 hours. Battery level was 68% after >34 hours since full charge, which is excellent imo.

So my point is that you maybe right that failing (VOIP!) XMPP accounts doesn't directly have part in this, but may be indirectly since they try to connect also and if connection fails, maybe might go to unwanted state? When I draw map from my last weeks testing, I first eliminated mitäkuuluu, and reboots did still occur, but not that easily. Then, on last Thursday March 27 (after similar jogging-reboot sequence), I finally removed also those two XMPP accounts (except working facebook which is still online). After that I have experienced only one 'forced' reboot (On sunday) and that _might_ be story of its own. I mean _possibly_ caused by bressure to TOH->Sim failure reported by others since device was in my side pocket while I was on Sat. working on my car in difficult positions.
So only one forced reboot after Last Thursday after removing XMPP accounts, and no boots after Sunday morning, no increased battery consumption.

As said earlier I'm fine waiting for next update, since I can workaround these for now.

Just to report: After yesterdays jogging, as of this morning I still cannot connect via WLAN, since I didn't want to reboot to see if device goes haywire. Symptom is that 'after jogging' device had switched over to moble data, and in settings WLAN is 'on', but when you go to settings->WLAN the signal bars are zero in my home WLAN ap (and word 'secure' under its name. Now after connecting via USB (to dave logs), I palyed with the settings and settings app seems to go more and more messed. I enabled 'flight mode' to refresh connections. After disabling 'filght mode' again, all indicators (WLAN,mobile data and BT) came bright, but still same WLAN problem. After disabling mobile data, wlan didin't come back, but BT indicator started to blink and i get big 'Settings is not responding ' indicator when I try to do something with connections. Only maybe interesting log entry at the time:

Apr 02 11:29:04 localhost jolla-settings[6706]: [D] NetworkService::setAutoConnect:282 - "Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken."

That might also come because I keep losing USB IP-address, which that might in laptop side, since I gave 'sudo ifconfig usb0 inet 192.168.2.14' which is not permanent? Again looks that yesterday after losing WLAN was not fatal since it successfully switched over to mobile, but now that i manually disabled just mobile data, something bad starts to happend in 'settings'. Selection settings->WLAN->select internet connection. Pulley appears slowly, stays visible long, finally comes yellow label '... Searching' -> 'Wlan, Oops no networks found' . Also 'Settings not responding' while tapping BT icon. BT status indicator blinking. At the same time nothing special seen in log. only 'd-bus[587] rejected send message...' i reported earlier:

Apr 02 11:40:05 localhost dbus-daemon[587]: dbus[587]: [system] Rejected send message, 5 matched rules; type="method_return", sender=":1.10" (uid=0 pid=824 comm="/usr/sbin/ofonod -n --noplugin=dun_gw,hfp,hfp_ag ") interface="(unset)" member="(unset)" error name="(unset)" requested_reply="0" destination=":1.13" (uid=0 pid=835 comm="/usr/bin/fastdormancyd ")
Apr 02 11:40:05 localhost dbus[587]: [system] Rejected send message, 5 matched rules; type="method_return", sender=":1.10" (uid=0 pid=824 comm="/usr/sbin/ofonod -n --noplugin=dun_gw,hfp,hfp_ag ") interface="(unset)" member="(unset)" error name="(unset)" requested_reply="0" destination=":1.13" (uid=0 pid=835 comm="/usr/bin/fastdormancyd ")

So I'm happy waiting for next update, no need to argue, but I still take my original stand that failing connection from whatever source maybe indirectly causes secondary problems (mitäkuuluu 1.0.2-2 eating 97% cpu & battery), XMPP accounts causing also resource consumption many of those finally leading to (possibly) pixelation, blinking LED, nonresponsive UI forcing boot, unintended boot etc -symptoms reported in other threads.
Camera problem, maybe lose battery broblem and pressing TOH excluded as separate problems.

PS. Apps Ihad active 24 hours was mostly the same, tweetian, tidings, settings, mail and activated screenshot overnight after yesterdays connection failure.

targon ( 2014-04-02 12:06:21 +0200 )edit

1

Just quick addition if it is of help to anybody. After connectivity problem described above, I tried to re-enable WLAN without reboot by the command:

systemctl restart connman.service

With no luck, actually got Green Led blinking problem, and only way to shut down was removing battery. Then tried booting -> grey WLAN icon and no wlan connectivity (mobile data and BT ok). Only way I could get WLAN back was to remove and re-create WLAN AP (=select 'forget' after long press on your WLAN ap in settings).

I have suspected settings database get messed after these reboot problems, and this adds one vote to that.

targon ( 2014-04-02 14:33:57 +0200 )edit

I believe that a lot of the issues you're seeing will be resolved by the next update, as significant effort was expended on improving the lower-layers of our connectivity stack. But I don't know much about it, at all, so I can't say exactly what changed. Reading the release notes and changelogs when the next update is released will probably be more informative than I have been, I guess.

chris.adams ( 2014-04-03 07:04:48 +0200 )edit

Answer 4

0

answered 2014-03-24 10:32:00 +0200

targon
911 ●10 ●14 ●20

updated 2014-03-24 10:46:12 +0200

Some more findings. I used Jolla cautiously throughout weekend but with pretty normal usage (Settings, browser, tweetian, e-mail, tidings, whatismyip, mitäkuuluu logged in but not used) experiencing AFAICT normal battery consumption (bit longer usage periods). Then on Saturday I was at first time chatting using mtäkuuluu (had been just in connected state since 1.0.4.20). App worked fluently, but when I tried at the same time to take a picture using Jolla camera, app opened, but sensor image was totally blank, menus and switching between camera/video mode worked normally but no picture and camera button was greyed out. Also I was able to select 'grid' from settings, but it didn't bring it out to camera view. With several retries I once managed to activate front camera preview, but still main camera remained black. In video mode I saw tiny yellow warning triangle in focus frame. Camera problems Never occurred before.

During Sunday I tried to monitor CPU usage with 'crest' and 'top', but for me it seemed normal or at least I didn't spot any process with high cpu constantly. Strange problem, but Jolla seemed quite normal otherwise whole day (maybe battery consumption was bit higher like double to low as other have reported).

In the evening something happened, I double tapped Jolla, in a situation where I quess switching from WLAN to 3G Data might have occured or was occuring. That is I walked into weakest WLAN coverage spot in our house Jolla in side pocket and then taking jolla from pocket and double tapping on screen to read tweetian. After double tap I saw that UI flicking problem reported here. Pixelation seen in 0:23 mark and that started before I even maximized any app from cover page. All apps become closed automatically because of this, and 'top' command reported mitakuuluu eating 94.3 % cpu and 1.8% memory (that is that between 22:33:34 and 22:39:03 'TIME+' column of of mitäkuuluu process went from 1:18:96->6:40:38). As a comparison lipstick process that was also under 12.4% load durig the event its TIME+ column went from 0:09.84 to 0:28.53 proving that loads were constantly high.

I think that runaway process was _background server_ process of mitäkuuluu app (seen as 'harbour-mitakuuluu' in process list) since that process remained there even I successfully opened mitäkuuluu UI and connected to whatssapp service and then disconnected and quitted app.
What I am not saying is that what was the root cause of the problems, hanging mitäkuuluu bacground process might just as well be the victim of badly behaving connection switcher of Sailfish and so on.

After reboot everything went back normal and battery went overnight from 100%->96% during 6h.

edit flag offensive delete publish link

Comments

Just quick update. After my last 'answer' above I have 66% battery left left (after about 32hours since full charge). Yesterday did only some poking around with apps, and only random clitch I found was this:

Go to camera (you don't necessarily even need to take a pic), flick left to see the gallery->whole camera app disappears (crashes) without showing gallery. It has occured twice since last reboot, and both times I had uncommon setting on (settings->apps->camera->set 8Mpix 4:3). Second time it was on even I thought I had reverted it back to 16:9 mode. After setting it to 16:9 mode I haven't experienced same issue (though tried camera only few times). Again I don't know which one was cause and which consequence.
Just a thought: This could also have something to do with updating settings. Mitäkuuluu got 'fixed after 'refresh cache' in warehouse app (see above) or what ever was in pulley first time after you enabled repos in command line, couldn't see camera preview on Saturday (see above) and so on. Settings db messed up?. Anybody how to see jolla log that would have some relevant info.

My random running apps overnight (last night), whatismyip (showing WLAN ip), tweetian, screen shot, hunger meter, crest, mitäkuuluu, showing last chat, but not in active chat after reboot.

uptime
 10:46:53 up 1 day, 12:02,  1 user,  load average: 0.76, 2.31, 4.04

targon ( 2014-03-25 10:54:11 +0200 )edit

Update#2 as of Mar 26, last 24 hour without clitches (not much active usage though). battery level 42% after about 55h since last full charge. Running apps last 24 hours 1)whatismyip, 2)hungerMeter, 3)crest, 4)browser (in tabs view),5) mitäkuuluu, 6)screenshot, 7)tweetian, 8)settings . WLAN ON, 3G data enabled (only WLAN IP shown in whatismyip ), BT on, mail sync every 30 minutes 2 accounts syncing ok.

Hunger meter and crest have been been running about 32 hours now, so they probably take their part from battery, but still >55 hours and 42% is not bad even very light usage (10-25 mins tweetian, 5-10 mins browser, fiddling around shortly between hungermeter and crest, camera, gallery, e-mail, mitäkuuluu. Hunger meter reports power consumption 81mW (24h average).

Last login: Tue Mar 25 10:37:25 2014 from 192.168.0.121
NOTICE: Env value ignored QT_GSTREAMER_CAMERABIN_FLAGS=15
NOTICE: Env value ignored QT_WAYLAND_RESIZE_AFTER_SWAP=1
,---
| SailfishOS 1.0.4.20 (Ohijärvi) (armv7hl)
'---
[nemo@localhost ~]$ uptime
 09:19:55 up 2 days, 10:35,  1 user,  load average: 1.53, 1.87, 3.04

targon ( 2014-03-26 09:25:47 +0200 )edit

Just during writing report above (and after connecting charger?), I used my Jolla again while in spot where we have weakest WLAN coverage (so possibly autoswitch WLAN->3G) and here is what happened (see harbour-mitakuuluu) line:

top - 09:51:11 up 2 days, 11:06,  1 user,  load average: 1.15, 1.29, 2.08
Tasks: 260 total,   1 running, 259 sleeping,   0 stopped,   0 zombie
Cpu(s): 50.6%us,  0.4%sy,  0.0%ni, 48.7%id,  0.3%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:    831704k total,   816968k used,    14736k free,      196k buffers
Swap:   520180k total,   134352k used,   385828k free,   136156k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                         
 1206 nemo      20   0  213m  13m  10m S 99.8  1.7  60:12.97 harbour-mitakuu                 
 1342 root       0 -20  6664  312  312 S  0.4  0.0   1:51.93 mpdecision                      
14272 nemo      20   0  168m  36m  27m S  0.4  4.5   0:40.15 harbour-hungerm                 
25563 root      20   0     0    0    0 S  0.4  0.0   0:09.37 kworker/0:2                     
 1441 system    20   0  894m  41m  23m S  0.3  5.1   1:32.32 system_server                   
29176 nemo      20   0  2608 1160  812 R  0.3  0.1   0:00.84 top                             
  111 root      20   0     0    0    0 S  0.2  0.0   1:22.24 mmcqd/0                         
29122 root      20   0     0    0    0 S  0.2  0.0   0:00.32 kworker/1:0                     
  906 root      20   0     0    0    0 S  0.1  0.0   0:09.57 TX_Thread                       
16711 nemo      20   0  148m  34m  25m S  0.1  4.2   0:17.21 harbour-crest                   
22173 nemo      20   0  526m 127m  38m S  0.1 15.7   1:44.95 sailfish-browse                 
28501 root      20   0     0    0    0 S  0.1  0.0   0:04.86 kworker/u:0                     
    1 root      20   0  5060 1932 1192 S  0.0  0.2   0:02.43 systemd

Disconnecting and quitting mitäkuuluu made problem to go away, after relaunch mitäkuuluu process is in its normal limits:

28969 nemo      20   0  176m  48m  27m S  0.2  5.9   0:06.08 harbour-mitakuu

I also tried to replicate problem by maully switching to 3G with no luck (occurs only when WLAN coverage drops quickly?)

targon ( 2014-03-26 09:56:15 +0200 )edit

Well what to say. Things started to happend quickly. After doing exactly the things mentioned 2 hours ago visited weak wlan coverage, connected charger, disconnected - quitted and relaunched runaway 'mitäkuuluu', tried to reproduce problem by disabling wlan and then enable back wlan phone to table on good coverage. Only top command active with 10 sec interval via ssh from Linux.

Charging led was lit as should then-> yellow led blinking (received e-mail)->double tapping to wake up ui->blank screen->green led blinking on quick succession->second double tap all apps closed but things seem othervise normal. Whatismyip shows two IP:s (wlan and 3G). Mitäkuuluu launches and connects normally. Forgot to say that facebook account has been 'online' whole week (green availability indicator on events view->show precense details) When double tap killed all apps (listed in previous post) top command via ssh was still active showing:

top - 12:04:48 up 2 days, 13:20,  1 user,  load average: 1.01, 0.76, 0.46
Tasks: 254 total,   1 running, 253 sleeping,   0 stopped,   0 zombie
Cpu(s):  2.2%us,  2.0%sy,  0.0%ni, 95.8%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:    831704k total,   653288k used,   178416k free,       80k buffers
Swap:   520180k total,    41032k used,   479148k free,   325976k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                          
30674 root      20   0     0    0    0 S  0.7  0.0   0:12.16 kworker/0:1                      
  492 dbus      20   0  3992 2296 1132 S  0.5  0.3   1:03.32 dbus-daemon                      
  848 root      20   0 25756 2976 2412 S  0.5  0.4   0:54.33 upowerd                          
 1342 root       0 -20  6664  308  308 S  0.4  0.0   2:33.90 mpdecision                       
29910 nemo      20   0  2708 1176  816 R  0.4  0.1   0:34.72 top                              
31434 nemo      20   0  307m  70m  38m S  0.3  8.7   0:06.26 lipstick                         
32020 radio     20   0  809m  34m  16m S  0.3  4.3   0:00.49 m.android.phone                  
  784 root      20   0  6088 2056 1756 S  0.2  0.2   0:58.78 connmand                         
31887 system    20   0  883m  68m  44m S  0.2  8.4   0:02.20 system_server                    
31963 10007     20   0  828m  52m  27m S  0.2  6.5   0:00.76 ndroid.systemui                  
  170 root      20   0  3632  968  836 S  0.1  0.1   0:11.39 systemd-udevd                    
  834 root      20   0  211m 4636 3808 S  0.1  0.6   0:47.41 statefs                          
  906 root      20   0     0    0    0 S  0.1  0.0   0:11.51 TX_Thread

Only suspicious is memory and cpu-time numbers of mpdecision process, which I don't know nothing about. Anybody have pointer to doc where these led blinkings are documented? (pretty sure they are Sailfish state/error/panic codes or something).

Also anybody have a clue what is this process, yesterday installed ChatSecure from 1MobileMarket. Is it using phone capabilities also?

32020 radio     20   0  809m  35m  16m S  0.4  4.4   0:03.99 m.android.phone

targon ( 2014-03-26 12:24:51 +0200 )edit

To me it looks like mitäkuuluu does not handle connection switching gracefully. So there is an issue there. This of course can cause it's own lot of problems by swamping the cpu etc... Your report also shows load is unusually high (it should not go above 1 normally). I would retry your tests to see how much of these isssues still remain when you stop using mitäkuuluu.

The logging can be accessed with journalctl. Use with -h to find the options that would show you a sane log. (usually -a --no-pager) If this does not give you all you are looking for please ask.

Btw you can also see your wlan ip in the developer mode settings, so no need to run whatsmyip ;)

Philippe De Swert ( 2014-03-26 12:42:08 +0200 )edit

[1.0.4.20] Stability problems - findings [not relevant]

The question has been closed for the following reason "question is not relevant or outdated" by molan
close date 2015-08-19 18:04:34.768064

Comments

4 Answers

Comments

Comments

Comments

Comments

Question tools

Stats

Related questions

[1.0.4.20] Stability problems - findings [not relevant]

The question has been closed for the following reason "question is not relevant or outdated" by molan close date 2015-08-19 18:04:34.768064

Comments

4 Answers

Comments

Comments

Comments

Comments

Question tools

Public thread

Stats

Related questions

The question has been closed for the following reason "question is not relevant or outdated" by molan
close date 2015-08-19 18:04:34.768064