|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
From: IT Resource Center (support_feedback
us-support.external.hp.com)Date: Wed Feb 28 2001 - 06:40:07 CST
HP Support Information Digests
===============================================================================
o IT Resource Center World Wide Web Service
---------------------------------------------------
If you subscribed through the IT Resource Center and would
like to be REMOVED from this mailing list, access the
IT Resource Center on the World Wide Web at:
http://www.itresourcecenter.hp.com/
Login using your IT Resource Center User ID and Password.
Then select Support Information Digests (located under
Maintenance and Support). You may then unsubscribe from the
appropriate digest.
To download a patch referenced below, access the
IT Resource Center on the World Wide Web at:
http://www.itresourcecenter.hp.com/
Login using your IT Resource Center User ID and Password.
Then select Individual Patches (under Maintenance and Support)
to access the patch. You may also download a patch via anonymous
ftp(1) from ftp.itrc.hp.com.
===============================================================================
Digest Name: weekly HP-UX series 800 10.X patch digest
Created: Wed Feb 28 3:05:04 PST 2001
Table of Contents:
Document ID Title
--------------- -----------
PHSS_22862 s700_800 10.24 VirtualVault 3.5 WebQOS patch
PHNE_22732 s700_800 10.20 R6.10.20 SNAplus2 Link cumulative patch
PHNE_21213 s700_800 10.20 R6.10.20 SNAplus2 Link cumulative patch
PHNE_23439 s700_800 10.24 (VVOS) BIND 4.9.7 components
PHNE_23277 s700_800 10.01-[12]0 BIND 4.9.7 components
PHCO_23148 s700_800 10.20 HP Array Manager/60 cumulative patch
PHCO_23037 s700_800 10.20 mkfs_vxfs(1M) cumulative patch
PHCO_23035 s700_800 10.20 extendfs_vxfs(1M) cumulative patch
PHSS_23351 s700_800 10.X Fortran90 B.10.20.(19|20|27) cumulative patch
PHNE_23034 s700_800 10.20 2.40.00-2.40.02 X.25/ACC Protocol Patch
PHCO_23321 s700_800 10.01 kermit(1) cumulative patch
PHCO_23320 s700_800 10.10 kermit(1) cumulative patch
PHCO_23319 s700_800 10.20 kermit(1) cumulative patch
PHSS_22652 s700_800 10.20 LIBCL cumulative patch
PHCO_23181 s700_800 10.26 libc cumulative patch
PHKL_23419 s800 10.20 VxFS mount(2) cumulative patch
PHKL_23285 s800 10.20 mpctl(2) negative SPU check
PHCO_22768 s700_800 10.20 cumulative cron/at/crontab patch
The documents are listed below.
-------------------------------------------------------------------------------
Document ID: PHSS_22862
Date Loaded: 20010226
Title: s700_800 10.24 VirtualVault 3.5 WebQOS patch
Patch Name: PHSS_22862
Patch Description: s700_800 10.24 VirtualVault 3.5 WebQOS patch
Creation Date: 00/12/01
Post Date: 01/02/26
Hardware Platforms - OS Releases:
s700: 10.24
s800: 10.24
Products:
VirtualVault A.03.50 US/Canada Release;
VirtualVault A.03.50 International Release
Filesets:
VaultNES.NES-VAULT,A.03.50
Automatic Reboot?: Yes
Status: General Release
Critical: No
Path Name: /hp-ux_patches/s700_800/10.X/PHSS_22862
Symptoms:
PHSS_22862:
With WebQoS is enabled, the following error is produced:
warning ( 1558): for host (IP X.X.X.X) trying to GET
/cgi-bin/menu/mboard, hpacControl reports: bad MD5 cookie
recieved from (IP X.X.X.X)
Defect Description:
PHSS_22862:
When WebQoS is enabled on VirtualVault the server will
return a cookie called 'VVMonState'. This cookie is used
to help WebQoS keep track of a session. Currently, this
cookie is being created using commas as field separators.
This is an invalid format that can not be properly
interpurpreted by The Java scripts and therefore, the
cookie can not be read.
Resolution:
The creation of the 'VVMonState' cookie has been modified
so that it no longer uses comma separators.
SR:
8606159019
Patch Files:
/var/opt/nes/bin/https/libvvsc.so
what(1) Output:
/var/opt/nes/bin/https/libvvsc.so:
None
cksum(1) Output:
1386647560 24631 /var/opt/nes/bin/https/libvvsc.so
Patch Conflicts: None
Patch Dependencies: None
Hardware Dependencies: None
Other Dependencies: None
Supersedes: None
Equivalent Patches: None
Patch Package Size: 80 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 PHSS_22862
5a. For a standalone system, run swinstall to install the
patch:
swinstall -x autoreboot=true -x match_target=true \
-s /tmp/PHSS_22862.depot
By default swinstall will archive the original software in
/var/adm/sw/patch/PHSS_22862. 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 PHSS_22862.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/PHSS_22862.depot of=/dev/rmt/0m bs=2k
Special Installation Instructions:
The patch installation replaces the WebQoS library.
The Netscape Daemon processes must be stopped prior to
the installation of the patch and restarted after
installation completes.
-----End of Document ID: PHSS_22862------------------------------------------
Document ID: PHNE_22732
Date Loaded: 20010226
Title: s700_800 10.20 R6.10.20 SNAplus2 Link cumulative patch
Patch Name: PHNE_22732
Patch Description: s700_800 10.20 R6.10.20 SNAplus2 Link cumulative patch
Creation Date: 00/11/14
Post Date: 01/02/26
Hardware Platforms - OS Releases:
s700: 10.20
s800: 10.20
Products:
SNAplus2-Link R6.10.20
Filesets:
SNAplus2-Link.SNAP2-LINK,R6.10.20.000
SNAplus2-Link.SNAP2-LINK,R6.10.20.010
Automatic Reboot?: Yes
Status: General Release
Critical:
Yes
PHNE_22732: PANIC
PHNE_21213: PANIC HANG
PHNE_20211: PANIC
PHNE_19407: HANG PANIC
PHNE_19070: HANG
PHNE_17819: PANIC HANG
PHNE_17405: HANG PANIC
PHNE_16758: HANG
Path Name: /hp-ux_patches/s700_800/10.X/PHNE_22732
Symptoms:
PHNE_22732:
(1) JAGad13997/8606144657
System panic from ncs_destroy_an_cb_if_required
Also the following asserts were logged at same time
as panic:
WARNING: SNA ASSERT:
File: ../../p/vappn/ncsfsmln.c
Line: 104
Condition: !an_cb->num_active_conns
WARNING: SNA ASSERT:
15:20:08 24 JUN 2000
File: ../../p/sappn/ncsxidtg.c
Line: 1272
Condition: tg_number == 0
(2) JAGad21193/8606151854
System panic from nrm_process_cnos_reply.
Also an assert was logged at same time as
panic:
WARNING: SNA ASSERT:
07:25:11 20 JUL 2000
File: ../../p/sappn/nrmcnos.c
Line: 292
Condition: wait_req != NULL
(3) JAGad35609/8606166322
RUI does not support segmented delivery from the lower
layers. Incorrect data is returned on RUI read call
when RU is segmented. Note that similarly, incorrect
data could be passed through on a PU concentrated
connection.
PHNE_21213:
(1) JAGac95609/8606130719
System panic after call to npo_sess_limit_data_lock_mgr().
(2) JAGac86152/8606128605
LU Type 2 is inactive on the HP side but active on the IBM
side. No DACTLU or segmentation error is seen in the DLC
trace, but sna.err file shows the following:
APPN Message 512 - 171, Subcode: 0 - 10
Session segmentation error.
....
RU : (3 bytes)
(3) JAGac78841/8606128040
System panics after receiving an UNBIND during initialise
session limits processing. The stack shows that
nba_mm_free was called from nlu_remove_mode. A similar
problem was also reported in JAGac95609.
(4) JAGac78479/8606127677
Cannot reliably stop SDLC link station or port.
Once the port gets stuck in the stopping state
the sna has to be recycled.
(5) JAGab74691/8606105945
3270 user gets PROG checks 432 (bracket race) when typing
ahead together with ASSERT in vbaccess line 324 and log 52
(internal error copying buffer). User needs to do reset on
3270 to recover.
PHNE_20738:
(1) JAGab83920/8606111815
Customer's QLLC link fails to come up due to error in the
XID exchange. The sna.err log shows XID 3 error during
negotiation.
(2) JAGab74185/8606105839
An LUA application receives an UNBIND indication from an
established LU-LU session. It responds with RSP.UNBIND and
encounters the following error:
primary return code: LUA_STATE_CHECK (0x0200)
secondary return code: LUA_NO_RUI_SESSION(0x81000000)
(3) JAGab65399/4701429621
Dependent APPC LU does not get BIND from VTAM after the
link is re-established following an outage.
(4) JAGab25510/5003467290
Token Ring connection hangs when frames exceeding the
largest frame size returned in RIF are dropped by the
network.
PHNE_20211:
(1) JAGab79003/8606108556
K580 system panics on reboot with the following error
messages:
System Panic:
9245XB HP-UX (B.10.20) #1: Sun Jun 9 06:31:19 PDT 1996
panic: (display==0xb800, flags==0x0) nio_initialize :
l_io_vec.iov_base == NULL
PC-Offset Stack Trace (read across, most recent is 1st):
0x00276f44 0x003fdab0 0x00404968 0x001297c4 0x00240ae8
0x002a7ea8 0x002a6ae4 0x00215088 0x002147e0 0x00295368
0x00295444 0x00295444 0x00295444 0x002951c0 0x00295d20
0x002f316c 0x000c7014 0x00183960
End Of Stack
It was not possible for the kernel to find a process
that caused this crash.
jCj1D
Dumpsys() called
(2) JAGab75469/8606106415
When starting an SDLC link the system panics with
following stack trace:
stack trace for event 0
crash event was a panic
FUNC
panic+0x10
report_trap_or_int_and_panic+0xe8
trap+0xa48
$RDB_trap_patch+0x20
sna_sdlc_vba_ips_putb+0x18
sdl_send_set_mode_frame+0x138
sdl_psecs+0xf88
sdl_prtmg+0x106c
sdl_wrxfr+0x5a8
sdl_receive_proc+0x80
sna_sdlc_nba_dispatch_input+0x254
sna_sdlc_nba_dispatch_process+0xa4
sna_sdlc_nba_scheduler+0x11c
vsi_stream_uw_service+0x3e0
sq_wrapper+0xb8
str_sched_mp_daemon+0x114
str_sched_daemon+0x1f4
main+0x97c
$vstart+0x34
(3) JAGab73055/8606105164
While running SNAplus2 R6 on HPUX 11 a link failure
occurred.
The sna.err log file recorded message 4096 - 13
(ASSERT: File name = ../../p/vhlwr/vhshmod.c ).
This caused the link to go down for one
minute, and disrupting the current file transfer.
Following the ASSERT, the sdlc driver is trying to
do ten consecutive svphrx() calls.
The last 9 calls will fail. The SDLC driver calls
svphclos() to stop the link.
(4) JAGab71519/8606104163
This system panic occurred on a H20 running 10.20 with
128MB.
panic+0x10
report_trap_or_int_and_panic+0xe8
trap+0xa48
$call_trap+0x20
nsm_delete_session_id+0x104
nsm_cleanup_lu_lu_session+0x7b8
nsm_fsm_status+0x1d4c
nsm_process_deactivate_session+0x140
nsm_process_record_from_rm+0x1a8
nsm_queue_handler+0x68
nba_dispatch_process+0x114
nba_scheduler+0x208
vpr_stream_uw_svc+0x58c
sq_wrapper+0xb8
str_sched_up_daemon+0x2b0
str_sched_daemon+0xf4
main+0x974
$vstart+0x34
PHNE_19407:
(1) JAGab71689
The following message is noted periodically in sna.err
file:
10:07:29 EDT 09 Aug 1999 4096-5(0-0) P (UH2010D3)
PID 3733 (snaperrlog)Log parameter mismatch.
Message number = 512 - 137
The message 512 - 137 then follows with a question mark
for the sense code.
(2) JAGab71162
Symptoms of problem:
After installing patch, PHNE_19527, and selecting
Diagnostics, node tracing, sdlc level 2 tracing in
xsnapadmin, activated the node. Then, ls went into
starting status, then retry pending. Several seconds
later, the system panicked. The following stack was
produced when the machine crashed:
panic+0x14
report_trap_or_int_and_panic+0x4c
trap+0xef4
$RDB_trap_patch+0x38
sdl_reset_port+0x13c
sdl_poll_port+0x3ec
sdl_hms_ctl_proc+0xb4
sdl_receive_proc+0x14c
sna_sdlc_nba_dispatch_input+0x254
sna_sdlc_nba_dispatch_process+0xa4
sna_sdlc_nba_scheduler+0x11c
sna_sdlc_vsi_stream_uw_service+0x3e0
sq_wrapper+0x90
str_sched_up_daemon+0x440
str_sched_daemon+0x1f0
main+0x6e0
$vstart+0x34
$locore+0x90
The following asserts were also seen in the console log:
WARNING: SNA ASSERT:
17:10:45 25 AUG 1999
File: ../../p/vsdlc/sdlcsigi.c
Line: 1495
Condition: pcb->resetting == FALSE
WARNING: SNA ASSERT:
17:11:15 25 AUG 1999
File: ../../p/vsdlc/sdlcsigi.c
Line: 1375
Condition: pcb->alert != NULL
(3) JAGab68385
Code inspection has shown that the SNAplus2 Kernel drivers
do not have the MGR_IS_MP flag set on the streams_info
structure. This has not caused problems but may affect
performance on MP systems.
(4) JAGab65528
The customer has been running SNAplus2 version R6.11.00
with PHNE_17229 for about a month with no problems. Today,
after about 20 3270 users become active the system hangs.
Needed to do a TOC to recover. The following stack trace
yielded from TOC:
nba_get_q_head+0x0
nch_sscp_receive+0x9b8
nba_dispatch_input+0x298
nba_dispatch_process+0xa4
nba_scheduler+0x1b0
vpr_stream_lr_svc+0x134
sq_wrapper+0x90
str_sched_up_daemon+0x440
str_sched_daemon+0x1f0
main+0x6e4
(5) JAGab65397
SNAplus2 R6.10.20 SDLC link fails to start if DSR is not
present when link station is started. Only recovery is to
reboot the system and ensure that modem signals are present
before starting the link. Loss of DSR causes the same
problem.
The following errors are logged:
SDLC Message 768 - 17, Subcode: 1 - 11
Log category: EXCEPTION Cause Type: External
System: dqserv1
DSR was not active when activating port.
Return code = 0x0003
Cause: An error occurred on a port. The port is configured
as Non-switched but DSR was not present.
Action: Check whether the configuration setting of
non-switched is correct.
If the port is correctly configured, check the modem and
link hardware.
Check other messages for further diagnostics.
SDLC Message 768 - 94, Subcode: 0 - 11
Log category: EXCEPTION Cause Type: External
System: dqserv1
SDLC port device driver reported an error.
DLC name = SDLC0
Port name = mapport
Port number = 0x00000000
Return code = 0x0003
Detailed return code = 0x0020
Cause: An error occurred on an SDLC port. The detailed
return code provides more information on the error,
as follows:
0x0020 DSR failure
0x0021 General hardware failure
0x0022 Modem power off
0x0023 CTS failure between frames (4 wire)
0x0024 CD failure between frames (4 wire)
Action: Check the detailed return code shown; check for
previous exception messages providing more information
about the failure.
(6) JAGab65303
The customer has problems printing a long file from a host.
Gets the following error:
---------------- 19:34:03 SAT 21 May 1999------------------
APPN Message 512 - 452, Subcode: 0 - 10
Log category: EXCEPTION Cause Type: SNA
System: cnbv
LU type 0, 1, 2, or 3 session ended abnormally - protocol
error.
Sense code = 0x10020000
LFSID = 018E0000
Cause: An LU type 0, 1, 2, or 3 session ended abnormally
(with the sense code shown) because of a protocol error.
Action: Contact network support personnel with details of
the problem.
The sense code 0x10020000 means 'RU Length Error'.
The problem was not seen when similar files were printed
with SNAplus.
PHNE_19070:
(1) 4701429407
Lan performance degraded when attempting to start an SDLC
psi card on a T600 system.
(2) 4701425561
R6.11.00 on a V-Class system: After several hours of APPC
activity, (about 10 incoming allocates per second), APPC
TP's fail to load, with error messages 512-257(0-10)
logged.
In addition, a system panic has occured while the user
APPC application was terminated.
Although these two problems are very different by nature,
it has been determined that they are closely related due
to internal mechanisms in SNAPlus2 in its communication
via Streams putq messages.
The stack trace for the panic was as follows:
panic+0x14
report_trap_or_int_and_panic+0x80
trap+0xa8c
nokgdb+0x8
putq_owned+0x2a0
putq+0x1c
vba_track_putq+0x4c
vpr_stream_output_msg+0x40c
vpr_delete_entity+0x43c
vpr_stream_close+0x1a8
close_wrapper+0x6c
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
exit+0x324
rexit+0x28
syscall+0x480
$syscallrtn+0x0
(3) 4701425355
While running reliability tests with new ACC driver and
SNAplus2 the lab hit a system hang a couple of times when
using qllc over X25.
(NB: ACC use their own X.25 stack which uses nli2zcom
module.)
When examining the TC with q4 we found the system stuck at
same routine, sna_q_v0_get_rw_lock, in libsixp.a. Here is
how the q4 stack looks.
sna_q_v0_get_rw_lock+0xc8
vql_stream_read_input+0xdc
putnext+0x50
N2Z_F_data_ind+0x38
N2z_iev_pass_data_up+0x114
N2z_ReadEvent_Recvd+0x209c
Zc_putq+0x5c
nacc0_receive_data+0x140
(4) 1653299073
After upgrading from R4.4 to R6.10.20 on a T600 system,
the SDLC link could no longer be activated and the lan
performance is severly degraded.
When the SNA resources are activated, the following error
messages are logged:
----------------------- 15:32:40 WET 19 mars 1999
SDLC Message 768 - 107, Subcode: 0 - 11
Log category: EXCEPTION Cause Type: External
System: centurix
SDLC write timer retry limit has been exceeded.
DLC name = SDLC0
Port name = SDLCP0
Port number = 0x00000000
Cause: An attempt to transmit a frame using an SDLC port
has timed out.
This may indicate a problem with the SDLC adapter or with
the modem and cabling. The port is stopped.
Action: Check the modem and communications link.
----------------------- 15:32:40 WET 19 mars 1999
APPN Message 512 - 60, Subcode: 0 - 10
Log category: PROBLEM Cause Type: SNA
System: centurix
An active link station has failed.
Port name = SDLCP0
LS name = SDLCL0
Adjacent CP name = 0000000000000000000000000000000000
Cause: An active link station has failed
----------------------- 15:33:29 WET 19 mars 1999
SDLC Message 768 - 17, Subcode: 1 - 11
Log category: EXCEPTION Cause Type: External
System: centurix
DSR was not active when activating port.
Return code = 0x0003
Cause: An error occurred on a port. The port is configured
as Non-switched but DSR was not present.
Also the syslog.log is filled up with the messages
'lan3_process_read_completion: Received out of sequence'
The impact of all the above is that the LAN card becomes
very slow to the point where the system becomes unusable.
The only way to recover LAN traffic is to reboot the system
without starting SNA at all.
PHNE_17819:
(1) 5003446971
Data page fault panic in nbm_free_buffer while running
simple SNA tests over two LAN interfaces between the three
machines running SNAplus2.
(2) 4701418707
When using CPI-C without side information, outgoing
attaches sometimes fail because validation has been
unintentionally turned on.
(3) 1653305805
One processor on a two processor box running R6 over 10.20
hangs which then causes cmcld to TOC the box to preserve
system integrity.
Top of stack for hanging process is:
FUNC PC
v0_get_rw_lock+0xb8 0.0x3cc4a8
vpr_route_ips_on_route+0x40 0.0x4094e0
vds_rcv_buffers_available+0x1a0 0.0x3e1720
vds_receive_proc+0x674 0.0x3e47fc
nba_dispatch_input+0x298 0.0x5af050
nba_dispatch_process+0xa4 0.0x5af184
nba_schedule_process+0x134 0.0x5af5ec
nba_send_ips+0x308 0.0x5afd3c
(4) 1653293878
Invokable TP failing to start with following error messages
logged.
------------- 10:52:14 GMT 10 Feb 1999 ----------------
NODE Message 16384 - 0, Subcode: 10 - 10
Log category: EXCEPTION Cause Type: Internal
System: LR1875
Internal system error. Errno = 7
Action: Provide support services with the audit and error
log files, and trace files if available.
------------- 10:52:14 GMT 10 Feb 1999 ----------------
APPN Message 512 - 257, Subcode: 0 - 10
Log category: PROBLEM Cause Type: Config
System: LR1875
Dynamic load of TP failed.
Sense code = 0x07000000
LU alias = DFKC
TP name = lr229bci
PHNE_17405:
(1) 5003441717
The snaperrlog process can be left lying around when the
SNAplus2 daemon is not started. Attempting to restart the
SNAplus2 software using 'snap start' will fail (because the
snaperrlog process is still there from a previous run).
(2) 4701413054
System panic - Data Page Fault at
nsm_process_record_from_ss+130
(3) 4701399279
The PSI firmware header is not recognized by the snapwhat
command.
(4) 1653289686
If using a TN3270 (not E) client and hit the clear
key while TN Server is presenting an SSCP screen,
then the client will lock up.
The host may respond with an error message.
(5) 1653289603
If using a TN3270 (not E) client and hit the clear key
while TN Server is presenting an SSCP screen, TN Server
forwards the clear key to the host(sends an empty RU
on SSCP-LU session).
The host may respond with an error message.
PHNE_16758:
(1) 4701405316
Updated binaries required for patching the latest
R6 release of SNAplus2.
(2) 4701399527
Assert errors are produced when the host sends a USSMSG10
screen to a LU configured for LU6.2. The ASSERTS are in
fact benign, and will cause no problems with the integrity
of the system.
The ASSERTs only occur when the USSMSG10 screen is
segmented, and greater than around 500 bytes in size.
(3) 1653279703
Assert errors logged when RJE workstation is started
due to RTM request being received.
This has no affect on opperation other than bad
entries in the error log.
(4) 1653276543
3270 session can hang, even if you stop and restart the
snap3270 emulator.
If you take a trace of the problem, you will see that a
NOTIFY is not sent when the 3270 emulator is stopped or
started.
(5) 1653273979
Enhancement to allow multiple PUs to be used on a secondary
leased link. This means that if an SDLC port is connected
to a leased line, you can have multiple LS's active over
the port at the same time.
(6) 1653267179
An Application can fail to start a remote LU62 transaction,
because an invalid user ID is specified on the Attach,
when AP_SAME is specified on the ALLOCATE verb.
PHNE_15937:
(1) 5003398354
If you issue 'snapadmin define_local_lu' for an LU which
is already defined, only the attach routing data and the
description field are updated - all other parameters are
ignored - however, the snapadmin command does not indicate
this but gives a successful return message.
(2) 4701396374
Node fails to start if TN Client configured with
unrecognised hostname.
(3) 4701395459
The following assert message is logged to the console,
syslog file and sna log files.
Assert ips->cont_size >= MU_CONT_SIZE from vtc.c
(4) 4701392670
When in client /server configuration, various ASSERT
messages recorded in the sna.err log file from the SLIM
component, followed often by a crash of the SLIM.
This causes general unpredictable behaviour of the system
when the master server goes down and is restarted.
(5) 1653261669
SDLC link shows DISABLED after restart of SNAPLUS2 daemon
PHNE_14392:
(1) 4701386227
Unable to start SDLC Eisa cards
Defect Description:
PHNE_22732:
(1) JAGad13997/8606144657
System panic occurs because a second attempt is made to
free an AN (Adjacent Node) control block , which has
already been succesfully freed.
Resolution:
A fire-wall has been put into the code to ensure
that it will not attempt a double-free in future.
(2) JAGad21193/8606151854
If a TP terminates at the same time as the CNOS race
condition, there is some bugged processing that
causes a panic.
The last error log before the panic shows that a TP
had indeed just ended - the assert shows that we
were in a CNOS race condition.
Resolution:
Modified the code in nrm_process_cnos_reply so that a check
is made to see whether wait_req is valid. If not then we
know the pending list has already been cleared up so we
don't need to do anything.
(3) JAGad35609/8606166322
RUI does not support segmented RU delivery from the lower
layers within the APPN node. However, it was not setting
a flag to tell PC to re-segment RU's before passing them
upwards.
Resolution:
RUI was getting incorrect data from lower layers when
Ru was segmented. Code change made to request unsegmented
delivery on PLU session at OPEN_PLU time.
PHNE_21213:
(1) JAGac95609/8606130719
The analysis of the partial dump points to the
following sequence of events that led to the panic:
- STOP_NODE quiesce comes into the NOF - goes to TRS,
then the first PS
- PS COPR builds and sends RESET_SESSION_LIMITS(all) to
itself
- PS COPR locks all the modes, and issues ALLOCATE to PS
(not traced)
- PS sends ALLOCATE_RCB to RM
- we cannot contact remote, so RM cannot activate a
session
- ALLOCATE_RCB(failure) comes back to PS
- PS completes its processing of ALLOCATE
- PS calls nlu_tidy_up_plu_and_mode, which removes a
mode CB ***bug***
(note that the assert on mode state in nlu_remove_mode
would get hit here).
- PS returns the ALLOCATE verb (not traced)
- PS COPR detects the failure of the ALLOCATE
- PS COPR tries to unlock all modes but none exist.
Asserts on mode_state and mode locks seen in the dump
also support this explanation.
Resolution:
A check is made on the mode lock before freeing the mode.
The mode CB is freed by npo_reset_sess_limit_proc
instead of npb_allocate_proc.
(2) JAGac86152/8606128605
The router kept the LU 'offline' until +RSP to a NOTIFY was
received. While the LU was 'offline' no segmentation
checking was done and an incoming EBIU (from the end of the
VTAM Screen) was ignored. This kept us 'in segment' and
caused subsequent NOTIFY +RSP and a BBIU to be processed
with an error. The IBM side meanwhile considers the LU to
be online since it received no indication of a problem.
Resolution:
The fix is to ensure that even when we are offline we
still clear the in_biu flag when we see an EBIU flag.
(3) JAGac78841/8606128040
In certain race cases the mode control block was being
released to memory twice leading to the panic.
Resolution:
A major rework of the mode control block handling code was
performed to carefully check and remove mode control blocks
at the correct time. The mode lock is checked before
freeing the mode, so that npb_allocate_proc does not free
the mode CB, but npo_reset_sess_limit_proc does.
(4) JAGac78479/8606127677
An internal message is being discarded during the close
processing of a link. The problem is intermittent due
to a race condition.
Resolution:
Changed code to eliminate discarding of internal messages
during close processing.
(5) JAGab74691/8606105945
The internal error (bracket race) was caused by
bad SNA data coming from the host (EB BC followed by
EC CD) and the user (or possibly HLLAPI) typing ahead.
The ASSERT that gets generated is actually harmless.
Resolution:
The bracket race is avoided by working around the bad SNA
data sent by the host (removed CD from EC). The ASSERT was
corrected by zeroing a floating length field.
PHNE_20738:
(1) JAGab83920/8606111815
The SNAplus2 node carefully checks the ABM support fields
on an XID. Unlike previous versions of SNAplus, we are
now being very restrictive regarding the particular
combination of ABM support flags we let through. Whilst
we are following the SNA Formats manual correctly, this
does cause interoperability problems with some hosts.
In this circumstance we have decided to relax the
checks on the ABM support flags, to allow
interoperability with other hosts.
Resolution:
Remove test that compares ABM support flags on XID.
(2) JAGab74185/8606105839
The problem is caused by a STATUS_SESSION(NO_SESSION,
LU_INACTIVE) followed by an CLOSE_PLU_SLU_SEC_RQ.
The CLOSE causes a dummy UNBIND to be built and
queued, but the CLOSE kills the session between
the RUI_BID returning and the subsequent RUI_READ.
Resolution:
Check the reason for the CLOSE - if it is due to a LINK
error or because the PU or LU are inactive, then simply
kill the session - don't send the UNBIND down to the
application.
(3) JAGab65399/4701429621
If CH (Conventional Half-session) receives a segmented
logon screen to an off-line LU, for example a dependent
LU6.2 LU, CH may send an invalid response or, more likely,
no response at all. This could potentially cause problems
when trying to use APPC over that LU.
Resolution:
The nch_sscp_receive now stores the RH from the BBIU
(!EBIU) in the SSCP section of local data. When the EBIU
arives, the RH is copied in and it is turned round as a
negative RSP.
(4) JAGab25510/5003467290
SNAplus2 does not negotiate down the maximum BTU size
from the largest frame size received in the RIF on the
TEST_RSP (route discovery frame) received from the
token ring driver.
Resolution:
Correct the code to process the RIF before sending the size
back to SNAP APPN.
PHNE_20211:
(1) JAGab79003/8606108556
The driver code during nio_initialize checks for NULL IOVAs
returned from sio_map(). The psi0 driver will panic if
sio_map returned an IOVA of 0. But 0 is a valid IOVA;
therefore, psi0 should not panic for NULL IOVAs.
Resolution:
Fix is to remove the panic on NULL IOVAs after sio_map()
calls. Also in the step data structure, invalid IOVAs are
redefined to be -1 (void* 0xffffffff) instead of 0. Also,
change all checks for 0 IOVAs to be -1 IOVAs.
(2) JAGab75469/8606106415
When a SNRM retry is received very quickly after the
initial SNRM such that it crosses with the outgoing UA,
SNAP-LINK may crash because it does not have a valid
frame buffer.
Resolution:
Before sending a UA for a SNRM retry, check to see if the
frame_buffer used for UA's is present or not. If not, it
must be in the stub, so ignore the incoming SNRM retry.
(3) JAGab73055/8606105164
Problem is that we are accessing data shared between
normal context and call back context (hence typically
interrupt context) outside the correct locking.
We need to keep the lock on vhs_data_lock whenever we
update data in the pcb_shared_data area of the
port control block. We had a window where a TX was
issued at the same time as a RX completed and so
both bits of code tried to set up the next frame to
RX and got confused.
Resolution:
The fix is to reorder the code to make all the changes
to pcb_shared_data area inside the locked section
of code.
(4) JAGab71519/8606104163
In certain circumstances RM will be asked to delete an
SCB that was created by another instance of RM. If
this happens then we can assert or crash when
trying to delete the session.
Resolution:
Fix is to store the process ID of the RM instance that
creates the SCB on the SCB, then when RM receives a
DEACTIVATE_CONV_GROUP (which is routed from the NOF using
the LU name/alias field) it can check that the SCB was
created by this instance of RM and reject the signal
(with new secondary return code NAP_LUNAME_CGID_MISMATCH).
PHNE_19407:
(1) JAGab71689
From the code it appears that there is not really a
parameter mismatch, but it looks as though the problem is
due to us trying to log more text than we actually allow.
We are limited by a 600 byte array of log text in
nba_pd_print_var.
Resolution:
The log parameters are limited to 600 bytes to allow all of
the log datagram to fit in a 1k buffer for use by the SLIM.
Consequently, we can't change this 600 byte limit.
Instead, for the particular log mentioned in this defect,
we should ensure that the sense code gets put into the
buffer before the error data (that way we will ensure we
get all of the sense code). This will also stop the
erroneous messages in the log file as we will be logging
all of the parameters.
(2) JAGab71162
Cause of problem:
Having looked at the dump file it appears that the root
cause of this crash is down to a timing problem:
For switched links we send a REGISTER_STATION message
from SNAP LINK to the HMOD stub. The HMOD receives
this message, sends a response and issues an
svphopen call to the actual HMOD. Upon receiving the
REGISTER_STATION response SNAP LINK sends down a DIAL
PORT message. The HMOD doesn't do anything with
this DIAL PORT - it simply sends a response back
immediately. When the HMOD open routine comes back
(via the HMOD call back) the HMOD stub sends a POLL
PORT message which indicates that we have successfully
raised DSR.
SNAP LINK must get the DIAL PORT response before the POLL
PORT.
However, if the HMOD open returns prior to the DIAL PORT
response being sent, SNAP LINK will decide this is an
error and issue a RESET PORT message.
Normally we don't see this as the svphopen takes long
enough to come back that we have processed the DIAL
PORT. However, turn on tracing and the SNAP LINK/HMOD
processing takes longer and there is a chance that we
will get the svphopen back sooner than the DIAL PORT
response (note that the customer hit this timing
window with just SDLC level 2 trace - to reproduce
it we had to turn on internal trace in the SDLC
driver as well).
The reason the box is actually crashing is even more
convoluted:
The reset port message that we send down (which is
built on top of an alert held on the port control
block in SNAP LINK) doesn't have the correct
port_handle put onto it. Consequently when we get the
reset_port response we assume that the port control
block has been destroyed and we simply free off the
reset port message. Unfortunately this leaves us
in a bad state:
- Firstly the resetting flag on the pcb is wrong - it
is left as resetting == TRUE.
- Secondly, because the reset port is freed off, this
frees the alert stored on the pcb.
The first assert is occurring because SNAP LINK issues
reset port again to reset the port group. At this point
we spot that the restting flag is wrong.
The second assert happens when we are doing a retry of
the LS - the same timing problem as before happens
meaning we try and send a reset port using the alert
held on the pcb. Unfortunately this has been set to NULL
(hence the assert) because of our failure to reconcile
the reset port response. Moreover, when we try and access
this memory in the sdl_reset_port routine we crash.
Resolution:
There are two fixes here:
Fix one - ensure that the correct handle is sent on the
reset_port message.
Fix two - ensure that for switched outgoing links we
don't open the HMOD until we receive the DIAL PORT message
For fix one we simplay add a line to sdl_reset_port to
ensure that in the reset port case (like the close port)
we set the port_handle to be the pcb->pcb_handle.
For fix two we add a test into vhs_register_station so
that vhs_hmod_open is only called if the port_type
not switched outgoing.
We then add a call to vhs_hmod_open to vhs_dial_port.
(3) JAGab68385
Missing flag in the streams definition.
Resolution:
Add flag to streams_info section of all kernel drivers.
(4) JAGab65528
The problem occurs under load when nch_sscp_receive() has
two NOTIFY messages on its normal request pending queue.
The routine loops round trying to process everything on
the queue. The first NOTIFY is sent out OK. However this
sets the flag 'LOCAL.norm_flow_rqs_blocked = TRUE'. This
means that the second NOTIFY is then placed back on the
queue by nch_df_sscp_send() resulting in a continuous loop
trying to empty the normal request pending queue.
Resolution:
Modify the while() test in nch_sscp_receive() that
processes the normal request pending queue so that it also
checks LOCAL.norm_flow_rqs_blocked and drops out when this
is TRUE. The end result of this change is that the first
NOTIFY is sent as at the moment, and we then drop out of
the queue processing and any further NOTIFYs or other MUs
on the queue are then dealt with when the NOTIFY RSP
returns.
(5) JAGab65397
Firmware problem:
It is possible for the state machine to remain in the
CLOSE_PEND state indefinitely because it expects only
timeout events when in this state. The firmware state
machine should declare an error and restart itself
when it remains in the CLOSE_PEND state too long.
Driver Issues:
From looking at the driver code and the traces it produced,
it is apparent the driver is not initiating any action with
the firmware if the link unexpectedly goes down (simulated
by disconnecting the cable between the 9000 and the modem).
The protocol between driver and firmware requires a message
exchange for the link to start up.
Resolution:
The fix is to make sure that the driver and firmware, once
they become 'unsynchronized', have a way to be
re-synchronized. This is done by:
A)
When the firmware hits an error condition which it does
not know how to handle, it will set a system error and
'jump' to the first line of the firmware code (i.e., first
line of main). This is done by timing out on inactivity in
the OPEN_PEND and CLOSE_PEND states of the firmware. The
declaration of system error will allow the firmware code
code to reset.
B)
To make sure that the driver will not be hung, the driver
code will start out with a credit of 2 when it initiates
data transfer with the card. This is to prevent situations
in which both the firmware and the driver are waiting for
each other to send a message. With the new credit
assignment during initialization, the driver will always
able to initiate action on the card. Since the code is
designed assuming only 1 outstanding message to the
firmware at a time, the driver has a credit check to make
sure the credit value is not greater than 2.
(6) JAGab65303
The problem occurs under load, when a temporary shortage of
internal buffers means that the software must queue an
incoming message (from the host) and deal with it later,
when a buffer has become available. The reason for the
problem is that the calculation of the RU length in the
APPN node counts the same MU twice, once when it arrives
(before it gets queued because there are no BUFFERs
available) and again once it has been dequeued (because a
BUFFER is now available). Specifically,
ntc_buffers_available() calls ntc_process_btu(), passing
the dequeued buffer. This calls ntc_segment_transfer()
which increments the partial_bui_size field. The same code
(from ntc_process_btu onwards) is called when the MU first
arrived so the size of the MU is counted twice!
Resolution:
The fix is to 'undo' the first addition of the incoming
message length to our running total of RU size if it turns
out that we have to queue the message for later processing.
Specifically, the fix decrements tc_cb->partial_biu_size in
ntc_segment_transfer() if posting is requested and this was
a non-BBIU segment. The process will be called again and
the partial_biu_size re-incremented when the buffer that
was posted for returns.
PHNE_19070:
(1) 4701429407
The problem is due to a code defect in the psi driver
when attempting to process multiple DMA transactions.
Resolution:
The fix implemented consists in processing 1 DMA
transaction at a time instead of processing queued DMA
transactions.
The DMA transactions are still queued but the DMA engine
processes only one transaction at a time. It does not
prefetch DMA transaction because we force it to stop and
generate an interrupt after having processed every
transaction.
When the driver gets the interrupt related to the
completion of a DMA transaction, it starts processing the
next DMA transaction in the queue.
(2) 4701425561
The Streams/UX subsystem on hp-ux 11.0 , unlike SVR4
streams, does not provide any form of locking when
accessing a streams Q. Thus, on HP-UX it is not safe to
perform a PUTQ to a stream from outside its context
(i.e. from the put or service routine of another queue).
Resolution:
The streams call PUT() does contend for ownership of a
given queue, because HP-UX guarantees that only a single
put or service routine for a queue will be run at one time.
Thus, to ensure the streams queues are protected we modify
the SNA code to:-
- issue put() rather than putq()
- have the put routine for the streams Q issue
the putq() to defer processing to the
service routine.
(3) 4701425355
Problem is that ACC stack is calling QLLC put routine from
interrupt context. QLLC module is not designed to cope with
this: all other drivers/stacks queue their messages in a
simple service routine so they can be sent upstream outside
interrupt context. We have nevertheless agreed that we
will add queuing to our QLLC module so that it works with
the new ACC X.25 driver.
Resolution:
Fundamental fix is to move from the put() routine to the
service() routine all the read-side processing in the QLLC
module. In practice this only affects M_PROTO messages.
Examination of the QLLC module code suggested that code
processing these messages in put() routine could simply be
removed -- provided the messages were then queued to the
service routine -- because the service routine already has
to handle them (via an FSM) in situations of buffer
shortage. Empirical testing bore this out.
So fix actually simplifies code by removing 'special case'
processing for data messages when there are buffers
available and no control messages queued in front of
them.
(4) 1653299073
The problem is caused by the corruption of the lan3 data
structures involved in DMA transactions by the psi0 DMA
transaction processing.
Resolution:
Changed the handling of DMA trasactions. The transactions
are still queued but the DMA engine processes only one
transaction at a time. It does not prefetch DMA
transaction because we force it to stop and generate an
interrupt after having processed a transaction. When the
driver gets the interrupt related to the completion of
a DMA transaction, it starts processing the next DMA
transaction in the queue.
PHNE_17819:
(1) 5003446971
Panic caused by attempting to dereference null pointer
while examining posted_list LQE in nbm_info structure to
see whether it is empty.
Resolution:
Add boolean flag to nbm_info to say whether posted list is
empty or not.
(2) 4701418707
The outgoing attach was being sent with the password
from the previously rejected incoming attach causing a
validation error.
Resolution:
Add code to copy the password from the START_TP signal into
the tcp_ptr in nrmsttp.c
(3) 1653305805
From the stack we can see that this a deadlock in the
kernel during snap stop processing. We grab a write lock
on vpr_entity_lock in vpr_stream_close() which we hold
across a number of calls, including the one to nba_term().
It is this lock we are trying to acquire in
vpr_route_ips_on_route() near the top of the stack trace.
Resolution:
We don't actually need to hold the vpr_entity_lock round
the call to nba_term() in vpr_stream_close(). So the fix
is just to release it before that call and reacquire it
afterwards.
(4) 1653293878
The TP is failing to start because the userid under which
it is running has been misconfigured so that it can't
retrieve its own group name. This may be due to local
access to the group file or with running NIS (Network
Information Service) to share user and group IDs across
more than one machine. There are two reasons for the
cryptic error logs recorded by SNAplus2:-
- Failure of the getpwuid() or getgrgid() system calls
was not logged as an error message.
- The VSM_AS_TP_FAILURE internal error code was not getting
put in the right part of the DLOAD_RSP_ERR message sent
from the Service Manager to the APPC Stub. This meant that
the APPC stub was misinterpreting it as an APPC sense code.
Resolution:
The root cause of the problem is to correctly configure the
Unix user/group under which the TP is to be run.
However changes to SNAplus2 have been made to improve the
logging in this area as follows:-
In vpm_build_user_info() in vr/vpmu.c we add error logs for
the cases where getpwuid() or getgrgid() system calls fail.
However, failure of these system calls leads to a path
failure. So to make sure these new error logs actually
reach the sna.err log file, we also modify
vlm_user_write_log() in vdiag/vlmuser.c so that even if we
fail to open a path we still attempt to send the datagram
containing the log (in addition to attempting to write it
locally).
In the error reply arm of vsm_rcv_dload_confirm() in
vr/vsmdload.c we put the error code in the dld_status field
rather than the ld_sense_data field of the DLOAD_RSP_ERR
message -- because this is where the vas_datagrams()
routine in the APPC Stub expects to find it. We also change
the exception logged in vsm_rcv_dload_confirm() from the
generic one, with its rather misleading reference to errno
to a new specific error.
Texts of the new logs are in the vdiag/*.txt files.
PHNE_17405:
(1) 5003441717
If the kernel initialisation fails, it is possible that
the snaperrlog process could hang - waiting for a signal
from the kernel which never arrives.
Resolution:
A code change has been made to ensure that ,if the
kernel initialisation fails, a failure notification is
sent to the snaperrlog process so it can exit
cleanly.
(2) 4701413054
Small timing window when there is an empty list of LULU
control blocks when processing SSCP_INIT_SIGNAL_NEG_RSP
ISP.
Resolution:
Code changed to check whether LULU list is empty before
trying to obtain first element of it.
(3) 4701399279
The PSI f/w header string was not changed with the
release of SNAplus2 as the f/w is common to both
SNAplus & SNAplus2.
Resolution:
- a new what string for the NIO firmware
- a new what string and a new compilation format for
the EISA firmware
The ']' character has been added at the beginning of
each PSI firmware library header line so that the
header can be recognized by the snapwhat command.
(4) 1653289686
TN3270 cliemt was locking up when the clear key was
entered because TN Server was passing the clear
command to the Host instead of processing it locally
(as is done in the Motif 3270 emulator for example).
Resolution:
Code changed to add check and special handling for the
clear key at the beginning of the TN Server SSCP inbound
MU processing.
(5) 1653289603
TN3270 client was receiving SSCP datas when the clear
key was entered because TN Server was passing the clear
command to the Host instead of processing it locally (as
is done in the Motif 3270 emulator for example).
Resolution:
Code changed to add check and special handling for the
clear key at the beginning of the TN Server SSCP inbound
MU processing.
PHNE_16758:
(1) 4701405316
Updated binaries provided for combined patching of
latest R6 release ,as documented in SR text.
(2) 4701399527
A Code change has been made to prevent Assert errors
occurring when a large USSMSG10 is received for an LU6.2
session .
The maximum amount of data permissible on the SSCP screen
has been increased to 2048 bytes, to ensure segmented data
on SSCP screen handled correctly.
(3) 1653279703
Code change made to fix a problem with Assert errors being
logged when an RJE workstation is started.
Code changed to correct the ASSERT - it should only be
produced if an application has opened the SSCP session and
is listening for RTM requests (RJE does not do this so it
should not be logged as an error).
(4) 1653276543
Code change to prevent 3270 session hang, due to NOTIFY
not sent.
The fix applied is to ensure that any pending NOTIFY
requests are flushed from the CH queue in the APPN node
when a CLOSE_SSCP message is received (indicating that
the emulator has been stopped).
(5) 1653273979
Enhancement to allow multiple PUs to be used on a secondary
leased link. This means that if an SDLC port is connected
to a leased line, you can have multiple LS's active over
the port at the same time.
(6) 1653267179
The problem is basically that if you specify AP_SAME on the
ALLOCATE verb but did not configure user validation, then
we will send a user ID consisting of 10 NULLs.
A code change has been made, and the following behavior
applies when AP_SAME is used :
case 1: a TP on Unix invokes a remote TP: the outgoing
Allocate will contain a userID subfield, set to the Unix
user ID
the TP is running under;
case 2 :a TP on Unix invokes several remote TPs:see case 1;
case 3 : multiple conversations, where an INVOKED TP issues
an ALLOCATE:in that case, the outgoing Allocate will
include the
same level of validation which was on the ATTACH that
invoked that TP.
PHNE_15937:
(1) 5003398354
Code changed to ensure that if the user specifies any other
parameters, they match those used on the initial define.
Produce an error code otherwise.
(2) 4701396374
Code changed to allow the node to start if it finds a
TN Client configured with unrecognised hostname, but
generates an error log which tells the user of the failure.
(3) 4701395459
This was an incorrect ASSERT which has been removed. It is
a benign problem, but produces annoying error logs and
console messages.
(4) 4701392670
The LAN logger component (which handles central logging)
incorrectly registered itself with the service manager as a
server. This means that a server could end up twice in the
service table (for example, once as a backup, then again as
a master server). This lead to extremely unpredictable and
unreliable client/server operation. Code change made to
prevent this incorrect registering.
(5) 1653261669
Send a signal to the host when firmware is ready (backplane
and frontplane are initialized)
Remove debug trace from msgbuf (opt1:)
PHNE_14392:
(1) 4701386227
Fixed problems in SDLC driver and firmware.
SR:
8606166322 8606151854 8606144657 8606130719 8606128605
8606128040 8606127677 8606111815 8606108556 8606106415
8606105945 8606105839 8606105164 8606104163 5003467290
5003446971 5003441717 5003398354 4701429621 4701429407
4701425561 4701425355 4701418707 4701413054 4701405316
4701399527 4701399279 4701396374 4701395459 4701392670
4701386227 1653305805 1653299073 1653293878 1653289686
1653289603 1653279703 1653276543 1653273979 1653267179
1653261669
Patch Files:
/opt/sna/conf/lib/libpsi0.a
/opt/sna/conf/lib/libpsi1.a
/opt/sna/conf/lib/libsixd.a
/opt/sna/conf/lib/libsixl.a
/opt/sna/conf/lib/libsixm.a
/opt/sna/conf/lib/libsixp.a
/opt/sna/conf/lib/libsixq.a
/opt/sna/conf/lib/libsixs.a
/opt/sna/sdlc.dlf
/opt/sna/sdlc.pbs
/opt/sna/bin/snaptnsrvr
what(1) Output:
/opt/sna/bin/snaptnsrvr:
HP92453-02A.10.00 HP-UX SYMBOLIC DEBUGGER (END.O) $R
evision: 74.03 $
]R6.10.20.101 SNAplus2 R6 TN Server
] (PHNE_17405 : 99/01/11 17:27:05)
]
/opt/sna/conf/lib/libpsi0.a:
]R6.10.20.105 SNAplus2 R6 NIO PSI driver
] (PHNE_20211 : 99/11/05 07:29:46)
]
/opt/sna/conf/lib/libpsi1.a:
]B.10.20.102 SNAplus2 R6 EISA PSI driver
] (PHNE_19407 : 99/08/16 07:41:48)
]
/opt/sna/conf/lib/libsixd.a:
]R6.10.20.102 SNAplus2 R6 NDLC to DLPI Mapping
] (PHNE_20738 : 99/11/30 17:33:31)
]
/opt/sna/conf/lib/libsixl.a:
]R6.10.20.107 SNAplus2 R6 SDLC in the Kernel
] (PHNE_21213 : 00/02/01 13:36:20)
]
/opt/sna/conf/lib/libsixm.a:
]R6.10.20.101 SNAplus2 R6 NDLC to DLPI Mapping
] (PHNE_19407 : 99/08/06 14:16:03)
]
/opt/sna/conf/lib/libsixp.a:
]R6.10.20.102 SNAplus2 R6 QLLC Module
] (PHNE_19407 : 99/08/06 14:20:01)
]
/opt/sna/conf/lib/libsixq.a:
]R6.10.20.101 SNAplus2 R6 QLLC Module
] (PHNE_19407 : 99/08/06 14:21:09)
]
/opt/sna/conf/lib/libsixs.a:
]R6.10.20.129 SNAplus2 R6 Router in the kernel
] (PHNE_22732 : 00/10/26 13:44:24)
]
]R6.10.20.122 SNAplus2 R6 APPN kernel library routin
es
] (PHNE_22732 : 00/10/26 13:37:08)
]
/opt/sna/sdlc.dlf:
SNAplus2 EISA FW v2.7
(99/07/30 12:58:42)
/opt/sna/sdlc.pbs:
]SNAplus2 NIO FW v2.1
](98/11/13 11:58:22)
cksum(1) Output:
2390782579 204416 /opt/sna/bin/snaptnsrvr
3096725199 63500 /opt/sna/conf/lib/libpsi0.a
3450841052 47488 /opt/sna/conf/lib/libpsi1.a
2028436616 172652 /opt/sna/conf/lib/libsixd.a
853364514 360508 /opt/sna/conf/lib/libsixl.a
2260423153 2540 /opt/sna/conf/lib/libsixm.a
656500477 142452 /opt/sna/conf/lib/libsixp.a
1648757111 2504 /opt/sna/conf/lib/libsixq.a
2686788375 3026508 /opt/sna/conf/lib/libsixs.a
3715532193 105228 /opt/sna/sdlc.dlf
3918812582 172212 /opt/sna/sdlc.pbs
Patch Conflicts: None
Patch Dependencies: None
Hardware Dependencies: None
Other Dependencies: None
Supersedes:
PHNE_14392 PHNE_15937 PHNE_16758 PHNE_17405 PHNE_17819 PHNE_19070
PHNE_19407 PHNE_20211 PHNE_20738 PHNE_21213
Equivalent Patches: None
Patch Package Size: 4270 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_22732
5a. For a standalone system, run swinstall to install the
patch:
swinstall -x autoreboot=true -x match_target=true \
-s /tmp/PHNE_22732.depot
By default swinstall will archive the original software in
/var/adm/sw/patch/PHNE_22732. 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_22732.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_22732.depot of=/dev/rmt/0m bs=2k
Special Installation Instructions:
Stop SNA daemon before installing patch (snap stop). After
installing the patch start the SNA daemon (snap start).
-----End of Document ID: PHNE_22732------------------------------------------
Document ID: PHNE_21213
Date Loaded: 20010226
Title: s700_800 10.20 R6.10.20 SNAplus2 Link cumulative patch
Patch Name: PHNE_21213
Patch Description: s700_800 10.20 R6.10.20 SNAplus2 Link cumulative patch
Creation Date: 00/03/29
Post Date: 01/02/26
Hardware Platforms - OS Releases:
s700: 10.20
s800: 10.20
Products:
SNAplus2-Link R6.10.20
Filesets:
SNAplus2-Link.SNAP2-LINK,R6.10.20.000
SNAplus2-Link.SNAP2-LINK,R6.10.20.010
Automatic Reboot?: Yes
Status: General Superseded
Critical:
Yes
PHNE_21213: PANIC HANG
PHNE_20211: PANIC
PHNE_19407: HANG PANIC
PHNE_19070: HANG
PHNE_17819: PANIC HANG
PHNE_17405: HANG PANIC
PHNE_16758: HANG
Path Name: /hp-ux_patches/s700_800/10.X/PHNE_21213
Symptoms:
PHNE_21213:
(1) JAGac95609/8606130719
System panic after call to npo_sess_limit_data_lock_mgr().
(2) JAGac86152/8606128605
LU Type 2 is inactive on the HP side but active on the IBM
side. No DACTLU or segmentation error is seen in the DLC
trace, but sna.err file shows the following:
APPN Message 512 - 171, Subcode: 0 - 10
Session segmentation error.
....
RU : (3 bytes)
(3) JAGac78841/8606128040
System panics after receiving an UNBIND during initialise
session limits processing. The stack shows that
nba_mm_free was called from nlu_remove_mode. A similar
problem was also reported in JAGac95609.
(4) JAGac78479/8606127677
Cannot reliably stop SDLC link station or port.
Once the port gets stuck in the stopping state
the sna has to be recycled.
(5) JAGab74691/8606105945
3270 user gets PROG checks 432 (bracket race) when typing
ahead together with ASSERT in vbaccess line 324 and log 52
(internal error copying buffer). User needs to do reset on
3270 to recover.
PHNE_20738:
(1) JAGab83920/8606111815
Customer's QLLC link fails to come up due to error in the
XID exchange. The sna.err log shows XID 3 error during
negotiation.
(2) JAGab74185/8606105839
An LUA application receives an UNBIND indication from an
established LU-LU session. It responds with RSP.UNBIND and
encounters the following error:
primary return code: LUA_STATE_CHECK (0x0200)
secondary return code: LUA_NO_RUI_SESSION(0x81000000)
(3) JAGab65399/4701429621
Dependent APPC LU does not get BIND from VTAM after the
link is re-established following an outage.
(4) JAGab25510/5003467290
Token Ring connection hangs when frames exceeding the
largest frame size returned in RIF are dropped by the
network.
PHNE_20211:
(1) JAGab79003/8606108556
K580 system panics on reboot with the following error
messages:
System Panic:
9245XB HP-UX (B.10.20) #1: Sun Jun 9 06:31:19 PDT 1996
panic: (display==0xb800, flags==0x0) nio_initialize :
l_io_vec.iov_base == NULL
PC-Offset Stack Trace (read across, most recent is 1st):
0x00276f44 0x003fdab0 0x00404968 0x001297c4 0x00240ae8
0x002a7ea8 0x002a6ae4 0x00215088 0x002147e0 0x00295368
0x00295444 0x00295444 0x00295444 0x002951c0 0x00295d20
0x002f316c 0x000c7014 0x00183960
End Of Stack
It was not possible for the kernel to find a process
that caused this crash.
jCj1D
Dumpsys() called
(2) JAGab75469/8606106415
When starting an SDLC link the system panics with
following stack trace:
stack trace for event 0
crash event was a panic
FUNC
panic+0x10
report_trap_or_int_and_panic+0xe8
trap+0xa48
$RDB_trap_patch+0x20
sna_sdlc_vba_ips_putb+0x18
sdl_send_set_mode_frame+0x138
sdl_psecs+0xf88
sdl_prtmg+0x106c
sdl_wrxfr+0x5a8
sdl_receive_proc+0x80
sna_sdlc_nba_dispatch_input+0x254
sna_sdlc_nba_dispatch_process+0xa4
sna_sdlc_nba_scheduler+0x11c
vsi_stream_uw_service+0x3e0
sq_wrapper+0xb8
str_sched_mp_daemon+0x114
str_sched_daemon+0x1f4
main+0x97c
$vstart+0x34
(3) JAGab73055/8606105164
While running SNAplus2 R6 on HPUX 11 a link failure
occurred.
The sna.err log file recorded message 4096 - 13
(ASSERT: File name = ../../p/vhlwr/vhshmod.c ).
This caused the link to go down for one
minute, and disrupting the current file transfer.
Following the ASSERT, the sdlc driver is trying to
do ten consecutive svphrx() calls.
The last 9 calls will fail. The SDLC driver calls
svphclos() to stop the link.
(4) JAGab71519/8606104163
This system panic occurred on a H20 running 10.20 with
128MB.
panic+0x10
report_trap_or_int_and_panic+0xe8
trap+0xa48
$call_trap+0x20
nsm_delete_session_id+0x104
nsm_cleanup_lu_lu_session+0x7b8
nsm_fsm_status+0x1d4c
nsm_process_deactivate_session+0x140
nsm_process_record_from_rm+0x1a8
nsm_queue_handler+0x68
nba_dispatch_process+0x114
nba_scheduler+0x208
vpr_stream_uw_svc+0x58c
sq_wrapper+0xb8
str_sched_up_daemon+0x2b0
str_sched_daemon+0xf4
main+0x974
$vstart+0x34
PHNE_19407:
(1) JAGab71689
The following message is noted periodically in sna.err
file:
10:07:29 EDT 09 Aug 1999 4096-5(0-0) P (UH2010D3)
PID 3733 (snaperrlog)Log parameter mismatch.
Message number = 512 - 137
The message 512 - 137 then follows with a question mark
for the sense code.
(2) JAGab71162
Symptoms of problem:
After installing patch, PHNE_19527, and selecting
Diagnostics, node tracing, sdlc level 2 tracing in
xsnapadmin, activated the node. Then, ls went into
starting status, then retry pending. Several seconds
later, the system panicked. The following stack was
produced when the machine crashed:
panic+0x14
report_trap_or_int_and_panic+0x4c
trap+0xef4
$RDB_trap_patch+0x38
sdl_reset_port+0x13c
sdl_poll_port+0x3ec
sdl_hms_ctl_proc+0xb4
sdl_receive_proc+0x14c
sna_sdlc_nba_dispatch_input+0x254
sna_sdlc_nba_dispatch_process+0xa4
sna_sdlc_nba_scheduler+0x11c
sna_sdlc_vsi_stream_uw_service+0x3e0
sq_wrapper+0x90
str_sched_up_daemon+0x440
str_sched_daemon+0x1f0
main+0x6e0
$vstart+0x34
$locore+0x90
The following asserts were also seen in the console log:
WARNING: SNA ASSERT:
17:10:45 25 AUG 1999
File: ../../p/vsdlc/sdlcsigi.c
Line: 1495
Condition: pcb->resetting == FALSE
WARNING: SNA ASSERT:
17:11:15 25 AUG 1999
File: ../../p/vsdlc/sdlcsigi.c
Line: 1375
Condition: pcb->alert != NULL
(3) JAGab68385
Code inspection has shown that the SNAplus2 Kernel drivers
do not have the MGR_IS_MP flag set on the streams_info
structure. This has not caused problems but may affect
performance on MP systems.
(4) JAGab65528
The customer has been running SNAplus2 version R6.11.00
with PHNE_17229 for about a month with no problems. Today,
after about 20 3270 users become active the system hangs.
Needed to do a TOC to recover. The following stack trace
yielded from TOC:
nba_get_q_head+0x0
nch_sscp_receive+0x9b8
nba_dispatch_input+0x298
nba_dispatch_process+0xa4
nba_scheduler+0x1b0
vpr_stream_lr_svc+0x134
sq_wrapper+0x90
str_sched_up_daemon+0x440
str_sched_daemon+0x1f0
main+0x6e4
(5) JAGab65397
SNAplus2 R6.10.20 SDLC link fails to start if DSR is not
present when link station is started. Only recovery is to
reboot the system and ensure that modem signals are present
before starting the link. Loss of DSR causes the same
problem.
The following errors are logged:
SDLC Message 768 - 17, Subcode: 1 - 11
Log category: EXCEPTION Cause Type: External
System: dqserv1
DSR was not active when activating port.
Return code = 0x0003
Cause: An error occurred on a port. The port is configured
as Non-switched but DSR was not present.
Action: Check whether the configuration setting of
non-switched is correct.
If the port is correctly configured, check the modem and
link hardware.
Check other messages for further diagnostics.
SDLC Message 768 - 94, Subcode: 0 - 11
Log category: EXCEPTION Cause Type: External
System: dqserv1
SDLC port device driver reported an error.
DLC name = SDLC0
Port name = mapport
Port number = 0x00000000
Return code = 0x0003
Detailed return code = 0x0020
Cause: An error occurred on an SDLC port. The detailed
return code provides more information on the error,
as follows:
0x0020 DSR failure
0x0021 General hardware failure
0x0022 Modem power off
0x0023 CTS failure between frames (4 wire)
0x0024 CD failure between frames (4 wire)
Action: Check the detailed return code shown; check for
previous exception messages providing more information
about the failure.
(6) JAGab65303
The customer has problems printing a long file from a host.
Gets the following error:
---------------- 19:34:03 SAT 21 May 1999------------------
APPN Message 512 - 452, Subcode: 0 - 10
Log category: EXCEPTION Cause Type: SNA
System: cnbv
LU type 0, 1, 2, or 3 session ended abnormally - protocol
error.
Sense code = 0x10020000
LFSID = 018E0000
Cause: An LU type 0, 1, 2, or 3 session ended abnormally
(with the sense code shown) because of a protocol error.
Action: Contact network support personnel with details of
the problem.
The sense code 0x10020000 means 'RU Length Error'.
The problem was not seen when similar files were printed
with SNAplus.
PHNE_19070:
(1) 4701429407
Lan performance degraded when attempting to start an SDLC
psi card on a T600 system.
(2) 4701425561
R6.11.00 on a V-Class system: After several hours of APPC
activity, (about 10 incoming allocates per second), APPC
TP's fail to load, with error messages 512-257(0-10)
logged.
In addition, a system panic has occured while the user
APPC application was terminated.
Although these two problems are very different by nature,
it has been determined that they are closely related due
to internal mechanisms in SNAPlus2 in its communication
via Streams putq messages.
The stack trace for the panic was as follows:
panic+0x14
report_trap_or_int_and_panic+0x80
trap+0xa8c
nokgdb+0x8
putq_owned+0x2a0
putq+0x1c
vba_track_putq+0x4c
vpr_stream_output_msg+0x40c
vpr_delete_entity+0x43c
vpr_stream_close+0x1a8
close_wrapper+0x6c
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
exit+0x324
rexit+0x28
syscall+0x480
$syscallrtn+0x0
(3) 4701425355
While running reliability tests with new ACC driver and
SNAplus2 the lab hit a system hang a couple of times when
using qllc over X25.
(NB: ACC use their own X.25 stack which uses nli2zcom
module.)
When examining the TC with q4 we found the system stuck at
same routine, sna_q_v0_get_rw_lock, in libsixp.a. Here is
how the q4 stack looks.
sna_q_v0_get_rw_lock+0xc8
vql_stream_read_input+0xdc
putnext+0x50
N2Z_F_data_ind+0x38
N2z_iev_pass_data_up+0x114
N2z_ReadEvent_Recvd+0x209c
Zc_putq+0x5c
nacc0_receive_data+0x140
(4) 1653299073
After upgrading from R4.4 to R6.10.20 on a T600 system,
the SDLC link could no longer be activated and the lan
performance is severly degraded.
When the SNA resources are activated, the following error
messages are logged:
----------------------- 15:32:40 WET 19 mars 1999
SDLC Message 768 - 107, Subcode: 0 - 11
Log category: EXCEPTION Cause Type: External
System: centurix
SDLC write timer retry limit has been exceeded.
DLC name = SDLC0
Port name = SDLCP0
Port number = 0x00000000
Cause: An attempt to transmit a frame using an SDLC port
has timed out.
This may indicate a problem with the SDLC adapter or with
the modem and cabling. The port is stopped.
Action: Check the modem and communications link.
----------------------- 15:32:40 WET 19 mars 1999
APPN Message 512 - 60, Subcode: 0 - 10
Log category: PROBLEM Cause Type: SNA
System: centurix
An active link station has failed.
Port name = SDLCP0
LS name = SDLCL0
Adjacent CP name = 0000000000000000000000000000000000
Cause: An active link station has failed
----------------------- 15:33:29 WET 19 mars 1999
SDLC Message 768 - 17, Subcode: 1 - 11
Log category: EXCEPTION Cause Type: External
System: centurix
DSR was not active when activating port.
Return code = 0x0003
Cause: An error occurred on a port. The port is configured
as Non-switched but DSR was not present.
Also the syslog.log is filled up with the messages
'lan3_process_read_completion: Received out of sequence'
The impact of all the above is that the LAN card becomes
very slow to the point where the system becomes unusable.
The only way to recover LAN traffic is to reboot the system
without starting SNA at all.
PHNE_17819:
(1) 5003446971
Data page fault panic in nbm_free_buffer while running
simple SNA tests over two LAN interfaces between the three
machines running SNAplus2.
(2) 4701418707
When using CPI-C without side information, outgoing
attaches sometimes fail because validation has been
unintentionally turned on.
(3) 1653305805
One processor on a two processor box running R6 over 10.20
hangs which then causes cmcld to TOC the box to preserve
system integrity.
Top of stack for hanging process is:
FUNC PC
v0_get_rw_lock+0xb8 0.0x3cc4a8
vpr_route_ips_on_route+0x40 0.0x4094e0
vds_rcv_buffers_available+0x1a0 0.0x3e1720
vds_receive_proc+0x674 0.0x3e47fc
nba_dispatch_input+0x298 0.0x5af050
nba_dispatch_process+0xa4 0.0x5af184
nba_schedule_process+0x134 0.0x5af5ec
nba_send_ips+0x308 0.0x5afd3c
(4) 1653293878
Invokable TP failing to start with following error messages
logged.
------------- 10:52:14 GMT 10 Feb 1999 ----------------
NODE Message 16384 - 0, Subcode: 10 - 10
Log category: EXCEPTION Cause Type: Internal
System: LR1875
Internal system error. Errno = 7
Action: Provide support services with the audit and error
log files, and trace files if available.
------------- 10:52:14 GMT 10 Feb 1999 ----------------
APPN Message 512 - 257, Subcode: 0 - 10
Log category: PROBLEM Cause Type: Config
System: LR1875
Dynamic load of TP failed.
Sense code = 0x07000000
LU alias = DFKC
TP name = lr229bci
PHNE_17405:
(1) 5003441717
The snaperrlog process can be left lying around when the
SNAplus2 daemon is not started. Attempting to restart the
SNAplus2 software using 'snap start' will fail (because the
snaperrlog process is still there from a previous run).
(2) 4701413054
System panic - Data Page Fault at
nsm_process_record_from_ss+130
(3) 4701399279
The PSI firmware header is not recognized by the snapwhat
command.
(4) 1653289686
If using a TN3270 (not E) client and hit the clear
key while TN Server is presenting an SSCP screen,
then the client will lock up.
The host may respond with an error message.
(5) 1653289603
If using a TN3270 (not E) client and hit the clear key
while TN Server is presenting an SSCP screen, TN Server
forwards the clear key to the host(sends an empty RU
on SSCP-LU session).
The host may respond with an error message.
PHNE_16758:
(1) 4701405316
Updated binaries required for patching the latest
R6 release of SNAplus2.
(2) 4701399527
Assert errors are produced when the host sends a USSMSG10
screen to a LU configured for LU6.2. The ASSERTS are in
fact benign, and will cause no problems with the integrity
of the system.
The ASSERTs only occur when the USSMSG10 screen is
segmented, and greater than around 500 bytes in size.
(3) 1653279703
Assert errors logged when RJE workstation is started
due to RTM request being received.
This has no affect on opperation other than bad
entries in the error log.
(4) 1653276543
3270 session can hang, even if you stop and restart the
snap3270 emulator.
If you take a trace of the problem, you will see that a
NOTIFY is not sent when the 3270 emulator is stopped or
started.
(5) 1653273979
Enhancement to allow multiple PUs to be used on a secondary
leased link. This means that if an SDLC port is connected
to a leased line, you can have multiple LS's active over
the port at the same time.
(6) 1653267179
An Application can fail to start a remote LU62 transaction,
because an invalid user ID is specified on the Attach,
when AP_SAME is specified on the ALLOCATE verb.
PHNE_15937:
(1) 5003398354
If you issue 'snapadmin define_local_lu' for an LU which
is already defined, only the attach routing data and the
description field are updated - all other parameters are
ignored - however, the snapadmin command does not indicate
this but gives a successful return message.
(2) 4701396374
Node fails to start if TN Client configured with
unrecognised hostname.
(3) 4701395459
The following assert message is logged to the console,
syslog file and sna log files.
Assert ips->cont_size >= MU_CONT_SIZE from vtc.c
(4) 4701392670
When in client /server configuration, various ASSERT
messages recorded in the sna.err log file from the SLIM
component, followed often by a crash of the SLIM.
This causes general unpredictable behaviour of the system
when the master server goes down and is restarted.
(5) 1653261669
SDLC link shows DISABLED after restart of SNAPLUS2 daemon
PHNE_14392:
(1) 4701386227
Unable to start SDLC Eisa cards
Defect Description:
PHNE_21213:
(1) JAGac95609/8606130719
The analysis of the partial dump points to the
following sequence of events that led to the panic:
- STOP_NODE quiesce comes into the NOF - goes to TRS,
then the first PS
- PS COPR builds and sends RESET_SESSION_LIMITS(all) to
itself
- PS COPR locks all the modes, and issues ALLOCATE to PS
(not traced)
- PS sends ALLOCATE_RCB to RM
- we cannot contact remote, so RM cannot activate a
session
- ALLOCATE_RCB(failure) comes back to PS
- PS completes its processing of ALLOCATE
- PS calls nlu_tidy_up_plu_and_mode, which removes a
mode CB ***bug***
(note that the assert on mode state in nlu_remove_mode
would get hit here).
- PS returns the ALLOCATE verb (not traced)
- PS COPR detects the failure of the ALLOCATE
- PS COPR tries to unlock all modes but none exist.
Asserts on mode_state and mode locks seen in the dump
also support this explanation.
Resolution:
A check is made on the mode lock before freeing the mode.
The mode CB is freed by npo_reset_sess_limit_proc
instead of npb_allocate_proc.
(2) JAGac86152/8606128605
The router kept the LU 'offline' until +RSP to a NOTIFY was
received. While the LU was 'offline' no segmentation
checking was done and an incoming EBIU (from the end of the
VTAM Screen) was ignored. This kept us 'in segment' and
caused subsequent NOTIFY +RSP and a BBIU to be processed
with an error. The IBM side meanwhile considers the LU to
be online since it received no indication of a problem.
Resolution:
The fix is to ensure that even when we are offline we
still clear the in_biu flag when we see an EBIU flag.
(3) JAGac78841/8606128040
In certain race cases the mode control block was being
released to memory twice leading to the panic.
Resolution:
A major rework of the mode control block handling code was
performed to carefully check and remove mode control blocks
at the correct time. The mode lock is checked before
freeing the mode, so that npb_allocate_proc does not free
the mode CB, but npo_reset_sess_limit_proc does.
(4) JAGac78479/8606127677
An internal message is being discarded during the close
processing of a link. The problem is intermittent due
to a race condition.
Resolution:
Changed code to eliminate discarding of internal messages
during close processing.
(5) JAGab74691/8606105945
The internal error (bracket race) was caused by
bad SNA data coming from the host (EB BC followed by
EC CD) and the user (or possibly HLLAPI) typing ahead.
The ASSERT that gets generated is actually harmless.
Resolution:
The bracket race is avoided by working around the bad SNA
data sent by the host (removed CD from EC). The ASSERT was
corrected by zeroing a floating length field.
PHNE_20738:
(1) JAGab83920/8606111815
The SNAplus2 node carefully checks the ABM support fields
on an XID. Unlike previous versions of SNAplus, we are
now being very restrictive regarding the particular
combination of ABM support flags we let through. Whilst
we are following the SNA Formats manual correctly, this
does cause interoperability problems with some hosts.
In this circumstance we have decided to relax the
checks on the ABM support flags, to allow
interoperability with other hosts.
Resolution:
Remove test that compares ABM support flags on XID.
(2) JAGab74185/8606105839
The problem is caused by a STATUS_SESSION(NO_SESSION,
LU_INACTIVE) followed by an CLOSE_PLU_SLU_SEC_RQ.
The CLOSE causes a dummy UNBIND to be built and
queued, but the CLOSE kills the session between
the RUI_BID returning and the subsequent RUI_READ.
Resolution:
Check the reason for the CLOSE - if it is due to a LINK
error or because the PU or LU are inactive, then simply
kill the session - don't send the UNBIND down to the
application.
(3) JAGab65399/4701429621
If CH (Conventional Half-session) receives a segmented
logon screen to an off-line LU, for example a dependent
LU6.2 LU, CH may send an invalid response or, more likely,
no response at all. This could potentially cause problems
when trying to use APPC over that LU.
Resolution:
The nch_sscp_receive now stores the RH from the BBIU
(!EBIU) in the SSCP section of local data. When the EBIU
arives, the RH is copied in and it is turned round as a
negative RSP.
(4) JAGab25510/5003467290
SNAplus2 does not negotiate down the maximum BTU size
from the largest frame size received in the RIF on the
TEST_RSP (route discovery frame) received from the
token ring driver.
Resolution:
Correct the code to process the RIF before sending the size
back to SNAP APPN.
PHNE_20211:
(1) JAGab79003/8606108556
The driver code during nio_initialize checks for NULL IOVAs
returned from sio_map(). The psi0 driver will panic if
sio_map returned an IOVA of 0. But 0 is a valid IOVA;
therefore, psi0 should not panic for NULL IOVAs.
Resolution:
Fix is to remove the panic on NULL IOVAs after sio_map()
calls. Also in the step data structure, invalid IOVAs are
redefined to be -1 (void* 0xffffffff) instead of 0. Also,
change all checks for 0 IOVAs to be -1 IOVAs.
(2) JAGab75469/8606106415
When a SNRM retry is received very quickly after the
initial SNRM such that it crosses with the outgoing UA,
SNAP-LINK may crash because it does not have a valid
frame buffer.
Resolution:
Before sending a UA for a SNRM retry, check to see if the
frame_buffer used for UA's is present or not. If not, it
must be in the stub, so ignore the incoming SNRM retry.
(3) JAGab73055/8606105164
Problem is that we are accessing data shared between
normal context and call back context (hence typically
interrupt context) outside the correct locking.
We need to keep the lock on vhs_data_lock whenever we
update data in the pcb_shared_data area of the
port control block. We had a window where a TX was
issued at the same time as a RX completed and so
both bits of code tried to set up the next frame to
RX and got confused.
Resolution:
The fix is to reorder the code to make all the changes
to pcb_shared_data area inside the locked section
of code.
(4) JAGab71519/8606104163
In certain circumstances RM will be asked to delete an
SCB that was created by another instance of RM. If
this happens then we can assert or crash when
trying to delete the session.
Resolution:
Fix is to store the process ID of the RM instance that
creates the SCB on the SCB, then when RM receives a
DEACTIVATE_CONV_GROUP (which is routed from the NOF using
the LU name/alias field) it can check that the SCB was
created by this instance of RM and reject the signal
(with new secondary return code NAP_LUNAME_CGID_MISMATCH).
PHNE_19407:
(1) JAGab71689
From the code it appears that there is not really a
parameter mismatch, but it looks as though the problem is
due to us trying to log more text than we actually allow.
We are limited by a 600 byte array of log text in
nba_pd_print_var.
Resolution:
The log parameters are limited to 600 bytes to allow all of
the log datagram to fit in a 1k buffer for use by the SLIM.
Consequently, we can't change this 600 byte limit.
Instead, for the particular log mentioned in this defect,
we should ensure that the sense code gets put into the
buffer before the error data (that way we will ensure we
get all of the sense code). This will also stop the
erroneous messages in the log file as we will be logging
all of the parameters.
(2) JAGab71162
Cause of problem:
Having looked at the dump file it appears that the root
cause of this crash is down to a timing problem:
For switched links we send a REGISTER_STATION message
from SNAP LINK to the HMOD stub. The HMOD receives
this message, sends a response and issues an
svphopen call to the actual HMOD. Upon receiving the
REGISTER_STATION response SNAP LINK sends down a DIAL
PORT message. The HMOD doesn't do anything with
this DIAL PORT - it simply sends a response back
immediately. When the HMOD open routine comes back
(via the HMOD call back) the HMOD stub sends a POLL
PORT message which indicates that we have successfully
raised DSR.
SNAP LINK must get the DIAL PORT response before the POLL
PORT.
However, if the HMOD open returns prior to the DIAL PORT
response being sent, SNAP LINK will decide this is an
error and issue a RESET PORT message.
Normally we don't see this as the svphopen takes long
enough to come back that we have processed the DIAL
PORT. However, turn on tracing and the SNAP LINK/HMOD
processing takes longer and there is a chance that we
will get the svphopen back sooner than the DIAL PORT
response (note that the customer hit this timing
window with just SDLC level 2 trace - to reproduce
it we had to turn on internal trace in the SDLC
driver as well).
The reason the box is actually crashing is even more
convoluted:
The reset port message that we send down (which is
built on top of an alert held on the port control
block in SNAP LINK) doesn't have the correct
port_handle put onto it. Consequently when we get the
reset_port response we assume that the port control
block has been destroyed and we simply free off the
reset port message. Unfortunately this leaves us
in a bad state:
- Firstly the resetting flag on the pcb is wrong - it
is left as resetting == TRUE.
- Secondly, because the reset port is freed off, this
frees the alert stored on the pcb.
The first assert is occurring because SNAP LINK issues
reset port again to reset the port group. At this point
we spot that the restting flag is wrong.
The second assert happens when we are doing a retry of
the LS - the same timing problem as before happens
meaning we try and send a reset port using the alert
held on the pcb. Unfortunately this has been set to NULL
(hence the assert) because of our failure to reconcile
the reset port response. Moreover, when we try and access
this memory in the sdl_reset_port routine we crash.
Resolution:
There are two fixes here:
Fix one - ensure that the correct handle is sent on the
reset_port message.
Fix two - ensure that for switched outgoing links we
don't open the HMOD until we receive the DIAL PORT message
For fix one we simplay add a line to sdl_reset_port to
ensure that in the reset port case (like the close port)
we set the port_handle to be the pcb->pcb_handle.
For fix two we add a test into vhs_register_station so
that vhs_hmod_open is only called if the port_type
not switched outgoing.
We then add a call to vhs_hmod_open to vhs_dial_port.
(3) JAGab68385
Missing flag in the streams definition.
Resolution:
Add flag to streams_info section of all kernel drivers.
(4) JAGab65528
The problem occurs under load when nch_sscp_receive() has
two NOTIFY messages on its normal request pending queue.
The routine loops round trying to process everything on
the queue. The first NOTIFY is sent out OK. However this
sets the flag 'LOCAL.norm_flow_rqs_blocked = TRUE'. This
means that the second NOTIFY is then placed back on the
queue by nch_df_sscp_send() resulting in a continuous loop
trying to empty the normal request pending queue.
Resolution:
Modify the while() test in nch_sscp_receive() that
processes the normal request pending queue so that it also
checks LOCAL.norm_flow_rqs_blocked and drops out when this
is TRUE. The end result of this change is that the first
NOTIFY is sent as at the moment, and we then drop out of
the queue processing and any further NOTIFYs or other MUs
on the queue are then dealt with when the NOTIFY RSP
returns.
(5) JAGab65397
Firmware problem:
It is possible for the state machine to remain in the
CLOSE_PEND state indefinitely because it expects only
timeout events when in this state. The firmware state
machine should declare an error and restart itself
when it remains in the CLOSE_PEND state too long.
Driver Issues:
From looking at the driver code and the traces it produced,
it is apparent the driver is not initiating any action with
the firmware if the link unexpectedly goes down (simulated
by disconnecting the cable between the 9000 and the modem).
The protocol between driver and firmware requires a message
exchange for the link to start up.
Resolution:
The fix is to make sure that the driver and firmware, once
they become 'unsynchronized', have a way to be
re-synchronized. This is done by:
A)
When the firmware hits an error condition which it does
not know how to handle, it will set a system error and
'jump' to the first line of the firmware code (i.e., first
line of main). This is done by timing out on inactivity in
the OPEN_PEND and CLOSE_PEND states of the firmware. The
declaration of system error will allow the firmware code
code to reset.
B)
To make sure that the driver will not be hung, the driver
code will start out with a credit of 2 when it initiates
data transfer with the card. This is to prevent situations
in which both the firmware and the driver are waiting for
each other to send a message. With the new credit
assignment during initialization, the driver will always
able to initiate action on the card. Since the code is
designed assuming only 1 outstanding message to the
firmware at a time, the driver has a credit check to make
sure the credit value is not greater than 2.
(6) JAGab65303
The problem occurs under load, when a temporary shortage of
internal buffers means that the software must queue an
incoming message (from the host) and deal with it later,
when a buffer has become available. The reason for the
problem is that the calculation of the RU length in the
APPN node counts the same MU twice, once when it arrives
(before it gets queued because there are no BUFFERs
available) and again once it has been dequeued (because a
BUFFER is now available). Specifically,
ntc_buffers_available() calls ntc_process_btu(), passing
the dequeued buffer. This calls ntc_segment_transfer()
which increments the partial_bui_size field. The same code
(from ntc_process_btu onwards) is called when the MU first
arrived so the size of the MU is counted twice!
Resolution:
The fix is to 'undo' the first addition of the incoming
message length to our running total of RU size if it turns
out that we have to queue the message for later processing.
Specifically, the fix decrements tc_cb->partial_biu_size in
ntc_segment_transfer() if posting is requested and this was
a non-BBIU segment. The process will be called again and
the partial_biu_size re-incremented when the buffer that
was posted for returns.
PHNE_19070:
(1) 4701429407
The problem is due to a code defect in the psi driver
when attempting to process multiple DMA transactions.
Resolution:
The fix implemented consists in processing 1 DMA
transaction at a time instead of processing queued DMA
transactions.
The DMA transactions are still queued but the DMA engine
processes only one transaction at a time. It does not
prefetch DMA transaction because we force it to stop and
generate an interrupt after having processed every
transaction.
When the driver gets the interrupt related to the
completion of a DMA transaction, it starts processing the
next DMA transaction in the queue.
(2) 4701425561
The Streams/UX subsystem on hp-ux 11.0 , unlike SVR4
streams, does not provide any form of locking when
accessing a streams Q. Thus, on HP-UX it is not safe to
perform a PUTQ to a stream from outside its context
(i.e. from the put or service routine of another queue).
Resolution:
The streams call PUT() does contend for ownership of a
given queue, because HP-UX guarantees that only a single
put or service routine for a queue will be run at one time.
Thus, to ensure the streams queues are protected we modify
the SNA code to:-
- issue put() rather than putq()
- have the put routine for the streams Q issue
the putq() to defer processing to the
service routine.
(3) 4701425355
Problem is that ACC stack is calling QLLC put routine from
interrupt context. QLLC module is not designed to cope with
this: all other drivers/stacks queue their messages in a
simple service routine so they can be sent upstream outside
interrupt context. We have nevertheless agreed that we
will add queuing to our QLLC module so that it works with
the new ACC X.25 driver.
Resolution:
Fundamental fix is to move from the put() routine to the
service() routine all the read-side processing in the QLLC
module. In practice this only affects M_PROTO messages.
Examination of the QLLC module code suggested that code
processing these messages in put() routine could simply be
removed -- provided the messages were then queued to the
service routine -- because the service routine already has
to handle them (via an FSM) in situations of buffer
shortage. Empirical testing bore this out.
So fix actually simplifies code by removing 'special case'
processing for data messages when there are buffers
available and no control messages queued in front of
them.
(4) 1653299073
The problem is caused by the corruption of the lan3 data
structures involved in DMA transactions by the psi0 DMA
transaction processing.
Resolution:
Changed the handling of DMA trasactions. The transactions
are still queued but the DMA engine processes only one
transaction at a time. It does not prefetch DMA
transaction because we force it to stop and generate an
interrupt after having processed a transaction. When the
driver gets the interrupt related to the completion of
a DMA transaction, it starts processing the next DMA
transaction in the queue.
PHNE_17819:
(1) 5003446971
Panic caused by attempting to dereference null pointer
while examining posted_list LQE in nbm_info structure to
see whether it is empty.
Resolution:
Add boolean flag to nbm_info to say whether posted list is
empty or not.
(2) 4701418707
The outgoing attach was being sent with the password
from the previously rejected incoming attach causing a
validation error.
Resolution:
Add code to copy the password from the START_TP signal into
the tcp_ptr in nrmsttp.c
(3) 1653305805
From the stack we can see that this a deadlock in the
kernel during snap stop processing. We grab a write lock
on vpr_entity_lock in vpr_stream_close() which we hold
across a number of calls, including the one to nba_term().
It is this lock we are trying to acquire in
vpr_route_ips_on_route() near the top of the stack trace.
Resolution:
We don't actually need to hold the vpr_entity_lock round
the call to nba_term() in vpr_stream_close(). So the fix
is just to release it before that call and reacquire it
afterwards.
(4) 1653293878
The TP is failing to start because the userid under which
it is running has been misconfigured so that it can't
retrieve its own group name. This may be due to local
access to the group file or with running NIS (Network
Information Service) to share user and group IDs across
more than one machine. There are two reasons for the
cryptic error logs recorded by SNAplus2:-
- Failure of the getpwuid() or getgrgid() system calls
was not logged as an error message.
- The VSM_AS_TP_FAILURE internal error code was not getting
put in the right part of the DLOAD_RSP_ERR message sent
from the Service Manager to the APPC Stub. This meant that
the APPC stub was misinterpreting it as an APPC sense code.
Resolution:
The root cause of the problem is to correctly configure the
Unix user/group under which the TP is to be run.
However changes to SNAplus2 have been made to improve the
logging in this area as follows:-
In vpm_build_user_info() in vr/vpmu.c we add error logs for
the cases where getpwuid() or getgrgid() system calls fail.
However, failure of these system calls leads to a path
failure. So to make sure these new error logs actually
reach the sna.err log file, we also modify
vlm_user_write_log() in vdiag/vlmuser.c so that even if we
fail to open a path we still attempt to send the datagram
containing the log (in addition to attempting to write it
locally).
In the error reply arm of vsm_rcv_dload_confirm() in
vr/vsmdload.c we put the error code in the dld_status field
rather than the ld_sense_data field of the DLOAD_RSP_ERR
message -- because this is where the vas_datagrams()
routine in the APPC Stub expects to find it. We also change
the exception logged in vsm_rcv_dload_confirm() from the
generic one, with its rather misleading reference to errno
to a new specific error.
Texts of the new logs are in the vdiag/*.txt files.
PHNE_17405:
(1) 5003441717
If the kernel initialisation fails, it is possible that
the snaperrlog process could hang - waiting for a signal
from the kernel which never arrives.
Resolution:
A code change has been made to ensure that ,if the
kernel initialisation fails, a failure notification is
sent to the snaperrlog process so it can exit
cleanly.
(2) 4701413054
Small timing window when there is an empty list of LULU
control blocks when processing SSCP_INIT_SIGNAL_NEG_RSP
ISP.
Resolution:
Code changed to check whether LULU list is empty before
trying to obtain first element of it.
(3) 4701399279
The PSI f/w header string was not changed with the
release of SNAplus2 as the f/w is common to both
SNAplus & SNAplus2.
Resolution:
- a new what string for the NIO firmware
- a new what string and a new compilation format for
the EISA firmware
The ']' character has been added at the beginning of
each PSI firmware library header line so that the
header can be recognized by the snapwhat command.
(4) 1653289686
TN3270 cliemt was locking up when the clear key was
entered because TN Server was passing the clear
command to the Host instead of processing it locally
(as is done in the Motif 3270 emulator for example).
Resolution:
Code changed to add check and special handling for the
clear key at the beginning of the TN Server SSCP inbound
MU processing.
(5) 1653289603
TN3270 client was receiving SSCP datas when the clear
key was entered because TN Server was passing the clear
command to the Host instead of processing it locally (as
is done in the Motif 3270 emulator for example).
Resolution:
Code changed to add check and special handling for the
clear key at the beginning of the TN Server SSCP inbound
MU processing.
PHNE_16758:
(1) 4701405316
Updated binaries provided for combined patching of
latest R6 release ,as documented in SR text.
(2) 4701399527
A Code change has been made to prevent Assert errors
occurring when a large USSMSG10 is received for an LU6.2
session .
The maximum amount of data permissible on the SSCP screen
has been increased to 2048 bytes, to ensure segmented data
on SSCP screen handled correctly.
(3) 1653279703
Code change made to fix a problem with Assert errors being
logged when an RJE workstation is started.
Code changed to correct the ASSERT - it should only be
produced if an application has opened the SSCP session and
is listening for RTM requests (RJE does not do this so it
should not be logged as an error).
(4) 1653276543
Code change to prevent 3270 session hang, due to NOTIFY
not sent.
The fix applied is to ensure that any pending NOTIFY
requests are flushed from the CH queue in the APPN node
when a CLOSE_SSCP message is received (indicating that
the emulator has been stopped).
(5) 1653273979
Enhancement to allow multiple PUs to be used on a secondary
leased link. This means that if an SDLC port is connected
to a leased line, you can have multiple LS's active over
the port at the same time.
(6) 1653267179
The problem is basically that if you specify AP_SAME on the
ALLOCATE verb but did not configure user validation, then
we will send a user ID consisting of 10 NULLs.
A code change has been made, and the following behavior
applies when AP_SAME is used :
case 1: a TP on Unix invokes a remote TP: the outgoing
Allocate will contain a userID subfield, set to the Unix
user ID
the TP is running under;
case 2 :a TP on Unix invokes several remote TPs:see case 1;
case 3 : multiple conversations, where an INVOKED TP issues
an ALLOCATE:in that case, the outgoing Allocate will
include the
same level of validation which was on the ATTACH that
invoked that TP.
PHNE_15937:
(1) 5003398354
Code changed to ensure that if the user specifies any other
parameters, they match those used on the initial define.
Produce an error code otherwise.
(2) 4701396374
Code changed to allow the node to start if it finds a
TN Client configured with unrecognised hostname, but
generates an error log which tells the user of the failure.
(3) 4701395459
This was an incorrect ASSERT which has been removed. It is
a benign problem, but produces annoying error logs and
console messages.
(4) 4701392670
The LAN logger component (which handles central logging)
incorrectly registered itself with the service manager as a
server. This means that a server could end up twice in the
service table (for example, once as a backup, then again as
a master server). This lead to extremely unpredictable and
unreliable client/server operation. Code change made to
prevent this incorrect registering.
(5) 1653261669
Send a signal to the host when firmware is ready (backplane
and frontplane are initialized)
Remove debug trace from msgbuf (opt1:)
PHNE_14392:
(1) 4701386227
Fixed problems in SDLC driver and firmware.
SR:
8606130719 8606128605 8606128040 8606127677 8606111815
8606108556 8606106415 8606105945 8606105839 8606105164
8606104163 5003467290 5003446971 5003441717 5003398354
4701429621 4701429407 4701425561 4701425355 4701418707
4701413054 4701405316 4701399527 4701399279 4701396374
4701395459 4701392670 4701386227 1653305805 1653299073
1653293878 1653289686 1653289603 1653279703 1653276543
1653273979 1653267179 1653261669
Patch Files:
/opt/sna/conf/lib/libpsi0.a
/opt/sna/conf/lib/libpsi1.a
/opt/sna/conf/lib/libsixd.a
/opt/sna/conf/lib/libsixl.a
/opt/sna/conf/lib/libsixm.a
/opt/sna/conf/lib/libsixp.a
/opt/sna/conf/lib/libsixq.a
/opt/sna/conf/lib/libsixs.a
/opt/sna/sdlc.dlf
/opt/sna/sdlc.pbs
/opt/sna/bin/snaptnsrvr
what(1) Output:
/opt/sna/bin/snaptnsrvr:
HP92453-02A.10.00 HP-UX SYMBOLIC DEBUGGER (END.O) $R
evision: 74.03 $
]R6.10.20.101 SNAplus2 R6 TN Server
] (PHNE_17405 : 99/01/11 17:27:05)
]
/opt/sna/conf/lib/libpsi0.a:
]R6.10.20.105 SNAplus2 R6 NIO PSI driver
] (PHNE_20211 : 99/11/05 07:29:46)
]
/opt/sna/conf/lib/libpsi1.a:
]B.10.20.102 SNAplus2 R6 EISA PSI driver
] (PHNE_19407 : 99/08/16 07:41:48)
]
/opt/sna/conf/lib/libsixd.a:
]R6.10.20.102 SNAplus2 R6 NDLC to DLPI Mapping
] (PHNE_20738 : 99/11/30 17:33:31)
]
/opt/sna/conf/lib/libsixl.a:
]R6.10.20.107 SNAplus2 R6 SDLC in the Kernel
] (PHNE_21213 : 00/02/01 13:36:20)
]
/opt/sna/conf/lib/libsixm.a:
]R6.10.20.101 SNAplus2 R6 NDLC to DLPI Mapping
] (PHNE_19407 : 99/08/06 14:16:03)
]
/opt/sna/conf/lib/libsixp.a:
]R6.10.20.102 SNAplus2 R6 QLLC Module
] (PHNE_19407 : 99/08/06 14:20:01)
]
/opt/sna/conf/lib/libsixq.a:
]R6.10.20.101 SNAplus2 R6 QLLC Module
] (PHNE_19407 : 99/08/06 14:21:09)
]
/opt/sna/conf/lib/libsixs.a:
]R6.10.20.126 SNAplus2 R6 Router in the kernel
] (PHNE_21213 : 00/03/13 11:14:26)
]
]R6.10.20.119 SNAplus2 R6 APPN kernel library routin
es
] (PHNE_21213 : 00/03/13 11:13:52)
]
/opt/sna/sdlc.dlf:
SNAplus2 EISA FW v2.7
(99/07/30 12:58:42)
/opt/sna/sdlc.pbs:
]SNAplus2 NIO FW v2.1
](98/11/13 11:58:22)
cksum(1) Output:
2390782579 204416 /opt/sna/bin/snaptnsrvr
3096725199 63500 /opt/sna/conf/lib/libpsi0.a
3450841052 47488 /opt/sna/conf/lib/libpsi1.a
2028436616 172652 /opt/sna/conf/lib/libsixd.a
853364514 360508 /opt/sna/conf/lib/libsixl.a
2260423153 2540 /opt/sna/conf/lib/libsixm.a
656500477 142452 /opt/sna/conf/lib/libsixp.a
1648757111 2504 /opt/sna/conf/lib/libsixq.a
4017435474 3026556 /opt/sna/conf/lib/libsixs.a
3715532193 105228 /opt/sna/sdlc.dlf
3918812582 172212 /opt/sna/sdlc.pbs
Patch Conflicts: None
Patch Dependencies: None
Hardware Dependencies: None
Other Dependencies: None
Supersedes:
PHNE_14392 PHNE_15937 PHNE_16758 PHNE_17405 PHNE_17819 PHNE_19070
PHNE_19407 PHNE_20211 PHNE_20738
Equivalent Patches: None
Patch Package Size: 4270 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_21213
5a. For a standalone system, run swinstall to install the
patch:
swinstall -x autoreboot=true -x match_target=true \
-s /tmp/PHNE_21213.depot
By default swinstall will archive the original software in
/var/adm/sw/patch/PHNE_21213. 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_21213.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_21213.depot of=/dev/rmt/0m bs=2k
Special Installation Instructions:
Stop SNA daemon before installing patch (snap stop). After
installing the patch start the SNA daemon (snap start).
-----End of Document ID: PHNE_21213------------------------------------------
Document ID: PHNE_23439
Date Loaded: 20010224
Title: s700_800 10.24 (VVOS) BIND 4.9.7 components
Patch Name: PHNE_23439
Patch Description: s700_800 10.24 (VVOS) BIND 4.9.7 components
Creation Date: 01/02/22
Post Date: 01/02/24
Hardware Platforms - OS Releases:
s700: 10.24
s800: 10.24
Products: N/A
Filesets:
InternetSrvcs.INETSVCS-RUN InternetSrvcs.INET-ENG-A-MAN
Automatic Reboot?: No
Status: General Release
Critical: No
Path Name: /hp-ux_patches/s700_800/10.X/PHNE_23439
Symptoms:
PHNE_23439:
Repackaged HP-UX patch PHNE_23277 for VVOS.
Based on HP-UX patch PHNE_23277:
1. JAGad38231/8606168953:
Disable version query feature on BIND 4.9.7
2. JAGad41828/8606172568:
named loops with some record queries.
3. JAGad48072/8606178847:
Incorrect error messages generated by named for
malformed DNS queries.
PHNE_22905:
Repackaged HP-UX patch PHNE_21999 for VVOS.
Based on HP-UX patch PHNE_21999:
1. JAGac79099 / SR8606128299:
"nslookup" cannot resolve hostnames properly
when there is wild card entry in DNS data files
and a search list having multiple entries in
resolv.conf.
2. JAGad09228 / SR8606139905:
DNS and symbolic link problem.
3. JAGad23810 / SR8606154493:
"nslookup" sets timeout value to 5000 seconds when
name server host is specified at the command line.
4. JAGab53671 / SR1653307470:
"hosts_to_named" does not validate entries in
/etc/hosts.
PHNE_21288:
Repackaged HP-UX patch PHNE_20618 for VVOS.
Based on HP-UX patch PHNE_20618:
1. JAGac40451 / SR8606125060:
"named" fails in certain cases.
2. JAGaa57264 / SR5003446138:
"named" fails to resolve some of the names.
3. JAGab69094:
BIND 4.9.7 and 8.1.2 resolver code not searching
and stopping with Fully Qualified Domain Name(FQDN).
4. JAGab84583 / SR8606112269:
In Network Connection Policy Manager(NCPM)
environment, "named" exits after few days.
5. JAGab21142 / SR1653306647:
Disable XSTATS on "named".
Based on HP-UX patch PHNE_7495:
"named" was unable to provide responses from the
relocatable IP address used in MC/ServiceGuard environments.
Resolver clients configured to first query the nameserver's
relocatable IP address would not accept the response
returned by the nameserver, causing name resolution delays.
PHNE_16204:
Repackaged HP-UX patch PHNE_14617 for VVOS.
Based on HP-UX patch PHNE_14617:
1. Upgrade to Bind 4.9.7
2. DNS has problem when directed to use forwarder.
3. PHNE_10494 has problem in Serviceguard environment.
Based on HP-UX patch PHNE_10494:
1. Upgrade to Bind 4.9.6.
2. Fix named 4.9.3 to handle database reload in the
service guard configuration.
3. nslookup with NIS gives incorrect aliases on
later lookups.
4. BIND 4.9.3 nslookup does not handle "RP"records.
5. nslookup returning improper aliases from the previous
lookup.
6. hosts_to_named cannot handle 4 byte network address.
7. In named 4.9.3, cache can drop root nameserver's
data and cannot recover.
8. nslookup shows incorrect source of the name resolution.
9.Bind patch PHNE_9589 does not show the latest manpages.
Based on HP-UX patch PHNE_9589:
New release of BIND components version 4.9.3 for 10.00,
10.01, 10.10 and 10.20.
Based on HP-UX patch PHNE_7864:
New release of BIND components version 4.9.3 for 10.20.
Based on HP-UX patch PHNE_6983:
When using hp's named as a slave/forwarder to a 4.9.2
named,if the 4.9.2 named sends an NXDOMAIN record without
AA in replyto a query which it has no other information,
our named would discard it and wait for a timeout period
(30 secs) before continuing the search. This timeout
period can cause delays toapplications relying on named
resolution.
Defect Description:
PHNE_23439:
Based on HP-UX patch PHNE_23277:
1. JAGad38231/8606168953:
An ER was requested to disable version query thru
nslookup.
Resolution:
Bind version query thru nslookup has been disabled.
2. JAGad41828/8606172568:
With some specific SRV records, named may loop.
Resolution:
Proper initialization of pointers resolved and avoided
the unnecessary loops of named.
3. JAGad48072/8606178847:
When named encountered malformed DNS queries, it
generated wrong error messages.
Resolution:
named has been fixed to report proper error messages.
PHNE_22905:
Repackaged HP-UX patch PHNE_21999 for VVOS.
Based on HP-UX patch PHNE_21999:
1. JAGac79099 / SR8606128299:
nslookup does not go through alternative domain
entries in the search list when the nameserver
returns a non-authoritative record with no answers.
Resolution:
nslookup now goes through alternative entries in the
search list when it receives a non-authoritative record
with no answers.
2. JAGad09228 / SR8606139905:
DNS and symbolic link problem.
Resolution:
DNS now compatible with symbolic links.
3. JAGad23810 / SR8606154493:
nslookup takes a very long time in responding
due to the retransmission value being set to
millisecs by libc. As nslookup assumes the
value to be in seconds there was a long delay for
responses to non-existent records.
Resolution:
nslookup resets timeout value in seconds if the value
has been set in milliseconds by libc.
4. JAGab53671 / SR1653307470:
hosts_to_named fails to validate entries in /etc/hosts.
Also this script takes a very long time to execute
when /etc/hosts contains a large number of entries.
Resolution:
hosts_to_named now checks for non-numeric values in
IP addresses of /etc/hosts entries. It also avoids
calling a function multiple times thereby reducing
the time taken to execute this program.
PHNE_21288:
Repackaged HP-UX patch PHNE_20618 for VVOS.
Based on HP-UX patch PHNE_20618:
1. JAGac40451 / SR8606125060:
Boundary conditions are not handled properly.
Resolution:
The boundary conditions have been addressed.
2. JAGaa57264 / SR5003446138:
BIND 4.9.7 running as internal nameserver
and forwarding queries to external nameserver
fails when the lookup address has a CNAME
record with a higher TTL than its corresponding
A record.
Resolution:
The query packet header was not properly framed.
Now a proper header is sent in the query packet.
3. JAGab69094:
If the name being queried has at least one dot,
nslookup appends domain name instead of
trying it as it is, at the very first query.
Resolution:
If the name has atleast one dot in it, nslookup
looks up the name as it is at the very first time.
4. JAGab84583 / SR8606112269:
In NCPM environment "named"(BIND 4.9.7) keeps
on consuming memory and after few days runs out
of memory and eventually exits.
Resolution:
The memory has been freed properly after its use.
5. JAGab21142 / SR1653306647:
ER by customer to disable XSTATS
information logged to syslog.
Resolution:
The "-X" command line option is provided
to disable XSTATS information that is logged
to syslog.
Based on HP-UX patch PHNE_7495:
named was unable to identify the relocatable IP address
assigned to a local network interface. Queries received
from resolver clients would be answered, however, the
source IP address in the response would be the base IP
address of the network interface rather than the
relocatable IP address. The resolver would drop the
response.
PHNE_16204:
Repackaged HP-UX patch PHNE_14617 for VVOS.
Based on HP-UX patch PHNE_14617:
1. Upgrade to Bind 4.9.7
2. Bug in forwarders implementation causes name
resolution to fail when forwarders are used.
3. A bug in initialisation causes problem in the
Serviceguard environment.
Based on HP-UX patch PHNE_10494:
1. Upgrade to Bind 4.9.6
2. Bind 4.9.3 closes the socket on a relocatable IP
when a database reload occurs.
3. Aliases from the last lookup appears in the next
nslookup, if the new address being looked up does
not have an alias.
4. nslookup is not able to handle "RP" records.
5. nslookup returns the alias of the previous lookup.
6. hosts_to_named creates wrong db files if a 4 byte
network address is specified.
7. Bug in 4.9.3 causes named to stop working after 3
or 4 days and has to be restarted.
8. nslookup does not show the actual source of the
name resolution.
9.Bind patch PHNE_9589 does not remove cat1m.Z files.
Based on HP-UX patch PHNE_9589:
New release of BIND components version 4.9.3 for 10.00,
10.01, 10.10 and 10.20.
Based on HP-UX patch PHNE_7864:
New release of BIND components version 4.9.3 for 10.20.
Based on HP-UX patch PHNE_6983:
The problem occurred due to a bug introduced in BIND
version 4.9.2. This bug has been fixed in BIND 4.9.3.
HP's namedversion 4.8.3 did not accept the erroneous
response receivedfrom BIND 4.9.2. Even though our version
of named was no in error, we now accept such a response
in order to better interoperate in BIND 4.9.2 environment.
SR:
8606168953 8606172568 8606178847 8606128299 8606139905
8606154493 1653307470 8606125060 5003446138 8606112269
1653306647 5003304238 1653240986 5003402404 5003369561
4701301150 5003361931 5003360248 1653096313 4701350181
5003379750 5003369744 4701293217 5003304733 5003346932
Patch Files:
/usr/bin/nslookup
/usr/sbin/hosts_to_named
/usr/sbin/named
/usr/sbin/named-xfer
/usr/sbin/sig_named
/usr/share/doc/bind496.txt
/usr/share/doc/bog.ps.Z
/usr/share/doc/bog.txt.Z
/usr/share/man/man1m.Z/named-xfer.1m
/usr/share/man/man1m.Z/named.1m
/usr/share/man/man1m.Z/sig_named.1m
what(1) Output:
/usr/bin/nslookup:
Copyright (c) 1985,1989 Regents of the University of
California.
nslookup $Revision: 1.1.112.6 $ Wed Feb 14 16:15:18
GMT 2001
/usr/sbin/hosts_to_named:
None
/usr/sbin/named:
Copyright (c) 1986, 1989, 1990 The Regents of the Un
iversity of California.
named 4.9.7 Wed Feb 14 16:14:34 GMT 2001 PHNE_23277
/usr/sbin/named-xfer:
Copyright (c) 1988, 1990 The Regents of the Universi
ty of California.
named 4.9.7 Wed Feb 14 16:14:34 GMT 2001 PHNE_23277
/usr/sbin/sig_named:
None
/usr/share/doc/bind496.txt:
None
/usr/share/doc/bog.ps.Z:
None
/usr/share/doc/bog.txt.Z:
None
/usr/share/man/man1m.Z/named-xfer.1m:
None
/usr/share/man/man1m.Z/named.1m:
None
/usr/share/man/man1m.Z/sig_named.1m:
None
cksum(1) Output:
3349344747 118784 /usr/bin/nslookup
2628928620 58210 /usr/sbin/hosts_to_named
3100259778 221184 /usr/sbin/named
2224505652 86016 /usr/sbin/named-xfer
1909378160 4053 /usr/sbin/sig_named
2882227719 4313 /usr/share/doc/bind496.txt
3899687399 79421 /usr/share/doc/bog.ps.Z
1715827123 41278 /usr/share/doc/bog.txt.Z
987811226 2056 /usr/share/man/man1m.Z/named-xfer.1m
1309694491 6217 /usr/share/man/man1m.Z/named.1m
2498961528 1476 /usr/share/man/man1m.Z/sig_named.1m
Patch Conflicts: None
Patch Dependencies: None
Hardware Dependencies: None
Other Dependencies: None
Supersedes:
PHNE_16204 PHNE_21288 PHNE_22905
Equivalent Patches:
PHNE_23277:
s700: 10.20
s800: 10.20
PHNE_23274:
s700: 11.00
s800: 11.00
PHNE_22919:
s700: 11.04
s800: 11.04
Patch Package Size: 690 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_23439
5a. For a standalone system, run swinstall to install the
patch:
swinstall -x autoreboot=true -x match_target=true \
-s /tmp/PHNE_23439.depot
By default swinstall will archive the original software in
/var/adm/sw/patch/PHNE_23439. 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_23439.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_23439.depot of=/dev/rmt/0m bs=2k
Special Installation Instructions:
The product updated in this patch is not normally configured
on VVOS systems.
-----End of Document ID: PHNE_23439------------------------------------------
Document ID: PHNE_23277
Date Loaded: 20010223
Title: s700_800 10.01-[12]0 BIND 4.9.7 components
Patch Name: PHNE_23277
Patch Description: s700_800 10.01-[12]0 BIND 4.9.7 components
Creation Date: 01/02/15
Post Date: 01/02/23
Hardware Platforms - OS Releases:
s700: 10.01 10.10 10.20
s800: 10.01 10.10 10.20
Products: N/A
Filesets:
InternetSrvcs.INETSVCS-RUN InternetSrvcs.INET-ENG-A-MAN
Automatic Reboot?: No
Status: General Release
Critical: No
Path Name: /hp-ux_patches/s700_800/10.X/PHNE_23277
Symptoms:
PHNE_23277:
1. JAGad38231/8606168953:
Disable version query feature on BIND 4.9.7
2. JAGad41828/8606172568:
named loops with some record queries.
3. JAGad48072/8606178847:
Incorrect error messages generated by named for
malformed DNS queries.
PHNE_21999:
1. JAGac79099 / SR8606128299:
"nslookup" cannot resolve hostnames properly
when there is wild card entry in DNS data files
and a search list having multiple entries in
resolv.conf.
2. JAGad09228 / SR8606139905:
DNS and symbolic link problem.
3. JAGad23810 / SR8606154493:
"nslookup" sets timeout value to 5000 seconds when
name server host is specified at the command line.
4. JAGab53671 / SR1653307470:
"hosts_to_named" does not validate entries in
/etc/hosts.
PHNE_20618:
1. JAGac40451 / SR8606125060:
"named" fails in certain cases.
2. JAGaa57264 / SR5003446138:
"named" fails to resolve some of the names.
3. JAGab69094:
BIND 4.9.7 and 8.1.2 resolver code not searching
and stopping with Fully Qualified Domain Name(FQDN).
4. JAGab84583 / SR8606112269:
In Network Connection Policy Manager(NCPM)
environment, "named" exits after few days.
5. JAGab21142 / SR1653306647:
Disable XSTATS on "named".
PHNE_7495:
"named" was unable to provide responses from the
relocatable IP address used in MC/ServiceGuard environments.
Resolver clients configured to first query the nameserver's
relocatable IP address would not accept the response
returned by the nameserver, causing name resolution delays.
PHNE_14617:
1. Upgrade to Bind 4.9.7
2. DNS has problem when directed to use forwarder.
3. PHNE_10494 has problem in Serviceguard environment.
PHNE_10494:
1. Upgrade to Bind 4.9.6.
2. Fix named 4.9.3 to handle database reload in the
service guard configuration.
3. nslookup with NIS gives incorrect aliases on
later lookups.
4. BIND 4.9.3 nslookup does not handle "RP"records.
5. nslookup returning improper aliases from the previous
lookup.
6. hosts_to_named cannot handle 4 byte network address.
7. In named 4.9.3, cache can drop root nameserver's
data and cannot recover.
8. nslookup shows incorrect source of the name resolution.
9.Bind patch PHNE_9589 does not show the latest manpages.
PHNE_9589:
New release of BIND components version 4.9.3 for 10.00,
10.01, 10.10 and 10.20.
PHNE_7864:
New release of BIND components version 4.9.3 for 10.20.
PHNE_6983:
When using hp's named as a slave/forwarder to a 4.9.2
named,if the 4.9.2 named sends an NXDOMAIN record without
AA in replyto a query which it has no other information,
our named would discard it and wait for a timeout period
(30 secs) before continuing the search. This timeout
period can cause delays toapplications relying on named
resolution.
Defect Description:
PHNE_23277:
1. JAGad38231/8606168953:
An ER was requested to disable version query thru
nslookup.
Resolution:
Bind version query thru nslookup has been disabled.
2. JAGad41828/8606172568:
With some specific SRV records, named may loop.
Resolution:
Proper initialization of pointers resolved and avoided
the unnecessary loops of named.
3. JAGad48072/8606178847:
When named encountered malformed DNS queries, it
generated wrong error messages.
Resolution:
named has been fixed to report proper error messages.
PHNE_21999:
1. JAGac79099 / SR8606128299:
nslookup does not go through alternative domain
entries in the search list when the nameserver
returns a non-authoritative record with no answers.
Resolution:
nslookup now goes through alternative entries in the
search list when it receives a non-authoritative record
with no answers.
2. JAGad09228 / SR8606139905:
DNS and symbolic link problem.
Resolution:
DNS now compatible with symbolic links.
3. JAGad23810 / SR8606154493:
nslookup takes a very long time in responding
due to the retransmission value being set to
millisecs by libc. As nslookup assumes the
value to be in seconds there was a long delay for
responses to non-existent records.
Resolution:
nslookup resets timeout value in seconds if the value
has been set in milliseconds by libc.
4. JAGab53671 / SR1653307470:
hosts_to_named fails to validate entries in /etc/hosts.
Also this script takes a very long time to execute
when /etc/hosts contains a large number of entries.
Resolution:
hosts_to_named now checks for non-numeric values in
IP addresses of /etc/hosts entries. It also avoids
calling a function multiple times thereby reducing
the time taken to execute this program.
PHNE_20618:
1. JAGac40451 / SR8606125060:
Boundary conditions are not handled properly.
Resolution:
The boundary conditions have been addressed.
2. JAGaa57264 / SR5003446138:
BIND 4.9.7 running as internal nameserver
and forwarding queries to external nameserver
fails when the lookup address has a CNAME
record with a higher TTL than its corresponding
A record.
Resolution:
The query packet header was not properly framed.
Now a proper header is sent in the query packet.
3. JAGab69094:
If the name being queried has at least one dot,
nslookup appends domain name instead of
trying it as it is, at the very first query.
Resolution:
If the name has atleast one dot in it, nslookup
looks up the name as it is at the very first time.
4. JAGab84583 / SR8606112269:
In NCPM environment "named"(BIND 4.9.7) keeps
on consuming memory and after few days runs out
of memory and eventually exits.
Resolution:
The memory has been freed properly after its use.
5. JAGab21142 / SR1653306647:
ER by customer to disable XSTATS
information logged to syslog.
Resolution:
The "-X" command line option is provided
to disable XSTATS information that is logged
to syslog.
PHNE_7495:
named was unable to identify the relocatable IP address
assigned to a local network interface. Queries received
from resolver clients would be answered, however, the
source IP address in the response would be the base IP
address of the network interface rather than the
relocatable IP address. The resolver would drop the
response.
PHNE_14617:
1. Upgrade to Bind 4.9.7
2. Bug in forwarders implementation causes name
resolution to fail when forwarders are used.
3. A bug in initialisation causes problem in the
Serviceguard environment.
PHNE_10494:
1. Upgrade to Bind 4.9.6
2. Bind 4.9.3 closes the socket on a relocatable IP
when a database reload occurs.
3. Aliases from the last lookup appears in the next
nslookup, if the new address being looked up does
not have an alias.
4. nslookup is not able to handle "RP" records.
5. nslookup returns the alias of the previous lookup.
6. hosts_to_named creates wrong db files if a 4 byte
network address is specified.
7. Bug in 4.9.3 causes named to stop working after 3
or 4 days and has to be restarted.
8. nslookup does not show the actual source of the
name resolution.
9.Bind patch PHNE_9589 does not remove cat1m.Z files.
PHNE_9589:
New release of BIND components version 4.9.3 for 10.00,
10.01, 10.10 and 10.20.
PHNE_7864:
New release of BIND components version 4.9.3 for 10.20.
PHNE_6983:
The problem occurred due to a bug introduced in BIND
version 4.9.2. This bug has been fixed in BIND 4.9.3.
HP's namedversion 4.8.3 did not accept the erroneous
response receivedfrom BIND 4.9.2. Even though our version
of named was no in error, we now accept such a response
in order to better interoperate in BIND 4.9.2 environment.
SR:
8606168953 8606172568 8606178847 8606128299 8606139905
8606154493 1653307470 8606125060 5003446138 8606112269
1653306647 5003304238 1653240986 5003402404 5003369561
4701301150 5003361931 5003360248 1653096313 4701350181
5003379750 5003369744 4701293217 5003304733 5003346932
Patch Files:
/usr/sbin/named
/usr/sbin/named-xfer
/usr/sbin/sig_named
/usr/sbin/hosts_to_named
/usr/bin/nslookup
/usr/share/man/man1m.Z/named.1m
/usr/share/man/man1m.Z/named-xfer.1m
/usr/share/man/man1m.Z/sig_named.1m
/usr/share/doc/bind496.txt
/usr/share/doc/bog.txt.Z
/usr/share/doc/bog.ps.Z
what(1) Output:
/usr/sbin/named:
Copyright (c) 1986, 1989, 1990 The Regents of the Un
iversity of California.
named 4.9.7 Wed Feb 14 16:14:34 GMT 2001 PHNE_23277
/usr/sbin/named-xfer:
Copyright (c) 1988, 1990 The Regents of the Universi
ty of California.
named 4.9.7 Wed Feb 14 16:14:34 GMT 2001 PHNE_23277
/usr/sbin/sig_named:
None
/usr/sbin/hosts_to_named:
None
/usr/bin/nslookup:
Copyright (c) 1985,1989 Regents of the University of
California.
nslookup $Revision: 1.1.112.6 $ Wed Feb 14 16:15:18
GMT 2001
/usr/share/man/man1m.Z/named.1m:
None
/usr/share/man/man1m.Z/named-xfer.1m:
None
/usr/share/man/man1m.Z/sig_named.1m:
None
/usr/share/doc/bind496.txt:
None
/usr/share/doc/bog.txt.Z:
None
/usr/share/doc/bog.ps.Z:
None
cksum(1) Output:
3100259778 221184 /usr/sbin/named
2224505652 86016 /usr/sbin/named-xfer
1909378160 4053 /usr/sbin/sig_named
2628928620 58210 /usr/sbin/hosts_to_named
3349344747 118784 /usr/bin/nslookup
1309694491 6217 /usr/share/man/man1m.Z/named.1m
987811226 2056 /usr/share/man/man1m.Z/named-xfer.1m
2498961528 1476 /usr/share/man/man1m.Z/sig_named.1m
2882227719 4313 /usr/share/doc/bind496.txt
1715827123 41278 /usr/share/doc/bog.txt.Z
3899687399 79421 /usr/share/doc/bog.ps.Z
Patch Conflicts: None
Patch Dependencies: None
Hardware Dependencies: None
Other Dependencies: None
Supersedes:
PHNE_6983 PHNE_7864 PHNE_9589 PHNE_10494 PHNE_14617 PHNE_7495
PHNE_20618 PHNE_21999
Equivalent Patches: None
Patch Package Size: 680 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_23277
5a. For a standalone system, run swinstall to install the
patch:
swinstall -x autoreboot=true -x match_target=true \
-s /tmp/PHNE_23277.depot
By default swinstall will archive the original software in
/var/adm/sw/patch/PHNE_23277. 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_23277.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_23277.depot of=/dev/rmt/0m bs=2k
Special Installation Instructions: None
-----End of Document ID: PHNE_23277------------------------------------------
Document ID: PHCO_23148
Date Loaded: 20010223
Title: s700_800 10.20 HP Array Manager/60 cumulative patch
Patch Name: PHCO_23148
Patch Description: s700_800 10.20 HP Array Manager/60 cumulative patch
Creation Date: 01/02/22
Post Date: 01/02/23
Hardware Platforms - OS Releases:
s700: 10.20
s800: 10.20
Products: N/A
Filesets:
OS-Core.ADMN-ENG-A-MAN OS-Core.C2400-UTIL
Automatic Reboot?: No
Status: General Release
Critical:
Yes
PHCO_23148: OTHER
Patch provides critical functionality for use of
HP Fibre Array/60 devices.
Path Name: /hp-ux_patches/s700_800/10.X/PHCO_23148
Symptoms:
PHCO_23148:
1. JAGad45524 - FC60 controller may attempt back-end I/O
during disk mech firmware download, resulting in
Selection Timeout error.
2. JAGad45915 - Parity scan does not report error blocks.
3. JAGad49307 - amdload core dump after controller
firmware download, while waiting for completion of
reset, if timeout occurs while polling AM60Srvr for
status.
4. JAGad49298 - amdsp core dump on fully loaded FC60
with misconfigured ID thumbwheels.
5. JAGad49309 - Downloading 4.X firmware or NVSRAM to
passive controller may be problematic. Separate
command sometimes required to restore controller
to active mode.
6. JAGad49088 - swremove of HP Array Manager/60 patch
causes /etc/rc.config.d/hparamgr file to be removed,
preventing automatic restart of daemon on reboot.
7. JAGad51090 - On HP-UX 10.20 patch install/remove,
swmodify attempts to access non-existent filesets of
name type PATCH_ID.PATCH_ID.
PHCO_22627:
1. JAGad35936 - Fix log clearing problem with HP03 and
earlier firmware, introduced in PHCO_22195.
2. JAGad34226 - Change MEL drive slot from 1-based to
0-based, to match amdsp output. Problem was introduced
in PHCO_22195.
3. JAGad36256 - Implement environment variable to allow
option for more than 100 MB of log files.
4. JAGad36259 - Add non-redundancy warnings for RAID 0.
5. The amlog utility provided in this patch does not read
the array log files generated by AM60Srvr from
PHCO_21314 or earlier patches. To read old log files,
use the archived version of amlog found in
/var/adm/sw/patch/<OLD_PATCH_NAME>/opt/hparray/bin/,
where OLD_PATCH_NAME is PHCO_21314 or earlier.
PHCO_22195:
1. JAGad04079 - AM60Srvr core dumps on parity scan of LUN
with owning controller missing.
2. JAGab16618 - Improve logging in multi-initiator
environments.
3. JAGab84551 - SCSI Device Lock Not Granted when
attempting syswipe of array.
4. JAGac00096 - LUN recovery difficult.
5. JAGad08697 - AM60Srvr dies intermittently.
6. JAGad23891 - amdload command lock violation.
7. JAGab78599 - Implement Major Event Logging in AM60.
8. JAGac79027 - AM60Srvr exits with PendingQueue::Add
buffer overflow.
9. JAGad26497 - LUN display shows drives as ?-? when
numDisks is 0.
10. JAGad03253 - Download application firmware and bootware
as one file.
11. JAGab82780 - amdsp command fails after LUN's owning
controller is removed.
12. JAGad03254 - Add support for RAID 0 LUNs.
13. JAGad03945 - Add support for UTM LUN.
14. JAGad07307 - Handle new sense codes from HP07 firmware.
15. JAGad27589 - Handle SCSI disk firmware convergence in
amdload.
16. JAGab15596 - Log files should not be able to grow so as
to overflow a file system.
17. JAGac86825 - Disk firmware download problems on Seagate
Cheetah III & IV mechs.
18. JAGad02941 - FRU device type 0x07 not always decoded
correctly in amlog.
19. JAGad03204 - Enable software controller reset when
allowed by firmware.
20. JAGad03821 - LUN number sometimes not initialized in
drive group display.
21. JAGad10447 - New FRU group decoding required with HP07
controller firmware.
22. JAGad10909 - Man page updates required for IPR-0012
software.
23. JAGad23902 - Decode FRU info provided in raw MEL data.
24. JAGab78603 - Validate AM60 ANSI C++ compliance.
25. JAGad02940 - Add support for LUN state 83.
26. JAGad05381 - Report disk sense data on SMART events.
27. JAGad07400 - Slot ID in disk display has wrong data
type.
28. JAGab75343 - Fix amlog memory leak.
29. JAGab75346 - Fix amdload memory leak.
30. JAGad16493 - amdsp -p -S on more than two links results
in a device ID error.
31. JAGad29621 - amdsp -i reports AM60Srvr unavailable,
but it is running.
PHCO_21314:
1. JAGad00714 - Change connection messages going to
syslog from info type to debug type. Also change
rescan message to be debug as well.
PHCO_20217:
1. JAGac33875 - AM60Srvr only logs events when LUN 1 is
configured.
2. JAGab78816 - amlog does not show LUN info when a LUN
is failed with unflushed cache.
3. JAGac39733 - AM60Srvr fails with core on startup on
systems with more than ten FC-60 arrays attached.
4. JAGac40880 - amfmt command requires change to man page
to indicate that it is a data destructive command.
5. JAGac39742 - amlog does not decode all sense codes.
6. JAGab76959 - amcfg fails with segmentation violation if
an invalid channel is specified when configuring a LUN.
7. JAGac29676 - make amcfg bind LUN default segment size
16K, instead of current cache block size.
8. JAGab32006 - Minor typographical error in amcfg man page
9. JAGac79070 - Need to re-designate SC-10 power supplies
and fans as A, B instead of 1, 2.
10. JAGac86303 - Change "ARM" reference to "AM60" in
amlog output and syslog file, when a required
message catalog entry can't be found.
PHCO_19485:
1. JAGab20973 - Incorrect diagnostic message when
specifying alias longer than 16 characters.
2. JAGab24502 - Unclear diagnostic message when
binding a LUN on a passive controller.
3. JAGab25356 - Ambiguous cache battery age shown in
controller display.
4. JAGab14439 - Rounding problem when setting and
displaying cache flush options.
5. JAGab18057 - Need to add interpretation of FRU code and
qualifier for amlog.
6. JAGab57569 - SCSI channel, SCSI ID, enclosure ID and
slot ID are ambiguous in disk display.
7. JAGab21223 - amdsp fails with core file during
LUN display when all original drives are spared.
8. JAGab39222 - Need improved handling of commands which
require controller synchronization (reset battery age,
set time, set alias), when one controller is missing
or failed.
9. JAGab67460 - Need capability to mark disks operational
from any failed state.
10. JAGab68932 - Need an option for amdload to allow
BCC firmware download regardless of disk states.
11. JAGab43951 - Need to show NVSRAM version in controller
display.
12. JAGab43865 - Need capability to reset LUN cache
parameters to default values, and show a cache state
table in the LUN display.
13. JAGab17231 - Command line extended help and usage
messages need to be more consistent with man pages.
14. JAGab65570 - amdload man page must describe requirement
to download bootware, firmware, NVSRAM file in proper
sequence.
15. JAGab70912 - Need capability to flash LEDs for a drive
list.
16. Need SIC HWPath call to allow EMS client to
report array hardware path.
17. JAGab72268 - Need capability to download firmware to
IBM disks.
18. Client/server interface (SIC) needs forward and
backward compatibility to support EMS monitor.
19. JAGab31757 - amdsp may fail with core file,
Segmentation violation.
PHCO_18684:
Initial Release Install Patch.
Defect Description:
PHCO_23148:
1. Description: JAGad45524 - FC60 controller may attempt
back-end I/O during disk mech firmware
download, resulting in Selection Timeout
error.
2. Description: JAGad45915 - Parity scan does not report
error blocks.
3. Description: JAGad49307 - amdload core dump after
controller firmware download, while
waiting for completion of reset, if
timeout occurs while polling AM60Srvr
for status.
4. Description: JAGad49298 - amdsp core dump on fully
loaded FC60 with misconfigured ID
thumbwheels.
5. Description: JAGad49309 - Downloading 4.X firmware or
NVSRAM to passive controller may be
problematic. Separate command sometimes
required to restore controller to active
mode.
6. Description: JAGad49088 - swremove of HP Array Manager/
60 patch causes /etc/rc.config.d/hparamgr
file to be removed, preventing automatic
restart of daemon on reboot.
7. Description: JAGad51090 - On HP-UX 10.20 patch install/
remove, swmodify attempts to access
non-existent filesets of name type
PATCH_ID.PATCH_ID.
NOTE: If any of the superceded patches have been
installed, and this patch is later removed, the
revision numbers of the superceded patches, as shown by
swlist, will be incorrectly displayed as B.10.00.00.AA.
The actual revision numbers are as follows: PHCO_22627
- B.10.20.13, PHCO_22195 - B.10.20.11, PHCO_21314 -
B.10.20.10, PHCO_20217 - B.10.20.9, PHCO_19485 -
B.10.20.7, PHCO_18684 - B.10.20.4.
PHCO_22627:
1. Description: JAGad35936 -
Fix log clearing problem with HP03 and
earlier firmware, introduced in PHCO_22195.
2. Description: JAGad34226 -
Change MEL drive slot from 1-based to
0-based, to match amdsp output. Problem
was introduced in PHCO_22195.
3. Description: JAGad36256 -
Implement environment variable to allow
option for more than 100 MB of log files.
4. Description: JAGad36259 -
Add non-redundancy warnings for RAID 0.
5. Description: The amlog utility provided in this patch
does not read the array log files generated
by AM60Srvr from PHCO_21314 or earlier
patches. To read old log files, use the
archived version of amlog found in
/var/adm/sw/patch/<OLD_PATCH_NAME>/opt/
hparray/bin/, where OLD_PATCH_NAME is
PHCO_21314 or earlier.
PHCO_22195:
1. Description: JAGad04079 -
AM60Srvr core dumps on parity scan of LUN
with owning controller missing.
2. Description: JAGab16618 -
Improve logging in multi-initiator
environments.
3. Description: JAGab84551 -
SCSI Device Lock Not Granted when
attempting syswipe of array.
4. Description: JAGac00096 -
LUN recovery difficult.
5. Description: JAGad08697 -
AM60Srvr dies intermittently.
6. Description: JAGad23891 -
amdload command lock violation.
7. Description: JAGab78599 -
Implement Major Event Logging in AM60.
8. Description: JAGac79027 -
AM60Srvr exits with PendingQueue::Add
buffer overflow.
9. Description: JAGad26497 -
LUN display shows drives as ?-? when
numDisks is 0.
10. Description: JAGad03253 -
Download application firmware and bootware
as one file.
11. Description: JAGab82780 -
amdsp command fails after LUN's owning
controller is removed.
12. Description: JAGad03254 -
Add support for RAID 0 LUNs.
13. Description: JAGad03945 -
Add support for UTM LUN.
14. Description: JAGad07307 -
Handle new sense codes from HP07 firmware.
15. Description: JAGad27589 -
Handle SCSI disk firmware convergence in
amdload.
16. Description: JAGab15596 -
Log files should not be able to grow so as
to overflow a file system.
17. Description: JAGac86825 -
Disk firmware download problems on Seagate
Cheetah III & IV mechs.
18. Description: JAGad02941 -
FRU device type 0x07 not always decoded
correctly in amlog.
19. Description: JAGad03204 -
Enable software controller reset when
allowed by firmware.
20. Description: JAGad03821 -
LUN number sometimes not initialized in
drive group display.
21. Description: JAGad10447 -
New FRU group decoding required with HP07
controller firmware.
22. Description: JAGad10909 -
Man page updates required for IPR-0012
software.
23. Description: JAGad23902 -
Decode FRU info provided in raw MEL data.
24. Description: JAGab78603 -
Validate AM60 ANSI C++ compliance.
25. Description: JAGad02940 -
Add support for LUN state 83.
26. Description: JAGad05381 -
Report disk sense data on SMART events.
27. Description: JAGad07400 -
Slot ID in disk display has wrong data
type.
28. Description: JAGab75343 -
Fix amlog memory leak.
29. Description: JAGab75346 -
Fix amdload memory leak.
30. Description: JAGad16493 -
amdsp -p -S on more than two links results
in a device ID error.
31. Description: JAGad29621 -
amdsp -i reports AM60Srvr unavailable,
but it is running.
PHCO_21314:
1. Description: JAGad00714 - Change connection messages
going to syslog from info type to debug
type. Also change rescan message to be
debug as well.
PHCO_20217:
1. Description: JAGac33875 - AM60Srvr only logs events when
LUN 1 is configured.
2. Description: JAGab78816 - amlog does not show LUN info
when a LUN is failed with unflushed cache.
3. Description: JAGac39733 - AM60Srvr fails with core on
startup on systems with more than ten FC-60
arrays attached.
4. Description: JAGac40880 - amfmt command requires change
to man page to indicate that it is a data
destructive command.
5. Description: JAGac39742 - amlog does not decode all
sense codes.
6. Description: JAGab76959 - amcfg fails with segmentation
violation if an invalid channel is
specified when configuring a LUN.
7. Description: JAGac29676 - make amcfg bind LUN default
segment size 16K, instead of current cache
block size.
8. Description: JAGab32006 - Minor typographical error in
amcfg man page.
9. Description: JAGac79070 - Need to re-designate SC-10
power supplies and fans as A, B instead
of 1, 2.
10. Description: JAGac86303 - Change "ARM" reference to
"AM60" in amlog output and syslog file,
when a required message catalog entry
can't be found.
PHCO_19485:
1. Description: JAGab20973 -
Incorrect diagnostic message when
specifying alias longer than 16 characters.
2. Description: JAGab24502 -
Unclear diagnostic message when binding a
LUN on a passive controller.
3. Description: JAGab25356 -
Ambiguous cache battery age shown in
controller display.
4. Description: JAGab14439 -
Rounding problem when setting and
displaying cache flush options.
5. Description: JAGab18057 -
Need to add interpretation of FRU code and
qualifier for amlog.
6. Description: JAGab57569 -
SCSI channel, SCSI ID, enclosure ID and
slot ID are ambiguous in disk display.
7. Description: JAGab21223 -
amdsp fails with core file during LUN
display when all original drives are
spared.
8. Description: JAGab39222 -
Need improved handling of commands which
require controller synchronization (reset
battery age, set time, set alias), when one
controller is missing or failed.
9. Description: JAGab67460 -
Need capability to mark disks operational
from any failed state.
10. Description: JAGab68932 -
Need an option for amdload to allow BCC
firmware download regardless of disk
states.
11. Description: JAGab43951 -
Need to show NVSRAM version in controller
display.
12. Description: JAGab43865 -
Need capability to reset LUN cache
parameters to default values, and show a
cache state table in the LUN display.
13. Description: JAGab17231 -
Command line extended help and usage
messages need to be more consistent with
man pages.
14. Description: JAGab65570 -
amdload man page must describe requirement
to download bootware, firmware, NVSRAM
file in proper sequence.
15. Description: JAGab70912 -
Need capability to flash LEDs for a drive
list.
16. Description:
Need SIC HWPath call to allow EMS client
to report array hardware path.
17. Description: JAGab72268 -
Need capability to download firmware to
IBM disks.
18. Description:
Client/server interface (SIC) needs
forward and backward compatibility to
support EMS monitor.
19. Description: JAGab31757 -
amdsp may fail with core file,
Segmentation violation.
PHCO_18684:
1. Description: Initial Release Install Patch.
SR:
4700000000
Patch Files:
/opt/hparray/bin/AM60Srvr
/opt/hparray/bin/amcfg
/opt/hparray/bin/amdsp
/opt/hparray/bin/amfmt
/opt/hparray/bin/amutil
/opt/hparray/bin/ammgr
/opt/hparray/bin/amlog
/opt/hparray/bin/amdload
/opt/hparray/lib/nls/msg/C/AM60Srvr.cat
/opt/hparray/lib/nls/msg/C/am60cl.cat
/opt/hparray/lib/nls/msg/C/am60oemmsg01.cat
/opt/hparray/lib/nls/msg/C/am60fwerrcod.cat
/usr/lbin/hparray/hparamail
/usr/lbin/hparray/hparamgr.hdr
/usr/lbin/hparray/hparamgrd
/usr/lbin/hparray/hparamgrrc
/sbin/init.d/hparamgr
/usr/newconfig/etc/rc.config.d/hparamgr
/opt/hparray/share/man/man1m/AM60Srvr.1m
/opt/hparray/share/man/man1m/amcfg.1m
/opt/hparray/share/man/man1m/amdsp.1m
/opt/hparray/share/man/man1m/amfmt.1m
/opt/hparray/share/man/man1m/amlog.1m
/opt/hparray/share/man/man1m/ammgr.1m
/opt/hparray/share/man/man1m/amutil.1m
/opt/hparray/share/man/man1m/amdload.1m
what(1) Output:
/opt/hparray/bin/AM60Srvr:
HP92453-02A.11.00 HP-UX SYMBOLIC DEBUGGER (END.O ILP
32) $Revision: 75.02 $
| (built for: HP-UX on B.10.20 2001/02/22 20:10:46)
| Version: B.10.20.14
+-HP Array Manager/60
+-Copyright (c) 1995 Hewlett-Packard Company
| (built for: HP-UX on B.10.20 2001/02/22 20:10:46)
| Version: B.10.20.14
+-HP Array Manager/60 - Server
+-HP Array Manager/60 - HP Shim
| Version: B.10.20.14
| (built for: HP-UX on B.10.20 2001/02/22 20:10:46)
+-Copyright (c) 1995 Hewlett-Packard Company
sascsidev_init.c, $Revision: 1.1 $
sascsidev_init_lun.c, $Revision: 1.1 $
sascsidev_init_dev_file.c, $Revision: 1.1 $
sascsidev_lock.c, $Revision: 1.1 $
sascsidev_io.c, $Revision: 1.1 $
sascsidev_unlock.c, $Revision: 1.1 $
sascsidev_end.c, $Revision: 1.3 $
sascsidev_io_diag0.c, $Revision: 1.1 $
sascsidev_io_sctl.c, $Revision: 1.1 $
sascsidev_gen.c, $Revision: 1.1 $
tl_io_init.c, $Revision: 1.1 $
tl_path_to_token.c, $Revision: 1.1 $
tl_get_driver_name.c, $Revision: 1.1 $
tl_io_end.c, $Revision: 1.1 $
tl_get_minor_number.c, $Revision: 1.1 $
tl_get_c_major.c, $Revision: 1.1 $
tl_diag0_init.c, $Revision: 1.1 $
tl_diag0_lock.c, $Revision: 1.1 $
tl_diag0_unlock.c, $Revision: 1.1 $
tl_diag0_end.c, $Revision: 1.1 $
pl_init_st_log_global.c, $Revision: 1.1 $
sys_test.c, $Revision: 1.1 $
tl_get_ioerrno_parm.c, $Revision: 1.1 $
tl_diag0_acc_errno.c, $Revision: 1.1 $
tl_diag0_send_buff.c, $Revision: 1.1 $
tl_diag0_return_buff.c, $Revision: 1.1 $
tl_diag0_get_buff.c, $Revision: 1.1 $
tl_diag0_scsi_io_setup.c, $Revision: 1.1 $
tl_diag0_log_rel.c, $Revision: 1.1 $
add_lit_parm.c, $Revision: 1.1 $
add_msg_parm.c, $Revision: 1.1 $
build_ll_msg.c, $Revision: 1.1 $
log_ll_msg.c, $Revision: 1.1 $
release_ll_msg.c, $Revision: 1.1 $
+-HP Array Manager/60 - Server Interface Component
| Version: B.10.20.14
| (built for: HP-UX on B.10.20 2001/02/22 20:10:46)
+-Copyright (c) 1995 Hewlett-Packard Company
/opt/hparray/bin/amcfg:
HP92453-02A.11.00 HP-UX SYMBOLIC DEBUGGER (END.O ILP
32) $Revision: 75.02 $
| (built for: HP-UX on B.10.20 2001/02/22 20:10:46)
| Version: B.10.20.14
+-HP Array Manager/60
+-Copyright (c) 1995 Hewlett-Packard Company
| (built for: HP-UX on B.10.20 2001/02/22 20:10:46)
| Version: B.10.20.14
+-HP Array Manager/60 - Client
+-HP Array Manager/60 - Server Interface Component
| Version: B.10.20.14
| (built for: HP-UX on B.10.20 2001/02/22 20:10:46)
+-Copyright (c) 1995 Hewlett-Packard Company
/opt/hparray/bin/amdsp:
HP92453-02A.11.00 HP-UX SYMBOLIC DEBUGGER (END.O ILP
32) $Revision: 75.02 $
| (built for: HP-UX on B.10.20 2001/02/22 20:10:46)
| Version: B.10.20.14
+-HP Array Manager/60
+-Copyright (c) 1995 Hewlett-Packard Company
| (built for: HP-UX on B.10.20 2001/02/22 20:10:46)
| Version: B.10.20.14
+-HP Array Manager/60 - Client
+-HP Array Manager/60 - Server Interface Component
| Version: B.10.20.14
| (built for: HP-UX on B.10.20 2001/02/22 20:10:46)
+-Copyright (c) 1995 Hewlett-Packard Company
/opt/hparray/bin/amfmt:
HP92453-02A.11.00 HP-UX SYMBOLIC DEBUGGER (END.O ILP
32) $Revision: 75.02 $
| (built for: HP-UX on B.10.20 2001/02/22 20:10:46)
| Version: B.10.20.14
+-HP Array Manager/60
+-Copyright (c) 1995 Hewlett-Packard Company
| (built for: HP-UX on B.10.20 2001/02/22 20:10:46)
| Version: B.10.20.14
+-HP Array Manager/60 - Client
+-HP Array Manager/60 - Server Interface Component
| Version: B.10.20.14
| (built for: HP-UX on B.10.20 2001/02/22 20:10:46)
+-Copyright (c) 1995 Hewlett-Packard Company
/opt/hparray/bin/amutil:
HP92453-02A.11.00 HP-UX SYMBOLIC DEBUGGER (END.O ILP
32) $Revision: 75.02 $
| (built for: HP-UX on B.10.20 2001/02/22 20:10:46)
| Version: B.10.20.14
+-HP Array Manager/60
+-Copyright (c) 1995 Hewlett-Packard Company
| (built for: HP-UX on B.10.20 2001/02/22 20:10:46)
| Version: B.10.20.14
+-HP Array Manager/60 - Client
+-HP Array Manager/60 - Server Interface Component
| Version: B.10.20.14
| (built for: HP-UX on B.10.20 2001/02/22 20:10:46)
+-Copyright (c) 1995 Hewlett-Packard Company
/opt/hparray/bin/ammgr:
HP92453-02A.11.00 HP-UX SYMBOLIC DEBUGGER (END.O ILP
32) $Revision: 75.02 $
| (built for: HP-UX on B.10.20 2001/02/22 20:10:46)
| Version: B.10.20.14
+-HP Array Manager/60
+-Copyright (c) 1995 Hewlett-Packard Company
| (built for: HP-UX on B.10.20 2001/02/22 20:10:46)
| Version: B.10.20.14
+-HP Array Manager/60 - Client
+-HP Array Manager/60 - Server Interface Component
| Version: B.10.20.14
| (built for: HP-UX on B.10.20 2001/02/22 20:10:46)
+-Copyright (c) 1995 Hewlett-Packard Company
/opt/hparray/bin/amlog:
HP92453-02A.11.00 HP-UX SYMBOLIC DEBUGGER (END.O ILP
32) $Revision: 75.02 $
| (built for: HP-UX on B.10.20 2001/02/22 20:10:46)
| Version: B.10.20.14
+-HP Array Manager/60
+-HP Array Manager/60 - Standalone Utility
| Version: B.10.20.14
| (built for: HP-UX on B.10.20 2001/02/22 20:10:46)
+-Copyright (c) 1995 Hewlett-Packard Company
/opt/hparray/bin/amdload:
HP92453-02A.11.00 HP-UX SYMBOLIC DEBUGGER (END.O ILP
32) $Revision: 75.02 $
| (built for: HP-UX on B.10.20 2001/02/22 20:10:46)
| Version: B.10.20.14
+-HP Array Manager/60
+-Copyright (c) 1995 Hewlett-Packard Company
| (built for: HP-UX on B.10.20 2001/02/22 20:10:46)
| Version: B.10.20.14
+-HP Array Manager/60 - Client
+-HP Array Manager/60 - Server Interface Component
| Version: B.10.20.14
| (built for: HP-UX on B.10.20 2001/02/22 20:10:46)
+-Copyright (c) 1995 Hewlett-Packard Company
/opt/hparray/lib/nls/msg/C/AM60Srvr.cat:
HP AutoRAID [B.10.20.14] AM60Srvr.cat $Revision: 1.1
6 $
Built for HP-UX B.10.20 on 2001/02/22 20:10:46 PM
MDT
(c) Copyright 1995 Hewlett-Packard Company
/opt/hparray/lib/nls/msg/C/am60fwerrcod.cat:
HP AutoRAID [B.10.20.14] fwerrcod.cat $Revision: 1.9
$
Built for HP-UX B.10.20 on 2001/02/22 20:10:46 PM
MDT
(c) Copyright 1995 Hewlett-Packard Company
/opt/hparray/lib/nls/msg/C/am60cl.cat:
HP AutoRAID [B.10.20.14] am60cl.cat $Revision: 1.60
$
Built for HP-UX B.10.20 on 2001/02/22 20:10:46 PM
MDT
(c) Copyright 1995 Hewlett-Packard Company
/opt/hparray/lib/nls/msg/C/am60oemmsg01.cat:
HP AutoRAID [B.10.20.14] oemmsg01.cat $Revision: 1.6
$
Built for HP-UX B.10.20 on 2001/02/22 20:10:46 PM
MDT
(c) Copyright 1995 Hewlett-Packard Company
/usr/lbin/hparray/hparamail:
+-HP Array Manager - Mail Script
| Version: B.11.00.00
+-Copyright (c) 1999 Hewlett-Packard Company
/usr/lbin/hparray/hparamgr.hdr:
+-HP Array Manager - Script Header
| Version: B.11.00.00
+-Copyright (c) 1999 Hewlett-Packard Company
/usr/lbin/hparray/hparamgrd:
+-HP Array Manager - Monitor Daemon
| Version: B.11.00.00
+-Copyright (c) 1999 Hewlett-Packard Company
/usr/lbin/hparray/hparamgrrc:
+-HP Array Manager - Startup Script
| Version: B.11.00.00
+-Copyright (c) 1999 Hewlett-Packard Company
/sbin/init.d/hparamgr:
+-HP Array Manager - Startup/Shutdown Script
| Version: B.11.00.00
+-Copyright (c) 1999 Hewlett-Packard Company
/usr/newconfig/etc/rc.config.d/hparamgr:
None
/opt/hparray/share/man/man1m/AM60Srvr.1m:
None
/opt/hparray/share/man/man1m/amcfg.1m:
None
/opt/hparray/share/man/man1m/amdsp.1m:
None
/opt/hparray/share/man/man1m/amfmt.1m:
None
/opt/hparray/share/man/man1m/amutil.1m:
None
/opt/hparray/share/man/man1m/ammgr.1m:
None
/opt/hparray/share/man/man1m/amlog.1m:
None
/opt/hparray/share/man/man1m/amdload.1m:
None
cksum(1) Output:
1001125669 2608400 /opt/hparray/bin/AM60Srvr
2802087634 1107664 /opt/hparray/bin/amcfg
2999291791 1268568 /opt/hparray/bin/amdsp
2411827029 1080352 /opt/hparray/bin/amfmt
2289815925 1101928 /opt/hparray/bin/amutil
1191376108 1111192 /opt/hparray/bin/ammgr
1877957277 1046920 /opt/hparray/bin/amlog
2264293212 1136416 /opt/hparray/bin/amdload
2258219791 7623 /opt/hparray/lib/nls/msg/C/AM60Srvr.cat
3319158706 8868 /opt/hparray/lib/nls/msg/C/am60fwerrcod.cat
299955134 113621 /opt/hparray/lib/nls/msg/C/am60cl.cat
3217585616 1383 /opt/hparray/lib/nls/msg/C/am60oemmsg01.cat
212830779 4931 /usr/lbin/hparray/hparamail
1655478901 3564 /usr/lbin/hparray/hparamgr.hdr
830060169 5893 /usr/lbin/hparray/hparamgrd
4267444545 2873 /usr/lbin/hparray/hparamgrrc
1647493802 5822 /sbin/init.d/hparamgr
999677066 199 /usr/newconfig/etc/rc.config.d/hparamgr
3615556153 3418 /opt/hparray/share/man/man1m/AM60Srvr.1m
3577060457 14504 /opt/hparray/share/man/man1m/amcfg.1m
2389533511 17293 /opt/hparray/share/man/man1m/amdsp.1m
1226416682 799 /opt/hparray/share/man/man1m/amfmt.1m
1747734987 7890 /opt/hparray/share/man/man1m/amutil.1m
2291579198 10467 /opt/hparray/share/man/man1m/ammgr.1m
1899341439 10153 /opt/hparray/share/man/man1m/amlog.1m
2068729702 10005 /opt/hparray/share/man/man1m/amdload.1m
Patch Conflicts: None
Patch Dependencies: None
Hardware Dependencies: None
Other Dependencies:
This patch provides the utilities for the HP Fibre
Array/60. To use the utilities an HP Fibre Array/60
array must be connected and configured to the system.
Supersedes:
PHCO_18684 PHCO_19485 PHCO_20217 PHCO_21314 PHCO_22195 PHCO_22627
Equivalent Patches:
PHCO_23149:
s700: 11.00
s800: 11.00
PHCO_23150:
s700: 11.11
s800: 11.11
Patch Package Size: 10550 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 PHCO_23148
5a. For a standalone system, run swinstall to install the
patch:
swinstall -x autoreboot=true -x match_target=true \
-s /tmp/PHCO_23148.depot
By default swinstall will archive the original software in
/var/adm/sw/patch/PHCO_23148. 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 PHCO_23148.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/PHCO_23148.depot of=/dev/rmt/0m bs=2k
Special Installation Instructions: None
-----End of Document ID: PHCO_23148------------------------------------------
Document ID: PHCO_23037
Date Loaded: 20010223
Title: s700_800 10.20 mkfs_vxfs(1M) cumulative patch
Patch Name: PHCO_23037
Patch Description: s700_800 10.20 mkfs_vxfs(1M) cumulative patch
Creation Date: 01/02/08
Post Date: 01/02/23
Hardware Platforms - OS Releases:
s700: 10.20
s800: 10.20
Products: N/A
Filesets:
JournalFS.VXFS-BASE-RUN
Automatic Reboot?: No
Status: General Release
Critical:
Yes
PHCO_23037: CORRUPTION
Path Name: /hp-ux_patches/s700_800/10.X/PHCO_23037
Symptoms:
PHCO_23037:
If a vxfs filesystem is bigger than a maximum
supported size of 128 gigabytes it may become
unmountable.
Defect Description:
PHCO_23037:
mkfs does not check if a size of a newly created
vxfs filesystem exceeds the supported limit of 128
gigabytes.
Resolution:
mkfs behavior has been modified to make sure that
the new filesystem size does not exceed the supported
limit of 128 gigabytes. It will refuse to create a
filesystem with a size beyond this limit.
SR:
8606169478
Patch Files:
/sbin/fs/vxfs/mkfs
what(1) Output:
/sbin/fs/vxfs/mkfs:
PATCH-PHCO_18644 for 10.20; for 10.30, 11.x compatib
ility libc.a_ID
/main/r10dav/libc_dav/libc_
dav_cpe/9
/ux/core/libs/libc/archive_pa1/libc.a_ID
Jul 8 1999 15:44:31
PATCH_10_20: mkfs.o tables.o 01/02/08
cksum(1) Output:
2222855886 241664 /sbin/fs/vxfs/mkfs
Patch Conflicts: None
Patch Dependencies: None
Hardware Dependencies: None
Other Dependencies: None
Supersedes: None
Equivalent Patches: None
Patch Package Size: 290 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 PHCO_23037
5a. For a standalone system, run swinstall to install the
patch:
swinstall -x autoreboot=true -x match_target=true \
-s /tmp/PHCO_23037.depot
By default swinstall will archive the original software in
/var/adm/sw/patch/PHCO_23037. 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 PHCO_23037.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/PHCO_23037.depot of=/dev/rmt/0m bs=2k
Special Installation Instructions: None
-----End of Document ID: PHCO_23037------------------------------------------
Document ID: PHCO_23035
Date Loaded: 20010223
Title: s700_800 10.20 extendfs_vxfs(1M) cumulative patch
Patch Name: PHCO_23035
Patch Description: s700_800 10.20 extendfs_vxfs(1M) cumulative patch
Creation Date: 01/02/08
Post Date: 01/02/23
Hardware Platforms - OS Releases:
s700: 10.20
s800: 10.20
Products: N/A
Filesets:
JournalFS.VXFS-BASE-RUN
Automatic Reboot?: No
Status: General Release
Critical:
Yes
PHCO_23035: CORRUPTION
Path Name: /hp-ux_patches/s700_800/10.X/PHCO_23035
Symptoms:
PHCO_23035:
If a filesystem is extended beyond the supported
limit of 128 gigabytes, it may become unmountable.
This patch will disallow expansion of vxfs
filesystem beyond 128 gigabytes.
Defect Description:
PHCO_23035:
extendfs does prevent a VxFS filesystem from being
grown beyond the supported limit of 128 gigabytes.
Resolution:
extendfs behavior has been modified to make sure that
the new filesystem size does not exceed the supported
limit of 128 gigabytes. It will refuse to extend a
filesystem beyond this limit.
SR:
8606169478
Patch Files:
/sbin/fs/vxfs/extendfs
what(1) Output:
/sbin/fs/vxfs/extendfs:
PATCH-PHCO_18644 for 10.20; for 10.30, 11.x compatib
ility libc.a_ID
/main/r10dav/libc_dav/libc_
dav_cpe/9
/ux/core/libs/libc/archive_pa1/libc.a_ID
Jul 8 1999 15:44:31
PATCH_10_20: extendfs.o 01/01/10
cksum(1) Output:
343508225 188416 /sbin/fs/vxfs/extendfs
Patch Conflicts: None
Patch Dependencies: None
Hardware Dependencies: None
Other Dependencies: None
Supersedes: None
Equivalent Patches: None
Patch Package Size: 240 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 PHCO_23035
5a. For a standalone system, run swinstall to install the
patch:
swinstall -x autoreboot=true -x match_target=true \
-s /tmp/PHCO_23035.depot
By default swinstall will archive the original software in
/var/adm/sw/patch/PHCO_23035. 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 PHCO_23035.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/PHCO_23035.depot of=/dev/rmt/0m bs=2k
Special Installation Instructions: None
-----End of Document ID: PHCO_23035------------------------------------------
Document ID: PHSS_23351
Date Loaded: 20010222
Title: s700_800 10.X Fortran90 B.10.20.(19|20|27) cumulative patch
Patch Name: PHSS_23351
Patch Description: s700_800 10.X Fortran90 B.10.20.(19|20|27) cumulative patch
Creation Date: 01/02/19
Post Date: 01/02/22
Hardware Platforms - OS Releases:
s700: 10.20
s800: 10.20
Products:
FORTRAN90 B.10.20.19
FORTRAN90 B.10.20.20
FORTRAN90 B.10.20.27
Filesets:
FORTRAN90.FORT90-PRG,B.10.20.19
FORTRAN90.FORT90-PRG,B.10.20.20
FORTRAN90.FORT90-PRG,B.10.20.27
FORTRAN90.FORT90-MAN,B.10.20.19
FORTRAN90.FORT90-MAN,B.10.20.20
FORTRAN90.FORT90-MAN,B.10.20.27
FORTRAN90.F90-JPN-E-MAN,B.10.20.19
FORTRAN90.F90-JPN-E-MAN,B.10.20.20
FORTRAN90.F90-JPN-E-MAN,B.10.20.27
FORTRAN90.F90-JPN-S-MAN,B.10.20.19
FORTRAN90.F90-JPN-S-MAN,B.10.20.20
FORTRAN90.F90-JPN-S-MAN,B.10.20.27
Automatic Reboot?: No
Status: General Release
Critical: No
Path Name: /hp-ux_patches/s700_800/10.X/PHSS_23351
Symptoms:
PHSS_23351:
01)JAGad49313:Compiler does not allow common blocks to be
mapped to system shared memory regions.
02)JAGad47314:Fortran77 and Fortran90 processes cannot share
memory whose size is not a multiple of 8
bytes.
03)JAGad08926:The compiler is not unrolling a simple loop,
user unroll is 2.5 times faster.
04)JAGad05033:The F90 Compiler takes over 100x longer to
compile a series of logical/equivalence
statements than the F77 compiler.
PHSS_23243:
01)JAGad47735:Compiler does not allow a called "C"
subroutine to modify a string literal
parameter. This was allowed in F77.
PHSS_23025:
01)JAGad41375:Compiler asserts on source with large
number of tokens.
02)JAGad39319:Internal Compiler error using +Oopenmp
03)JAGad41488:Return 0 not handled properly (should
be a normal return).
04)JAGab75257:Fortran90 does not support Complex(16).
Should return an error.
05)JAGad44817:Compiler Internal Error with +Oopenmp.
06)JAGad43235:Use of PRIVATE directive causes internal
compiler abort with bad dictionary
reference.
PHSS_22538:
01)JAGaa68236: Computation of "s**5." is 2-3 times slower
with F90 than F77.
02)JAGad12935: f90 program generates incorrect results
when compiled with -C.
03)JAGad15427: The compiler aborts using +O3 +Oparallel
for programs with a GOTO out of a
LOOP_PARALLEL.
04)JAGad23650: Compiler generates internal error
message during assignment of a string
field from a constant record substructure.
05)JAGad30138: Parallel reduction code overwrites static
variables in BSS.
06)JAGad32585: F90 compilation error:
Return_U2_Variable_Tag_From_Variable
observed when a name list containing
objects declared in common is used in a
read statement.
07)JAGad32663: Error 4244 was not generated for OpenMP
code as expected when a dynamic variable
is used in a "private" clause of the
"$omp parallel" directive.
08)JAGad33376: +DAportable does not work on 11x PA
2.0 machines. It produces an executable
that will not run on PA 1.1.
09)JAGad35535: The F90 compiler needs an extension to
allow a file to be opened several times
using different unit numbers. This
switch was in the F77 product as +E5.
PHSS_22464:
01)JAGaa68254: Compiler Internal Error referencing
f90numtab overflow with large data
initialization.
02)JAGad12934: Compiler Internal Error with (character*(*))
when compiling index((text),'TEST').
03)JAGad15565: IXOR of logical*1 was not supported.
04)JAGad23380: Customer requests E and G format treatment
of leading zeros match f77 compiler output
for easier comparison of prior results.
05)JAGad25820: +fastallocatable caused errors with
allocatable arrays that were SAVEd.
06)JAGad29886: Compiler Internal Error when a module defines
a COMMON block and USEs another module that
also defines the same COMMON block.
PHSS_22290:
01)JAGad10204: Compiler Internal Error with 'write(*)
sizeof(1)'
02)JAGad12719: EQUIVALENCE statements with shared common
caused compile time errors.
PHSS_22112:
01)JAGad04422: Some OpenMP directives caused compiler
internal errors when used with Modules.
02)JAGad08015: When multiple load options occurred in a
single compile line and the later options
were shorter than the earlier options,
incorrect behavior occurred.
03)JAGad14842: The zero based getarg solution provided by
PHSS_20578 caused incompatiblies for some
customers using shared library calls to
getarg.
04)JAGad10257: FSTREAM intrinsic only returns the lower
32 bits of FILE *fp pointer. That can
cause problems for applications using
wide mode (+DA2.0W).
05)JAGad21776: Hollerith literals that extended beyond
a single line behaved differently in
f77 +es than with f90 with +extend_source
06)JAGad23380: Request for closer correspondance of I/O
output between f77 and f90.
PHSS_21787:
01)JAGac40404: OpenMP runtime routines not yet available
(such as omp_get_thread_num, omp_set_lock,
omp_unset_lock, omp_test_lock) cause an
abnormal exit from the compiler.
02)JAGac86812: segmentation fault in Fortran90 Front End
after invalid alternate return detected.
03)JAGac89036: use of +fastallocatable building module
gives error 8901
04)JAGad00206: +fastallocatable problem with SPEC 191.fma3d
05)JAGad00286: compiler abort for legal code with PARAMETER
value in a CHARACTER declaration.
06)JAGad00311: assigning 65535 to an integer*2 generated
an error message.
07)JAGad02360: Parallel reduction overflows were not
handled correctly.
08)JAGad04015: Difference in literal printing between
f77 +es and f90 +extend_source.
09)JAGad04620: Problem with Union overlapping other
variables.
10)JAGad09092: NASTRAN f90 problem +DS2.0W segmentation
fault and wrong behavior
11)JAGad09294: LOGICAL FUNCTION G*1() syntax not accepted
by f90, but was accepted by f77.
12)JAGad12095: OpenMP directive error handling was
inadequate.
PHSS_21485:
01)JAGab70979: Reshape with negative numbers gives incorrect
results.
02)JAGab75487: Some variables starting with Z in data
statements are not handled properly.
03)JAGac86733: Logical statement function containing
floating point gives incorrect results.
04)JAGad00245: Backend Assert - Unimplemented feature 5172
while compiling +O3 +Oparallel for a loop
that had a multiple of 2 loop stride.
05)JAGad00286: When a CHARACTER declaration size is set by
a PARAMETER value, the compiler complains
that the value was undefined.
06)JAGad00305: Alternate return arguments in an external
subroutine call that was part of an IF
statement caused an compiler internal
error (8901).
07)JAGad00306: REAL*4 constants that exceeded the range of
REAL*4 variables caused a compiler time error
to be generated.
08)JAGad04026: Need to support OpenMP model of
threadprivate.
Defect Description:
PHSS_23351:
01)JAGad49313:There was no mechanism for this in the
compiler. Added compilation switch
+indirectcommonlist=file to allow the common
blocks listed in the specified file to be
treated as shared common blocks. These common
blocks are not attached. The user must attach
or otherwise allocate storage for the common
blocks before they are referenced.
Resolution:Recompile with the new compiler using
+indirectcommonlist=file switch.
02)JAGad47314:There was no mechanism to select this
behavior. Added the +nopadsharedcommon flag
to direct the compiler to not pad shared
common blocks to a multiple of 8 bytes.
All source files referencing the same
shared common block must be compiled with
the same setting of this flag.
Resolution:Recompile with the new compiler using
+nopadsharedcommon flag.
03)JAGad08926:There was a problem with max/min reductions
in the loop unroll algorithm.
Resolution:Recompile with the new compiler.
04)JAGad05033:Equivalence processing in the front end
used an overly simplisitic n**3 algorithm.
It has been enhanced to an n**2 algorithm.
Resolution:Recompile with the new compiler.
PHSS_23243:
01)JAGad47735:The places string literals in read-only
memory. Modified the compiler to place
the literal in read-write memory if the
user specifies +charlit77.
Resolution:Recompile with the new compiler using
+charlit77.
PHSS_23025:
01)JAGad41375:Token string table size was limiting number
of tokens.
Resolution: Recompile with new compiler.
02)JAGad39319:The IFBLOCK following the OMPPARALLELDOBLOCK
was being read before "insertendompdo" was
called.
Resolution: Recompile with new compiler.
03)JAGad41488:Compiler didn't handle return 0 correctly.
Resolution: Recompile with new compiler.
04)JAGab75257:Compiler tried to represent data types in an
unsupported format.
Resolution: Recompile with new compiler.
05)JAGad44817:A push routine in DU_directives.c was being
called twice when it should only be
called once.
Resolution: Recompile with new compiler.
06)JAGad43235:Compiler didn't handle PRIVATE directives
correctly.
Resolution: Recompile with new compiler.
PHSS_22538:
01)JAGaa68236: F90 did not inline x**r, where r is a real
constant with an integral value.
Resolution: Recompile with new compiler.
02)JAGad12935: The basic basic block optimizer in the LLO
disposed of a store that it incorrectly
determined was redundant.
Resolution: Recompile with new compiler.
03)JAGad15427: The optimizer tried to parallelize a loop
with multiple exits and aborted. This type
of loop cannot be parallelized. The
compiler now generates a warning message and
continues to compile without parallelizing
the loop.
Resolution: Recompile with new compiler.
04)JAGad23650: The compiler was producing an unexpected type
of initializer for an array of derived type,
when the initial value was an array
constructor composed of structure
constructors.
Resolution: Recompile with new compiler.
05)JAGad30138: The compiler was using an incorrect memory
area when several reduction variables were
needed within a loop.
Resolution: Recompile with new compiler.
06)JAGad32585: The compiler did not correctly handle the
name list.
Resolution: Recompile with new compiler.
07)JAGad32663: The compiler did not handle this disallowed
variable correctly. It now generates the
appropriate error message.
Resolution: Recompile with new compiler.
08)JAGad33376: The link process caused 2.0 libraries to get
pulled in. We now pull in 1.1 libraries.
Resolution: Rebuild.
09)JAGad35535: The compiler now supports +multi_open to
allow a file to be used in multiple F90
Open statements.
Resolution: Compile using the new +multi_open compiler
switch.
PHSS_22464:
01)JAGaa68254: Compiler Internal Error referencing
f90numtab overflow with large data
initialization. Internal compiler tables
were increased in size.
Resolution: Recompile with new compiler.
02)JAGad12934: Compiler failed to handle an extra set of
paratheses in a character variable as an
intrinsic argument.
Resolution: Recompile with new compiler.
03)JAGad15565: IXOR of logical*1 was not supported.
Resolution: Recompile with new compiler.
04)JAGad23380: Customer requests E and G format treatment
of leading zeros match f77 compiler output
for easier comparison of prior results.
New switch +io77 added to support this
functionality.
Resolution: Recompile with new compiler using +io77.
05)JAGad25820: +fastallocatable caused errors with
allocatable arrays that were SAVEd.
Resolution: Recompile with new compiler.
06)JAGad29886: Compiler Internal Error when a module defines
a COMMON block and USEs another module that
also defines the same COMMON block.
Resolution: Recompile with new compiler.
PHSS_22290:
01)JAGad10204: Compiler failed to handle correctly a
constant argument to sizeof.
Resolution: Recompile with new compiler.
02)JAGad12719: EQUIVALENCE statements with shared common
were not handled correctly.
Resolution: Recompile with new compiler.
PHSS_22112:
01)JAGad04422: Some OpenMP directives caused parallel code
to be misplaced in the code stream when
used with Modules.
Resolution: Recompile with new compiler.
02)JAGad08015: The load option buffer was not being
reinitialized between uses, leaving garbage
at the end of the buffer on second and
later uses.
Resolution: Recompile with new compiler.
03)JAGad14842: The zero based getarg solution provided by
PHSS_20578 caused incompatiblies for some
customers using shared library calls to
getarg, so PHSS_20578 was superceded.
Resolution: Zero-based getarg behavior is now the default
when recompiling code. (HP f77 compatible
and also the method used by most other
Fortran vendors). To retain the one-based
behavior of earlier versions of f90,
recompile with the switch +getarg1.
04)JAGad10257: FSTREAM intrinsic only returns the lower
32 bits of FILE *fp pointer. That can
cause problems for applications using
wide mode (+DA2.0W).
Resolution: Recompile with new compiler.
05)JAGad21776: Hollerith literals that extended beyond
a single line behaved differently in
f77 +es than with f90 with +extend_source.
Resolution: Recompile with new compiler using +es switch.
06)JAGad23380: f90 has different I/O behavior for some
cases with G format. New switch added to
provide G format that behaves like f77.
Resolution: Recompile with new compiler using +gformat77.
PHSS_21787:
01)JAGac40404: OpenMP runtime routines not yet available
did not give an appropriate error message.
Resolution: Recompile with new compiler.
02)JAGac86812: Fortran90 Front End did not handle an
invalid alternate return appropriately.
Resolution: Recompile with new compiler.
03)JAGac89036: Errors were present in design of
fastallocatable option. New design is
binary compatible with non-fastallocatable
code, so mixed compilation is allowed.
Resolution: Recompile with new compiler
04)JAGad00206: Errors were present in design of
fastallocatable option. New design is
binary compatible with non-fastallocatable
code, so mixed compilation is allowed.
Resolution: Recompile with new compiler
05)JAGad00286: Fortran Front End did not handle PARAMETER
values in CHARACTER declarations properly.
Resolution: Recompile with new compiler.
06)JAGad00311: assigning 65535 to an integer*2 did not
allow for unsigned value representation.
Resolution: Recompile with new compiler.
07)JAGad02360: HLO did not use cpslib 'rover' feature for
parallel reduction overflow
Resolution: Recompile with new compiler.
08)JAGad04015: f90 +extend_source blindly extended the
line with blanks while with +es, f77
trimmed the line to match the blanks in
the source file.
Resolution: Recompile with new compiler using the new
flag +es instead of +extend_source.
09)JAGad04620: Unions not at the start of structures were
incorrectly handled.
Resolution: Recompile with new compiler.
10)JAGad09092: Assigned format labels in wide mode were not
handled correctly.
Resolution: Recompile with new compiler.
11)JAGad09294: LOGICAL FUNCTION G*1() syntax not accepted
by f90, but was accepted by f77.
Resolution: Recompile with new compiler.
12)JAGad12095: OpenMP directives did not handle several
cases appropriately. These were resolved.
Resolution: Recompile with new compiler.
PHSS_21485:
01)JAGab70979: Integer exponentiation of negative numbers by
negative numbers was incorrectly implemented.
Resolution: Recompile with new compiler.
02)JAGab75487: While implemented the 'Z' hex data format
extension for DATA statements to better
support existing f77 code, the parser was
incorrectly changed to not distingish between
variables and hex values starting with Z.
Resolution: Recompile with new compiler.
03)JAGac86733: When logical statement functions contained
floating point code, the result register was
not set properly.
Resolution: Recompile with new compiler.
04)JAGad00245: The HLO phase encoded a nonexistent
arithmetic left shift instead of the correct
logical left shift.
Resolution: Recompile with new compiler.
05)JAGad00286: The parser was not making PARAMETER values
available to CHARACTER declarations.
Resolution: Recompile with new compiler.
06)JAGad00305: Alternate return arguments were not handled
correctly for some cases.
Resolution: Recompile with new compiler.
07)JAGad00306: Users desired that out of range REAL*4
constants in f90 match the behavior of f77.
f90 generated an error message while f77
replaced out of range constants with the
largest representable REAL*4 constant.
Resolution: Recompile with new compiler.
08)JAGad04026: The OpenMP model of threadprivate needed to
be mapped to the HP model of thread private.
Also, warnings were added to state that
unnamed critical sections are not supported
yet.
Resolution: Recompile with new compiler.
SR:
0000000000
Patch Files:
/opt/fortran90/bin/f90
/opt/fortran90/lbin/f90com32
/opt/fortran90/lbin/f90com64
/opt/fortran90/lib/nls/msg/C/f90.cat
/opt/fortran90/lib/nls/msg/C/f90com.cat
/opt/fortran90/share/man/man1.Z/f90.1
/opt/fortran90/share/man/ja_JP.eucJP/man1.Z/f90.1
/opt/fortran90/share/man/ja_JP.SJIS/man1.Z/f90.1
/opt/fortran90/lib/libF90.a
/opt/fortran90/lib/pa2.0/libF90.a
what(1) Output:
/opt/fortran90/bin/f90:
HP-UX f90 20010214 (082309) B3907DB/B3909DB PHSS_23
351 B.10.20.30
HP F90 v2.4.13
/usr/lib/libc: $Revision: 76.3 $
/opt/fortran90/lbin/f90com32:
HP F90 v2.4.13
HP-UX SLLIC/OPTIMIZER UX.11.01.96 (ROSE): 11/16/98
HP aC++ B3910B A.01.19.02 Classic Iostream Library
HP aC++ B3910B A.01.19.02 Language Support Library
Ucode Code Generator - UX11.01.04(GS IB4) (PACG - No
vember 16, 1998)
HP-UX f90com32 20010214 (110533) B3907DB/B3909DB PH
SS_23351 B.10.20.30
Copyright (c) 1993-2000 EPCL. All Rights Reserved.
EPC Fortran-95 Version FFE15.3(S) HP:240500:103937
Ucode-2 - UCODE2_UX11.01_STABLE(v2.1) (October 19, 1
998)
High Level Optimizer - UX.11.00.981019 (UX11.01-CURR
ENT) [-DHLO_RELEASE +noeh -z +O2] - 11-Jan-2
001.15:51
/usr/lib/libc: $Revision: 76.3 $
/opt/fortran90/lbin/f90com64:
HP F90 v2.4.13
HP-UX SLLIC/OPTIMIZER UX.11.01.96 (ROSE): 11/16/98
HP aC++ B3910B A.01.19.02 Classic Iostream Library
HP aC++ B3910B A.01.19.02 Language Support Library
Ucode Code Generator - UX11.01.04(GS IB4) (PACG - No
vember 16, 1998)
HP-UX f90com64 20010214 (111751) B3907DB/B3909DB PH
SS_23351 B.10.20.30
Copyright (c) 1993-2000 EPCL. All Rights Reserved.
EPC Fortran-95 Version FFE15.3(S) HP:240500:103937
Ucode-2 - UCODE2_UX11.01_STABLE(v2.1) (October 19, 1
998)
High Level Optimizer - UX.11.00.981019 (UX11.01-CURR
ENT) [-DHLO_RELEASE +noeh -z +O2] - 11-Jan-2
001.15:51
/usr/lib/libc: $Revision: 76.3 $
/opt/fortran90/lib/nls/msg/C/f90.cat:
None
/opt/fortran90/lib/nls/msg/C/f90com.cat:
None
/opt/fortran90/share/man/man1.Z/f90.1:
None
/opt/fortran90/share/man/ja_JP.eucJP/man1.Z/f90.1:
None
/opt/fortran90/share/man/ja_JP.SJIS/man1.Z/f90.1:
None
/opt/fortran90/lib/libF90.a:
None
/opt/fortran90/lib/pa2.0/libF90.a:
None
cksum(1) Output:
1182048205 380928 /opt/fortran90/bin/f90
1898560326 12214272 /opt/fortran90/lbin/f90com32
702280099 12259328 /opt/fortran90/lbin/f90com64
412476016 14060 /opt/fortran90/lib/nls/msg/C/f90.cat
1871672615 107895 /opt/fortran90/lib/nls/msg/C/f90com.cat
3506399091 21145 /opt/fortran90/share/man/man1.Z/f90.1
2916332196 23883 /opt/fortran90/share/man/ja_JP.eucJP/
man1.Z/f90.1
852479595 23966 /opt/fortran90/share/man/ja_JP.SJIS/man1.Z/
f90.1
3057005238 4048400 /opt/fortran90/lib/libF90.a
3885477316 4330148 /opt/fortran90/lib/pa2.0/libF90.a
Patch Conflicts: None
Patch Dependencies: None
Hardware Dependencies: None
Other Dependencies: None
Supersedes:
PHSS_23243 PHSS_23025 PHSS_22538 PHSS_22464 PHSS_22290 PHSS_22112
PHSS_21787 PHSS_21485
Equivalent Patches: None
Patch Package Size: 32710 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 PHSS_23351
5a. For a standalone system, run swinstall to install the
patch:
swinstall -x autoreboot=true -x match_target=true \
-s /tmp/PHSS_23351.depot
By default swinstall will archive the original software in
/var/adm/sw/patch/PHSS_23351. 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 PHSS_23351.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/PHSS_23351.depot of=/dev/rmt/0m bs=2k
Special Installation Instructions: None
-----End of Document ID: PHSS_23351------------------------------------------
Document ID: PHNE_23034
Date Loaded: 20010222
Title: s700_800 10.20 2.40.00-2.40.02 X.25/ACC Protocol Patch
Patch Name: PHNE_23034
Patch Description: s700_800 10.20 2.40.00-2.40.02 X.25/ACC Protocol Patch
Creation Date: 01/01/12
Post Date: 01/02/22
Hardware Platforms - OS Releases:
s700: 10.20
s800: 10.20
Products:
Z7404AA_APZ B.02.40.00; Z7404AA_APZ B.02.40.01;
Z7404AA_APZ B.02.40.02; Z7301A_APZ B.02.40.00;
Z7301A_APZ B.02.40.01; Z7301A_APZ B.02.40.02;
Filesets:
ACC-X25.ACC-X25-FW,B.02.40.00,B.02.40.01,B.02.40.02
ACC-X25.ACC-X25-KRN,B.02.40.00,B.02.40.01,B.02.40.02
ACC-X25.ACC-X25-MAN,B.02.40.00,B.02.40.01,B.02.40.02
ACC-X25.ACC-X25-RUN,B.02.40.00,B.02.40.01,B.02.40.02
ACC-X25.ACC-X25-PRG,B.02.40.00,B.02.40.01,B.02.40.02
Automatic Reboot?: Yes
Status: General Release
Critical:
No (superseded patches were critical)
PHNE_22520: PANIC
Path Name: /hp-ux_patches/s700_800/10.X/PHNE_23034
Symptoms:
PHNE_23034:
SR 8606181518 / CR JAGad50734:
The checkinstall script of patch PHNE_22520 returns an
error when installed on a system that does not have
PHNE_18717 already installed.
SR 8606181300 / CR JAGad50517:
Incorrect ownership and permission was given for the
file libzx25dsyms.o.
SR 8606176420 / CR JAGad45658:
The return value of "txt2msg" should not be set to
"exitval" in the postinstall and the postremove control
scripts.
PHNE_22520:
SR 8606171991 / CR JAGad41254:
System panic due to spinlock deadlock.
SR 8606161688 / CR JAGad31004:
X.25 connection over ISDN does not get established.
SR 8606152413 / CR JAGad21743:
During high load activity on the Z7200A or Z7400A ACC
cards, such as X.25 call establishment and clearing on
all ports, one or more ports were unable to accept
further transmit requests. The affected ports were
not usable until the ACC card is restarted.
In the case of X.25 call establishment, the user
application may encounter the error return ENOSPC.
PHNE_18717:
DTS TPO0h02233
Under high rates of X.25 link startup and shutdown,
as seen for instance under ISDN/ACC, the axin driver
reports error 2015 in the nettl log, indicating
a timeout has ocurred during link shutdown.
DTS TPO0h01780
The LAPB and LAPD protocols were not behaving correctly
in relation to retransmission of the REJect frame.Only
one REJect frame would be transmitted, despite never
receiving an in-sequence I-frame which clears the reject
condition. The standards state that that a REJect frame
should be retransmitted every T1 interval until the
condition clears.
DTS TPO0h01967
Some ports on some 8-port cards fail to come up in
X.21 mode.
DTS TPO0h02172
LAPB/LAPD: Extended Information and Supervisory frames
that are received and are too short (missing part of
control field) are simply being ignored.Receipt of these
frames should result in the following action:
LAPB - sends FRMR (w and x set)
LAPD - sends SABME
DTS TPO0h02173
On LAPB/LAPD connection establishment, groups of DM
frames are sent between groups of SABM/SABME frames -
which is incorrect. DM frames should not be sent during
this connection establishment state.
DTS TPO0h02175
LAPB/LAPD terminals are not handling the "busy condition"
properly.If one side of a link is inactive (sent RNR -
Receiver Not Ready), the other side should poll every
T1 until the remote end activates.
DTS TPO0h02256
The LAPB Z180 firmware blocks messages from being
sent aftera link reset under special circumstances:
A received frame with a bad N(R) will result in a FRMR
being sent. On receiving this,the remote end will send
a SABM, our end send a UA and the link is re-established.
This is fine. But once this process is through,the
firmware refuses to send I-frames until it receives a
frame.This is a bug.
DTS TPO0h02414
A customer would like to be able to congigure the
frame protocol buffer transmit timer in the same
way timers are configured in HDLC-LAPB.
A problem exists at baud rates of 1200 and below.
A full buffer of data (238 bytes) will be cut
short when the 1 second transmit timeout expires.
DTS TPO0h02429
The ACC loopback test (invoked by the LB command in
zmntr) was occasionally failing with non-defective
8-port cards. The problem occurred on average about
once every 50 zmntr LB commands.
DTS TPO0h02484
After booting X25/9000 with x25init, a further x25init
after a card reset would hang. This only occurs if
PVCs are defined on 8-port and 2-port Z180 based ACC
cards.
DTS TPO0h02504
With the baud rate incorrectly configured as 64,000
while the actual line speed is 9600, transmitted
frames can be cut short and joined together.
DTS TPO0h02745
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.
DTS TPO0h02773
Some ports on some cards do not work properly in X.21
mode on the 8-port NIO and EISA cards. Some of these
failures occur just after a card reset, and recover
after some 10 - 30seconds. Other ports fail all the
time. The failure appears to be the port detecting the
CTS and/or DCD signals missing.
DTS TPO0h02671
Add nettl L3 tracing for X.25 to the B.02.39/B.02.40
releases.
DTS TPO0h02610
Add Q4 support for the 10.X release.
DTS TPO0h02755:
The ACC mux, port, and subchannel numbers are not logged
in the zx25 messages
DTS TPO0h02327:
For PVC ZLUs, the following message is logged when inbound
packets arrive on the PVC:
zx25d 00415 Link <#>: Illegal packet received!
Diagnostic = 36.
Packet = <pkt data> Pkt length = <#>
TPO0h02648:
System panic (data page fault) after VC Reset issued by
firmware.
PHNE_17026:
SR 5003437947
For NIO 8-port ACC cards, DMA timeout was occurring
during ZCOM/ACC subsystem startup in HP K class systems
(and potentially any T series) with 2 or more ACC cards
installed. The problem is faster to reproduce if 2 ACC
cards have failing ports and/or the ACC cards are not
numbered consecutively (0, 1, 2, etc.) in the user's ACC
.answ file.
PHNE_15354:
DTS NONE
Inbound Call indication packet is lost when the
packet arrives *immediately* after a Restart exchange
resulting in "Application timeout on inb. call"
message in ZCOM log file.
DTS TPO0h02042:
4-ch card: LAPB/LAPD loses timers in the timer
download control request.
DTS TPO0h01946:
4-ch card: LAPB/LAPD layer can get frames out of
sequence after receiving
a REJ.
SR 5003398362 / DTS TPO0h01774:
A large number of short packets received with
the M-bit set can lead to a firmware failure
(ACC card restart).
SR None / DTS TPO0h01974:
X25 firmware can corrupt queues on cable disconnect
and reconnect. The X25 link can no longer manage
calls correctly once this has happened.
SR 4701391862 / DTS TPO0h01966:
No current method to determine hardware revision
TPO0h01893:
Man page for x25stat has an incorrect library reference
PHNE_14011:
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 TPO0h01640
The following trace shows that the 2-ch ACC card transmits
a bad frame (search for BAD) at the beginning of link setup.
10:03:45/310.3 1- TD D1 FRAME len=0034 flg=0002
01 44 10 01 13 00 f1 01 59 01 3f 01 3f 01 3f 01 BAD!
3f 01 3f 01 3f 01 3f 01 3f 01 3f 01 3f 01 3f 01
01 3f
10:03:45/546.9 1- RD D1 FRAME len=0002 flg=9999
01 0f
SR NONE / DTS TPO0h01755
This problem was spotted in dump files
In addition to the incorrect REJ, the retry mechanism
for the unsatisfied REJ is incorrect.
SR NONE / DTS TPO0h01641
Trace shows unrecogised frame is received the response
is a FRMR, as it should be (see BAD).
18:29:26/739.4 1- RD D1 FRAME len=0002 flg=9999
D2 (01) DISC P/F=0
18:29:26/739.8 1- TD D1 FRAME len=0005 flg=9999
D2 (03) FRMR P/F=0
cmd=43 vr=007 vs=000 c/r=1 wxyz=0000 BAD!
18:29:27/378.0 1- RD D1 FRAME len=0002 flg=9999
D2 (01) DM P/F=0
Defect Description:
PHNE_23034:
SR: 8606181518 CR: JAGad50734
The checkinstall script of patch PHNE_22520 incorrectly
checks for the existance of the file libzx25dsyms.o.
This file gets installed only with patch PHNE_18717 and
not with the ACC product. Now, if the patch PHNE_22520
is installed on a system which has the ACC product but
does not have the patch PHNE_18717 already installed,
the checkinstall script of PHNE_22520 will return an
error.
Resolution: The checkinstall script has been modified
to check the existance of firmware files instead of
libzx25dsyms.o.
SR: 8606181300 CR: JAGad50517
The ownership and the permission of the file
libzx25dsyms.o was incorrect. The file should have
been owned by "root" instead of "bin". Also, the
permissions should have been 04555 instead of 0444.
Resolution: The ownership and permission of the file
libzx25dsyms.o has been corrected.
SR: 8606176420 CR: JAGad45658
In the postinstall and postremove scripts, the return
value of "txt2msg" should not be used to set "exitval".
Instead the value of "exitval" should be set to either
$SUCCESS, $FAILURE, $WARNING, or $EXCLUDE
appropriately.
Resolution: The postinstall and postremove scripts
have been modified so that "exitval" is set to either
$SUCCESS, $FAILURE, $WARNING, or $EXCLUDE and not to
the return value of "txt2msg".
PHNE_22520:
SR: 8606171991 CR: JAGad41254
splx() calls were not handled correctly. SPL for the
processor was not lowered.
Resolution: splx() calls that were not done properly in
the code are now done. Without these changes, the
system could panic with spinlock deadlock message.
SR: 8606161688 CR: JAGad31004
The problem was occuring because the remote end was
sending a SABM out of the blue. Though the firmware
was sending a Control write failure, this was not
ignored by the zx25d driver. This caused the zx25d
driver and the firmware to get out of sync and caused
the zx25d driver to send two RESTART packets.
Resolution: Code has been modified to ignore the
unsolicited message coming from the firmware when the
Link is down, reset, disabled or disconnected.
SR: 8606152413 CR: JAGad21743
The transmit processing for the affected port was
stalled, because the firmware was in an inconsistent
state. Two problems in the low level state processing
of the frame protocol have been identified and removed.
A workaround has been implemented for an inconsistent
state where the transmit timer was not running, but the
trasmitter was active. Additional protection has also
been added to interrupt critical state processing.
PHNE_18717:
DTS TPO0h02233
Under high load the events coming into the X25 control
driver zx25d can be processed out of the expected order.
Processing is added to repeat link shutdown processing
in this case.
DTS TPO0h01780
The HDLCABM state machine was not designed to handle
REJect frame retransmission. Extensive changes have been
made to the HDLCABM state machine to handle REJect frame
retransmission.
DTS TPO0h01967
Change to ensure that X.21 is disabled for the Z7200A Rev.A
card only. Change particularly focused at the Z7400A EISA
cards to ensure that Rev.A cards are not disabled from X.21
configuration. This corrects the X.21 configuration problem
with all cards.
DTS TPO0h02172
HDLC firmware was ignoring this condition. The HDLC
firmware has been corrected.
DTS TPO0h02173
Bad state change on N2/N200 timer expiration. The finite
state machine (FSM) has been corrected.
DTS TPO0h02175
Incorrect behaviour coded into the HDLCABM state machine.
The state machine has been corrected.
DTS TPO0h02256
The LAPB Z180 firmware blocks messages from being sent
after a link reset under special circumstances: A received
frame with a bad N(R) will result in a FRMR being sent.
On receiving this, the remote end will send a SABM, our
end send a UA and the link is re-established.This is fine.
But once this process is through, the firmware refuses to
send I-frames until it receives a frame. This is a bug.
DTS TPO0h02414
The transmit timeout is fixed at 1 second which
is not enough to allow the complete transmission
of a full buffer (238 bytes) at 1200 baud or less.
The frame module now sets the timeout according
to the configured baud rate on the port.
Baud rate Tx timeout (x100ms)
300 136
600 69
1200 35
2400 18
4800 10
9600 6
>9600 4
These timeouts allow approximately double the
necessary time for the maximum of 252 bytes to
be transmitted.
252 bytes is the maximum number of bytes to be
transmitted because that is the maximum which
can be held in one ACC buffer.
DTS TPO0h02429
A problem with the 8-port's ISCC chips caused a transmit
underrun to be incorrectly generated during the start of a
frame tranmission - resulting in the first few bytes of
that frame being corrupt. Note: The test is transmitting
in single character mode.
On initialisation of the ISCC, the firmware was issuing a
"Reset Tx Underrun/EOM Latch" command. This was found to
cause the occasional transmit underrun external/status
interrupt.This reset command was taken out of the
initialisation sequence in the testprot firmware.
DTS TPO0h02484
The zx25d driver and firmware were both contributing to the
firmware corrupting its internal counters of active
channels.On the card reset, the driver sends two "delete
association up" transactions to the card per virtual
circuit (should only send one). The firmware (wrongly)
accepted both for each PVC - the result was that an
internal firmware counter of active VCs was being
incremented twice per PVC.When the subsequent
x25init was issued, the X.25 link would not disable itself
because the internal counter read that active PVCs were not
shut down (when in fact all were). This caused x25init to
hang. Both driver and firmware were corrected.
The firmware was modified to not accept the second "delete
association up" transaction. The driver was also modified
to not send two of these transactions.
DTS TPO0h02504
This is due to an enhancement that was made for
defect TPO0h02414. The transmit timeout used at
level-1 was shortened for baud rates as high as
64000.
DTS TPO0h02745
The x25 firmware incorrectly processes the
disable request if there were outstanding uncompleted
control write requests, because of pending level 2
control packets to be transmitted.
The x25 firmware processing of the disable request
has been corrected.
DTS TPO0h02773
The Sipex chips (line drivers) when placed in RS422 mode
(balanced signaling mode used for X.21) leave some unused
TTL output pins in an unknown state. These pins are used
for the CTS signal when the Sipex chip is in RS232 mode.
The firmware was reading the state of the CTS signal -
and the ISCC chips were configured to react to this signal.
This problem was not detected before because the usual state
of these Sipex pins signal that CTS is up. On some Sipex
chips,this signal is down, or is down and then comes up
after a short period of time after being put into RS422
mode.The firmware has been changed to ignore the CTS signal
whenin X.21 mode. Also the ISCC chips are configured to
also ignore changes in the CTS and DCD signals. The
firmware code still checks the DCD signal - which matches
the X.21 Indicate signal, so the firmware still can
detect a cable disconnect. Note: There is no problem
in ignoring the (internal) CTS signal- as it does not
map to any signal in X.21.
DTS TPO0h02671
There is a commitment to provide X.25 nettl level 3 tracing
in the ACC B.02.39 and B.02.40 releases.
DTS TPO0h02610
There is a commitment to provide Q4 support for the
ACC B.02.39 and B.02.40 releases.
DTS TPO0h02755:
This is an enhancement made to the zx25d driver to supply
the ACC mux, port, and subchannel numbers in most messages
written to the ZCOM log file.
DTS TPO0h02648:
A system panic was occured during reset processing because
of a NULL pointer to the X.25 link data structure. This
was probably caused by dynamically deleting the link
(zmasterd stop or x25stop) while there was on-going
activity on the link.
DTS TPO0h02327:
This problem will never occur when using x25init to
configure the link. It only occurs when the link is
fully configured through ttgen and PVCs are used. If the
user declares more PVCs in the subscription parameter
(last_pvc) then there are PVC term entries, this problem
will occur. The zx25 driver is not initializing one of its
internal tables correctly when there are missing PVCs in
the ttgen configuration file. The code has been modified
to correctly initialize the table when one or more PVCs
have not been defined.
PHNE_17026:
SR 5003437947
The system part of the firmware was not verifying
whether the LO-QUIX chip (responsible for managing
backplane transactions) on the ACC card was ready
before requesting another I/O operation.
PHNE_15354:
DTS NONE
The X.25 driver uses a completion status message to
signal when the Restart Exchange is complete. If
an inbound call arrived before the completion status
was passed by the firmware to the driver, the inbound
call would be lost. This would appear as through the
application was not acknowledging the inbound call.
DTS TPO0h02042:
4-ch card: When timers are downloaded to the
LAPB/LAPD protocol in the CW_TIMERS control write
request, a system timer entry is wasted. Eventually
the ACC card can run out of timers.
DTS TPO0h01946:
4-ch card: When the HDLCABM or X25 protocol receives
a REJ frame while it is in the process of
retransmitting frames, it can get transmitted frames
out of sequence.
SR 5003398362 / DTS TPO0h01774:
There was a bug in the X.25 firmware code, which
caused queue corruption on the ACC whenever a short
DATA packet was received (that's one which is less
than the full packet size but with the M-bit set
and without the D-bit set). The error handling
causes the queue corruption. The ACC firmware can
survive for some time with this queue corruption, but
a lot of these errors will eventually cause the card
to fail.
SR None / DTS TPO0h01974:
The level-2 LAPB layer could mistakenly leave frames
on a transmit queue after the link has gone down.
These frames then corrupt the processing after the
link is re-established. A second bug causes the same
symptom by allowing a level-3 flow-control packet to
be transmitted after the SABM/UA exchange, with an
incorrect sequence number.
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.
TPO0h01893:
Reference to library "libzx25.a" has been added to the
x25stat man page.
PHNE_14011:
SR NONE / DTS TPO0h01833
Firmware failures with FRAME and HDLCABM concurrently in use
SR NONE / DTS TPO0h01640
2ch card transmits bad frame on link startup
SR NONE / DTS TPO0h01755
hdlcabm sends REJ on I-frame with duplicate N(s)
SR NONE / DTS TPO0h01641
frame reject cause information is bad on unknown frame type
SR:
8606181518 8606181300 8606176420 8606161688 8606152413
8606171991 4701380667 4701391862 5003398362 5003437947
Patch Files:
/opt/acc/protocol/zx25.zrel
/usr/conf/master.d/zx25
/usr/conf/lib/libzx25dsyms.o
/opt/acc/msg/def.zx25d.txt
/opt/acc/protocol/hdlcabm.zrel
/opt/acc/share/man/man3.Z/x25stat.3x
/opt/acc/z7350a/x25.zabs
/opt/acc/z7350a/x25.zmap
/opt/acc/z7200a/x25.zabs
/opt/acc/z7200a/x25.zmap
/opt/acc/z7400a/x25.zabs
/opt/acc/z7400a/x25.zmap
/usr/conf/lib/libzx25d.a
/usr/conf/acc/zx25_trace.h
what(1) Output:
/opt/acc/protocol/zx25.zrel:
ZCOM X.25 Protocol
ACC Rel B.02.40-B.2.40.02 for B.10.20 PHNE_18717 zx
25.z8
ZCOM X.25 Level 2
ACC Rel B.02.40-B.2.40.02 for B.10.20 PHNE_18717 ab
m.cpp
ZCOM HDLC ABM State Tables Rev:1.12 981123.1126
ACC Rel B.02.40-B.2.40.02 for B.10.20 PHNE_18717 ab
mfsmt
/usr/conf/master.d/zx25:
None
/usr/conf/lib/libzx25dsyms.o:
ACC Rel B.02.40-B.2.40.02 for B.10.20 PHNE_22520 lib
zx25dsyms.o
/opt/acc/msg/def.zx25d.txt:
None
/opt/acc/protocol/hdlcabm.zrel:
ZCOM HDLC ABM Protocol
&n