Overzealous suspend everything watchdog [workaround included]
 

I would describe N900 behaviour as sane: you have sshd running, you are on a network with IP assigned, whether your screen is on or off people on the network can come and say hello through SSH.

Jolla behaviour is a bit insane, same setup: if your ssh connection hit before screen went dark all is fine and good (until you try to ./configure/make/sudo something), but after screen goes dark (might need an extra minute or two to reproduce) no way to connect.

Does anybody know how to make Jolla more sane in such situations?

edit: This supposedly could help (from irc when asking if screen on could be faked):
Workaround by keeping screen on, but will be horrible on battery. Any other way?

Re: Overzealous suspend everything watchdog
 

Device will not suspended when your device is connected to usb. In home that usually means charger or your laptop.

Only way to wake from suspend (not connected to usb and display off) is to use https://github.com/nemomobile/libiphb which allows periodic heartbeat (ie wake system up at some interval).

Having said that you really should not do it unless you want to screw up your battery life.

Re: Overzealous suspend everything watchdog
 

Going to compile it in a second, do I run it from fingerterm on device and then lock or does it have to be run for each process that needs to be kept alive?

EDIT:
I want to be able to use my J as my N900 pocket computer that works in pocket and does what it was told to. If I can trigger libphb off after usage and keep the rest of awesome battery life than even better, for now I need to know how to keep this thing working when I want it to

Re: Overzealous suspend everything watchdog
 

Not that easy, you cant say what process needs to be kept alive, you need to integrate that into each application itself. So most likely in your use case its just easier to keep your phone in charger, or have external battery charger connected. (Or keep display on).

libiphb is mostly used by alarm application which needs to wake up from suspend, and some internal apps that needs to wake up peridically.

Re: Overzealous suspend everything watchdog
 

My use case is N900 connected to J through ssh running makes etc on J. No way to connect USB/power on on the bus/car (train with laptop will work, sure)

Re: Overzealous suspend everything watchdog
 

Well, yes in developer mode, you can use "mcetool" to disable suspend all together, which will suit your case, but it will make your battery go empty pretty fast.

pkcon install mce-tools
mcetool --set-suspend-policy=disabled

Re: Overzealous suspend everything watchdog
 

Thanks! Device goes into crazy state though, tap to unlock gone, ssh even more wild unresponsive... might need to try on fresh reboot

edit: but htop from ssh now behaves normally instead of screenshot behaviour previously, now just as lively as in fingerterm

Re: Overzealous suspend everything watchdog
 

Works like a charm. New ssh connections start yay! Autogen/configure on libphb went nicely up to lacking 'mce'.
Thanks a lot, with disable.sh while getting on a tram and enable.sh when disembarking this suits all my needs. TY!

Re: Overzealous suspend everything watchdog [workaround included]
 

Back when I realized that this device had this terribly idiotic behavior*, I tried figuring out how to take a permanent wakelock from the Android side. I did not know about the mce "feature" and thus decided to create a new daemon (actually, a kernel module).

The thing is, the battery doesn't actually seem to take a very hard hit (in fact, I got slightly more battery life after enabling the "permanent wakelock" -- but obviously because of measurement error). Then I discovered the craze about the "other half power vampire" and I suspect I will have to redo tests, but at least that got my hopes somewhat high again. I also must mention that I have not inserted a SIM card yet.

* Which is the same as every other Android device out there. That's one benefit less of Jolla vs other Android devices, and one big con when comparing to Maemo devices :( See blog post on why opportunistic suspend is wrong right from the mouth of a member of the original N900 team.

The problem with that is that wake locks are deleted when the process that created them dies. In the above command line, a subshell (or /bin/echo) is the one creating the wakelock and thus the lock dies as soon as echo dies, which is immediate. EDIT: Possibly wrong, see next page.

Re: Overzealous suspend everything watchdog [workaround included]
 

Now can anyone tell me what is different with my Jola, since I have never been hit with this problem.
I can always SSH to my Jolla, just as I can SSH to my N9, whether the screen is on or off. (and on my Jolla I do have the device lock ON, so if I want to access it via the UI then I need to unlock it first...)

Re: Overzealous suspend everything watchdog [workaround included]
 

