NOVELL TECHNICAL BULLETIN TITLE: IBM Token Ring and Novell NetWare DOCUMENT ID#: TB.P.291 DATE: 04/06/91 PRODUCT: NetWare 286, 386 PRODUCT REVISION: all versions SUPERSEDES: NA SYMPTOM: NA ISSUE/PROBLEM Several Novell customers and third-party vendors have experienced problems with IBM Token Ring stations while using IBM LAN Support Program and Novell NetWare. Symptoms typically are that the workstation will simply "hang." Most of these problems have been with TIC (Token Ring Interconnect Option) connected 3270 gateways. Tracking these problems down turned out to be extremely difficult. With the help of our customers, third-party vendors, and IBM we now believe we understand the nature of the problem. These problems are not due to a single cause. We believe we have identified a total of three issues which individually could cause problems and together are likely to cause a network station to fail. The exact combination of hardware and software which has been shown to have problems is the IBM Token Ring Adapter (any vintage or bus type), IBM LAN Support Program version 1.0 through 1.1, NetWare Token Ring drivers versions 2.60 and earlier, MS-DOS or PC-DOS 3.3x or 4.0x, and a 3270 gateway such as DCA's Irmalan product. It must be emphasized these problems are not properly "bugs" as all the components of a system showing these symptoms are functioning as designed. Furthermore, the circumstances which can cause a failure are extremely unusual and always involve very heavy LAN traffic, particularly connection attempts. SOLUTION PROBLEM #1 Certain characteristics of the IBM LAN Support Program DXMC0MOD.SYS driver were interacting with NetWare's IPX program causing IPX and DXMC0MOD to enter infinite loops waiting for a reply. The DXMC0MOD driver, for performance reasons related to RS232C communications through serial ports using single character buffer UARTs (such as National Semiconductor's INS8250 or equivalent) will re-enable interrupts after 400 ęseconds to avoid dropping characters during high speed communications. This behavior can be disabled with a switch on the CONFIG.SYS line which loads the driver, "q" for "quiet." This switch is not case sensitive. This "Q" switch is not currently documented in the IBM LAN Support Program documentation. The syntax to use the "q" switch is given below. DEVICE=DXMC0MOD.SYS Q This interrupt disabling behavior of DXMC0MOD can allow IPX and DXMC0MOD to enter an endless wait. When two protocols are using DXMC0MOD, such as 802.2 3270 protocols from a gateway to the System 370 Controller and IPX/SPX between the gateway station and network stations connecting to the gateway, problems can occur. The scenario of events is as follows: An 802.2 TRANSMIT begins. Before the TRANSMIT can complete interrupts are re-enabled. While interrupts are re-enabled an SPX CONNECT request arrives. If the SPX CONNECT request has passed through a NetWare Router (sometimes erroneously called a NetWare Bridge) SPX issues an IPXGetLocalTarget request to determine the Time To Target. Because the previous 802.2 TRANSMIT is still pending the IPX TRANSMIT is queued. IPX assumes that only two things can EVER happen to a packet transmit request: it will either FAIL or SUCCEED. Thus IPX waits for a reply from the card indicating the packet transmit has either failed or succeeded but because the packet has NOT been transmitted, only queued up, IPX NEVER receives this required response from the card. Meanwhile the DXMC0MOD driver is patiently waiting for control to return to it so it can process the two pending transmits. Both IPX and DXMC0MOD thus wait for each other forever. This failure is most likely to occur in an environment where very large numbers of connect requests are being presented to the gateway. PROBLEM #2 The combination of the IBM LAN Support Program, IPX, SPX, the gateway software, and DOS use a large amount of DOS STACK space. The default STACKS of DOS 3.3x/4.0x in 286/386 machines of 9 stack frames of 128 bytes each may be insufficient in some cases. To prevent internal stack failure or stack overruns we suggest increasing the size and number of these dynamic stacks. Add the following line to CONFIG.SYS in the gateway station: STACKS=16,256 This allocates 16 stack frames of 256 bytes each and should prevent any stack related problems. PROBLEM #3 The combination of an IBM 4/16 Token Ring Adapter with 1990 firmware, version 1.1 LAN Support Program, and NetWare 2.60 or earlier Token Ring drivers has been shown to cause the Token Ring Adapter to lockup. In most instances this has been resolved with the 1.20 or 1.21 LAN Support Program and 2.62 NetWare Token Ring drivers when used together with the "Q" switch for the DXMC0MOD.SYS driver. If these problems persist in a station using these latest drivers, the IBM Token Ring Adapter Diagnostics diskette provided with the adapter should be run to determine the revision level of the adapter's microcode. If the ISA adapter microcode revision level is C24550 an Authorized IBM Dealer or Support Representative should be contacted to arrange for an upgrade of the adapter microcode. This applies ONLY to stations being used as a gateway and does not apply to other network stations including file servers. To use the IBM Token Ring Adapter Diagnostic diskette to check your firmware level: FOR MCA ADAPTERS - Place the Token Ring Adapter diskette in the boot diskette drive of the computer being tested and power the computer on. Press 0 After the Ring Adapter Open completes, press The next screen will show the Adapter Code Level number. Press , Press , remove the Adapter Diagnostic diskette and press any key to re-boot the computer. FOR ISA ADAPTERS - Place the Token Ring Adapter diskette in the boot diskette drive ofthe computer being tested and power the computer on. Press 1 (Ring Diagnostics) then Press Enter Press 0 After the Ring Adapter Open completes, press The next screen will show the Adapter Code Level number. Press , Press , remove the Adapter Diagnostic diskette and press any key to re-boot the computer. Novell Technical Services has reports of another Token Ring Adapter Code Level which has produced similar symptoms, 8A78064. This has not been completely confirmed by both IBM and Novell Technical Services. If the symptoms described above are experienced and the solutions described above do not resolve the problems please contact Novell Technical Services (1-800-NETWARE) and/or IBM. PLEASE NOTE: AT THIS TIME WE ARE NOT RECOMMENDING REQUESTING REPLACEMENT FOR THIS ADAPTER CODE LEVEL. IF PROBLEMS ARE EXPERIENCED, REPORT THEM AND IBM AND NOVELL WILL INVESTIGATE FURTHER.