Skip to content

hwclock on Raspberry Pi 2 with DS1307 RTC: operates correctly in util-linux 2.30.1, fails in 2.31 #543

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
es30 opened this issue Nov 21, 2017 · 8 comments

Comments

@es30
Copy link

es30 commented Nov 21, 2017

On a Raspberry Pi 2 with DS1307 RTC running Arch Linux ARM with util-linux 2.30.1:

# hwclock -D
hwclock from util-linux 2.30.1
Trying to open: /dev/rtc0
Using the rtc interface to the clock.
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
/dev/rtc0 does not have interrupt functions. Waiting in loop for time from /dev/rtc0 to change
...got clock tick
Time read from Hardware Clock: 2017/11/21 20:27:03
Hw clock time : 2017/11/21 20:27:03 = 1511296023 seconds since 1969
Time since last adjustment is 1511296023 seconds
Calculated Hardware Clock drift is 0.000000 seconds
2017-11-21 12:27:02.930019-0800
#

But with util-linux 2.31:

# hwclock -D
hwclock from util-linux 2.31
System Time: 1511286992.869143
Trying to open: /dev/rtc0
Using the rtc interface to the clock.
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
hwclock: ioctl(3, RTC_UIE_ON, 0) to /dev/rtc0 failed: Invalid argument
...synchronization failed
#

Reverting the function synchronize_to_clock_tick_rtc in hwclock-rtc.c to its definition in branch stable/v2.30 restores some semblance of correct operation (which is not to say that this is the fix to the problem):

# ./hwclock -D
hwclock from util-linux 2.31
System Time: 1511287003.907954
Trying to open: /dev/rtc0
Using the rtc interface to the clock.
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
/dev/rtc0 does not have interrupt functions. ioctl(3, RTC_UIE_ON, 0): Invalid argument
Waiting in loop for time from /dev/rtc0 to change
...got clock tick
Time read from Hardware Clock: 2017/11/21 17:56:45
Hw clock time : 2017/11/21 17:56:45 = 1511287005 seconds since 1969
Time since last adjustment is 1511287005 seconds
Calculated Hardware Clock drift is 0.000000 seconds
2017-11-21 09:56:44.370380-0800
#

For other users experiencing the same problem, see thread https://archlinuxarm.org/forum/viewtopic.php?f=57&t=12222.

@karelzak
Copy link
Collaborator

I guess we need

- } else if (errno == ENOTTY) {
+ } else if (errno == ENOTTY || errno == EINVAL) {

@jwpi ?

@es30
Copy link
Author

es30 commented Nov 22, 2017

I can't speak to the general case, but the proposed fix works in my particular case:

# ./hwclock -D
hwclock from util-linux 2.31
System Time: 1511366637.637657
Trying to open: /dev/rtc0
Using the rtc interface to the clock.
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
ioctl(3, RTC_UIE_ON, 0): Invalid argument
Waiting in loop for time from /dev/rtc0 to change
...got clock tick
Time read from Hardware Clock: 2017/11/22 16:03:59
Hw clock time : 2017/11/22 16:03:59 = 1511366639 seconds since 1969
Time since last adjustment is 1511366639 seconds
Calculated Hardware Clock drift is 0.000000 seconds
2017-11-22 08:03:58.097366-08:00
#

@ghost
Copy link

ghost commented Nov 22, 2017 via email

@es30
Copy link
Author

es30 commented Nov 22, 2017

Hmm, interesting. I would think that my kernel is sufficiently current:

$ uname -a
Linux Corvus 4.9.60-1-ARCH #1 SMP Mon Nov 6 10:03:15 PST 2017 armv7l GNU/Linux

Could the fact that I'm compiling the rtc-ds1307 driver into my kernel be making a difference?

$ diff config config.original
2667c2667
< CONFIG_I2C_BCM2835=y
---
> CONFIG_I2C_BCM2835=m
4606,4607c4606
< CONFIG_RTC_HCTOSYS=y
< CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
---
> # CONFIG_RTC_HCTOSYS is not set
4626c4625
< CONFIG_RTC_DRV_DS1307=y
---
> CONFIG_RTC_DRV_DS1307=m

I'll try running hwclock against the stock kernel with loadable RTC driver, but it will take me a bit of time.

@ghost
Copy link

ghost commented Nov 23, 2017 via email

karelzak added a commit that referenced this issue Nov 23, 2017
This commit reverts 1d5cffa.

(I did this revert manually as there was another changes in the code
and git-revert does not work in this case.)

Addresses: #543
Signed-off-by: Karel Zak <kzak@redhat.com>
@karelzak
Copy link
Collaborator

The change will in v2.31.1 (probably end of Nov).

@ghost
Copy link

ghost commented Dec 13, 2017 via email

@karelzak
Copy link
Collaborator

Ah, ... already December. OK, I'l fix it ASAP.

karelzak added a commit that referenced this issue Dec 14, 2017
This commit reverts 1d5cffa.

(I did this revert manually as there was another changes in the code
and git-revert does not work in this case.)

Addresses: #543
Signed-off-by: Karel Zak <kzak@redhat.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants