From owner-freebsd-hardware@FreeBSD.ORG Tue Feb 17 16:32:35 2009 Return-Path: Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46F3E1065690 for ; Tue, 17 Feb 2009 16:32:35 +0000 (UTC) (envelope-from won.derick@yahoo.com) Received: from n54.bullet.mail.sp1.yahoo.com (n54.bullet.mail.sp1.yahoo.com [98.136.44.32]) by mx1.freebsd.org (Postfix) with SMTP id 23ED18FC24 for ; Tue, 17 Feb 2009 16:32:34 +0000 (UTC) (envelope-from won.derick@yahoo.com) Received: from [69.147.84.145] by n54.bullet.mail.sp1.yahoo.com with NNFMP; 17 Feb 2009 16:32:34 -0000 Received: from [69.147.84.116] by t8.bullet.mail.sp1.yahoo.com with NNFMP; 17 Feb 2009 16:32:34 -0000 Received: from [127.0.0.1] by omp208.mail.sp1.yahoo.com with NNFMP; 17 Feb 2009 16:32:34 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 778689.53283.bm@omp208.mail.sp1.yahoo.com Received: (qmail 47683 invoked by uid 60001); 17 Feb 2009 16:32:34 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=rxphflGqBDRshVW7EWB3PUowMDys3azQqkYtssPLkJRen9yqbX+y1vd/m3p+sECIoavyjaI/YVLXaieQ2RApJC39lWvyyzxatTwzKMBsQqGxyr5WAo19DHJ8Z4kmXqg3wUfI48953vjW7tua83FbNFUVIdXVAEClLNx6W1eUbRE=; X-YMail-OSG: 4m1xYMYVM1lQXIlQhAayszXpD9YNavlBDeMqUZcyf8SB4OsLUspLPmLUz_qGcR91gwiqIqWdLhu.yOz6ZCtUZOyN1AY1WrtmutfXFKr6IFySs_Itsx6lbs.iF3TN3WTozliYTaprYAdKsr3hVol.2G3Mz7E22.HMQOj0qpGqfNuLhmU1wzrTqh5EWOlDpz8- Received: from [58.71.34.137] by web45808.mail.sp1.yahoo.com via HTTP; Tue, 17 Feb 2009 08:32:34 PST X-Mailer: YahooMailWebService/0.7.260.1 Date: Tue, 17 Feb 2009 08:32:34 -0800 (PST) From: Won De Erick To: Olivier Gautherot MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <538199.46897.qm@web45808.mail.sp1.yahoo.com> Cc: freebsd-hardware@FreeBSD.ORG Subject: Re: Hardware clock is not SYNC'ed with kernel clock by ntpdate? X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: won.derick@yahoo.com List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 16:32:42 -0000 Hi All, Is this firmware-related bug? tool log parsing error? Thanks in advance. --- On Mon, 2/16/09, Won De Erick wrote: > Thank you very much for the clear explanation. >=20 > --- On Sat, 2/14/09, Oliver Fromme > wrote: > > Won De Erick 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