Date: Thu, 24 Apr 1997 15:27:09 +0200 (CEST) From: Are Bryne <are@communique.no> To: Bruce Evans <bde@zeta.org.au> Cc: freebsd-hackers@freebsd.org Subject: Re: kern/3375: Ten minute delay at boot-time Message-ID: <Pine.BSF.3.96.970424150451.184A-100000@rune> In-Reply-To: <199704231715.DAA11851@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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. */
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.970424150451.184A-100000>