Conference lassie::ucx

5229.0. "TNDRIVER writes IIRP packet to LTDRIVER" by HYDRA::DORHAMER () Fri Feb 14 1997 10:22

The attached problem description comes from a software partner, Progress
Software, who would like to know if this is a known problem.  They are
currently running UCX v3.3 but may upgrade to v4.1 soon (I think their
reluctance stems from problems with their systems crashing when UCX v4.0
was installed previously).  Please let me know if this is a known
problem and whether upgrading to 4.1 is expected to help.

Thanks,
Karen Dorhamer
Software Partner Engineerig

Problem desscription from Progress:

With UCX V3.3 (I want to try on V4.1, but I'm afraid to upgrade :-) - but
I probably will soon...)...  I have a problem seen *ONLY* (so far) on a
VAX 4000 Model 90 (tried it on a Model 60, but no problems there...) where
the UCX TNDRIVER writes it's IIRP packet to the *middle* of another driver
in this case LTDRIVER.  LTDRIVER gets a timer interrupt and "attempts" to
run the code, but naturally an OPCDEC occurs very quickly!..  Now it may not
be TNDRIVER at fault since between a 60 and a 90 there are two different
LANCE chip drivers (ES for the 60 and EZ for the 90)...  I'm not wanting to
point a finger, but I have to start somewhere...

The data that is written to LTDRIVER appears to be an IIRP ( or perhaps VCRP -
the type field is missing - so I'm guessing).. The IRP$L_AST is 823ADA80, which
translates to :

ex/inst 823ADA80-20;20
%SDA-W-INSKIPPED, unreasonable instruction stream - 17 bytes skipped
TNDRIVER+033F1:  BLSS    TNDRIVER+033F6
TNDRIVER+033F3:  BGEQ    823ADA84
TNDRIVER+033F5:  BRB     823ADA8A
TNDRIVER+033F7:  HALT
TNDRIVER+033F8:  BNEQ    823ADAF8
TNDRIVER+033FA:  PUSHL   R0
TNDRIVER+033FC:  MOVZBL  0B(R5),R0
823ADA80:  BSBW    TNDRIVER+00865

and then:
ex/inst TNDRIVER+00860;20
TNDRIVER+00860:  CLRQ    (R0)+
TNDRIVER+00862:  CLRQ    (R0)
TNDRIVER+00864:  MOVAB   01E0(R5),R0
TNDRIVER+00869:  CLRQ    (R0)+
TNDRIVER+0086B:  CLRQ    (R0)+
TNDRIVER+0086D:  CLRQ    (R0)+
TNDRIVER+0086F:  CLRQ    (R0)
TNDRIVER+00871:  MOVL    00A4(R6),R1
TNDRIVER+00876:  MOVAB   4C(R1),R0
TNDRIVER+0087A:  MOVAB   TNDRIVER+01DD0,20(R0)
TNDRIVER+00882:  BISW2   #08,14(R0)


Even if I have the structure types wrong, when formatting they appear to be
pretty close - I even see INET routines listed..:

(from the IIRP)
823AE1EC   IRP$L_OBCNT                     8182DF1C     INET_RTRN_XMT_LO_VCI

(from the IIRP$L_ASTPRM - 8230C380 - and format as IIRP)

8230C3B8   IRP$L_IOST1                     8182DC40
						INET$VCI_RCV_ARP_COMPLETE+000BB
8230C3C0   IRP$L_ABCNT                     8182F8EC     INET_IPINTR+003AD



----------

If it doesn't ring any bells, then I'll try doing to upgrades to see what
happens from there... I'm not even sure if there are any patches applied, but
here are some dir/dates:


UCX$BGDRIVER.EXE;3   29-APR-1995 14:53:15.50
UCX$DNFSDRIVER_V5.EXE;2
                     18-APR-1995 12:49:54.84
UCX$DNFSDRIVER_V6.EXE;2
                     18-APR-1995 12:49:57.73
UCX$INETDRIVER.EXE;3
                     18-APR-1995 05:09:17.30
UCX$INTERNET_SERVICES.EXE;3
                     29-APR-1995 14:53:29.51
UCX$INTERNET_SERVICES_V6.EXE;3
                     29-APR-1995 14:53:53.33
UCX$PWIPDRIVER.EXE;3
                     18-APR-1995 09:19:46.39
UCX$TNDRIVER.EXE;3   26-APR-1995 03:33:45.89



tks in advance
    

    Progress just reported that they installed the latest 3.3 patch kit
    for UCX and it has fixed their crash problem.
    
    Karen