Contents of the DEADLOCK.TXT file

ABSTRACT:These files fix a problem when using Windows or Windows forWorkGroups on a Novell network. The symptom is a blank screen with a blinking underline curser in the upper-left-hand corner of the screen and the workstation hangs._________________________________________________________________

DISCLAIMERTHE ORIGIN OF THIS INFORMATION MAY BE INTERNAL OR EXTERNAL TONOVELL. NOVELL MAKES EVERY EFFORT WITHIN ITS MEANS TO VERIFY THISINFORMATION. HOWEVER, THE INFORMATION PROVIDED IN THIS DOCUMENT ISFOR YOUR INFORMATION ONLY. NOVELL MAKES NO EXPLICIT OR IMPLIEDCLAIMS TO THE VALIDITY OF THIS INFORMATION._________________________________________________________________

ADDITIONAL CONFIGURATION

Third-Party Product and Version:

WindowsWindows for WorkGroups

SYMPTOM

The symptom is a blank screen with a blinking underline curser in the upper-left-hand corner of the screen and the workstation hangs. This may happen at any time while in Windows, launching a dos box, using a Windows application or exiting Windows.

The following is a list of causes/solutions that Novell has isolated that can cause/remedy the symptom described above.

CAUSE

IPXODI.COM had a bug in SPX. During a retry, SPX would jump toinvalid memory causing an invalid opcode exception in v86 mode onlywhen SPX is being used. Few applications use SPX. This usuallymanifests itself as a reboot, hung machine, or blank screen withcursor in upper-left corner.

CAUSE

LSL.COM had a bug that was GetStackECBPrescanIsPresent destroyedthe return Flag when an ECB was given. The symptom of this problemwould most likely manifest it self by a workstation hang when usinga protocol stack that expects to get an ECB from the LSL under aheavy load.

CAUSE

LSL.COM also had a problem with the "Do Send for Windows" code thatneeded a "Start and End Critical Section" call added.

VIPX.386 is a Windows 3.X virtualization driver for IPXODI.COMdriver that was enhanced jointly by Novell and Microsoft. Itvirtualizes requests to the globally loaded IPX driver. When arequest is made to IPX, VIPX will allocate a request buffer in thesystem's global memory, copy the original request to the globalbuffer and give the global request to IPX. When the global requestcompletes, IPX will call VIPX. VIPX will then copy any resultsback to the original request buffer and call the application thatsubmitted the request.

CAUSE

Some Windows applications have been found to create the symptom if whenexiting Windows the application is running in the background in a minimized state. If this occurs, close all applications beforeleaving Windows.

CAUSE

There are occasions when using a Winstart.bat file (which is createdby the user and placed in the Windows directory) may also cause Windowsto hang when exiting Windows. Avoid a Winstart.bat file if the symptom persists.

CAUSE

Microsoft has a patch called VTDA.386 for their Windows 3.1 VTD driver. VTDA.386 obtainable from Microsoft. Their BBS number is 206-936-6735 and the file to down load is WW0863.EXE.

Version Compatibility with Dedicated IPX ----------------------------------------Novell officially ceased maintenance on the dedicated IPX driver(IPX.OBJ) version 3.10 dated 11-21-91. The last version of VIPX toexplicitly support that driver is 1.10. The current version ofVIPX supports IPXODI.COM only.

Packet Size Limitations -----------------------VIPX.386 will only virtualize packets that are 8000 (decimal) bytesor less. Any DOS and Windows IPX or SPX applications that usenetworks with a physical packet size greater than 8000 bytes maynot work with VIPX.386. For example, IBM Token Ring can beconfigured to run with 16 KB packets. A request by a DOS orWindows IPX application to send a 16 KB packet will be truncated to8000 bytes. On the other hand, any 16 KB packet that is receivedby the LAN driver will be dropped because VIPX cannot allocate apacket big enough to handle it.

Memory Manager Limitations --------------------------When a request is passed up from IPX, VIPX will immediately testthe request buffer to see if it is in global memory. If it is inglobal memory, the request will be passed back down to IPX withoutany virtualization. For example, a TSR loaded before Windows isconsidered to be in global memory. If that TSR calls IPX, VIPXwill test the requests and pass them back down to IPX. This isdone because there is no need to virtualize requests that arealready global.

The use of UMA memory complicates the test for global memory. There are two basic scenarios.

The first scenario is when a TSR has been loaded high beforeWindows was loaded. In this case, IPX requests will come fromglobal UMA memory. VIPX will simply pass these requests back downto IPX.

The second scenario is when a TSR is loaded high in a WindowsDOSBOX. In this case, IPX requests will come from local UMAmemory. VIPX will virtualize these requests.

Some memory managers test for global UMA memory and will workproperly under both scenarios. However, other memory managersexist that do not work properly under Windows. With these drivers,all local DOSBOX UMAs look as if they are GLOBAL UMAs.

