Date: Fri, 8 Feb 2008 23:30:12 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: "Oliver B. Warzecha" <obw@amarok.ping.de> Cc: FreeBSD-gnats-submit@freebsd.org, freebsd-i386@freebsd.org Subject: Re: i386/119574: 7.0-RC1 times out in calibrate_clocks() Message-ID: <20080208222001.K25038@besplex.bde.org> In-Reply-To: <20080206155514.GD1361@karnevil9.amarok.ping.de> References: <200801112032.m0BKWFXg001186@karnevil9.amarok.ping.de> <20080113225917.Y50887@delplex.bde.org> <20080206155514.GD1361@karnevil9.amarok.ping.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 6 Feb 2008, Oliver B. Warzecha wrote: > Addon to my last mail, as I just discovered the i440BX-Specs, just > 2 clicks away from one of the pages where I last searched for info. > They are downloadable from > http://www.intel.com/design/intarch/datashts/290562.htm I found I even have the 1998 version of that locally. > On page 84, there is specified that the RTC index register > is write only (as I found out in practical testing :-). And it I think it actually says that the register is more or less readable "Reads ... flow through to the ISA bus, but no RT... will be generated". It says that the register is traditionally write-only. However, ISTR successfully reading this register from debuggers on 5-10 machines over the last 15-20 years. Van Gilluwe's book published in 1993 or 1994 says that the index register is write-only and complains that h/w designers keep making the mistake of write-only registers. Van Gilluwe gives mainly access methods that take not just 2, but 3 ISA accesses to the RTC ports, and 2 I/O delays of 1-16 usec to ensure slowing things down further. The extra RTC access is to turn the NMI disable bit in the index register back off after turning it on together with setting the index. It doesn't bother to preserve either the old or the new index, and always leaves the index set at 0. This NMI bit is more portable than I thought -- the Intel data sheet documents it. This much care with NMIs may be required if NMIs actually happen. FreeBSD is generally careless with NMIs, and doesn't touch the NMI bit in its RTC access functions except to blindly clear it. > is also described as a latch register, which makes the current > code "working by pure chance", as it's implementation dependent > which bus noise happens on the other side of the gate. (If I > didn't get the meaning of "latch" in this case totally wrong) The wording is: "[Index register]: latched by the real time clock..."; [Data register]: Data written to standard RAM bank address selected by RTC Index...". These descriptions conflict a bit. The first one doesn't quite say that the data value at the time of the write to the index register is latched to be read by any later read of the data register, and the second one doesn't quite say that the index register is just a select (latched at the time of read of the data register) for the data. The first behaviour can be tested for (try to latch the current seconds value and read the data register several seconds later and see if you got the old value (*)), but we know that it doesn't work like that on more machines, else my change would break most machines (RTC interrupts would be broken if reading the data register didn't give current data). I think you just have unusual hardware, else more machines would have broken. However, I fear there is a problem somewhere, since RTC interrupts broke a couple of times last week on my main machine (with a VIA VT8237(??) bridge). It's surprising how well FreeBSD works with the statistics clock stopped. I haven't looked at your other hardware reference yet. (*) A quick test using ddb on my hardware shows that reading the data register for the seconds register gives its current value, not the value at the time of the write of the seconds register index (0) to the index register. Then subsequent reads of the data register with no intervening write to the index register keep returning the current seconds register. I tested using ddb, and trust ddb not to access the RTC in normal operation. What does your hardware do for this? Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080208222001.K25038>