Date: Sat, 9 Feb 2008 06:20:02 GMT From: Bruce Evans <brde@optusnet.com.au> To: freebsd-i386@FreeBSD.org Subject: Re: i386/119574: 7.0-RC1 times out in calibrate_clocks() Message-ID: <200802090620.m196K20c064260@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR i386/119574; it has been noted by GNATS.
From: Bruce Evans <brde@optusnet.com.au>
To: "Oliver B. Warzecha" <obw@amarok.ping.de>
Cc: Bruce Evans <brde@optusnet.com.au>, FreeBSD-gnats-submit@freebsd.org,
freebsd-i386@freebsd.org
Subject: Re: i386/119574: 7.0-RC1 times out in calibrate_clocks()
Date: Sat, 9 Feb 2008 17:13:45 +1100 (EST)
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?200802090620.m196K20c064260>