Time of Day clock error
When I boot OI on my system, I sometimes see an error message about the hardware clock. When this happens, the date goes back to December 1986. Sometimes I don't get this error and the date and time are correct. In both instances, my BIOS clock shows the correct time. Even after a BIOS upgrade, I saw this error. Here's an excerpt from /var/adm/messages, showing the error:
Dec 27 18:00:00 ryzen genunix: [ID 936769 kern.info] pcieb3 is /pci@0,0/pci1022,1454@8,1 Dec 27 18:00:00 ryzen pcplusmp: [ID 805372 kern.info] pcplusmp: pciclass,0c0330 (xhci) instance 0 irq 0x3b vector 0x82 ioapic 0xff intin 0xff is bound to cpu 1 Dec 27 18:00:01 ryzen genunix: [ID 514117 kern.warning] WARNING: Time of Day clock error: reason [Jumped by 0x39d0099c]. -- Stopped tracking Time Of Day clock. Dec 27 18:00:04 ryzen pcieb: [ID 586369 kern.info] PCIE-device: pci1022,43b2@0,2, pcieb4 Dec 27 18:00:04 ryzen npe: [ID 236367 kern.info] PCI Express-device: pci1022,43b2@0,2, pcieb4
In the messages log, it appears about 90 lines after the SunOS banner.
My system is an ASUS PRIME B350M-A motherboard with an AMD Ryzen 3 1200 Quad-Core CPU. It has two 4-gig DIMMs with an ASUS video card. Booting the latest OI USB image requires a loader that has been patched to fix bug #8651.
#2 Updated by Gary Mills 4 months ago
I found a workaround for this problem. Add this line to /etc/system:
Yes, it's the same statement that has been suggested whenever the illumos kernel code doesn't cooperate with the hardware clock. It certainly works, though. With this addition, the warning messages disappeared, and the date and time were correct again.
#3 Updated by Gary Mills 4 months ago
The workaround proved to be unreliable. After I added a second ethernet interface, this message appeared consistently:
WARNING: Time-of-day chip unresponsive.
The date went back to December 1986. Fortunately, I had NTP running on this system. It corrected the date and time within a few minutes of the reboot.
#4 Updated by Gary Mills 14 days ago
This error happens because the tod_get() function sometimes returns a small number for tv_sec, the number of seconds elapsed since the epoch. This number is always less than 60, suggesting that the RTC hardware was unstable when the registers were being read. Subsequent calls to that function return the correct time.
Also available in: Atom