On Thu, Sep 1, 2022, at 1:31 PM, Reinier Kuipers wrote: > > I'm working to fix the y2038 issue for an existing sama5d3-based > product. This involves updating the kernel and glibc to appropriate > versions (5.10 and 2.35.1 respectively) and I got things running up to > a state where, from userspace, both date and hwclock commands have no > issue accepting dates beyond 2038. However, even with the RTC_HCTOSYS > and RTC_HCTOSYS_DEVICE options configured correctly, the RTC driver > fails to initialize the system clock at bootup. > > Some digging in rtc/class.c::rtc_hctosys() indicates that > do_settimeofday64() is deliberately not executed on systems with > BITS_PER_LONG==32 and a second counter higher than INT_MAX. I assumed > that the work on 64-bits timestamps was already fully implemented for > 32-bit systems as well, so my gut feel is that this > BITS_PER_LONG/INT_MAX check has become unnecessary. A test build with > these checks disabled results in correct time initialization at bootup > with, at a glance, no adverse effects. Does anybody here know whether > do_settimeofday64() is robust on 32-bit systems or that the checks > are still required to prevent further breakage?
Please see commit b3a5ac42ab18 ("rtc: hctosys: Ensure system time doesn't overflow time_t") and https://github.com/systemd/systemd/issues/1143 for the problem that originally caused this to be added. Removing this check would probably break systemd again for machines that return a post-y2038 time with systemd built on 32-bit time_t. The only reliable fix I can see would be to disable CONFIG_RTC_HCTOSYS_DEVICE. I think this is Alexandre's plan for the long run anyway, but I don't know if there has been any progress in convincing distros to turn it off. Arnd _______________________________________________ Y2038 mailing list -- y2038@lists.linaro.org To unsubscribe send an email to y2038-le...@lists.linaro.org