Some good press on SunOS 4.0

Rob McMahon cudcv%warwick.ac.uk at nss.cs.ucl.ac.uk
Fri Feb 10 14:10:20 AEST 1989


steinmetz!dawn!stpeters at uunet.uu.net writes:
>According to 'uptime', my group's server has been up 113 days now.

Hmm, here's the uptime from our two multi-user machines, this is Saturday
lunchtime, things are really quiet:

orchid:
 12:12pm  up 1 day,  4:43,  12 users,  load average: 0.10, 0.11, 0.00

Sun 4/280, OS 4.0.1, 2 disks, only 8M memory (more was supposed to arrive
last Thursday (not from Sun).  Had to be rebooted when all the
in.telnetd's and in.rlogind's decided to eat all the processor and the
load average went up to 35.  Happened three times now, but I've only just
reported it to Sun, I never report things the first time they happen.

poppy:
 12:16pm  up 3 days, 20 hrs,  3 users,  load average: 1.18, 1.34, 1.20

Sun 3/160, OS 4.0.1, 3 disks, 16M memory, serving 3 Sun3/50s.  Last had to be
rebooted when it jammed up after:

Jan 31 16:09:55 poppy vmunix: mti0: DMA output error
Jan 31 16:09:55 poppy last message repeated 2 times
Jan 31 16:09:55 poppy vmunix: mti0: read error code <21>. Probable hardware fault
Jan 31 16:09:55 poppy vmunix: output_echo_char: out of blocks
Jan 31 16:09:55 poppy last message repeated 13 times

First time it's happened, I haven't reported it.  Current load average is
offset by one by a process which is stuck, reported by ps as in `D' "short
term" wait, and has been for two days.  Reported end of October, Sun
"can't reproduce the problem", although it sometimes happens to use once a
day, on both of our multi-user machines.  Last time it happended, earlier
in the week, all the nfsd's got stuck in this state, and the clients
froze.

Three of our four Sun 3/50s (OS 4.0.1, 4M) are currently spouting:

clnttcp_create: RPC: Program not registered
rpc.statd: cannot talk to statd at sol

once every 15 seconds.  Sol is a Gould PN6031 running a version of NFS
that does not have statd/lockd.  Rebooting doesn't cure this, I have to cd
/etc/sm.bak and remove a file and then reboot.  Reported to Sun about a
week ago, no answer yet.

>Sure, we found a gotcha or two in going to 4.0 - you always do with any
>major OS upgrade, but compared with, say, going from 1.0 to 2.0, the
>upgrade to 4.0 was a piece of cake.  4.0 is loaded with goodies for users
>and makes system management much easier.
>
>If you're still running 3.X, you're in the dark ages (well, maybe 3.5.1 is
>just the grey ages).

If you're still running 3.X, think long and hard before going to 4.0, and
be prepared to back out.

[[ This next section was sent in later:  --wnl ]]

As of 17/01/89 we had 17 problem reports outstanding with Sun, dating back
as far as September/October:
	Closing mailtool sometimes gives panic: Bus error
	Windows `pop' after period of inactivity
	restore gives spurious `resync restore' when file straddles dump tapes
	GNUemacs on an ALM-2 freezes the terminal on suspend/quit
	Losing characters on multiple rlogins/telnets to a single host
	pwd leaves thousands of /tmp/.getwd files around
	ctrace doesn't work on Sun4s
	Fileservers give itrunc: new size = 0, blocks = -16
	Processes stuck in ps `D' state
	screenblank dies leaving screen blank
	root can read files via NFS sometimes without remote root access
	ps dumps core
	NFS inconsistencies, updates not noticed sometimes
	finger dumps core
	panic: mclput
	Writes to /dev/rst8 hang near end of tape, tape unusable until reboot
	panic: spec_getapage pvn_kluster

We are looking to buy a new machine over the Summer, and Sun has lost a
lot of Brownie points over their software reliability and support, despite
the convenience of having another machine with the same architecture.

Rob
-- 
UUCP:   ...!mcvax!ukc!warwick!cudcv	PHONE:  +44 203 523037
JANET:  cudcv at uk.ac.warwick             ARPA:   cudcv at warwick.ac.uk
Rob McMahon, Computing Services, Warwick University, Coventry CV4 7AL, England



More information about the Comp.sys.sun mailing list