From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 22 05:34:16 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 67CF016A41F for ; Tue, 22 Nov 2005 05:34:16 +0000 (GMT) (envelope-from spork@fasttrackmonkey.com) Received: from angryfist.fasttrackmonkey.com (angryfist.fasttrackmonkey.com [216.220.107.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id 242A643D46 for ; Tue, 22 Nov 2005 05:34:12 +0000 (GMT) (envelope-from spork@fasttrackmonkey.com) Received: (qmail 82556 invoked by uid 2003); 22 Nov 2005 05:27:36 -0000 Received: from spork@fasttrackmonkey.com by angryfist.fasttrackmonkey.com by uid 1001 with qmail-scanner-1.20 (clamscan: 0.65. Clear:RC:1(216.220.116.154):. Processed in 0.058554 secs); 22 Nov 2005 05:27:36 -0000 Received: from unknown (HELO white.nat.fasttrackmonkey.com) (216.220.116.154) by 0 with (DHE-RSA-AES256-SHA encrypted) SMTP; 22 Nov 2005 05:27:35 -0000 Date: Tue, 22 Nov 2005 00:34:29 -0500 (EST) From: Charles Sprickman X-X-Sender: spork@white.nat.fasttrackmonkey.com To: Uwe Doering In-Reply-To: <4382731A.9040904@geminix.org> Message-ID: References: <200511182215.04399.jhb@freebsd.org> <437F79F1.5040706@geminix.org> <200511211149.01165.jhb@freebsd.org> <4382731A.9040904@geminix.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org Subject: Re: 4.8 "Alternate system clock has died" error X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2005 05:34:16 -0000 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@geminix.org | http://www.escapebox.net >