Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!decvax!harpo!seismo!hao!hplabs!sri-unix!root@cit-vax
From: root%cit-vax@sri-unix.UUCP
Newsgroups: net.unix-wizards
Subject: 4.2 crashes
Message-ID: <12965@sri-arpa.UUCP>
Date: Tue, 25-Oct-83 13:25:23 EST
Article-I.D.: sri-arpa.12965
Posted: Tue Oct 25 13:25:23 1983
Date-Received: Mon, 31-Oct-83 02:57:22 EST
Lines: 18
From: Root of All Evil <root@cit-vax>
We just installed 4.2bsd and have since been getting crashes every
few hours. These are usually trap type 9 or 8, i.e. illegal memory
references, and are for the most part in the clist manipulation routines
(as evidenced by the "pc =" part of the trap message). Has anyone else
met with these problems in putting up 4.2bsd?
Another, possibly related, problem is that every once in a while a
terminal (on a dz11) will just hang. "pstat -t" says that it is
"awaiting output". Killing the process on the terminal leaves it
<exiting>, presumably waiting for the terminal in a close. It isn't the
dz because it happens on several of them.
Are these related? Might it be hardware? Any ideas would be
appreciated. I have a hard time believing that 4.2 would be distributed
with such glaring bugs, but my hardware worked fine under 4.1.
* Eric Holstege Caltech, Pasadena, CA.
* eric@cit-vax eric@cit-20
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site ucbvax.UUCP
Path: utzoo!linus!decvax!tektronix!ucbcad!ucbvax!sam
From: sam@ucbvax.UUCP
Newsgroups: net.unix-wizards
Subject: Re: 4.2 crashes
Message-ID: <160@ucbvax.UUCP>
Date: Sat, 29-Oct-83 21:30:27 EST
Article-I.D.: ucbvax.160
Posted: Sat Oct 29 21:30:27 1983
Date-Received: Fri, 11-Nov-83 21:33:19 EST
References: <12965@sri-arpa.UUCP>, <1127@uwvax.ARPA>
Organization: U.C. Berkeley
Lines: 20
I have spoken to a number of people running 4.2 and none
have experienced the problem mentioned, nor have any bug
reports been mailed to Berkeley regarding such a problem
(I'm no longer there to get phone calls, so I wouldn't know
if you called). Since you presumably have a crash dump,
you should be able to at least give more information than
it crashes with a trap 8/9 and/or lots of dz's hang. Even
differentiating between trap type 8 and 9 would be useful.
It is almost always a simple matter to get a stack trace
from a crash dump. Try the following after your system
reboots and savecore has recorded the dump;
% cd /usr/crash (or similar)
% adb -k vmunix.XX vmcore.XX
....
*(scb-4)$c
This should give you a stack trace. If it doesn't, then
you have to search for the stack frame on the interrupt or
system stack (there should always be a recognizable frame
on the interrupt stack if a dump was performed); once again
not too difficult, but more than I care to discuss here.
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!vaxine!wjh12!genrad!decvax!harpo!floyd!clyde!ihnp4!
inuxc!pur-ee!uiucdcs!parsec!kolstad
From: kolstad@parsec.UUCP
Newsgroups: net.unix-wizards
Subject: Re: 4.2 crashes - (nf)
Message-ID: <3583@uiucdcs.UUCP>
Date: Tue, 1-Nov-83 23:25:42 EST
Article-I.D.: uiucdcs.3583
Posted: Tue Nov 1 23:25:42 1983
Date-Received: Fri, 4-Nov-83 08:28:33 EST
Lines: 7
#R:sri-arpa:-1296500:parsec:44200014:000:147
parsec!kolstad Oct 31 20:59:00 1983
The guys at SMU have had these identical problems. I assumed it was
their brand new (and hence unproven hardware). Can anyone help???
Rob
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!security!genrad!grkermit!masscomp!clyde!ihnp4!
inuxc!pur-ee!uiucdcs!parsec!kolstad
From: kolstad@parsec.UUCP
Newsgroups: net.unix-wizards
Subject: Re: 4.2 crashes - (nf)
Message-ID: <3893@uiucdcs.UUCP>
Date: Wed, 16-Nov-83 23:20:06 EST
Article-I.D.: uiucdcs.3893
Posted: Wed Nov 16 23:20:06 1983
Date-Received: Thu, 17-Nov-83 23:52:32 EST
Lines: 17
#R:sri-arpa:-1296500:parsec:44200015:000:515
parsec!kolstad Nov 16 11:58:00 1983
I should have posted a reply earlier.
As I understand, a half dozen or so "erroneous tapes" were mailed out
with a cleverer-but-defective routine to save some time calling a clock
routine. I received almost instant help by calling Berkeley and had
the SMU machine fixed post haste by changing less than a dozen lines of
code.
Since those fixes (which almost everyone else received in their standard
distribution), the SMU machine has neither crashed nor hung a DZ.
Good stuff, that BSD distribution.
Rob
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site qubix.UUCP
Path: utzoo!linus!decvax!decwrl!qubix!msc
From: msc@qubix.UUCP (Mark Callow)
Newsgroups: net.unix-wizards
Subject: 4.2 performance
Message-ID: <669@qubix.UUCP>
Date: Tue, 29-Nov-83 22:01:00 EST
Article-I.D.: qubix.669
Posted: Tue Nov 29 22:01:00 1983
Date-Received: Thu, 1-Dec-83 23:49:32 EST
Organization: Qubix Graphic Systems, Saratoga, CA
Lines: 51
We have just converted our Vax 11/750 from 4.1bsd to 4.2bsd.
The system is currently terribly terribly slow. Since I haven't
seen any other comments about 4.2's performance I hadn't expected
it to be slower. In fact I expected it to be faster.
The system is slow slow that vi is a pain and you can sometimes
watch individual characters being written to the terminal even
though the baud rate is 9600. Also I am having troubles with
uucp timing out. I increased PKTIME in the packet driver but I still
get timeouts. I was running rtiuucp on 4.1 (which is also the one
distributed with 4.2) and it was absolutely rock solid. The system
is verging on the unusable and is slower than a Sun running 4.1c
When we changed over to 4.2 we also added a Fujitsu Eagle disk
on a new controller in addition to one rm05. Having thus introduced
interleaved swapping plus having moved the user file systems to a
second disk arm plus having the 4.2 file system I expected to see a
significant improvement. I also added an Interlan ethernet controller.
When I was working on the system alone during the conversion work my
feeling was that compilations were significantly faster and that other
things that I was doing (mostly editing) were about the same.
I have watched vmstat and cannot see any sign of excessive interrupts,
context switches, system calls or paging all though I am hampered in
my interpretation of the output because I never looked at it much when we
were running 4.1. The only noticeable thing is that the cpu idle time
is frequently 0% when our normal load (18 users) is on the system.
I have also looked at ps and have seen what appear to be very low priorities
(eg 75 for ccom). Are such low priorities to be expected? One other strange
thing I noticed is that rvcat which is spawned by the new lpr program has
priority -1 even when its status is given as R. I thought negative
priorities meant a process was waiting for something.
Can anyone give me any suggestions of areas to watch and possible
causes of this slow running. What are other users' experiences with
4.2? Any responses are welcome. I will summarize to the net if
sufficient interest is shown.
For reference our configuration is:
Vax 11/750 - no fpa, 2MB memory, 2dz11, 2 Emulex dh's,
- 1 Interlan 10 Mbit/s ethernet controller
1 rm05 on massbus 0
1 tu77 on massbus 1
1 eagle on massbus 2 using Emulex controller.
1 lp11 and controller
1 Versatec v80 and 121 controller
--
From the Tardis of Mark Callow
msc@qubix.UUCP, decwrl!q...@Berkeley.ARPA
...{decvax,ucbvax,ihnp4}!decwrl!qubix!msc, ...{ittvax,amd70}!qubix!msc