Patch Name: PHNE_30554 Patch Description: s700_800 11.00 3.10.01 ACC X.25/9000 Link S/W Patch Creation Date: 04/03/24 Post Date: 04/05/11 Hardware Platforms - OS Releases: s700: 11.00 s800: 11.00 Products: Z7480AA B.03.02.00 B.03.10.00 B.03.10.01 Z7476AA B.03.02.00 B.03.10.00 B.03.10.01 Filesets: ACC-SX25.ACC-SX25-KRN,fr=B.03.02.00,fa=HP-UX_B.11.00_32,v=HP ACC-SX25.ACC-SX25-KRN,fr=B.03.10.00,fa=HP-UX_B.11.00_32,v=HP ACC-SX25.ACC-SX25-KRN,fr=B.03.10.01,fa=HP-UX_B.11.00_32,v=HP ACC-SX25.ACC-SX25-KRN,fr=B.03.02.00,fa=HP-UX_B.11.00_64,v=HP ACC-SX25.ACC-SX25-KRN,fr=B.03.10.00,fa=HP-UX_B.11.00_64,v=HP ACC-SX25.ACC-SX25-KRN,fr=B.03.10.01,fa=HP-UX_B.11.00_64,v=HP ACC-SX25.ACC-SX25-RUN,fr=B.03.02.00,fa=HP-UX_B.11.00_32/64,v=HP ACC-SX25.ACC-SX25-RUN,fr=B.03.10.00,fa=HP-UX_B.11.00_32/64,v=HP ACC-SX25.ACC-SX25-RUN,fr=B.03.10.01,fa=HP-UX_B.11.00_32/64,v=HP Automatic Reboot?: Yes Status: General Release Critical: Yes PHNE_30554: PANIC ABORT PHNE_28606: PANIC HANG PHNE_26297: OTHER Once the problem mentioned in JAGad97577 happens, stopping the X.25 link and ZCOM subsystem does not resolve the problem. The only way to recover is to reboot the system. PHNE_23722: PANIC PHNE_22253: MEMORY_LEAK HANG PHNE_20745: PANIC HANG Category Tags: defect_repair hardware_enablement enhancement general_release critical panic halts_system memory_leak Path Name: /hp-ux_patches/s700_800/11.X/PHNE_30554 Symptoms: PHNE_30554: SR 8606287932 / CR JAGae51865 System Panics with Data Page Fault with the following stack trace: stack trace for event 0 crash event was a panic panic+0x6c report_trap_or_int_and_panic+0x94 interrupt+0x208 $ihndlr_rtn+0x0 N2z_drain_outb_queue+0x868 N2z_ReadEvent_Recvd+0x28f0 Zc_putq+0x60 zkresponse+0x1c4 nacc1_process_firqs+0xe74 nacc2_complete_req+0xd84 nacc2_end_io+0x5b0 nacc2_isr+0x1244 sapic_interrupt+0x2c mp_ext_interrupt+0x3f0 ivti_patch_to_nop3+0x0 sul_pcxu_stop_here+0x0 N2Z_F0_rserv+0x144 sq_wrapper+0x94 str_sched_mp_daemon+0x174 str_sched_daemon+0x298 im_mpnetstr+0x28 DoCalllist+0x3c main+0x28 $vstart+0x48 istackatbase+0x88 stack trace for event 1 crash event was a TOC wait_for_lock_spinner+0x298 wait_for_lock+0xc0 sl_retry+0x1c N2Z_F0_wput+0x245c putnext+0xf0 XSO_F_putnext+0x48 streams_put+0x110 XSO_F0_a_retry_shutdown+0x1ac XSO_F_handler+0x3114 XSO_F_handler+0x3644 XPR_F_pr_usrreq+0x61c sodisconnect+0x90 soclose+0x1cc soo_close+0x90 closef+0x64 exit+0xa5c psig_core+0x374 syscall+0x820 $syscallrtn+0x0 SR 8606345144 / CR JAGaf05994: System Panics with Data Page Fault with following stack trace: stack trace for event 0 crash event was a panic panic+0x14 report_trap_or_int_and_panic+0x84 trap+0xd9c nokgdb+0x8 N2Z_F0_conn_conf+0x5a4 N2Z_F0_wput+0xebc putnext+0xcc XSO_F_putnext+0x44 streams_put+0xe8 XSO_F0_a_connect_resp+0x268 XSO_F_handler+0xdb0 XLS_F_handler+0x14a8 XSO_F_handler+0x408 XPR_F_pr_usrreq+0x540 soaccept+0x590 sodequeue+0x254 accept+0x22c syscall+0x28c $syscallrtn+0x0 PHNE_28606: SR 8606306906 / CR JAGae69940: System Panics with Data Page Fault on K-class system with 4-port NIO card with the following stack trace : stack trace for event 0 crash event was a panic panic+0x14 report_trap_or_int_and_panic+0x4c trap+0xeb0 $call_trap+0x38 N2Z_F0_rserv+0x7c0 sq_wrapper+0x90 str_sched_mp_daemon+0x130 str_sched_daemon+0x2dc main+0xaa0 $vstart+0x34 $locore+0x90 stack trace for event 1 crash event was a panic panic+0x14 wait_for_lock+0x270 slu_retry+0x18 N2Z_F0_close+0x458 close_wrapper+0x38 csq_protect+0x10c osr_pop_subr+0x1ec osr_close_subr+0xc0c hpstreams_close_int+0x30c streams_close+0x10 XSO_F0_close_dirty_list+0x78 XPR_F_pr_usrreq+0x1fc soclose+0x220 soo_close+0x7c closef+0x60 close+0x84 syscall+0x1e4 $syscallrtn+0x0 SR 8606236935 / CR JAGae05984: 'x25stat' doesn't report the Negotiated parameters correctly for flowcontrol and thruputclass SR 8606289434 / CR JAGae53365: ACC not recovering after sending an RNR(Receiver Not Ready). SR 8606266220 / CR JAGae30469: System panics with a Data Page Fault with the following stack trace : panic+0x14 report_trap_or_int_and_panic+0x84 interrupt+0x1d4 $ihndlr_rtn+0x0 streams_put+0x30 N2Z_F_reset_ind+0x94 N2z_iev_reset_ind+0x128 N2z_ReadEvent_Recvd+0x2278 SR 8606259525 / CR JAGae23843: System panics with a Data Page Fault with the following stack trace : panic+0x6c report_trap_or_int_and_panic+0x94 trap+0xed4 nokgdb+0x8 kfree+0xe4 N2z_shutdown_x25_subsys+0x6ac N2Z_F0_close+0x708 close_wrapper+0x38 SR 8606235666 / CR JAGae04809: In nli2zcom driver some spinlock issues were found which can result in spinlock timeout or deadlock panics. PHNE_26297: SR 8606231736 / CR JAGae00972: ACC X.25 IP/X25 will no longer work after the 2nd "x25init". SR 8606228520 / CR JAGad97577: When there is a lot of open and close of X.25 sockets and the ACC kernel limit "n2z_max_devs" is reached, X.25 socket creation with socket() call returns invalid errno 65535(-1). PHNE_23722: SR 8606227359 / CR JAGad96420: ioctls in n2z_cntrl fails with "Bad address" error SR 8606225328 / CR JAGad94415: ACC 3.xx sends the calling address in call accept packet SR 8606171598 / CR JAGad40862: Need to enhance "x25stat" command to show "VC Up Time" for all active virtual circuits. SR 8606144441 / CR JAGad13781: 'x25init' fails due to insufficient HP-UX memory. SR 8606146312 / CR JAGad15656: 'x25init' command fails with the following error message in nettl log when there are more number of VCs configured than the number of terminal ZLU entries in the ".answ" file. N2Z: The zconfig() call to create a new L3 ZLU has unexpectedly failed with error -15. Unable to startup the X.25 line (Mux = 0, Port 7, Subc 0)! SR 8606146870 / CR JAGad16213: Data page fault in streams_put with the following stack trace : panic+0x14 report_trap_or_int_and_panic+0x94 interrupt+0x1d0 $ihndlr_rtn+0x0 streams_put+0x2c N2Z_F_reset_ind+0x90 N2z_iev_reset_ind+0x138 N2z_ReadEvent_Recvd+0x1d94 SR 8606152276 / CR JAGad21615: System panics due to spinlock deadlock with the following stack trace : panic+0x14 too_much_time+0x2e8 wait_for_lock+0x204 sl_retry+0x1c N2Z_F0_open+0x9b8 open_wrapper+0x40 csq_protect+0x120 SR 8606197878 / CR JAGad67069: When an "x25stat" is done, the Max Framesize that is displayed is shown in bits instead of bytes. SR 8606197879 / CR JAGad67070: System panics with the Spinlock timeout failure when system runs out of system buffers. SR 8606151859 / CR JAGad21198: System panics with a Data Page Fault with the following stack trace : panic+0x14 report_trap_or_int_and_panic+0x5c interrupt+0x1f8 $ihndlr_rtn+0x0 N2Z_F_disc_ind+0xf4 N2z_iev_disconnect_ind+0xc60 N2z_ReadEvent_Recvd+0x588 Zc_putq+0x60 PHNE_22253: CR JAGad13782 memory leak in nli2zcom driver. PHNE_20745: CR JAGad03672 Potential data loss when sending large messages spanning multiple send request with the M-bit set and the VC goes into outbound flow control. CR JAGad03662 Inbound data would not be available to an application using the SET_FRAGMENT_SIZE ioctl until a large amount of data (2K-28K bytes) or the entire message had arrived CR JAGad03531 "x25stat -c" does not display the correct values for the facility settings or throughput class. CR JAGad03534 When an X.25 link is configured with flow control and/or throughput class facilities and the user or other upper layer protocol stack (e.g. SNA QLLC, OTS, etc) also supplies one or more of these facilities, the facilities string will contain duplicate facility codes. CR JAGad02275 System panic in N2Z_F0_rserv() during extreme traffic loads with a grossly undersize ZCOM buffer pool and running x25stop. The stack trace is: panic+0x14 report_trap_or_int_and_panic+0x80 trap+0xdb8 nokgdb+0x8 N2Z_F0_rserv+0x624 sq_wrapper+0x9c ioctl_sleep+0x304 wait_iocack+0x7c str_istr_ioctl+0x73c hpstreams_ioctl_int+0x2a4 hpstreams_ioctl+0x50 spec_ioctl+0xac vno_ioctl+0x90 ioctl+0x84 syscall+0x200 $syscallrtn+0x0 CR JAGad01873 System panics when hitting Ctrl-C (^C) during "x25init" CR JAGad00253 System hang when running CHO tests. CR JAGac42655 System panic in Zc_balloc() or Zc_bfree() or a panic with the string "Caller attempted to free buffer twice!" and the following stack trace : panic+0x14 n2z_free_zcom_buffer+0x7a8 freeb+0x81c freemsg+0x1c XIQ_F_handler+0x45c XST_F_read_put+0x294 csq_turnover_with_lock+0x88 streams_put+0x224 XSO_F0_a_retry_shutdown+0x190 XSO_F_handler+0x2fe0 XSO_F_handler+0x350c XPR_F_pr_usrreq+0x5f4 sodisconnect+0x4c soclose+0x390 soo_close+0x90 closef+0x68 exit+0x324 psig+0x258 syscall+0x97c $syscallrtn+0x0 CR JAGab66344 When running lanscan, no I/O hardware path is displayed for initialized X.25 links. CR JAGac39375 When running "x25stat" with the "-v" option, the incorrect or missing local and remote addresses are displayed. CR JAGac39379 When running "x25stat" with the "-c" option, the high LCN value is always one greater than it should be. CR JAGac39382 When running "x25stat" with the "-c" option, the line speed (baud rate) is not displayed correctly. CR JAGac42322 When "x25init" is run in parallel with a zmasterd stop/kill, subsequent "x25inits" can fail. The failure is always logged as a zconfig() failed with ZCOM error -85 (invalid sender's ZLU) in the nettl log file. At this point, the only way to clear this problem is to reboot the system. CR JAGab66351 The ACC X.25/9000 link software product SD control scripts and other invoked 'ksh' scripts violated the SD control script guidelines for output messages. CR JAGab66277 When the user's path variable was not defined or at least not set with the paths expected by the ACC scripts, various ACC script failures would occur. CR JAGab72105 Using n2z_cfg, you could not set the port back into loopback mode on a 64-bit system. CR JAGab68606 Message logged by the 'zx25d' driver when an inbound diagnostic packet arrives displays random values for the mux, port, and subchannel number. CR JAGab73855 System panic in asm_spinlock/XSY_F_plp_callback on 'x25init'. CR JAGab84691 Enhancement Request: Add support for the new 8-port PCI card. CR JAGab84870 System panic in N2Z_F_disc_conf(). CR JAGac29102 PANIC: Data page fault in N2Z_F_data_ind() when under extreme loads CR JAGab29104 This is an enhancement to improve driver trace performance and a minor improvement in accuracy of display when there is lots of trace output. Affects zx25d, naccX, and n2z driver trace and display programs. CR JAGab66272 when 'x25init' is hit with signals, it fails with a error message indicating that N2Z_IOCTL failed. Subsequent usage of x25init results in the same error message getting displayed and x25init does not complete. CR JAGab66270 when a zmasterd stop is done while >200 VCs are established and data transfer is being done (as in QA tests_x25_cmd/test27) a panic occurs. CR JAGab66342 When running the installation verification loopback tests for the X.25/ACC product, the second invocation of "x25init" failed. CR JAGab83699 Every time "x25init" was run for an ACC card, the following two messages were logged in syslog.log: "vmunix: stream thresholds received: context = 3fa5480" "vmunix: stream denied received: context = 3fa5480" PHNE_20101: CR JAGab82635 After running a series of stress tests that use lot of sockets the system fails with "Can't open any more Nli2zcom streams" message. A test program showed errors such as: "accept() #189 failed, errno = 65535: Unknown error" CR JAGab81509 system panics with "kernel stack overflow" panic+0x14 report_trap_or_int_and_panic+0x80 trap+0x958 nokgdb+0x8 XLS_F0_call_match_1+0x0 XLS_F_handler+0x6e8 XST_F_read_put+0x3f8 putnext+0x198 N2Z_F0_n_di_listen+0x25c N2Z_F0_wput+0x2c48 putnext+0x198 XLS_F0_a_disconnect_req+0xcc XLS_F_handler+0xed0 XLS_F_handler+0x1540 XST_F_read_put+0x3f8 putnext+0x198 N2Z_F0_n_di_listen+0x25c N2Z_F0_wput+0x2c48 putnext+0x198 N2Z_F0_n_di_listen+0x25c CR JAGab66316 System panics when x25init is done with a large configuration of Vcs > 8K. panic+0x14 report_trap_or_int_and_panic+0x80 interrupt+0x1d4 $ihndlr_rtn+0x0 asm_spinlock+0x14 XSY_F_plp_callback_func+0x54 N2Z_F_link_up+0x2c N2z_ReadEvent_Recvd+0x133c Zc_putq+0x64 Zc_addq+0x1cc Zc_dataput_p+0x34 zksend+0x2a4 Zx_Send_appl_status+0x1d0 Zx_proc_unsol_event+0xd28 zx25_event_handler+0x3f0 Zc_putq+0x64 nacc1_receive_data+0x178 nacc1_pass_rxdata+0x8c nacc1_cmplt_read+0x4b4 nacc1_complete_req+0x25d8 nacc1_end_io+0x380 nacc1_int_event+0x47c nacc1_isr+0x14 wsio_interrupt+0x58 mp_ext_interrupt+0x14c ivti_patch_to_nop3+0x0 idle+0x1dc swidle_exit+0x0 CR JAGab72034 system panic when zmasterd stop is done during x25init q4> trace event 0 stack trace for event 0 crash event was a panic panic+0x14 report_trap_or_int_and_panic+0x80 trap+0xdb8 nokgdb+0x8 N2z_Enable_ZLUs+0x134 N2z_start_link+0x5a8 N2Z_F0_start_link_ioctl+0x28c N2Z_F0_wput+0x2408 putnext+0x198 wait_iocack+0x68 str_istr_ioctl+0x73c hpstreams_ioctl_int+0x2a4 hpstreams_ioctl+0x50 spec_ioctl+0xac vno_ioctl+0x90 ioctl+0x84 syscall+0x200 $syscallrtn+0x0 Another panic stack seen: q4> trace event 0 stack trace for event 0 crash event was a panic panic+0x14 report_trap_or_int_and_panic+0x80 trap+0xde8 nokgdb+0x8 N2z_shutdown_x25_subsys+0x584 N2Z_F0_close+0x4a0 close_wrapper+0x38 csq_protect+0x120 osr_pop_subr+0x220 osr_close_subr+0x324 hpstreams_close_int+0x314 hpstreams_close+0x2c call_open_close+0x1f8 closed+0xb0 spec_close+0x54 vn_close+0x48 vno_close+0x20 closef+0x64 close+0x88 syscall+0x200 $syscallrtn+0x0 CR JAGab82415 / SR 8606109715 Memory leak of 2K stream buffers in call accept path. JAGab72105 On a 64bit system, the 'n2z_pcfg' command can not set the port to a LOOPBACK state. CR JAGab72028 'nz2_pcfg' causes backplane DMA timeout and card crash. Seen when the following was performed: -Start acc with ports in LBACK -run 'x25init' on each port -change port mode to rs232 using 'n2z_pcfg' -the command appears to hang, and there is a backplane timeout, after which the card is unusable and the ports will not come up, until ACC is stopped and restated. (zmon restart does not bring card back - you have to use zmasterd kill) Log message includes: Backplane command (DMA) has timed out ! CR JAGab66270 system panic when zmasterd stop is done during connection and data transfer involving 200 VCs. q4> trace event 0 stack trace for event 0 crash event was a panic panic+0x14 report_trap_or_int_and_panic+0x4c trap+0x7a4 $RDB_trap_patch+0x38 N2Z_F0_wput+0x814 putnext+0x50 XST_F_write_service+0xe8 sq_wrapper+0x90 str_sched_mp_daemon+0x150 str_sched_daemon+0x3a0 main+0x540 $vstart+0x34 $locore+0x90 CR JAGab66342 The 'x25init' program functionality was changed to require that each X.25 IP address be assigned to a separate subnet. The default x25init configuration files for the loopback tests did not an IP address on a separate subnet. This caused the second x25init to fail. The scripts which build the 'x25init' configuration files have been change to comment out the IP parameters since they are not used in the loopback verification tests. CR JAGab83699 Two debugging printf's were accidentally left in the shipped driver. These statements have been removed. PHNE_19049: CR JAGab66250 ACC passes Invalid QOS parameters when an outgoing connection is sent / rejected. When a large message is sent with 'Mbit',the circuit will hang after receiving 'N2z_max_ninb_pkts' packets. When SNA with QLLC option is used on ACC , the inbound data was queued using "putq" that causes performance problems. CR JAGab66253 Fix the Transient Reject problem seen by OTS, the symptom could be that when OTS is configured with Transient Reject the Inbound calls are not accepted. DTS TPO0h02841 / SR 4701431023 ACC 3.02, Using padem the "ls -R", will cause ACC to hang TPO0h02756 A variety of strange HDLC protocol problems including N2 retransmit limit exceeded error , T3/T4 timeouts. TPO0h02728 The 'n2z_pcfg' utility fails with an error and does not configured the ACC MUX port. TPO0h02696 Under heavy load, the system would panic with a data page fault in 'N2z_restart_qdwrts()'. DTS TPO0h02602 It takes too long (30-60 sec) for an Application to receive OOB_VC_CLEAR on an Inbound Disconnect Indication. DTS TPO0h02561 System panic in N2z_close(). DTS TPO0h01987 Enhancement request to implement the 'isdn_pcfg' utility program to reconfigure the ISDN port. DTS TPO0h01629 Traces won't work if the core dump is not in the default directory. (/var/adm/crash) DTS TPO0h02703 While testing the OTS/9000 product with X25/ACC, the routine QVF_F_qos_to_x25fac () returns an error code (-1), when there is no error, when processing a disconnect indication. Defect Description: PHNE_30554: SR: 8606287932 / CR: JAGae51865 This problem happens due to synchronization issue. During data transmission, if the application issues a disconnect, this request can be taken by another thread and clean the queues. As a result, when the last transmission of data is done, it tries to delink the message from the queue which is already made NULL by other thread causing the system to panic. Resolution: The panic is avoided by checking queue heads before delinking the message. SR: 8606345144 / CR: JAGaf05994 This problem happens when the upper layers do an accept when there is no incoming call. The driver tries to send a connect confirmation, but the connect structures are not filled completely (which is filled when there is an incoming call) causing the system to panic. Resolution: The driver before continuing with the call accept checks if Nz_INB_CALL flag is set. If not then the call is disconnected. PHNE_28606: SR 8606306906 / CR JAGae69940: This problem happens when "x25stop" is issued after a "zmasterd kill". This results in a race condition in which even after the zcom cleanup routines are called, streams layer calls the 'N2Z callback' service routine to queue the data to upper layers. But since the cleanup routines have freed most of the relevant data structures like 'lhvcp', 'N2Z' service routine causes a panic while accessing these data structures. Resolution: The fix is to prevent 'N2Z' service routine to return immediately if a 'zcom' shutdown is in progress or complete. N2Z_F0_rserv() routine is modified to check if 'N2Z_ZCOM_SHUTDOWN_COMPLETE' flag is set in 'n2z_cb.state' and return immediately if set. SR 8606236935 / CR JAGae05984: This problem is related to misinterpretation of the flag used for getting these negotiated parameters. The flag, which was assumed by ACC to display the thruput parameters, was actually used by the x25 stack to display the flowcontrol parameters. Hence for an "x25stat" command that issued while flowcontrol is set, ACC takes this as thruputflag and responds with values related to thruputflag. Resolution: Correct flag has been set so that "x25stat" displays the flowcontrol information correctly when turned on. SR: 8606289434 / CR: JAGae53365 After sending an 'RNR', ACC/X.25 driver did not send an RR to clear the flowcontrol i.e. 'NLI2ZCOM' driver was not coming out of flowcontrol mode. This caused the communication to be in a pending (hung) state until another event clears the flowcontrol condition such as a Reset packet after the timeout. Resolution: To resolve this defect, code change has been done to check the flowcontrol parameters of the 'NLI2ZCOM' driver. Once the driver is out of the flowcontrol it sends 'RR'. SR: 8606266220 / CR: JAGae30469 This problem arises due a to race condition between the detaching and resetting of a PVC. This panic is happening because the Reset and Detach processing of the same PVC are going on simultaneously. While detaching the PVC, the 'readq' pointer is set to NULL and when 'Reset' is trying to access that pointer it results in a Data Page Fault panic in "N2Z_F_reset_ind" function. Resolution: The fix is to prevent Detach and Reset of a PVC to go simultaneously. This is achieved by setting a flag 'Nz_X25_RESET_ACTIVE' (lhvcp flag) in "N2z_iev_reset_ind( )" to indicate that a 'Reset' is active and do not start Detaching this PVC, wait till 'Reset' is over for this PVC. SR: 8606259525 / CR: JAGae23843 This panic was a result of a Race condition between 'zmasterd' shutdown and the 'x25subsystem' shutdown. In one thread "N2z_zcom_shutdown_cleanup()" function was running in which 'l2pda->vctbl' is made NULL and in another thread "N2z_shutdown_x25_subsys()" was going on. When "N2z_shutdown_x25_subsys()" tries to access 'l2pda->vctbl' which has been made NULL by "N2z_zcom_shutdown_cleanup()", the system panics. Resolution: Fix was to add a check for 'l2pda->vctbl' is NULL or not in "N2z_shutdown_x25_subsys()". Also care has been taken to prevent a race condition. SR: 8606235666 / CR: JAGae04809 In "N2z_Cfg_Zlus()" routine, it was observed that in one code path, there were chances of a thread going to sleep while holding the spinlock and in another code path, where the spinlock is supposed to be held, it was not holding the lock. Both these cases can lead to spinlock timeout/deadlock panics or race conditions. Resolution: Code changes have been done to take care of these issues. PHNE_26297: SR: 8606231736 / CR: JAGae00972 If multiple X.25 links are used concurrently on a system, then following symptoms happen: 'IP over x25' works with 'x25init -c config_file -a ip_to_x121_map' command, if it was issued before 'sx25d' process startup. But if we restart the x.25 link with the same command while 'sx25d' is still running, then 'IP over X25' do not work while all the SVC and PVC operations for the link work normally. If we stop all the x.25 links via "x25stop -K" or "x25stop -d" individually, which causes 'sx25d' process stop, and then with the above "x25init" command, IP over X.25 works. In "N2z_stop_link" processing, we scan through all the VC structures and cleanup that are not in idle state. In this process, we check to see if there is any stream associated with the VC. If so, stype of stream context was set as 'N2Z_ERROR_STRM' for the duration till the x25 upper layers releases the previous connection established by 'ping'. So, when "x25init" is done for the second time within this duration, "x25init" path identifies that VC stream context type as ERROR stream and 'ping' doesn't go through. Resolution: Fix is to change the N2Z_ERROR_STRM to N2Z_UNKNOWN_STRM, so that the ping will go through. SR: 8606228520 / CR: JAGad97577 This problem has been noticed with PVCs and while detaching the PVC in "N2Z_F_pvc_detach_up()" routine, the VC Stream q_ptr field was made NULL. However in VC Stream close routine "N2Z_F0_close()", if q_ptr is NULL, then the further closing and clean-up of the VC stream was not complete, and hence VC Streams were not returned to free pool. So this caused the driver to run out of available VC Streams and the socket() call returns errno. 65535 after the kernel 'n2z_max_devs' is reached. Resolution: A new 'lhvcp' flag mask has been introduced and this flag is set during PVC detach processing to indicate that VC Stream close is still pending and thereby avoiding a need to set the VC Stream 'q_ptr' to NULL. Code change has been made to check for this flag and reset the flag during 'lhvcp' allocation. PHNE_23722: SR: 8606227359 / CR: JAGad96420 When trying to set the tunable values using 'n2z_cntrl', it fails with "Bad address" error. For eg., "n2z_cntrl -d0" will display "n2z_cntrl: Bad address". This is because, the parameters used in ioctl function were not correct. The second parameter of the ioctl should be 'I_STR' and the third parameter should be the 'strioctl' structure. Resolution : This has been fixed as follows: Instead of calling ioctl like, "ioctl(ssmfd, N2Z_CTS_CD_FLAG, &flag)" ioctl will now be called by filling the strioctl structure and then call, "ioctl(ssmfd, I_STR,&strioctl)" SR: 8606225328 / CR: JAGad94415 ACC 3.xx has a non NULL calling address in the call accept packet, which is refused by TRANSPAC. Resolution : This problem has been fixed by providing a tunable parameter, which can be set using "/opt/acc/bin/n2z_cntrl". By default this flag is set to '0'. So, calling address in call accept packet is '0' by default. If set to '1', the call accept packet contains the calling address. SR: 8606171598 / CR: JAGad40862 'x25stat' in ACC 3.xx does not display "VC Up Time" for all the active virtual circuits. Resolution : Provided "-u" option in "x25stat" command so that the user can request the "VC Up Time" for all active virtual circuits. A new ioctl has been added for this purpose. This option, however, has to be used in conjunction with the "-v" option of x25stat command. SR: 8606144441 / CR: JAGad13781 When "MALLOC with wait" is called with lock held, it returns NULL even though there is enough memory. In this case, the 'zx25drv' held the lock and called "MALLOC with wait". This returns NULL, causing 'x25init' to fail. Resolution: The fix is to unlock the spinlock before calling the MALLOC macro. SR: 8606146312 / CR: JAGad15656 'x25init' command fails because there are not enough number of terminal ZLU entries configured in the ".answ" file. Resolution: The fix is to instruct the user of this possible cause and to tune these parameters in .answ file and then start-up the ZCOM subsystem. SR: 8606146870 / CR: JAGad16213 After a PVC detach occurred (which causes the stream to be closed), an inbound request queued on the read side is passed upwards on a now invalid stream. This resulted in the panic. Resolution: The fix is to clear the read side "q_ptr" field during the PVC detach processing which prevents any request pending on the read side from being passed upwards. SR: 8606152276 / CR: JAGad21615 When the system was running out of memory, it would cause the 'nli2zcom' to drop a data packet and issue a 'reset' request on the VC. This particular condition caused many resets and reset confirmations to be issued during heavy data transfer loads. The 'NLI2ZCOM' driver showed that a reset request (or response) was being sent to the 'DAM' driver at the same time that an inbound event was arriving from the 'DAM' on the same card. The 'DAM' held the 'IFT' lock and passed the event to the 'NLI2ZCOM' driver which found the 'N2Z' lock already held. The 'NLI2ZCOM' driver locked its spinlock and passed a request to the 'DAM' which found the 'IFT' lock already held. Thus a classic spinlock deadlock has occurred. Resolution: The fix is to have the 'NLI2ZCOM' driver drop its lock when issuing a request to the 'DAM' and then re-acquire its lock upon return from the 'DAM'. This was done for both the outbound 'Reset' Request and 'Reset' Response functions. SR: 8606197878 / CR: JAGad67069 When an 'x25stat' is done, the Max. Framesize that is displayed is shown in bits instead of bytes. Resolution: The code has been changed such that the max frame size is displayed in bytes instead of bits. SR: 8606197879 / CR: JAGad67070 The Spinlock timeout failure seems to be happening because the function "N2z_Disable_ZLUs()" calls "zcntl()" holding the "SPINLOCK(glock)". Because there are no buffers available, the "Zc_gosleep()" is eventually called which in turn calls "sleep()". This is causing the spinlock timeout failure to occur because the spinlock should not be held when the "sleep()" is called. Resolution: Released the spinlock before calling the zcntl() in function "N2z_Disable_ZLUs()". SR: 8606151859 / CR: JAGad21198 The data page fault panic is because a NULL pointer was dereferenced. Resolution: To fix this problem a check has been added to verify if the pointer is NULL. PHNE_22253: CR JAGad13782 Multiple connections over ACC/X25 are made. After 5 days of intensive stress on the machine it needs to be rebooted because of a memory leak in the 512 bucket. The problem can be reproduced on all possible systems running hpux 11.00. The result found with vmtrace activated on the dumps is shown below: 0 0x9c80000 512 0 Wed Jun 7 07:45:22 2000 vmtrace_kmalloc+0x1c8 kmalloc+0x5ec allocb+0x32c N2z_iev_pass_data_up+0x210 N2z_ReadEvent_Recvd+0x1ea8 0 0x4b00000 512 0 Tue Jun 6 14:30:29 2000 vmtrace_kmalloc+0x1c8 kmalloc+0x5ec allocb+0x32c N2z_iev_pass_data_up+0x210 N2z_ReadEvent_Recvd+0x1ea8 Resolution: Memory is now freed where ever applicable. PHNE_20745: CR JAGad03672 When "drain_outb_queue()" sends data to the 'DAM', it must unlock the global spinlock in order to avoid a potential spinlock deadlock between the lower layer's and the 'nli2zcom' driver's spinlocks. Right after the spinlock is unlocked, a write completion or user level data requests can cause the write service procedure to run resulting in additional data being queued on the outbound data queues and "drain_outb_queue()" being called reentrantly. Code is already in place to detect the reentrant call and to exit. However, the first instance thinks that it has transmitted the entire message and calls freemsg. This behavior is incorrect because the 2nd instance appended data to the first instance's request and thus when the first instance calls "freemsg()" it causes the data from the 2nd instance to be thrown away and never transmitted. Code has been added to detect the reentrant call and to avoid calling "freemsg()" in this special corner case. CR JAGad03662 The format of the control write request used to tell the card the threshold for forwarding inbound data to the system was modified in the firmware but the drivers were never updated. The 'nli2zcom' driver has been changed to issue this request using the new format. CR JAGad03531 The driver was not returning these values to 'x25stat'. The code has been corrected. CR JAGad03534 This problem was introduced in a prior patch due to a logic error. The code has been corrected to only add the default facilities configured through 'x25init' if the called did not supply them. CR JAGad02275 This panic occurs when the 'nli2zcom' driver's read server is entered on a stream whose VC has been closed and the VC's data structure deallocated (by x25stop). The read server retrieves the pointer to the VC structure from the 'RD(Q)->q_ptr' field and dereferences it thereby causing the panic. The "x25stop" processing code now sets the 'q_ptr' field to NULL before deallocating the VC'structure. CR JAGad01873 The panic occurred when "N2z_stop_link" tried to free the ZCOM buffer that holds clear data for a VC. The pointer to this buffer is maintained in the VC's 'clear_pkt' field. Currently, neither the 'clear_pkt' or 'call_pkt' fields are used and should always be zero. It appears that some stale data somehow got into the field (which of course was not a real ZCOM buffer). The system panic'd when an attempt was make to free this buffer. This fix is to comment out all calls to 'Zc_Mfree' for these two fields. CR JAGad00253 When running internal tests, it was discovered that there were several small memory leaks that existed when handling a variety of exception conditions. Under some situations, the number of exception conditions occurring can grow exponentially causing the system to run out of memory and hang. These memory leaks have been corrected. CR JAGac42655 This problem occurred when an application that was generating extreme traffic loads on 2000+ VCs is killed (kill -9). The root cause is a violation of the streams synchronization rules by the 'nli2zcom' driver. The driver was issuing a 'flushq' call on the read queue from the write side (wput). This caused Streams/UX to both free a message and at the same time pass the message upwards to the X.25/9000 layers. When the upper layers was finished processing, it freed the message a second time resulting in this panic. The 'nli2zcom' driver code has been modified to use an alternative method for flushing its read side queue which avoids calling 'flushq'. This method follows the synchronization rules and therefore avoids this race condition. CR JAGab66344 The 'lanscan' program uses the results of the X.25/9000 ioctl(X25_RD_HDW_PATH) which was recently added. The ACC 'nli2zcom' driver did not implement this functionality and just returned a null string. We now return the full I/O path to the card associated with the SNID in the ioctl request. CR JAGac39375 The 'nli2zcom' drivers was supplying the correct addresses, however the code was retrieve the address lengths from the wrong fields in the VC structure. The code has been modified to use the proper fields for the address lengths. CR JAGac39379 The driver returns these values through an ioctl request. The driver needs to calculate the upper LCN value based on the number of VCs and the starting LCN value. This calculation was performed incorrectly resulting in an upper LCN value that is always one greater than it should be. The calculation has been corrected. CR JAGac39382 There was a logic error in the code which retrieved and calculated the baud rate value. The logic error has been corrected and the baud rate is now displayed with its proper value. CR JAGac42322 What is happening is that the zmasterd stop is notifying the driver that the ZCOM subsystem is being shutdown. The driver cleans up all the links and detaches from 'ZCOM'. However, before ZCOM actually begins its shutdown process another 'x25init' enters the driver and causes it to reattach to ZCOM. The ZCOM subsystem is then shutdown but the 'nli2zcom' driver stills thinks its attached. The next time an 'x25init' is run, it fails because the driver is using an invalid program ZLU (check sums don't match). Code has been added to the driver to detect this race condition and to avoid it. CR JAGab66351 The ksh and control scripts have been corrected to follow the SD guidelines. CR JAGab66277 All ACC scripts have been reviewed and a "PATH" statement added containing the standard HP-UX directories for various system utilities. This should allow the scripts to find the utilities regardless of the customer has setup the path environment variable. CR JAGab72105 The problem was introduced by the C-compiler on 64-bit systems. The compiler added padding to the beginning of a data structure that was passed as a parameter to the function which set the port configuration. This data structure was a 4-byte union containing the port configuration value. The padding caused the value to always contain zero or some other random value. Therefore, the card port could never be correctly configured using the 'n2z_pcfg' utility. The parameter type was changed to an "int" instead of the union data structure which corrected the problem. CR JAGab68606 The code which logs this message was not supplying the mux, port, and subchannel parameters causing random values to be displayed. The code has been corrected. CR JAGab73855 The problem was caused by walking off the end of the 'zx25_pda_infotbl' and 'n2z_zlu_tables' when the VC ZLU is greater than the size of these tables. This corrupted random areas of system memory leading to the above panic. CR JAGab84691 The ACC team is developing a new 8-port PCI serial card. The ACC software and firmware needs to be enhanced to support this new card. CR JAGab84870 The problem occurs when an outbound disconnect request is issued followed by a stream close on the VC stream *before* the disconnect confirm packet arrives. The disconnect request changes the type of the stream context structure to "unknown". When the stream close is issued, the code is unable to perform the proper cleanup processing for the VC stream because the context structure type is no longer assigned to a "VC" stream. This allows the disconnect confirm packet to be delivered to the upper half of the driver after the stream has been closed which causes the system panic. The fix is to delete the line that assigned the context structure type to unknown when an outbound disconnect request is issued. CR JAGac29102 Under extremely heavy loads with insufficient streams buffers being available, this panic can occur. An outbound call is placed and when the call is confirmed, if the driver is unable to allocate a streams buffer to pass the call confirmation upward, the driver clears the call by sending a clear indication up the stack and a clear request down the stack. However, before the clear request is processed, a VC up status, immediately followed by inbound data arrives. The VC up status unconditionally changes the state of the VC from clearing to data transfer which allows the inbound data to be sent upwards. The panic occurs when the VC data structures that have been nulled by the clear request are referenced in the processing of the inbound data packet. A change was made to the VC up status processing to ignore this status if the VC is in the clearing state. This causes the data packet to be discarded rather then passed upwards and thus avoids the panic. CR JAGab29104 Sometimes an ACC problem can not be reproduced with trace turned on due to timing differences. The chances of reproducing a problem with trace turned on increases with better performance of the trace code. Also, with better performance, it can be acceptable to leave trace permanently turned on for faster troubleshooting. CR JAGab66272 None. CR JAGab66270 The VC stream context (V_sctx->stype) was unprotected in 'n2z_upper.c' and could change from a valid VC stream to an unknown stream while executing PHNE_20101: CR JAGab82635 When the problem happened the test that is run uses lot of sockets and closes them.At this time the timing is such that the clear collision happens i.e., when Disconnect request is sent to the remote and the remote also sends a Disconnect (indication) and the 'Nli2zcom' is not sending Disconnect confirmation to the upper layers and simply terminates the circuit. The upper layers wait for disconnect confirmation and don't send close() on the stream until that is received. So when the problem happened the 'Nli2zcom' driver was not receiving close() and so Minor device table gets full. CR JAGab81509 "putq()" should be used instead of "putnext()". When "putq()" is used we delegate the service thread to do the job that way we are switching process context and avoiding the stack overflow. CR JAGab66316 By default the 'N2z_max_zlus' are defined 16K while the 'Zx25_max_zlus' are only 8K. So in a large configuration where the Zlu # >8k , the zx25 driver does not check for the zlu # and there by corrupts Sentry driver structures. This leads to a Panic. CR JAGab72034 System panic when zmasterd stop is done during 'x25init' There is a race condition that happens when 'x25init' is in progress and zcom subsystem is shutdown. 'X25init' goes to sleep waiting for the Zlus to be enabled and if meanwhile the user shutsdown Zcom, the shutdown process removes all the 'Nli2zcom' Link data structures and marks the links / Vcs down. Now if the Zlu enabled event happens , the driver tries to access freed data and results in panic. CR JAGab82415 / SR 8606109715 Memory leak of 2K stream buffers in call accept path. In the normal path the driver was simply not freeing the buffer. CR JAGab72105 Using the "n2z_pcfg zx25m0p0 3 0x8000" command to set the port to a LOOPBACK state is not working on the 64bit system. The problem is - the parameter "0x8000" is not properly passed to the N2z_Zcom_Port_Config() routine on the 64bit system. CR JAGab72028 A data structure being passed to the DAM was not aligned correctly when compiled in a 64 bit environment and the structure was modified to compile correctly. CR JAGab66270 A race condition during shutdown leaves data structures unprotected. Additional lock protection solves this problem. PHNE_19049: CR JAGab66255 When an 'N_CI' call is issued (outbound call request) and is rejected due to some reason, the 'N_DI' (disconnect Indication ) passed to upper layers has Invalid QOS fields. When a packet is received with 'Mbit', sometimes the 'Dbit' is getting turned on.This is due to a bug in the way the parenthesis are used in the logic. However the driver was only incrementing the 'inb_npkts' if both M&D bits are ON but not decrementing correctly. This leads to sending flowcontrol to the remote once the "inb_npkts > max_inb_pkts" but the flow control is never turned off. 'inb_npkts' counter should be decremented when a packet with M&D bit is moved up the stack. When SNA with QLLC option is used on ACC , the inbound data was queued using "putq" that causes performance problem. This was done to work around a bug in SNA that makes using "putnext" (faster) fail. Now that SNA is fixed in a patch , we can undo this and use "putnext" to queue inbound data for better performance. The transient reject feature used by OTS expects the Incoming call to be redirected to the Next listener if the Call Reject is not Permanent. 'Nli2zcom' driver had a logic problem that resulted in the call getting queued to the first matching listener always. DTS TPO0h02841 / SR 4701431023 The inbound flow control is incorrect handled by the 'N2Z' driver. Also, the zksend call is used the wrong parameter. TPO0h02756 The X.25/9000 product does not allow the 'T2' value to be configured and does not pass in a reasonable value to the ACC drivers when 'x25init' is run. This results in the 'T2' timer not being configured correctly. Modify the ACC 'nli2zcom' driver to set the 'T2' timer to the value of the 'T1' timer divided by 2. TPO0h02728 The 'NLI2ZCOM' driver was retrieving the mux, port, and subchannel values from the wrong field of the stream structure. In addition, the two IOCTL requests used to perform this functionality had the wrong modes. These two problems have been corrected. TPO0h02696 When adding an X.25 link to a linked list of L2 PDAs with pending writes to process, one of the source statements that is used to add the L2 PDA to the linked list was out of order causing the list to become corrupt. Later when the list was traversed, the system would panic. The source code statements were reordered to correctly construct the linked list. TPO0h02602 It is found that 'NLI2ZCOM' driver send it up 'M_FLUSH' on receiving a Disconnect Indication but that will stop at 'NLIFE's' lower side. So all the buffers from 'NLIFE' toward the 'STREAM head' are not flushed and so the Disconnect Indication MSG sits behind the Data msgs and takes too long to reach the Application. TPO0h02561 panic+0x14 report_trap_or_int_and_panic+0x4c interrupt+0x1ec $ihndlr_rtn+0x0 nacc1_process_firqs+0x56c nacc1_complete_req+0x1fe8 nacc1_end_io+0x26c nacc1_int_event+0x1e8 nacc1_isr+0x14 wsio_interrupt+0x54 inttr_emulate_save_fpu+0x100 spinunlock+0x2c settimeout_for_cpu+0xbc timeout+0x34 lpmc_lumberjack+0x28 invoke_callouts_for_self+0xac sw_service+0x94 This problem was caused when a request was issued to the 'zx25dvr' from the 'nli2zcom' (N2Z) driver to clear a VC which then failed due to lack of 'ZCOM' memory used to build the clear request packet.The 'N2Z' driver passed up an 'M_ERROR' but the state of the VC was not cleaned up in either the 'n2z' or 'zx25' drivers. Also, the "zksend()" function filtered request for both normal write and control request for a low memory condition. When the remote side cleared the VC, it was passed up by the 'zx25' driver to the 'n2z' which improperly passed the clear up to the SISL code causing a panic. The "zksend()" function was modified to only reject write requests when ZCOM memory runs low. Control writes and control request are will continue to be sent until ZCOM is completely out of memory. The 'nli2zcom' driver was modified to detect a low memory error from the 'zx25' request to clear a SVC. In this case, the driver logs an error message and disables and re-enables the X.25 link ZLU. For non-memory errors, the SVC ZLU is disabled and re-enabled. In both cases, 'M_ERROR' is no longer called and success is returned to the upper layers for the clear request. Note that the disable request causes the VC to be cleared or the link to be reset. TPO0h01987 Enhancement request to implement the 'isdn_pcfg' utility program to put the ISDN port into a tristate( reconfigure the port pmode state). DTS TPO0h01629: There was no option to specify a different path for the core dump directory. We have added the '-f' option that allows an user to specify the full path of the core dump. DTS TPO0h02703 While testing the OTS/9000 product with X25/ACC, the routine "QVF_F_qos_to_x25fac()" returns an error code (-1), when there is no error, when processing a disconnect indication. Enhancement: No (superseded patches contained enhancements) PHNE_23721: This is an enhancement for "x25stat" command to show "VC Up Time" for all active virtual circuits. SR: 8606287932 8606345144 8606306906 8606236935 8606289434 8606266220 8606259525 8606235666 8606231736 8606228520 8606227359 8606225328 8606171598 8606144441 8606146312 8606146870 8606152276 8606197878 8606197879 8606151859 8606144442 8606134537 8606134527 8606134396 8606134399 8606133128 8606132725 8606131096 8606125776 8606124015 8606124019 8606124022 8606125660 1653309682 8606112363 8606112521 8606114338 D500340299 8606110949 8606109934 8606108806 8606109715 4701431023 Patch Files: ACC-SX25.ACC-SX25-KRN,fr=B.03.02.00,fa=HP-UX_B.11.00_32, v=HP: ACC-SX25.ACC-SX25-KRN,fr=B.03.10.00,fa=HP-UX_B.11.00_32, v=HP: ACC-SX25.ACC-SX25-KRN,fr=B.03.10.01,fa=HP-UX_B.11.00_32, v=HP: /usr/conf/lib/libn2z.a /usr/conf/lib/libn2zsyms.o /usr/conf/acc/nli2zcom.h /usr/conf/acc/n2z_trace.h /opt/acc/bin/n2ztrc /opt/acc/bin/n2z_pcfg /usr/conf/space.h.d/zsx25_space.h /usr/conf/master.d/zsx25 ACC-SX25.ACC-SX25-KRN,fr=B.03.02.00,fa=HP-UX_B.11.00_64, v=HP: ACC-SX25.ACC-SX25-KRN,fr=B.03.10.00,fa=HP-UX_B.11.00_64, v=HP: ACC-SX25.ACC-SX25-KRN,fr=B.03.10.01,fa=HP-UX_B.11.00_64, v=HP: /usr/conf/lib/libn2z.a /usr/conf/lib/libn2zsyms.o /usr/conf/acc/nli2zcom.h /usr/conf/acc/n2z_trace.h /opt/acc/bin/n2ztrc /opt/acc/bin/n2z_pcfg /usr/conf/space.h.d/zsx25_space.h /usr/conf/master.d/zsx25 ACC-SX25.ACC-SX25-RUN,fr=B.03.02.00,fa=HP-UX_B.11.00_32/64, v=HP: ACC-SX25.ACC-SX25-RUN,fr=B.03.10.00,fa=HP-UX_B.11.00_32/64, v=HP: ACC-SX25.ACC-SX25-RUN,fr=B.03.10.01,fa=HP-UX_B.11.00_32/64, v=HP: /opt/acc/bin/make_n2z_ipmap /opt/acc/bin/make_n2z_route /opt/acc/bin/make_n2z_x25init /opt/acc/bin/n2z_cntrl /opt/acc/lbin/add_n2z_nls /opt/acc/lbin/make_n2z_devs /usr/lib/nls/C/zx25fmt.cat /etc/x25/x25init.sample what(1) Output: ACC-SX25.ACC-SX25-KRN,fr=B.03.02.00,fa=HP-UX_B.11.00_32, v=HP: /usr/conf/lib/libn2z.a: ACC Rel B.03.10.01 for 32-bit B.11.00 PHNE_30554 lib n2z.a /usr/conf/lib/libn2zsyms.o: None /usr/conf/acc/nli2zcom.h: $Header: nli2zcom.h@@/main/r3.10_r3.02/6 03/05/04 2 0:20:09 $ /usr/conf/acc/n2z_trace.h: $Header: n2z_trace.h@@/main/r3.10_r3.02/3 03/05/04 20:17:06 $ /opt/acc/bin/n2ztrc: ACC Rel B.03.10.01 for 32-bit B.11.00 PHNE_30554 n2z trc $ PATCH/11.00:PHCO_19491 Aug 9 1999 09:49:32 $ /opt/acc/bin/n2z_pcfg: ACC Rel B.03.02 for B.11.00 PHNE_20101 $Header: n2z_ pcfg.c@@/main/3 10/18/98 21:50:07 $ $ PATCH/11.00:PHCO_16629 Oct 23 1998 15:31:36 $ /usr/conf/space.h.d/zsx25_space.h: $Header: n2z_space.h@@/main/r3.10_r3.02/1 11/20/01 15:50:52 $ /usr/conf/master.d/zsx25: None ACC-SX25.ACC-SX25-KRN,fr=B.03.02.00,fa=HP-UX_B.11.00_64, v=HP: /usr/conf/lib/libn2z.a: ACC Rel B.03.10.01 for 64-bit B.11.00 PHNE_30554 lib n2z.a /usr/conf/lib/libn2zsyms.o: None /usr/conf/acc/nli2zcom.h: $Header: nli2zcom.h@@/main/r3.10_r3.02/6 03/05/04 2 0:20:09 $ /usr/conf/acc/n2z_trace.h: $Header: n2z_trace.h@@/main/r3.10_r3.02/3 03/05/04 20:17:06 $ /opt/acc/bin/n2ztrc: ACC Rel B.03.10.01 for 64-bit B.11.00 PHNE_30554 n2z trc $ PATCH/11.00:PHCO_19491 Aug 9 1999 09:56:42 $ /opt/acc/bin/n2z_pcfg: ACC Rel B.03.02 for B.11.00 PHNE_20101 $Header: n2z_ pcfg.c@@/main/3 10/18/98 21:50:07 $ $ PATCH/11.00:PHCO_16629 Oct 23 1998 15:31:36 $ /usr/conf/space.h.d/zsx25_space.h: $Header: n2z_space.h@@/main/r3.10_r3.02/1 11/20/01 15:50:52 $ /usr/conf/master.d/zsx25: None ACC-SX25.ACC-SX25-RUN,fr=B.03.02.00,fa=HP-UX_B.11.00_32/64, v=HP: /opt/acc/bin/make_n2z_ipmap: None /opt/acc/bin/make_n2z_route: None /opt/acc/bin/make_n2z_x25init: None /opt/acc/bin/n2z_cntrl: ACC Rel B.03.10.01 for 32-bit B.11.00 PHNE_23722 $He ader: n2z_cntrl.c@@/main/r3.10_r3.02/1 11/2 0/01 15:46:58 $ $ PATCH/11.00:PHCO_19491 Aug 9 1999 09:49:32 $ /opt/acc/lbin/add_n2z_nls: None /opt/acc/lbin/make_n2z_devs: None /usr/lib/nls/C/zx25fmt.cat: None /etc/x25/x25init.sample: NACC x25init.sample $Rev: /main/3 $ cksum(1) Output: ACC-SX25.ACC-SX25-KRN,fr=B.03.02.00,fa=HP-UX_B.11.00_32, v=HP: 1604336038 437820 /usr/conf/lib/libn2z.a 2042519297 273472 /usr/conf/lib/libn2zsyms.o 841380152 55153 /usr/conf/acc/nli2zcom.h 3064416710 57891 /usr/conf/acc/n2z_trace.h 3829033198 249856 /opt/acc/bin/n2ztrc 3425167226 156368 /opt/acc/bin/n2z_pcfg 2528857527 10612 /usr/conf/space.h.d/zsx25_space.h 265170293 5566 /usr/conf/master.d/zsx25 ACC-SX25.ACC-SX25-KRN,fr=B.03.02.00,fa=HP-UX_B.11.00_64, v=HP: 1784017699 968314 /usr/conf/lib/libn2z.a 883976311 340448 /usr/conf/lib/libn2zsyms.o 841380152 55153 /usr/conf/acc/nli2zcom.h 3064416710 57891 /usr/conf/acc/n2z_trace.h 3560097926 338184 /opt/acc/bin/n2ztrc 3425167226 156368 /opt/acc/bin/n2z_pcfg 2528857527 10612 /usr/conf/space.h.d/zsx25_space.h 265170293 5566 /usr/conf/master.d/zsx25 ACC-SX25.ACC-SX25-RUN,fr=B.03.02.00,fa=HP-UX_B.11.00_32/64, v=HP: 2797378038 9480 /opt/acc/bin/make_n2z_ipmap 3875774991 11013 /opt/acc/bin/make_n2z_route 3922711005 15082 /opt/acc/bin/make_n2z_x25init 3593047420 196608 /opt/acc/bin/n2z_cntrl 2423085775 6280 /opt/acc/lbin/add_n2z_nls 2007601403 4492 /opt/acc/lbin/make_n2z_devs 102571960 41753 /usr/lib/nls/C/zx25fmt.cat 209400739 676 /etc/x25/x25init.sample Patch Conflicts: None Patch Dependencies: s700: 11.00: PHNE_26693 PHNE_23723 s800: 11.00: PHNE_26693 PHNE_23723 Hardware Dependencies: None Other Dependencies: To enable the feature mentioned in JAGad40862 ie. usage of "-u" option with x25stat command to display "VC Up Time", the patch PHNE_23190 or its superseding patch must be installed. Supersedes: PHNE_19049 PHNE_20101 PHNE_20745 PHNE_22253 PHNE_23722 PHNE_26297 PHNE_28606 Equivalent Patches: None Patch Package Size: 1380 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_30554 5. Run swinstall to install the patch: swinstall -x autoreboot=true -x patch_match_target=true \ -s /tmp/PHNE_30554.depot By default swinstall will archive the original software in /var/adm/sw/save/PHNE_30554. If you do not wish to retain a copy of the original software, include the patch_save_files option in the swinstall command above: -x patch_save_files=false WARNING: If patch_save_files is false when a patch is installed, the patch cannot be deinstalled. Please be careful when using this feature. For future reference, the contents of the PHNE_30554.text file is available in the product readme: swlist -l product -a readme -d @ /tmp/PHNE_30554.depot To put this patch on a magnetic tape and install from the tape drive, use the command: dd if=/tmp/PHNE_30554.depot of=/dev/rmt/0m bs=2k Special Installation Instructions: None