From owner-freebsd-hackers Thu Apr 24 06:37:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id GAA06443 for hackers-outgoing; Thu, 24 Apr 1997 06:37:27 -0700 (PDT) Received: from www.communique.no (www.communique.no [193.212.204.33]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id GAA06438 for ; Thu, 24 Apr 1997 06:37:25 -0700 (PDT) Received: (qmail 212 invoked by uid 1001); 24 Apr 1997 13:27:09 -0000 Date: Thu, 24 Apr 1997 15:27:09 +0200 (CEST) From: Are Bryne X-Sender: are@rune To: Bruce Evans cc: freebsd-hackers@freebsd.org Subject: Re: kern/3375: Ten minute delay at boot-time In-Reply-To: <199704231715.DAA11851@godzilla.zeta.org.au> Message-ID: Organization: Communique DA MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Thank you for your patch, Bruce. I applied it, and rebooted (shutdown -r now). Using -v at the boot prompt, I was given: Calibrating clock(s) ... i586 clock: 133662709 Hz, i8254 clock: 1202460 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency CLK_USE_I586_CALIBRATION not specified - using old calibration method It seemed to speed along just fine, and I did not notice any 10 second delay (as is now the new timeout). Then, as I'd forgotten to use -c (to enable the psm0 - why is it that it is disabled by default?), I did another reboot, this time with -cv. Now I got (and why is it that this first part - before vis. config - doesn't get added to /var/log/messages?): Calibrating clock(s) ... failed, using default i8254 clock of 1193182Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency This time it waited for about ten secs. before continuing (entering config). Does this mean the RTC isn't quite stable? Should I add any of the noted CALIBRATION options? And one last thing: Sometimes when shuting down, /var/log/messages is appended with a lot of junk like this ESC[mESC[8;1HESC[mESC[9;1HESC[mESC[m. What's up? Thank you very much for your attention and help. Are Bryne On Thu, 24 Apr 1997, Bruce Evans wrote: > > The system seems to freeze right after the boot prompt. I can enter > > e.g a -c at the prompt, or nothing, but after pressing return, the > > system will stay put for ten minutes before it continues booting. > > This is probably caused by broken RTC (clock) hardware. If this is the > case, then you can probably tell by booting with -v and noticing that the > delay occurs after the "Calibrating clock(s) ... " message. There is a > timeout, but it is too large (apparently 10 minutes on your system). > > > This happens with both the generic kernel, and my own one. > > It also seems as if the time lapse is _not_ recorded, so that the > > clock (as seen with date) sags behind by ten minutes afterwards. > > The clock is not supposed to stop. Perhaps the i/o's to initialize it > somehow stop it. This would explain both problems. Try this fix. The > reduced timeout should reduce the delay to < 10 seconds on your machined > even if the other change doesn't work. The timeout is still too large > for i386's. > > diff -c2 clock.c~ clock.c > *** clock.c~ Mon Apr 7 19:36:15 1997 > --- clock.c Thu Apr 24 03:08:45 1997 > *************** > *** 504,509 **** > --- 568,576 ---- > writertc(u_char reg, u_char val) > { > + inb(0x84); > outb(IO_RTC, reg); > + inb(0x84); > outb(IO_RTC + 1, val); > + inb(0x84); /* XXX work around wrong order in rtcin() */ > } > > *************** > *** 524,528 **** > if (!(rtcin(RTC_STATUSD) & RTCSD_PWR)) > goto fail; > ! timeout = 100000000; > > /* Read the mc146818A seconds counter. */ > --- 591,595 ---- > if (!(rtcin(RTC_STATUSD) & RTCSD_PWR)) > goto fail; > ! timeout = 1000000; /* XXX */ > > /* Read the mc146818A seconds counter. */ >