home *** CD-ROM | disk | FTP | other *** search
/ Network Support Encyclopedia 96-1 / novell-nsepro-1996-1-cd2.iso / download / netware / pnwupw.exe / VXDS / DEADLOCK.TXT next >
Text File  |  1995-04-28  |  22KB  |  523 lines
  1.  
  2.            NOVELL TECHNICAL INFORMATION DOCUMENT
  3.  
  4. TITLE:          Deadlocks with Novell NetWare and Windows
  5. DOCUMENT ID:        TID0xxxxx
  6. DOCUMENT REVISION:  C
  7. DATE:               01OCT94
  8. ALERT STATUS:       Yellow
  9. INFORMATION TYPE:   Symptom Solution
  10.  
  11.  
  12. NOVELL PRODUCT and VERSION:
  13. NetWare Client for DOS/MS Windows 1.1
  14.  
  15. ABSTRACT:
  16.  
  17. These document discusses updates that resolve problems when using Windows
  18. 3.x or Windows for Workgroups 3.11 on a Novell network.  The symptom is a 
  19. blank screen with a blinking underline curser in the upper-left-hand corner 
  20. of the screen and the workstation hangs.
  21. _________________________________________________________________
  22. DISCLAIMER
  23. THE ORIGIN OF THIS INFORMATION MAY BE INTERNAL OR EXTERNAL TO
  24. NOVELL.  NOVELL MAKES EVERY EFFORT WITHIN ITS MEANS TO VERIFY THIS
  25. INFORMATION.  HOWEVER, THE INFORMATION PROVIDED IN THIS DOCUMENT
  26. IS FOR YOUR INFORMATION ONLY.  NOVELL MAKES NO EXPLICIT OR IMPLIED
  27. CLAIMS TO THE VALIDITY OF THIS INFORMATION.
  28. _________________________________________________________________
  29.  
  30. ADDITIONAL CONFIGURATION
  31.  
  32. Third-Party Product and Version:
  33.  
  34. Windows 3.x
  35. Windows for Workgroups 3.x
  36.  
  37.  
  38. SYMPTOM
  39.  
  40. The symptom is a blank screen with a blinking underline cursor 
  41. in the upper-left-hand corner of the screen and the workstation 
  42. hangs.  This may happen at any time while in Windows, launching 
  43. a DOS box, using a Windows application or exiting Windows.
  44.  
  45. The following is a list of causes/solutions that Novell has 
  46. isolated that can cause/remedy the symptom described above.
  47.  
  48.  
  49. CAUSE
  50.  
  51. IPXODI.COM had a problem in SPX.  During a retry, SPX would jump to
  52. invalid memory causing an invalid opcode exception in v86 mode only
  53. when SPX is being used.  This usually manifests itself as a reboot,
  54. hung machine, or blank screen with cursor in upper-left corner.
  55.  
  56. CAUSE
  57.  
  58. LSL.COM had a bug that was GetStackECBPrescanIsPresent destroyed
  59. the return Flag when an ECB was given.  The symptom of this problem
  60. would most likely manifest it self by a workstation hang when using
  61. a protocol stack that expects to get an ECB from the LSL under a
  62. heavy load.
  63.  
  64. CAUSE
  65.  
  66. LSL.COM also had a problem with the "Do Send for Windows" code that
  67. needed a "Start and End Critical Section" call added.
  68.  
  69. CAUSE
  70.  
  71. An incorrect system configuration including memory management.
  72.  
  73. CAUSE
  74.  
  75. Any I/O, memory, or IRQ conflicts may cause this problem.
  76.  
  77. CAUSE
  78.  
  79. Using third-party device drivers or terminate-and-stay-resident
  80. (TSR) programs.
  81.  
  82. CAUSE
  83.  
  84. Lan Card MLID driver's misuse of ECB buffers. (Update ODI MLIDs as a
  85. standard trouble shooting tip)
  86.  
  87. CAUSE
  88.  
  89. Third party protocol stacks, such as TCPIP.
  90.  
  91. CAUSE
  92.  
  93. VIPX.386 is a Windows 3.X virtualization driver for IPXODI.COM
  94. driver that was enhanced jointly by Novell and Microsoft.  It
  95. virtualizes requests to the globally loaded IPX driver.  When a
  96. request is made to IPX, VIPX will allocate a request buffer in the
  97. system's global memory, copy the original request to the global
  98. buffer and give the global request to IPX.  When the global request
  99. completes, IPX will call VIPX.  VIPX will then copy any results
  100. back to the original request buffer and call the application that
  101. submitted the request.
  102.  
  103. CAUSE
  104.  
  105. Some Windows applications have been found to create the symptom if when
  106. exiting Windows the application is running in the background in a 
  107. minimized state.  If this occurs, close all applications before
  108. leaving Windows.
  109.  
  110. CAUSE
  111.  
  112. There are occasions when using a WINSTART.BAT file (which is created
  113. by the user and placed in the Windows directory) may also cause Windows
  114. to hang when exiting Windows.  Avoid a WINSTART.BAT file if the symptom 
  115. persists.
  116.  
  117.  
  118. CAUSE
  119.  
  120. Microsoft has a patch called VTDA.386 for their Windows 3.1 VTD (Virtual
  121. Timer Device). VTDA.386 is a obtainable from Microsoft.  Their BBS number
  122.  is 206-936-6735 and the file to download is WW0863.EXE.
  123.  
  124. *Note: Windows 3.1 was refreshed to 3.11. In the update, VTDA.386 is made 
  125.        available in the box. This patch is installed by default if you 
  126.        select NetWare in the Windows SETUP option. This also applies to
  127.        Windows for Workgroups 3.11 users.
  128.  
  129.  
  130.  Version Compatibility with Dedicated IPX
  131.  ----------------------------------------
  132. Novell officially ceased maintenance on the dedicated IPX driver
  133. (IPX.OBJ) version 3.10 dated 11-21-91.  The last version of VIPX to
  134. explicitly support that driver is 1.10.  The current version of
  135. VIPX supports IPXODI.COM only.
  136.  
  137.  Packet Size Limitations
  138.  -----------------------
  139. VIPX.386 will only virtualize packets that are 8000 (decimal) bytes
  140. or less.  Any DOS and Windows IPX or SPX applications that use
  141. networks with a physical packet size greater than 8000 bytes may
  142. not work with VIPX.386.  For example, IBM Token Ring can be
  143. configured to run with 16 KB packets.  A request by a DOS or
  144. Windows IPX application to send a 16 KB packet will be truncated to
  145. 8000 bytes.  On the other hand, any 16 KB packet that is received
  146. by the LAN driver will be dropped because VIPX cannot allocate a
  147. packet big enough to handle it.
  148.  
  149.  Memory Manager Limitations
  150.  --------------------------
  151. When a request is passed up from IPX, VIPX will immediately test
  152. the request buffer to see if it is in global memory.  If it is in
  153. global memory, the request will be passed back down to IPX without
  154. any virtualization.  For example, a TSR loaded before Windows is
  155. considered to be in global memory.  If that TSR calls IPX, VIPX
  156. will test the requests and pass them back down to IPX.  This is
  157. done because there is no need to virtualize requests that are
  158. already global.
  159.  
  160. The use of UMA memory complicates the test for global memory. 
  161. There are two basic scenarios.
  162.  
  163. The first scenario is when a TSR has been loaded high before
  164. Windows was loaded.  In this case, IPX requests will come from
  165. global UMA memory.  VIPX will simply pass these requests back down
  166. to IPX.
  167.  
  168. The second scenario is when a TSR is loaded high in a Windows
  169. DOSBOX.  In this case, IPX requests will come from local UMA
  170. memory.  VIPX will virtualize these requests.
  171.  
  172. Some memory managers test for global UMA memory and will work
  173. properly under both scenarios.  However, other memory managers
  174. exist that do not work properly under Windows.  With these drivers,
  175. all local DOSBOX UMAs look as if they are GLOBAL UMAs.
  176.  
  177. In the case of the second scenario when a TSR calls IPX, VIPX will
  178. test the request buffer and think that it is in global UMA memory
  179. when it is really in LOCAL UMA memory.  As a result, VIPX will pass
  180. a local ECB to IPX without virtualization.  The normal result of
  181. this is a hung machine or data corruption.
  182.  
  183.  
  184. SOLUTION
  185.  
  186. Novell strongly recommends that you update your dedicated IPX
  187. driver with IPXODI.COM v2.12 or higher, included in VLMUP1 .EXE,
  188. when using versions of VIPX later than 1.10.
  189.  
  190. Because of the problems with LSL.COM, Novell also recommends that
  191. you update your LSL.COM to v2.05 or higher.  This version is also
  192. available in VLMUP1.EXE in the NOVFILES forum of Compuserve.
  193.  
  194. If you are using third-party memory managers and hang, do not load
  195. TSRs using the IPX interface (including IPX itself) high.  Load
  196. these in conventional memory only.
  197.  
  198. Files Needed:     Size     Date      Version  Location     Owner
  199. =================================================================
  200.     VIPX.386      23855   10-08-93    1.19    WINDR1.EXE   Novell
  201.   IPXODI.COM      30247   10-07-93    2.12    VLMUP1.EXE   Novell
  202.      LSL.COM      17805   09-10-93    2.05    VLMUP1.EXE   Novell
  203.     VTDA.386      xxxxx   xx-xx-xx    x.xx    WW0863.EXE   Microsoft  
  204.  
  205. Installation Instructions:
  206.  
  207. 1. Rename or backup the old VIPX.386, IPXODI.COM, and LSL.COM
  208.    files.
  209.  
  210. 2. Copy IPXODI.COM and LSL.COM to where the network board's
  211.    software is initialized.
  212.  
  213. 3. Copy VIPX.386 to your WINDOWS\SYSTEM directory.
  214.  
  215. 4. Virtualize the network board's IRQ in the [VIPX] section of the
  216.    SYSTEM.INI if using IBM LAN SUPPORT. (See  Specialized Configuration
  217.    Parameters below for instructions)
  218.  
  219. 5. Put TimerCriticalSection=10000 in the [386Enh] section of the
  220.    SYSTEM.INI.
  221.  
  222. 6. Download, and implement the VTDA.386 driver from Microsoft as documented
  223.    in their README file.
  224.  
  225. 7. Reboot the machine and load the ODI drivers.
  226.  
  227. 8. Enter Windows.
  228.  
  229.  
  230. Solution Specifics:
  231.  
  232.  Specialized Configuration Parameters
  233.  ------------------------------------
  234.  
  235. Under most circumstances, VIPX will work fine under the default
  236. configuration.  However, there may be some applications that
  237. require custom configuration of the driver.  This following is a
  238. list of SYSTEM.INI parameters that can be used to configure VIPX:
  239.  
  240. [VIPX]
  241. VipxMappingPages          =[number of 4K pages]  (default = 16)
  242. VipxFailOverSizedPackets  =[ON|OFF|TRUE|FALSE]   (default = OFF)
  243. VirtualizeIrq[0-F]        =[ON|OFF|TRUE|FALSE]   (default = OFF) 
  244.  
  245. VIPX Parameters
  246.  
  247.  VipxMappingPages
  248.  ----------------
  249. This is the number of pages that VIPX can use to globalize requests
  250. to the global IPXODI.COM driver.  VIPX is not absolutely guaranteed
  251. to have all of these pages available at any one point, because this
  252. is the requested number of pages for shared global mapping that
  253. VIPX makes to the Windows VMM at initialization time.
  254.  
  255.  VipxFailOverSizedPackets
  256.  ------------------------
  257. This parameter tells VIPX to fail any requests that require more
  258. than the maximum allowed globalization size.  The actual maximum
  259. will vary according to the media the user is using.  The absolute
  260. maximum is 8000 (decimal) bytes.  With media that have smaller
  261. packets than 8000 bytes, the maximum allowed size is the maximum
  262. packet size that can be put onto the media.
  263.  
  264.  VirtualizeIrq[0-F]
  265.  ------------------
  266. VIPX v1.15 or greater avoids a deadlock between the machine and
  267. network board by virtualizing the network board's IRQ.  With ODI
  268. and dedicated IPX (IPX.OBJ) drivers, VIPX will automatically read
  269. the configuration of the network board from the driver and
  270. virtualize the selected IRQs.  However, when using the IBM LAN
  271. Support Program with SLANSUP.OBJ or LANSUP.COM, the LAN IRQ is not
  272. readable from the driver.  The only way to get this information is
  273. to read the network board hardware itself.  The problem with doing
  274. this is that the hardware can be Token Ring, PCN2 or Ethernet. 
  275. VIPX must now be aware of many different hardware configurations. 
  276. Instead of this, VIPX requires the IBM LAN Support user to specify
  277. the network board's IRQ in the [VIPX] section of the SYSTEM.INI. 
  278. IRQs range from 0 to F (hex).  An example is listed below:
  279.  
  280.      [VIPX]
  281.      VirtualizeIrq2=TRUE
  282.      VirtualizeIrq3=TRUE
  283.  
  284. In this example, VIPX will virtualize both IRQ 2 and IRQ 3. VIPX
  285. can virtualize up to four different LAN IRQs.  The reason for
  286. virtualizing multiple IRQs is to allow other LAN boards and
  287. protocols to be installed on the same PC and prevent them from
  288. deadlocking the machine.  For example, you may have IPX running
  289. through an NE2000 board on IRQ 3 and TCP/IP running through to an
  290. IBM Token-Ring board on IRQ 2.
  291.  
  292. VIPX.386 v1.18 included the two following changes:
  293.  
  294.      1.   This file corrects a possible problem with virtualizing the network
  295.           board's interrupt line (IRQ) setting.  The Virtualization API
  296.           returns a carry clear (OK) when the IRQ  handle is 0.  Now, VIPX.386
  297.           will not virtualize the IRQ if the IRQ handle is 0.  Also a code was
  298.           added to specify which VM (Virtual Machine) "owns" a virtualized
  299.           IRQ.
  300.  
  301.      2.   In VIPX.386, a comparison for the VM handle for an AES ECB in the
  302.           GLOBAL ECB was added.  VIPX.386 also verifies the VM handle for an
  303.           AES ECB in a condition not previously considered.
  304.  
  305. VIPX.386 v1.19 includes the previous two changes plus three additional
  306. changes:
  307.      
  308.      1.   A changed was made to force Windows applications to open only
  309.           long-lived sockets.
  310.  
  311.           For example, if you ran a DOS BOX with RCONSOLE with v1.18, it would
  312.           allocate a short-lived socket; and if this DOS box was terminated,
  313.           VIPX would overwrite an area that caused Windows to trap with a
  314.           black screen and flashing cursor. VIPX v1.19 fixes this issue.
  315.  
  316.      2.   This patch address an issue with a TSR (globally loaded) that needs
  317.           to open sockets after Windows is loaded.  Right now, v1.18 closes
  318.           all sockets, opened after Windows is loaded, when exiting Windows.
  319.  
  320.           A fix was made to check for the KeepLongLivedSocketsOpen parameter. 
  321.           This parameter is set to OFF by default.  If this parameter is set
  322.           to ON when an Open Socket operation is issued from V86 mode, the
  323.           socket will be considered global and will not be closed when exiting
  324.           Windows.  The syntax to change the default from OFF to ON needs to
  325.           be added to the end of SYSTEM.INI file as follows:
  326.  
  327.           [VIPX]
  328.           KeepLongLivedSocketsOpen=[TRUE|FALSE|ON|OFF] default=FALSE
  329.  
  330.      3.   This patch resolved an issue related to Virtualizing LAN IRQs.
  331.  
  332.           For example, when exiting enhanced mode Windows back to DOS,
  333.           sometimes the cursor will flash in the upper left hand corner and
  334.           not return back to the DOS prompt.
  335.  
  336.           With this update the releasing of a Virtualized IRQ is restored,
  337.           allowing COMMAND.COM to be reloaded, and the SYSTEM to return to the
  338.           DOS prompt.
  339.  
  340.  
  341.  TimerCriticalSection
  342.  --------------------
  343. As of version 1.15 of VIPX, TimerCriticalSection is required to be
  344. set on.  The recommended setting is as follows:
  345.  
  346.      [386Enh]
  347.      TimerCriticalSection=10000
  348.  
  349. The reason for this parameter is to avoid a deadlock with the LAN
  350. IRQ Virtualization code.  See "VirtualizeIrq[0-F]" section.
  351.  
  352. Changes to updated LSL.COM v2.05 or greater
  353.  
  354. 1.    GetStackECBPrescanIsPresent destroyed the return Flag when an
  355.     ECB was given.  The symptom of this problem would most likely
  356.     manifest it self by a workstation hang when using a protocol stack    
  357.     that expects to get an ECB from the LSL under a heavy load.
  358.  
  359. 2.    Added a line to correct ECBLISTHEAD overwriting of variable
  360.     StackECBHoldQHead.
  361.  
  362. Changes to LSL.COM v2.02
  363.  
  364. 1.     Commandline Switches:
  365.  
  366.     Valid switches:  U, F, ?, H, C=
  367.  
  368.     Only the "U, ?, C=" are documented in the help.
  369.  
  370.         U    Used to unload LSL.
  371.  
  372.         ?    Used for Help.
  373.     
  374.         F    Used to force the unload.
  375.  
  376.         H    Used as an equivalent to "?" switch, and is used by
  377.                   many of Novell's other utilities.
  378.  
  379.         C=   Used to change the path or filename of the configuration
  380.                   file. The "C=" switch is the only two-letter switch that 
  381.                   is valid,  Custom Configuration Files.  When using the 
  382.                   "C=" command-line switch, the LSL first tries the
  383.                   [path]\filename as given.  If the file is not found, then
  384.                      the filename is searched for in the directory where the 
  385.                      LSL was loaded from; and if it still cannot be found, it
  386.                      looks in the current working directory.  If all these 
  387.                      efforts fail, then the LSL reverts back to looking for a
  388.                      "NET.CFG" file in the directory where the LSL was loaded
  389.                      from then in the current working directory.  The filename
  390.                      is considered valid even if the path was incorrect.  
  391.                      After parsing the Configuration file, the  LSL displays 
  392.                      the relative path of the Configuration file that was 
  393.                      parsed.
  394.  
  395. 2.     LSL.COM had a problem that caused a deadlock situation with
  396.        the LAN adapter.  A Do Send for Windows needed a Start and End
  397.        Critical Section call added.  It is now language enabled.
  398.  
  399. 3.     Multiple Prescan Stack Chaining did not pass a packet properly.
  400.  
  401. 4.     GetProtocolControlEntry would not return the DefaultProtocol
  402.        Control Entry point if it was not the only stack in the
  403.        DefaultProtocolChain.
  404.  
  405. 5.     Bound checking was added on the MLID Support Functions.
  406.  
  407. 6.     Error code not preserved in Deregister Prescan Tx chain.
  408.  
  409. 7.     A problem in the Memory Calculation when calculating the amount of
  410.        memory to reserve when going TSR was fixed.
  411.  
  412. 8.     The LSL, while checking for boards and Protocols that were still
  413.        registered would unload from memory, leaving the still registered
  414.        entities with bad pointers.  The LSL will now remove all the MLIDS,
  415.        through the SHUTDOWN command.  The LSL will not unload if a
  416.        Protocol stack is still registered with the LSL.
  417.  
  418. 9.     On Installation of a LAN driver, the LSL would check the version
  419.        of the Configuration Table and delete the board number.  This is
  420.        now fixed.
  421.  
  422. 10.     On unload of a LAN driver, the driver called
  423.         MLIDSUP_DEREGISTER_MLID, which called
  424.     MLIDSUP_CONTROL_STACK_FILTER.
  425.  
  426. =================================================================
  427. IPXODI.COM
  428.  
  429.     Command line Switches:
  430.  
  431.     Valid switches: /?, /D, /A, /C=, /U, /F
  432.  
  433.         ?    Used for help screen.
  434.  
  435.         D    Used for Eliminate Diagnostic Responder; reduces size
  436.              by 3 KB.
  437.  
  438.         A    Used for Eliminate Diagnostic Responder and SPX;
  439.              reduces size by 9 KB.
  440.  
  441.      PLEASE NOTE:  Disabling SPX will mean that SPX
  442.      applications (such as RPRINTER, BTRIEVE, RCONSOLE, or
  443.      NetWare for SAA STRNRTR) will not be supported on this
  444.      workstation.
  445.  
  446.         C=   Used to change the path or filename of the
  447.                   configuration file.  "C=" is the only two letter switch
  448.              that is valid.  If the *.CFG file used does not exist a
  449.              message will be displayed that the standard NET.CFG
  450.              file will be used instead.
  451.  
  452.         U    Used to unload.
  453.  
  454.         F    Used to force the unload.
  455.  
  456.  IPXODI.COM v2.12 or greater 
  457.  
  458. 1. Fixed SPX problem that was seen using NASI/NACS modem sharing
  459.    data.  This problem shows up when using an SPX applications that is
  460.    transferring data in full duplex mode (most SPX applications do not
  461.    do this).  The code was advancing the session sequence number in
  462.    the local session table immediately after sending an SPX data
  463.    packet to the other side.  If a data packet came in from the other
  464.    side that did not acknowledge Novell's "send," Novell would
  465.    generate a system packet back to the other end with the session
  466.    sequence number set to the value in the local session table, which
  467.    is one higher than what it should be.  Then if Novell's data packet
  468.    got dropped, Novell would retransmit it, in which case the other
  469.    end would ignore our packet since it session sequence number was
  470.    not high enough.  This would result in session failure.
  471.  
  472. 2. Enhanced initialization code to check the board's node ID for
  473.    all 0FFs.  If it is then we display an error and fail to load. 
  474.    This enhancement was requested by Novell Austin for support of his
  475.    serial line ODI drivers which set the node Id to all 0FFs if the
  476.    user hasn't made a connection.  A new error message has been
  477.    created for this condition, however the code checks to see if the
  478.    msg file IPXODI is using has the new error message.  If it does
  479.    not, then the error condition is ignored and IPXODI still loads. 
  480.    This will allow current/older msg files to be used successfully.
  481.  
  482. 3. A problem in RxHandler was fixed that was introduced in IPXODI
  483.    v2.00 where in the case Novell steals a mapping ECB then they have
  484.    to have VIPX get a client receive ECB.  Novell was not preserving
  485.    register AX, which was supposed to have the destination socket
  486.    number.  In this case, VIPX would return that there was not any
  487.    receive ECB since it thought the socket was not opened when in
  488.    reality it was and it had receives posted.  This bug can cause
  489.    back-to-back receive packets to be dropped when the packets are
  490.    destined for an IPX application (DOS or Windows) running under
  491.    Enhanced mode Windows.
  492.  
  493. 4. Novell fixed IPX diagnostic responder code so it would return a
  494.    0FFFFh in the SPX socket number field of the IPX diagnostic query
  495.    reply packet when SPX or diagnostic portion of IPXODI has not be
  496.    loaded by the user.  This provides a method for diagnostic
  497.    applications to determine if SPX is there or not so they do not
  498.    have to attempt a SPX connect request if SPX is not there.
  499.  
  500.  IPXODI.COM 04-23-93 v2.11 Released for NMS and NetWare 4.01 
  501.  Release
  502.  
  503. 1. Implemented fix in SPXConnectHandler routine where it
  504.    was not preserving the session count in CX when comparing the
  505.    session addresses.  This problem exists in the dedicated IPX/SPX
  506.    module as well.  To see this problem the same source connection ID
  507.    would have to be in use by two nodes trying to connect to a
  508.    particular node.
  509.  
  510. 2. Novell fixed a problem in SPXMessageHandler routine where it was
  511.    setting the a send ECB's ESR to SessionSendCompletedDelayed without
  512.    a group "CGroup:" override that caused a bogus offset to be put in
  513.    the ESR offset field.  Thus when the active send finished it would
  514.    blow up.  This problem exists in the dedicated IPX/SPX module as
  515.    well.  This problem showed itself while running the Novell NMS
  516.    Windows application for a few hours.
  517.  
  518. 3. IPXODI.COM had a problem in SPX.  During a retry, SPX would jump to
  519.    invalid memory causing an invalid opcode exception in v86 mode only
  520.    when SPX is being used.  Few applications use SPX.  This usually
  521.    manifests itself as a reboot, hung machine, or blank screen with
  522.    cursor in upper-left corner.
  523.