Hardware clock is not SYNC'ed with kernel clock by ntpdate?

Won De Erick won.derick at yahoo.com
Sun Feb 15 17:35:32 PST 2009


Thank you very much for the clear explanation.


--- On Sat, 2/14/09, Oliver Fromme <olli at lurza.secnetix.de> wrote:
> Won De Erick <won.derick at yahoo.com> wrote:
>  > This file /etc/wall_cmos_clock was missing, so I
> created an empty one. 
> 
> So you _do_ want to run your CMOS clock at local time
> instead of UTC?  That is only required if you run a
> different OS on the same machine (dual-boot), because
> Windows expects the CMOS clock to run at local time.
> 

'Not that I want to run at UTC. I wanted to find out how the BMC system event log (SEL) timestamps are done by the BMC firmware. The IBM x343 box is an IPMI v1.5 compliant, and FreeBSD is the only OS installed. I wondered why I got late datestamps on SEL. 

> Otherwise, if FreeBSD is the only OS on that machine,
> it's better to let the CMOS clock run at UTC (i.e. do
> not create /etc/wall_cmos_clock), because it avoids
> all the switching back and forth between time zones,
> and adjkerntz(8) doesn't have to run all the time.
> 
> As far as ntpd is concerned, it doesn't matter.  ntpd
> doesn't care about time zones.  It always works on UTC
> internally and synchronizes the time that way (otherwise
> there would be additional complexities using NTP servers
> in different time zones).  Even the kernel doesn't care
> about time zones.  Handling time zones is done in the
> libc (userland).  So, basically, if a program like
> date(1) displays the time, it converts UTC to your local
> time zone for you.
> 
>  > However, how should I make this automatic, something
>  > that will update
>  > the CMOS clock everytime the kernel clock is
>  > syncronized with a NTP
>  > server? Do I need to make changes on the variables
>  > below?
> 
> You seem to misunderstand.  The CMOS clock _is_ always
> updated when you run ntpd.  You do not have to change
> anything.
> 
> The only question is at which time zone the CMOS clock
> runs, as I've explained above.
> 
> If your CMOS clock runs at UTC (recommended if FreeBSD
> is the only OS on that machine), then the BIOS will
> always display a wrong time, because the BIOS doesn't
> know your time zone, so it can't convert from UTC to
> your time zone.  But that's purely a cosmetical issue.
> You can ignore that.  Your CMOS clock _is_ synchronized
> and runs correctly.  Only your BIOS doesn't know how
> to display it correctly.
> 


This is a cool explanation. This has cleared my assumption that the CMOS clocked is not updated whenever the system is sync'ed with an NTP server.
I think this has narrow down the issue.

Let me share you the problem that I encountered, which had led me to suspect before that CMOS clock was not properly sync'ed. I hope you can give me more hints/explanations for me to come up with a conclusive findings. 

1. Get the date/time in shell
   # date
   Fri Feb 13 14:20:20 PHT 2009

2. Rebooted the box, then entered BIOS config to verify date/time

System Time : 06:25:29            # seems correct, it runs at UTC
System Date : Fri 02/13/2009

3. Let the system up.
4. Unplugged the power cord to come up with a new event in SEL. I am using FreeIPMI v0.7.1 to retrieve the logs.

1724:01-Jan-1970 08:00:12:Power Supply Power Supply 2:Presence detected
1744:01-Jan-1970 08:00:12:Power Supply Power Supply 2:Power Supply input lost (AC/DC)  -------------------> uplug the power.
1764:01-Jan-1970 08:00:12:Power Unit Power Redundancy:Entered from Non-redundant:Insufficient Resources
1784:01-Jan-1970 08:00:41:System Event System Event:Timestamp Clock Synch
1804:12-Feb-2009 14:27:50:System Event System Event:Timestamp Clock Synch
1824:12-Feb-2009 14:28:15:System Event System Event:OEM System Boot Event
1844:12-Feb-2009 14:29:53:System Event System Event:Timestamp Clock Synch
1864:12-Feb-2009 14:29:53:System Event System Event:Timestamp Clock Synch
1884:12-Feb-2009 14:31:55:System Event System Event:OEM System Boot Event -------------------> datestamp incorrect

Is the datestamp '01-Jan-1970' a sign of a defective CMOS battery?
Does the datestamp '12-Feb-2009' being not updated to the correct date (13-Feb-2009) is a sign of a defective battery too? or other issues like firmware bug? I would be grateful to receive more tips from you.


> Best regards
>    Oliver
> 
> -- 
> Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29,
> 85567 Grafing b. M.
> Handelsregister: Registergericht Muenchen, HRA 74606, 
> Geschäftsfuehrung:
> secnetix Verwaltungsgesellsch. mbH, Handelsregister:
> Registergericht Mün-
> chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf
> Erb, Ralf Gebhart
> 
> FreeBSD-Dienstleistungen, -Produkte und mehr: 
> http://www.secnetix.de/bsd
> 
> "The ITU has offered the IETF formal alignment with
> its
> corresponding technology, Penguins, but that won't
> fly."
>         -- RFC 2549
> _______________________________________________
> freebsd-hardware at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
> To unsubscribe, send any mail to
> "freebsd-hardware-unsubscribe at freebsd.org"


      



More information about the freebsd-hardware mailing list