Date: Tue, 17 Feb 2009 08:32:34 -0800 (PST) From: Won De Erick <won.derick@yahoo.com> To: Olivier Gautherot <olivier@gautherot.net> Cc: freebsd-hardware@FreeBSD.ORG Subject: Re: Hardware clock is not SYNC'ed with kernel clock by ntpdate? Message-ID: <538199.46897.qm@web45808.mail.sp1.yahoo.com>
next in thread | raw e-mail | index | archive | help
Hi All, Is this firmware-related bug? tool log parsing error? Thanks in advance. --- On Mon, 2/16/09, Won De Erick <won.derick@yahoo.com> wrote: > Thank you very much for the clear explanation. >=20 > --- On Sat, 2/14/09, Oliver Fromme > <olli@lurza.secnetix.de> wrote: > > Won De Erick <won.derick@yahoo.com> wrote: > > > This file /etc/wall_cmos_clock was missing, so I > > created an empty one.=20 > >=20 > > 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. > >=20 >=20 > '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.=20 >=20 > > 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. > >=20 > > As far as ntpd is concerned, it doesn't matter.=20 > 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. > >=20 > > > 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? > >=20 > > You seem to misunderstand. The CMOS clock _is_ always > > updated when you run ntpd. You do not have to change > > anything. > >=20 > > The only question is at which time zone the CMOS clock > > runs, as I've explained above. > >=20 > > 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. > >=20 >=20 >=20 > 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. >=20 > 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.=20 >=20 > 1. Get the date/time in shell > # date > Fri Feb 13 14:20:20 PHT 2009 >=20 > 2. Rebooted the box, then entered BIOS config to verify > date/time >=20 > System Time : 06:25:29 # seems correct, it runs > at UTC > System Date : Fri 02/13/2009 >=20 > 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. >=20 > 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 >=20 > 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. >=20 >=20 > > Best regards > > Oliver > >=20 > > --=20 > > Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz > 29, > > 85567 Grafing b. M. > > Handelsregister: Registergericht Muenchen, HRA 74606,=20 > > Gesch=E4ftsfuehrung: > > secnetix Verwaltungsgesellsch. mbH, Handelsregister: > > Registergericht M=FCn- > > chen, HRB 125758, Gesch=E4ftsf=FChrer: Maik Bachmann, > Olaf > > Erb, Ralf Gebhart > >=20 > > FreeBSD-Dienstleistungen, -Produkte und mehr:=20 > > http://www.secnetix.de/bsd > >=20 > > "The ITU has offered the IETF formal alignment > with > > its > > corresponding technology, Penguins, but that won't > > fly." > > -- RFC 2549 > > _______________________________________________ > > freebsd-hardware@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-hardware > > To unsubscribe, send any mail to > > "freebsd-hardware-unsubscribe@freebsd.org"=0A=0A=0A
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?538199.46897.qm>