In the case of the second scenario when a TSR calls IPX, VIPX willtest the request buffer and think that it is in global UMA memorywhen it is really in LOCAL UMA memory. As a result, VIPX will passa local ECB to IPX without virtualization. The normal result ofthis is a hung machine or data corruption.

SOLUTION

Novell strongly recommends that you update your dedicated IPXdriver with IPXODI.COM v2.12, included in DOSUP9.EXE, when usingversions of VIPX later than 1.10.

Because of the problems with LSL.COM, Novell also recommends thatyou update your LSL.COM to v2.05. This version is also availablein DOSUP9.EXE in the NOVFILES forum of Compuserve.

If you are using third-party memory managers and hang, do not loadTSRs using the IPX interface (including IPX itself) high. Loadthen in conventional memory only.

Under most circumstances, VIPX will work fine under the defaultconfiguration. However, there may be some applications thatrequire custom configuration of the driver. This following is alist of SYSTEM.INI parameters that can be used to configure VIPX:

VipxMappingPages ----------------This is the number of pages that VIPX can use to globalize requeststo the global IPXODI.COM driver. VIPX is not absolutely guaranteedto have all of these pages available at any one point, because thisis the requested number of pages for shared global mapping thatVIPX makes to the Windows VMM at initialization time.

VipxFailOverSizedPackets ------------------------This parameter tells VIPX to fail any requests that require morethan the maximum allowed globalization size. The actual maximumwill vary according to the media the user is using. The absolutemaximum is 8000 (decimal) bytes. With media that have smallerpackets than 8000 bytes, the maximum allowed size is the maximumpacket size that can be put onto the media.

VirtualizeIrq[0-F] ------------------VIPX v1.15 or greater avoids a deadlock between the machine andnetwork board by virtualizing the network board's IRQ. With ODIand dedicated IPX (IPX.OBJ) drivers, VIPX will automatically readthe configuration of the network board from the driver andvirtualize the selected IRQs. However, when using the IBM LANSupport Program with SLANSUP.OBJ or LANSUP.COM, the LAN IRQ is notreadable from the driver. The only way to get this information isto read the network board hardware itself. The problem with doingthis is that the hardware can be Token Ring, PCN2 or Ethernet. VIPX must now be aware of many different hardware configurations. Instead of this, VIPX requires the IBM LAN Support user to specifythe network board's IRQ in the [VIPX] section of the SYSTEM.INI. IRQs range from 0 to F (hex). An example is listed below:

[VIPX] VirtualizeIrq2=TRUE VirtualizeIrq3=TRUE

In this example, VIPX will virtualize both IRQ 2 and IRQ 3. VIPXcan virtualize up to four different LAN IRQs. The reason forvirtualizing multiple IRQs is to allow other LAN boards andprotocols to be installed on the same PC and prevent them fromdeadlocking the machine. For example, you may have IPX runningthrough an NE2000 board on IRQ 3 and TCP/IP running through to anIBM Token-Ring board on IRQ 2.

TimerCriticalSection --------------------As of version 1.15 of VIPX, TimerCriticalSection is required to beset on. The recommended setting is as follows:

[386Enh] TimerCriticalSection=10000

The reason for this parameter is to avoid a deadlock with the LANIRQ Virtualization code. See "VirtualizeIrq[0-F]" section.

Changes to LSL.COM v2.05

1. GetStackECBPrescanIsPresent destroyed the return Flag when anECB was given. The symptom of this problem would most likelymanifest it self by a workstation hang when using a protocol stackthat expects to get an ECB from the LSL under a heavy load.

2. Added a line to correct ECBLISTHEAD overwriting of variableStackECBHoldQHead.

Changes to LSL.COM v2.02

1. Commandline Switches:

Valid switches: U, F, ?, H, C=

Only the "U, ?, C=" are documented in the help.

U Used to unload LSL.

? Used for Help.

F Used to force the unload.

H Used as an equivalent to "?" switch, and is used by many of Novell's other utilities.

C= Used to change the path or filename of the configuration file. The "C=" switch is the only two-letter switch that is valid, Custom Configuration Files. When using the "C=" command-line switch, the LSL first tries the [path]\filename as given. If the file is not found, then the filename is searched for in the directory where the LSL was loaded from; and if it still cannot be found, it looks in the current working directory. If all these efforts fail, then the LSL reverts back to looking for a "NET.CFG" file in the directory where the LSL was loaded from then in the current working directory. The filename is considered valid even if the path was incorrect. After parsing the Configuration file, the LSL displays the relative path of the Configuration file that was parsed.

2. LSL.COM had a number of bugs and one was a bug that caused adeadlock situation with the LAN adapter. A Do Send for Windowsneeded a Start and End Critical Section call added. It is nowlanguage enabled.