Maybe you have your device connected to usb charger? Or you have new enough wlan AP which sends keepalives often enough.

Re: Overzealous suspend everything watchdog [workaround included]
 

No charger there, no. The device is just there on da table in the front of me :)

And I have used it like this on 2 locations, at my home where I have a Buffalo WHR-G300N (running default SW, no mods in the box) and now here at my parent's house, where I am connected to a DNA mokkula thingy, which is a ZDE model MF80 hotspot...

So, I don't believe it is about the WLAN AP, or else I have been just lucky :D:D

Re: Overzealous suspend everything watchdog [workaround included]
 

That explains why I have to try about 4 times before I successfully ssh into my Jolla.

That breaks my workflow too much (I want to be able to transfer files to it while sitting on the table) and I am willing to sacrifice some battery life for that. I'll try disabling suspend.

The Z10 had the best feature ever. An smb share always visible. Compatibility with every machine out there, no additional software needed, and live editing on files via network is supported. I am willing to live with sftp, but having to plug in to transfer files takes me back to pre-N900 days.

Re: Overzealous suspend everything watchdog [workaround included]
 

But there has to be other people for whom it works right-out-of-the-box correctly, too, I mean I cannot be the only one here, can I?

have not done any spectacular tweaks to my device, and I reallly don't believe there is something special on my WLAN access points...

Re: Overzealous suspend everything watchdog [workaround included]
 

How is your battery life? With suspend policy disabled it goes close to what was with NFC bug/tohd.service, in 10.5h went from 80% to 35%, WLAN only, 5 minutes email sync, ssh reply instant after all that time. After reenabling, touch to wake is restored and battery went down 1% only in the last hour (and no new ssh connections as previously).

Re: Overzealous suspend everything watchdog [workaround included]
 

Most of the time (95%), I can connect straight away, screen off or on through ssh over WLAN.

I'm using a Draytek 2820Vn router.

I've also noticed that if I stop the WLAN connection on the Jolla mid-session, and then reconnect, the ssh resumes without having to login again, no broken pipe errors. I've never noticed that before in my (limited) experience with the n9/n900/other PCs in the past when I've lost a network connection.

Edit: re: battery life. I only suffered a 20% loss in battery over 26 hours, with low usage, but with WIFI active and sim card inserted, and tohd disabled.

Re: Overzealous suspend everything watchdog [workaround included]
 

Works for me out of the box too. Thats why Im suspecting wlan ap's. But either way there is a way to disable suspend if needed.

Re: Overzealous suspend everything watchdog [workaround included]
 

Works for me also as I use a fuse ssh-fs to transfer files from my mac and regularly just ssh in at will.

Router at home and work are both avm fritz!box (7390 & 3390).

Re: Overzealous suspend everything watchdog [workaround included]
 

After I disabled the TOHD my battery life has been excellent... I used to hook it up to charger every night after a days usage, with 30%...40% juice left, and now I only hook it up every other night or so... forex. now I have 77% left, and I charged it yesterday night, so it's been running about 35 hours straight noww...
(granted, I only have made one call of about 22min, and less than 20min of surfing...)
Howeveer it's been in WLAN all the time I've been in the house, and any random time I ssh into it it works flawlessely :D
All in all, I am very pleased in that aspect :D

Re: Overzealous suspend everything watchdog [workaround included]
 

Do the following:
- Unplug Jolla from USB/wall charger
- Login via WLAN to Jolla from PC
- Run top
- Hands away from keyboard

EXPECTED OUTCOME: Top refreshes every few seconds
ACTUAL OUTCOME: Top output does not refresh. It appears as if it hung. Pressing a key refreshes it.

This happens on every other Android device out there too. And on the HP Touchpad.

The device awakens every time there's some traffic (and keeps awake for a few seconds after that because of some Android design failure), so things like sshfs will work. But it will not wake for SIGALRMs, select() timeouts, and other common POSIXy things. It is unusable as a pocket computer.

If your device still refreshes then some other device on your network is throwing unicast traffic to your Jolla, keeping it awake. But I doubt this.

Re: Overzealous suspend everything watchdog [workaround included]
 

Allright, just tried this, altough I did not login via USB, but via WLAN.
And lo and behold!, it works just as you describe. If I do not touch anything it will not refresh. If I touch a key, it will refresh.

