Kobo Clara colour standby bug?

[Howchie]

Device

Kobo

KOReader version

2025.04

Model and firmware version

Clara Color

Issue description

When auto standby is enabled, there's a constant stream of errors saying "Cannot write mem to file /sys/power/state: Operation not permitted". I've looked through the code as best I can - it seems like identifying the power states and checking permissions are not syncing up? Koreader is assuming that the standby succeeds because the standby timer increments in the system statistics in an expected way, but I suspect the device is not actually in standby (or if it is, there's something wrong with the check).

Steps to reproduce

1. Go to '...'
2. Click on '...'
3. Scroll down to '...'
4. See error

Log

Additional information

No response

[OGKevin]

If I forget to manually put the device to sleep, I wake up the next morning to a dead KLC. It fails to enter standby and also fails to power off after 1 hour — which are the settings I’ve configured.

Something keeps running and drains the battery.

I’ve seen similar log entries.

If I do manually put it to sleep, then after 1 hour it correctly powers off.

---

Will do some digging when I have time to kill.

[Howchie]

My color dies much faster than my clara bw, both have had koreader from day 1. The colour definitely needed a couple of full drains to calibrate but even now it will drop 2-3% per session and about the same overnight (hence why I hoped autostandby would work). Edit: OK so the same error message shows on my Clara BW neither seems to be able to use mem as a power state (unless the permissions issue is something that can be fixed)?

[FabioEight]

I notice the same errors on my Kobo Libra Color

06/21/25-00:42:59 INFO  WakeupMgr: scheduling wakeup in 2 -> 1750459381
Cannot write `mem` to file `/sys/power/state`:	Operation not permitted
06/21/25-00:42:59 WARN  Kobo standby: the kernel refused to enter standby!
06/21/25-00:43:03 INFO  WakeupMgr: scheduling wakeup in 58 -> 1750459441
Cannot write `mem` to file `/sys/power/state`:	Operation not permitted
06/21/25-00:43:04 WARN  Kobo standby: the kernel refused to enter standby!
06/21/25-00:43:08 INFO  WakeupMgr: scheduling wakeup in 53 -> 1750459441
06/21/25-00:43:44 INFO  WakeupMgr: scheduling wakeup in 16 -> 1750459440

[NiLuJe]

You will see a few standby failures in your log, that's perfectly normal (e.g., if the standby timer fires too close to a screen update).

[Howchie]

You will see a few standby failures in your log, that's perfectly normal (e.g., if the standby timer fires too close to a screen update).

It's basically a continuous stream of logs the entire time the device is active (not asleep).

[NiLuJe]

That's slightly more unexpected :D.

I've seen the powercover completely break suspend/standby on the Sage, but I'm not aware of such quirks on the mtk devices.

Perhaps Bluetooth shenanigans?

See if a full restart helps?

[OGKevin]

Reboot is a temporary solution.

There is also a scenario when you wake the device up, it immediately goes back to sleep.

Next to this, after wake-up, the G sensor and backlight are broken. The device refuses to turn on the backlight at koreader’s request, and G sensor events are either no longer detected by koreader or something else.

So essentially, if the device goes to sleep with koreader running, you must reboot to get G sensor and backlight.

I suspect some "assumptions" that koreader makes aren't true on MTK.

I'm not equipped at the moment to provide proper debug info 😔. Can only provide experience information.

[NiLuJe]

There is also a scenario when you wake the device up, it immediately goes back to sleep.

I'd be interested in verbose debug logs for that one ;). Especially if there are no sleep covers (... or magnets) involved.

Bonus points if you can get matching timestamped kernel logs (via klogd & logread).

[OGKevin]

Why is this closed as duplicate 👀? There are no sleep cover or magnets involved. Nor is the linked issue mentioning G sensor or Backlight?

I can provide logs when I have a min, I have the means to do so now.

---

Right, due to https://github.com/koreader/koreader/issues/13986#issuecomment-3195740525 I presume.

Would be nice to summarize all the diff issues as well.

[Frenzie]

The sleep cover there is just a red herring. The log is the same:

12/03/24-09:43:09 INFO  Kobo suspend: going to sleep . . . 
Cannot write `mem` to file `/sys/power/state`:	Operation not permitted
12/03/24-09:43:12 WARN  Kobo suspend: the kernel refused to enter suspend! 

[OGKevin]

Cool.

Conveniently, I can't seem to make the device reproduce the issue on demand. Will provide detailed info with logs when it happens again during normal usage in the merged issue.

[NiLuJe]

Keep in mind that, as mentioned in... one of these issues (EDIT: Whelp, this one actually, lol), some suspend failures like these are completely expected.

IIRC, the issue here is that it keeps happening, for some reason ;o). The only device where I ever saw something like this was the Sage when the PowerCover decides to break the kernel's PM ;).

[NiLuJe]

If the affected people really really can't setup SSH, running klogd once via the Terminal plugin should do just fine. Capturing the logread output will be slightly more annoying, though, but an I/O redirection could work, e.g., logread > /mnt/onboard/kernel.log

[Frenzie]

That's what I just said a few hours ago. ;-) https://github.com/koreader/koreader/issues/12787#issuecomment-3195840018

[NiLuJe]

That's what I just said a few hours ago. ;-) #12787 (comment)

Yep, just realized that ;).

I'm clearly not entirely awake today ^p^.

[Howchie]

If the affected people really really can't setup SSH, running klogd once via the Terminal plugin should do just fine. Capturing the logread output will be slightly more annoying, though, but an I/O redirection could work, e.g., logread > /mnt/onboard/kernel.log

I'm happy to do it, but what exactly are we looking for? All my logs just show the same could not write mem error that's listed here, and it's been reported here for nearly a year. I've just typed the two commands you listed into "terminal emulator" but I don't know if anything happened

[OGKevin]

I can provide the needed info, just need to get the device to misbehave again.

I changed my whole setup to prevent it to being with, I disabled all timeouts and manaully turn the device off when I'm done with it. So I need to play around with the setup to get it to the state that it was before when this happened often and capture the logs at the time.

So, hopefully I have valid events in the comming days.

[Frenzie]

Don't post here please (including @NiLuJe ;-)