[arch-dev-public] [PATCH 1/3] rc.sysinit: background hwclock calls
hwclock calls appear to block somewhere between 1 and 2 seconds when we have back-to-back calls. My theory (without looking at the code) is that hwclock has to synchronize to the 1 second intervals of the hardware clock, so it can sometimes take up to a second to complete. To get around this unpleasant behavior, we can background the calls at point X in the boot sequence, and then later at point Y in the script (when we absolutely need the clock actions to be complete), we wait on the subprocess. This allows the rest of the boot sequence, after the hwclock code block, to continue until the point where we wait on the subprocess. Signed-off-by: Dan McGee <dan@archlinux.org> --- rc.sysinit | 11 ++++++++++- 1 files changed, 10 insertions(+), 1 deletions(-) diff --git a/rc.sysinit b/rc.sysinit index 0c934c7..e948074 100755 --- a/rc.sysinit +++ b/rc.sysinit @@ -281,9 +281,13 @@ if [ "$TIMEZONE" != "" -a -e "/usr/share/zoneinfo/$TIMEZONE" ]; then /bin/cp "/usr/share/zoneinfo/$TIMEZONE" /etc/localtime fi +clock_pid="" if [ -n "$HWCLOCK_PARAMS" ]; then + ( /sbin/hwclock --adjust #Adjust for system drift /sbin/hwclock $HWCLOCK_PARAMS + ) & + clock_pid=$! fi stat_done @@ -396,7 +400,12 @@ fi /bin/dmesg >| /var/log/dmesg.log +# final hwclock setting needs to be done at this point +if [ -n "$clock_pid" ]; then + wait $clock_pid +fi + run_hook sysinit_end # End of file -# vim: set ts=2 noet: +# vim: set ts=2 sw=2 noet: -- 1.6.5.5
Signed-off-by: Dan McGee <dan@archlinux.org> --- rc.sysinit | 18 +++++++++++++++--- 1 files changed, 15 insertions(+), 3 deletions(-) diff --git a/rc.sysinit b/rc.sysinit index e948074..c09dad2 100755 --- a/rc.sysinit +++ b/rc.sysinit @@ -54,8 +54,14 @@ if [ -n "$HWCLOCK_PARAMS" ]; then /bin/ln -s /dev/rtc0 /dev/rtc fi - # Set clock early to fix some bugs with filesystem checks - # Clock is set again later to match rc.conf + # Do a clock set here for a few reasons: + # 1. Make creation time on udev nodes sane (FS#8665) + # 2. Filesystem checks can depend on system time + # 3. This will set the clock, if using non-UTC, off the last known + # configured timezone. Any new timezone put in rc.conf is copied over at + # a later time. + # This does *NOT* take into account a time adjustment file as /var may not be + # mounted yet. A second set occurs later to match rc.conf. if [ -f /etc/localtime ]; then /sbin/hwclock $HWCLOCK_PARAMS --noadjfile fi @@ -283,8 +289,14 @@ fi clock_pid="" if [ -n "$HWCLOCK_PARAMS" ]; then + # This time, we set the clock for real. Use the adjustment file now that + # /var will definitely be available, and then set the system clock once + # the hardware clock has been adjusted accordingly. The backgrounding magic + # is due to the fact that the second call to hwclock will almost always + # take ~1 second because of the clock granularity, and we might as well + # stay busy. ( - /sbin/hwclock --adjust #Adjust for system drift + /sbin/hwclock --adjust /sbin/hwclock $HWCLOCK_PARAMS ) & clock_pid=$! -- 1.6.5.5
This is an Arch initscripts original (commit 98c76a4), but is not actually necessary for hwclock to operate correctly, so kill it. The file is created automatically when `hwclock --systohc` is invoked. Signed-off-by: Dan McGee <dan@archlinux.org> --- rc.sysinit | 3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/rc.sysinit b/rc.sysinit index c09dad2..4e079ad 100755 --- a/rc.sysinit +++ b/rc.sysinit @@ -279,9 +279,6 @@ stat_done status "Activating Swap" /sbin/swapon -a stat_busy "Configuring System Clock" -if [ ! -f /var/lib/hwclock/adjtime ]; then - echo "0.0 0 0.0" > /var/lib/hwclock/adjtime -fi if [ "$TIMEZONE" != "" -a -e "/usr/share/zoneinfo/$TIMEZONE" ]; then /bin/rm -f /etc/localtime /bin/cp "/usr/share/zoneinfo/$TIMEZONE" /etc/localtime -- 1.6.5.5
On Sun, 13 Dec 2009 21:26:46 -0600 Dan McGee <dan@archlinux.org> wrote:
This is an Arch initscripts original (commit 98c76a4), but is not actually necessary for hwclock to operate correctly, so kill it. The file is created automatically when `hwclock --systohc` is invoked.
hmm can't find any mention of 'systohc' in the current rc.init, nor in your other patches? Dieter
On Thu, Dec 17, 2009 at 5:54 AM, Dieter Plaetinck <dieter@plaetinck.be> wrote:
On Sun, 13 Dec 2009 21:26:46 -0600 Dan McGee <dan@archlinux.org> wrote:
This is an Arch initscripts original (commit 98c76a4), but is not actually necessary for hwclock to operate correctly, so kill it. The file is created automatically when `hwclock --systohc` is invoked.
hmm can't find any mention of 'systohc' in the current rc.init, nor in your other patches?
rc.shutdown is where that is, but I may have mean hctosys. I don't know because these patches are a month or so old and I can't look into it at the moment. -Dan
On Sun, Dec 13, 2009 at 9:26 PM, Dan McGee <dan@archlinux.org> wrote:
hwclock calls appear to block somewhere between 1 and 2 seconds when we have back-to-back calls. My theory (without looking at the code) is that hwclock has to synchronize to the 1 second intervals of the hardware clock, so it can sometimes take up to a second to complete.
To get around this unpleasant behavior, we can background the calls at point X in the boot sequence, and then later at point Y in the script (when we absolutely need the clock actions to be complete), we wait on the subprocess. This allows the rest of the boot sequence, after the hwclock code block, to continue until the point where we wait on the subprocess.
Signed-off-by: Dan McGee <dan@archlinux.org> ---
I discussed this patch series with Thomas a while back; I'd be happy to answer questions on it. They have worked great on my Eee over the last month. -Dan
On Sun, Dec 13, 2009 at 9:28 PM, Dan McGee <dan@archlinux.org> wrote:
On Sun, Dec 13, 2009 at 9:26 PM, Dan McGee <dan@archlinux.org> wrote:
hwclock calls appear to block somewhere between 1 and 2 seconds when we have back-to-back calls. My theory (without looking at the code) is that hwclock has to synchronize to the 1 second intervals of the hardware clock, so it can sometimes take up to a second to complete.
To get around this unpleasant behavior, we can background the calls at point X in the boot sequence, and then later at point Y in the script (when we absolutely need the clock actions to be complete), we wait on the subprocess. This allows the rest of the boot sequence, after the hwclock code block, to continue until the point where we wait on the subprocess.
Signed-off-by: Dan McGee <dan@archlinux.org> ---
I discussed this patch series with Thomas a while back; I'd be happy to answer questions on it. They have worked great on my Eee over the last month.
These look good to me. Feel free to push them if no one else takes issue with it
participants (4)
-
Aaron Griffin
-
Dan McGee
-
Dan McGee
-
Dieter Plaetinck