Also, if I ping it from another device, it starts to refresh the top listing.

Re: Overzealous suspend everything watchdog [workaround included]
 

Yep, I meant WLAN -- fixed the post.

Re: Overzealous suspend everything watchdog [workaround included]
 

OK, so you argue that as the wakelock taking process is gone, now the device should revert back to the non-responsive state, right?
I tried that command, logged off and logged back on, and now when I launch "top" it does refresh continiously... How is that?

Re: Overzealous suspend everything watchdog [workaround included]
 

Well, no idea. I might be completely wrong.

Re: Overzealous suspend everything watchdog [workaround included]
 

With just ssh in top does indeed pause for me. I'd not noticed this before. I presume it's because I usually have an sshfs running too as that's the only semi-nice way I can get to it from my Mac.

Re: Overzealous suspend everything watchdog [workaround included]
 

After 8 hours off charger the SbJ is at 60% with the suspend disabled which is not bad, so I think I'll keep it like this. Definitely better than the Z10.

The only thing I miss is the double-tap to unlock, especially now that the phone wakes up instantly. Before it took a couple of seconds to wake up, to the point that I pressed a second time resulting in the phone responding to both events and waking up for a moment before sleeping again.

Re: Overzealous suspend everything watchdog [workaround included]
 

I've been reading the Android kernel source a bit (I'm an Android hater, not a hacker, and would prefer to keep it that way ;) -- besides I feel like puking every time I read some of the hacks).

Seems that user-space wakelocks are not reclaimed when the process dies -- and thus they are prone to being leaked (a dubious decision if you ask me). But then this means that the approach in the first post is a valid way to take a permanent wake lock:
And indeed I've checked and it does the same my trivial module did. If you do the above command, the kernel is not suspending. You can list current wakelocks in /proc/wakelocks.

I have no idea why it doesn't work for szopin -- maybe we are talking about two different problems here? What's exactly the difference with mcetool "suspend policy"? I am quite sure that with an active wakelock it does not suspend at all.

Besides, with the wake_lock, double tap to unblock still works.


Yeah, well. I discovered this the moment I logged in via ssh to the device. Not only it was a surprise to me: the fact that no one else mentioned this was also a surprise. Opportunistic suspending is terribly annoying if you're trying to do anything useful with the device -- background applications basically get SIGSTOP'd the moment you turn the screen off. Computations are interrupted, timeouts are ignored, and writing daemons becomes hard.

If I had known beforehand that the Jolla device used opportunistic suspending, I probably would never have bought it. I know they probably had no choice....

The good news is that I was using "permanent wake_lock" mode to workaround this and that it had 'acceptable' battery life when compared to the stock (with tohd running) software.
The bad new this is that improving the battery life when under "permanent wake_lock" mode might be very well impossible. The kernel is full of hacks (Qualcomm-made no doubt) that just assume the device is going to spent most of its time suspended. There are bazillions of sub-second timers everywhere, in the kernel, the Android side...

Re: Overzealous suspend everything watchdog [workaround included]
 

Never said it doesn't, just thought I'd mention it as had to run and my question on IRC had no other answers at this point.


Interesting, need to compare battery consumption in both cases, though expecting the same, btw when Jolla is acting as a hotspot (without sim, just for ssh) I have no problems connecting to it after some time (whether new connection or resuming old), but battery consumption is even worse than suspend and on router.

Can you share your workaround, want to see which way is best to have (and the least battery hungry)

Re: Overzealous suspend everything watchdog [workaround included]
 

Ah, I see. Well, echo asdf > /sys/power/wake_lock is basically "my" workaround too. I was just too stupid to figure out that there was a way to create these wakelocks from userspace. From what I see, a userspace space wakelock should be the same as a kernel one (except the type is forced to WAKE_LOCK_SUSPEND but this is what we want...).

---------

So, I've found the difference.

Seems that Android has a middle state between suspend and normal that is called "early-suspend". "Double tap to unlock" seems to be enabled during early-suspend, and thus will only work when the device is either suspend or "early-suspended".

Having a wakelock prevents the device from suspending when the screen is off, but it will not prevent it from going to early-suspend, it seems. So double tap to unlock works and I presume some peripherals are put in a low power mode (dynpm on Android is basically non-existant it seems).

