![]() |
![]() |
![]() ![]()
Post
#1
|
|
![]() Group: Members Posts: 408 Joined: 3-December 06 Member No.: 13,063 ![]() |
When I started with beta3, had some time issues and pdaxrom occasionally "locking up" - which turns out to be because of wrong clock. Here I share my way of fixing them.
I use the following pair of scripts. When you need date synchronization, just call 'dt' script. (modify the values to your needs, I live in Sofia and use for sync ntp.intergenia.de, which you might not be able to access. Place the files in /usr/local/bin, and 'chmod +x' ) dt CODE #!/bin/bash lt_unset ntpdate ntp.intergenia.de hwclock --systohc lt_set lt_set: CODE #!/bin/bash rm -f /etc/localtime ln -s /usr/share/zoneinfo/Europe/Sofia /etc/localtime lt_unset: CODE #!/bin/bash rm -f /etc/localtime in /etc/apm/scripts.d/hwclock the functions inside look like this: CODE suspend() { lt_unset hwclock --systohc lt_set return 0 } resume() { lt_unset hwclock --hctosys lt_set return 0 } I can guarantee you that you will have _no_ problems with the clock anymore, just set the correct timezone and ntp server. If you don't have internet, you just can issue commands in 'dt' one by one, replacing ntpdate with 'date xxxx' command to set the clock. Also, if you accidentally turn off your zaurus, don't turn it on immediately. wait 3-4 seconds at least, and then do it. timezones package from the feed is required. |
|
|
![]() |
![]()
Post
#2
|
|
![]() Group: Members Posts: 2,803 Joined: 21-March 05 From: Sydney, Australia Member No.: 6,686 ![]() |
this is what I have in /etc/apm.d/scripts/hwclock
CODE suspend() { /etc/rc.d/init.d/atd stop 2>/dev/null >/dev/null hwclock --systohc return 0 } resume() { hwclock --hctosys /etc/rc.d/init.d/atd start 2>/dev/null >/dev/null return 0 } and my time is always correct |
|
|
![]()
Post
#3
|
|
![]() Group: Members Posts: 1,001 Joined: 28-April 05 From: Germany Member No.: 7,027 ![]() |
QUOTE(Meanie @ Feb 19 2007, 09:27 AM) this is what I have in /etc/apm.d/scripts/hwclock CODE suspend() { /etc/rc.d/init.d/atd stop 2>/dev/null >/dev/null hwclock --systohc return 0 } resume() { hwclock --hctosys /etc/rc.d/init.d/atd start 2>/dev/null >/dev/null return 0 } and my time is always correct Interesting - does KO/PI alarm work from suspend, although atd is stopped prior to suspending? daniel |
|
|
![]()
Post
#4
|
|
Group: Members Posts: 88 Joined: 11-December 07 Member No.: 21,059 ![]() |
QUOTE(Meanie @ Feb 19 2007, 09:27 AM) this is what I have in /etc/apm.d/scripts/hwclock CODE suspend() { /etc/rc.d/init.d/atd stop 2>/dev/null >/dev/null hwclock --systohc return 0 } resume() { hwclock --hctosys /etc/rc.d/init.d/atd start 2>/dev/null >/dev/null return 0 } and my time is always correct Interesting - does KO/PI alarm work from suspend, although atd is stopped prior to suspending? daniel Blast from the past, I know. I just wanted to say that the KO/PI alarm wakeup fix (kopi-apm) doesn't appear to work in pdaXii13. When I suspend and there is a pending KO/PI alarm, my Zaurus won't wake up and I need to perform a hard reset. I verified that disabling the hwclock script allows the KO/PI alarm wakeup fix to work. Apparently the original solution for the KO/PI alarm wakeup involved apm, and not atd, but since apm didn't work properly due to some bugs, the atd solution took its place. I might work on trying to fix apm to use that as a solution. However, I'm wondering if stopping atd on suspend might affect some other things, and therefore a better solution for the conflict might be to edit hwclock and reimplement it so that atd is not stopped. I'm not expecting an answer to this, since pdaXrom seems to be pretty much done in terms of user base and support, but I'm documenting it for the benefit of future generations. ![]() |
|
|
![]()
Post
#5
|
|
Group: Members Posts: 88 Joined: 11-December 07 Member No.: 21,059 ![]() |
Blast from the past, I know. I just wanted to say that the KO/PI alarm wakeup fix (kopi-apm) doesn't appear to work in pdaXii13. When I suspend and there is a pending KO/PI alarm, my Zaurus won't wake up and I need to perform a hard reset. I verified that disabling the hwclock script allows the KO/PI alarm wakeup fix to work. Apparently the original solution for the KO/PI alarm wakeup involved apm, and not atd, but since apm didn't work properly due to some bugs, the atd solution took its place. I might work on trying to fix apm to use that as a solution. However, I'm wondering if stopping atd on suspend might affect some other things, and therefore a better solution for the conflict might be to edit hwclock and reimplement it so that atd is not stopped. I'm not expecting an answer to this, since pdaXrom seems to be pretty much done in terms of user base and support, but I'm documenting it for the benefit of future generations. ![]() Obviously, atd must be stopped for hwclock to work (in Beta3 and pdaXii13 at least.) So the only way to solve this conflict and have both proper time and wakeup for KO/PI alarms is to change the kopi-apm script to actually use apm, which to my knowledge would involve fixing apm. I'll have a look. And yes, I know I'm talking to myself here. And no, I'm not crazy (at least not because of this. ![]() |
|
|
![]() ![]() |
![]() |
Lo-Fi Version | Time is now: 24th April 2018 - 09:02 PM |