Date: Sat, 9 Feb 2008 17:13:45 +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: <20080209162051.N28112@besplex.bde.org> In-Reply-To: <20080209013526.GA1216@karnevil9.amarok.ping.de> References: <200801112032.m0BKWFXg001186@karnevil9.amarok.ping.de> <20080113225917.Y50887@delplex.bde.org> <20080206155514.GD1361@karnevil9.amarok.ping.de> <20080208222001.K25038@besplex.bde.org> <20080209013526.GA1216@karnevil9.amarok.ping.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 9 Feb 2008, Oliver B. Warzecha wrote: > 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 happen to have an old BX system online. It is my only system handy that has an unreadable port 0x70: %%% Intel 82371AB/EB/MB PIIX4/4E/4M ISA Bridge on an Abit BP6 port 0x70 is w/o (reads return 0xff) optimized RTC accesses work NVIDIA nForce MCP2 ISA Bridge on an ASUS A7N8X-E port 0x70 is r/w optimized RTC accesses work VIA VT8237(??) PCI to ISA Bridge on a Gigabyte K8VT800 port 0x70 is r/w optimized RTC accesses work ATI <card=0x30b0103c chip=0x43771002> PCI-ISA bridge on an HP nx6325 port 0x70 is r/w optimized RTC accesses work %%% > 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." Maybe it is actually readable on the i815. On my 82371, FreeBSD never sets the NMI bit in writes, so the read return of 0xff indicates that even the NMI bit is w/o. > 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. Or it may be w/o mainly on original ATs and Intel chipsets. > 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. I think I had nothing between PIIX1 and PIIX4 except some other VIA chipsets. The system with the PIIX1 still works but is not worth turning on even for testing :-). >> 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... The RTC is almost never accessed accept by rtcintr(), and with LAPIC timer interrupts rtcintr() is not used. At least a few years ago, the only other RTC accesses were for reading the time and initializing the RTC and the fd driver on bootup, for setting the time later, and for APM and maybe ACPI to reinitialize the RTC after un-suspend (the un-suspend hook seems to be broken on amd64). ntpd only sets the RTC when it steps the clock; slews by ntpd and timed only do micro-adjustments which don't affect the RTC. Since the RTC is rarely accessed by anything except rtcintr(), missing locking for the accesses rarely mattered. (The locking is mostly fixed now.) > 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). There would only be timing preoblems like that if the hardware is really primitive or has weird latching semantics. I see no problems with the index and data register accesses separated by many seconds due to my typing in the accesses in ddb. > 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 checked your other reference, where the need to rewrite the index register but not much else is clearly stated. Was that for the 430HX? > 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. My PIIX1 is on the slghtly earlier and/or lower end P55TP4XE. > 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. ;) Any configuration 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. It's just "call inb(port) and call outb(port, data)", where inb() and outb() are ordinary functions whose sole purpose is to let ddb call them (the kernel uses inline or different versions of these in normal operations). ddb can call any function (but most not safely, and these not safely unless the parameters are safe) and the man page is too small to list them all. I sometimes miss inw/outw/inl/outl but am too lazy to add these to ddb. My 1980's debugger has these. Ports could also be mapped to (virtual) memory so that you can examine and write to them using memory access commands and not have to learn a different and less convenient set of commands. My 1980's debugger doesn't do this but copies DOS DEBUG with minor improvements. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080209162051.N28112>