Autoshutdown not initiating when already in sleep mode on Kobo Glo #7994
Comments
|
The wakeup appears to get scheduled properly for 6 minutes after suspension, but it apparently never fired. I can confirm that this works properly on an H2O and a Forma, FWIW. If you have shell access to the device, what does |
|
Also, we need over 15s of logs after the wakeup to see the results of the wakeup guard checks ;). |
I haven't verified that it's still working and I probably won't do so today, but it's been a couple of months since anything changed in that direction and I verified after #7624. |
I checked when the device is awake (so I have wifi access and can ssh into it). Do I need to check /proc/driver/rtc when it is asleep using the serial connection, if that is even possible? Was the full error.log sufficient? here is a new one from this morning without any removing Nickel can shutdown while sleeping just fine btw, so it isn't a hardware limitation. |
It wouldn't be sleeping, now would it? ;-) Just have some script write a timestamp every (x) second(s) and you'll see well enough whether it's actually sleeping or not. |
Kinda weird behaviour if you ask me, I don't know what the sleep modes exactly do, but it keeps running the script for 20 seconds after going to sleep and then stops. I also logged /proc/driver/rtc while autosuspend kicks in
rtc.logAgain the kobo is running the script 10 more seconds after losing wifi, but no alrm_time is set and it never wakes up again until I wake it up again. |
That's intentional. The modules need time to unload properly etc. or suspend will fail. (At least on some Kobos.) |
|
Well, the alarm being stuck @ epoch is a strong hint that something is indeed failing to even set the alarm. (nickel itself should have set it a bunch of times before we even start. Which reminds me: how are you booting KOReader?). I suppose it could be a strange Glo-specific quirk (ping @poire-z ;)), or faulty hardware? Does the |
|
(I have a Glo "HD" - and even if I don't use KOReader's own alarm stuff, I have some private hacks that use it - writing into /sys/class/rtc/rtc0/wakealarm - without issues.) |
|
Oops, forgot that there was a non-HD Glo ^^. It's Mk. 4, so I'm pretty sure we'd have heard about it before if it were a generic issue on that generation ;). |
which apperently is due to /sys/class/rtc/rtc0/device/power/wakeup not containing "enabled" but I cannot write to it. seems to be due to a faulty check here https://github.com/kobolabs/busybox/blob/kobo/util-linux/rtcwake.c#L69 so it appears to be due to a faulty busybox, but I am not sure how Nickel does it then. I am no C expert and I don't know how to recompile the busybox for the Kobo and the original link on mobilereads is dead. Maybe I can open it up in a hex editor and change the location of the checked file. And yes, I have a non HD hand me down Kobo Glo ;) |
|
Neither we nor nickel use the busybox applet to do it, it was just supposed to be another way to do it to triple-check, but, alas, it indeed doesn't work without patching. |
|
Ah okay thanks, so I patched the binary, and it successfully goes to sleep with: But then it freezes? the frontlight stays on but the device is not responsive. When I turn it off using the slider for 10 seconds I can boot again. Maybe this is all just a bit too much to ask from such an old device... |
|
Not quite sure why we can't wakeup from that, but I can confirm that ;p. Unless you break suspend by keeping the USB host controller busy (i.e., I was in USBNet mode at the time): EDIT: Also, the |
|
Just checked the all the available modes of rtcwake, A well, I'll guess I will resort to Nickel on vacations. |
|
I figures out why it was freezing, apparently you cannot go to sleep when WiFi is enabled (which it was due to my SSH session). The following script works: it produces: This suggests the bug is in KoReader after all, I almost never have Wi-Fi enabled so I guess it can't be that. Edit: Apparently it is done in koreader-base and the comments say it is done the same way as rtcwake, which is odd |
|
Oh, right, the good old "kernel implodes if you suspend with wi-fi on", good catch ;). You still haven't posted the before/after status of And it's indeed irrelevant as far as KOReader itself is concerned, as we kill Wi-Fi much earlier than we try to actually suspend ;). (And a hang on suspend wasn't your original issue: no alarm being set is ;)). |
See #7994 (comment) |
Not sure when |
|
AFAIK, the alarm should stick, even if fired (e.g., it should be visible there). Let me double-check on an H2O. |
|
Yup: Shot in the dark: it's possible the battery is dying, making reading the rtc unreliable, while still allowing it to be set & fire (mostly okay). Unfortunately, we rely on a sane RTC, and being able to read it in order to validate the alarm. |
|
My battery is less than a year old but not stock (I put a 700mah in) so I don't think it's dying. Thanks for your help, a pity the RTC date not being set messes things up. I'll maybe try to hack koreader to do what I want. |
|
Nickel does an extra ioctl specifically aimed at checking the RTC voltage ( |
|
I injected the following code into logger.info("Kobo suspend: Bart edit")
epoch_before_sleep = os.time(os.date("!*t"))
seconds_sleep = 60 * 30 -- 30 minutes of sleep
logger.info("Kobo suspend: suspending, epoch " .. epoch_before_sleep .. " awaking in s: " .. seconds_sleep)
os.execute("/mnt/onboard/.adds/busybox_new rtcwake -m mem -s " .. seconds_sleep)
-- When we resume here, we either used the slider or the rtcwake fired
epoch_after_sleep = os.time(os.date("!*t"))
sec_asleep = epoch_after_sleep - epoch_before_sleep
if sec_asleep > seconds_sleep - 30 then -- we slept so long, we awoke due to rtcwake, 30 seconds of leeway
logger.info("Kobo suspend: Shutting down, sec asleep: " .. sec_asleep)
os.execute("/usr/local/kfmon/bin/fbink -S 4 -m -M shutdown")
os.execute("/bin/sleep 5 && poweroff -f")
else
logger.info("Kobo suspend: woke up due to slider, sec asleep: " .. sec_asleep)
end |
We've had a couple reports over the years of broken alarm reads on old NTX boards (in... every sense of the word; this only seems to affect old i.MX RTCs, true, but more specifically really old devices, with possibly dying batteries). e.g., koreader/koreader#7994 & koreader/koreader#10996 While there *is* an ioctl that is supposed to help with this sort of stuff by reporting on the state of RTC's battery voltage, in my own testing on much less broken RTCs, it was extremely unreliable (especially when it matters most, i.e., right after a wakeup), so, that's kind of a no-go. Thankfully, when this occurs, the returned alarm is *extremely* obviously bogus: `1`, as in, Epoch. TL;DR: Just ignore such return values and assume the alarm did indeed fire properly, we already validate against both the task and the current time, double-checking the actual alarm is just a defensive and pedantic guard against... something... setting alarms behind our back, which should never really happen in the first place, least of all on the affected platform (Kobo) ;). Also actually implement honoring WakeupMgr's character device selection, in case we ever need to actually use something other than rtc0 ;).
Issue
Auto-shutdown does not work when the device already is in sleep mode. It does not matter if the sleepmode was initiated by the user or by auto-sleepmode. My battery sucks so that's one reason I would like this to work.
Steps to reproduce
Set auto-sleepmode to 5 minutes, and auto-shutdown to a higher value (I use 0.1 hours == 6 minutes for testing)
The device will now never exit the sleep mode to go to a full shutdown, thus using a higher sleep current and draining the battery.
crash.log(with dev mode and verbose logging on)My device is set to auto-sleep after 5 minutes, and to auto shutdown after 0.1 hours. I stopped touching the device at 21:22, the device correctly went to sleep at 21:27, but never woke up at 21;28 to shutdown completely. I woke up the device at 22:15 to get this log contents.
crash.log (snipped, full log down below )
Please let me know if any more details are necessary, I have the emulator running and am able to trying to debug. But this project is a bit too big to wrap my head around to do it myself.
full crash.log
The text was updated successfully, but these errors were encountered: