Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 10 Nov 1996 00:29:59 +0200 (SAT)
From:      Khetan Gajjar <khetan@iafrica.com>
To:        Jim Riffle <rif@ns.kconline.com>
Cc:        questions@freebsd.org, Greg Hormann <ghormann@ns.kconline.com>, msmith@atrad.adelaide.edu.au
Subject:   Re: Perhaps the same lock up problem
Message-ID:  <Pine.BSF.3.95.961110001901.2917E-100000@chain-work.iafrica.com>
In-Reply-To: <Pine.BSI.3.95.961109164010.10031A-100000@ns.kconline.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 9 Nov 1996, Jim Riffle wrote:

>Within the past month, my 2.1.5-Stable machine has seemingly crashed in
>the same manner as these people's machines twice.  I am writing this

Well, this is good and bad news - good in that I'm not the only one, bad
in that it's affecting other people as well.

>server still would function, and I was logged in via PPP, and that was

I noticed that a ssh I had to another machine was responding perfectly,
but as soon as I logged out of that machine, the session did not respond
anymore (i.e. when I exited the ssh and was returned to my machine).

>>*mumble*  our gateway/server box took a dive on thursday, and I've only
>>just mostly got it back up (it fell over a little while after I got 
>>home this afternoon, screen saver & network were going, but no disk,
>>no login.  Bad.)

The biggest problem is the lack of the drives syncing - I lose quite a bit
when it fails to do that :-(

>My machins has been really stable up until this month and I have not
>changed anything, except it is serving more  hits and generally just
>getting busyier.

My machine had all the source rebuilt on it. It was running 2.2-current
prior to the tree split, and is now running (although I hate to use that
phrase :-) 3.0-current. It also moved locations and ethernet (although I
doubt it's those two). I suspect the source rebuild.

>Anyone else thing this same thing is happening to them?  I am unsure if
>all 4 of us are having the same trouble, but it appears to be that way.

As an aside, I discovered some things which I added/changed in my kernel
which made the machine MUCH more stable (in fact, it's been up for 2
hours, the previous record being 3 minutes.

I added

options         DDB_UNATTENDED	<-- sounded useful
options         KTRACE		<-- sounded useful
options         DIAGNOSTIC 	<-- what I think is making it work

to my kernel, and literally removed everything that wasn't critical, like
the drive controller, the drives and the ethernet interface. I also 
reduced the max windows, etc, etc. It definitely looks like a kernel
problem (in my case).

I tried it with a generic kernel (a 2.1 generic kernel, in fact), and it
appeared stable. It is also quite stable (with a unmodified -current
and/or generic kernel) in single user mode - but who wants to be in single
user mode ?

>FreeBSD 2.1.5-Stable

FreeBSD chain.iafrica.com 3.0-CURRENT FreeBSD 3.0-CURRENT #0: Sun Nov 10
00:15:36 SAT 1996     root@:/usr/src/sys/compile/KHETAN-DEBUG  i386

>P5-133
>32 Megs ram
>Adaptec 2940 Ultra SCSI host adapter
>sd0 - Segate ST32430N 2 Gig SCSI drive
>sd1 - MICROP 4421-07 2 Gig SCSI drive
>sd2 - HP Tape Backup Drive

Output from my dmesg :

Copyright (c) 1992-1996 FreeBSD Inc.
Copyright (c) 1982, 1986, 1989, 1991, 1993
	The Regents of the University of California.  All rights reserved.

FreeBSD 3.0-CURRENT #0: Sun Nov 10 00:15:36 SAT 1996
    root@:/usr/src/sys/compile/KHETAN-DEBUG
Calibrating clock(s) relative to mc146818A clock ... i8254 clock: 1193320 Hz
CPU: i486DX (486-class CPU)
real memory  = 50331648 (49152K bytes)
avail memory = 47091712 (45988K bytes)
Probing for devices on the ISA bus:
sc0 at 0x60-0x6f irq 1 on motherboard
sc0: VGA color <16 virtual consoles, flags=0x0>
ed0 at 0x300-0x31f irq 5 on isa
ed0: address 00:80:c8:2e:e4:2c, type NE2000 (16 bit) 
wdc0 at 0x1f0-0x1f7 irq 14 on isa
wdc0: unit 0 (wd0): <WDC AC21000H>
wd0: 1033MB (2116800 sectors), 2100 cyls, 16 heads, 63 S/T, 512 B/S
wdc0: unit 1 (wd1): <QUANTUM FIREBALL1080A>
wd1: 1039MB (2128896 sectors), 2112 cyls, 16 heads, 63 S/T, 512 B/S
wdc1 at 0x170-0x177 irq 15 on isa
wdc1: unit 0 (wd2): <ST1144AT>
wd2: 124MB (255255 sectors), 1001 cyls, 15 heads, 17 S/T, 512 B/S
npx0 on motherboard
npx0: INT 16 interface
changing root device to wd1a
file: table is full
file: table is full
file: table is full
file: table is full
file: table is full
file: table is full
file: table is full
file: table is full
file: table is full
file: table is full
file: table is full
file: table is full
file: table is full
file: table is full
file: table is full
file: table is full
file: table is full

I see this "file: table is full" error just now - any ideas what it means
?

>I am not sure if we all are having the same troubles here, but it appears
>like that may be the case here.

I would agree, except that I'm running -current, where things like this
are supposed to happen. It hasn'thappened before though, and besides for
myself, none of you are tracking -current (afaik). It's just frustrating
when your make world is finished (succesfully), you reboot and the PC is
basically totally unuseable - and it's not a matter of core dumping or
libraries being mangled - it's a matter of COMPLETE lack of ability to do
anything.

Oh well. Here's hoping for a soln.


--khg





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.961110001901.2917E-100000>