Date: Sat, 9 Feb 2008 02:35:26 +0100 From: "Oliver B. Warzecha" <obw@amarok.ping.de> To: Bruce Evans <brde@optusnet.com.au> Cc: FreeBSD-gnats-submit@freebsd.org, freebsd-i386@freebsd.org Subject: Re: i386/119574: 7.0-RC1 times out in calibrate_clocks() Message-ID: <20080209013526.GA1216@karnevil9.amarok.ping.de> In-Reply-To: <20080208222001.K25038@besplex.bde.org> References: <200801112032.m0BKWFXg001186@karnevil9.amarok.ping.de> <20080113225917.Y50887@delplex.bde.org> <20080206155514.GD1361@karnevil9.amarok.ping.de> <20080208222001.K25038@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Feb 08, 2008 at 11:30:12PM +1100, Bruce Evans wrote: > 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. Note that I have a 430HX chipset, the datasheet of the 82371SB is some kind of vague concerning the RTC access, in fact only the NMI functionality seems documented there. I also checked the ICH (i815) specs, on page 234 of the PDF (p. 8-44) it says: "Software must preserve the value of bit 7 at I/O addresses 70h and 74h. When writing to these addresses, software must first read the value, and then write the same value for bit 7 during the sequential address write." Given that in the 440BX documentation there is a written "Attribute: write-only", which is admittedly contradicted in the next sentence, which you quoted below, it may well be that the access specification for this particular address has changed over time. > >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. Well... IIRC a read of the register always resulted in 0xA9 here, no matter what was written before. But "more or less readable" seems to describe the status quo quite well. ;-) Do you remember if there was any machine with a HX chipset in your list of machines. Perhaps this is a peculiarity of the 82437SB. I see that this chip (also called PIIX3) was also used in the VX chipset. > Van Gilluwe's book published in 1993 or 1994 says that the index Oh :-) This was the book that I thought to be helpful if after some googling. > 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. Mmmh... NMIs seem to be used for indicating ECC errors in RAM. But this is a different story... > 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 I think this may be well the major problem here, that the descriptions are less than clear and the specifications have varied over the years. > 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). What is the call profile? Does "read same register again" happen in the normal use case? Or maybe there are intermittent accesses which mask the problem. It might even be depending on a running ntpd or timed, which is correcting the RTC... Also, this machine here is relatively slow (200 Mhz K6), it can also be that on a faster machine the access follows up fast enough so that the circuits behind that gate keep state (see my comment on capacitors in a past mail). > 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. Given this other reference I think that the problem might only occur in this particular chip set (As I mentioned, it's the reference for a "PC on a PCI card" system which uses the 430HX). I don't think, a 430HX is that unusual, although it's rapidly reaching highschool age. Given that the problem only gets noticed when the machine boots up under surveillance (When it gets switched on it does come up after some minutes... if unattended, you might not notice the delay) I just found I have another HX board lying around here (a P55T2P4 - no SCSI and only 4 mem slots), maybe I can slap something together, so I can check it with this one, major problem being the AT power supply. A pragmatic solution would be to implement both the "secure" and the "fast" strategy and to select the correct one at boot time after checking for signs that the "fast" does not work, for example. A config option might be overkill. ;) > (*) 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? Having played around with ddb now, how do you do it? I don't see any possibility to access I/O space besides writing some assembler code. Coming from a happy 6502/68k background, where all I/O was memory mapped, I am scratching my head here. That the man page for ddb needs an urgent update does not help here, too. So maybe I missed the command, there seem to be roughly 4 dozen undocumented options for show only. OBW
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080209013526.GA1216>