(ds1307/ds3231) hwclock: ioctl(3, RTC_UIE_ON, 0): Invalid argument

[boatbodger]

Describe the bug
When running hwclock on a Pi 4 with a DS3231 RTC, an "invalid argument" error occurs
Waiting for clock tick...
`ioctl(3, RTC_UIE_ON, 0): Invalid argument'

Additional context
Ultimately my problem with reading the clock was being caused by noise on the ground connection between the R-Pi and the clock chip.
The 'Invalid argment' is still occurring, but is non-fatal - many thanks to pelwell for the explanation below.

[pelwell]

The error is caused by the lack of an interrupt signal from the RTC - the I and the E in RTC_UIE stand for Interrupt Enable. As you've discovered, that shouldn't stop the basic RTC functions working.

[qjayjayp]

I had the same error, and for me the cause was that the initial value for the month was 0x1f, which is neither BCD (as it is supposed to) nor a value somewhere within the proper range 8yes it is accidentaly decimal 31, but it was the month field). I finally took a python script that could write the system date and time via /dev/i2c, from this moment on everything worked as expected.

[thrasher]

@qjayjayp thanks for posting your note, as I was concerned about the same. What data is it that you're sending via i2c? Would you mind linking to your python script?

[qjayjayp]

@thraser Yes I looked it up, I used this old script from, 2013 (@XiErCh): https://gist.github.com/sorz/6049584 and commented in the 'write now' line 208. I've seen the code may got some improvements, it is mentioned here (https://www.switchdoc.com/2014/07/python-driver-ds1307-real-time-clock/) and put into a lib here (https://github.com/switchdoclabs/RTC_SDL_DS1307), but you can still use it the same way (ds1307.write_now()).

[V10lator]

Why has this been closed? This is an issue when using Chrony, for example:
chronyd[383]: Could not enable RTC interrupt : Invalid argument
This pevents chrony from measuring the RTC clock drift and as a result from acting against it. The DS3231 is capapble of emitting a 1 Hz signal (which corresponds to "interrupt on every clock update, for RTCs that support this once-per-second interrupt") on the SQW pin. Uptream DT even mentions it but doesn't tell how to route it to a GPIO pin and from there back to the driver: https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/rtc/maxim%2Cds3231.txt - Raspberry DT completely ignores the #clock-cells parameter.

[pelwell]

Answering in the Forums - please don't cross-post.

[by]

When compiling a customer kernel with CONFIG_RTC_INTF_DEV_UIE_EMUL, the error 'hwclock: ioctl(3, RTC_UIE_ON, 0): Invalid argument' is gone.

[kurahaupo]

@qjayjayp

[...] the initial value for the month was 0x1f [...] decimal 31

That could also be -1 expressed as a 5-bit 2's-complement number, perhaps trying to indicate that the month isn't available?

[alexdelprete]

Why has this been closed? This is an issue when using Chrony, for example: chronyd[383]: Could not enable RTC interrupt : Invalid argument This pevents chrony from measuring the RTC clock drift and as a result from acting against it.

has this ever been solved? I have the exact same issue with an uputronics gps hat with rv3028.

I couldn't find a follow-up discussion on the forums...

[boatbodger]

I closed it because in my case, the RTC module I was using did not have an interrupt output connected - and as pelwell explained, the error message was effectively a warning about that being the case (albeit not a very obvious way of saying it).
For me, therefore, there was no bug to fix. My use case did not need the RTC to be able to create interrupts. If you think you need an interrupt, make sure your hardware actually has one connected, and then fiddle with the devicetree to enable it.

[alexdelprete]

When compiling a customer kernel with CONFIG_RTC_INTF_DEV_UIE_EMUL, the error 'hwclock: ioctl(3, RTC_UIE_ON, 0): Invalid argument' is gone.

Thanks a lot. I compiled 6.1.11 and it worked perfectly. I can finally use chrony RTC drift monitoring functionality.