Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!WOLF.UWYO.EDU!waldram From: waldram@WOLF.UWYO.EDU Newsgroups: comp.sys.apollo Subject: RE: SR10.3.p is big trouble Message-ID: <9101201904.AA01881@wolf.Uwyo.EDU> Date: 20 Jan 91 19:04:36 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 55 RE: Message-Id: <1991Jan18.203853.1893@alchemy.chem.utoronto.ca> >>>>> We upgraded our DN10020 to SR10.3.p 2 days ago, and in general our >>>>> experience so far has not been good: We upgraded our DN10010 to 10.3.p 20 days ago, and in general our experience HAS BEEN EXCELLENT! We went from 10.1.p to 10.3.p. >>>>> 1) vi still hangs in a DM pad after the first use; it will work once >>>>> after the pty's are rebuilt, then hangs ever after. We have not seen this problem at 10.1.p or 10.3.p! We ARE running in the BSD environment. >>>>> 2) SR10.3.p almost ran for 2 hours before the tcpd hung and started >>>>> eating 100% of the cpu time. WE HAVE SEEN THIS PROBLEM, but the offending process was rgyd (a slave). 800-2APOLLO explained the problem, but offered only a potentially dangerous fix. (see previous reports here) We are still pursuing the problem (no APR), but have seen it occur only 3 times since installation (none in the last 10 days). While any activity was EXTREMELY HINDERED (slow response), by killing the offending processes, we were able to do a clean SHUT. >>>>> 4) saving the best for last, NONE OF THE WORKSTATIONS SOLUTIONS 9 TRACK >>>>> TAPE DRIVE SOFTWARE WORKS ON SR10.3.p We found that 'rwmt' access worked with WS TapeAT version 2.2.1 (SR10.1.p & 10.3.p) BUT NOT WITH 'wbak/rbak' backup utilities. WS has supplied version 3.1.1 which I was going to install this weekend (before I read #4). This version is supposed to fix the problems I was having! What version is giving you these problems? >>>>> If any one has any Workstations Solutions stuff that runs on SR10.3.p at I was also hoping to install our WS Exatape on our 10010 this weekend. I'll keep you posted on my experiences. We have seen some problems with /dev/tty0x. Our applications read a data stream from tty01, tty02, and tty03 which worked at 10.1.p. The tty0x's could not be opened by the applications at 10.3.p. HOWEVER!!! by modifying the code to allow the "non-UNIX" /dev/siox to be used, the applications functioned! We tried remaking all the devices and rebooting to fix the problem, but the tty's did not return to functionality. We investigated the "fix to tty's" where the hardware lines needed to be at the correct levels, to no avail. Getty did not care wether we used sio or tty device files (both worked when H/W signal levels correct). We gave up for the time being as the applications were critical to daily operation. We have also seen some major performance hits when LARGE applications are running. We attribute these to the lack of RAM (we have only 16MB) as we are seeing significant disk paging request levels (20 to 90 per second). -jjw Jim Waldram Department of Atmospheric Science, University of Wyoming waldram@grizzly.uwyo.edu jwaldram@outlaw.uwyo.edu jwaldram@UWYO.BITNET