Re: CURRENT is freezing again ...

2000-11-19 Thread Mark Huizer

On Thu, Nov 16, 2000 at 12:20:49PM -0500, Steven E. Ames wrote:
 It seems to only do it SMP... the same machine built with a non-SMP
 kernel (same source code) runs just fine for extended periods.

I have a non-SMP machine that is running a 15-nov current kernel, which
freezes a few times a day. This morning I found it might coincide with
the times that cvsup is running. Disabled that, I'll see if that's where
the problem might show up.
Freeze means: no keyboard activity possible, machine just does nothing.
 
   On Thu, 16 Nov 2000, Soren Schmidt wrote:
  
 After last cvsup my machine (Dual PIII, SMP kernel) is freezing
 again in
 10 min after boot...
   
You mean "is still freezing" right ?
   
Current has been like this for longer than I care to think about,
 it
seems those in charge doesn't take these problems seriously
 (enough)...
  
   I think info about where/how it freezing would be more helpful.
 
  No idea, the system just freezes, no drob to DDB no remote gdb no
  nothing, so its really hard to tell where...
  As to how, just boot current on a fairly fast machine, make a kernel
  and it'll hang in minutes if not less, or just leave it alone and
  it will hang in 10-30 mins...
 
  -Søren
 
 
  To Unsubscribe: send mail to [EMAIL PROTECTED]
  with "unsubscribe freebsd-current" in the body of the message
 
 
 
 
 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with "unsubscribe freebsd-current" in the body of the message

-- 
Nice testing in little China...


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: Typo in labpc.c

2000-11-19 Thread Julian Elischer

Peter Dufault wrote:
 
 
   This seems to only do the cdevsw_add if the malloc failed. I presume
   this is the opposit of the intended sense. I'll fix it up if you also
   think it looks wrong.
  
   If nobody have noticed in "17 months, 2 weeks ago" (as cvs-web says)
   that labpc doesn't work, the labpc driver should be killed, not fixed.
  
   Objections ?
  
  What you are saying is that people who may be using this driver have
  not yet moved up to -current or 4.x and as such should not be allowed
  to?
 
  I'm saying:
 
 "If nobody have noticed in "17 months, 2 weeks ago" (as cvs-web says)
 that labpc doesn't work, the labpc driver should be killed, not fixed."
 
  That's 1.5 year Julian, and if nobody *who is using it* objects it goes.
 
 For the record: If anyone wants labpc tested and kept up to date send
 me a card and I'll test it at each stable release cycle.  Even better,
 also send me the register compatible DAQCARD 1200 PC card version.
 
 My former client using a batch of those cards obviously
 isn't staying up to date on the OS.  Anyone who upgrades a working
 system will be just as upset if it doesn't work as if it is gone
 so I defer on the axe discussion.

I gather you aren't in a position to test using your former client's 
cards.. ("former" is a bit of a clue I guess). What are the chances that
he may decide one day to upgrade? (e.g. to support a new PC)


 
 Peter
 
 --
 Peter Dufault ([EMAIL PROTECTED])   Realtime development, Machine control,
 HD Associates, Inc.   Fail-Safe systems, Agency approval
 
 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with "unsubscribe freebsd-current" in the body of the message

-- 
  __--_|\  Julian Elischer
 /   \ [EMAIL PROTECTED]
(   OZ) World tour 2000
--- X_.---._/  presently in:  Budapest
v


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: Typo in labpc.c

2000-11-19 Thread Peter Dufault

  For the record: If anyone wants labpc tested and kept up to date send
  me a card and I'll test it at each stable release cycle.  Even better,
  also send me the register compatible DAQCARD 1200 PC card version.
  
  My former client using a batch of those cards obviously
  isn't staying up to date on the OS.  Anyone who upgrades a working
  system will be just as upset if it doesn't work as if it is gone
  so I defer on the axe discussion.
 
 I gather you aren't in a position to test using your former client's 
 cards.. ("former" is a bit of a clue I guess). What are the chances that
 he may decide one day to upgrade? (e.g. to support a new PC)

