Charles Sprickman wrote:
On Tue, 22 Nov 2005, Uwe Doering wrote:
Charles Sprickman wrote:
[...]
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?
No. User supplied patches in PRs aren't necessarily 100% correct. In
this case the PR submitter clears pending interrupts while interrupt
generation is disabled. However, the committer of 1.214 (John Baldwin,
in fact) thought that this is wrong because you have to clear pending
interrupts after interrupt generation has been re-enabled, or else you'd
get a race condition. And I agree with that.
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? :)
Not only that. In case of kernel issues they also have to have quite a
lot of knowledge and experience in kernel hacking. If you botch a
kernel patch and don't notice in time you'll likely cause quite a lot of
grief for the users.
[...]
If anyone wants to satisfy my curiousity about this whole clock issue,
I'd be grateful. A few questions:
RTC = "CMOS clock"?
Right.
Does the RTC supply all timing in a system, or just "time of day"?
Just the latter (once at boot time) and also the RTC interrupt
('stathz'). Perhaps 'profhz' too, if you enable profiling. Can't tell
offhand.
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?
There's another clock device, which 'hz' is derived of, for example.
Perhaps one can call it the CPU clock. It drives the CPU, memory, PCI
bus etc. Also, while the system is running it drives the kernel's
time-of-day clock. However, the CPU clock's frequency isn't overly
accurate. That's why the kernel's time-of-day clock usually deviates
pretty much from the wall clock unless you apply some form of continuous
adjustment, for instance NTP.
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]"
