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