I was puzzled why "hwclock" wrongly reported my x86_64 sytem didn't
support RTC update interrupts. Bogus #ifdef, that's why ... added
by the 2.11y patch (from 2.11t). Probably this whole #ifdef should
just vanish ... if the kernel rejects UIE_ON, the program ought to
just cope with it.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
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>
/sbin/hwclock is supposed to fall back to using /dev/rtc0 if /dev/rtc isn't
working (which it isn't, because mkinitrd creates it with the old device
numbers, and we're switching to the new RTC_CLASS driver).
Unfortunately, it'll only cope if the error it gets is ENOENT (i.e. the device
node doesn't exist). It doesn't fall back to the next device in the list if the
error is ENODEV, which is what happens when the device node exists, but there's
no driver.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: Karel Zak <kzak@redhat.com>
The --rtc option does not set the name of the device correctly.
It still uses /dev/rtc even if the --rtc option is given.
Testcase:
$ mv /dev/rtc /dev/foo
$ hwclock --show --debug --rtc=/dev/foo
hwclock from util-linux-2.13-rc2
Using /dev interface to clock.
Last drift adjustment done at 1190198135 seconds after 1969
Last calibration done at 1190198135 seconds after 1969
Hardware clock is on local time
Assuming hardware clock is kept in local time.
Waiting for clock tick...
hwclock: open() of /dev/rtc failed, errno=2: No such file or directory.
...got clock tick
Co-Author: Karel Zak <kzak@redhat.com>
Signed-off-by: Matthias Koenig <mkoenig@suse.de>
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>
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>