Using mcetool --set-suspend-policy=disabled disables BOTH suspending and early-suspend altogether. Therefore, double tap to unlock does not work. However, there is a third method, mcetool --set-suspend-policy=early, which enables early-suspend only. I suspect this third method will be exactly the same as taking a wakelock.

Re: Overzealous suspend everything watchdog [workaround included]
 

Tomorrow's question, does the SbJ have better battery life with --set-suspend-policy=early?

So far I'm pretty much happy that it made it for 14 hours with 15% remaining with suspend completely disabled.

Re: Overzealous suspend everything watchdog [workaround included]
 

bah, today's experiment failed miserably. Evdev touch stuck on 100% processor usage eating up all my battery. I'll try again tomorrow

Re: Overzealous suspend everything watchdog [workaround included]
 

Similar here. Early option seemed as battery efficient as suspend enabled, connected ok after 1h (1% battery drain in that time), after 4h too although had a strange behaviour in mc (2 seconds responsive, then ~5 seconds unresponsive, back and forth, mostly visible while scrolling in big directories), extra 2% battery rundown by this time. In the morning couldn't connect. After waking the device up it showed ~70%, not sure how but 20 minutes later checking emails/web browsing it was already down to 30%, evdev touch, msyncd and timed-qt5 in htop seem to have spikes in activity going 100% on both processors (actually over 100%/200% if you count all percentages of the processes, bug in htop?), don't remember such behaviour previously, could be related to the battery rundown. Needs more testing

Re: Overzealous suspend everything watchdog [workaround included]
 

early suspend policy seems viable. After around 14h of my regular use I'm still at 55% which is pretty good

Re: Overzealous suspend everything watchdog [workaround included]
 

I have had good experiences for ssh responsivines by changing the sshd clientalive -parameters.

in /etc/ssh/sshd_config i uncommented following parameters, and changed interval to 15 secs.

ClientAliveInterval 15
ClientAliveCountMax 3

(This helps only when ssh opened to the phone, but it seems to keep e.g. all qml timers running)

Re: Overzealous suspend everything watchdog [workaround included]
 

Do you mean when using a ssh _client_ on the phone?

Otherwise it would be weird -- because by changing ClientAliveInterval on the phone it is actually the phone the one that should be sending ClientAlive messages. But the phone is suspended! So it would do nothing at best and at worst it would cause the phone to drop the connection when it awakens....

Note that changing mcetool settings survive a reboot (wakelocks do not).

Re: Overzealous suspend everything watchdog [workaround included]
 

I remember reading this back when the n9 came out and sending it to my android-loving friend to show him how google's heavy-handed approach to power management isn't the only way. It's a bit disappointing to see that Sailfish is so androidy on the sbj. Does that mean it's basically an android kernel?

Re: Overzealous suspend everything watchdog [workaround included]
 

Yes, that's the case. At least, from init onwards it is more or less a GNU system (systemd based...) albeit with an Android chroot where the Qualcomm binaries are run.
Which is different from the Aliendalvik one. Effectively, the Jolla device contains two separate Android userspaces plus a glibc one :D.

Re: Overzealous suspend everything watchdog [workaround included]
 

By the way, I've not been able to reproduce that issue, either with wakelocks or by using mcetool. I am now using the mcetool 'early' setting and have had no "runaway" processes so far.

Battery life is bad (~1 day with light usage) albeit it is also similarly bad with stock settings (I assume tohd bug, but I'm not certain...). I still have no SIM card inserted.

Re: Overzealous suspend everything watchdog [workaround included]
 

that issue is completely unrelated, I didn't mean to present it as a sideffect. It had happened to me once again days before I started playing with standbydedness.

BTW battery life is not bad here, sim inserted, 3G always on, gtalk connected, light usage (most of the day near wifi, one or two short calls, around 15 minutes of 3G browsing, no wifi browsing today), suspend-policy early and after 12h I'm still at 68%

Re: Overzealous suspend everything watchdog [workaround included]
 

Battery may get better if these 'optimizations' for the Qualcomm SoC that were mentioned before the tohd fix come about. If it gets up to n9 levels with early-suspend, I can see a lot of people switching.
Totally loving everything being Qualcomm's fault, by the way.