Patch Name: PHNE_18716 Patch Description: s700_800 10.20 2.40-2.40.02 ACC Base Software Patch Creation Date: 99/08/23 Post Date: 99/09/29 Hardware Platforms - OS Releases: s700: 10.20 s800: 10.20 Products: Z7299A_APZ Z7301A_APZ Z7401A_APZ Z7404AA_APZ Z7422AA_APZ Filesets: ACC.ACC-KRN ACC.ACC-RUN ACC.ACC-PRG ACC.ACC-FW ACC.ACC-MAN Automatic Reboot?: Yes Status: General Superseded Critical: Yes PHNE_18716: PANIC PHNE_17877: OTHER Bad FixMajor script. Reboot error. PHNE_16615: OTHER DMA timeout. PHNE_15350: PANIC Path Name: /hp-ux_patches/s700_800/10.X/PHNE_18716 Symptoms: PHNE_18716: DTS TPO0h02823 The fault handling routines in the firmware do not decode the fault record that the CPU writes to the stack. DTS TPO0h02806 The zmasterd man page does not describe the "kill" option. DTS TPO0h02738 This bug causes a "firmware error 5" type card crash for the Z7330A and a "DMA timeout" for the Z7300A card. It occurs at random and is statistically more likely to occur, the greater the message rate. A high rate of short messages on relatively few channels is more likely to cause the problem than long messages on many channels. DTS TPO0h02674 SAM does not display a description of the ACC kernel tunable parameters or subsystems. DTS TPO0h02813 Confusing message logged by ttgen for an invalid port mode DTS TPO0h02786 This defect is a follow up to defect TPO0h02762. That defect addressed problems experienced when the 4-channel E1/T1 cards were loaded up in such a way that the Munich chip receive descriptors would overrun. This could be made to happen more readily by using a very small buffer size (32 bytes) with large frames. The symptom was usually that the receive channel would hang so no more frames could be received, until the subchannel was re-enabled. The changes made for TPO0h02762 fixed these problems except in a rare case, when it is still possible for the receive channel to hang. DTS TPO0h02765 netfmt fails after the r2.40.01 ISDN/ACC product is installed DTS TPO0h02783 TTGEN does not allow an E1/T1 port to be configured in "Loopback" mode unless the Frame mode is set to TRANS. DTS TPO0h02610 Add Q4 support for the 10.X release. DTS TPO0h01522 The x.25 firmware was failing to transmit a level 3 RR on a PVC when activated. Deactivating a PVC did result in a level 3 RNR being sent. 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 TPO0h02173 On LAPB/LAPD connection establishment, groups of DM frames are sentbetween 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 TPO0h02242 DMA timeout errors occur in running ISDN/X.25. DTS TPO0h02245 The pmon utility does not clean up its dynamically created terminals on exiting. DTS TPO0h02255 The ACC X.25 firmware occasionally fails in creating a large number of X.25 virtual circuits in a short period of time. This problem was discovered in executing a stress test that attempts to establish 1024 VCs. The driver sometimes detected that write completion messages arrived out of sequence. DTS TPO0h02273 An x.25 PVC cannot be enabled after being explicitly disabled.This problem only occurs on the 4 port cards (I960 based) DTS TPO0h02438 When an exception occurs on an ACC card, a card reset is sometimes required before a firmware dump is taken. It has been found that some valuable data in the dump file gets corrupted, making the analysis of the firmware dump file much harder. DTS TPO0h02620 The axin driver sometimes detects error -43 (timeout of level 2 disable request) in the nettl log, while attempting to shutdown an X.25 link. DTS TPO0h02775 The lbtest() library function, which is called by ZMNTR to perform the port loopback test on E1/T1 ports, can cause a core dump. DTS TPO0h02774 When an E1/T1 port is re-configured, while other ports are in use, it is possible for a "Backplane DMA timeout" to occur. DTS TPO0h02762 With small buffers configured and large frames, it is possible to overrun the available receive and transmit descriptors used by the Munich chips. For example, with a buffer size of 32 bytes, a received frame larger than 588 bytes, or a transmitted frame larger than 1584 bytes cannot be handled. The level-1 protocol does not handle these cases cleanly, and can stop receiving or transmitting frames correctly. DTS TPO0h02331 When using zconfig() to dynamically configure ports on E1/T1 ACC cards, there is no check for invalid timeslot and subchannel configurations. DTS TPO0h02681 The 60008 version of the 4-ch PCI card cannot synchronise correctly in E1 mode. The PMON output indicates occasional "Slip" errors which correspond to data errors on the line. DTS TPO0h01918 The selftest on the Z7300A 4 port ACC cards can very occsasionally not complete, leading to a timeout. DTS TPO0h02063 The port configuration done via zconfig() should be able to configure a timeslots or subchannels without affecting the operation of the rest of the port. This feature was never completed in the original implementation. DTS TPO0h02239 The 4 port ACC is not able to detect an error condition when the ACC transmit side has been disconnted, but the recive side remains intact. It does not act on a received RAI signal. DTS TPO0h02423 TTGEN does not report an error when inappropriate framing or encoding options are used for an E1 or T1 port configuration. DTS TPO0h02446 TTGEN fails to catch re-defined subchannels. For example : subchannel 3 mapped to timeslot 3 subchannel 4 mapped to timeslot 4 subchannel 3 mapped to timeslots 8-31 DTS TPO0h02477 Subchannel quota tables can be corrupted leading to an incorrectly reported "buffer shortage". DTS TPO0h02676 The transmitted T1 signal waveform for the T1 RJ45 100ohm mode is not within the T1 specification. 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 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 TPO0h02723 It is possible for an E1/T1 line to go down within one second of a received RAI or loss of frame sync. The FALC protocol module is supposed to ensure that the line is DOWN for 3 to 4 seconds before the other layers are informed. DTS TPO0h02246 DTS TPO0h02246With the PMON utility in use, the ZMNTR loopback test cannot be run on any E1/T1 port. 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 None / DTS TPO0h01209: port mode validation is incorrect in ttgen SR 5003380527 / DT 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(). SR None / DTS TPO0h01629: Traces won't work if the core dump is not in the default directory. (/var/adm/crash) DTS: TPO0h02037 SR: 5003415463 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. SR:None / 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 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: 5003427252 / DTS TPO0h02222: When BX.25 code is compiled with zcomsys.h, compiler gives error about the TRUE/FALSE definitions. SR: 5003427245 / DTS TPO0h02228: ACC does not comeup on reboot even when configured right. TPO0h02238: zconfig terminal delete deletes mux terminal but returns error TPO0h02263: When using the X.25 protocol in the Z7300A and Z7330A 4-port ACC cards, if expeditied data (interrupt packets) are sent, the virtual circuit will be reset with disgnostic code of 145 three minutes after the interrupt packet is transmitted. TPO0h02280: On the Z7330A and Z7300A 4-port ACC cards, a subchannel can occasionally stop receiving frames on one port. This would be indicated at the protocol level by timeouts and excessive retry errors. The subchannel can only be recovered by re-initializing the port. TPO0h02292: In TTGEN, the port and subchannel checks for T1 and E1 ports are of no difference. This is not correct and causes illegal configuration passed down to the mux. TPO0h02389: On the Z7300A and Z7330A 4-port ACC cards, under high message loads with large messages, an occasional single byte of user message data can be corrupted. TPO0h02421: TPO0h02425: 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: TPO0h02428 SR: 4701408526 wsio_map() error shows up in dmesg system log when mapping EISA driver buffer. TPO0h02486: Hardware failured detected errors logged which is followed by an ACC card reset. 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. TPO0h02669: During extreme card activity (especially inbound data) PCI systems, the system may panic with the following cause: Non-access data TLB miss (on the ICS) The panic stack trace produced by Q4 is: crash event was a panic panic+0x14 report_trap_or_int_and_panic+0x4c interrupt+0x1ec $ihndlr_rtn+0x0 nacc1_start_dma+0x394 nacc1_do_next_task+0x105c nacc1_int_event+0xc58 nacc1_isr+0x20 dino_isr+0x128 inttr_emulate_save_fpu+0x100 idle+0x49c swidle_exit+0x0 TPO0h02685: Method required to repetitively run ACC card selftest for diagnostic purposes. TPO0h02712: During ZCOM subsystem startup, the following error messages are placed into the ZCOM log file: zcom 00206 Card 0 Port 4 configuration failed with error 3. zcom 00206 Card 0 Port 5 configuration failed with error 1. The messages are logged infinitely with the port number being incremented by one for each message logged.This ZCOM log file quickly grows to fill the entire disk. 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. PHNE_17877: TPO0h02485: As your system is coming up during reboot, the ACC FixMajor script reports mknod errors. PHNE_16615: SR 5003437947 For NIO 8-port ACC cards, DMA timeout was occurring during ZCOM/ACC subsystem startup in HP K class systems (and potentially any T series) with 2 or more ACC cards installed. The problem is faster to reproduce if 2 ACC cards have failing ports and/or the ACC cards are not numbered consecutively (0, 1, 2, etc.) in the user's ACC .answ file. PHNE_15350: TPO0h01894: Loopback test on Z7330A and Z7300A cards may sometimes fail. TPO0h01645: ZMNTR loopback command does not report errors for wrong options used. TPO0h01493: ZTERM on-line help is incomplete. SR 4701391862 / DTS TPO0h01966 No current method to determine hardware revision SR 5003417972/ DTS TPO0h2086 System panics when zx25l2stat_rcvr() called rapidly from remote node. DTS TPO0h01934 Timeout on $RSET cannot be distinguished from hard reset timeout DTS TPO0h01483 (Same as DTS TPO0h01934) AMADEUS - zmasterd may be returning before card is completely up or down TPO0h01179: Under high message loads on the Z7300A and Z7330A 4 port E1/T1 cards, the central processor utilisation is higher than expected. PHNE_13990: DTS TPO0h01661 DAM runs heartbeat timer on an "unusable" card DTS TPO0h01285 For HP-UX 10.0 and later, all driver major numbers are dynamically assigned. When the ACC software is installed, its devices are created with the correct major numbers. However, if other products containing kernel driver components are removed and/or new kernel driver components are installed, the HP-UX system can sometimes change the ACC's major numbers without its knowledge. The results in the ACC device files now pointing to non-existent or the wrong (non-ACC) drivers. The ACC utilities are then no longer able to access the ACC kernel components in the expected way (the results of the access is random). DTS TPO0h01643 zmon message 00111 (Last backplane command) has bad info for 4 port card DTS TPO0h01285 The ZCOM subsystem will fail to startup typically with an immediate error return, but sometimes with random symptoms. DTS TPO0h01822 DMA timeouts on 4 port card DTS TPO0h01913 During a card restart, the following message is logged for a ZLU: zcom 00207 ZLU 3 Set terminal parameters failed with error: Protocol not loaded. After the card restart processing completes, all ZLUs mentioned by the above message will be unusable (hung). DTS TPO0h01914 Request issued to a ZLU hangs and is never processed. That is,it is queued in the data structures but never sent to the card. DTS TPO0h02076 Year 2000 - ROM timestamp will show 1900 after 2000 DTS TPO0h02097 Year 2000 - zterm timestamp incorrect after 1999 Defect Description: PHNE_18716: DTS TPO0h02823 The fault handling routines have been enhanced to decode the fault record on the stack and placed in global storage. Also the G and R registers are saved (and the first 2 G registers are no longer corrupted). DTS TPO0h02806 The zmasterd man page has been update to include the "kill" option of this utility. DTS TPO0h02738 The problem is caused by some unprotected critical code. With high message load, there is more chance that the unprotected code will be interrupted and re-executed by the interrupt process, which causes queue corruption. DTS TPO0h02674 The SAM description files have never been created for the ACC products. This patch now includes appropriate ACC files for SAM. DTS TPO0h02813 When a port mode value is specified in the TTGEN configuration that is not supported by the card type, the error message logged is unclear or confusing. The message text has been modified to indicate the port mode value is invalid for the card type. DTS TPO0h02786 This problem occurs when a very high receive descriptor load is immediately followed by two background crxio() processes. This leads to the receive descriptor with the HOLD bit set to remain the HELD descriptor. This prevents the Munich from receiving any further frames until the subchannel is disabled and enabled again. With a normal configuration this problem is possible but very unlikely to occur. DTS TPO0h02765 After the r2.40.01 ISDN/ACC product is installed, the /etc/nettlgen.conf file will contain the ISDN_ACC_USR record to refer to the libTELfmt.sl shared library. netfmt fails when it refers to the libTELfmt.sl which is not built properly. DTS TPO0h02783 The error checking for invalid port configurations failed to account for a port mode setting of LBACK. That is, TTGEN was validating that when the port mode was configured for E1, that E1 frame modes were used and that when the port mode was T1, that T1 frame modes were used. This caused the frame mode check to fail an E1 or T1 specific frame mode was selected and the port mode was set to LBACK (because LBACK is neither T1 or E1). The code has been modified to allow all frame modes when the port mode is LBACK. DTS TPO0h02610 There is a commitment to provide Q4 support for the ACC B.02.39 and B.02.40 releases. DTS TPO0h01522 Mishandling of the rrch flag was found in the firmware code. The handling of the flag has been corrected. 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 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 TPO0h02242 An X.25 status request transaction is sent to the card while the terminal is being deleted. The stat request is queued on the terminal's queue, but not through the normal mechanism which pushes the backplane code onto the message stack. This mechanism did not check if the terminal is deleted. When a new terminal (with same terminal#) is created some time later, the stat request is sitting on its queue. It is then processed by the protocol layers and a stack underflow occurs, producing a CPU fault. The code has been changed to include the verification that the terminal is not deleted, which prevents the stat request transactions from being queued. DTS TPO0h02245 The pmon utility doesn't delete the receiver for the dynamic reconfiguration events using the zevent_rc. The cleanup code has been added to the exit routine. DTS TPO0h02255 The X.25 firmware was using an 8-bit sequence counter to ensure in-sequence delivery of write completion messages back to the host. The result is that the firmware could not handle more than 256 outstanding transmitted packets at once Since these particular request messages arrive on the card via the express queue, no flow-control mechanism is in place . More than 256 sent requests to the card resulted in out of sequence write completions. The X.25 firmware sequence counter has been extended to 16 bits. This increases the maximum outstanding requests to 65536 messages. DTS TPO0h02273 Mishandling of the cclr flag was found in the firmware code.The handling of the flag has been corrected. DTS TPO0h02438 The firmware selftest (of the Munich chips) overwrites an area of memory that is used to store data during firmware execution. This Munich selftest is executed as part of the card reset. Since the self-test code is contained in the ROM has been reorganised to avoid the areas used by the Munich self-test. DTS TPO0h02620 The x25 firmware incorrectly processes the disable request if there were outstanding uncompleted control write requests, because of pending level 2 control packets to be transmitted. The x25 firmware processing of the disable request has been corrected. DTS TPO0h02775 There is a switch() statement in lbtest.c which has it's logic wrong! There is an almost identical problem in the almost identical code in pmon.c which, although it has not yet caused a problem, is also fixed. DTS TPO0h02774 The problem occurs when the process_port.c module performs a hardware reset of the Munich and Falc chips on the port - using a library function port_reset(). As part of this reset the register 0xC0000004 is written with bit 3 set (DHOLD bit). This is intended to prevent ALL Munich chips accessing the system bus during the hardware reset. What happens is that if there is Munich activity on the system bus when the DHOLD bit is set, then only a few more Munich cycles occur and then the system bus is permanently stopped. The port configuration can only cause this problem if at least one other port is in operation. The Munich chips are now given a 'soft' reset when the port is re-configured. The hadware reset is not used at all. DTS TPO0h02762 The boundary case where the Munich receive channel goes through the whole descriptor chain before any are freed up, is not handled. Additionally there is no provision to handle frames larger than can be contained in the available set of receive descriptors. On the transmit side, frames which are too large to be processed with the available transmit descriptors, can be left queued forever, causing the transmit channel to hang. The new version of frame.c can now handle any size received frame, regardless of the configured buffer size. On the transmit side, frames which could be transmitted when TDs are freed up later are left queued. Frames which can never be transmitted because they contain more buffers than there are transmit descriptors available are flushed with the IO_LONG_MSG status code. The maximum size transmit frame can be calculated with the formula: F = (B-16) * 99 Where B is the configured buffer size and F is the maximum transmit frame size. DTS TPO0h02331 This defect follows on from TPO0h02292, which addresses error detection in ttgen of unusable timeslots for T1. This defect is to include an error check in the 4-port firmware $PORT command to reject invalid configurations when using dynamic configurations. For the general port configuration (ZcDSC_ALL_PARMS) the firmware now prevents timeslot 0 being assigned to any subchannel except subchannel 0 (must be allowed for the default - unconfigured - case). The firmware prevents timeslots 25 to 31 being assigned to any subchannel except subchannel zero in T1 mode. For timeslot configuration requests, the firmware does not allow timeslot zero to be configured, or timeslots 25 to 31 in T1 mode. DTS TPO0h02681 The FALC-LH has many changes in this area , and the new "loop-timed" mode is now necessary for E1 to operate correctly. The description of the "looped-timed" proessing in the FALC-LH documentation matches precisely what we require for "EXT clock" operation. In the changes originally made for the 60008 card, Loop-timed was included as an extra clock mode. For this defect, the loop-timed clock option will be removed, and "Loop-timed" mode enabled on the FALC-LH whenever "EXT clock" is configured. DTS TPO0h01918 The Munich communications controller can be requesting the i960 bus access, just as it is reset at the end of the selftest. This condition prevents further processing by the i960 microsprocessor, until the i960 is reset. The workaround to the problem is to implement a reset retry mechanism in zmon, to retry the selftest if it fails to complete. DTS TPO0h02063 The ZcDSC_SET_TIMESLOTS and ZcDSC_SET_SUBC_SPECS $PORT actions are now implemented as specified in the original E1/T1 card ERS. The LDM, DAM and firmware all had to be changed. When the ZcDSC_SET_TIMESLOTS and ZcDSC_SET_SUBC_SPECS $PORT actions are requested the LDM was checking the length of the supplied subchannel/timeslot buffer incorrectly. The LDM now checks that the buffer length is equal to "sizeof(subchbuf_def)". On completion of these requests the DAM has to update the subchannel and timeslot configurations which have been modified. This is now implemented. The firmware module backplane.c has been modified to check the appropriate subchannels for any enabled terminals when a ZcDSC_SET_TIMESLOTS or ZcDSC_SET_SUBC_SPECS action is requested. ie. When configuring a timeslot, the current subchannel and new requested subchannel (may be the same one) must both be checked for any enabled terminals, and when configuring a subchannel, that subchannel must be checked for any enabled terminals. If any terminals are enabled a new status code (PT_SC_ENB) is reported. The man page for zconfig.3x has been updated to explain the use of the ZcDSC_SET_TIMESLOTS and ZcDSC_SET_SUBC_SPECS actions. DTS TPO0h02239 The HDLC.FRAME protocol now puts the line down if RAI is received continuously for 3-4 seconds (as well as when frame sync is lost). DTS TPO0h02423 For E1 the options are: Framing DF CRCMF Encoding HDB3 AMI For T1 the options are: Framing F4 SF ESF F72 Encoding B8ZS AMI These are not interchangeable. These checks are now in place. DTS TPO0h02446 TTGEN now reports an error in this case. DTS TPO0h02477 The mqfreeput() library function, when freeing a message composed of a queue of message headers (rather than buffers), makes the assumption that all of the component messages will have originated from the same subchannel as the first message, and adjusts the subchannel quota table of the first message header in the queue accordingly. This assumption is not always correct and can lead to the subchannel quota tables being corrupted. This does not affect any of the existing protocols, since there is never a case where messages originating from different subchannels are queued on the same message header. In the new firmware, as each message is freed from the message header queue, the quota pointed to by the freed message is updated. DTS TPO0h02676 The FALC waveform shaping parameters for the T1 RJ45 100ohm case are not right. New parameters are now implemented. 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. 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 TPO0h02723 The "downcounter" used to count the number of one second events at which the state of the line has changed does NOT get reset whenever the line is found UP in the UP state or DOWN in the DOWN state. This means the "second" count keeps accumulating until the line state changes. So if the line was found down 4 times since the port was started up then the next time the line is found to be down, the line will be marked DOWN immediately. The state is still checked only once each second so glitches are unlikely to bring the line down. However the line may go down within one second of the "Remote alarm" signal occuring in this case. This would only be noticed on a line with a lot of errors or one which has been running for a long time. The "downcounter" is now reset each time the line is found to be UP. DTS TPO0h02246 Because PMON creates a monitoring terminal on each E1/T1 port and enables it, ZMNTR cannot re-configure these ports. The answer is for ZMNTR to disable the PMON terminal on a port while it runs the loopback test on that port. The PMON terminal can then be re-enabled. 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. TPO0h01209 ttgen did not take into account the entire set of ACC boards. 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. 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. 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. 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. 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. 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. TPO0h02222 In zcomsys.h, the TRUE/FALSE definitions uses type casting to zc_boolean. Somehow, in some BX.25 application source, this crashes with other defintions of TRUE/FALSE. TPO0h02228 The /sbin/rc2.d and /sbin/rc1.d links are not set up for the base product. TPO0h02238 The zconfig delete request is processed as far as the (destructive) zcntl delete request (which succeeds and make the terminal unavailable), but fails to complete the request by fully deleting the host terminal structures because of the queued message. TPO0h02263 The internal timer for the interrupt confirmation packet was not being stopped when the interrupt confirmation was received. The code has been corrected. TPO0h02280 A subchannel can be unexpectedly initialized as a result of an incorrect command to the Munich HDLC controller. The condition no longer causes the subchannel to be intialized. TPO0h02292 The appropriate checks are added to ttgen: For T1 port: valid subchannel numbers: 0..31 valid timeslot numbers: 1..24 For E1 port: valid subchannel numbers: 0..31 valid timeslot numbers: 1..31 TPO0h02389 When a large number of received messages are transferred in a single backplane transaction, the last byte of user data in a dma transfer can be corrupted. The code has been corrected to ensure the data is correctly set up before the dma transfer is initiated. 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. TPO0h02425 Here is a case where a msg was sent down to the card and the Write completion is yet to arrive. Meanwhile the Terminal is deleted that causes the Express, Hi and low priority queues to be flushed. On the arrival of Write completion we try to match and get to the msg we sent to the card and since the queues are flushed as part of deleting the TERM it does not find it. So results in panic. TPO0h02428 The problem is analyzed to be that we are not ZERO-ing the data structures used for eisa_dma_setup() . 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. 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. TPO0h02624 This symptom is as designed and indicates and out-of-range number. That is, there is insufficient room to display the number. TPO0h02669 When the driver receives an external interrup performing the byte swap. If the number of pending events exceeded 127, a *very* large negative number results which is used to program the next DMA operation which then cause the indicated panic. TPO0h02685 An enhancement is provided to run the ACC card selftest repetitively using a new command SF. Please consult the SF command help interactively for further information. From the zdbi960 prompt type: "? sf" TPO0h02712 This problem occured due to an incorrectly coded IF statement which allowed the RESTART processing to continue past the end of the number of ports allowed on the E1/T1 card and also not retrieving the next port to be processing in the completion function. This caused the driver to continue issuing $PORT request for MAXINT number of ports. All $PORT request past port #3 would fail with an error message thus filling up the disk with zmlog error messages. The 4-port E1/T1 driver code has been corrected. 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. PHNE_17877: TPO0h02485: An incorrect newer version of FixMajor was included with the previous patch. PHNE_16615: SR 5003437947 The system part of the firmware was not verifying whether the LO-QUIX chip (responsible for managing backplane transactions) on the ACC card was ready before requesting another I/O operation. PHNE_15350: TPO0h01894: The relays used to connect the network and loopback lines on the E1/T1 cards take a finite time to switch. The loopback test can sometimes be too fast for the relays and the test can fail. TPO0h01645: The only options accepted now are "i" "e" or "2". The first bad option character is reported to the user. TPO0h01493: The ZTERM on-line help file has been updated. 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. DTS TPO0h01934 The ZCOM startup does not wait for all the card to startup. If a device failed to startup, the zmasterd utility returns without knowing if the card startup retry is successful. SR 5003417972/ DTS TPO0h2086 Panic was due to ZCOM memory corruption. One of the Znode kernel routine was calling a ZCON routine with a missing argument. This caused the ZCOM memory to be corrupted. TPO0h01179: The multi-message protocol used to transfer messages to and from the card is under-utilised, resulting in more driver activity than is necessary. This is an enhancement to introduce a delay in the data transfers to and from the ACC cards, to allow better advantage to be taken of the multi-message protocol. The default delay is 5 milliseconds, allowing significant reduction in cpu utilisation, whilst having a minimal increase in message latency. The default value is strongly recommended.To configure the delay, use the keyword "datadelay " in the interface definiton section of the ttgen .answ file.To override the delay, use "datadelay 0". PHNE_13990: DTS TPO0h01661 Heart beat timeouts on unusable card DTS TPO0h01913 This problem occurs when a ZLU has been dynamically created but has not yet been configured with a zcntl request to set the terminal paramters and the card is restarted (either through a firmware failure or user initiated action). Part of the restart processing is to issue a set terminal parameters request on every ZLU that is defined. In this case, the terminal parameter data is all NULLs (since the user has not configured it yet) which results in the firmware failure the request with a "protocol not loaded" error. Note that part of ther terminal parameter data is which protocol to use. TPO0h01914 The application is dynamically creating a ZLU on a subchannel or port that has not been defined or configured. The dynamic configuration code is not checking for this condition. 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 YYYMMDD.HHMMSS.The code, has been modified to accomodate for both scenarios. SR: 4701323840 5003380527 5003415463 5003427245 4701408526 1653296699 4701323840 5003380527 5003415463 5003427252 5003427245 4701408526 1653296699 4701381277 4701391862 5003417972 5003437947 Patch Files: /usr/conf/masterd.d/nacc /opt/acc/share/man/man1.Z/zmasterd.1 /usr/sam/lib/kc/paramsACC.tx /usr/sam/lib/kc/subsysACC.tx /usr/sam/lib/kc/driversACC.tx /opt/acc/TEL/lib/libTELfmt.sl /opt/acc/protocol/testprot.zrel /usr/conf/lib/libnacc1_niosyms.o /usr/conf/lib/libnacc1_pcisyms.o /usr/conf/lib/libnacc_eisasyms.o /usr/conf/lib/libnacc_niosyms.o /usr/conf/lib/libzcomsyms.o /opt/acc/msg/default.txt /opt/acc/bin/pmon /opt/acc/sys/wmux4.zrel /opt/acc/bin/zdbi960 /opt/acc/msg/def.zdbi960.txt /opt/acc/share/man/man3.Z/zevent_rcvr.3x /opt/acc/share/man/man3.Z/zset_rcvr.3x /opt/acc/msg/zerrmsg.txt /opt/acc/bin/zmasterd /opt/acc/bin/nacc1_stats /opt/acc/bin/nacc1_trc /opt/acc/bin/nacc_trc /opt/acc/include/zcom/zcomcall.h /opt/acc/bin/zmlog /opt/acc/msg/def.zmlog.txt /sbin/init.d/acc /etc/rc.config.d/acc /opt/acc/lbin/FixMajor.awk /opt/acc/z7350a/loopback.zabs /opt/acc/z7350a/loopback.zmap /opt/acc/protocol/level1.zrel /opt/acc/msg/def.zcom.txt /opt/acc/lbin/FixMajor /opt/acc/bin/zmon /opt/acc/bin/zmntr /usr/conf/lib/libnacc_nio.a /usr/conf/lib/libnacc_pci.a /usr/conf/lib/libzcom.a /opt/acc/z7400a/loopback.zabs /opt/acc/z7400a/loopback.zmap /opt/acc/sys/z7350_fw.zrel /opt/acc/sys/z7400_fw.zrel /opt/acc/z7300a/download.zabs /opt/acc/z7330a/download.zabs /opt/acc/bin/ttgen /opt/acc/bin/zscan /opt/acc/msg/def.ttgen.txt /opt/acc/msg/def.zscan.txt /opt/acc/msg/zterm.hlp /opt/acc/include/zcom/zcomsys.h /usr/conf/acc/zcomsys.h /opt/acc/bin/zterm /opt/acc/sys/wmux3.zrel /opt/acc/sys/wmux1.zrel /opt/acc/z7200a/loopback.zabs /opt/acc/z7200a/loopback.zmap what(1) Output: /usr/conf/masterd.d/nacc: None /opt/acc/share/man/man1.Z/zmasterd.1: None /usr/sam/lib/kc/paramsACC.tx: None /usr/sam/lib/kc/subsysACC.tx: None /usr/sam/lib/kc/driversACC.tx: None /opt/acc/TEL/lib/libTELfmt.sl: None /opt/acc/protocol/testprot.zrel: ZCOM Port Diagnostic Module ACC Rel B.02.40-B.2.40.02 for B.10.20 PHNE_18716 te stpro /usr/conf/lib/libnacc1_niosyms.o: ACC Rel B.02.40-B.2.40.02 for B.10.20 PHNE_18716 lib nacc1_niosyms.o /usr/conf/lib/libnacc1_pcisyms.o: ACC Rel B.02.40-B.2.40.02 for B.10.20 PHNE_18716 lib nacc1_pcisyms.o /usr/conf/lib/libnacc_eisasyms.o: ACC Rel B.02.40-B.2.40.02 for B.10.20 PHNE_18716 lib nacc_eisasyms.o /usr/conf/lib/libnacc_niosyms.o: ACC Rel B.02.40-B.2.40.02 for B.10.20 PHNE_18716 lib nacc_niosyms.o /usr/conf/lib/libzcomsyms.o: ACC Rel B.02.40-B.2.40.02 for B.10.20 PHNE_18716 lib zcomsyms.o /opt/acc/msg/default.txt: $Header: default.txt@@/main/4 11/20/96 15:33:26 $ /opt/acc/bin/pmon: ACC Rel B.02.40-B.2.40.02 for B.10.20 PHNE_18716 pmo n /opt/acc/sys/wmux4.zrel: ZCOM System Software (WMUX4) ACC Rel B.02.40-B.2.40.02 for B.10.20 PHNE_18716 wm ux4.z /opt/acc/bin/zdbi960: ACC Rel B.02.40-B.2.40.02 for B.10.20 PHNE_18716 zdb i960 /opt/acc/msg/def.zdbi960.txt: $Header: def.zdbi960.txt@@/main/r2.40/2 03/30/99 21 :08:43 $ /opt/acc/share/man/man3.Z/zevent_rcvr.3x: None /opt/acc/share/man/man3.Z/zset_rcvr.3x: None /opt/acc/msg/zerrmsg.txt: $Header: zerrmsg.txt@@/main/r2.40/1 05/28/99 12:51: 35 $Rev: /main/r2.40/1 $ /opt/acc/include/zcom/zcomcall.h: $Header: zcomcall.h@@/main/r2.40/1 05/26/98 21:15:5 5 $Rev: /main/r2.40/1 $ /opt/acc/bin/nacc1_trc: ACC Rel B.02.40-B.2.40.02 for B.10.20 PHNE_18716 nac c1_trc /opt/acc/bin/nacc_trc: ACC Rel B.02.40-B.2.40.02 for B.10.20 PHNE_18716 nac c_trc /opt/acc/bin/zmasterd: ACC Rel B.02.40-B.2.40.02 for B.10.20 PHNE_18716 zma sterd ACC Rel B.02.40-B.2.40.02 for B.10.20 PHNE_18716 lib Zmd_c.a /opt/acc/bin/nacc1_stats: ACC Rel B.02.40-B.2.40.02 for B.10.20 PHNE_18716 nac c1_stats /opt/acc/bin/zmlog: ACC Rel B.02.40-B.2.40.02 for B.10.20 PHNE_18716 zml og ACC Rel B.02.40-B.2.40.02 for B.10.20 PHNE_18716 lib Zmd_c.a /opt/acc/msg/def.zmlog.txt: $Header: def.zmlog.txt@@/main/r2.40/1 05/25/99 13:2 0:14 $Rev: /main/r2.40/1 $ /sbin/init.d/acc: None /etc/rc.config.d/acc: None /opt/acc/lbin/FixMajor.awk: None /opt/acc/z7350a/loopback.zabs: ZCOM System Firmware (ROM) Rev 01.T5 ACC Rel B.02.40-B.2.40.02 for B.10.20 PHNE_18716 z7 350_r ZCOM Z7350A System Software ACC Rel B.02.40-B.2.40.02 for B.10.20 PHNE_18716 z7 350_f CPU clock 32MHz ZCOM LEVEL1 Protocol ACC Rel B.02.40-B.2.40.02 for B.10.20 PHNE_18716 le vel1. ZCOM Monitor Module ACC Rel B.02.40-B.2.40.02 for B.10.20 PHNE_18716 mo nitor ZCOM Port Diagnostic Module ACC Rel B.02.40-B.2.40.02 for B.10.20 PHNE_18716 te stpro ZCOM Protocol Module Entry Point Table ACC Rel B.02.40-B.2.40.02 for B.10.20 PHNE_18716 pm entta /opt/acc/z7350a/loopback.zmap: ZCOM System Firmware (ROM) Rev 01.T5 ACC Rel B.02.40/B.02.40.01 for B.10.20 PHNE_16615 z 7350_ ZCOM Z7350A System Software ACC Rel B.02.40/B.02.40.01 for B.10.20 PHNE_16615 z 7350_ CPU clock 32MHz ZCOM LEVEL1 Protocol ACC Rel B.02.40/B.02.40.01 for B.10.20 PHNE_16615 l evel1 ZCOM Monitor Module ACC Rel B.02.40/B.02.40.01 for B.10.20 PHNE_16615 m onito ZCOM Port Diagnostic Module ACC Rel B.02.40/B.02.40.01 for B.10.20 PHNE_16615 t estpr ZCOM Protocol Module Entry Point Table ACC Rel B.02.40/B.02.40.01 for B.10.20 PHNE_16615 p mentt /opt/acc/protocol/level1.zrel: ZCOM LEVEL1 Protocol ACC Rel B.02.40/B.02.40.01 for B.10.20 PHNE_16615 l evel1 /opt/acc/msg/def.zcom.txt: None /opt/acc/lbin/FixMajor: None /opt/acc/bin/zmon: ACC Rel B.02.40-B.2.40.02 for B.10.20 PHNE_18716 zmo n ACC Rel B.02.40-B.2.40.02 for B.10.20 PHNE_18716 lib Zmd_c.a /opt/acc/bin/zmntr: ACC Rel B.02.40-B.2.40.02 for B.10.20 PHNE_18716 zmn tr /usr/conf/lib/libnacc_nio.a: ACC Rel B.02.40-B.2.40.02 for B.10.20 PHNE_18716 lib nacc.a ACC Rel B.02.40-B.2.40.02 for B.10.20 PHNE_18716 $He ader: Zc_dma_A.c@@/main/17 09/16/97 17:10:0 0 $ /usr/conf/lib/libnacc_pci.a: ACC Rel B.02.40-B.2.40.02 for B.10.20 PHNE_18716 lib nacc.a ACC Rel B.02.40-B.2.40.02 for B.10.20 PHNE_18716 $He ader: Zc_dma_A.c@@/main/17 09/16/97 17:10:0 0 $ ACC Rel B.02.40-B.2.40.02 for B.10.20 PHNE_18716 lib eacc.a /usr/conf/lib/libzcom.a: ACC Rel B.02.40-B.2.40.02 for B.10.20 PHNE_18716 lib zcom.a /opt/acc/z7400a/loopback.zabs: ZCOM System Firmware (ROM) Rev 01.B5 ACC Rel B.02.40-B.2.40.02 for B.10.20 PHNE_18716 z7 400_r ZCOM Z7400A System Software ACC Rel B.02.40-B.2.40.02 for B.10.20 PHNE_18716 z7 400_f ZCOM LEVEL1 Protocol ACC Rel B.02.40-B.2.40.02 for B.10.20 PHNE_18716 le vel1. ZCOM Monitor Module ACC Rel B.02.40-B.2.40.02 for B.10.20 PHNE_18716 mo nitor ZCOM Port Diagnostic Module ACC Rel B.02.40-B.2.40.02 for B.10.20 PHNE_18716 te stpro ZCOM Protocol Module Entry Point Table ACC Rel B.02.40-B.2.40.02 for B.10.20 PHNE_18716 pm entta /opt/acc/z7400a/loopback.zmap: ZCOM System Firmware (ROM) Rev 01.B5 ACC Rel B.02.40/B.02.40.01 for B.10.20 PHNE_16615 z 7400_ ZCOM Z7400A System Software ACC Rel B.02.40/B.02.40.01 for B.10.20 PHNE_16615 z 7400_ ZCOM LEVEL1 Protocol ACC Rel B.02.40/B.02.40.01 for B.10.20 PHNE_16615 l evel1 ZCOM Monitor Module ACC Rel B.02.40/B.02.40.01 for B.10.20 PHNE_16615 m onito ZCOM Port Diagnostic Module ACC Rel B.02.40/B.02.40.01 for B.10.20 PHNE_16615 t estpr ZCOM Protocol Module Entry Point Table ACC Rel B.02.40/B.02.40.01 for B.10.20 PHNE_16615 p mentt /opt/acc/sys/z7350_fw.zrel: ZCOM Z7350A System Software ACC Rel B.02.40-B.2.40.02 for B.10.20 PHNE_18716 z7 350_f /opt/acc/sys/z7400_fw.zrel: ZCOM Z7400A System Software ACC Rel B.02.40-B.2.40.02 for B.10.20 PHNE_18716 z7 400_f /opt/acc/z7300a/download.zabs: ACC Rel B.02.40-B.2.40.02 for B.10.20 PHNE_18716 ACC Base F/W ACC Rel B.02.40-B.2.40.02 for B.10.20 PHNE_18716 LAP -B Protocol F/W ACC Rel B.02.40-B.2.40.02 for B.10.20 PHNE_18716 LAP -D Protocol F/W ACC Rel B.02.40-B.2.40.02 for B.10.20 PHNE_18716 X.2 5 Protocol F/W /opt/acc/z7330a/download.zabs: ACC Rel B.02.40-B.2.40.02 for B.10.20 PHNE_18716 ACC Base F/W ACC Rel B.02.40-B.2.40.02 for B.10.20 PHNE_18716 LAP -B Protocol F/W ACC Rel B.02.40-B.2.40.02 for B.10.20 PHNE_18716 LAP -D Protocol F/W ACC Rel B.02.40-B.2.40.02 for B.10.20 PHNE_18716 X.2 5 Protocol F/W /opt/acc/bin/ttgen: ACC Rel B.02.40-B.2.40.02 for B.10.20 PHNE_18716 ttg en /opt/acc/bin/zscan: ACC Rel B.02.40/B.02.40.01 for B.10.20 PHNE_16615 zs can /opt/acc/msg/def.ttgen.txt: $Header: def.ttgen.txt@@/main/r2.40/2 08/30/98 18:2 6:27 $Rev: /main/r2.40/2 $ /opt/acc/msg/def.zscan.txt: $Header: def.zscan.txt@@/main/r2.40/1 03/04/98 17:0 7:26 $Rev: /main/r2.40/1 $ /opt/acc/msg/zterm.hlp: $Header: zterm.hlp@@/main/r2.40/1 02/22/98 17:21:10 $Rev: /main/r2.40/1 $ /opt/acc/include/zcom/zcomsys.h: $Header: zcomsys.h@@/main/r2.40/9 05/28/99 12:41:07 $ /usr/conf/acc/zcomsys.h: $Header: zcomsys.h@@/main/r2.40/9 05/28/99 12:41:07 $ /opt/acc/bin/zterm: ACC Rel B.02.40-B.2.40.02 for B.10.20 PHNE_18716 zte rm /opt/acc/sys/wmux3.zrel: ZCOM System Software (WMUX3) ACC Rel B.02.40/B.02.40.01 for B.10.20 PHNE_16615 w mux3. CPU clock 16MHz /opt/acc/sys/wmux1.zrel: ZCOM System Software (WMUX1) ACC Rel B.02.40/B.02.40.01 for B.10.20 PHNE_16615 w mux1. /opt/acc/z7200a/loopback.zabs: ZCOM System Firmware (ROM) Rev 04.B 921106.1200 ACC Rel B.02.40-B.2.40.02 for B.10.20 PHNE_18716 z7 200_s ZCOM System Software (WMUX1) ACC Rel B.02.40-B.2.40.02 for B.10.20 PHNE_18716 wm ux1.z ZCOM System Software (WMUX3) ACC Rel B.02.40-B.2.40.02 for B.10.20 PHNE_18716 wm ux3.z CPU clock 16MHz ZCOM System Software (WMUX4) ACC Rel B.02.40-B.2.40.02 for B.10.20 PHNE_18716 wm ux4.z ZCOM LEVEL1 Protocol ACC Rel B.02.40-B.2.40.02 for B.10.20 PHNE_18716 le vel1. ZCOM Monitor Module ACC Rel B.02.40-B.2.40.02 for B.10.20 PHNE_18716 mo nitor ZCOM Port Diagnostic Module ACC Rel B.02.40-B.2.40.02 for B.10.20 PHNE_18716 te stpro ZCOM Protocol Module Entry Point Table ACC Rel B.02.40-B.2.40.02 for B.10.20 PHNE_18716 pm entta ZCOM System Entry Point Table ACC Rel B.02.40-B.2.40.02 for B.10.20 PHNE_18716 um uxent /opt/acc/z7200a/loopback.zmap: ZCOM System Firmware (ROM) Rev 04.B 921106.1200 ACC Rel B.02.40/B.02.40.01 for B.10.20 PHNE_16615 z 7200_ ZCOM System Software (WMUX1) ACC Rel B.02.40/B.02.40.01 for B.10.20 PHNE_16615 w mux1. ZCOM System Software (WMUX3) ACC Rel B.02.40/B.02.40.01 for B.10.20 PHNE_16615 w mux3. CPU clock 16MHz ZCOM System Software (WMUX4) ACC Rel B.02.40/B.02.40.01 for B.10.20 PHNE_16615 w mux4. ZCOM LEVEL1 Protocol ACC Rel B.02.40/B.02.40.01 for B.10.20 PHNE_16615 l evel1 ZCOM Monitor Module ACC Rel B.02.40/B.02.40.01 for B.10.20 PHNE_16615 m onito ZCOM Port Diagnostic Module ACC Rel B.02.40/B.02.40.01 for B.10.20 PHNE_16615 t estpr ZCOM Protocol Module Entry Point Table ACC Rel B.02.40/B.02.40.01 for B.10.20 PHNE_16615 p mentt ZCOM System Entry Point Table ACC Rel B.02.40/B.02.40.01 for B.10.20 PHNE_16615 u muxen cksum(1) Output: 950671173 3976 /usr/conf/masterd.d/nacc 2276587332 2172 /opt/acc/share/man/man1.Z/zmasterd.1 4113486100 525 /usr/sam/lib/kc/paramsACC.tx 2303197461 295 /usr/sam/lib/kc/subsysACC.tx 1413496282 369 /usr/sam/lib/kc/driversACC.tx 2853717544 28731 /opt/acc/TEL/lib/libTELfmt.sl 2381368008 9336 /opt/acc/protocol/testprot.zrel 2708231343 180728 /usr/conf/lib/libnacc1_niosyms.o 2434598371 187876 /usr/conf/lib/libnacc1_pcisyms.o 1059951513 194160 /usr/conf/lib/libnacc_eisasyms.o 2906653088 179412 /usr/conf/lib/libnacc_niosyms.o 3248540808 204968 /usr/conf/lib/libzcomsyms.o 2805633415 1256 /opt/acc/msg/default.txt 2348793103 32906 /opt/acc/bin/pmon 3512162462 11138 /opt/acc/sys/wmux4.zrel 2390466435 123221 /opt/acc/bin/zdbi960 545910662 29945 /opt/acc/msg/def.zdbi960.txt 3634397512 3817 /opt/acc/share/man/man3.Z/zevent_rcvr.3x 4284640607 3448 /opt/acc/share/man/man3.Z/zset_rcvr.3x 4086019893 4973 /opt/acc/msg/zerrmsg.txt 3756164227 5910 /opt/acc/include/zcom/zcomcall.h 3500346884 36927 /opt/acc/bin/nacc1_trc 3531369535 32831 /opt/acc/bin/nacc_trc 1329615096 32959 /opt/acc/bin/zmasterd 3820956845 20540 /opt/acc/bin/nacc1_stats 3813339715 28814 /opt/acc/bin/zmlog 776025718 2507 /opt/acc/msg/def.zmlog.txt 589639145 1997 /sbin/init.d/acc 2974354459 1116 /etc/rc.config.d/acc 993209107 191 /opt/acc/lbin/FixMajor.awk 3227614873 17044 /opt/acc/z7350a/loopback.zabs 376299850 2635 /opt/acc/z7350a/loopback.zmap 1329747964 8822 /opt/acc/protocol/level1.zrel 1860434810 6333 /opt/acc/msg/def.zcom.txt 2836329911 3761 /opt/acc/lbin/FixMajor 3495974557 74300 /opt/acc/bin/zmon 4099417872 160281 /opt/acc/bin/zmntr 1740304526 142764 /usr/conf/lib/libnacc_nio.a 997247226 206568 /usr/conf/lib/libnacc_pci.a 317047185 225740 /usr/conf/lib/libzcom.a 3223766002 17952 /opt/acc/z7400a/loopback.zabs 203754437 2570 /opt/acc/z7400a/loopback.zmap 2511310876 39326 /opt/acc/sys/z7350_fw.zrel 2417573834 41844 /opt/acc/sys/z7400_fw.zrel 1437150695 57568 /opt/acc/bin/ttgen 2205947814 57488 /opt/acc/bin/zscan 1192209378 33530 /opt/acc/msg/def.ttgen.txt 1056236874 15394 /opt/acc/msg/def.zscan.txt 3196247555 26740 /opt/acc/msg/zterm.hlp 1375215920 104504 /opt/acc/include/zcom/zcomsys.h 1375215920 104504 /usr/conf/acc/zcomsys.h 1171762460 143760 /opt/acc/bin/zterm 2538203156 27430 /opt/acc/sys/wmux3.zrel 1093109792 3042 /opt/acc/sys/wmux1.zrel 3624327499 17880 /opt/acc/z7200a/loopback.zabs 1879443941 3558 /opt/acc/z7200a/loopback.zmap 2533706813 1936337 /opt/acc/z7300a/download.zabs 3044840516 2085082 /opt/acc/z7330a/download.zabs Patch Conflicts: None Patch Dependencies: None Hardware Dependencies: None Other Dependencies: None Supersedes: PHNE_13990 PHNE_15350 PHNE_16615 PHNE_17877 Equivalent Patches: None Patch Package Size: 6910 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_18716 5a. For a standalone system, run swinstall to install the patch: swinstall -x autoreboot=true -x match_target=true \ -s /tmp/PHNE_18716.depot By default swinstall will archive the original software in /var/adm/sw/patch/PHNE_18716. 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_18716.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_18716.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. After install, run the following commands to make new msg files: txt2msg def.zcom txt2msg def.zdbi960 txt2msg def.ttgen txt2msg default txt2msg def.zmlog txt2msg def.zscan Note that fixing the DTS TPO0h01209 problem required adding new checking to the ttgen program to verify the correctness of the port modes in your .answ file. So some port mode and card type combinations which you may have used up to now may not be valid anymore. The following table shows the allowable combinations: Name Value 8 port 2 port 4 port RS232 0 Good Good Bad V35 1 Bad Good Bad RS449 2 Bad Good Bad V36 3 Bad Good Bad RS422 4 Good Good Bad E1DB9 5 Bad Bad Good E1BNC 6 Bad Bad Good T1RJ45 7 Bad Bad Good LBACK 8 Good Good Good E1RJ45 9 Bad Bad Good T1DB9 10 Bad Bad Good T1BNC 11 Bad Bad Good X21 12 Good Good Bad Refer to the latest Utilities documentation for information on what is supported by the ttgen program.