Patch Name: PHNE_19216 Patch Description: s700_800 10.20 2.23 ACC Base Software (EISA) Patch Creation Date: 99/12/08 Post Date: 00/02/16 Hardware Platforms - OS Releases: s700: 10.20 s800: 10.20 Products: Z7401A 2.23; Z7402A 2.23 Filesets: ACC.ACC-KRN ACC.ACC-RUN ACC.ACC-MAN ACC.ACC-PRG ACC-X25.ACC-X25-RUN ACC-X25ST.ACC-X25ST-RUN Automatic Reboot?: Yes Status: General Release Critical: No Path Name: /hp-ux_patches/s700_800/10.X/PHNE_19216 Symptoms: PHNE_19216: SR 4701323840 / DTS TPO0h00545 The customer has noted a problem when having large network events causing the zcom log file to grow very quickly and filling up the file system. This causes problems for the rest of the application and the customer would like a solution that would prevent the zcom log from taking out the file system. SR 5003380527 / DTS TPO0h01523 When the operating system is configured incorrectly, there is not enough msg buffers (reported by HP-UX with dmesg error: Can't allocate message buffer.). When this happens zmasterd cold & kill does not behave properly because it can't get msg buffer in msgsnd(). DTS TPO0h01629 Traces won't work if the core dump is not in the default directory. (/var/adm/crash) SR 5003415463 / DTS TPO0h02037 Utility zmlog reads zcom log buffer from the LDM. But occasionally the read return length is not consistent with the "log buffer length" kept in the returned log buffer. This usually happens when there is a lot of messages being logged in a short time, e.g. during system startup with a large number of X.25 circuit. But it did happen in a small configuration. When this happens, zmlog prints an error message in the ZCOM error log file and ignores the whole log buffer. DTS TPO0h02107 It is found during code inspection/review that the zx25*() APIs do not have prototypes defined. All the other ZCOM APIs have such prototypes defined in zcomcall.h DTS TPO0h02189 zset_rcvr() allows shared receivers to be set without limit. But zget_shrcvr_list() silently imposes a limit of 64 shared retrieves (ZcMAX_SHARED_RCVRS) that can be retrieved. So a program can keep setting shared receivers, but cannot retrieve the whole list. SR 5003427245 / DTS TPO0h02228 ACC does not comeup on reboot even when configured right. DTS TPO0h02421 When running ZTERM, the primary ZLU and the open ZLU (OP command) shows "$$$$" as the ZLU number. E.g. % zterm 19:15:54 ZCOM Interactive command utility 19:15:54 Primary ZLU is $$$$ ZTERM> ZTERM> op 19:15:58 ZLU #$$$$ opened with name AUX0235 ZTERM> op 19:16:03 ZLU #$$$$ opened with name AUX1235 ZTERM> DTS TPO0h02485 As your system is coming up during reboot, the ACC FixMajor script reports mknod errors. DTS TPO0h02486 Hardware failured detected errors logged which is followed by an ACC card reset. DTS TPO0h02617 Card reset due to heartbeat timeout or messages being logged indicating "Write completion length mismatch". SR 1653296699 / DTS TPO0h02624 The zmntr message counter values are displayed as "$$$$$$$" when the counter value exceeds 7 decimal digits. DTS TPO0h02759 Each time a "zmasterd stop" is issued, one or two additional zombie processes are left that do not disappear until a "zmasterd kill" is issued. DTS TPO0h02806 The zmasterd man page does not describe the "kill" option. PHNE_16933: SR 4701408526 / DTS TPO0h02428 wsio_map() error shows up in dmesg system log when mapping EISA driver buffer. PHNE_15602: SR 4701393827 The patch PHNE_15349 does not verify the version of ACC before installing. DTS TPO0h02076 The ROM timestamp kept in Interface Table (IFT) will be shown (by zmntr MX command) as Year 19xx after Year 2000. DTS TPO0h02076 Year 2000 - ROM timestamp will show 1900 after 2000 DTS TPO0h02097 Year 2000 - zterm timestamp incorrect after 1999 PHNE_15349: DTS TPO0h01966 No current method to determine hardware revision DTS TPO0h02007 zmntr displays port information about cards flagged as absent SR 4701391920 / DTS TPO0h01285 ZCOM subsystem startup failure with random symptoms Defect Description: PHNE_19216: SR 4701323840 / DTS TPO0h00545 This is an enhancement. A new mechanism is introduced. When the current log file (binary or text) gets to a max size, it is renamed with ".old" suffix (e.g. mon.tlog.old). A new empty log file is created as the current log file. If messages continue to come in before the end of day and the new log file hits the max again, it will be renamed again and OVERWRITE the previous ".old" file. This will result in losing messages. But the TOTAL size used by 1-day's log file is limited to TWICE the maximum file size. The default maximum size of a log file is set at 1Gb (text or binary log). Practically it means no limit, and is for backward compatibility. This maximum log file size can be set by the new zmlog options -B and -T. Note that the zmasterd list file "/opt/acc/cfg/zmasterd_list" needs to be modified manually to use the -T and -B options to set the maximum log file size to non-default values. SR 5003380527 / DTS TPO0h01523 Currently, zmasterd & zmon use msg queue (msgrcv, msgsnd) to communicate the command: zmasterd to zmasterd daemon and response: zmon daemon to zmasterd daemon. The msgsnd() call used is a "Send-With-Wait" call. When there is not enough msg buffer in the system, the caller will be suspended until msg buffer is available. In this case of bad kernel config, it will be forever. Both zmasterd & zmon are changed to do a loop of msgsnd() With-No-Wait. The loop is of 15 seconds (5 retries with 3-second sleep interval). If system is out of msg buffer for 15 seconds, both of them will detect the error: Resource temporarily unavailable. This error will be logged to zcomlog and to console. And zmasterd & zmon is able to continue its processing. DTS TPO0h01629 There was no option to specify a different path for the core dump directory. We have added the -f option that allows an user to specify the full path of the core dump. SR 5003415463 / DTS TPO0h02037 It is suspected that it is caused by contention in the driver, e.g. when multiple pieces of driver codes is trying to log messages and hitting some unprotected criticial sections. DTS TPO0h02107 It was missed out when the zx25*() functions were first introduced to ZCOM. Function prototypes are added to "zcomcall.h", which is intended to be included when user wants to have prototype checking. DTS TPO0h02189 A simple check is added to the LDM driver to limit the number of shared receivers to ZcMAX_SHARED_RCVRS (64). A new error ZERCVRFULL (-18) is returned when trying to add more receivers. The new error is added to zcomsys.h and zerrmsg.txt. zevent_rcvr, zset_rcvr man pages are also updated. SR 5003427245 / DTS TPO0h02228 The /sbin/rc2.d and /sbin/rc1.d links are not set up for the base product. DTS TPO0h02421 This is a long known problem in ZTERM when ZLU number is larger than 9999. ZTERM uses a 4-char buffer to convert the number to ASCII characters and its conversion routine uses $$$$ to indicate overflow. In TTGEN answerfile, if "Terminal-ZLU" is defined as 10000, ZCOM will use 10001 and onwards for program ZLUs. In this case, when ZTERM opens its primary ZLU, it'll get 10001, which will cause the conversion routine to overflow. The whole ZTERM program is checked for 4-digit conversion. If overflow can occur, it is changed to 5-digit conversion. Most of them are the ZLU numbers. Some LTT and PTT numbers are also fixed. DTS TPO0h02485 An incorrect newer version of FixMajor was included with the previous patch. DTS TPO0h02486 This problem was caused by an interrupt collision between the NIO Lo-Quix chip on the ACC card and the HP-UX host. That is, the card sent up an external interrupt at the exact same time the host told the card to turn-off interrupts and to start a DMA operation. This resulted in the Lo-Quix chip being unable to complete the DMA request which eventually times out. The nacc1 and nacc0 drivers was modified to detect this condition and to sequence events to avoid the problem. DTS TPO0h02617 The nacc drivers were being entered re-entrantly by the interrupt handler and/or user space request. This could result in a variety of symptoms or which two are listed. This was caused by timing windows in the code that could allow a second thread of execution in a multi-processor environment to reenter driver routines that do not allows this. The driver code was modified to eliminate the timing windows. SR 1653296699 / DTS TPO0h02624 This symptom is as designed and indicates and out-of-range number. That is, there is insufficient room to display the number. Zmntr has been enhanced to automatically scale the value when it exceeds the available space on the screen. When a counter value exceeds 999999, it is divided by 1000 and the character 'K' is appended to the value. If the counter value exceeds 999999999, it is divided by 100000 and the character 'M' is appended to the value. Note that the counter value is rounded to the nearest 1000 or 1000000 as appropriate. DTS TPO0h02759 After the "zmasterd stop" command completed, zmasterd was not receiving its children's termination signal causing them to be left hanging around in the system until the master copy of zmasterd terminated. The code has been modified to issue a waitpid() to terminate all children after the "stop" command is executed. DTS TPO0h02806 The zmasterd man page has been update to include the "kill" option of this utility. PHNE_16933: SR 4701408526 / DTS TPO0h02428 The dma data structure that used by nacc0 driver to call the eisa_dma_setup() was not initialized properly. This corrupted the EISA wsio_map directory table. PHNE_15602: SR 4701393827 There is a problem with the chekckinstall script of the patch PHNE_15349 DTS TPO0h02076 When zmon initializes an ACC card, it uploads the ROM ID information from the card. One of the fields is the ROM timestamp in YYMMDD.hhmm ASCII format. zmon extracts the digits and convert the timestamp to HPUX time and save it in IFT. The two-digit year value is passed to mktime(), which expects a year value since 1900. In Year 2000, a ROM timestamp with year "00" will be shown as 1900. The timestamp conversion in zmon is modified to check whether the 2-digit year is less than 70. If so, it adds 100 to the year number before calling mktime() to convert the time. This supports year 1970 to 2037. Year 1970 is chosen because it is the base year of HPUX time. Year 2037 is when the 32-bit time overflow. DTS TPO0h02076 When zmon initializes an ACC card, it uploads the ROM ID information from the card. One of the fields is the ROM timestamp in YYMMDD.hhmm ASCII format. zmon extracts the digits and calls mktime() to convert the timestamp to UNIX Epoch time (saved in IFT). The two-digit year value is passed to mktime(), which expects a year value since 1900. In Year 2000, a ROM timestamp with year "00" will be shown as 1900. DTS TPO0h02097 When zterm is employed, timestamp as well as activity will be reported. The call numerictime, currently returns a timestamp in the form YYMMDD.HHMMSS. In Year 2000, the timestamp is returned in the form YYYYMMDD.HHMMSS. The code, has been modified to accomodate for both scenarios. PHNE_15349: 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. DTS TPO0h02007 zmntr has been modified to not display port details of absent cards SR 4701391920 / DTS TPO0h01285 The ACC drivers (like most HP-UX drivers) use dynamic major numbers. When the ACC software is installed, its device files are created with the correct major numbers. However, if other products are removed and/or installed, HP-UX can sometimes change the ACC's major numbers without its knowledge. The results in the ACC device files now pointing ot non-existent or the wrong drivers. The ACC utilities are then no longer able to access the ACC kernel components in the expected way. Since the utilities (e.g. zmasterd) are issuing request to non-ACC components, the symptoms will vary depending on whose kernel drivers the device file major numbers point to. The ACC major numbers can only change when the system is rebooted. New scripts have been written which are now scheduled at every system bootup that scans all of the ACC device files and recreates them with the correct major numbers as needed. SR: 4701391920 4701393827 4701408526 4701323840 5003380527 5003415463 5003427245 1653296699 Patch Files: /sbin/init.d/acc /etc/rc.config.d/acc /opt/acc/lbin/FixMajor.awk /opt/acc/bin/zmlog /opt/acc/msg/def.zmlog.txt /opt/acc/bin/zmon /opt/acc/bin/eacc_trc /opt/acc/bin/axin_trc /opt/acc/bin/zx25trc /usr/conf/lib/libzcom.a /opt/acc/include/zcom/zcomcall.h /opt/acc/include/zcom/zcomsys.h /opt/acc/msg/zerrmsg.txt /opt/acc/share/man/man3.Z/zevent_rcvr.3x /opt/acc/share/man/man3.Z/zset_rcvr.3x /opt/acc/bin/zterm /opt/acc/lbin/FixMajor /usr/conf/lib/libeacc.a /opt/acc/bin/zmntr /opt/acc/bin/zmasterd /opt/acc/share/man/man1.Z/zmasterd.1 /opt/acc/lbin/ACC_ksh_functs /opt/acc/.patch_build_info_PHNE_19216 what(1) Output: /sbin/init.d/acc: None /etc/rc.config.d/acc: None /opt/acc/lbin/FixMajor.awk: None /opt/acc/bin/zmlog: ACC Rel B.02.23 for B.10.20 PHNE_19216 zmlog ACC Rel B.02.23 for B.10.20 PHNE_19216 $Header: libz md.c@@/main/5 06/11/96 07:11:07 $ /opt/acc/msg/def.zmlog.txt: $Header: def.zmlog.txt@@/main/r2.23/1 05/25/99 16:1 1:54 $Rev: /main/r2.23/1 $ /opt/acc/bin/zmon: ACC Rel B.02.23 for B.10.20 PHNE_19216 $Header: zmon .c@@/main/r2.23/3 05/28/99 11:05:05 $ ACC Rel B.02.23 for B.10.20 PHNE_19216 $Header: libz md.c@@/main/5 06/11/96 07:11:07 $ /opt/acc/bin/eacc_trc: ACC Rel B.02.23 for B.10.20 PHNE_19216 $Header: eacc _trc.c@@/main/r2.23/1 05/21/99 17:51:35 $ /opt/acc/bin/axin_trc: ACC Rel B.02.23 for B.10.20 PHNE_19216 axin_trc /opt/acc/bin/zx25trc: ACC Rel B.02.23 for B.10.20 PHNE_19216 zx25trc /usr/conf/lib/libzcom.a: ACC Rel B.02.23 for B.10.20 PHNE_19216 $Header: zcom 0.c@@/main/r2.23/1 11/11/96 17:33:46 $ /opt/acc/include/zcom/zcomcall.h: $Header: zcomcall.h@@/main/r2.23/1 05/26/98 21:20:4 0 $Rev: /main/r2.23/1 $ /opt/acc/include/zcom/zcomsys.h: $Header: zcomsys.h@@/main/r2.23/2 05/28/99 12:40:44 $Rev: /main/r2.23/2 $ /opt/acc/msg/zerrmsg.txt: $Header: zerrmsg.txt@@/main/r2.23/1 05/28/99 12:51: 07 $Rev: /main/r2.23/1 $ /opt/acc/share/man/man3.Z/zevent_rcvr.3x: None /opt/acc/share/man/man3.Z/zset_rcvr.3x: None /opt/acc/bin/zterm: ACC Rel B.02.23 for B.10.20 PHNE_19216 $Header: zterm.F@@/main/r2.23/3 07/26/99 16:30:27 $ /opt/acc/lbin/FixMajor: None /usr/conf/lib/libeacc.a: ACC Rel B.02.23 for B.10.20 PHNE_19216 libeacc.a /opt/acc/bin/zmntr: ACC Rel B.02.23 for B.10.20 PHNE_19216 $Header: zmntr.F@@/main/r2.23/5 05/26/99 19:01:59 $ /opt/acc/bin/zmasterd: ACC Rel B.02.23 for B.10.20 PHNE_19216 $Header: zmas terd.c@@/main/r2.23/2 05/28/99 11:11:16 $ ACC Rel B.02.23 for B.10.20 PHNE_19216 $Header: libz md.c@@/main/5 06/11/96 07:11:07 $ /opt/acc/share/man/man1.Z/zmasterd.1: None /opt/acc/lbin/ACC_ksh_functs: None /opt/acc/.patch_build_info_PHNE_19216: None cksum(1) Output: 589639145 1997 /sbin/init.d/acc 2974354459 1116 /etc/rc.config.d/acc 993209107 191 /opt/acc/lbin/FixMajor.awk 1382941708 24723 /opt/acc/bin/zmlog 1755106854 2507 /opt/acc/msg/def.zmlog.txt 3127755345 37038 /opt/acc/bin/zmon 2630946254 24642 /opt/acc/bin/eacc_trc 2879129905 41031 /opt/acc/bin/axin_trc 3151831758 20547 /opt/acc/bin/zx25trc 1913658545 206504 /usr/conf/lib/libzcom.a 280613896 5223 /opt/acc/include/zcom/zcomcall.h 3490958141 72333 /opt/acc/include/zcom/zcomsys.h 1322149708 4973 /opt/acc/msg/zerrmsg.txt 4164225442 7104 /opt/acc/share/man/man3.Z/zevent_rcvr.3x 164437332 5877 /opt/acc/share/man/man3.Z/zset_rcvr.3x 3498264932 3338 /opt/acc/lbin/FixMajor 1684140738 55144 /usr/conf/lib/libeacc.a 3880193531 115198 /opt/acc/bin/zmntr 1052431880 28866 /opt/acc/bin/zmasterd 2794825371 4639 /opt/acc/share/man/man1.Z/zmasterd.1 1521241154 123269 /opt/acc/bin/zterm 2467478852 7701 /opt/acc/lbin/ACC_ksh_functs 1113409080 1140 /opt/acc/.patch_build_info_PHNE_19216 Patch Conflicts: None Patch Dependencies: None Hardware Dependencies: None Other Dependencies: None Supersedes: PHNE_15349 PHNE_15602 PHNE_16933 Equivalent Patches: None Patch Package Size: 880 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_19216 5a. For a standalone system, run swinstall to install the patch: swinstall -x autoreboot=true -x match_target=true \ -s /tmp/PHNE_19216.depot By default swinstall will archive the original software in /var/adm/sw/patch/PHNE_19216. 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_19216.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_19216.depot of=/dev/rmt/0m bs=2k Special Installation Instructions: SUBSYSTEM_SHUT Before installing this patch, use the following command to shutdown the ACC subsystem and kill the ACC daemons. /opt/acc/bin/zmasterd kill The above command kills any of the ACC daemons that are still running, including zmasterd, zx25d, watch, zmlog, zmon, and znode. The kernel will be regenerated and the system will reboot automatically during the patch installation.