Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!ames!ucbcad!ucbvax!SDCSVAX.UCSD.EDU!gr65%sdcc12
From: gr65%sdcc12@SDCSVAX.UCSD.EDU.UUCP
Newsgroups: mod.computers.vax
Subject: (none)
Message-ID: <8702151836.AA06817@sdcc12.UCSD.EDU>
Date: Sun, 15-Feb-87 13:36:51 EST
Article-I.D.: sdcc12.8702151836.AA06817
Posted: Sun Feb 15 13:36:51 1987
Date-Received: Mon, 16-Feb-87 01:48:25 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 135
Approved: info-vax@sri-kl.arpa

Subject: Help needed for VMS crashes (YFDRIVER?)
Newsgroups: mod.computers.vax
Keywords: crash microvax vms yfdriver vaxnet

   A plea for help directed to VMS wizards.

   I received no responses to my posting last week; my first
article had no subject header so I will try again.  My apologies if
I am disturbing anyone.

   The following plea for help is fairly long since I am not sure
that I have isolated the problem and I wanted to cover all the
bases.  A quick-and-dirty question for those who do not want to
wade through it all :
   Is there a known bug with the YFDRIVER that might cause MicroVMS 
system crashes and is there a work-around?

   Around the time I installed the asynchronous communications 
program VAXNET version 10 (10 months ago), we started
experiencing a crash or two per month.  Superficial (fumbling?, I am first
an oceanographic researcher, second an MVax system manager) analyses
of some of the crash dumps revealed that VAXNET was the cause of the 
majority of the crashes and that the YFDRIVER seems to be where the problem
manifests itself.

   Here are the facts that I think to be pertinent :

 -- MicroVAX II (with vms 4.2 till Oct 86, now with vms 4.4, prob. persists)
     with 2 RA81's, a RD53 and a TK50, 7 Mb of (Emulex) memory. 
 -- DHV11 (Emulex?)
 -- VAXNET is not installed with any privileges, although protection is
      set on the outgoing port to allow modification by the program.
 -- Crashes most often occur with 5-8 users on (i.e., fairly heavy load)
 -- Crashes occur when VAXNET is writing to user's terminal screen, usually
      not right away but after several 'pages' have scrolled by.
 -- Crashes occur when port with 1200 baud modem is used but never
      when 9600 baud port to an Ungermann-Bass LAN is used.
 -- Crashes have occurred when VAXNET is connected to VAX 11/750 with
      VMS 4.1, Pyramid/Unix 4.2 BSD and an IBM(?) machine

    Yes, we do have KERMIT, but VAXNET seems to have superior terminal handling
 for remote editting and some VMS-specific niceties such as with file transfers
 so yes we would like to get VAXNET running properly.

 Can anyone give me a shove in the right direction for solving this problem?
 What is the sequence of things I might do based on the crash info given 
 below (all VAXNET crash dumps give virtually identical info to that below)?

 The YFDRIVER seems to be involved but is there an obvious way to prevent the
 crash conditions from materializing in the first place, as apparently happens
 on the 9600 baud connection.  Thanks for your help.

 Steve Piper
 gr65%sdcc12@SDCSVAX.ARPA


 An abbreviated typical VAXNET-related system crash dump summary follows
 (typed in ...; I will be pleased to send more info on request) :

   SDA> sho crash

   Time of system crash: 28-JUL-1986 10:46:00.62

   Version of system: VAX/VMS VERSION 4.2

   Reason for BUGCHECK exception: INVEXCEPTN, Exception while above ASTDEL
     or on interrupt stack
  
   Current image file: DUA0:[NETWORK.VAXNET.VER10.DEBUG]VAXNET.EXE;1

   Current IPL: 4 (decimal)

   General registers:

      R0 = 00000004  R1 = 04040000  R2 = 8012E8E8  R3 = 8012E8FC
      R4 = 800024A8  R5 = 801B3D70  R6 = 7FFDBD20  R7 = 00000000
      R8 = 0190000C  R9 = 000087AC  R10= 00000004  R11= 0000A9A4
      AP = 00004C08  FP = 7FFE7DE4  SP = 801F25AC  PC = 80004862
      PSL= 04040009

   Processor registers:

      P0BR   = 8020C400  PCBB   = 004DBC78  ACCS  = 00000000
      POLR   = 000002B4  SCBB   = 006F6E00  SBIFS = 00000000
      P1BR   = 7FA1D400  ASTLVL = 00000004  SBISC = 00000000
      P1LR   = 001FFB60  SISR   = 00000000  SBIMT = 00000000
      SBR    = 006F8200  ICCS   = 00000040  SBIER = 00000000
      SLR    = 00001C80  ICR    = 00000000  SBITA = 00000000
                         TODR   = 7B5918CA  SBIS  = 00000000

      ISP = 801F25AC
      KSP = 7FFE7DDC
      ESP = 7FFE9E00
      SSP = 7FFED04E
      USP = 7FF6E71C

  SDA> sho stack

  Current operating stack (INTERRUPT):

         801F258C  000087AC
         801F2590  00000004
         801F2594  0000A9A4
         801F2598  00004C08  SGN$C_MAXPAGCNT+C08
         801F259C  7FFE7DE4  CTL$GL_KSTKBAS+5E4
         801F25A0  801F25A4  
         801F25A4  80004862  EXE$EXCEPTION+047
         801F25A8  04040009
 
    SP=> 801F25AC  00000004
         801F25B0  7FFE7DE4  CTL$GL_KSTKBAS+5E4
         801F25B4  FFFFFFFD
         801F25B8  00000000
         801F25BC  00000083
         801F25C0  00000001
         801F25C4  00000005
         801F25C8  0000000C

         801F25CC  00000004
         801F25D0  00000020
         801F25D4  80004A4E  IOC$BUFPOST+017
         801F25D8  04040000
         801F25DC  80004A6D  IOC$BUFPOST+036
         801F25E0  8012DDA0  YFDRIVER+130
         801F25E4  801B3D70
         801F25E8  8012E8E8  YFDRIVER+C78 
         801F25EC  8012E8FC  YFDRIVER+C8C
         801F25F0  0000000D
         801F25F4  8012E830  YFDRIVER+BC0
         801F25F8  80009CC4  EXE$INSIOQ+01D
         801F25FC  00C20000



---------------------------end-message---------------------------------------