We aren't enemies, and they will probably be clients again.  I
could test things down their on my own dime but it would be too
big a dime. I'd be better off buying a board on my own but I'm not
going to.

These are manufacturing test stands for medical equipment that have
been "validated" in their limited environment.  They have identical
spare computers, will install 3.4, and set them up and test the
test stands following a formal step by step procedure.  They don't
need me to help them and they probably won't upgrade for the life
of the current product unless they needed to change production
numbers.

Unlike many projects, this sort is extremely close-ended.  One of
the things we do during release is to make sure every feature is
specified and has a test, and I happily go through and rip out
those features without that.  That's why it is hard for me to argue
with Poul.

Peter

--
Peter Dufault ([EMAIL PROTECTED])   Realtime development, Machine control,
HD Associates, Inc.   Fail-Safe systems, Agency approval


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: Typo in labpc.c

2000-11-19 Thread Julian Elischer

Peter Dufault wrote:
 
   For the record: If anyone wants labpc tested and kept up to date send
   me a card and I'll test it at each stable release cycle.  Even better,
   also send me the register compatible DAQCARD 1200 PC card version.
  
   My former client using a batch of those cards obviously
   isn't staying up to date on the OS.  Anyone who upgrades a working
   system will be just as upset if it doesn't work as if it is gone
   so I defer on the axe discussion.
 
  I gather you aren't in a position to test using your former client's
  cards.. ("former" is a bit of a clue I guess). What are the chances that
  he may decide one day to upgrade? (e.g. to support a new PC)
 
 We aren't enemies, and they will probably be clients again.  I
 could test things down their on my own dime but it would be too
 big a dime. I'd be better off buying a board on my own but I'm not
 going to.
 
 These are manufacturing test stands for medical equipment that have
 been "validated" in their limited environment.  They have identical
 spare computers, will install 3.4, and set them up and test the
 test stands following a formal step by step procedure.  They don't
 need me to help them and they probably won't upgrade for the life
 of the current product unless they needed to change production
 numbers.
 
 Unlike many projects, this sort is extremely close-ended.  One of
 the things we do during release is to make sure every feature is
 specified and has a test, and I happily go through and rip out
 those features without that.  That's why it is hard for me to argue
 with Poul.

My thinking is that there are others like them out there
using these cards, that are not in 'regular contact' with the freeBSD
community.
If these cards are dropped entirely, then we never hear from them again,
as when they need to upgrade for somereason, they just say "stuffit,
let's use linux". We don;t even KNOW we 
pissed off users. 
If we have a driver (with the typo fixed)
then at least we'll hear from them if it doesn't work, and get a chance
to
fix it.. if we do we are noce guys and they sing praise of our support.
in either case I think we are no worse off, and probably better off than
if we delete
the file, and silently lose users. We certainly don't know who wants to
use
BSD in the future for some cute control operation..

 
 Peter
 
 --
 Peter Dufault ([EMAIL PROTECTED])   Realtime development, Machine control,
 HD Associates, Inc.   Fail-Safe systems, Agency approval

-- 
  __--_|\  Julian Elischer
 /   \ [EMAIL PROTECTED]
(   OZ) World tour 2000
--- X_.---._/  presently in:  Budapest
v


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: Cardbus fixes

2000-11-19 Thread Justin T. Gibbs

I'll have to look up the CIS_PTR spec.  I'm not sure I like hardwiring
things like this.

Where did you get a copy of the pccard spec?  Do you have to order
it from the pcmcia SIG?

--
Justin


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



pccardd dies with SIGSEGV [PATCH included]

2000-11-19 Thread Daniel M. Eischen

Many weeks ago, I noticed that pccardd died with a SIGSEGV when
I inserted my Motorola Montana 33.6 fax/modem.  I'm not sure of
the exact time as to when this occurred, but I know that pccardd
had been working just fine with this card.  I finally found the
time to track down the problem (now that I really need to use it).

Here's an excerpt from `pccardc dumpcis`:

  Tuple #2, code = 0x15 (Version 1 info), length = 39
  000:  04 01 4d 6f 74 6f 72 6f 6c 61 00 4d 4f 4e 54 41
  010:  4e 41 20 33 33 2e 36 20 46 41 58 2f 4d 4f 44 45
  020:  4d 00 56 32 2e 30 00
  Version = 4.1, Manuf = [Motorola], card vers = [MONTANA 33.6 FAX/MODEM]
  Addit. info = [V2.0],[]
   ^^ Note this field is empty

When pccardd reads the field above, the length is supposedly 4,
but garbage is read in and the field is not terminated with a
null character.  This causes problems later on when the field
is copied using strdup().

Attach is a patch that fixes the problem for me.  I can offer
a `pccardc dumpcis` and a full gdb session that shows the problem
to anyone interested.

-- 
Dan Eischen

Index: readcis.c
===
RCS file: /opt/b/CVS/src/usr.sbin/pccard/pccardd/readcis.c,v
retrieving revision 1.20
diff -u -r1.20 readcis.c
--- readcis.c   2000/06/18 20:22:11 1.20
+++ readcis.c   2000/11/19 16:30:57
@@ -202,7 +202,9 @@
cp-manuf = NULL;
}
if (len  1  *p != 0xff) {
-   cp-manuf = strdup(p);
+   /* cp-manuf = strdup(p); */
+   cp-manuf = xmalloc(len + 1);
+   strncat(cp-manuf, p, len);
while (*p++  --len  0);
}
if (cp-vers) {



Error in libstdc++ buildworld

2000-11-19 Thread Mark R Grant

FreeBSD user since 2.x, but never attempted to make/build/install world.

While doing 'make -j2 buildworld':

=== libstdc++

~~~deleted a couple hundred lines between, then got here:

cc -pg -O -pipe -I/usr/src/gnu/lib/libstdc++
-I/usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/include
-I/usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/../libio -I.
-I/usr/obj/usr/src/i386/usr/include -c
/usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/../libio/floatconv.c
-o floatconv.po
{standard input}: cc: Assembler messages:
Internal compiler error: program cc1 got fatal signal 11{standard
input}:0:
Warning: end of file not at end of a line; newline inserted
{standard input}:2148: Error: bad register name `%'
*** Error code 1
1 error
*** Error code 2
1 error
*** Error code 2
1 error
*** Error code 2
1 error
*** Error code 2
1 error

Got the same error after several cvs updates and retries.

Mark Grant
[EMAIL PROTECTED]



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: Error in libstdc++ buildworld

2000-11-19 Thread Mark R Grant

David O'Brien wrote:

 On Sun, Nov 19, 2000 at 09:54:58AM -0600, Mark R Grant wrote:
  FreeBSD user since 2.x, but never attempted to make/build/install world.
  While doing 'make -j2 buildworld':

 It would help us immensely if you would give some details of the
 environment in which you are having this problem.
 What CLFAGS are you using?  What version of FreeBSD are you running?


Following my interpretation of the instructions in the make.conf file, the
CFLAGS line is commented out.
I am running version 4.1.1-RELEASE, trying to upgrade to -CURRENT using the
'RELENG_4' tag.  Last cvsup was Nov 18, 2300 GMT



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: Error in libstdc++ buildworld

2000-11-19 Thread David O'Brien

On Sun, Nov 19, 2000 at 10:44:09AM -0600, Mark R Grant wrote:
 David O'Brien wrote:

Respect my "Reply-To: [EMAIL PROTECTED]" or I won't respond to queries
for help in the future.
 
 Following my interpretation of the instructions in the make.conf file, the
 CFLAGS line is commented out.
 I am running version 4.1.1-RELEASE, trying to upgrade to -CURRENT using the
 'RELENG_4' tag.  Last cvsup was Nov 18, 2300 GMT

One cannot "upgrade"[*] to -CURRENT using he "RELENG_4" tag.  The
"RELENG_4" is the 4.x code base.  To get -CURRENT source one would use no
tag.  RELENG_4 is very buildable right now, so something is weird on your
end.  You'll [again] need to give more _details_.
Example:

1. I checked out the source using ``cd /usr ; cvs co src''
2. I then made sure the /usr/obj/ directory existed.
3. I then did ``cd /usr/src ; make world''.


[*] "upgrading" to -CURRENT really doesn't mean anything as it isn't a
release and for your use it may easily be a "downgrade".  You should
examine your reasons for wanting to run -CURRENT.

-- 
-- David  ([EMAIL PROTECTED])
  GNU is Not Unix / Linux Is Not UniX


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: Cardbus fixes

2000-11-19 Thread Nate Williams

 I'll have to look up the CIS_PTR spec.  I'm not sure I like hardwiring
 things like this.
 
 Where did you get a copy of the pccard spec?  Do you have to order
 it from the pcmcia SIG?

Mike has my really old copy you can have (if you can get it from him),
and I think FreeBSD Inc. bought Warner a copy.

It's *HUGE*.



Nate


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: Cardbus fixes

2000-11-19 Thread Warner Losh

In message [EMAIL PROTECTED] Nate Williams writes:
:  I'll have to look up the CIS_PTR spec.  I'm not sure I like hardwiring
:  things like this.
:  
:  Where did you get a copy of the pccard spec?  Do you have to order
:  it from the pcmcia SIG?
: 
: Mike has my really old copy you can have (if you can get it from him),
: and I think FreeBSD Inc. bought Warner a copy.

Yes, they did.  Since it was FreeBSD, Inc a limited sharing of the
electronic version may be permitted (I have to go look at the license
that came with the cdrom, but I think it said limited sharing within
the organization is permitted).

: It's *HUGE*.

Yes.  It takes up more space than the cabinet that I keep 90% of my
pcmcia/cardbus cards in :-).  I'd have been happy with the cdrom
only.

Warner


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Mini head's up: [Fwd: cvs commit: src/etc crontab]

2000-11-19 Thread Doug Barton

Per discussion that ensued after the most round of DST changes last
month, I've changed the default time for the periodic/daily job to
3:01am (0301). The commit message describes the reasoning, and many,
many more details are available in the mail archives. 

Enjoy,

Doug

 Original Message 
Subject: cvs commit: src/etc crontab
Date: Sun, 19 Nov 2000 10:16:47 -0800 (PST)
From: Doug Barton [EMAIL PROTECTED]
To: [EMAIL PROTECTED], [EMAIL PROTECTED]

dougb   2000/11/19 10:16:47 PST

  Modified files:
etc  crontab 
  Log:
  When to run the periodic/daily event has had several rounds of
discussion
  over the past couple years. The most recent came to the general
consensus
  that this was the best time, but no one actually made the change, so
I'll
  don my asbestos undies and dive in.
  
  Please note that this time was chosen with input from people in
various
  countries with various methods and schedules for switching to and from
DST.
  There is no perfect time to schedule this job that works for everyone,
but
  this time both A) Works for more people, and B) Causes problems for
fewer
  people. And, ultimately, you can always change it if you need to.
  
  Revision  ChangesPath
  1.23  +2 -2  src/etc/crontab


http://www.FreeBSD.org/cgi/cvsweb.cgi/src/etc/crontab.diff?r1=1.22r2=1.23f=h


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: Error in libstdc++ buildworld

2000-11-19 Thread Mark R Grant

David O'Brien wrote:


 Example:

 1. I checked out the source using ``cd /usr ; cvs co src''
 2. I then made sure the /usr/obj/ directory existed.
 3. I then did ``cd /usr/src ; make world''.

 [*] "upgrading" to -CURRENT really doesn't mean anything as it isn't a
 release and for your use it may easily be a "downgrade".  You should
 examine your reasons for wanting to run -CURRENT.

Now, here is where I am.  For precision, I decided to take it step-by-step again
and document every action:

0.  The CHFLAGS setting my my make.conf file is commented out.
1.  I cleaned up the source directories using "cd /usr ; make cleandir"
2.  I cleaned up the object directories using "cd /usr/obj ; chflags -R noschg *
; rm -rf *"
3.  I edited by cvs-supfile to "tag=*" then checked out the source using "cd
/usr/src ; cvsup -g -L 2 /usr/local/etc/cvs-supfile"
4.  I decided that since I am too much of a novice at this, I should use the
buildworld and installworld seperately.  I ran "cd /usr/src ; make -j2
buildworld"

This is where it errored out, somewhere during the building of "=== rpcsrv"

///deleted several hundred messages///

cd /usr/src/secure/lib/libcrypto; make beforeinstall
sh /usr/src/tools/install.sh -c -o root -g wheel -m 444 bsd.README bsd.dep.mk
bsd.doc.mk bsd.docb.mk bsd.info.mk bsd.kern.mk bsd.kmod.mk bsd.lib.mk
bsd.libnames.mk bsd.man.mk bsd.obj.mk bsd.own.mk bsd.port.mk bsd.port.post.mk
bsd.port.pre.mk bsd.port.subdir.mk bsd.prog.mk bsd.sgml.mk bsd.subdir.mk sys.mk
/usr/obj/usr/src/i386/mk
usage: install [-CcDpsv] [-f flags] [-g group] [-m mode] [-o owner] file1 file2
   install [-CcDpsv] [-f flags] [-g group] [-m mode] [-o owner] file1 ...
 fileN directory
   install -d [-v] [-g group] [-m mode] [-o owner] directory ...
*** Error code 64
1 error
*** Error code 2
1 error
*** Error code 2
1 error
*** Error code 2
1 error



I can provide all/more of the script output



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



/etc/local/rc.conf not working?

2000-11-19 Thread janb

the rc.conf on my computer sets the sendmail enable flag to NO, and yet on
bootup the sendmail daemon is started. ps -ax confirms this with sendmail:
accepting connections

JAn



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: /etc/local/rc.conf not working?

2000-11-19 Thread Doug Barton

[EMAIL PROTECTED] wrote:
 
 the rc.conf on my computer sets the sendmail enable flag to NO, and yet on
 bootup the sendmail daemon is started. ps -ax confirms this with sendmail:
 accepting connections

Do you actually have the file in /etc/local as the subject of your
email suggests? If so, that's your problem. You want to have rc.conf
and/or rc.conf.local in /etc/ itself. 

Good luck,

Doug
-- 
Life is an essay test. Long form. Spelling counts.

Do YOU Yahoo!?


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: Cardbus fixes

2000-11-19 Thread Wes Peters

Warner Losh wrote:
 
 In message [EMAIL PROTECTED] Nate Williams writes:
 :  I'll have to look up the CIS_PTR spec.  I'm not sure I like hardwiring
 :  things like this.
 : 
 :  Where did you get a copy of the pccard spec?  Do you have to order
 :  it from the pcmcia SIG?
 :
 : Mike has my really old copy you can have (if you can get it from him),
 : and I think FreeBSD Inc. bought Warner a copy.
 
 Yes, they did.  Since it was FreeBSD, Inc a limited sharing of the
 electronic version may be permitted (I have to go look at the license
 that came with the cdrom, but I think it said limited sharing within
 the organization is permitted).

If it permits sharing within the "engineering department" perhaps we should
just mount it in a drive on freefall.  That's the usual sharing arrangement
within for-profit companies, and only FreeBSD "associates" have access to
freefall.

-- 
"Where am I, and what am I doing in this handbasket?"

Wes Peters Softweyr LLC
[EMAIL PROTECTED]   http://softweyr.com/


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: Cardbus fixes

2000-11-19 Thread Warner Losh

In message [EMAIL PROTECTED] Wes Peters writes:
: If it permits sharing within the "engineering department" perhaps we should
: just mount it in a drive on freefall.  That's the usual sharing arrangement
: within for-profit companies, and only FreeBSD "associates" have access to
: freefall.

I think that we can do that (or I can just put them in my local
directory).  We can't put them on a web page, however.  I had them in
a private directory for a while.

I'm having problems finding the cdrom, so I'm having problems finding
the exact license that we have the cdrom under.  Some of them restrict
things to one geographic division, while others do not.  Until then,
I'm not going to make them generally available to all FreeBSD
developers.  I may make them available on an as needed basis to
bonified cardbus workers (which I define arbitrarily as people that
have submitted code for cardbus).

BTW, http://www.pcisig.com/order/index.php3 has the pci specs on a
cdrom for an excellent deal on pci specs.

Warner


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: /etc/local/rc.conf not working?

2000-11-19 Thread Gregory Neil Shapiro

janb the rc.conf on my computer sets the sendmail enable flag to NO, and
janb yet on bootup the sendmail daemon is started. ps -ax confirms this
janb with sendmail: accepting connections

At least as of November 6th, the only rc.conf files are
/etc/defaults/rc.conf, /etc/rc.conf, and /etc/rc.conf.local.  There is no
/etc/local/rc.conf.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: /etc/local/rc.conf not working?

2000-11-19 Thread janb

OOPs, well this was the problem. That leaves me wondering, why this is on
two places...

Thanks,

JAN

On Sun, 19 Nov 2000, Doug Barton wrote:

 [EMAIL PROTECTED] wrote:
  
  the rc.conf on my computer sets the sendmail enable flag to NO, and yet on
  bootup the sendmail daemon is started. ps -ax confirms this with sendmail:
  accepting connections
 
   Do you actually have the file in /etc/local as the subject of your
 email suggests? If so, that's your problem. You want to have rc.conf
 and/or rc.conf.local in /etc/ itself. 
 
 Good luck,
 
 Doug
 -- 
 Life is an essay test. Long form. Spelling counts.
 
   Do YOU Yahoo!?
 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: /etc/local/rc.conf not working?

2000-11-19 Thread Gregory Neil Shapiro

janb OOPs, well this was the problem. That leaves me wondering, why this is on
janb two places...

/etc/defaults/rc.conf are the defaults -- you should not be editing that
file.  Any settings you want to change to in /etc/rc.conf (which should be
a small file, not a copy of /etc/defaults/rc.conf).


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Clock Strangeness in UP Kernel

2000-11-19 Thread Thomas D. Dean

The clock is strange in -current UP.

# uname -a
FreeBSD celebris 5.0-CURRENT FreeBSD 5.0-CURRENT #1: \
  Sun Nov 19 17:53:38 PST 2000 \
  root@celebris:/usr/src/sys/compile/CELEBRIS  i386

dmesg is attached.  Some of the garbage at the top of dmesg is from 2
kernels ago, 15 Nov., when I was running SMP and had silo overflows.

Both timecounters are listed in dmesg:
...
Timecounter "i8254"  frequency 1193026 Hz
Timecounter "TSC"  frequency 121329898 Hz
...

I have 
options CLK_USE_I8254_CALIBRATION
in my config.

Some recent output from ntpdate log: (I changed the server from
140.142.16.34 to ).

...
18 Nov 16:29:41 ntpdate[10276]: step time server  offset -443.428520 sec
18 Nov 20:29:41 ntpdate[10463]: step time server  offset -443.462177 sec
19 Nov 00:29:41 ntpdate[10799]: step time server  offset -443.474425 sec
19 Nov 04:29:42 ntpdate[11305]: step time server  offset -443.515112 sec
19 Nov 08:29:41 ntpdate[11536]: step time server  offset -443.437881 sec
19 Nov 12:29:42 ntpdate[11855]: step time server  offset -443.461982 sec
19 Nov 16:29:41 ntpdate[12378]: step time server  offset -443.430663 sec

The step has a high std. dev.  I see values of 115 to 2900 sec over
the past few days.  The machine was up for 3 days, 10 hours, before
rebooting an hour ago.

tomdean

= dmesg 
B/s transfers (10.000MHz, offset 8), Tagged Queueing Enabled
da2: 3090MB (6328861 512 byte sectors: 255H 63S/T 393C)
da0 at ncr0 bus 0 target 0 lun 0
da0: QUANTUM FIREBALL1080S 1Q09 Fixed Direct Access SCSI-2 device 
da0: 10.000MB/s transfers (10.000MHz, offset 8)
da0: 1042MB (2134305 512 byte sectors: 255H 63S/T 132C)
Mounting root from ufs:/dev/da1s1a
da1 at ncr0 bus 0 target 1 lun 0
da1: IBM DNES-309170 SAH0 Fixed Direct Access SCSI-3 device 
da1: 10.000MB/s transfers (10.000MHz, offset 8), Tagged Queueing Enabled
da1: 8748MB (17916240 512 byte sectors: 255H 63S/T 1115C)
SMP: AP CPU #1 Launched!
de0: enabling BNC port
sio0: 1 more silo overflow (total 1)
sio0: 1 more silo overflow (total 2)
sio0: 1 more silo overflow (total 3)
sio0: 2 more silo overflows (total 5)
boot() called on cpu#1
Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped
Waiting (max 60 seconds) for system process `syncer' to stop...stopped

syncing disks... 
done
Uptime: 6m6s
RebooCopyright (c) 1992-2000 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.0-CURRENT #1: Sun Nov 19 17:53:38 PST 2000
root@celebris:/usr/src/sys/compile/CELEBRIS
Timecounter "i8254"  frequency 1193026 Hz
Timecounter "TSC"  frequency 121329898 Hz
CPU: Pentium/P54C (121.33-MHz 586-class CPU)
  Origin = "GenuineIntel"  Id = 0x525  Stepping = 5
  Features=0x3bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,APIC
real memory  = 100663296 (98304K bytes)
avail memory = 94822400 (92600K bytes)
Preloaded elf kernel "kernel" at 0xc0302000.
Preloaded userconfig_script "/boot/kernel.conf" at 0xc030209c.
Intel Pentium detected, installing workaround for F00F bug
npx0: math processor on motherboard
npx0: INT 16 interface
pcib0: Host to PCI bridge at pcibus 0 on motherboard
pci0: PCI bus on pcib0
ncr0: ncr 53c810 fast10 scsi port 0xec00-0xecff mem 0xfedfbf00-0xfedfbfff irq 11 at 
device 1.0 on pci0
isab0: Intel 82378IB PCI to ISA bridge at device 2.0 on pci0
isa0: ISA bus on isab0
pci0: Matrox MGA Millennium 2064W graphics accelerator at 6.0 irq 9
de0: Digital 21041 Ethernet port 0xe880-0xe8ff mem 0xfedfbe80-0xfedfbeff irq 10 at 
device 8.0 on pci0
de0: DEC DE450-CA 21041 [10Mb/s] pass 1.1
de0: address 00:00:f8:02:76:db
atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0
atkbd0: AT Keyboard irq 1 on atkbdc0
psm0: PS/2 Mouse irq 12 on atkbdc0
psm0: model Generic PS/2 mouse, device ID 0
fdc0: NEC 72065B or clone at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0
fdc0: FIFO enabled, 8 bytes threshold
fd0: 1440-KB 3.5" drive on fdc0 drive 0
ppc0: Parallel port at port 0x378-0x37f irq 7 on isa0
ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode
lpt0: Printer on ppbus0
lpt0: Interrupt-driven port
sc0: System console on isa0
sc0: VGA 16 virtual consoles, flags=0x200
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 16550A
sio1 at port 0x2f8-0x2ff irq 3 on isa0
sio1: type 16550A
vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0
unknown: IBM Enhanced (101/102-key) KC can't assign resources
unknown: Microsoft PS/2 Mouse can't assign resources
unknown: 16550 compatible COM device can't assign resources
unknown: 16550 compatible COM device can't assign resources
unknown: LPT printer port can't assign resources
unknown: Floppy Controller can't assign resources
Waiting 10 seconds for SCSI devices to settle
Mounting root from ufs:/dev/da1s1a
cd0 at ncr0 bus 0 target 5 lun 0
cd0: TOSHIBA CD-ROM XM-5401TA 3605 Removable CD-ROM SCSI-2 device 
cd0: 4.237MB/s transfers (4.237MHz, offset 8)