4.8 "Alternate system clock has died" error

Charles Sprickman spork at fasttrackmonkey.com
Tue Nov 22 05:34:16 GMT 2005


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
> gemini at geminix.org  |  http://www.escapebox.net
>


More information about the freebsd-hackers mailing list