On Tuesday 22 November 2005 04:35 am, Uwe Doering wrote: > 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.
Yeah, put the rtcin() after both writes have been completed. > >>> 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. Well, if your box boots ok with it then send me a diff in an e-mail and I'll backport it. Note, however, that there isn't going to be a 4.12 release. > > 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. Yes, it does provide profhz as well. When you start profiling a process, we reprogram the RTC to interrupt at profhz and divided down to still call statclock at stathz (see the fiddling with pscnt and psdiv). > > 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. Actually, the timer for 'hz' is ISA timer #0. There are three ISA timers, 0, 1, and 2. I have no idea if 1 has a common use though I don't think FreeBSD uses it. timer 2 drives the pc speaker, and timer 0 can generate a periodic interrupt. The three timers are in the i8254 "chip" (part of the southbridge LPC stuff in modern systems). On 6.0 and later we do actually use a per-CPU timer known as the lapic (short for Local APIC) timer to drive 'hz', 'stathz', and 'profhz' on systems using an APIC. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"