Re: Seting the hardware clock
On Monday, 14 July 2003 at 19:16:04 -0400, stan wrote: ;m struggling with getting the hardware clock (BIOS clock) equal to the kernels time. On my Linux boxes a utility called hwclock is run on the way down to synchronize the 2. The problem I'm running into is that if the time on the system gets to far out of date for ntpd to bring it into synch, then I can update the kernels clock with ntpdate. But when I reboot the old incorrect time comes back. I think you have your answer from others, but one thing wasn't made very clear: When you set a FreeBSD (or any other BSD) clock, you automatically set the CMOS clock as well. This is why there is not hwclock(8) program. I can't understand why Linux requires these separate steps. Greg -- When replying to this message, please copy the original recipients. If you don't, I may ignore the reply or reply to the original recipients. For more information, see http://www.lemis.com/questions.html See complete headers for address and phone numbers pgp0.pgp Description: PGP signature
Re: Seting the hardware clock
+-- stan [freebsd] [14-07-03 19:16 -0400]: | ;m struggling with getting the hardware clock (BIOS clock) equal to the | kernels time. | | On my Linux boxes a utility called hwclock is run on the way down to | synchronize the 2. | | The problem I'm running into is that if the time on the system gets to far | out of date for ntpd to bring it into synch, then I can update the kernels | clock with ntpdate. But when I reboot the old incorrect time comes back. From the manual page of ntpdate -b Force the time to be stepped using the settimeofday(2) system call, rather than slewed (default) using the adjtime(2) system call. This option should be used when called from a startup file at boot time. Hope this helps. Regards, Shantanu | | I ran into this during some software testing, that required setting the | clock pretty far off of real time, and it was a PIA to get the machine back | to the correct time. | | How _should_ this be handled? | | -- | They that would give up essential liberty for temporary safety deserve | neither liberty nor safety. | -- Benjamin Franklin | | -- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Seting the hardware clock
stan [EMAIL PROTECTED] writes: ;m struggling with getting the hardware clock (BIOS clock) equal to the kernels time. On my Linux boxes a utility called hwclock is run on the way down to synchronize the 2. The problem I'm running into is that if the time on the system gets to far out of date for ntpd to bring it into synch, then I can update the kernels clock with ntpdate. But when I reboot the old incorrect time comes back. I ran into this during some software testing, that required setting the clock pretty far off of real time, and it was a PIA to get the machine back to the correct time. How _should_ this be handled? Most people run ntpdate before starting ntpd. The rc.conf enable flags for the two programs support this. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Seting the hardware clock
On Tue, Jul 15, 2003 at 08:32:23AM -0400, Lowell Gilbert wrote: stan [EMAIL PROTECTED] writes: ;m struggling with getting the hardware clock (BIOS clock) equal to the kernels time. On my Linux boxes a utility called hwclock is run on the way down to synchronize the 2. The problem I'm running into is that if the time on the system gets to far out of date for ntpd to bring it into synch, then I can update the kernels clock with ntpdate. But when I reboot the old incorrect time comes back. I ran into this during some software testing, that required setting the clock pretty far off of real time, and it was a PIA to get the machine back to the correct time. How _should_ this be handled? Most people run ntpdate before starting ntpd. The rc.conf enable flags for the two programs support this. OK, that's exactly what I _am_ doing. So here is teh scenario that creates the problme. 1. Set the hardware clock to some truly strange time (for testing software). 2. Reboot. a. time is set by the BIOS to the wrong time b. ntpdate corrects this (for the kernel). c. ntp keeps the time acurate (for this run session). 3. shutdown (BIOS time is not corrected). See the problem? -- They that would give up essential liberty for temporary safety deserve neither liberty nor safety. -- Benjamin Franklin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Seting the hardware clock
stan [EMAIL PROTECTED] writes: 1. Set the hardware clock to some truly strange time (for testing software). 2. Reboot. a. time is set by the BIOS to the wrong time b. ntpdate corrects this (for the kernel). c. ntp keeps the time acurate (for this run session). 3. shutdown (BIOS time is not corrected). See the problem? Nope. ntpd is supposed to set the CMOS clock, and it certainly does so for me. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Seting the hardware clock
On Tue, Jul 15, 2003 at 02:55:20PM -0400, Lowell Gilbert wrote: stan [EMAIL PROTECTED] writes: 1. Set the hardware clock to some truly strange time (for testing software). 2. Reboot. a. time is set by the BIOS to the wrong time b. ntpdate corrects this (for the kernel). c. ntp keeps the time acurate (for this run session). 3. shutdown (BIOS time is not corrected). See the problem? Nope. ntpd is supposed to set the CMOS clock, and it certainly does so for me. Interesting. It does not do this under Linux, and I was assuming that the behavior would be the same on FreeBSD. I expect that now that I know thta, I understnad what happened to me. On reboot with the CMOS clock set incorectly ntpd failed to satrt. I thien ran ntpdate by hand. But of course ntpd was no longer running to set the hardware clock. Thanks for making me think this thru. -- They that would give up essential liberty for temporary safety deserve neither liberty nor safety. -- Benjamin Franklin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Seting the hardware clock
;m struggling with getting the hardware clock (BIOS clock) equal to the kernels time. On my Linux boxes a utility called hwclock is run on the way down to synchronize the 2. The problem I'm running into is that if the time on the system gets to far out of date for ntpd to bring it into synch, then I can update the kernels clock with ntpdate. But when I reboot the old incorrect time comes back. I ran into this during some software testing, that required setting the clock pretty far off of real time, and it was a PIA to get the machine back to the correct time. How _should_ this be handled? -- They that would give up essential liberty for temporary safety deserve neither liberty nor safety. -- Benjamin Franklin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Seting the hardware clock
On Mon, Jul 14, 2003 at 04:20:30PM -0700, Marvin J. Kosmal wrote: Sound like the battery is bad.. I would suggest changing the battery. That's not it. If I go intot the BIOS and reset the time to something close, all is well. besides, if it was a battery problem, even when the time was close, power up setting via ntp would be a problme. -- They that would give up essential liberty for temporary safety deserve neither liberty nor safety. -- Benjamin Franklin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Seting the hardware clock
On Monday 14 July 2003 06:16 pm, stan wrote: ;m struggling with getting the hardware clock (BIOS clock) equal to the kernels time. On my Linux boxes a utility called hwclock is run on the way down to synchronize the 2. The problem I'm running into is that if the time on the system gets to far out of date for ntpd to bring it into synch, then I can update the kernels clock with ntpdate. But when I reboot the old incorrect time comes back. I ran into this during some software testing, that required setting the clock pretty far off of real time, and it was a PIA to get the machine back to the correct time. How _should_ this be handled? adjkerntz(8) holds the key to synchronizing kernel and BIOS/CMOS clock time. As for your kernel clock not holding good time, there are ways to correct that too. Ntpd can not keep the popular Soekris boards (based on AMD Elan SC520) in sync without tuning the time standard used in the kernel. Forgot if it gains or loses 4 to 5 minutes per day without mod. Because you are having problems keeping time, and other problems writing time, there may be something odd about your motherboard. Maybe there is something to protect the CMOS clock from being written to? Some sort of BIOS virus protection? Another thing we saw with Soekris and FreeBSD 4.x was that FreeBSD wrote Sunday as 0 but would accept 0 or 7 on read, Soekris clock hardware was happy with 0, but BIOS demanded 7 else it assumed the clock was corrupt and reset its time to Jan 1, 1980. This only mattered if you rebooted on Sunday. Its a 2 byte patch to FreeBSD 4.x, already included in 5.x. -- David Kelly N4HHE, [EMAIL PROTECTED] = The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Seting the hardware clock
At 19:24 7/14/2003, David Kelly, wrote: Another thing we saw with Soekris and FreeBSD 4.x was that FreeBSD wrote Sunday as 0 but would accept 0 or 7 on read, Soekris clock hardware was happy with 0, but BIOS demanded 7 else it assumed the clock was corrupt and reset its time to Jan 1, 1980. This only mattered if you rebooted on Sunday. Its a 2 byte patch to FreeBSD 4.x, already included in 5.x. Where would one find this 2 byte patch for 4.7? Start Here to Find It Fast! - http://www.US-Webmasters.com/best-start-page/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Seting the hardware clock
On Monday 14 July 2003 08:11 pm, W. D. wrote: At 19:24 7/14/2003, David Kelly, wrote: Another thing we saw with Soekris and FreeBSD 4.x was that FreeBSD wrote Sunday as 0 but would accept 0 or 7 on read, Soekris clock hardware was happy with 0, but BIOS demanded 7 else it assumed the clock was corrupt and reset its time to Jan 1, 1980. This only mattered if you rebooted on Sunday. Its a 2 byte patch to FreeBSD 4.x, already included in 5.x. Where would one find this 2 byte patch for 4.7? Look for messages from phk in the soekris-tech mail list archives at http://www.soekris.com/ to be sure of finding the right thing. Nosing around a bit I believe the file is /usr/src/sys/i386/isa/clock.c. The fixed version (copied from 5.1): writertc(RTC_WDAY, (tm + 4) % 7 + 1); /* Write back Weekday */ The old version (+ 1 hacked out of above): writertc(RTC_WDAY, (tm + 4) % 7); /* Write back Weekday */ % cvs log /usr/src/sys/i386/isa/clock.c says: revision 1.191 date: 2002/12/04 13:46:49; author: phk; state: Exp; lines: +1 -1 Use the correct value when writing the Day Of Week byte in the CMOS. The correct range is [1...7] with Sunday=1, but we have been writing [0...6] with Sunday=0. The Soekris computers flagged the zero, zapped the date, so if you rebooted your soekris on a sunday, it would come up with a wrong date. Bruce has a more extensive rework of this code, but we will stick with the minimalist fix for now. Spotted by: Soren Kristensen [EMAIL PROTECTED] Thanks to: Michael Sierchio [EMAIL PROTECTED]. Confirmed by: bde Approved by:re IIRC the comment above about Sunday is incorrect. Have been using 0, but 7 (not 1) is correct. I believe 1-6 is still Monday thru Saturday in both versions. But I'm not going to sweat it tonight. Both versions work on most BIOS's. -- David Kelly N4HHE, [EMAIL PROTECTED] = The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
