 |
» |
|
|
|
|  | |
This chapter contains an explanation of the ZCOM Subsystem
messages that may be logged by the base drivers, LDM and DAM. These
messages are identified by the label "zcom". Meaning of Messages | |
zcom 00000: System
bootup - Explanation:
This message is automatically logged by the LDM when
the HP-UX system is booted up. - Action:
None required, this is an informational message.
zcom 00001 - 00080: Not used zcom 00081: Can't
add timer messages: <ZCOM error text> - Explanation:
This message is reported by the ZCOM timer module when
it tries to add a timer message to a ZLU queue. The reason is also
reported. - Action:
Check the ZCOM error and determine the action. The most
common reason is "Not enough system free buffer",
which indicates the ZCOM buffer pool is too small, or there is abnormal
use of buffer.
zcom 00101: Unknown
ZCOM request, request id = <#> - Explanation:
An illegal application request was passed to the
LDM for processing. This could be caused by an incompatible ZCOM
API library, or an internal defect in the LDM. - Action:
Rectify any potential problem with software revisions. If
problem persists, inform your HP Support Representative.
zcom
00102: Flushed <#> message(s) on closing ZLU <#> - Explanation:
When a ZLU is to be closed or mapped (to another ZLU),
if the LDM finds some pending messages queued on that ZLU, it flushes
the queue and releases all buffers to the buffer pool. These messages
are reported when this happens. - Action:
None needed, this is an informational message.
zcom
00111: Can't get free buffer: corrupted free buffer at <#> - Explanation:
This error is reported by the buffer pool manipulation routines
when they detect a data corruption problem in the buffer header
linkages. This is a serious problem, most likely due to an internal
defect in the product (although this could also be caused by a defect
in another HP-UX or customer supplied kernel module). The ZCOM subsystem
will not function properly if this occurs. - Action:
You should immediately shutdown the ZCOM subsystem
(using zmon stop) and then
restart it again. This will correct the ZCOM data structure corruption problems
and restore the ZCOM subsystem to a normal operating state. If other
HP-UX subsystems are experiencing problems, you may wish to reboot
the system. If the problem persists, contact your HP Support Representative.
zcom
00121: Initiate reset with <#> active ZCOM requests - Explanation:
When a user initiates a ZCOM subsystem shutdown while
there are application requests currently in progress, the LDM will
wait for 5 seconds before it forces the ZCOM subsystem to shutdown.
These two messages report the number of active application requests
in progress when the LDM forced the ZCOM subsystem to shutdown. - Action:
None needed, this is an informational message.
zcom 00131: Can't
get buffer data: short length (<#> bytes) at <#> - Explanation:
This error is reported when the LDM tries to read
from a buffer and finds that it is too small to hold the ZCOM message
header. This indicates an illegal buffer was found in the ZCOM subsystem.
It is usually caused by data corruption or software problem with
the ZCOM buffer handling routines. - Action:
Contact your HP Support Representative.
zcom 00141: Unknown
ZMUX request, request id = <#> - Explanation:
An illegal interface request was passed to the LDM
for processing. This could be caused by incompatible ZCOM API library,
or an internal defect in the LDM. Currently, only ZMON and ZCBUG
can issue these interface requests. - Action:
Verify that the correct revisions of the product
have been installed and correct any discrepancies as needed. If
the problem persists, contact your HP Support Representative.
zcom 00150: Error
in copying data from ZNODE: <error text> - Explanation:
This error is reported when there is a problem in copying
data from ZNODE's program data space to the LDM's
kernel data space. This could indicate inconsistencies in the versions
of the ZCOM kernel drivers and the ZNODE daemon. This error will
cause ZNODE to terminate, thereby resulting in all remote nodes
being inaccessible. - Action:
Verify that the correct revisions of the product
have been installed and correct any discrepancies as needed. Specifically,
do a what on HP-UX and ZNODE and verify that the revision codes
of ZNODE and the ZCOM drivers match. If the problem persists, contact
your HP Support Representative.
zcom 00151: Invalid
API response ID <#> returned from node <#> - Explanation:
The LDM has received from ZNODE a remote API call completion
response with a response ID that does not match the original request.
The LDM assigns a response ID whenever a remote API request is issued and
stores this information in a response record. When the completion
response for the request arrives from the remote, the response ID
is validated. This error could be caused by incompatible revisions
of the ZCOM software being installed on the local and remote nodes, data
corruption during the inter-system transfer, or an internal defect
in the ZCOM subsystem. - Action:
Verify that all systems running the ZCOM software have
been installed with the same version (release) and correct as needed.
Verify that your communication links are operating properly. If
the problem persists, contact your HP Support Representative.
zcom 00152: Late API
response returned from node <#> - Explanation:
The LDM received a remote API request response after it
had timed out the original request. When a ZCOM request is issued
to a remote node, the LDM sends the request and allows a fixed (configurable)
amount of time for the request to be completed (response to arrive).
After this amount of time has expired, the LDM automatically completes
the request with an error of ZENTOUT (-23, Remote node timed out).
If the response to this request arrives at a later time, this error
message is logged and the response is ignored. - Action:
If this error occurs too often, increase the remote
node timeout value specified in the Remote-Node definition of
your TTGEN configuration file. In addition, you should verify that
the communication links are operating properly.
zcom 00153: Can't
save response from node <#>: <error text> - Explanation:
The LDM received a valid response from the indicated remote
node, but it was unable to allocate a ZCOM memory buffer to save
the response data. The requesting application will receive the error ZERSPLOST
(-42, No buffer for remote response) when this condition occurs.
The remote request was successfully processed by the remote node.
This error has two principle causes; either the Buffer-Pool parameter in the TTGEN
configuration file is too small or there is an application programming
error that is causing all of the ZCOM buffers to be consumed. - Action:
Use the zscan utility
to check for abnormal buffer usage and correct the application if
necessary or increase the size of the Buffer-Pool parameter
in the TTGEN configuration file.
zcom 00154: Dropped
data not for this node (from node <#> to <#>) - Explanation:
The LDM received data from a remote node that does not
appear to be intended for the local ZCOM subsystem. The source and
destination node numbers from the original request are displayed
in the message. The request message (data) has been discarded. This error
most likely is due to inconsistencies in the Node-Definition sections
of the TTGEN configuration files on the different systems. - Action:
Verify that the correct node numbers and host addresses
have been supplied and are consistent across all systems running
the ZCOM software. Correct any inconsistencies in the TTGEN configuration
file as needed.
zcom
00155: Dropped data from node <#> to ZLU <#>: <error
text> - Explanation:
The local LDM received data from the indicated remote node
that is destined for the specified local ZLU. However, when the
LDM attempted to deliver the data to the ZLU a problem occurred.
The data is discarded and the specific reason for the problem is
given in the error text. Usually
this is due to an application programming error (bad parameter in
the original request). Two different error numbers are used based on
the specific internal operation that failed. - Action:
Examine the error text and
correct the application software as necessary.
zcom 00157: Can't
read ZNODE queue: <error text> - Explanation:
The LDM attempted to retrieve a request from its internal
ZNODE queue but encountered an unexpected error. The specific reason
for the error is given in the error text displayed
in the message. Depending on the error, ZNODE may terminate. - Action:
Examine the error text and
correct the problem if possible. Check for possible incompatible
versions of ZCOM software installed. Try shutting down and restarting
the ZCOM subsystem. If the problem persists, contact your HP Support
Representative.
zcom 00158: Can't
send error to node <#>: <error text> - Explanation:
The LDM attempted to place an error response on
the ZNODE queue to be passed back to the remote application but
encountered an unexpected error. The specific reason for the error
is given in the error text displayed
in the message. The completion response message is lost and the
remote application will eventually receive a ZENTOUT (-23, Remote
node timed out) error for the request. - Action:
Examine the error text and
correct the problem if possible. Check for possible incompatible
versions of ZCOM software installed. Try shutting down and restarting
the ZCOM subsystem. If the problem persists, contact your HP Support
Representative.
zcom 00159: Can't
build response for node <#>: <error text> - Explanation:
The LDM attempted to link a deferred response to
a response record for a remote request (e.g. zsend mode 8),
but detected an unexpected error. The specific reason for the error
is given in the error text displayed in
the message. The completion response message is lost and the remote
application will eventually receive a ZENTOUT (-23, Remote node
timed out) error for the request. - Action:
Examine the error text and
correct the problem if possible. Check for possible incompatible
versions of ZCOM software installed. Try shutting down and restarting
the ZCOM subsystem. If the problem persists, contact your HP Support
Representative.
zcom 00160: Can't
send message to node <#>: <error text> - Explanation:
The LDM tried to place application data or a response message
for the indicated remote node on the ZNODE queue but encountered
an unexpected error. The specific reason for the error is given
in the error text displayed
in the message. The application data or response message is discarded.
This may affect the remote application. - Action:
Examine the error text and
correct the problem if possible. Check for possible incompatible
versions of ZCOM software installed. Try shutting down and restarting
the ZCOM subsystem. If the problem persists, contact your HP Support
Representative.
zcom 00161: Can't
send response to node <#>: <error text> - Explanation:
The LDM attempted to place a response message on the
ZNODE queue to be passed back to the remote application but encountered
an unexpected error. The specific reason for the error is given
in the error text displayed
in the message. The completion response message is lost and the
remote application will eventually receive a ZENTOUT (-23, Remote
node timed out) error for the request. - Action:
Examine the error text and
correct the problem if possible. Check for possible incompatible
versions of ZCOM software installed. Try shutting down and restarting
the ZCOM subsystem. If the problem persists, contact your HP Support
Representative.
zcom 00162: ZNODE
inactive for <#> seconds, all nodes down - Explanation:
During normal remote node operations, ZNODE issues periodic
requests to the LDM to indicate that it is functioning properly.
This message is logged when ZNODE has not communicated with the
LDM for the indicated number of seconds. The LDM will mark all remote
nodes as down. In addition, the local node is also marked down to
indicate that ZNODE does not appear to be running. Any requests
requiring remote node access are rejected with error ZENDOWN (-61, Remote
node is DOWN). This message may or may not indicate a problem. It
will be logged if ZNODE was not scheduled (remote nodes not used). - Action:
If remote node functionality is not needed or used,
this message is normal and can be ignored. However, if the application
expects to make requests to remote ZCOM nodes, corrective action
is needed. Make sure that ZNODE is being scheduled (check the /usr/zcomopt/acc/cfg/zmasterd_list
file if starting the ZCOM subsystem with zmasterd).
If it is determined that ZNODE is terminating abnormally or is running when
this message is logged, contact your HP Support Representative.
zcom 00163: ZNODE
has terminated, all nodes set DOWN - Explanation:
This message is logged when the LDM detects that ZNODE
has terminated. ZNODE could have terminated abnormally (core dump),
been killed (kill -9), or the user could have shutdown znode (zmasterd deact
znode). The LDM will mark all remote nodes as down. In addition,
the local node is also marked down to indicate that ZNODE is no
longer running. Any requests requiring remote node access are rejected with
error ZENDOWN (-61, Remote node is DOWN). This message may or may
not indicate a problem. - Action:
If znode was killed or deactivated using zmasterd,
the message is normal and can be ignored. However, if the application
expects to make requests to remote ZCOM nodes, corrective action
is needed. If it is determined that ZNODE is terminating abnormally,
contact your HP Support Representative.
zcom 00164: Node <#> has
gone DOWN - Explanation:
This message is logged when the local system is
no longer receiving heartbeat messages from the indicated remote
node. This means either the communication link(s) has gone down,
the remote node has failed, or the remote ZNODE has been shutdown.
The indicated remote node is now inaccessible. All remote requests
to this node are rejected with error ZENDOWN (-61, Remote node is
DOWN). - Action:
Check the relevant ZCOM message log files for other related
error messages. Correct the problems as needed.
zcom 00165: Node <#> is
now UP - Explanation:
This message is logged when a remote node previously marked
as down begins to receive heartbeat messages (or request) from the
indicated remote node. The remote node can now be accessed and any
request issued to this node will be processed normally. - Action:
None. This is an informational message.
zcom 00166: Node <#> link <#> DOWN: <text> - Explanation:
This message is logged when one of the links to
a remote node has gone down. The Remote-Node definition
in the TTGEN configuration file allows up to four links to be specified.
The links are numbered from 0 to 3. This message will be followed
by a node down message (zcom 164) if this link is the only one defined or
is the last usable link for the associated remote node. - Action:
Check for network problems and correct as necessary. When
the link is returned to normal operation, zcom message 167 will
be logged.
zcom 00167: Node <#> link <#> UP: <text> - Explanation:
This message is logged when a communication link
to a remote node has come back on-line after previously being down.
The Remote-Node definition
in the TTGEN configuration file allows up to four links to be specified. The
links are numbered from 0 to 3. This message indicates that the
specified link is now operating normally. - Action:
None. This is an informational message.
zcom 00168: Can't
send event to ZLU <#>: <error text> - Explanation:
This message is logged when the LDM is unable to queue
an event message on the indicated program ZLU. The specific reason
is given in the error text.
This is usually caused by a problem in the application program (e.g.
the program ZLU has been closed, hitting the queue limit, etc).
When this messages is logged, the specified program ZLU will not
receive that event message. This will not cause a problem within
the ZCOM subsystem, but may affect the application. - Action:
Correct the application source code.
zcom 00169: Not enough
memory for Buffer-Pool size of <#> bytes Buffer-Pool
size reduced to <#> bytes. - Explanation:
This message is logged during ZCOM subsystem startup
if the LDM finds the specified Buffer-Pool size in the ttgen configuration
file is larger than what the kernel can accommodate. When kernel memory is not sufficient to meet the ttgen configuration,
the memory reserved for Buffer-Pool is reduced to allow system startup.
The other ZCOM tables are not affected. The user should make sure
the reduced buffer-pool size can still allow normal operations. - Action:
The ttgen configuration file should be reviewed
to see whether unnecessary tables can be reduced (e.g. too many
program or terminal ZLUs defined, too many unused node entries).
Otherwise, should consider increasing the kernel memory for ZCOM.
The total size of the ZCOM memory in kernel is configurable, by
the zcom_mem_size tunable parameter
(usually added to /stand/system).
See Appendix B for detailed description.
zcom 00170: Buffer-Pool
size set to <#> bytes. - Explanation:
This message is logged during ZCOM system startup
if the LDM finds the specified Buffer-Pool size in the ttgen configuration
file is smaller than what the kernel can accommodate. The LDM will
allocate more memory to the Buffer-Pool, so as to use up all the
kernel memory reserved for the ZCOM system. - Action:
The user should make sure the intended use of memory is
correct. The 'extra' memory is not because of incorrect
ttgen configuration. If it is not desirable to use a large Buffer-Pool
(e.g. in a small testing system with only limited memory), the total
size of the ZCOM memory in kernel is configurable through the zcom_mem_size tunable parameter (usually
added to /stand/system). See
Appendix B for detailed description.
zcom
00200: Warning - DMA complete received on port <#> with
no DMA active. - Explanation:
This message is logged whenever the ACC Device Adapter
Manager (DAM) receives a DMA completion interrupt but the DAM has
determined that no DMA operation is in progress. The DMA completion interrupt
will be ignored by the DAM. - Action:
In most cases, you may safely ignore this message. However,
if this message occurs frequently or unusual behavior is exhibited
by the ACC/X.25 subsystem, contact your HP Support Representative.
This message may be symptomatic of failing hardware (either the ACC
Mux card or some component in your system).
zcom
00201: Card <#> - System powerfail detected - Explanation:
This message is logged whenever the DAM receives
a system powerfail notification message. The ZCOM subsystem will
automatically reinitialize all Mux cards and restart any operations
in progress at the point of the power failure. - Action:
No further action is necessary.
zcom
00202: Card <#> - Backplane command (DMA) has
timed out! - Explanation:
This message indicates that a DMA transaction has not
completed within a predefined period of time. This can occur as
the result of a Mux card firmware failure or a hardware failure
in either the Mux card or some other component of the I/O subsystem.
The ZCOM subsystem will automatically reinitialize this Mux card and
restart any operations in progress at the point of the DMA failure. - Action:
Run hardware diagnostics on the Mux card. If this
does not appear to be a hardware problem and the problem persists,
contact your HP Support Representative.
zcom 00203: Card <#> -
Firmware failure detected (card reset)! - Explanation:
The DAM received an unsolicited interrupt from
an ACC Mux card indicating that the ZCOM Mux card firmware has experienced
some kind of fatal error (internal defect). The card will be reinitialized
and all operations in process at the time of the firmware failure
will be restarted. - Action:
Contact your HP Support Representative.
zcom
00204: Card <#> - failure detected (card reset)! - Explanation:
The DAM has received an unsolicited interrupt which indicates
that a fatal error has occurred in the DMA operation. This typically
can occur as the result of an abnormality in the operation of the
DAM related hardware. The card will be reinitialized and all operations
in process at the time of the failure will be restarted. - Action:
If the problem persists, swap out the Mux card.
You may wish to run diagnostics on the Mux card.
zcom 00205: Unrecognized
port server message, desc <#>, port <#> - Explanation:
The ACC DAM received an LLIO message on its port server
routine that was an unknown message type. The DAM will ignore this
message. This could be due to a defect in any of the HP-UX drivers.
(e.g. a Logical Device Manager or Device Manager sent an I/O message
to the wrong port). - Action:
If the problem persists or abnormal behavior is observed,
you should contact your HP Support Representative.
zcom 00206: Card <#> Port <#> configuration
failed with error <#>. - Explanation:
A $PORT backplane transaction was issued to the ACC
Mux card which completed with an error. This could be due to an
illegal configuration or a self-test failure for that port. - Action:
If due to a bad configuration, correct your TTGEN configuration
file. If the port failed its self-test, the port will remain unusable.
You will need to replace the ACC Mux card to correct that condition.
If this does not appear to be either a hardware problem or configuration
problem, contact your HP Support Representative.
zcom 00207: ZLU <#> Set
terminal parameters failed with error <#>. - Explanation:
A $TERM backplane transaction to set the terminal (ZLU)
parameters was issued to the ACC Mux card which completed with an
error. This could be due to a bad TTGEN configuration. - Action:
If due to a bad configuration, correct your TTGEN configuration
file. If this does not appear to be either a hardware problem or
configuration problem, contact your HP Support Representative.
zcom 00208: ZLU <#> Enable/Activate
terminal failed with error <#>. - Explanation:
A $TERM backplane transaction to enable and/or activate
a terminal ZLU was issued to the ACC Mux card which completed with
an error. This could be due to a bad TTGEN configuration. - Action:
If due to a bad configuration, correct your TTGEN configuration
file. If this does not appear to be either a hardware problem or
configuration problem, contact your HP Support Representative.
zcom 00209: Improperly
configured ZLU <#> found during card restart. Most
likely this is due to an application defect. The application did
not issue a zcntl (ZCOM_MRCODE_TERM) request. - Explanation:
While attempting to initialize all of the terminal
ZLUs configured into an ACC Mux card, the DAM found a Physical Terminal
Table entry which was marked as not in use. However, this condition
is inconsistent with the data in the Interface Table structure for
this card. - Action:
Contact your HP Support Representative.
zcom 00210: Card <#> timed
out (no terminal heartbeat status)! - Explanation:
When there are no user initiated requests to the
ACC Mux card, the card will send status on a regular basis (every
10 seconds) to inform the DAM that the Mux card is still functioning
properly. This message is logged when the Mux card has failed to
send its heartbeat status after 30 seconds. This typically indicates
that the Mux card has failed due to an internal defect in the Mux
card firmware or some form of hardware failure. The ZCOM subsystem
will automatically reinitialize this Mux card and restart any operations
in progress at the point of the failure. - Action:
Run hardware diagnostics on the Mux card in question. If
this does not appear to be a hardware problem and the failure persists,
contact your HP Support Representative.
zcom
00211: Card <#> - NULL PTT entry in IFT->ifplook[]
table! Port number = <#> Terminal
number = <#>. - Explanation:
The ifplook data
structure is used by the DAM to vector inbound data and status to
the correct Physical Terminal Table entry which the event is to
be queued on. However, the DAM did not find a valid pointer in the ifplook table entry indicated by
the Mux firmware. The DAM has discarded the data and/or status information. - Action:
Contact your HP Support Representative.
zcom 00212: Card <#> write
completion with none outstanding! Port number = <#> Terminal
number = <#> - Explanation:
In the normal processing of requests, the DAM will issue
a request to the ACC Mux card firmware and place the request onto
a queue of requests waiting for a completion acknowledgment from
the Mux firmware. The Mux after actually performing the request
will send unsolicited status to the DAM indicating that the previously
issued request is now complete. In this case, the DAM has received
unsolicited completion status from the Mux firmware for a terminal
that does not have any unacknowledged requests. - Action:
If abnormal behavior is observed or the problem persists,
contact your HP Support Representative.
zcom 00213: Card <#> ZLU <#> Error
on read (length mismatch)! - Explanation:
Processing of inbound data and status is a two step process.
First the DAM receives an unsolicited interrupt packet indicating
the type of inbound data and its length. The DAM then issues a transaction
to the Mux card to read the inbound data or status packet. Within
this packet is the length of the data. If this length does not match
the length indicated in the unsolicited interrupt packet, then the
DAM logs this message. - Action:
If abnormal behavior is observed or the problem persists,
contact your HP Support Representative.
zcom 00214: Card <#> ZLU <#> No
receiver - data dropped. - Explanation:
Inbound data and/or status information has arrived for
a ZLU that does not have an application setup to receive the information.
The DAM will discard the inbound data and/or status information. - Action:
In order to prevent this information from being
lost, an application must issue a zset_rcvr call
for each ZLU that it wants data from.
zcom 00215: Card <#> ZLU <#> Receiver
is not a program ZLU <#>. - Explanation:
When inbound data and/or status arrives from a terminal
ZLU, it may only be delivered to a program ZLU. An application has
apparently setup this ZLU to deliver its inbound data to a non-program
ZLU. - Action:
Correct the application.
zcom 00216: Card <#> ZLU <#> Queue
limited for inbound data. - Explanation:
When a program ZLU is created the application can select
the maximum amount of inbound data and/or status that can be queued
onto the ZLU. This message is logged when that limit has been exceeded.
The data and/or status information is thrown away when this limit
is exceeded. - Action:
If you wish to avoid this condition, increase the
queue limit for this ZLU and/or insure that the application reads
its inbound data promptly.
zcom 00217: Card <#> ZLU <#> Zc_qmove
(txqa) failed! - Explanation:
After sending a request to the ACC Mux card, the
DAM attempted to place the request onto its queue of unacknowledged
transactions. This operation has unexpectedly failed. - Action:
Contact your HP Support Representative.
zcom 00218: Card <#> ZLU <#> Zc_qmove
(txqb) failed! - Explanation:
After sending a request to the ACC Mux card, the
DAM attempted to place the request onto its queue of unacknowledged
transactions. This operation has unexpectedly failed. - Action:
Contact your HP Support Representative.
zcom
00219: Card <#> Port <#> Port
is out of transmit buffers. - Explanation:
This message indicates that the ACC Mux card has temporarily
consumed all of its internal transmit data buffers and is currently
unable to accept another request. The DAM will send the request
again when this condition is alleviated. If this condition occurs frequently,
it will have a negative impact on performance. - Action:
No action is necessary. However, you may wish to adjust
the Unack-Limit and Port-Limit (or E1T1-Port-Limit)
parameters downward in your TTGEN configuration file to avoid this
condition.
zcom 00220: Card <#> system
is out of data buffers! - Explanation:
This message is logged whenever new inbound data arrives
and the DAM is unable to allocate another ZCOM subsystem buffer
to hold the data. The DAM will be unable to process the unsolicited
interrupt indicating inbound data and/or status. The Mux firmware
will continue to attempt to send the inbound data up until this
condition clears itself. - Action:
Make sure that applications are reading their inbound data
queues. You may also want to increase the value of the "BUFFER-POOL" parameter
in your TTGEN configuration file.
zcom 00221: Card <#> found
unrecognizable step of type <#>. - Explanation:
This message is due to an internal defect in the
Device Adapter Manager. - Action:
Contact your HP Support Representative.
zcom
00222: ZLU <#> RXDT bad reply (status = <#>),
data dropped! - Explanation:
This message can occur when the DAM issues a request
to read inbound data and the Mux firmware cannot find any inbound
data to send or if the length of the inbound data requested by the
DAM is different then the length maintained by the Mux firmware. - Action:
Contact your HP Support Representative.
zcom
00223: Card <#> Port <#> Term <#>:
Zc_qbadd failed with error <#>! Unable
to allocate a buffer for inbound data. - Explanation:
While attempting to allocate a ZCOM subsystem buffer for
inbound data an unexpected failure occurred. - Action:
Examine the error returned and check the ZCOM manuals.
If this appears to be an internal defect in the product and abnormal
behavior is observed or this problem reoccurs, contact your HP Support Representative.
zcom 00224: Card <#> External
interrupt arrived during DMA operation. - Explanation:
The DAM was entered with an interrupt message during
a DMA operation but the interrupt was not a DMA completion interrupt. - Action:
In most cases you can ignore this message. However,
if this problem occurs frequently or if abnormal behavior is observed,
it might indicate a pending hardware failure.
zcom 00225: Card <#> Port <#> RXDT15
bad reply (status = <#>), data dropped! - Explanation:
This message can occur when the DAM issues a request
to read inbound data and the Mux firmware cannot find any inbound
data to send or if the length of the inbound data requested by the
DAM is different then the length maintained by the Mux firmware. - Action:
Contact your HP Support Representative.
zcom 00226: Card <#> Port <#> Error
on $RXDT15 read (length mismatch). - Explanation:
Processing of inbound data and status is a two
step process. First the DAM receives an unsolicited interrupt packet
indicating the type of inbound data and its length. The DAM then
issues a transaction to the Mux card to read the inbound data or
status packet. Within this packet is the length of the data. If this
length does not match the length indicated in the unsolicited interrupt
packet, then the DAM logs this message. - Action:
If abnormal behavior is observed or the problem persists,
contact your HP Support Representative.
zcom 00228: Write
completion length mis-match on ZLU <#>. FIRQ length
was <#> bytes but message length was <#> bytes. - Explanation:
After an outbound write request is completed by
the Mux firmware, it passes a write completion acknowledgment unsolicited
status to the DAM. Within this status is the length of the original
write request. This message is logged when the length in the unsolicited
status does not match the length of the actual write request. - Action:
If abnormal behavior is observed or the problem persists,
contact your HP Support Representative.
zcom
00229: Card <#> Port <#> No
buffers and no requests pending - Explanation:
This message is logged when the DAM is notified
by the ACC MUX firmware that their are no available buffers on the
card, but the DAM has no outstanding write request to the card.
This is a rare but potential condition that can arise with a complex
protocol such as X.25 and can normally be ignored. - Action:
If abnormal behavior is observed or the problem persists,
contact your HP Support Representative.
zcom
00230: Card <#> - Firmware failure detected,
bad IRQ type (card reset)! - Explanation:
During normal operations the MUX firmware will send an
unsolicited message to the DAM to indicate that inbound data is
available or a previous write request has completed. However, this
message will be logged if the unsolicited message (FIRQ) type was unrecognizable
by the DAM. The DAM will automatically reset the MUX card (reboot)
when this occurs. - Action:
Swap the hardware with a known good ACC MUX card. If
the problem still persists, contact your HP Support Representative.
zcom 00231: ZLU <#> receiver
data dropped: <error text> Unable to create a
copy of data for a shared receiver. - Explanation:
When more than one receiver for a terminal ZLU
is defined, the drivers must queue the inbound data message on each
program's input queue. However, when the driver attempted
to create the data structures to link the data to each input queue,
the operation unexpectedly failed. The error
text contains the specific reason for the failure. The
most probable failure cause is lack of ZCOM buffer space. That is,
the driver was unable to allocate memory for the structure required
to link the data to the shared receiver. - Action:
Make sure that applications are reading their inbound data
queues. You may also want to increase the value of the "Buffer-Pool" parameter in
your TTGEN configuration file.
zcom 00232: Card <#> -
Firmware failure induced (card reset)! - Explanation:
When a serious inconsistency is detected in the transaction
data sent by the mux card firmware, the DAM will force an upload
of the mux card memory followed by a reset of the mux card. This
causes a fresh copy of the mux firmware to be downloaded into the card.
The previous message logged indicates the specific type of failure
which has occurred. - Action:
This is an internal problem. Contact your HP Support Representative
and provide them with the mux memory dump file, ttgen configuration
file, and ZCOM log files.
zcom 00233: Card <#> -
sio_map() failure! Cmd = 0x########. - Explanation:
This is an internal defect. - Action:
Contact your HP Support Representative.
zcom 00234: Card <#> -
sio_map(<%s>) failure! - Explanation:
This is an internal defect. - Action:
Contact your HP Support Representative.
zcom 00235: Card <#> -
I/O suspended due to lack of ZCOM buffers. - Explanation:
When the ACC card indicates an inbound data buffer needs
to be transferred to the host, the driver attempts to allocate a
buffer to DMA the data into. This message is logged when there are
no free buffers remaining in the ZCOM buffer pool. The driver has
disabled the card from interrupting it for inbound data requests
until there is sufficient free space available in the buffer pool. - Action:
This is usually due to an improperly coded application which
uses the ZCOM API. Most likely, an application is failing to read
inbound data from its program ZLU. This could also occur if the
application terminates with out cleaning up its program ZLUs and
removing any receivers it has setup. In rare cases, it could be
due to a Buffer-Pool parameter
value that is too small.
zcom 00236: Card <#> -
ZCOM buffers now available, I/O resumed. - Explanation:
This message is logged when the driver has had to suspend
inbound data processing due to a lack free space (buffers) in the
ZCOM buffer pool and the driver now detects that sufficient free
space is available to continue processing inbound data. - Action:
This is an informational message.
zcom 00237: Card <#> -
Firmware detected error code =0x######## - Explanation:
This is an internal defect. - Action:
Contact your HP Support Representative.
zcom 00250: Card <#> -
Update interrupt state timeout! - Explanation:
This is an internal defect. - Action:
Contact your HP Support Representative.
zcom 00251: Card <#> -
NORQ interrupt with none outstanding! - Explanation:
This is an internal defect. - Action:
Contact your HP Support Representative.
zcom 00252: Card <#> -
Too few or too many quads in backplane request. - Explanation:
This is an internal defect. - Action:
Contact your HP Support Representative.
zcom 00305: Card <#> Internal
error: Transmit requeue stack not empty on exit! - Explanation:
This is an internal defect. - Action:
Contact your HP Support Representative.
zcom 00306: Card <#> Port <#> Invalid
request code on port list! - Explanation:
This is an internal defect. - Action:
Contact your HP Support Representative.
zcom 00307: Card <#> Port <#> Ran
out of DMA quads for port config data! - Explanation:
This is an internal defect. - Action:
Contact your HP Support Representative.
zcom 00308: Card <#> Ran
out of DMA quads for transmit request! - Explanation:
This is an internal defect. - Action:
Contact your HP Support Representative.
zcom 00309: Card <#> Ran
out of DMA quads for inbound data! - Explanation:
This is an internal defect. - Action:
Contact your HP Support Representative.
zcom 00311: Card <#> Term <#>:
Invalid IRQ request code <#>! Forcing MUX dump. - Explanation:
This is an internal defect. - Action:
Contact your HP Support Representative.
zcom 00312: Card <#>:
Requested <#> IRQs but available IRQs is <#>. - Explanation:
This is an internal defect. - Action:
Contact your HP Support Representative.
zcom 00313: Card <#>:
$STAT returned illegal terminal #<#>. Terminal ignored. - Explanation:
These are internal defects. - Action:
Contact your HP Support Representative.
zcom 00321: Card <#>:
Invalid pending IRQ count 0x<#> - Explanation:
These are internal defects. - Action:
Contact your HP Support Representative.
zcom 00322: Card <#>:
Invalid terminal number (<#>) in IRQ entry! - Explanation:
These are internal defects. - Action:
Contact your HP Support Representative.
zcom
99990: <Debug message> - Explanation:
These are driver debug messages from the LDM. Normally,
these messages should not appear unless debug mode is enabled via
ZMON. Driver debugging is intended for internal use only and is
not recommended for general users. - Action:
Use "zmon nodebug" to
disable driver debugging.
|
Printable version