3. Multiple Prescan Stack Chaining did not pass a packet properly.

4. GetProtocolControlEntry would not return the DefaultProtocolControl Entry point if it was not the only stack in theDefaultProtocolChain.

5. Bound checking was added on the MLID Support Functions.

6. Error code not preserved in Deregister Prescan Tx chain.

7. A bug in Memory Calculation when calculating the amount ofmemory to reserve when going TSR was fixed.

8. The LSL, while checking for boards and Protocols that were stillregistered would unload from memory, leaving the still registeredentities with bad pointers. The LSL will now remove all the MLIDS,through the SHUTDOWN command. The LSL will not unload if aProtocol stack is still registered with the LSL.

9. On Installation of a LAN driver, the LSL would check the version

of the Configuration Table and delete the board number. This isnow fixed.

10. On unload of a LAN driver, the driver calledMLIDSUP_DEREGISTER_MLID, which called MLIDSUP_CONTROL_STACK_FILTER.

When testing for board numbers that are bound to the MLID, a JNEwas used where a JE was needed.

IPXODI.COM

Command line Switches:

Valid switches: /?, /D, /A, /C=, /U, /F

? Used for help screen.

D Used for Eliminate Diagnostic Responder; reduces size by 3 KB.

A Used for Eliminate Diagnostic Responder and SPX; reduces size by 9 KB.

PLEASE NOTE: Disabling SPX will mean that SPX applications (such as RPRINTER, BTRIEVE, RCONSOLE, or Netware for SAA STRNRTR) will not be supported on this workstation.

C= Used to change the path or filename of the configuration file. "C=" is the only two letter switch that is valid. If the *.CFG file used does not exist a message will be displayed that the standard NET.CFG file will be used instead.

U Used to unload.

F Used to force the unload.

IPXODI.COM v2.12 Released for NetWare 4.01 Update

1. Fixed SPX problem that was seen using NASI/NACS modem sharingdata. This problem shows up when using an SPX applications that istransferring data in full duplex mode (most SPX applications do notdo this). The code was advancing the session sequence number inthe local session table immediately after sending an SPX datapacket to the other side. If a data packet came in from the otherside that did not acknowledge Novell's "send," Novell wouldgenerate a system packet back to the other end with the sessionsequence number set to the value in the local session table, whichis one higher than what it should be. Then if Novell's data packetgot dropped, Novell would retransmit it, in which case the otherend would ignore our packet since it session sequence number wasnot high enough. This would result in session failure.

2. Enhanced initialization code to check the board's node ID forall 0FFs. If it is then we display an error and fail to load. This enhancement was requested by Novell Austin for support of hisserial line ODI drivers which set the node Id to all 0FFs if theuser hasn't made a connection. A new error message has beencreated for this condition, however the code checks to see if themsg file IPXODI is using has the new error message. If it doesnot, then the error condition is ignored and IPXODI still loads. This will allow current/older msg files to be used successfully.

3. A problem in RxHandler was fixed that was introduced in IPXODIv2.00 where in the case Novell steals a mapping ECB then they haveto have VIPX get a client receive ECB. Novell was not preservingregister AX, which was supposed to have the destination socketnumber. In this case, VIPX would return that there was not anyreceive ECB since it thought the socket was not opened when inreality it was and it had receives posted. This bug can causeback-to-back receive packets to be dropped when the packets aredestined for an IPX application (DOS or Windows) running underEnhanced mode Windows.

4. Novell fixed IPX diagnostic responder code so it would return a0FFFFh in the SPX socket number field of the IPX diagnostic queryreply packet when SPX or diagnostic portion of IPXODI has not beloaded by the user. This provides a method for diagnosticapplications to determine if SPX is there or not so they do nothave to attempt a SPX connect request if SPX is not there.

IPXODI.COM 04-23-93 v2.11 Released for NMS and NetWare 4.01 Release

1. Implemented fix in SPX.ASM SPXConnectHandler routine where itwas not preserving the session count in CX when comparing thesession addresses. This problem exists in the dedicated IPX/SPXmodule as well. To see this problem the same source connection IDwould have to be in use by two nodes trying to connect to aparticular node.

2. Novell fixed a bug in SPXMessageHandler routine where it wassetting the a send ECB's ESR to SessionSendCompletedDelayed withouta group "CGroup:" override that caused a bogus offset to be put inthe ESR offset field. Thus when the active send finished it wouldblow up. This problem exists in the dedicated IPX/SPX module aswell. This problem showed itself while running the Novell NMSWindows application for a few hours.

3. IPXODI.COM had a bug in SPX. During a retry, SPX would jump toinvalid memory causing an invalid opcode exception in v86 mode onlywhen SPX is being used. Few applications use SPX. This usuallymanifests itself as a reboot, hung machine, or blank screen withcursor in upper-left corner.