Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!rice!sun-spots-request From: cudcv%warwick.ac.uk@nss.cs.ucl.ac.uk (Rob McMahon) Newsgroups: comp.sys.sun Subject: Re: Some good press on SunOS 4.0 Message-ID: <98@titania.warwick.ac.uk> Date: 10 Feb 89 04:10:20 GMT References: <8901202311.AA11706@dawn.steinmetz.GE.COM> Sender: usenet@rice.edu Organization: Computing Services, Warwick University, UK Lines: 87 Approved: Sun-Spots@rice.edu Original-Date: 4 Feb 89 12:34:44 GMT X-Sun-Spots-Digest: Volume 7, Issue 148, message 2 of 6 steinmetz!dawn!stpeters@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@uk.ac.warwick ARPA: cudcv@warwick.ac.uk Rob McMahon, Computing Services, Warwick University, Coventry CV4 7AL, England