Patch Name: PHNE_18712 Patch Description: s700_800 10.10 2.39.00-2.39.02 ACC Base Software Patch Creation Date: 99/09/02 Post Date: 00/06/08 Hardware Platforms - OS Releases: s700: 10.10 s800: 10.10 Products: Z7299A_APX 2.39; Z7301A_APX 2.39; Z7401A_APX 2.39; Filesets: ACC.ACC-KRN ACC.ACC-RUN ACC.ACC-PRG ACC.ACC-FW ACC.ACC-MAN ACC-X25ST.ACC-X25ST-RUN Automatic Reboot?: Yes Status: General Release Critical: Yes PHNE_18712: PANIC PHNE_15365: PANIC Path Name: /hp-ux_patches/s700_800/10.X/PHNE_18712 Symptoms: PHNE_18712: 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. 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. TPO0h01209: port mode validation is incorrect in ttgen 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(). SR None / 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. 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: 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> TPO0h02425: ACC panics the system.when using zmon restart followed by zx25init SR 4701408526 / DTS TPO0h02428 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. 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. 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. 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. TPO0h02246: With the PMON utility in use, the ZMNTR loopback test cannot be run on any E1/T1 port. TPO0h02331: When using zconfig() to dynamically configure ports on E1/T1 ACC cards, there is no check for invalid timeslot and subchannel configurations. TPO0h02423: TTGEN does not report an error when inappropriate framing or encoding options are used for an E1 or T1 port configuration. 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 TPO0h02477: Subchannel quota tables can be corrupted leading to an incorrectly reported "buffer shortage". TPO0h02676: The transmitted T1 signal waveform for the T1 RJ45 100ohm mode is not within the T1 specification. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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 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. 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. TPO0h02242: DMA timeout errors occur in running ISDN/X.25. TPO0h02245: The pmon utility does not clean up its dynamically created terminals on exiting. 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. TPO0h02273: An x.25 PVC cannot be enabled after being explicitly disabled. This problem only occurs on the 4 port cards (I960 based) 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. TPO0h02620: The nli2zcom (or axin) driver sometimes detects error -43 (timeout of level 2 disable request) in the nettl log, while attempting to shutdown an X.25 link. TPO0h02610: Add Q4 support for the 10.X release. TPO0h02783 TTGEN does not allow an E1/T1 port to be configured in "Loopback" mode unless the Frame mode is set to TRANS. PHNE_15365: TPO0h01894: Loopback test on Z7330A and Z7300A cards may sometimes fail. TPO0h02076: The ROM timestamp kept in Interface Table (IFT) will be shown (by zmntr MX command) as Year 19xx after Year 2000. 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_13989: SR None / 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). SR None / DTS TPO0h01914 Request issued to a ZLU hangs and is never processed. It is queued in the data structures but never sent to the card. SR None / DTS TPO0h01918 Selftest on the Z7330A and Z7300A 4 port ACC cards can very occsasionally not complete, leading to a timeout. SR None / DTS TPO0h01285 The ZCOM subsystem will fail to startup typically with an immediate error return, but sometimes with random symptoms. SR None / DTS TPO0h01643 The zmon message 00111 doesn't contain useful diagnostic information for the 4 port cards. SR None / DTS TPO0h01822 DMA timeout when application's primary ZLU reached it's queue limit. SR None / DTS TPO0h01661 DAM runs heartbeat timer on an "unusable" card SR None / DTS TPO0h01640 2 channel ACC card transmits a bad frame at the beginning of link setup. SR None / DTS TPO0h01833 8-channel NIO card crashes, with the use of the frame protocol and hdlcabm protocol together on the same port. SR None / DTS TPO0h01755 hdlcabm sends REJ on I-frame with duplicate N(s) Defect Description: PHNE_18712: 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. 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. TPO0h01209: ttgen did not take into account the entire set of ACC boards. We now check the following 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 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. 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. 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. 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. 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. 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). However it does not transmit RAI if the line is down because of a received RAI. RAI is only transmitted when received frame sync is lost. 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. TPO0h02331: When using zconfig() to dynamically configure ports on E1/T1 ACC cards, there is no check for invalid timeslot and subchannel configurations. 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. TPO0h02446: TTGEN now reports an error in this case. 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. TPO0h02676: The FALC waveform shaping parameters for the T1 RJ45 100ohm case are not right. New parameters are now implemented. 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. 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. 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. 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. 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. 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. 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. 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. TPO0h01522: Mishandling of the rrch flag was found in the firmware code. The handling of the flag has been corrected. 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. TPO0h02172: HDLC firmware was ignoring this condition. The HDLC firmware has been corrected. TPO0h02173: Bad state change on N2/N200 timer expiration. The finite state machine (FSM) has been corrected. TPO0h02175: Incorrect behaviour coded into the HDLCABM state machine. The state machine has been corrected. 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. 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. 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. TPO0h02273: Mishandling of the cclr flag was found in the firmware code. The handling of the flag has been corrected. 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 - the firmware memory has been reorganised to avoid the areas used by the Munich self-test. 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. TPO0h02610: There is a commitment to provide Q4 support for the ACC B.02.39 and B.02.40 releases. 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. PHNE_15365: 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". 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. PHNE_13989: SR None / DTS TPO0h01913 Card restart on partial dynamic term config gives protocol not loaded SR None / DTS TPO0h01914 Dynamic terminal create hangs on undefined subchannel, port or interface SR None / DTS TPO0h01918 Reset can timeout on COLD start of 4 port cards SR None / 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). SR None / DTS TPO0h01643 zmon message 00111 (Last backplane command) has bad info for 4 port card SR None / DTS TPO0h01822 Application's primary ZLU reached it's queue limit, about 15 seconds and 3 messages later the DAM detected a DMA SR None / DTS TPO0h01661 The DAM should not be running the heartbeat timer on a card which is reported as "unusable". SR None / DTS TPO0h01640 2ch card transmits bad frame on link startup SR None / DTS TPO0h01833 Firmware failures with FRAME and HDLCABM concurrently in use. SR None / DTS TPO0h01755 hdlcabm sends REJ on I-frame with duplicate N(s) SR: 4701323840 5003380527 5003415463 5003427252 5003427245 4701408526 1653296699 4701391862 5003417972 Patch Files: /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 /sbin/init.d/acc /etc/rc.config.d/acc /opt/acc/lbin/FixMajor.awk /opt/acc/z7200a/loopback.zmap /opt/acc/z7350a/loopback.zmap /opt/acc/protocol/level1.zrel /opt/acc/msg/def.zcom.txt /opt/acc/lbin/FixMajor /opt/acc/z7400a/loopback.zmap /opt/acc/bin/zscan /opt/acc/msg/def.zscan.txt /opt/acc/msg/zterm.hlp /opt/acc/bin/zmlog /opt/acc/msg/def.zmlog.txt /opt/acc/msg/default.txt /opt/acc/msg/def.ttgen.txt /opt/acc/bin/ttgen /opt/acc/bin/zmasterd /opt/acc/bin/nacc1_stats /opt/acc/bin/nacc1_trc /opt/acc/bin/nacc_trc /opt/acc/bin/zmon /usr/conf/lib/libzcom.a /opt/acc/include/zcom/zcomcall.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/include/zcom/zcomsys.h /usr/conf/acc/zcomsys.h /opt/acc/bin/zterm /usr/conf/lib/libnacc_nio.a /usr/conf/lib/libnacc_eisa.a /opt/acc/bin/zmntr /opt/acc/bin/zdbi960 /opt/acc/msg/def.zdbi960.txt /opt/acc/bin/pmon /opt/acc/z7200a/loopback.zabs /opt/acc/z7350a/loopback.zabs /opt/acc/z7400a/loopback.zabs /opt/acc/sys/wmux3.zrel /opt/acc/sys/wmux4.zrel /opt/acc/sys/wmux1.zrel /opt/acc/sys/z7350_fw.zrel /opt/acc/sys/z7400_fw.zrel /usr/conf/master.d/nacc /usr/conf/lib/libnacc1_niosyms.o /usr/conf/lib/libnacc_eisasyms.o /usr/conf/lib/libnacc_niosyms.o /usr/conf/lib/libzcomsyms.o /opt/acc/protocol/testprot.zrel /opt/acc/z7300a/download.zabs what(1) Output: /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 /sbin/init.d/acc: None /etc/rc.config.d/acc: None /opt/acc/lbin/FixMajor.awk: None /opt/acc/protocol/level1.zrel: ZCOM LEVEL1 Protocol ACC Rel B.02.39 for B.10.10 PHNE_13989 level1.z80 /opt/acc/z7200a/loopback.zmap: ZCOM System Firmware (ROM) Rev 04.B 921106.1200 ACC Rel B.02.39 for B.10.10 PHNE_13989 z7200_snp.z8 0 ZCOM System Software (WMUX1) ACC Rel B.02.39 for B.10.10 PHNE_13989 wmux1.z80 ZCOM System Software (WMUX3) ACC Rel B.02.39 for B.10.10 PHNE_13989 wmux3.z80 CPU clock 16MHz ZCOM System Software (WMUX4) ACC Rel B.02.39 for B.10.10 PHNE_13989 wmux4.z80 ZCOM LEVEL1 Protocol ACC Rel B.02.39 for B.10.10 PHNE_13989 level1.z80 ZCOM Monitor Module ACC Rel B.02.39 for B.10.10 PHNE_13989 monitor.z80 ZCOM Port Diagnostic Module ACC Rel B.02.39 for B.10.10 PHNE_13989 testprot.z80 ZCOM Protocol Module Entry Point Table ACC Rel B.02.39 for B.10.10 PHNE_13989 pmenttab.z80 ZCOM System Entry Point Table ACC Rel B.02.39 for B.10.10 PHNE_13989 umuxent.z80 /opt/acc/z7350a/loopback.zmap: ZCOM System Firmware (ROM) Rev 01.T5 ACC Rel B.02.39 for B.10.10 PHNE_13989 z7350_rom.z8 0 ZCOM Z7350A System Software ACC Rel B.02.39 for B.10.10 PHNE_13989 z7350_fw.z80 CPU clock 32MHz ZCOM LEVEL1 Protocol ACC Rel B.02.39 for B.10.10 PHNE_13989 level1.z80 ZCOM Monitor Module ACC Rel B.02.39 for B.10.10 PHNE_13989 monitor.z80 ZCOM Port Diagnostic Module ACC Rel B.02.39 for B.10.10 PHNE_13989 testprot_ius c.z80 ZCOM Protocol Module Entry Point Table ACC Rel B.02.39 for B.10.10 PHNE_13989 pmenttab.z80 /opt/acc/msg/def.zcom.txt: $Header: def.zcom.txt@@/main/r2.40/1 02/06/98 08:11 :58 $Rev: /main/r2.40/1 $ /opt/acc/lbin/FixMajor: None /opt/acc/z7400a/loopback.zmap: ZCOM System Firmware (ROM) Rev 01.B5 ACC Rel B.02.39 for B.10.10 PHNE_15365 z7400_rom.z8 0 ZCOM Z7400A System Software ACC Rel B.02.39 for B.10.10 PHNE_15365 z7400_fw.z80 ZCOM LEVEL1 Protocol ACC Rel B.02.39 for B.10.10 PHNE_15365 level1.z80 ZCOM Monitor Module ACC Rel B.02.39 for B.10.10 PHNE_15365 monitor.z80 ZCOM Port Diagnostic Module ACC Rel B.02.39 for B.10.10 PHNE_15365 testprot.z80 ZCOM Protocol Module Entry Point Table ACC Rel B.02.39 for B.10.10 PHNE_15365 pmenttab.z80 /opt/acc/sys/wmux3.zrel: ZCOM System Software (WMUX3) ACC Rel B.02.39 for B.10.10 PHNE_15365 wmux3.z80 CPU clock 16MHz /opt/acc/bin/zscan: ACC Rel B.02.39 for B.10.10 PHNE_15365 zscan /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/bin/zmlog: ACC Rel B.02.39-B.02.39.02 for B.10.10 PHNE_18712 zm log ACC Rel B.02.39-B.02.39.02 for B.10.10 PHNE_18712 li bZmd_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 $ /opt/acc/msg/default.txt: $Header: default.txt@@/main/4 11/20/96 15:33:26 $ /opt/acc/msg/def.ttgen.txt: $Header: def.ttgen.txt@@/main/r2.40/6 06/30/99 12:3 9:31 $Rev: /main/r2.40/6 $ /opt/acc/bin/ttgen: ACC Rel B.02.39-B.02.39.02 for B.10.10 PHNE_18712 tt gen /opt/acc/bin/zmasterd: ACC Rel B.02.39-B.02.39.02 for B.10.10 PHNE_18712 zm asterd ACC Rel B.02.39-B.02.39.02 for B.10.10 PHNE_18712 li bZmd_c.a /opt/acc/bin/nacc1_stats: ACC Rel B.02.39-B.02.39.02 for B.10.10 PHNE_18712 na cc1_stats /opt/acc/bin/nacc1_trc: ACC Rel B.02.39-B.02.39.02 for B.10.10 PHNE_18712 na cc1_trc /opt/acc/bin/nacc_trc: ACC Rel B.02.39-B.02.39.02 for B.10.10 PHNE_18712 na cc_trc /opt/acc/bin/zmon: ACC Rel B.02.39-B.02.39.02 for B.10.10 PHNE_18712 zm on ACC Rel B.02.39-B.02.39.02 for B.10.10 PHNE_18712 li bZmd_c.a /usr/conf/lib/libzcom.a: ACC Rel B.02.39-B.02.39.02 for B.10.10 PHNE_18712 li bzcom.a /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/include/zcom/zcomsys.h: $Header: zcomsys.h@@/main/r2.40/9 05/28/99 12:41:07 $ /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/share/man/man3.Z/zevent_rcvr.3x: None /opt/acc/share/man/man3.Z/zset_rcvr.3x: None /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.39-B.02.39.02 for B.10.10 PHNE_18712 zt erm /usr/conf/lib/libnacc_nio.a: ACC Rel B.02.39-B.02.39.02 for B.10.10 PHNE_18712 li bnacc.a ACC Rel B.02.39-B.02.39.02 for B.10.10 PHNE_18712 $H eader: Zc_dma_A.c@@/main/17 09/16/97 17:10: 00 $ /usr/conf/lib/libnacc_eisa.a: ACC Rel B.02.39-B.02.39.02 for B.10.10 PHNE_18712 li bnacc.a ACC Rel B.02.39-B.02.39.02 for B.10.10 PHNE_18712 $H eader: Zc_dma_A.c@@/main/17 09/16/97 17:10: 00 $ ACC Rel B.02.39-B.02.39.02 for B.10.10 PHNE_18712 li beacc.a /opt/acc/bin/zmntr: ACC Rel B.02.39-B.02.39.02 for B.10.10 PHNE_18712 zm ntr /opt/acc/bin/zdbi960: ACC Rel B.02.39-B.02.39.02 for B.10.10 PHNE_18712 zd bi960 /opt/acc/msg/def.zdbi960.txt: $Header: def.zdbi960.txt@@/main/r2.40/2 03/30/99 21 :08:43 $ /opt/acc/bin/pmon: ACC Rel B.02.39-B.02.39.02 for B.10.10 PHNE_18712 pm on /opt/acc/z7200a/loopback.zabs: ZCOM System Firmware (ROM) Rev 04.B 921106.1200 ACC Rel B.02.39-B.02.39.02 for B.10.10 PHNE_18712 z 7200_ ZCOM System Software (WMUX1) ACC Rel B.02.39-B.02.39.02 for B.10.10 PHNE_18712 w mux1. ZCOM System Software (WMUX3) ACC Rel B.02.39-B.02.39.02 for B.10.10 PHNE_18712 w mux3. CPU clock 16MHz ZCOM System Software (WMUX4) ACC Rel B.02.39-B.02.39.02 for B.10.10 PHNE_18712 w mux4. ZCOM LEVEL1 Protocol ACC Rel B.02.39-B.02.39.02 for B.10.10 PHNE_18712 l evel1 ZCOM Monitor Module ACC Rel B.02.39-B.02.39.02 for B.10.10 PHNE_18712 m onito ZCOM Port Diagnostic Module ACC Rel B.02.39-B.02.39.02 for B.10.10 PHNE_18712 t estpr ZCOM Protocol Module Entry Point Table ACC Rel B.02.39-B.02.39.02 for B.10.10 PHNE_18712 p mentt ZCOM System Entry Point Table ACC Rel B.02.39-B.02.39.02 for B.10.10 PHNE_18712 u muxen /opt/acc/z7350a/loopback.zabs: ZCOM System Firmware (ROM) Rev 01.T5 ACC Rel B.02.39-B.02.39.02 for B.10.10 PHNE_18712 z 7350_ ZCOM Z7350A System Software ACC Rel B.02.39-B.02.39.02 for B.10.10 PHNE_18712 z 7350_ CPU clock 32MHz ZCOM LEVEL1 Protocol ACC Rel B.02.39-B.02.39.02 for B.10.10 PHNE_18712 l evel1 ZCOM Monitor Module ACC Rel B.02.39-B.02.39.02 for B.10.10 PHNE_18712 m onito ZCOM Port Diagnostic Module ACC Rel B.02.39-B.02.39.02 for B.10.10 PHNE_18712 t estpr ZCOM Protocol Module Entry Point Table ACC Rel B.02.39-B.02.39.02 for B.10.10 PHNE_18712 p mentt /opt/acc/z7400a/loopback.zabs: ZCOM System Firmware (ROM) Rev 01.B5 ACC Rel B.02.39-B.02.39.02 for B.10.10 PHNE_18712 z 7400_ ZCOM Z7400A System Software ACC Rel B.02.39-B.02.39.02 for B.10.10 PHNE_18712 z 7400_ ZCOM LEVEL1 Protocol ACC Rel B.02.39-B.02.39.02 for B.10.10 PHNE_18712 l evel1 ZCOM Monitor Module ACC Rel B.02.39-B.02.39.02 for B.10.10 PHNE_18712 m onito ZCOM Port Diagnostic Module ACC Rel B.02.39-B.02.39.02 for B.10.10 PHNE_18712 t estpr ZCOM Protocol Module Entry Point Table ACC Rel B.02.39-B.02.39.02 for B.10.10 PHNE_18712 p mentt /opt/acc/sys/wmux4.zrel: ZCOM System Software (WMUX4) ACC Rel B.02.39-B.02.39.02 for B.10.10 PHNE_18712 w mux4. /opt/acc/sys/z7350_fw.zrel: ZCOM Z7350A System Software ACC Rel B.02.39-B.02.39.02 for B.10.10 PHNE_18712 z 7350_ CPU clock 32MHz /opt/acc/sys/z7400_fw.zrel: ZCOM Z7400A System Software ACC Rel B.02.39-B.02.39.02 for B.10.10 PHNE_18712 z 7400_ /usr/conf/master.d/nacc: None /usr/conf/lib/libnacc1_niosyms.o: ACC Rel B.02.39-B.02.39.02 for B.10.10 PHNE_18712 li bnacc1_niosyms.o /usr/conf/lib/libnacc_eisasyms.o: ACC Rel B.02.39-B.02.39.02 for B.10.10 PHNE_18712 li bnacc_eisasyms.o /usr/conf/lib/libnacc_niosyms.o: ACC Rel B.02.39-B.02.39.02 for B.10.10 PHNE_18712 li bnacc_niosyms.o /usr/conf/lib/libzcomsyms.o: ACC Rel B.02.39-B.02.39.02 for B.10.10 PHNE_18712 li bzcomsyms.o /opt/acc/sys/wmux1.zrel: ZCOM System Software (WMUX1) ACC Rel B.02.39-B.02.39.02 for B.10.10 PHNE_18712 w mux1. /opt/acc/protocol/testprot.zrel: ZCOM Port Diagnostic Module ACC Rel B.02.39-B.02.40.02 for B.10.10 PHNE_18712 t estpr Patch version: PHNE_18712 /opt/acc/z7300a/download.zabs: ACC Rel B.02.39-B.02.39.02 for B.10.10 PHNE_18712 AC C Base F/W ACC Rel B.02.39-B.02.39.02 for B.10.10 PHNE_18712 LA P-B Protocol F/W ACC Rel B.02.39-B.02.39.02 for B.10.10 PHNE_18712 LA P-D Protocol F/W ACC Rel B.02.39-B.02.39.02 for B.10.10 PHNE_18712 X. 25 Protocol F/W cksum(1) Output: 2557621601 4639 /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 589639145 1997 /sbin/init.d/acc 2974354459 1116 /etc/rc.config.d/acc 993209107 191 /opt/acc/lbin/FixMajor.awk 650971180 8816 /opt/acc/protocol/level1.zrel 2942366898 3395 /opt/acc/z7200a/loopback.zmap 2736863618 2435 /opt/acc/z7350a/loopback.zmap 1860434810 6333 /opt/acc/msg/def.zcom.txt 2110311983 3772 /opt/acc/lbin/FixMajor 1584939606 2360 /opt/acc/z7400a/loopback.zmap 129073451 27422 /opt/acc/sys/wmux3.zrel 4172363384 57467 /opt/acc/bin/zscan 1056236874 15394 /opt/acc/msg/def.zscan.txt 3196247555 26740 /opt/acc/msg/zterm.hlp 2251320541 24690 /opt/acc/bin/zmlog 776025718 2507 /opt/acc/msg/def.zmlog.txt 2805633415 1256 /opt/acc/msg/default.txt 1192209378 33530 /opt/acc/msg/def.ttgen.txt 1303030170 57522 /opt/acc/bin/ttgen 1690457322 28814 /opt/acc/bin/zmasterd 2650186474 16438 /opt/acc/bin/nacc1_stats 2517814155 28729 /opt/acc/bin/nacc1_trc 3548511338 28729 /opt/acc/bin/nacc_trc 1642714106 69986 /opt/acc/bin/zmon 3045931675 215056 /usr/conf/lib/libzcom.a 3756164227 5910 /opt/acc/include/zcom/zcomcall.h 1375215920 104504 /opt/acc/include/zcom/zcomsys.h 4086019893 4973 /opt/acc/msg/zerrmsg.txt 3634397512 3817 /opt/acc/share/man/man3.Z/zevent_rcvr.3x 4284640607 3448 /opt/acc/share/man/man3.Z/zset_rcvr.3x 1375215920 104504 /usr/conf/acc/zcomsys.h 4212815661 143711 /opt/acc/bin/zterm 919390323 139440 /usr/conf/lib/libnacc_nio.a 33008148 80652 /usr/conf/lib/libnacc_eisa.a 3276954019 164302 /opt/acc/bin/zmntr 1019016894 86291 /opt/acc/bin/zdbi960 545910662 29945 /opt/acc/msg/def.zdbi960.txt 2428572628 28786 /opt/acc/bin/pmon 3355551828 17880 /opt/acc/z7200a/loopback.zabs 629703816 17044 /opt/acc/z7350a/loopback.zabs 350194741 17952 /opt/acc/z7400a/loopback.zabs 1689281977 11138 /opt/acc/sys/wmux4.zrel 3917498253 39326 /opt/acc/sys/z7350_fw.zrel 2278585314 41844 /opt/acc/sys/z7400_fw.zrel 950671173 3976 /usr/conf/master.d/nacc 1713839533 167808 /usr/conf/lib/libnacc1_niosyms.o 1653981630 181432 /usr/conf/lib/libnacc_eisasyms.o 1561337298 166472 /usr/conf/lib/libnacc_niosyms.o 3202058960 194916 /usr/conf/lib/libzcomsyms.o 241819159 3042 /opt/acc/sys/wmux1.zrel 1351044040 9382 /opt/acc/protocol/testprot.zrel 1926928446 1936337 /opt/acc/z7300a/download.zabs Patch Conflicts: None Patch Dependencies: None Hardware Dependencies: None Other Dependencies: None Supersedes: PHNE_13989 PHNE_15365 Equivalent Patches: None Patch Package Size: 4410 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_18712 5a. For a standalone system, run swinstall to install the patch: swinstall -x autoreboot=true -x match_target=true \ -s /tmp/PHNE_18712.depot By default swinstall will archive the original software in /var/adm/sw/patch/PHNE_18712. 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_18712.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_18712.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.