i386/119574: 7.0-RC1 times out in calibrate_clocks()

[Bruce Evans]

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