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> .

[NiLuJe]

Random lightbulb moment: If any of you can still reproduce this fairly easily, some other thing to try would be to switch to the performance CPU governor.

If it magically fixes it like Wi-Fi & being plugged in did, it might be possible to alleviate the issue by keeping the usual governor (interactive, IIRC), and just raising the minimum cpufreq step so the CPU doesn't ever clock down too low. (Some ARM SoCs have weird quirky bus freq issues and interactions, this might help with those, barring a real kernel/dts fix).

[melyux]

@NiLuJe I can try that, I'll do anything to be frank... I'm afraid to even adjust the frontlight/warmth on this thing because Koreader crashes and the Kobo restarts with like a 10% chance every time I do it. I thought it might have been the gesture manager since I only adjust the lights using gestures, and it once restarted while doing something else too (but every other time has been the frontlight), and once refused to resume from sleep until I force rebooted it with the button.

Would this workaround make the battery life much worse? I noticed Koreader on Libra 2 drains the battery a lot, even when sleeping.

[NiLuJe]

It'll affect battery life, sure. How much, I can't say.

That said, since you mentioned extra drain during sleep, that feels like a separate issue (possibly hardware).

Do you use a sleep cover?

[melyux]

It'll affect battery life, sure. How much, I can't say.

That said, since you mentioned extra drain during sleep, that feels like a separate issue (possibly hardware).

Do you use a sleep cover?

Well it's just to try temporarily. Let's give it a try. As for the battery, I'll hold off until I can confirm some drain besides a hunch, so scratch that. No cover.

Here's an interesting question for you: this thing is still within its return window, and I'm not interested in using anything but Koreader. Is there any hope for this thing, or would you pick some other device if you wanted to get something that works better?

[NiLuJe]

Oh, definitely throw it in a fire and get something else ;).

Right now, I'd go so far as recommending a PW5 if you can get one in the JB range...

Otherwise, the Sage has... issues (specifically, horrendous power efficiency), but at least it's usable and fast, and we actually had ways to alleviate some of its issues on our end (it is my daily driver, FWIW).

[melyux]

I hear you. Going to see if I can find any Signature edition PW5 units locally that are still on the old jailbreakable firmware. I thought Sage was a complete clown show, but the Libra 2's taken that spot? Sucks, this thing and its upgradable SD card and screen and speed are otherwise really great. Didn't know things were that hopeless...

[NiLuJe]

I'm not even sure it's using an sdcard, FWIW. That'd be the Nia (possibly also suffering from hopeless kernel issues).

[Frenzie]

Homeless kernel? Maybe we're nice enough to offer it a roof? 🤣

[NiLuJe]

On mobile ;p. I almost left it as is when I caught it ^^.

[melyux]

Libra 2? Definitely uses an SD card. Dunno about the sage

[NiLuJe]

Oh, right, yeah, tropicalized/glued mess, now I remember ;). Yeah, SD card!

[NiLuJe]

#10713 mentions that the boot spinner may be a fine way to trip this.

I remember that it definitely was in the worst conditions possible (i.e., with NanoClock pushing updates in //, you'd be lucky to actually get a device to successfully boot at all), so it would stand to reason that the way we rerun the spinner might more easily expose the issue too...

[NiLuJe]

Let's hope #10771 did the trick ;).