From owner-freebsd-i386@FreeBSD.ORG Wed Feb 6 11:50:02 2008 Return-Path: Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD69816A419 for ; Wed, 6 Feb 2008 11:50:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9CD0013C45B for ; Wed, 6 Feb 2008 11:50:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m16Bo2ZE052815 for ; Wed, 6 Feb 2008 11:50:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m16Bo2Qi052814; Wed, 6 Feb 2008 11:50:02 GMT (envelope-from gnats) Date: Wed, 6 Feb 2008 11:50:02 GMT Message-Id: <200802061150.m16Bo2Qi052814@freefall.freebsd.org> To: freebsd-i386@FreeBSD.org From: "Oliver B. Warzecha" Cc: Subject: Re: i386/119574: 7.0-RC1 times out in calibrate_clocks() X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Oliver B. Warzecha" List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2008 11:50:02 -0000 The following reply was made to PR i386/119574; it has been noted by GNATS. From: "Oliver B. Warzecha" To: Bruce Evans Cc: FreeBSD-gnats-submit@FreeBSD.ORG, freebsd-i386@FreeBSD.ORG Subject: Re: i386/119574: 7.0-RC1 times out in calibrate_clocks() Date: Wed, 6 Feb 2008 12:37:21 +0100 Okay, it took some time, one reason the machine in question being used as my router, which reduces research options when test booting kernels... On Mon, Jan 14, 2008 at 12:11:34AM +1100, Bruce Evans wrote: > On Fri, 11 Jan 2008, Oliver B. Warzecha wrote: > > >As I noticed that rtcin() was reworked during the change to 7.0, > >(http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/i386/isa/clock.c.diff?r1=1.222.2.2;r2=1.239.2.1;f=h) > >it occurred to me that perhaps there might be some condition > >in the new code. > > Probably. I wrote both. Apparently I optimized rtcin() too much. > Try adding some delays to it, and/or more debugging code. For debugging > code, just read the RTC index register and verify that it is set to > the memory value that is supposed to track it. Check after writing > to it and when the write is avoided because it already has the desired > value according to the memory value. I came relatively fast to the conclusion that reading the register leads nowhere, it seems to be a write-only register that never yields the value just written to it. > > > > /* Read the mc146818A seconds counter. */ > > for (;;) { > > if (!(rtcin(RTC_STATUSA) & RTCSA_TUP)) { > > sec = rtcin(RTC_SEC); > > break; > > } > > if (--timeout == 0) > > goto fail; > > } > >// printf("seconds counter read ... \n"); > > The optimization might break this by going too fast -- it now reads the > status register as fast as possible, where before it had lots of delays. > It still has the delays (supposed to be done more carefully than before > when switching to reading the seconds register, so I would expect the > read of the seconds register to be as correct as before, but it apparently > isn't. I have found at least one design - one of these compact PC on a PCI card designs: http://www.pt.com/Manuals_Legacy/ZT_5510_Manual_PTI.pdf - where it is explicitely mentioned in the documentation that for repeated access to the same register in the RTC you have to set the address register again. This card is also based on the HX chipset, maybe this limitation was lifted in newer designs. Maybe accesses on newer systems are fast enough that any capacitors in the circuit are refreshed, whatever, this is pure speculation. It is tough to find some definitive documentation on the net about this issue. Anyway, at least for this specific case, it seems that only the original way of clock access was the right one, I am afraid. For what it's worth, I just checked the linux sources, it's also straight "write address register, then read/write data" there. It would be nice to have some definitive documentation on that case, but I have no idea right now. OBW (rest snipped, as it does not apply as long as the register is not read correctly)