Tech Insider					     Technology and Trends

			      USENET Archives

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
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!
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

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???


Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!security!genrad!grkermit!masscomp!clyde!ihnp4!
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

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

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.


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

			        About USENET

USENET (Users’ Network) was a bulletin board shared among many computer
systems around the world. USENET was a logical network, sitting on top
of several physical networks, among them UUCP, BLICN, BERKNET, X.25, and
the ARPANET. Sites on USENET included many universities, private companies
and research organizations. See USENET Archives.

		       SCO Files Lawsuit Against IBM

March 7, 2003 - The SCO Group filed legal action against IBM in the State 
Court of Utah for trade secrets misappropriation, tortious interference, 
unfair competition and breach of contract. The complaint alleges that IBM 
made concentrated efforts to improperly destroy the economic value of 
UNIX, particularly UNIX on Intel, to benefit IBM's Linux services 
business. See SCO v IBM.

The materials and information included in this website may only be used
for purposes such as criticism, review, private study, scholarship, or

Electronic mail:			       WorldWideWeb: