Bug #8680

Time of Day clock error

Added by Gary Mills about 1 month ago. Updated 20 days ago.

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

0%

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

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

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

History

#1 Updated by Gary Mills 30 days ago

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

#2 Updated by Gary Mills 24 days 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 20 days 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.

Also available in: Atom