Kobo libra 2: koreader crashes when jumps across epub table of contents

[huronhorn]

• KOReader version: latest nightly (build 48)
• Device: kobo libra 2

Issue

When i try to jump across chapters (chapter 1 to 2 back to 1 etc) in table of contents, koreader crashes, and my libra goes to restart itself. Note that this doesn't happen everytime but most of the time, and also jumps across internal links on epub resulted on the same problem.

Steps to reproduce

Open epub -> open TOC -> tap random chapters or internal links back and forth -> crash

Any help would be much appreciated, thanks!

[crash.log](https://github.com/koreader/koreader/files/7469663/crash.log)

Edit: ive attached the crash.log

[NiLuJe]

A look at the crash log as the issue template suggests would be a good start ;).

[gerhaher]

Happens to me too.

crash.log

[Frenzie]

At a glance I only see what looks like clean exits?

[gerhaher]

For me the device freezes and after a few seconds restart.

Do you want a verbose log too?

[Frenzie]

Could be helpful, but a timstamp might help too. For example, one thing I did spot was this but it seems like it was probably too long ago?

11/03/21-17:21:13 INFO  opening file /mnt/onboard/BOOKS/Non-Fiksi/hysteria 3.pdf
11/03/21-17:21:14 INFO  setting zoom mode to pagewidth
11/03/21-17:21:18 INFO  setting zoom mode to contentwidth
11/03/21-17:21:24 WARN  Running low on memory (~19%, ~96.80/496 MiB), evicting half of the cache...
11/03/21-17:21:57 WARN  Running low on memory (~19%, ~98.19/496 MiB), evicting half of the cache...
Killed
!!!!
Uh oh, something went awry... (Crash n°1: 11/03/21 @ 17:22:07)
Running FW 4.29.18730 on Linux 4.1.15-00629-g706eeae6abf (#25 SMP PREEMPT Mon Sep 6 15:35:16 CST 2021)
Attempting to restart KOReader . . .
!!!!

[gerhaher]

Here is a verbose log:
crash.log
When the device restarted this time it started with the 'Choose language'-screen (Then I chose my language whereupon nickel's home screen appeared, and then I could happily return to Koreader)

[NiLuJe]

Is it actually the right log/timestamp? Because, again, there's nothing in there, it's the first 21 seconds after a startup and that's it :s.

[NiLuJe]

So, next question: how are you launching KOReader?

[NiLuJe]

(And, next next question: watch over it in a Wi-FI SSH session, maybe?).

[gerhaher]

Is there anything in this one?:
crash.log

Launching KOReader with NickelMenu

[huronhorn]

Here's my verbose log. The steps i reproduce the error is still from jumping across epub toc. Anyway, is it possible that the problem didn't get logged because this bug resulted in the device itself restarted, all the bugs i previously faced just resulted in koreader crash (bomb screen).

crash.log

[NiLuJe]

If it's actually a device crash, there's nothing much we can do about it (and, yeah, you won't find anything in the log).

I'd recommend:

• Updating to the latest FW released a few days ago, it contained a kernel update, so, who knows.

• Checking over system health in a Wi-Fi SSH shell, see if you can catch a pattern (or an actual crash).
  Running klogd and then following the logs with logread -F might be helpful.

FWIW, when a Mk. 7 device crashed because of a kernel issue, it did not restart on its own.

Which either means this is something slightly different, or that the kernel watchdog is set up differently and/or actually does its job.

[poire-z]

There was libcrengine.so mentionned in the debug bits after a SIGSEGV in one of the crash.log above I looked at this morning (on a book about people and computing, that I couldn't find to download on the web). So, a scrambled copy (with check that it still crash once scramble) could help finding if it's crengine related.

[huronhorn]

Just out of curiosity, I've installed koreader on my libra 2 to by replacing koreader nightly files to ocp zip, then copy all the ocp (with nightly koreader inside) to my kobo. Bcs afaik koreader version on latest ocp package didnt support libra 2 yet.

Is it possible that this caused the bug?

[Frenzie]

Nah, that's just the update procedure. ^_^ But depending on if you updated your nightly since, it might be missing a few further optimizations.

[gerhaher]

I'd recommend:

Updating to the latest FW released a few days ago, it contained a kernel update, so, who knows.

Checking over system health in a Wi-Fi SSH shell, see if you can catch a pattern (or an actual crash).
Running klogd and then following the logs with logread -F might be helpful.

The FW didn't help.

And about the SSH shell: "Running klogd", what's that? In what way should I modify these instructions #6582 (comment)?

[Frenzie]

klogd is for dealing with the kernel log, probably just some busybox symlink (busybox is typically used on embedded systems; it's an all in one thing to provide basic system tools, unless @NiLuJe means he compiled it himself and provides a build of the real deal)

[NiLuJe]

And about the SSH shell: "Running klogd", what's that? In what way should I modify these instructions #6582 (comment)?

Just run klogd before logread -F in step 7. ;). (And stop there, of course ;p).

---

@Frenzie: I think the stock kobo busybox build bundles the klogd applet, but I know KoboStuff does, and SSH > telnet anyway ;).

[gerhaher]

Could the problem be related to Wifi?

When I tried the wifi SSH shell logging I failed to trigger the issue.

So then I turned off the wifi - now it was back. And then I reconnected to wifi, and again I couldn't trigger it.

In other words:

Wifi connection: no "crash"
No wifi connection: "crash"

So, does that make any sense?

Maybe @huronhorn can confirm?

[NiLuJe]

No, but it's vaguely similar to my (very) sporadic Forma crashes: I could never replicate 'em with Wi-Fi on.

What's likely happening is that the simple fact of the Wi-Fi chip being alive and kicking affects the hardware in fun and mysterious ways (possibly related to power management), and simply papers over whatever the root cause is.

[huronhorn]

You were right lol, didn't think with wifi turned on the bug just gone @gerhaher

Anyway this is my results:
With wifi off: consecutively jump across chapters, and in 2nd or 3rd try (consecutive), the bug happened koreader freezes and libra restarts.

With wifi on: same thing, but koreader didnt crash and my libra didt restarts (well i tried at least 10 times consecutive jumps across toc) and it works fine

[poire-z]

(Feels like my various freezes on my GloHD, actually more like auto-power-off, when viewing some images, which do not happen when it is plugged via USB to a computer, cf #5916 and koreader/koreader-base#1309 (comment) ...)

@NiLuJe : I once looked for it, but can you confirm there is no way to tweak/force voltage tweaks via /sys/* /proc/* , that we could enable when doing stuff and disable when going idle ? Or is it all hardware internal stuff and there's nothing we can do from linux ?

[NiLuJe]

What concerns me is that it actually reboots here, it doesn't just hang like our usual nxp or mxcfb kernel snafus...

And, no, there's no actionable dvfs on newer devices (there might be on your Glo, though).

[huronhorn]

Apparently the bug didn't trigger even without wifi (on) connected to a network. Anyway The book im currently reading has many images/diagrams internal links in it, and my adhd brain can't help but to tap them, so, i guess ill keep my wifi turned on for the time being

Is turning the wifi on all the time has significant cons to battery life?
Edit: found some answers (https://www.reddit.com/r/kobo/comments/g7h81q/some_encouraging_stats_about_battery_life_with/)

[gerhaher]

Yeah, I can confirm what @huronhorn says. As long as the "Wi-Fi connection"-box is ticked - whether or not there is a real wifi connection - the problem is gone.

Good to know, if this problem will live on.

[NiLuJe]

Ironically, the wifi chip is probably the thing having the best power management handling in there, so it might not be too awful ;).

…

On Fri, Nov 5, 2021, 08:14 gerhaher ***@***.***> wrote: Yeah, I can confirm what @huronhorn <https://github.com/huronhorn> says. As long as the "Wi-Fi connection"-box is ticked - whether or not there is a real wifi connection - the problem is gone. Good to know, if this problem will live on. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#8414 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA3KZRGNRDEACTURVWRM2LUKN73ZANCNFSM5HJQBLDA> .

[huronhorn]

Another little interesting finding, it seems like when the device is being charged/plugged in (with wifi off), the bug gone as well. Just like when i have it with the wifi on.

Maybe @gerhaher can confirm?

[gerhaher]

Another little interesting finding, it seems like when the device is being charged/plugged in (with wifi off), the bug gone as well. Just like when i have it with the wifi on.

Maybe @gerhaher can confirm?

Yes, confirmed.

[NiLuJe]

I think I forgot to mention, that, much like on the Clara HD, disabling the 8bpp switch may also alleviate the issue (to some extent).

(In the FM, Tools > More tools > Developer tools > Something something 8bpp switch (:D)).

(The downside is a performance hit, but you don't lose dithering on those devices, because hardware \o/).

[NiLuJe]

Might also require hasReliableMxcWaitFor = no, c.f., the cross-ref above.