On Tue, 22 Nov 2005, Uwe Doering wrote:
Charles Sprickman wrote:
On Mon, 21 Nov 2005, John Baldwin wrote:
On Saturday 19 November 2005 02:16 pm, Uwe Doering wrote:
John Baldwin wrote:
[...]
Actually, there was a patch that was committed in 5.4 and 6.0 for this
issue. You can see the diff here:
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/i386/isa/clock.c.diff?r1=1.
213&r2=1.214&f=h
That patch would probably backport to 4.x fairly easily.
I just looked at RELENG_4, and yes, backporting should be easy. Though
I haven't tried it yet on our machines.
I wonder, however, what's writing to the RTC on a running server. Could
this event perhaps have been triggered by the recent Daylight Saving
Time switch?
Yep. Also, if you are using ntp, then the adjustments to the time are
getting
pushed back to the RTC as well.
I run ntp everywhere.
So it certainly looks easy enough for me to change the first two sections
of the diff referenced above, but I'm having issues finding that last one
in cpu_initclocks(). It looks like that section really has changed quite a
bit. (see v.1.206)
Just look for all instances of
writertc(RTC_STATUSB, rtc_statusb);
and put
rtcin(RTC_INTR);
directly behind them (into the next line). There should be three of them, in
4.8 as well as RELENG_4 and CURRENT.
I found the first two (line 721 and 979) and I see third at line 1064.
One other question, looking at the initial patch
(http://www.freebsd.org/cgi/query-pr.cgi?pr=17800), I see that they
followed a slightly different line:
/* Initialize RTC. */
writertc(RTC_STATUSA, rtc_statusa);
writertc(RTC_STATUSB, RTCSB_24HR); <<<---
+ rtcin(RTC_INTR); /* clear any pending interrupt */
Should I worry about that at all?
Is there any interest in moving this back to 4-STABLE?
Interest there is, I suppose. Plenty of people still run 4.x. The question
is rather whether there is any committer willing to do the backport. As far
as I can tell, most of them are more focused on newer branches. Perhaps we
need special backporting committers for legacy branches. Just a thought. ;-)
Yeah, I work on a total of about 32 boxes, all still at either 4.8 or
4.11. Committers have to know C, right? :)
And lastly, is there any snippet of code that can twiddle the clock from
userspace and determine if it's wedged or dead?
You may want to look at adjkerntz(8).
Running the standard "adjkerntz -a" gives no errors, but I'm not sure if
that tells me anything. The manpage does say that if it has a problem it
will log it... Also built it with the DEBUG define uncommented and it's
still silent.
If anyone wants to satisfy my curiousity about this whole clock issue, I'd
be grateful. A few questions:
RTC = "CMOS clock"?
Does the RTC supply all timing in a system, or just "time of day"?
How does this line relate to things? kern.clockrate: { hz = 100, tick =
10000, tickadj = 5, profhz = 1024, stathz = 128 }
If the RTC doesn't supply the base timing for things like all the I/O
busses, processor, what does?
Maybe a new thread for that?
Thanks,
Charles
Uwe
--
Uwe Doering | EscapeBox - Managed On-Demand UNIX Servers
[EMAIL PROTECTED] | http://www.escapebox.net
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
