Date: Tue, 22 Nov 2005 08:41:41 -0500 From: John Baldwin <jhb@freebsd.org> To: Uwe Doering <gemini@geminix.org> Cc: Charles Sprickman <spork@fasttrackmonkey.com>, freebsd-hackers@freebsd.org Subject: Re: 4.8 "Alternate system clock has died" error Message-ID: <200511220841.42863.jhb@freebsd.org> In-Reply-To: <4382E664.2050005@geminix.org> References: <Pine.OSX.4.61.0511182152380.2298@gee5.nat.fasttrackmonkey.com> <Pine.OSX.4.61.0511220009140.529@white.nat.fasttrackmonkey.com> <4382E664.2050005@geminix.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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=3D17800), 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'l= l=20 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, w= e=20 reprogram the RTC to interrupt at profhz and divided down to still call=20 statclock at stathz (see the fiddling with pscnt and psdiv). > > How does this line relate to things? kern.clockrate: { hz =3D 100, tick= =3D > > 10000, tickadj =3D 5, profhz =3D 1024, stathz =3D 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,=20 1, and 2. I have no idea if 1 has a common use though I don't think FreeBS= D=20 uses it. timer 2 drives the pc speaker, and timer 0 can generate a periodi= c=20 interrupt. The three timers are in the i8254 "chip" (part of the southbrid= ge=20 LPC stuff in modern systems). On 6.0 and later we do actually use a per-CP= U=20 timer known as the lapic (short for Local APIC) timer to drive 'hz',=20 'stathz', and 'profhz' on systems using an APIC. =2D-=20 John Baldwin <jhb@FreeBSD.org> =A0<>< =A0http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" =A0=3D =A0http://www.FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200511220841.42863.jhb>