Patch Name: PHNE_19226 Patch Description: s700_800 10.01-[12]0 2.2X ACC HDLC/LAP-B FW (EISA) Patch Creation Date: 99/09/02 Post Date: 00/02/16 Hardware Platforms - OS Releases: s700: 10.01 10.10 10.20 s800: 10.01 10.10 10.20 Products: Z7408AA 2.22 2.23 Filesets: ACC-HDLC.ACC-HDLC-FW Automatic Reboot?: No Status: General Release Critical: No Path Name: /hp-ux_patches/s700_800/10.X/PHNE_19226 Symptoms: PHNE_19226: DTS TPO0h01780: The LAPB and LAPD protocols were not behaving correctly in relation to retransmission of the REJect frame. Only one REJect frame would be transmitted, despite never receiving an in-sequence I-frame which clears the reject condition. The standards state that that a REJect frame should be retransmitted every T1 interval until the condition clears. DTS TPO0h01967: Some ports on some 8-port cards fail to come up in X.21 mode. DTS TPO0h02172: LAPB/LAPD: Extended Information and Supervisory frames that are received and are too short (missing part of control field) are simply being ignored. Receipt of these frames should result in the following action: LAPB - sends FRMR (w and x set) LAPD - sends SABME DTS TPO0h02173: On LAPB/LAPD connection establishment, groups of DM frames are sent between groups of SABM/SABME frames - which is incorrect. DM frames should not be sent during this connection establishment state. DTS TPO0h02175: LAPB/LAPD terminals are not handling the "busy condition" properly. If one side of a link is inactive (sent RNR - Receiver Not Ready), the other side should poll every T1 until the remote end activates. DTS TPO0h02256: The LAPB Z180 firmware blocks messages from being sent after a link reset under special circumstances: A received frame with a bad N(R) will result in a FRMR being sent. On receiving this, the remote end will send a SABM, our end send a UA and the link is re-established. This is fine. But once this process is through, the firmware refuses to send I-frames until it receives a frame. This is a bug. DTS TPO0h02414: A customer would like to be able to congigure the frame protocol buffer transmit timer in the same way timers are configured in HDLC-LAPB. A problem exists at baud rates of 1200 and below. A full buffer of data (238 bytes) will be cut short when the 1 second transmit timeout expires. DTS TPO0h02429: The ACC loopback test (invoked by the LB command in zmntr) was occasionally failing with non-defective 8-port cards. The problem occurred on average about once every 50 zmntr LB commands. DTS TPO0h02504: With the baud rate incorrectly configured as 64,000 while the actual line speed is 9600, transmitted frames can be cut short and joined together. DTS TPO0h02773: Some ports on some cards do not work properly in X.21 mode on the 8-port NIO and EISA cards. Some of these failures occur just after a card reset, and recover after some 10 - 30 seconds. Other ports fail all the time. The failure appears to be the port detecting the CTS and/or DCD signals missing. DTS TPO0h02776 / DTS TPO0h02780: Enhancement - The r2.23 x.25 firmware needs to be updated to the newer frame-based version (zx25) which supersedes the current 2.23 version. DTS TPO0h02789: HDLC terminals on X.21 lines sometimes can "bounce" as they are being enabled and brought up - meaning the line comes up, then quickly goes down and comes up again. This can lead to loss of transmitted data if the data is sent as soon as the terminal is enabled. PHNE_17264: SR 4701405889 / DTS TPO0h02414 The Z180 based cards timesout when sending a buffer larger than 147 bytes at 1200 Baud rate. PHNE_15373: SR 4701391862 / DTS TPO0h01966 No current method to determine hardware revision Defect Description: PHNE_19226: DTS TPO0h01780: The HDLCABM state machine was not designed to handle REJect frame retransmission. Extensive changes have been made to the HDLCABM state machine to handle REJect frame retransmission. DTS TPO0h01967: Change to ensure that X.21 is disabled for the Z7200A Rev.A card only. Change particularly focused at the Z7400A EISA cards to ensure that Rev.A cards are not disabled from X.21 configuration. This corrects the X.21 configuration problem with all cards. DTS TPO0h02172: HDLC firmware was ignoring this condition. The HDLC firmware has been corrected. DTS TPO0h02173: Bad state change on N2/N200 timer expiration. The finite state machine (FSM) has been corrected. DTS TPO0h02175: Incorrect behaviour coded into the HDLCABM state machine. The state machine has been corrected. DTS TPO0h02256: The transmit window full flag in the firmware was not being cleared on the link reset. The firmware did not send further messages because it thought the window was full. Code to reset this transmit window full flag have been added in the appropriate points. DTS TPO0h02414: The transmit timeout is fixed at 1 second which is not enough to allow the complete transmission of a full buffer (238 bytes) at 1200 baud or less. The frame module now sets the timeout according to the configured baud rate on the port. Baud rate Tx timeout (x100ms) 300 136 600 69 1200 35 2400 18 4800 10 9600 6 >9600 4 These timeouts allow approximately double the necessary time for the maximum of 252 bytes to be transmitted. 252 bytes is the maximum number of bytes to be transmitted because that is the maximum which can be held in one ACC buffer. DTS TPO0h02429: A problem with the 8-port's ISCC chips caused a transmit underrun to be incorrectly generated during the start of a frame tranmission - resulting in the first few bytes of that frame being corrupt. Note: The test is transmitting in single character mode. On initialisation of the ISCC, the firmware was issuing a "Reset Tx Underrun/EOM Latch" command. This was found to cause the occasional transmit underrun external/status interrupt. This reset command was taken out of the initialisation sequence in the testprot firmware. DTS TPO0h02504: This is due to an enhancement that was made for defect TPO0h02414. The transmit timeout used at level-1 was shortened for baud rates as high as 64000. Because incorrect baud rate configurations can lead to this problem, part of the changes made for TPO0h02414 have now been backed out. The minimum timeout used is now 1 second which will allow for typical incorrect configurations. DTS TPO0h02773: The Sipex chips (line drivers) when placed in RS422 mode (balanced signaling mode used for X.21) leave some unused TTL output pins in an unknown state. These pins are used for the CTS signal when the Sipex chip is in RS232 mode. The firmware was reading the state of the CTS signal - and the ISCC chips were configured to react to this signal. This problem was not detected before because the usual state of these Sipex pins signal that CTS is up. On some Sipex chips, this signal is down, or is down and then comes up after a short period of time after being put into RS422 mode. The firmware has been changed to ignore the CTS signal when in X.21 mode. Also the ISCC chips are configured to also ignore changes in the CTS and DCD signals. The firmware code still checks the DCD signal - which matches the X.21 Indicate signal, so the firmware still can detect a cable disconnect. Note: There is no problem in ignoring the (internal) CTS signal - as it does not map to any signal in X.21. DTS TPO0h02776 / DTS TPO0h02780: The current r2.23 x.25 firmware has been superseded with the latest release, which brings it up-to-date with the latest r2.40 x.25 firmware. DTS TPO0h02789: The HDLCABM protocol verifies the status of the line (CTS/DCD/RTS type signals) on receipt of a frame. This verification checks status bits that are set by the frame protocol every 1 second. If the HDLC terminal is enabled and a frame is received within one second, the status bits may not be up-to-date. This indicates to the HDLC terminal that the link is down and it discards the frame. This problem has been fixed in the firmware. PHNE_17264: SR 4701405889 / DTS TPO0h02414 The Z180 based cards cannot transmit more than 147 bytes at 1200 baud, because the transmit timeout is set at 1 second per buffer and it takes more than 1 second to transmit 148 bytes at this baud rate PHNE_15373: SR 4701391862 / DTS TPO0h01966 Enhancement to detect hardware revisions of ACC cards. A standard interface has been defined to identify hardware revisions of all ACC cards. The 'mx' command of zmntr has been enhanced to include the display of the hardware revision. SR: 4701405889 4701391862 Patch Files: /opt/acc/z7400a/hdlc.zabs /opt/acc/z7400a/hdlc.zmap /opt/acc/z7400a/hdlc.zlnk /opt/acc/.patch_build_info_PHNE_19226 what(1) Output: /opt/acc/z7400a/hdlc.zabs: ZCOM System Firmware (ROM) Rev 01.B5 970416.1600 ZCOM Z7400A System Software Rev 01.C 970624.1601 Patch name: PHNE_19226 ZCOM LEVEL1 Protocol REV_STR level1.z80, Patch name: PHNE_19226 ZCOM HDLC ABM Protocol REV_STR abm.cpp, Patch version: PHNE_19226 ZCOM HDLC ABM State Tables Rev:1.12 981123.1126 REV_STR abmfsmtab.zinc ZCOM Monitor module Rev 3.0 940706.1800 ZCOM Port Diagnostic Module REV_STR testprot.z80, Patch version: PHNE_19226 ZCOM Protocol module entry point table 870406.1041 /opt/acc/z7400a/hdlc.zmap: ZCOM System Firmware (ROM) Rev 01.B5 970416.1600 ZCOM Z7400A System Software Rev 01.C 970624.1601 Patch name: PHNE_19226 ZCOM LEVEL1 Protocol REV_STR level1.z80, Patch name: PHNE_19226 ZCOM HDLC ABM Protocol REV_STR abm.cpp, Patch version: PHNE_19226 ZCOM HDLC ABM State Tables Rev:1.12 981123.1126 REV_STR abmfsmtab.zinc ZCOM Monitor module Rev 3.0 940706.1800 ZCOM Port Diagnostic Module REV_STR testprot.z80, Patch version: PHNE_19226 ZCOM Protocol module entry point table 870406.1041 /opt/acc/z7400a/hdlc.zlnk: NACC hdlc.zlnk $Rev: /main/r2.23/1 $ /opt/acc/.patch_build_info_PHNE_19226: None cksum(1) Output: 2451308201 25214 /opt/acc/z7400a/hdlc.zabs 2736604948 17767 /opt/acc/z7400a/hdlc.zmap 1769121658 438 /opt/acc/z7400a/hdlc.zlnk 1373699803 1123 /opt/acc/.patch_build_info_PHNE_19226 Patch Conflicts: None Patch Dependencies: None Hardware Dependencies: None Other Dependencies: None Supersedes: PHNE_15373 PHNE_17264 Equivalent Patches: None Patch Package Size: 110 KBytes Installation Instructions: Please review all instructions and the Hewlett-Packard SupportLine User Guide or your Hewlett-Packard support terms and conditions for precautions, scope of license, restrictions, and, limitation of liability and warranties, before installing this patch. ------------------------------------------------------------ 1. Back up your system before installing a patch. 2. Login as root. 3. Copy the patch to the /tmp directory. 4. Move to the /tmp directory and unshar the patch: cd /tmp sh PHNE_19226 5a. For a standalone system, run swinstall to install the patch: swinstall -x autoreboot=true -x match_target=true \ -s /tmp/PHNE_19226.depot By default swinstall will archive the original software in /var/adm/sw/patch/PHNE_19226. If you do not wish to retain a copy of the original software, you can create an empty file named /var/adm/sw/patch/PATCH_NOSAVE. WARNING: If this file exists when a patch is installed, the patch cannot be deinstalled. Please be careful when using this feature. It is recommended that you move the PHNE_19226.text file to /var/adm/sw/patch for future reference. To put this patch on a magnetic tape and install from the tape drive, use the command: dd if=/tmp/PHNE_19226.depot of=/dev/rmt/0m bs=2k Special Installation Instructions: SUBSYSTEM_SHUT After installing this patch, the ACC subsystem must then be stopped and restarted using zmasterd in order to download the new firmware. Please Note: To customers who link their own firmware, you should now link with the zx25.zrel and hdlcabm.zrel files that supersede the x25.zrel and hdlc.zrel firmware files.