Bug #8680

Time of Day clock error

Added by Gary Mills 11 months ago. Updated 7 months ago.

Status:ClosedStart date:2017-09-22
Priority:NormalDue date:
Assignee:-% Done:


Target version:-
Difficulty:Medium Tags:needs-triage


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

Related to illumos gate - Bug #8681: loader: bios loader should check the smap while loading the modules Closed 2017-09-22


#1 Updated by Gary Mills 11 months ago

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

#2 Updated by Gary Mills 11 months 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.

#3 Updated by Gary Mills 11 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 7 months 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.

#5 Updated by Electric Monk 7 months ago

  • % Done changed from 0 to 100
  • Status changed from New to Closed

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>

Also available in: Atom