|
|||||||
 |
|
|
Thread Tools | Search this Thread |
09-05-2019, 04:45 PM
|
#31 | |
|
Wizard
  Posts: 1,751
Karma: 730681
Join Date: Oct 2014
Location: Antwerp
Device: Kobo Aura H2O
|
Quote:
Code:
02/01/11-12:22:29 INFO Kobo WiFi: disabling WiFi 02/01/11-12:22:45 INFO Kobo suspend: going to sleep . . . 02/01/11-12:22:45 INFO Kobo suspend: asked the kernel to put subsystems to sleep, ret: true 02/01/11-12:22:47 INFO Kobo suspend: waited for 2s because of reasons... 02/01/11-12:22:47 INFO Kobo suspend: synced FS 02/01/11-12:22:47 INFO Kobo suspend: asking for a suspend to RAM . . . 02/01/11-12:22:47 INFO Kobo suspend: ZzZ ZzZ ZzZ? Write syscall returned: true 02/01/11-12:26:54 INFO Kobo suspend: woke up! 02/01/11-12:27:09 ERROR Kobo suspend: putting device back to sleep, unexpected wakeups: 1 02/01/11-12:27:09 INFO Kobo suspend: going to sleep . . . 02/01/11-12:27:09 INFO Kobo suspend: asked the kernel to put subsystems to sleep, ret: true 02/01/11-12:27:11 INFO Kobo suspend: waited for 2s because of reasons... 02/01/11-12:27:11 INFO Kobo suspend: synced FS 02/01/11-12:27:11 INFO Kobo suspend: asking for a suspend to RAM . . . 02/01/11-12:27:11 INFO Kobo suspend: ZzZ ZzZ ZzZ? Write syscall returned: true 02/01/11-12:29:36 INFO Kobo suspend: woke up! 02/01/11-12:29:36 INFO Kobo resume: clean up after wakeup 02/01/11-12:29:36 INFO Kobo resume: unflagged kernel subsystems for resume, ret: true |
|
|
|
|
09-05-2019, 04:56 PM
|
#32 |
|
Pain in the arse
Posts: 758
Karma: 77856
Join Date: Apr 2013
Device: Kobo Aura One, Kindle 4
|
I'm sure I can learn also from Frenzie. It's the inactivity that drive me mad. Instead of discussing that something is impossible, try it.
|
|
|
|
|
09-05-2019, 05:00 PM
|
#33 |
|
Pain in the arse
Posts: 758
Karma: 77856
Join Date: Apr 2013
Device: Kobo Aura One, Kindle 4
|
Frenzie, it's a stupid four line script. Can you please test it?
Code:
while true ; do
sleep 3
current_date=$(date -Iseconds)
echo "$current_date" >> tempus_fugit.txt
done
Last edited by Lucas Malor; 09-05-2019 at 05:04 PM. |
|
|
|
|
09-05-2019, 05:17 PM
|
#34 | ||||
|
cosiñeiro
Posts: 1,406
Karma: 2451781
Join Date: Apr 2014
Device: BQ Cervantes 4
|
Quote:
Quote:
Quote:
Quote:
You seem confused about the differences between halt and shutdown -h on a embedded device. I would start for trying to probe my own points. I'm not saying you have no reason in your past experiences but sometimes humans reach wrong conclusions. I came to the conclusion that sleep mode didn't work because I was debugging a Kobo using usbnet module, which in fact prevents the device sleep. I had to watch a few places to know that I was wrong as my experiment was the thing to lead me to wrong conclusions. So: are you sure that you're not preventing the system from falling asleep by writting stuff to a file?. If you are sure please explain how do you know. If not please try it |
||||
|
|
|
|
09-05-2019, 05:50 PM
|
#35 |
|
BLAM!
Posts: 13,506
Karma: 26047202
Join Date: Jun 2010
Location: Paris, France
Device: Kindle 2i, 3g, 4, 5w, PW, PW2, PW5; Kobo H2O, Forma, Elipsa, Sage, C2E
|
@Lucas Malor: But poweroff does, and poweroff *is* the halt applet in busybox (this is incidentally why I linked to the source of the applet because it made that fact fairly obvious, even if you're not familiar with busybox's applet backend)
 .---- And, yeah, your script will definitely get shafted by a suspend, resuming only on... resume .(EDIT: And someone already mentioned KOReader's own sleep script logging as an example, so, good job, everyone ).I'm not familiar with /etc/pm/sleep.d, but that sounds like something controlled by a fancy-ish init system, which, err, is definitely not applicable to the Kobo, since they're using one of the simplest boot process out there (especially as opposed, to say, a Kindle, where upstart's depgraph can induce chtulhuesque nightmares). .(It's also not the case on my desktop w/ OpenRC, FWIW). EDIT: Wheee, missed a new page!  .
Last edited by NiLuJe; 09-05-2019 at 05:53 PM. |
|
|
|
|
09-05-2019, 05:51 PM
|
#36 |
|
Wizard
Posts: 1,751
Karma: 730681
Join Date: Oct 2014
Location: Antwerp
Device: Kobo Aura H2O
|
@Lucas Malor I did, rather extensively, back in 2014 to get the H2O to suspend reliably. If you get a log without interruptions it means that the device failed to suspend, for example because a particular module is still loaded. In order to suspend successfully, you must do it with a script. Wifi or USB will block it. If you don't wait at least 4 seconds after unloading all necessary modules then the H2O will almost certainly not suspend. If there's a full screen update you have to wait up to 8 seconds to suspend reliably. NB The H2O is an outlier.
The log I posted before shows exactly the same thing as the one below. I literally "tried it" half a dozen times this afternoon in order to get the result where the log was interrupted. Code:
2011-02-01T19:09:37+0100 2011-02-01T19:09:40+0100 2011-02-01T19:09:43+0100 2011-02-01T19:09:46+0100 2011-02-01T19:09:49+0100 2011-02-01T19:09:52+0100 2011-02-01T19:09:55+0100 2011-02-01T19:09:58+0100 2011-02-01T19:10:01+0100 2011-02-01T19:11:53+0100 2011-02-01T19:11:56+0100 2011-02-01T19:11:59+0100 2011-02-01T19:12:02+0100 2011-02-01T19:12:05+0100 2011-02-01T19:12:09+0100 |
|
|
|
|
09-05-2019, 05:55 PM
|
#37 |
|
BLAM!
Posts: 13,506
Karma: 26047202
Join Date: Jun 2010
Location: Paris, France
Device: Kindle 2i, 3g, 4, 5w, PW, PW2, PW5; Kobo H2O, Forma, Elipsa, Sage, C2E
|
To bounce off @pazos's USBNet comment: surprisingly enough, Mk.7 devices *will* enter suspend while in USBNet, which was a welcome surprise (because it indeed made debugging this kind of stuff more annoying).
|
|
|
|
|
09-05-2019, 05:57 PM
|
#38 |
|
BLAM!
Posts: 13,506
Karma: 26047202
Join Date: Jun 2010
Location: Paris, France
Device: Kindle 2i, 3g, 4, 5w, PW, PW2, PW5; Kobo H2O, Forma, Elipsa, Sage, C2E
|
TL;DR: Don't pick a fight about suspend on Kobos with a bunch of guys who lost a *lot* of sleep trying to figure out exactly how it behaved when working on KOReader ^^.
|
|
|
|
|
09-06-2019, 04:15 AM
|
#39 |
|
Evangelist
Posts: 446
Karma: 305160
Join Date: Aug 2015
Device: Kobo Glo HD, Kobo Aura ONE
|
Here's a simple script to check if the alarm system works:
Code:
#! /bin/sh set -e WAKE_ALARM=/sys/class/rtc/rtc0/wakealarm # Cancel an existing alarm. echo 0 > "$WAKE_ALARM" # Set an alarm one second into the future. echo +1 > "$WAKE_ALARM" # Check that the pseudo-file contains a Unix Epoch. grep -q '^[0-9]\+$' "$WAKE_ALARM" # The alarm should fire while we're sleeping. sleep 2 # And now, the pseudo-file should be empty. test -s "$WAKE_ALARM" |
|
|
|
|
09-06-2019, 06:28 AM
|
#40 |
|
Wizard
Posts: 1,751
Karma: 730681
Join Date: Oct 2014
Location: Antwerp
Device: Kobo Aura H2O
|
@baskerville That's precisely why I mistakenly thought the H2O couldn't schedule a wake up. To illustrate using your lines:
Code:
[root@(none) ~]# cd /sys/class/rtc/rtc0/ [root@(none) rtc0]# ls date hctosys power time dev max_user_freq since_epoch uevent device name subsystem Code:
[root@(none) rtc0]# WAKE_ALARM=/sys/class/rtc/rtc0/wakealarm [root@(none) rtc0]# echo 0 > "$WAKE_ALARM" -sh: can't create /sys/class/rtc/rtc0/wakealarm: nonexistent directory You can still query the state through /proc/driver/rtc. Code:
# ./rtcwake -m on -s 300 rtcwake: assuming RTC uses UTC ... rtcwake: wakeup using /dev/rtc0 at Tue Feb 1 12:26:53 2011 ^C [root@(none) sbin]# cat /proc/driver/rtc rtc_time : 12:22:10 rtc_date : 2011-02-01 alrm_time : 12:26:53 alrm_date : 2011-02-01 alarm_IRQ : yes alrm_pending : no 24hr : yes |
|
|
|
|
09-06-2019, 05:49 PM
|
#41 | |
|
Pain in the arse
Posts: 758
Karma: 77856
Join Date: Apr 2013
Device: Kobo Aura One, Kindle 4
|
Quote:
|
|
|
|
|
|
09-06-2019, 09:45 PM
|
#42 | |
|
Wizard
Posts: 2,804
Karma: 7025947
Join Date: May 2016
Location: Ontario, Canada
Device: Kobo Mini, Aura Edition 2 v1, Clara HD
|
Quote:
Code:
N3PowerWorkflowManager::setupAlarm is called (this seems to be what allows it to power off during a sleep, etc):
Gets PowerSettings::getAutoOffMinutes and PowerSettings::getAutoSleepMinutes
Runs ::configureWakup for ::powerOff and ::requestSleep depending on values of autoOffMinutes autoSleepMinutes
::configureWakeup:
Multiplies provided minutes by 60000 (min -> ms)
Schedules a wakeup, when triggered, calls the provided function
N3PowerWorkflowManager::pollBattery (does the check, called through Qt's object system):
Gets PowerSettings::getAutoOffMinutes and PowerSettings::getAutoSleepMinutes
Multiplies each by 60000 (min -> ms)
Compares with PowerManager::timeLastUsed
Performs an action if needed
It seems that these two locations are the only ones which matter.
From a quick glance, it appears that it should be fine to patch these multipliers as long as they fit in a 64-bit signed
integer. But, note that the multiplier is a 32-bit signed integer. But, to be safe, don't make the largest possible timeout
longer than 596 hours (~35800 minutes), as I haven't checked all the places where it is used.
Code:
Larger Sleep/Power-off timeouts:
- Enabled: no
# Multiplier in N3PowerWorkflowManager::configureWakeup
- ReplaceBytes: {Offset: 0xA1194C, FindH: 04 FB 05 F5, ReplaceH: 4F EA C5 45} # mul r5(dest), r4(multiplier), r5(mins) -> lsl r5, r5, #19
# Multiplier in N3PowerWorkflowManager::pollBattery
- ReplaceBytes: {Offset: 0xA13692, FindH: 08 FB 00 F8, ReplaceH: 4F EA C0 48} # mul r8(dest), r8(multiplier), r0(mins) -> lsl r8, r0, #19
- ReplaceBytes: {Offset: 0xA136C2, FindH: 02 FB 00 F2, ReplaceH: 4F EA C0 42} # mul r2(dest), r2(multiplier), r0(mins) -> lsl r2, r0, #19
# Menu text
- BaseAddress: 0xD48754
- ReplaceString: {Offset: 0, Find: "5 mins\0", Replace: "8m"}
- ReplaceString: {Offset: 8, Find: "10 mins", Replace: "34m"}
- ReplaceString: {Offset: 16, Find: "15 mins", Replace: "1h1m"}
- ReplaceString: {Offset: 24, Find: "30 mins", Replace: "4h4m"}
- ReplaceString: {Offset: 32, Find: "45 mins", Replace: "12h5m"}
- ReplaceString: {Offset: 38, Find: "60 mins", Replace: "24h1m"}
# Values
- BaseAddress: 0
- ReplaceInt: {Offset: 0xACF230, Find: 5, Replace: 1}
- ReplaceInt: {Offset: 0xACF3F6, Find: 5, Replace: 1}
- ReplaceInt: {Offset: 0xACF288, Find: 10, Replace: 4}
- ReplaceInt: {Offset: 0xACF432, Find: 10, Replace: 4}
- ReplaceInt: {Offset: 0xACF2C4, Find: 15, Replace: 7}
- ReplaceInt: {Offset: 0xACF46C, Find: 15, Replace: 7}
- ReplaceInt: {Offset: 0xACF300, Find: 30, Replace: 28}
- ReplaceInt: {Offset: 0xACF4A6, Find: 30, Replace: 28}
- ReplaceInt: {Offset: 0xACF33C, Find: 45, Replace: 83}
- ReplaceInt: {Offset: 0xACF4E0, Find: 45, Replace: 83}
- ReplaceInt: {Offset: 0xACF378, Find: 60, Replace: 165}
- ReplaceInt: {Offset: 0xACF518, Find: 60, Replace: 165}
Spoiler:
Last edited by geek1011; 09-06-2019 at 09:49 PM. Reason: Fixed offset for N3PowerWorkflowManager::configureWakeup |
|
|
|
|
|
09-07-2019, 06:19 AM
|
#43 | ||
|
Wizard
Posts: 1,751
Karma: 730681
Join Date: Oct 2014
Location: Antwerp
Device: Kobo Aura H2O
|
Quote:
Quote:
|
||
|
|
|
|
09-07-2019, 12:40 PM
|
#44 | |
|
Pain in the arse
Posts: 758
Karma: 77856
Join Date: Apr 2013
Device: Kobo Aura One, Kindle 4
|
Quote:
Code:
//config:config HALT //config: bool "halt (4 kb)" //config: default y //config: help //config: Stop all processes and halt the system. //config: //config:config POWEROFF //config: bool "poweroff (4 kb)" //config: default y //config: help //config: Stop all processes and power off the system. Last edited by Lucas Malor; 09-07-2019 at 12:45 PM. |
|
|
|
|
|
09-07-2019, 01:00 PM
|
#45 | |
|
Wizard
Posts: 2,804
Karma: 7025947
Join Date: May 2016
Location: Ontario, Canada
Device: Kobo Mini, Aura Edition 2 v1, Clara HD
|
Quote:
Also, regarding your earlier comment about /etc/pm/suspend.d, that is for pm-utils, which isn't even usually used on systemd anymore, so you won't even find it on most modern distros. The Kobo doesn't have pm-utils either, and it doesn't need it. And it does have a real suspend mode, which is why it sets a RTC alarm to wake it up. The reason why your script may have worked before is the periodic wake-up for syncing. |
|
|
|
|
|
«
Previous Thread
|
Next Thread
»
| Thread Tools | Search this Thread |
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| Kobo Forma: changing button behaviour | franklekens | Kobo Reader | 5 | 02-05-2019 03:28 PM |
| Aura ONE Kobo Aura ONE touchscreen generating random button presses, unresponsive | pl8o | Kobo Reader | 3 | 12-25-2018 04:04 AM |
| Notification about power button presses for the K5 and hopefully for the KPW | PaulFreund | Kindle Developer's Corner | 2 | 04-15-2013 11:55 AM |
| Simulating Button Presses Externally | inuxy | Kindle Developer's Corner | 58 | 08-28-2012 01:55 PM |
| PRS-T1 How can I use back button as power button? | younghere | Sony Reader | 1 | 03-12-2012 06:37 PM |
All times are GMT -4. The time now is 08:35 AM.