muddyfeet:

The WRT1200AC and the WRT1900AC (and quite possibly the WRT3200AC) has a hardware RTC on the Marvell SoC. The kernel recognises this and creates a /dev/rtc0 device.

The RTC is not battery backed so can come up with any random time set - have seen dates around 1970 and 2034 and 2036.

The /etc/init.d/sysfixtime script is designed to bring up the system with a sensible time and date (sourced from file dates in /etc) until it can be accurately set via NTP on systems with and without hardware RTCs.

The problem is at boot it assumes that because /etc/rtc0 exists and /sbin/hwclock exists, then it can obtain the sensible time from the hardware clock. This causes problems on my router with syslog-ng, vnstat and collectd if the date is in the future (collectd doesn't log any data and syslog-ng writes spurious logs based on the date).

The issue is further compounded in that the hardware RTC appears to lock up sometimes (probably due to the hardware RTC Vbatt line having no power on boot) and can only be reset by doing a "date reset" command under U-Boot. When the RTC has locked up the command "hwclock -s -u -f /dev/rtc0" or "hwclock -w" has no effect.

The solution may be to not create /dev/rtc0 on devices with an RTC but no battery back up. Another solution may be to modify /etc/init.d/sysfixtime to account for systems with no RTC, systems with battery backed RTCs, and systems like this with an RTC but no battery backup.

Has also been noted by someone else on https://dev.openwrt.org/ticket/20629

/etc/init.d/sysfixtime
....

boot() {
start && exit 0

local maxtime="$(maxtime)"                            <------ this is not executed because start() succeeds
local curtime="$(date +%s)"
[ $curtime -lt $maxtime ] && date -s @$maxtime

}

start() {
[ -e "$RTC_DEV" ] && [ -e "$HWCLOCK" ] && $HWCLOCK -s -u -f $RTC_DEV
}

.....