Bug #8680


Time of Day clock error

Added by Gary Mills over 5 years ago. Updated about 3 years ago.

Start date:
Due date:
% Done:


Estimated time:
Gerrit CR:
External Bug:


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] pcieb3 is /pci@0,0/pci1022,1454@8,1
Dec 27 18:00:00 ryzen pcplusmp: [ID 805372] 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] PCIE-device: pci1022,43b2@0,2, pcieb4
Dec 27 18:00:04 ryzen npe: [ID 236367] 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

Related to illumos gate - Bug #8681: loader: bios loader should check the smap while loading the modulesClosedToomas Soome2017-09-22

Actions #1

Updated by Gary Mills over 5 years ago

  • Related to Bug #8681: loader: bios loader should check the smap while loading the modules added
Actions #2

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.

Actions #3

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.

Actions #4

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.

Actions #5

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 <>
Date:   2018-01-24T16:32:10.000Z

    8680 Time of Day clock error
    Reviewed by: Yuri Pankov <>
    Reviewed by: Toomas Soome <>
    Approved by: Dan McDonald <>

Actions #6

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?


Also available in: Atom PDF