Conference netcad::hub_mgnt

2248.0. "900tm v1.1.0 crashes" by COMICS::REYNOLDS (Mad Dogs and Englishmen) Wed May 03 1995 11:33

    
    Hi,                       
    
    I have a customer suffering regular repeater 900TM crashes.
    These seem to have started since upgrading their VMS host
    systems from v5.5-2H4 (Decnet IV) to V6.1 (Decnet/OSI v6.1)
    
    They have upgraded the repeaters to v1.1.0 and MAMs to V3.1.0.
    but stil get the crashes.
    
    There are 2 hubs:
    
    
    UPSTAIRS:   3 x 900TM rptrs
                1 x 900TM term server
                1 x 90FL rptr
                1 x 900MX bridge
                1 x Wanrouter 90
    
    DOWNSTAIRS: 2 x 900TM rptrs
                1 x 900TM term server
                1 x 90FL rptr
                1 x 900MX bridge
                1 x brouter 90
    
    the 'downstairs' repeaters have never crashed.
   
    cust has noticed up to 70% collision rates on the repeater 'speedos'
    in Hubwatch  - I'm not sure if this is also true of the downstairs
    repeaters.
    
    Looking at the error logs, I see the following. note that the reset 
    count doesnt tally with the count reported through Hubwatch:
    
    
    UPSTAIRS: # 1  'Entry 1: reset count 0  Fatal Error: line 310, file
    		    pcomerrlog.c
              (module reset count thru Hubwatch: 21)
    
              # 2  'Entry 1: reset count 0  Fatal Error: line 310, file
                    pcomerrlog.c
              (module reset count thru Hubwatch: 13)
    
              # 3  'Entry 1: reset count 17 Fatal Error: line 329, file
                   pcomerrlog.c
              (module reset count thru Hubwatch: 19)
    
    
    DOWNSTAIRS:
    
              # 1  'No entries'
              (module reset count thru Hubwatch: 5)
    
              # 2  'Entry 1: reset count 4 Fatal Error: line 310, file
                   pcomerrlog.c
              (module reset count thru Hubwatch: 6)
    
    
    Are there any known crash problems under V1.1.0 relating to traffic load/
    collision rates or an aversion to certain frame types?
    
    
    
    regards,
    
    		John Reynolds, UK CSC, Comms.
    

    John,
    
    	This is actually a known problem...  and it is partly traffic load
    related.  The root of the problem has to do with a heap bug that allows
    high and low IPL processes to access the same data structures
    simultaneously.
    
    	We have a fix in the pipeline but it needs a thorough system test
    before we can release it to customers.  After a reasonable duration of
    system test, we will likely release it to some customers to verify that
    we've actually got the correct fix.
    
    	The new version will be v2.0.
    
    
    Charlie

    
    Charlie,
    
    
    		thanks for your prompt reply. Can you give me a rough idea
    of the release date for v2.0 field test and let me know when its out?
    (KERNEL::REYNOLDSJ)
    
    many thanks,
    
    			John.
    
    
    

    I too have a customer that has had multiple 900TM's crash.  It appears
    the affected repeaters are in slot 5 of the Hub900.  Is there a
    correlation?
    
    Also, can you reply in this note the rough release date for the fix? 
    Or list product manager so I can contact directly, or mail to
    POBOX::ELARSON or Ed Larson @ACI.
    
    Thanks for any and all assistance.
    
    Ed

    We're just about through updating the DETMM, DETTM and DEFMM modules to
    v2.0 functionality.  At this time, we're awaiting system test time
    before we can release to customers.  From the test results we have so
    far, it seems like we've corrected the problem.  However, since it
    takes about a week to appear we'll be monitoring the modules to verify.
    
    Since our current schedule has the v2.0 updates shipping at the end of
    August, you may want to contact Mike Mattock, NPSS::MATTOCK, since he
    will be aware of any pre-ship releases that will be made available to
    customers.
    
    
    Charlie