The tool misspellings (https://github.com/lyda/misspell-check)
detected several typos. Command used:
$ git ls-files | grep -v ^po/ | misspellings -f -
* isosize: Fix typo in usage string.
* configure.ac: Fix typo in help string of --enable-most-builds option.
* fdisk: Fix typo in man page.
* libblkid, blkid, mount: Likewise.
* Fix various typos in docs and in source code comments.
Signed-off-by: Bernhard Voelker <mail@bernhard-voelker.de>
Also do it at sensible boundaries, improve some of the wording, and
indent continuation lines for clarity. Also document -V instead of
-v for --version, to conform to the majority of utilities.
Signed-off-by: Benno Schulenberg <bensberg@justemail.net>
hwclock.c: In function 'manipulate_epoch':
hwclock.c:1299:29: warning: unused parameter 'getepoch' [-Wunused-parameter]
hwclock.c:1299:50: warning: unused parameter 'setepoch' [-Wunused-parameter]
hwclock.c:1300:14: warning: unused parameter 'epoch_opt' [-Wunused-parameter]
hwclock.c:1300:36: warning: unused parameter 'testing' [-Wunused-parameter]
hwclock.c: In function 'usage':
hwclock.c:1373:1: warning: embedding a directive within macro arguments is not portable [enabled by default]
hwclock.c:1377:1: warning: embedding a directive within macro arguments is not portable [enabled by default]
hwclock.c:1383:1: warning: embedding a directive within macro arguments is not portable [enabled by default]
hwclock.c:1385:1: warning: embedding a directive within macro arguments is not portable [enabled by default]
cmos.c: In function 'outb':
cmos.c:84:15: warning: unused parameter 'a' [-Wunused-parameter]
cmos.c:84:22: warning: unused parameter 'b' [-Wunused-parameter]
cmos.c: In function 'inb':
cmos.c:88:13: warning: unused parameter 'c' [-Wunused-parameter]
cmos.c: In function 'atomic':
cmos.c:265:20: warning: unused parameter 'name' [-Wunused-parameter]
cmos.c: In function 'i386_iopl':
cmos.c:544:32: warning: unused parameter 'level' [-Wunused-parameter]
cmos.c: In function 'get_permissions_cmos':
cmos.c:565:8: warning: unused variable 'errsv' [-Wunused-variable]
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
Despide amount of the change this change should be harmless.
Everything is about indendation, comment restructuring etc not
code changes.
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
hwclock.c: In function ‘set_hardware_clock’:
hwclock.c:467:7: warning: variable ‘err’ set but not used [-Wunused-but-set-variable]
hwclock.c: In function ‘main’:
hwclock.c:1461:7: warning: variable ‘ARCconsole’ set but not used [-Wunused-but-set-variable]
Signed-off-by: Karel Zak <kzak@redhat.com>
Thanks to the direct ISA method and by disabling the RTC get/set epoch
functionality, hwclock can work fine on non-Linux systems which provide
ioperm or iopl.
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
If /etc/adjtime doesn't specify UTC or LOCAL, rtcwake defaults to UTC
and hwclock defaults to LOCAL.
Switch hwclock to meet the behaviour of rtcwake (default=UTC), also
matching the kernel's CONFIG_RTC_HCTOSYS behaviour.
The user impact of this change should be minimal, as anyone who has run
"hwclock --systohc" before will have their UTC/LOCAL choice already
recorded in /etc/adjtime.
Signed-off-by: Daniel Drake <dsd@laptop.org>
In some cases the date/time stored in an RTC can be corrupted, eg due to
loss of power, before its been initially set, etc. When this occurs
the RTC_RD_TIME ioctl can fail since the Linux kernel determines that
the RTC contains invalid data. Currently, when setting an RTC using
hwclock, hwclock performs a number of RTC_RD_TIME ioctls before setting
the RTC. When one of these ioctls fails, hwclock bombs out and the
corrupted RTC data can't be overwritten. Thus once an RTC is corrupted,
it can't be fixed via hwclock*.
To work around the above issue we can make hwclock not exit when a
RTC_RD_TIME failure occurs during the process of setting the RTC. This
allows the RTC to be set even when it contains an invalid value,
although it is not synchronized to a clock tick before it is set.
* 'hwclock --utc --noadjfile --set --date="11/23/10 17:19:00' currently
works to fix a corrupted RTC, but a user couldn't determine this without
digging through the source code.
Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
Implement new option --predict that predicts what the RTC will read
at a time given by the --date option. This is useful for example if
you need to setup an RTC wakeup time to distant future and want to
account for the RTC drift.
Signed-off-by: Timo Juhani Lindfors <timo.lindfors@iki.fi>
Signed-off-by: Karel Zak <kzak@redhat.com>
Even though --systz doesn't need to change the system clock when the
hardware clock is in UTC time (--systz --utc), it does need to set
the kernel timezone so that FAT timestamps, etc. will be correct.
Signed-off-by: Scott James Remnant <scott@ubuntu.com>
When using --systz we do not read from the hardware clock, so there
is no need to search for a hardware clock. Indeed, we may be running
hwclock --systz before /dev is mounted.
Signed-off-by: Scott James Remnant <scott@ubuntu.com>
date_child_fp is opened by popen, so should be closed with pclose.
Signed-off-by: John Keeping <john.keeping@lineone.net>
Reviewed-by: WANG Cong <xiyou.wangcong@gmail.com>
Since the system clock time is already set from the hardware clock by the
kernel (when compiled with CONFIG_RTC_HCTOSYS), there's no particular need to
read the hardware clock again.
This option sets the system clock using itself as a reference if the
hardware clock was in local time. The resulting system clock time
is in UTC, with the kernel timezone set to the difference.
[kzak@redhat.com: - fix the condition that controls read_adjtime() call]
Signed-off-by: Scott James Remnant <scott@ubuntu.com>
Signed-off-by: Karel Zak <kzak@redhat.com>
- Avoid delaying 1.5 seconds when 0.5 will do.
- Guard for forward time resets as well.
[kzak@redhat.com: - fix the "Delaying.." debug message
- add comments]
Signed-off-by: Kalev Soikonen <ksop@hot.ee>
Signed-off-by: Karel Zak <kzak@redhat.com>
* It seems that
rtc-isl1208 0-006f: chip found, driver version 0.3
rtc-isl1208 0-006f: rtc core: registered rtc-isl1208 as rtc0
rtc-isl1208 0-006f: rtc power failure detected, please set clock.
causes that hardware clock returns persistent time and synchronization
is impossible. The hwclock(8) has to ignore this problem and allows to
set clock anyway.
* synchronize_to_clock_tick() shouldn't to print the "...got clock tick"
debug message in case of failure.
Signed-off-by: Karel Zak <kzak@redhat.com>
- Bogus if test means one message is never produced.
- Avoid needless passing of a global variable (debug).
The --test option flag ought to be a global as well (and perhaps -n/--dry-run).
Signed-off-by: Kalev Soikonen <ksop@hot.ee>
It's a pity that hwclock first tries to read the clock when running
hwclock --systohc --noadjfile --utc
and exits as this fails. I cannot see a reason to read first in that
case.
Old version:
# hwclock --systohc --noadjfile --utc --debug
hwclock from util-linux-ng 2.14
Using /dev interface to clock.
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
/dev/rtc does not have interrupt functions. Waiting in loop for time
from /dev/rtc to change
...got clock tick
Time read from Hardware Clock: 2008/06/17 11:18:24
Hw clock time : 2008/06/17 11:18:24 = 1213701504 seconds since 1969
Time elapsed since reference time has been 0.904855 seconds.
Delaying further to reach the next full second.
Setting Hardware Clock to 11:18:24 = 1213701504 seconds since 1969
ioctl(RTC_SET_TIME) was successful.
New version:
# hwclock --systohc --noadjfile --utc --debug
hwclock from util-linux-ng 2.14
Using /dev interface to clock.
Assuming hardware clock is kept in UTC time.
Time elapsed since reference time has been 0.572151 seconds.
Delaying further to reach the next full second.
Setting Hardware Clock to 11:18:52 = 1213701532 seconds since 1969
ioctl(RTC_SET_TIME) was successful.
Addresses-Debian-Bug: #478663
Signed-off-by: Karel Zak <kzak@redhat.com>
Currently, if hwclock is given the --noadjfile option it will
nevertheless display information about the drift rate when invoked with
the --debug option.
Signed-off-by: Matthias Koenig <mkoenig@suse.de>
When hwclock --hctosys is started very early during the system startup,
with / still mounted read-only, and there was no /etc/adjtime file,
hwclock fails creating a default adjfile full of zeroes, and prints an
error message. I believe that such zero adjfile is not necessary,
because it means exactly the same as no adjfile at all.
The attached patch prevents creation of a zero adjfile, of course unless
something gets changed (this never happens during a --hctosys).
Signed-off-by: Alain Guibert <alguibert+ulng@free.fr>
We have PACKAGE_STRING in config.h that includes package name and
version. It's better to use this macro that hardcoded strings.
Signed-off-by: Karel Zak <kzak@redhat.com>
If you compile --with-audit the hwclock tool reports changes in sys/hw clock to
audit system. The real long-term and final solution is probably add hooks for
/dev/rtc to kernel, but it's not implemented yet.
Signed-off-by: Steve Grubb <sgrubb@redhat.com>
Signed-off-by: Karel Zak <kzak@redhat.com>
quote from rh150493:
The kernel code, when setting the BIOS clock notes that the clock time
ticks to the next second 0.5 seconds after adjusting it (see
linux/arch/i386/kernel/time.c).
hwclock --systohc sets the CMOS clock at the 1 second boundry and thus
causes the clock to be wrong by 500ms each time it is reset. If the
clock is set every shutdown then the clock will have a reboot-count
related drift as well as the natural drift problems of the clock. Note
that this also mucks up the drift calculations, of course.
Signed-off-by: Karel Zak <kzak@redhat.com>
The patch to allow "hwclock --rtc /dev/rtc1" and so on,
since "/dev/rtc" may not be there and "/dev/rtc0" may not be
the right answer either.
The "--rtc" is compatible with next Bryan Henderson's hwclock
versions.
Signed-off-by: David Brownell <david-b@pacbell.net>
Signed-off-by: Karel Zak <kzak@redhat.com>
