Bug #8680
closed
Time of Day clock error
100%
Description
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.
Related issues
Updated by Gary Mills over 5 years ago
- Related to Bug #8681: loader: bios loader should check the smap while loading the modules added
Updated by Gary Mills over 5 years ago
I found a workaround for this problem. Add this line to /etc/system:
set tod_validate_enable=0
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.
Updated by Gary Mills over 5 years 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.
Updated by Gary Mills over 5 years 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.
Updated by Electric Monk over 5 years ago
- Status changed from New to Closed
- % Done changed from 0 to 100
git commit 4414ceb126491c1abe47e693790eca5915a15fca
commit 4414ceb126491c1abe47e693790eca5915a15fca
Author: Gary Mills <gary_mills@fastmail.fm>
Date: 2018-01-24T16:32:10.000Z
8680 Time of Day clock error
Reviewed by: Yuri Pankov <yuripv@icloud.com>
Reviewed by: Toomas Soome <tsoome@me.com>
Approved by: Dan McDonald <danmcd@joyent.com>
Updated by Gordon Ross about 3 years ago
I see the same problem occasionally when running as a guest under VMware Fusion.
Apparently ToD clock "jumps" are somewhat normal when running as a VM.
Is there some way we could make this adapt better to being a guest?
Should I open a new issue for that?