Date: Mon, 17 Feb 2003 16:29:06 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Kris Kennaway <kris@obsecurity.org> Cc: current@FreeBSD.ORG, <phk@FreeBSD.ORG> Subject: Re: Clock disabled during DDB Message-ID: <20030217155320.N4682-100000@gamplex.bde.org> In-Reply-To: <20030217020553.GA67649@rot13.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 16 Feb 2003, Kris Kennaway wrote: > Is it an expected feature that the system clock is not updated when > the system is sitting in DDB? Yes. Interrupts must be disabled while ddb is running, so the time cannot be updated normally. Timecounting can mostly work if it is driven by a timecounter with a slow clock and a large mask, but there are few or none such timecounters available. The i8254 timecounter wraps after 1/hz seconds. The TSC wraps after 4G cycles (2 seconds at 2GHz) since we don't (and currently can't) use all its bits. The piix timecounter has a lower frequency than the TSC, but for some reason we mask it to 24 bits (16M cycles @ 3.5+ MHz = 4+ seconds). The acpi timecounter is the same as the piix timecounter except it has more style bugs and less bitrot. Times once sometimes went backwards after exiting ddb due to overflow in timecounter code when the delta-counts were unexpectedly large. I think this has been fixed. Things sometimes (mostly) sort of worked before RELENG_5 (except in my version) because of a bug in ddb -- it didn't mask interrupts properly, so all sorts of interrupts including timeout interrupts were handled while ddb was running unless ddb was invoked with those interrupts already masked. > I just had 8 machines sitting in DDB > for about 20 minutes at boot (because of that &^@%&^ sysctl LOR), and > ntpd refused to time-sync them when I continued, because the clock had > fallen too far behind: > > Feb 16 17:18:08 <ntp.err> gohan12 ntpd[177]: time correction of 1149 seconds exceeds sanity limit (1000); set clock manually to the correct UTC time. > Feb 16 17:18:12 <ntp.err> gohan10 ntpd[177]: time correction of 1155 seconds exceeds sanity limit (1000); set clock manually to the correct UTC time. > Feb 16 17:18:00 <ntp.err> gohan15 ntpd[177]: time correction of 1169 seconds exceeds sanity limit (1000); set clock manually to the correct UTC time. You shouldn't let ddb be invoked on machines that need to keep the correct time. However, I like to invoke ddb on all my machines including my ntp server, so I had to fix this problem years ago :-). My fix involves syncing with the RTC in rtcintr() 2-3 seconds after leaving ddb. My code doesn't work in plain -current because SMPng made rtcintr() a fast interrupt (rtcintr() is a normal interrupt in my kernel but this requires large unfinished changes). It could be done almost as well in an application, preferably ntp itself. ntpd -g might work. What is really needed is a way to force ntpd to step the clock (forwards only) without losing more state than necessary. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030217155320.N4682-100000>