KoReader's suspend problem on Kobos

[embryo]

Originally Posted by NiLuJe

Note that current versions of KOReader now have native shutdown and light toggle options.

I'll have to play with it to see if I can make the scripts work with that too...
The version of Koreader I use works very well and there is not a "real" reason to update it, but then again ... who needs a "real"reason )

[Ken Maltby]

Originally Posted by NiLuJe

Note that current versions of KOReader now have native shutdown and light toggle options.

The shutdown hack used the KSM PowerOff, and the user could have their own PowerOff image/html page. The reader menu Home Icon exits KOReader, to the launching program, but the device is not powered off, unless that is something really new.

Luck;
Ken

[NiLuJe]

@Ken Maltby: Yup, really new .

[Ken Maltby]

Ok, I'm still on 389, I'll give 396 a try. I tried the 389, and it works holding the power slide switch for 3+ seconds. It even gave me my KSM PowerOff page, but slapped an info box with "Powered off." on top of my image. (I'll have to comment out the "show" command.) One thing though, it requires fewer pokes to just use the Home Icon and return directly to KSM then poke the Poweroff selection.

Luck;
Ken

PS; comment out: frontend/ui/uimanager.lua line 70, to drop the Info box.

[xor_]

After the recent changes, I get a segfault on my H2O when suspend kicks in (or maybe when waking up?).

This is with build 411. The same with several recent builds.

from crash.log:

[05/30/16 @ 23:13:36] Kobo Suspend: BEGIN!
[05/30/16 @ 23:13:36] Kobo Suspend: Current WakeUp count: 246
[05/30/16 @ 23:13:36] Kobo Suspend: Asked the kernel to put subsystems to sleep
[05/30/16 @ 23:13:38] Kobo Suspend: Waited for 2s because of reasons...
[05/30/16 @ 23:13:38] Kobo Suspend: Synced FS
[05/30/16 @ 23:13:38] Kobo Suspend: Wrote WakeUp count: 246 (0)
[05/30/16 @ 23:13:39] Kobo Suspend: Asked to suspend to RAM... ZzZ ZzZ ZzZ? (0)
[05/30/16 @ 23:13:40] Kobo Suspend: END! (WakeUp count: 247)
Segmentation fault

[Ken Maltby]

I never understood how the "WakeUp count" idea was supposed to work.

Luck;
Ken

[xor_]

Adding a crash.log with debug enabled. It seems to be time-related?

I close the reader with the magnet mechanism, and let it sit for a while. Then open it. A couple of times it came back (after only waiting for a relatively short time), maybe the time was too short for the suspend to actually come on? The crash only occurs after the last open (when I had let it sit for some longer).

Could it be that the new suspend interferes with the magnet cover mechanism?

[NiLuJe]

There's a PR open on GH (can't remember the #ID right now) for that one. We probably need a proper stack trace to figure this one out, something which has proven to be a bit tricky to actually get on Kobos...

[xor_]

Originally Posted by NiLuJe

There's a PR open on GH (can't remember the #ID right now) for that one.

Ah, found it. Somehow I'd thought that was an Android issue because of the "force close" lingo.

We probably need a proper stack trace to figure this one out, something which has proven to be a bit tricky to actually get on Kobos...

--verbose on this, please. (Even though I figure that since you have an H2O, you would have done it by now if I could do it. )

[NiLuJe]

@xor_: Basically can't for the life of me get the kernel to coredump automatically. Which is rather annoying, since this appears to be a semi-random crash and a PITA to trigger in any case.
And on top of that, coredumps generated by gcore appear to be borked...

So my cheap workaround would be attaching gdb to luajit in a tmux session, and making sure you're in a position to re-attach on crash (i.e., usbnet). Binaries for all that are available in there.

(Because *that*, at least, works to get useful stacktraces ).

EDIT: For ref., this is the GH issue we're talking about.

EDIT²: And my comments on stacktraces were in this one.

@xor_: Good point on its name, I just fixed that.

[jonch919]

What's working for me on my Kobo Aura H2O is using the suspend.sh script from pbchess.
Download latest build from here: http://forum.vlasovsoft.net/viewtopic.php?f=8&t=537

Only edit I do is to comment out the wifi line, like this:

#. $ROOT/wifi_off.sh

Replace the suspend.sh file in the koreader directory with this file from pbchess. (Preferably keep the other file as a backup by renaming it)

You will have to replace the file again after every update as it will be overwritten with the original file.

[Alan_S]

Interesting thing I just found out on this problem:

Yesterday I had 100% battery, today when I started reading it dropped to 72%. Well, that isn't that interesting. But, interesting is the clock.

There was "lost time", i.e. clock was about 3 minutes late(r) than it should. Like something influenced clock also. Like it crashed, or went in some processor intensive loop.

On the surface everything looked normal, I started reader just fine, there was no obvious problems with reader except lost battery and clock time.

[Alan_S]

Originally Posted by church mouse

4. Finally, but this may be completely unnecessary, I extended to "12" from "10" the time in the line for UIManager:scheduleIn in frontend/device/generic/device.lua

At the moment this looks like best solution to this problem.

More info you can find here: https://github.com/koreader/koreader...ment-246927411

I just changed setting on my device and will monitor how things go from now on.

[Ken Maltby]

"Oldhasbeen" has added a post to that thread, that describes the state of his research and indicates that the change of "koreader\frontend\device\generic\device.lua

UIManager:scheduleIn(10, self.suspend)

to

UIManager:scheduleIn(15, self.suspend)"

allows for "True Sleep", in almost all situations. He has also provided some data that helps understand the final scenario that can cause power drain.

So, it looks like the change to 15 may fix the suspend for Kobos issue, and the final problem/scenario is described and can be avoided, until a permanent fix is merged into KOReader.

Luck;
Ken

[jscris]

Originally Posted by Ken Maltby

"Oldhasbeen" has added a post to that thread, that describes the state of his research and indicates that the change of "koreader\frontend\device\generic\device.lua

UIManager:scheduleIn(10, self.suspend)

to

UIManager:scheduleIn(15, self.suspend)"

allows for "True Sleep", in almost all situations. He has also provided some data that helps understand the final scenario that can cause power drain.

So, it looks like the change to 15 may fix the suspend for Kobos issue, and the final problem/scenario is described and can be avoided, until a permanent fix is merged into KOReader.

Luck;
Ken

I made that change when it was first suggested and have still had the power drain on the Aura One. I have not, however, completely drained the battery and recharged, so there may be something else going on. I'm losing about 18% over 9 or 10 hours, waking it periodically to read then letting it auto suspend. This happened both last night and the night before with the change to 15 implemented. I have the latest firmware and am using File Monitor.