SDI Driver Specific Status Values

CAUSE: During a link-open operation by an upper level subsystem, the link module configurator was preparing to send configuration data to the driver, but encountered an error while trying to freeze that data into memory ("Cause"= 32-bit status from the call to freeze).

ACTION: The system may be low on available memory. Try closing any unnecessary applications or sessions and retry the operation. The open did not succeed. The module configurator cleaned up and returned an error to the subsystem.

CAUSE: During a link-open operation by an upper level subsystem, the link module configurator was preparing to send configuration data to the driver, but encountered an error while trying to send the port message ("Cause"= 32-bit status from the call to send_msg).

ACTION: There may be a system problem, or another subsystem has already shut the driver down while this one was trying to start it. The open did not succeed. The module configurator cleaned up and returned an error to the subsystem.

Retry the operation. If this does not help, try stopping all networks using the link, then retry. If the problem still persists, halt the system and take a memory dump, then see Appendix A “Submitting an SR ”

CAUSE: During a link-open operation by an upper level subsystem, the link module configurator sent configuration data to the driver, then encountered a timeout while awaiting the correct reply message ("Cause"= 32-bit status from the call to extend_receive, saying there was a timeout).

ACTION: The link driver is probably hung because of a problem in the driver, or the driver may have sent the wrong message back. The open did not succeed. The module configurator cleaned up and returned an error to the subsystem.

Perform a :LINKCONTROL @ command to see if an entry exists for the linkname being started. If so, then run the VBPBA diagnostic tool and attempt to force a driver dump. If that works, save the resulting NETDMP##.PUB.SYS file for analysis by Hewlett-Packard. Otherwise, halt the system and take a memory dump. The dump should tell Hewlett-Packard what actions the driver took. See Appendix A “Submitting an SR ”

CAUSE: During a link-open operation by an upper level subsystem, the link module configurator sent configuration data to the driver, then encountered an error while awaiting the correct reply message ("Cause"= 32-bit status from the call to extend_receive).

ACTION: There may be a system problem with message ports, or the link driver may have sent the wrong reply message. The open did not succeed. The module configurator cleaned up and returned an error to the subsystem.

Perform a :LINKCONTROL @ command to see if an entry exists for the linkname being started. If so, then run the VBPBA diagnostic tool and attempt to force a driver dump. If that works, save the resulting NETDMP##.PUB.SYS file for analysis by Hewlett-Packard. Otherwise, halt the system and take a memory dump. The dump should tell Hewlett-Packard what actions the driver took. See Appendix A “Submitting an SR ”

CAUSE: During a link-open operation by an upper level subsystem, the link module configurator sent configuration data to the driver, but the driver returned an error in the reply message ("Cause" is not used here).

ACTION: If this error occurs, there may be additional driver-specific errors logged, giving more information about the problem. Attempt to locate those errors and look them up also. The open did not succeed. The module configurator cleaned up and returned an error to the subsystem.

CAUSE: During a link-open operation by an upper level subsystem, the link module configurator did not find an HP-PB bus at the hardware path specified in NMCONFIG ("Cause" is not used here).

ACTION: The module configurator cleaned up and returned an error to the subsystem.

Verify the path in NMCONFIG is correct and complete, and matches the path where a supported 100VG-AnyLAN or 100Base-T adapter card is installed in your computer backplane. If the path passes through bus converters, verify the SYSGEN configuration has entries for the higher-level bus converters leading to that path. A diagram of the backplane slot paths, often found in the rear of your system near the backplane, may help you. You can also try an offline diagnostic utility such as MAPPER, or an online utility such as SYSMAP, to precisely determine your hardware configuration. If necessary, change NMCONFIG or contact your Hewlett-Packard Representative for assistance in determining paths or correcting bus hardware problems.

CAUSE: During a link-open operation by an upper level subsystem, the link module configurator did not find a supported 100VG-AnyLAN or 100Base-T adapter card at the hardware path specified in NMCONFIG ("Cause"= 32-bit hex value from a system table which holds the first 4 bytes of IODC information from the adapter card).

ACTION: The module configurator cleaned up and returned an error to the subsystem.

Verify the path in NMCONFIG is correct and complete, and matches the path where a supported 100VG-AnyLAN or 100Base-T adapter card is installed in the computer backplane. Verify the Power LED is lit on that adapter. If necessary, reseat the board or contact your Hewlett-Packard Representative for hardware assistance.

CAUSE: During a link-open operation by an upper level subsystem, the link module configurator found a supported adapter card at the path specified in NMCONFIG, but it was not the right type of card for the link being started.

ACTION: Correct the network configuration or plug in the correct type of adapter card, and retry the operation. The module configurator cleaned up and returned an error to the subsystem.

CAUSE: During a link-open operation by an upper level subsystem, the link module configurator encountered an error while trying to create an outbound buffer pool ("Cause"= 32-bit status from the call to bmgr_create_pool).

ACTION: The system may be low on available memory. The module configurator cleaned up and returned an error to the subsystem.

Try stopping some applications or sessions and retry the operation. If the problem persists, stop all networking and restart it, or restart the system.

The buffer size and pool size are not configurable. If the problem still occurs, there could be a problem with the buffer manager. See Appendix A “Submitting an SR ”

CAUSE: During a link-open operation by an upper level subsystem, the link module configurator encountered an error while trying to create a control buffer pool ("Cause"= 32-bit status from the call to bmgr_create_pool).

ACTION: The system may be low on available memory. The module configurator cleaned up and returned an error to the subsystem.

Try stopping some applications or sessions and retry the operation. If the problem persists, stop all networking and restart it.

The buffer size and pool size are not configurable. If the problem still occurs, there could be a problem with the buffer manager. See Appendix A “Submitting an SR ”

CAUSE: During a link-open operation by an upper level subsystem, the link module configurator encountered an error while trying to load the code for the driver ("Cause"= 32-bit status from the call to io_get_mgr_entry).

ACTION: Probably not all software required to operate this type of link is installed. The software was incorrectly installed, or you may need to purchase additional software or install newer patches. Reinstall the link software or contact your Hewlett-Packard Representative for assistance.

CAUSE: During a link-open operation by an upper level subsystem, the link module configurator encountered an error while trying to load code for the write initiator procedure needed for the link type configured in NMCONFIG ("Cause"= 32-bit status from the call to hpgetsysplabel).

ACTION: Probably not all software required to operate this type of link is installed. Software was incorrectly installed, or you may need to purchase additional software or install newer patches. Reinstall the link software or contact your Hewlett-Packard Representative for assistance.

CAUSE: During a link-open operation by an upper level subsystem, the link module configurator attempted to create a new instance of the link driver, but discovered the driver was already created ("Cause"= 32-bit status from the call to io_configure).

ACTION: This event is informational. No action is required. It probably would not appear as a log event. The module configurator will ignore this warning and continue to bring the link driver up, so that the number of users may be checked. May be followed by another error.

CAUSE: During a link-open operation by an upper level subsystem, the link module configurator attempted to create a new instance of the link driver, but encountered an error which was not one of the legal errors the configurator was able to handle ("Cause"= 32-bit status from the call to io_configure).

ACTION: The module configurator cleaned up and returned an error to the subsystem.

Verify the path in NMCONFIG is correct and complete, and matches the path where a supported 100VG-AnyLAN or 100Base-T adapter card is installed in your computer backplane. If the path passes through bus converters, verify the SYSGEN configuration has entries for the higher-level bus converters leading to that path. A diagram of the backplane slot paths, often found in the rear of your system near the backplane, may help you. You can also try an offline diagnostic utility such as MAPPER, or an online utility such as SYSMAP, to precisely determine your hardware configuration. If necessary, change NMCONFIG or contact your Hewlett-Packard Representative for assistance in determining paths or correcting bus hardware problems.

CAUSE: During a link-open operation by an upper level subsystem, the link module configurator encountered an error while trying to open the configuration file ("Cause"= 32-bit status from the call to nmconfopen).

ACTION: The module configurator cleaned up and returned an error to the subsystem.

Verify an NMCONFIG.PUB.SYS file exists. If so, try to verify its format matches rest of the operating system. If the system was updated, you may need to run NMMGRVER.PUB.SYS to convert the file to a newer format. If the system was backdated, you may need to restore an older copy of NMCONFIG from a backup tape.

Perform a :LISTF,3 command and make sure the file is not protected by a lockword, and that the user starting the link has the necessary access rights to open the file.

Perform a :DSTAT ALL command and make sure the disk drive the file resides on is present and mounted. Make sure the file resides on Ldev 1. If not, use Fcopy and a file equation with a ";DEV=1" option to force a copy of the file onto Ldev 1.

Perform a :SHOWPROC 1;TREE;SYSTEM command and verify an NMFILE process exists. If not, shut down and restart the system, and retry the operation. If the problem persists, contact your Hewlett-Packard Representative for assistance with NMCONFIG file open problems.

CAUSE: During a link-open operation by an upper level subsystem, the link module configurator was able to open the configuration file, but encountered an error while trying to data for the link being started ("Cause"= 32-bit status from the call to nmconfopen).

ACTION: The module configurator cleaned up and returned an error to the subsystem.

Using NMMGR, verify the path LINK.linkname exists in the NMCONFIG file and is the exact same linkname which is now being started. Verify the "Data=Y" flag is set at the top of that LINK screen (meaning that ENTER has been pressed to save the configuration data there). If the link is being used with NS or DTS, use the VALIDATE function to validate the network configuration. Correct any configuration errors and retry the operation

CAUSE: After successfully reading configuration data for a link being started, the link module configurator checked the data and found it was not valid ("Cause" is not used here). For NS/3000, probably the link type and NI type do not match.

ACTION: The module configurator cleaned up and returned an error to the subsystem.

Using NMMGR, verify the path LINK.linkname exists in the NMCONFIG file and is either a 100VG-AnyLAN or 100Base-T link type. If the subsystem being started is NS, verify the link type matches the NI type for the network being started.

If these are not the problem, an incorrect version of NMMGR may have been used to create the NMCONFIG file on your system. Run NMMAINT.PUB.SYS;PARM=24 to check versions of NMMGR components.

The format of your NMCONFIG file may be incompatible with the link driver version installed on your system. Run NMMGRVER.PUB.SYS to update your NMCONFIG file to a newer version, or restore an older version from a backup tape, whichever is appropriate.

If the problem still occurs, contact your Hewlett-Packard Representative for assistance in using NMMGR to configure 100VG-AnyLAN or 100Base-T links.

CAUSE: An upper level subsystem has called the link module configurator, which has successfully located configuration for the link, and will now proceed to start it up ("Transport= name of the subsystem which is starting the link, or its subsystem number if the configurator does not know the name).

ACTION: None. This is an informational event only.

A similar event will be logged when the link is closed.

CAUSE: During a link-open operation by an upper level subsystem, the link module configurator found that the link was configured to enable tracing at startup, but encountered an error trying to open the trace file ("Cause"= 32-bit status from the call to nmopentrace).

ACTION: This is an informational error that tracing was not started. The link came up, but the error was returned to the upper level subsystem, which may decide to shut the link back down again.

Using NMMGR, check if a filename was configured. If so, verify it is a legal MPE filename. A group and account may need to be specified. Make sure the user starting the link has the necessary capabilities to create that file in the group and account specified.

Check whether the system is low on disk space. Check whether too many NMTCnnnn.PUB.SYS trace data files already exist. Purge files as necessary to free up disk space, or add more disks.

Make sure the version of the NMCONFIG file matches the rest of the system software, by running NMMGRVER.PUB.SYS.

If none of these suggestions solves the problem, contact your Hewlett-Packard Representative for assistance with configuring a 100VG-AnyLAN or 100Base-T link to enable tracing at startup.

CAUSE: During a link-open operation by an upper level subsystem, the link module configurator found that the link was configured to enable tracing at startup. After successfully opened a trace file, the configurator encountered an error trying to enable driver tracing ("Cause"= 32-bit status from the call to sio_trace_req).

ACTION: This is an informational error that tracing was not enabled. The link came up, but the error was returned to the upper level subsystem, which may decide to shut the link back down again.

Probably the link driver returned an error reply when asked to enable tracing. The driver may have a problem. Check for other, driver-specific error messages which may give more information about the problem, and look them up also. If no other errors are found, see Appendix A “Submitting an SR ”.

CAUSE: After a link-open operation by an upper level subsystem failed, the link module configurator tried to clean up, but encountered an error trying to disable driver tracing ("Cause"= 32-bit status from the call to sio_trace_req).

ACTION: This is an informational error that tracing was not disabled. If this error occurs it is because some other error has already occurred. The link open did not succeed.

Probably the link driver returned an error reply when asked to disable tracing. The driver may have a problem, or may already have shut down. Check for other, driver-specific error messages which may give more information about the problem, and look them up also. If no other errors are found, see Appendix A “Submitting an SR ”

CAUSE: During a link-open operation by an upper level subsystem, the link module configurator tried to read the current list of multicast addresses produced by the subsystem, but encountered an error on the read ("Cause"= 32-bit status from the call to ieee_multicast_read).

ACTION: The module configurator cleaned up and returned an error to the subsystem.

Run NMMAINT.PUB.SYS;PARM=74 or ;PARM=77, for 100VG-AnyLAN or 100Base-T respectively, and check that the multicast services are present. If present, try starting a ThinLAN link, to see if the same errors occur; or try restarting the system, then retry the operation. If not present, you may need to reinstall ThinLAN software (which contains the multicast for 100VG-AnyLAN and 100Base-T) or obtain newer patches; contact your Hewlett-Packard Representative for assistance. If reinstalling software does not solve the problem, see Appendix A “Submitting an SR ”

CAUSE: During the first link-open operation by an upper level subsystem, the link module configurator attempted to create a new instance of the link driver, but discovered the driver was already created and has been opened at least once ("Cause"= 32-bit status from the call to io_configure, saying the link is already started).

ACTION: This is an informational warning only. The module configurator will leave the link driver up and stop trying to start it again. Usually preceded by another error.

CAUSE: During a link-open operation by an upper level subsystem, the link module configurator successfully started the driver, but encountered an error trying to add the link to the link table ("Cause"= 32-bit status from the call to lsslktbladd).

ACTION: The module configurator cleaned up and returned an error to the subsystem.

Possibly too many links are started.

If not. try starting a different link, to see if that works. If not, first try doing a :LINKCONTROL @ command to see if any LSS errors occur. If they do, you may need to reinstall MPE software; contact your Hewlett-Packard Representative for assistance. Otherwise try restarting the system to see if it corrects the problem or LINKCONTROL errors. If none of these suggestions helps, see Appendix A “Submitting an SR ”

CAUSE: During a link-close operation by an upper level subsystem, the link module deconfigurator was preparing to send new configuration data to the driver, but encountered an error while trying to freeze that data into memory ("Cause"= 32-bit status from the call to freeze).

ACTION: The system may be low on available memory. Try closing any unnecessary applications or sessions and retry the operation. The driver did not receive the updated configuration data. The module deconfigurator attempted to continue with the close. If this happens every time, see Appendix A “Submitting an SR ”

CAUSE: During a link-close operation by an upper level subsystem, the link module deconfigurator was preparing to send updated configuration data to the driver, but encountered an error while trying to send the port message ("Cause"= 32-bit status from the call to send_msg).

ACTION: There may be a system problem, or another subsystem has already shut the driver down while this one was trying to close it. The driver did not receive the updated configuration data. The module deconfigurator reported an error, but attempted to continue with the close. If this happens every time, see Appendix A “Submitting an SR ”

CAUSE: During a link-close operation by an upper level subsystem, the link module deconfigurator sent updated configuration data to the driver, then encountered a timeout while awaiting the correct reply message ("Cause"= 32-bit status from the call to extend_receive, saying there was a timeout).

ACTION: The link driver is probably hung because of a problem in the driver, the driver has already shut down, or the driver may have sent the wrong message back. The module deconfigurator reported an error, but attempted to continue with the close. If this happens every time, see Appendix A “Submitting an SR ”

CAUSE: During a link-close operation by an upper level subsystem, the link module deconfigurator sent updated configuration data to the driver, then encountered an error while awaiting the correct reply message ("Cause"= 32-bit status from the call to extend_receive).

ACTION: There may be a system problem with message ports, or the link driver may have sent the wrong reply message. The module deconfigurator reported an error, but attempted to continue with the close. If this happens every time, see Appendix A “Submitting an SR ”

CAUSE: During a link-close operation by an upper level subsystem, the link module deconfigurator sent updated configuration data to the driver, but the driver returned an error in the reply message ("Cause" is not used here).

ACTION: If this error occurs, there may be additional driver-specific errors logged, giving more information about the problem. Attempt to locate those errors and look them up also. The module deconfigurator reported an error, but attempted to continue with the close. If this happens every time, see Appendix A “Submitting an SR ”

CAUSE: An upper level subsystem has called the link module deconfigurator, which has successfully located the link, and will now proceed to close it.

ACTION: None. This is an informational event only. A similar event was logged when the link was opened.

CAUSE: During a link-close operation by an upper level subsystem, the link module deconfigurator encountered an error trying to disable driver tracing ("Cause"= 32-bit status from the call to sio_trace_req).

This is an informational error that tracing was not disabled. The module deconfigurator reported an error, but attempted to continue with the close.

Probably the link driver returned an error reply when asked to disable tracing. The driver may have a problem, or may already have shut down. Check for other, driver-specific error messages which may give more information about the problem, and look them up also. If this happens every time, see Appendix A “Submitting an SR ”

CAUSE: During a link-close operation by an upper level subsystem, the link module deconfigurator tried to read the current list of multicast addresses produced by the subsystem, but encountered an error on the read ("Cause"= 32-bit status from the call to ieee_multicast_read).

ACTION: The module deconfigurator reported an error, but attempted to continue with the close. Network management services may have been shut down. Otherwise, if this happens every time, see Appendix A “Submitting an SR ”

CAUSE: During a link-close operation by an upper level subsystem, the link module deconfigurator checked its context memory area for validity, but did not find the expected data ("Cause"= 32-bit status saying the context was not accessed).

ACTION: The module deconfigurator's context memory area is being overwritten, or is not working properly. The deconfigurator did not perform the close. If this happens every time, wait until the next time the link is to be closed; instead of closing the link, halt the system and take a memory dump, and see "Submitting an SR".

CAUSE: During the final link-close operation by an upper level subsystem, the link module deconfigurator attempted to delete an instance of the link driver, but encountered an I/O system error ("Cause"= 32-bit status from the call to io_unconfigure).

ACTION: The deconfigurator stopped trying to close the link. However, the driver already received updated configuration data removing the subsystem's multicast information, but other resources, such as link table, were not updated. The driver may already have been shut down by some other means, or the system I/O configuration may have been altered. If this happens frequently, see Appendix A “Submitting an SR ”

CAUSE: During the final link-close operation by an upper level subsystem, the link module deconfigurator attempted to delete the link from the link table, but encountered an error ("Cause"= 32-bit status from the call to lsslktbldelete).

ACTION: The module deconfigurator reported an error, but attempted to continue with the close. Network management services may have been shut down. Otherwise, if this happens every time, see Appendix A “Submitting an SR ”

CAUSE: During the final link-close operation by an upper level subsystem, the link module deconfigurator encountered an error while trying to release the link's write initiator procedure ("Cause"= 32-bit status from the call to hprelsysplabel).

ACTION: This is an informational warning that some system memory resources may have been lost. The module deconfigurator reported an error, but attempted to continue with the close. If this happens every time, see Appendix A “Submitting an SR ”

CAUSE: During a link-close operation by an upper level subsystem, the link module deconfigurator encountered an error while trying to delete an outbound buffer pool ("Cause"= 32-bit status from the call to bmgr_delete_pool).

ACTION: This is an informational warning that some system memory resources may have been lost. The module deconfigurator reported an error, but attempted to continue with the close. If this happens every time, see Appendix A “Submitting an SR ”

CAUSE: During a link-close operation by an upper level subsystem, the link module deconfigurator encountered an error while trying to delete a control buffer pool ("Cause"= 32-bit status from the call to bmgr_delete_pool).

ACTION: This is an informational warning that some system memory resources may have been lost. Probably not all buffers were freed before the pool was deleted. The module deconfigurator reported an error, but attempted to continue with the close. If this happens every time, see Appendix A “Submitting an SR ”

CAUSE: During final processing of a fatal driver error, the driver attempted a standard auto-reset instead of dying. However, its attempt to send a reset message to itself failed ("Cause"= 32-bit status returned by the call to send_msg). If this error is reported, it is because the driver has already encountered some other error.

ACTION: This error is likely an indication of a more serious system software problem, and may be followed by a system abort. Probably all message frames have been exhausted by some module running on the system. Further recovery actions may not be possible; if the system fails, take a memory dump and reboot.

Otherwise, since the auto-reset failed, the driver dies instead, notifying upper layer software via an asynchronous event message if possible. The network and/or link must now be stopped and restarted. Some upper layers may stop the link on their own in response to an event message. If not, manually stop the network and/or link via the appropriate operator command (for example, :NETCONTROL STOP) and then restart it.

CAUSE: While notifying upper level subsystems that the driver detected a serious error, powerfail, or reset, an attempt to send an asynchronous event message to one of those subsystems failed ("Cause"= 32-bit status returned by the call to send_msg).

ACTION: This is a warning that one or more subsystems may not be aware the link has had a problem. The subsystem(s) may have failed to close the driver as part of their shutdown. The driver will continue with its error recovery actions, and no user action is required. If this happens every time, see Appendix A “Submitting an SR ”

CAUSE: During processing of a fatal driver error, the driver attempted a driver dump, but determined it had already dumped too many times since it was initially started ("Cause" is not used here). If this error is reported, it is because the driver has already encountered some other error.

ACTION: By design, the driver attempts to auto-reset itself after any driver dump. But after 3 dumps, to avoid uncontrollably filling disk space with driver dumps, additional dumps are automatically suppressed. No attempt is made to determine whether the dumps are duplicates of the same problem. The driver did not dump, but will still attempt to auto-reset itself, up to a total of 12 times or more.

There is apparently something wrong, since many driver dumps are occurring. Collect binary copies of all dump files (NETDMP##.PUB.SYS) on tape for analysis by Hewlett-Packard and see Appendix A “Submitting an SR ”

CAUSE: During processing of a fatal driver error, the driver attempted a driver dump, but encountered an error while trying to get or reset a timer ("Cause"= 32-bit status returned by the call to vg_start_timer). This timer was to be used to avoid deadlock in case the dump process did not respond; the driver cannot attempt a dump if a dump timer cannot be started. If this error is reported, it is because the driver has already encountered some other error.

ACTION: Typically preceded by another error message giving better information about the original cause; check log data for that error and look it up also. The driver did not dump, but will still attempt to auto-reset itself, up to a total of 12 times or more.

CAUSE: During final processing of a fatal driver error, the driver attempted a driver dump, but was unable to send a dump event to the dump process ("Cause"= 32-bit status returned by the call to send_msg). If this error is reported, it is because the driver has already encountered some other error.

ACTION: The driver did not dump, but will still attempt to auto-reset itself, up to a total of 12 times or more.

CAUSE: During processing of some other fatal driver error, the driver attempted a driver dump, but encountered an error. It then encountered this second error while trying to clean up, when attempting to release a dump timer it had obtained ("Cause"= 32-bit status returned by the call to vg_stop_timer).

ACTION: Typically preceded by another error giving better information about the original cause; check log data for that error and look it up also. This error is mainly informational, since the driver did not dump, but may be indicative of other, possibly-related problems. The driver will still attempt to auto-reset itself, up to a total of 12 times or more.

CAUSE: The driver attempted to get a system timer from I/O Services but encountered an error ("Cause"= 32-bit status returned by the call to io_get_timer). This is either caused by exhausting all timers due to heavy system load, or by system software either failing to release timers, or having some other bug.

ACTION: This is a fatal software error. The number of available timers is not configurable, and the driver cannot operate without the necessary timers. After reporting this error, the driver will die, then will either attempt an auto-reset or else require a manual shutdown and restart. Typically followed by another error giving more information about what kind of timer the driver needed; check log data for that error and look it up also.

If you suspect a heavy load, you can try shutting some processes down, then restart the driver. Otherwise use Control-B at the console to halt the system, take a memory dump, and reboot. See Appendix A “Submitting an SR ”

CAUSE: The driver attempted to reset a system timer previously obtained from I/O Services but encountered an error ("Cause"= 32-bit status returned by the call to io_reset_timer). This is likely caused by a bug in system software, or by corruption of the driver's PDA context memory.

ACTION: This is a fatal software error. The driver cannot operate without all necessary timers. After reporting this error, the driver will die, then will either attempt an auto-reset or else require a manual shutdown and restart. If the problem persists, use Control-B at the console to halt the system, take a memory dump, and reboot. See Appendix A “Submitting an SR ”

CAUSE: The driver attempted to release a system timer previously obtained from I/O Services but encountered an error ("Cause"= 32-bit status returned by the call to io_release_timer). This is likely caused by a bug in system software, or by corruption of the driver's PDA context memory.

ACTION: This is a warning that some timer resources may have been lost. The driver will attempt to continue. Unless this happens constantly, the system should continue to run. Possibly followed by another error giving more information about what kind of timer the driver was releasing; check log data for that error and look it up also. If the problem happens every time, see Appendix A “Submitting an SR ”

CAUSE: While processing a new blocking request (requiring a driver exit and later reply) and scanning a table in which to save the request, the driver found an unused entry, but an entry counter indicated the table was full ("Cause" is not used here).

ACTION: This fatal software error is only caused by a bug, because the in use flags and counters should match. After reporting this error, the driver will die, then will either attempt an auto-reset or else require a manual shutdown and restart. If the problem persists, use Control-B at the console to halt the system, take a memory dump, and reboot. See Appendix A “Submitting an SR ”

CAUSE: While processing a new blocking request (requiring a driver exit and later reply) and scanning a table in which to save the request, the driver was unable to find an unused entry ("Cause" is not used here).

ACTION: This fatal software error is only caused by a bug, since message port subqueue controls should have prevented the table from filling. After reporting this error, the driver will die, then will either attempt an auto-reset or else require a manual shutdown and restart.

Most likely some subsystem has sent a message to an incorrect subqueue. If the problem persists, try to determine which program, networking subsystem, or operator command causes it; then activate link tracing, reproduce the problem, and save the resulting trace file (NMTC####.PUB.SYS) for analysis by Hewlett-Packard. See Appendix A “Submitting an SR ”

CAUSE: While completing an old blocking request (requiring a driver exit and later reply), the driver found that the entry in the pending message save area, where the request was supposedly saved, was no longer in use ("Cause"= table entry number where the request was supposed to be).

ACTION: This fatal software error is only caused by a bug, because the driver should never be trying to complete the same message twice. After reporting this error, the driver will die, then will either attempt an auto-reset or else require a manual shutdown and restart. If the problem persists, try to determine which program, networking subsystem, or operator command causes it; then activate link tracing, reproduce the problem, and save the resulting trace file (NMTC####.PUB.SYS) for analysis by Hewlett-Packard. See Appendix A “Submitting an SR ”

CAUSE: While completing an old blocking request (requiring a driver exit and later reply), the driver found that the index specified for an entry in the pending message save area, where the request was supposedly saved, was not within the range of legal table indexes ("Cause"= the bad table entry number specified).

ACTION: This fatal software error is only caused by memory corruption or a bug, because the driver should never passing an illegal index. After reporting this error, the driver will die, then will either attempt an auto-reset or else require a manual shutdown and restart. If the problem persists, try to determine which program, networking subsystem, or operator command causes it; then activate link tracing, reproduce the problem, and save the resulting trace file (NMTC####.PUB.SYS) for analysis by Hewlett-Packard. See Appendix A “Submitting an SR ”

CAUSE: While attempting to request action from its ISR module, the driver found that no available communication frames were available on the referenced queue ("Cause" is not used here). The number of available comm frames is not configurable, and the driver cannot operate if frames run out.

ACTION: This is a fatal software error. After reporting this error, the driver will attempt a driver dump, then will auto-reset and attempt to continue. Typically followed by another error giving more information about what kind of comm the driver was trying to send; check log data for that error and look it up also.

Collect binary copies of all NETDMP##.PUB.SYS dump files on tape for analysis by Hewlett-Packard and see Appendix A “Submitting an SR ”

CAUSE: While attempting to send a reply to an earlier request message from an upper level subsystem or tool, the driver encountered an error on the send ("Cause"= 32-bit status returned by the call to send_msg).

ACTION: This error is sometimes fatal, causing the remainder of the driver's processing to be skipped. May be followed by another error giving more information about what kind of reply the driver was trying to send; check log data for that error and look it up also. If the link does not seem to be responding, attempt to shut down and restart the network and/or link. If the problem persists, wait until it occurs again, then use Control-B at the console to halt the system, take a memory dump, and reboot. See Appendix A “Submitting an SR ”

CAUSE: Too many subsystems are attempting to open the driver at the same time, or subsystems are shutting down without closing the driver ("Cause"= maximum number of driver opens allowed).

ACTION: The driver allows 11 simultaneous opens. It was not opened by the additional subsystem. Shut down any networking subsystems that are not currently needed and try again.

A side-effect of this error may be that the driver becomes unusable; if so, run VGPBA and execute the Reset function to see if that restores normal operation.

CAUSE: While starting up the link, the driver attempted to request ADA memory from the MPE I/O system, but encountered an error trying to send a memory request message to the I/O Memory Port ("Cause"= 32-bit status from the call to send_msg).

ACTION: This is a fatal software error. The driver cannot operate the adapter card without ADA memory. After reporting this error, the driver will return a configuration error, then die and wait to be shut down; the configuration routine should shut it down automatically.

The problem can be caused either by lack of memory or by a bug. If you suspect high memory usage and have the GLANCE tool, run it and check system memory usage. If usage is high, try closing some applications or subsystems, then retry link startup. If the problem persists, shut down the system to clear memory, then reboot but try starting the link earlier, before too many other applications get going.

If still low on memory, you may need to add more memory hardware. First, however, Hewlett-Packard can try to determine if more memory would help, or if instead there is a bug. Use NMMGR to make sure all logging classes are enabled for the link type, for disk logging. Reproduce the problem, then collect all NM log files (NMLG####.PUB.SYS) and see Appendix A “Submitting an SR ”

CAUSE: While shutting down the link, the driver attempted to free ADA memory previously obtained from the MPE I/O system, but encountered an error trying to send a memory request message to the I/O Memory Port ("Cause"= 32-bit status from the call to send_msg).

ACTION: This is a warning that some memory resources may have been lost. The driver will attempt to continue. Unless this happens frequently, the system should continue to run.

If the problem happens every time, enable link tracing via :LINKCONTROL then reproduce the link shutdown problem (the trace file will close automatically). Save the resulting trace file (NMTC####.PUB.SYS) on tape for Hewlett-Packard analysis, and see Appendix A “Submitting an SR ”

CAUSE: The driver is being shut down. The last subsystem that was using the driver is now closing it.

ACTION: This event is informational only. No action is needed.

CAUSE: During initial driver startup, an HP-PB bus was not found at the hardware path specified in NMCONFIG.

ACTION: The driver did not start up. Use NMMGR to verify the path in NMCONFIG is correct and complete, and matches the path where a supported 100VG-AnyLAN or 100Base-T adapter card is installed in your computer backplane. If the path resides on a bus converter, use SYSGEN to make sure a path to that bus converter exists in the I/O configuration. A diagram of the backplane slot paths, often found in the rear of your system near the backplane, may help you. You can also try an offline diagnostic utility such as MAPPER, or an online utility such as SYSMAP, to precisely determine your hardware configuration. If necessary, change the SYSGEN or NMCONFIG configurations or contact your Hewlett-Packard Representative for assistance in determining paths or correcting bus hardware problems.

CAUSE: During initial driver startup, a supported 100VG-AnyLAN or 100Base-T adapter card was not found at the hardware path specified in NMCONFIG.

ACTION: The driver did not start up. Verify the path in NMCONFIG is correct and complete, and matches the path where a supported 100VG-AnyLAN or 100Base-T adapter card is installed in the computer backplane. Verify the Power LED is lit on that adapter. If necessary, contact your Hewlett-Packard Representative for hardware assistance.

CAUSE: During initial driver startup, the driver was unable to add its ISR into the MPE I/O system, as an interrupt handler routine for any adapter card interrupts on that EIR bit ("Cause"= 32-bit status returned by the call to io_config_int).

ACTION: The driver did not start up. There is probably an MPE software installation problem, with incomplete or incompatible O/S software. Verify the system is running an MPE release which supports 100-Mbit link drivers. The only other cause is a software bug; see Appendix A “Submitting an SR ”

CAUSE: During a 100VG-AnyLAN link connect attempt, the driver detected all 1's on a hardware register read, and, upon checking further, saw that its hardware I/O address space was disabled, indicating a powerfail had already occurred.

ACTION: None. This error can be ignored. Power failures can occur at any moment. The driver was executing at the moment power failed. Power then returned, and the driver ran to completion, noticing this error along the way. Upon exit, the driver was then officially notified of a powerfail by MPE. The driver then attempted powerfail recovery, and should now be operating the same as before.

CAUSE: During a 100VG-AnyLAN link connect attempt, the driver attempted to request a training interval from the hub, but detected all 1's on an MII hardware register read, indicating a powerfail had already occurred.

ACTION: None. This error can usually be ignored. Power failures can occur at any moment. The driver was executing at the moment power failed. Power then returned, and the driver ran to completion, noticing this error along the way. Upon exit, the driver was then officially notified of a powerfail by MPE. The driver then attempted powerfail recovery, and should now be operating the same as before.

The link did not connect. If you suspect power did not really fail but the problem persists, the adapter card may be faulty. If retrying the connect does not help, replace the adapter card.

CAUSE: During a 100VG-AnyLAN link connect attempt, the driver attempted to request a training interval from the hub, but its read from an MII hardware register on the adapter card failed to return the proper acknowledgment bit.

ACTION: The link did not connect. MII reads can be sensitive to software timing. If you have GLANCE or a similar tool, run it and check the CPU load on the system. If the load is high, try reducing the CPU load, then retry the connect. If the problem persists, the adapter card has probably failed; replace the adapter card.

CAUSE: During a 100VG-AnyLAN link connect attempt, the driver attempted to request a training interval from the hub, but detected all 1's on an MII hardware register read, indicating a powerfail had already occurred. The driver was trying to read from a PHY status register to clear it, when the powerfail or error occurred.

ACTION: None. This error can usually be ignored. Power failures can occur at any moment. The driver was executing at the moment power failed. Power then returned, and the driver ran to completion, noticing this error along the way. Upon exit, the driver was then officially notified of a powerfail by MPE. The driver then attempted powerfail recovery, and should now be operating the same as before.

The link did not connect. If you suspect power did not really fail but the problem persists, the adapter card may be faulty. If retrying the connect does not help, replace the adapter card.

CAUSE: During a 100VG-AnyLAN link connect attempt, the driver attempted to request a training interval from the hub, but its read from an MII hardware register on the adapter card failed to return the proper acknowledgment bit.

ACTION: The link did not connect. MII reads can be sensitive to software timing. If you have GLANCE or a similar tool, run it and check the CPU load on the system. If the load is high, try reducing the CPU load, then retry the connect. If the problem persists, the adapter card has probably failed; replace the adapter card.

CAUSE: During a 100VG-AnyLAN link connect attempt, the driver detected all 1's on a hardware register read, and, upon checking further, saw that its hardware I/O address space was disabled, indicating a powerfail had already occurred. The driver was reading from adapter card memory to check a received training frame, when power failed.

ACTION: None. This error can be ignored. Power failures can occur at any moment. The driver was executing at the moment power failed. Power then returned, and the driver ran to completion, noticing this error along the way. Upon exit, the driver was then officially notified of a powerfail by MPE. The driver then attempted powerfail recovery, and should now be operating the same as before.

CAUSE: During a 100VG-AnyLAN link connect attempt, the driver attempted to request a training interval from the hub, but detected all 1's on an MII hardware register read, indicating a powerfail had already occurred. The driver was trying to read from a PHY control register before writing back to it, when the powerfail or error occurred.

ACTION: None. This error can usually be ignored. Power failures can occur at any moment. The driver was executing at the moment power failed. Power then returned, and the driver ran to completion, noticing this error along the way. Upon exit, the driver was then officially notified of a powerfail by MPE. The driver then attempted powerfail recovery, and should now be operating the same as before.

The link did not connect. If you suspect power did not really fail but the problem persists, the adapter card may be faulty. If retrying the connect does not help, replace the adapter card.

CAUSE: During a 100VG-AnyLAN link connect attempt, the driver attempted to request a training interval from the hub, but its read from an MII hardware register on the adapter card failed to return the proper acknowledgment bit.

ACTION: The link did not connect. MII reads can be sensitive to software timing. If you have GLANCE or a similar tool, run it and check the CPU load on the system. If the load is high, try reducing the CPU load, then retry the connect. If the problem persists, the adapter card has probably failed; replace the adapter card.

CAUSE: The first upper layer subsystem to bind to the driver triggered a link connect, which was successful ("Mode"= the connection mode: 100VG, 100Base-TX, or 10Base-T "Duplex"= Full or Half). This event is also logged after the link or cable has been successfully reconnected after being disconnected, or on a link reconnect following a hub retrain, severe line-hit, power failure, or other recoverable error.

ACTION: This event is informational only.

No action is needed unless the message appears frequently while the link is up, indicating possible cabling problems; make sure cabling is securely connected and properly routed away from sources of interference, and is of the proper UTP category or grade for the type of link (CAT-5 for 100Base-T, CAT-3 or -5 for 100VG-AnyLAN).

CAUSE: The last upper layer subsystem has unbound itself from the driver, triggering a link disconnect This event is also logged if the link unexpectedly drops due to a cable disconnect, hub retrain request, powerfail, severe line hit, or other recoverable error ("Status"= 32-bit status giving the reason for the disconnect, 0=normal).

ACTION: This event is informational only. If the network is being shut down, no action is required.

However, if the link was supposed to be up or the message appears frequently while the link is up, this indicates possible cabling problems; make sure cabling is securely connected and properly routed away from sources of interference, and is of the proper UTP category or grade for the type of link (CAT-5 for 100Base-T, CAT-3 or -5 for 100VG-AnyLAN).

CAUSE: The driver has completed initial startup of the adapter card, or a restart following a reset, powerfail, dump, or other recoverable condition ("Status"= 32-bit status giving the result of the startup attempt, 0=successful).

ACTION: This event is informational. No action is required unless the status is nonzero. Nonzero status indicates the startup failed; this may be preceded by other specific errors.

CAUSE: After successful or unsuccessful completion of initial hardware startup, the driver attempted to reply to a pending configuration request from its module configurator, but encountered an error on the send ("Cause"= 32-bit status returned by the call to vg_dvr_send_reply).

ACTION: This is a fatal software error. It might be caused by heavy CPU load, or by attempting to operate the network subsystem or tool which started the link at too low of a CPU process priority, causing a timeout. Any condition, such as a timeout or abort, which causes the driver's module configurator to cease awaiting the reply and dispose of its reply port, might also cause this error.

The module configurator did not receive the reply, therefore network and/or link startup will fail. The driver now "dies" and awaits a shutdown, which the module configurator should attempt automatically.

CAUSE: Following an unsuccessful initial startup of its adapter card, or a restart because of a powerfail or reset, the driver sent a bad reply to the pending config request message, if any, logged this error, then died ("Cause"= 32-bit status giving the reason startup failed).

ACTION: This event indicates a fatal driver software condition. May be preceded by other errors giving more information about the original failure, which may help you determine whether it was a hardware or software problem.

If this occurred on initial startup, the driver's module configurator should shut the driver down automatically. If not, it may mean the adapter card has failed because of a hardware problem, or that a software reset attempt has failed. The driver may need to be manually shut down and restarted, using an appropriate network subsystem command (such as :NETCONTROL STOP). If you wish, you may first try running the VGPBA diagnostic; execute the Reset function to see if that clears the problem.

CAUSE: During a 100VG-AnyLAN link connect attempt, the driver was unable to allocate and start or reset its training timer. The timer was to be used to quiesce the driver and ISR prior to link training ("Cause"= 32-bit status returned by the call to vg_start_timer).

ACTION: This informational error should be preceded by another error giving a more specific reason for the failure; check log data and look up that error also, for more actions to take. The driver cannot connect the link without the timer, and it will now "die", then will either attempt an auto-reset or else require a manual shutdown and restart.

CAUSE: During initial driver startup, the driver encountered an error during configuration ("Cause"= 32-bit status returned by the call to vg_dvr_port_msg_exec). Probably there are already too many opens against the driver.

ACTION: This informational error should be preceded by another error giving a more specific reason for the failure; check log data and look up that error also, for more actions to take. This error can only be caused by a bug, a mismatch between driver's state and open table.

The open request failed. If the problem occurs repeatedly, see Appendix A “Submitting an SR ”

CAUSE: The driver has just completed initial configuration and is now starting up ("Vers"= driver version number, "Pda"= 64-bit pointer to driver context area: Hewlett-Packard use only). This event only occurs on initial startup, not on restarts after powerfails, resets, etc.

ACTION: This event is informational. No action is required.

CAUSE: During initial driver startup, the driver encountered an error during configuration, while attempting to request ADA memory from the MPE I/O system ("Cause"= 32-bit status returned by the call to vg_dvr_port_msg_exec). Probably a port message could not be sent.

ACTION: This informational error should be preceded by another error giving a more specific reason for the failure; check log data and look up that error also, for more actions to take.

The open request failed. The driver will now "die" and must be shut down; the module configurator should do this automatically.

CAUSE: While processing a driver open from an upper layer subsystem, which was not the first open against the driver, the driver encountered an error during configuration ("Cause"= 32-bit status returned by the call to vg_dvr_port_msg_exec). Probably there are already too many opens against the driver.

ACTION: This informational error should be preceded by another error giving a more specific reason for the failure; check log data and look up that error also, for more actions to take.

The driver returned a bad result to the subsystem, and the open request failed. The driver will continue to operate all other subsystems as before.

CAUSE: While processing a driver open from an upper layer subsystem, which was not the first open against the driver, the driver encountered an error during configuration ("Cause"= 32-bit status returned by the call to vg_dvr_send_reply). Probably a port message could not be sent.

ACTION: The driver allows 11 simultaneous opens. The open attempt by the additional subsystem failed. Shut down any subsystems that are not currently needed and try again.

A side-effect of this error may be that the driver becomes unusable; if so, run VGPBA and execute the Reset function to see if that restores normal operation.

CAUSE: The driver received a new open from an upper layer subsystem, at a time the driver was not able to process these requests, such as during shutdown or after a fatal software error ("Cause"= 16-bit encoded value, giving driver input event code and current state: Hewlett-Packard use only).

ACTION: The open failed. Check the system console; if the driver is shutting down or doing a dump, wait until that completes. Retry the operation. If the problem persists, the driver may be broken; run the VGPBA diagnostic and attempt a Reset function. If the problem still persists, run VGPBA, attempt a Dump function, and save the resulting file (NETDMP##.PUB.SYS) for analysis by Hewlett-Packard. If the driver still does not become usable after this, use Control-B at the console to halt the system, take a memory dump, and reboot. See Appendix A “Submitting an SR ”

CAUSE: While attempting to forward a diagnostic request to its ISR, the driver encountered an error ("Cause"= 32-bit status returned by the call to vg_dvr_copy_send_to_isr). Probably no comm frame was available.

ACTION: This informational error should be preceded by another error giving a more specific reason for the failure; check log data and look up that error also, for more actions to take. Most likely the previous error was fatal and the driver is about to "die", then will either attempt an auto-reset or else require a manual shutdown and restart.

CAUSE: Before attempting to forward a diagnostic request to its ISR, the driver discovered the ISR was already in a "dead" state and unable to process requests ("Cause"= 32-bit status stating the driver is "dying").

ACTION: If the operator already knows the driver is in the process of being closed, this error can be ignored. The driver attempted to send an error reply for the diagnostic request. The ISR may also be "dead" as a result of a serious previous error. A diagnostic reset action may clear this condition.

CAUSE: The driver received a request to turn link tracing off when it was already off. Typically this condition is caught at the C.I. level, however in this case trace may be under the control of a different mechanism.

ACTION: No action is required; this error is informational only. An error reply was sent in response to the request. Trace was not stopped by this request this time, but it remains off.

CAUSE: While processing a request to turn link trace off, the driver was unable to locate a free storage element in which to save reply information ("Cause"= 32-bit status returned by the call to vg_dvr_save_msg).

ACTION: This informational error should be preceded by another error giving a more specific reason for the failure; check log data and look up that error also, for more actions to take. Most likely the previous error was fatal and the driver is about to "die", then will either attempt an auto-reset or else require a manual shutdown and restart.

CAUSE: While attempting to forward a disable-trace request to its ISR, the driver encountered an error ("Cause"= 32-bit status returned by the call to vg_dvr_copy_send_to_isr). Probably no comm frame was available.

ACTION: This informational error should be preceded by another error giving a more specific reason for the failure; check log data and look up that error also, for more actions to take. Most likely the previous error was fatal and the driver is about to "die", then will either attempt an auto-reset or else require a manual shutdown and restart.

CAUSE: While processing its very first startup message, the driver encountered a problem ("Cause"= 32-bit status returned by the call to vg_dvr_initialize). Probably the configured hardware is not present, is not the correct kind of adapter card, or there was a problem configuring the ISR into the I/O system.

ACTION: This informational error should be preceded by another error giving a more specific reason for the failure; check log for that error and look it up also, for more actions to take. The driver will attempt to send an error reply for the startup request. It then enters a "broken" state and awaits a shutdown, which the module configurator should attempt automatically.

CAUSE: While processing its very first startup message, the driver encountered a problem trying to send a reply to that message ("Cause"= 32-bit status returned by the call to vg_dvr_send_reply). Probably an underlying call to send_msg has failed.

ACTION: The link did not start. This informational error should be preceded by other errors giving a more specific reason for the failure; check log data and look up that error also, for more actions to take. Possibly the process which was to receive the reply no longer exists. The error occurred on the reply, so if the caller—typically the I/O system—does exist, it will not receive the reply, and may time out. The hardware path may or may not be usable after this error, so a system reboot may be needed before the next retry, however you may attempt a retry anyway.

CAUSE: The driver received a second copy of the first initialization message it would ever get, indicating a second attempt to start the driver ("Cause"= 16-bit encoded value, giving driver input event code and current state: HP use only).

ACTION: The driver sent an error reply in response to the message. Further action may not be required. If the problem occurs frequently, try to determine what operator commands or actions trigger the error, then see Appendix A “Submitting an SR ”

CAUSE: The driver received a driver-dump completion message when it was not working on a dump ("Cause"= 32-bit status saying there was a bad message for the current state).

ACTION: This error is informational only. Probably the Network Dump Process was delayed by other system processing, such that it exceeded the time limit set by the driver. The resulting dump file may or may not be incomplete. A more serious driver problem has already occurred, after which the driver will now attempt to auto-reset and continue. If you are trying to reproduce a specific problem but this error occurs every time, reduce the CPU or disk activity load before the next attempt.

If load is not the problem, see Appendix A “Submitting an SR ”

CAUSE: The driver's dump timer popped while performing a dump operation ("Cause"= 32-bit status indicating a timeout has occurred). Probably a heavy CPU or disk activity load caused the Network Dump Process to take longer than the time allowed by the driver.

ACTION: This error is informational only. The resulting dump file may or may not be incomplete. A more serious driver problem has already occurred, and by the time this error is logged, the driver is already attempting to auto-reset and continue. If you are trying to reproduce a specific problem but this error occurs every time, reduce the CPU or disk activity load before the next attempt.

CAUSE: The driver received a request to turn link tracing on when it was already on. Typically this condition is caught at the C.I. level, however in this case trace may be under the control of a different mechanism.

ACTION: No action is required; this error is informational only. An error reply was sent in response to the request. Trace was not started by this request this time, but it remains on.

CAUSE: The driver received a request to turn link tracing on either too early or too late in the driver's life cycle, or when the driver was already broken ("Cause"= 16-bit encoded value, giving driver input event code and current state: HP use only).

ACTION: Retry the same trace command later. An error reply was sent in response to the request. Trace was not started by this request this time, and remains off.

CAUSE: While processing a request to turn link trace on, the driver was unable to locate a free storage element in which to save reply information ("Cause"= 32-bit status returned by the call to vg_dvr_save_msg).

ACTION: This informational error should be preceded by another error giving a more specific reason for the failure; check log data and look up that error also, for more actions to take. Most likely the previous error was fatal and the driver is about to "die", then will either attempt an auto-reset or else require a manual shutdown and restart.

CAUSE: While attempting to forward an enable-trace request to its ISR, the driver encountered an error ("Cause"= 32-bit status returned by the call to vg_dvr_copy_send_to_isr). Probably no comm frame was available.

ACTION: This informational error should be preceded by another error giving a more specific reason for the failure; check log data and look up that error also, for more actions to take. Most likely the previous error was fatal and the driver is about to "die", then will either attempt an auto-reset or else require a manual shutdown and restart.

CAUSE: A user attempted to force a driver dump while a previous driver dump was still occurring ("Cause"= 32-bit status saying a driver dump is starting).

ACTION: A dump of your problem is already being produced. Wait a minute or two for the dump to finish. Forward the resulting NETDMP##.PUB.SYS to Hewlett-Packard for analysis if necessary, and see Appendix A “Submitting an SR ”

CAUSE: A user is forcing a driver dump to occur, typically via the VGPBA diagnostic tool program ("Cause"= 32-bit status saying the driver dump was forced).

ACTION: This error is informational only. The dump is probably being forced because the system operator suspects a link driver problem. Forward the resulting NETDMP##.PUB.SYS file to Hewlett-Packard for analysis if necessary, and see Appendix A “Submitting an SR ”

CAUSE: During initial startup, the driver attempted to obtain a memory object via the I/O system, but received a bad status in the reply for that request ("Cause"= 32-bit status from the reply message).

ACTION: The link did not start, and the driver attempted to send back an error reply in response the configuration request from the module configurator. Probably the amount of frozen memory on the system is very high; if you have the GLANCE tool you can try to check memory usage. Try retrying the operation again later, or first terminate some applications and then retry.

CAUSE: The driver received a get-memory reply message it was not expecting ("Cause"= 16-bit encoded value, giving driver input event code and current state: HP use only).

ACTION: The driver may already have changed state because of a shutdown or another problem, in which case this message can be ignored. Otherwise, the I/O system may be confused. Either way, some memory may have been lost. The driver will drop this message without further action. If the problem occurs frequently, see Appendix A “Submitting an SR ”

CAUSE: While attempting to forward a diagnostic reconnect event to its ISR, the driver encountered an error ("Cause"= 32-bit status returned by the call to vg_dvr_copy_send_to_isr). Probably no comm frame was available.

ACTION: This informational error should be preceded by another error giving a more specific reason for the failure; check log data and look up that error also, for more actions to take. Most likely the previous error was fatal and the driver is about to "die", then will either attempt an auto-reset or else require a manual shutdown and restart. The driver dropped this event message without further action.

CAUSE: During shutdown, the driver requested the I/O system to release a memory object, but received an error reply in response ("Cause"= 32-bit status from the mem_reply message).

ACTION: This error should not occur. The driver may be confused, or there is a system problem. However, the driver will ignore the error and attempt to continue with the shutdown. If this problem happens frequently when the driver is shutting down, see Appendix A “Submitting an SR ”

CAUSE: The driver received a release-memory reply message it was not expecting ("Cause"= 16-bit encoded value, giving driver input event code and current state: HP use only).

ACTION: The driver may already have changed state because of a shutdown or another problem, in which case this message can be ignored. Otherwise, the I/O system may be confused. The driver will drop this message without further action. If the problem occurs repeatedly, see Appendix A “Submitting an SR ”

CAUSE: While attempting to forward a protocol rendezvous (bind) message to its ISR, the driver encountered an error ("Cause"= 32-bit status returned by the call to vg_dvr_copy_send_to_isr). Probably no comm frame was available.

ACTION: This informational error should be preceded by another error giving a more specific reason for the failure; check log data and look up that error also, for more actions to take. Most likely the previous error was fatal and the driver is about to "die", then will either attempt an auto-reset or else require a manual shutdown and restart. The driver dropped this request message without further action, likely resulting in timeouts and failure of the network and/or protocol to successfully start up.

CAUSE: Before attempting to forward a protocol rendezvous (bind) request to its ISR, the driver discovered the ISR was already in a "dead" state and unable to process requests ("Cause"= 32-bit status stating the driver is "dying").

ACTION: If the operator already knows the driver is in the process of being closed, this error can be ignored. The driver attempted to send an error reply for the rendezvous request. The ISR may also be "dead" as a result of a serious previous error. A diagnostic reset action may clear this condition.

CAUSE: The driver received a request to reset itself too early in the driver's life cycle before it had ever brought up the adapter card, or at a point late in shutdown when recovery is no longer needed ("Cause"= 16-bit encoded value, giving driver input event code and current state: HP use only).

ACTION: This error is informational only. If the reset request was manually sent by a user, such as via the VGPBA diagnostic tool, an error reply will be returned; resets are not allowed (or needed) when the driver is in the state it is currently in. If the reset was automatically generated by the driver in response to some serious error it detected, this log event means it is being ignored.

CAUSE: While attempting to forward a protocol separate (unbind) message to its ISR, the driver encountered an error ("Cause"= 32-bit status returned by the call to vg_dvr_copy_send_to_isr). Probably no comm frame was available.

ACTION: This informational error should be preceded by another error giving a more specific reason for the failure; check log data and look up that error also, for more actions to take. Most likely the previous error was fatal and the driver is about to "die", then will either attempt an auto-reset or else require a manual shutdown and restart. The driver dropped this request message without further action, likely resulting in timeouts and failure of the network and/or protocol to cleanly shut down.

CAUSE: Before attempting to forward a protocol separate (unbind) request to its ISR, the driver discovered the ISR was already in a "dead" state and unable to process requests ("Cause"= 32-bit status stating the driver is "dying").

ACTION: If the operator already knows the driver is in the process of being closed, this error can be ignored. The driver attempted to send an error reply for the separate request. The ISR may also be "dead" as a result of a serious previous error. A diagnostic reset action may clear this condition.

CAUSE: While attempting to forward a diagnostic or LINKCONTROL statistics request to its ISR, the driver encountered an error ("Cause"= 32-bit status returned by the call to vg_dvr_copy_send_to_isr). Probably no comm frame was available.

ACTION: This informational error should be preceded by another error giving a more specific reason for the failure; check log data and look up that error also, for more actions to take. Most likely the previous error was fatal and the driver is about to "die", then will either attempt an auto-reset or else require a manual shutdown and restart. The driver dropped this request message without further action, likely resulting in timeouts and possibly a hung C.I. or program session. A system reboot may be required to recover from that session hang.

CAUSE: Before attempting to forward a diagnostic or LINKCONTROL statistics request to its ISR, the driver discovered the ISR was already in a "dead" state and unable to process requests ("Cause"= 32-bit status stating the driver is "dying").

ACTION: If the operator already knows the driver is in the process of being closed, this error can be ignored. The driver attempted to send an error reply for the statistics request. The ISR may also be "dead" as a result of a serious previous error. A diagnostic reset action may clear this condition.

CAUSE: During an attempt to establish the proper stack context within which to begin 100VG-AnyLAN link training, the driver encountered an error trying to start a timer ("Cause"= 32-bit status returned by the call to vg_start_timer).

ACTION: This informational error should be preceded by another error giving a more specific reason for the failure; check log data and look up that error also, for more actions to take. The driver made no attempt to finish the link training request or reply to its ISR. Most likely the previous timer error was fatal and the driver is about to "die", then will either attempt an auto-reset or else require a manual shutdown and restart.

CAUSE: While attempting to forward successful or unsuccessful 100VG-AnyLAN link training results to its ISR, the driver encountered an error ("Cause"= 32-bit status returned by the call to vg_dvr_copy_send_to_isr). Probably no comm frame was available.

ACTION: This informational error should be preceded by another error giving a more specific reason for the failure; check log data and look up that error also, for more actions to take. The driver made no further attempt to finish link training since it cannot communicate with its ISR. Most likely the previous error was fatal and the driver is about to "die", then will either attempt an auto-reset or else require a manual shutdown and restart.

CAUSE: During a link close operation, the driver encountered an error while unconfiguring the link ("Cause"= 32-bit status returned by the call to vg_dvr_port_msg_exec).

ACTION: The subsystem close did not work. The driver attempted to return an error reply to the sending subsystem. Reaction to that message is subsystem-dependent. Probably the subsystem passed an invalid open ID, or tried to close a link it had not opened. If this problem happens every time the same subsystem is closed, submit an SR against that subsystem, describing the problem; see Appendix A “Submitting an SR ”

CAUSE: During a link close operation, the driver encountered an error while sending an unconfigure reply message to an upper layer subsystem ("Cause"= 32-bit status returned by the call to vg_dvr_send_reply).

ACTION: This informational error should be preceded by another error giving a more specific reason for the failure; check log data and look up that error also, for more actions to take. The subsystem's access to the link was closed, but the subsystem did not get the reply; reaction to this situation is subsystem-dependent. The subsystem have already terminated. If this problem happens every time the same subsystem is closed, submit an SR against that subsystem, describing the problem; see Appendix A “Submitting an SR ”

The driver may now enter a broken state and not respond to further requests, requiring a system reboot to completely shut the driver down. If other subsystems still need to use the link, if you wish you may try running the VGPBA diagnostic; execute the Reset function to see if that restores access for the other subsystems, until a reboot can happen.

CAUSE: The driver received an unconfigure request message before it received its first configure request ("Cause"= 16-bit encoded value, giving driver input event code and current state: HP use only).

ACTION: This error is informational only. The driver attempted to return an error reply to the sending subsystem. If this problem happens frequently, try to determine what actions lead to the problem, then see Appendix A “Submitting an SR ”

CAUSE: While processing a diagnostic input-output request message, the driver was unable to locate a free storage element in which to save reply information ("Cause"= 32-bit status returned by the call to vg_dvr_save_msg).

ACTION: This informational error should be preceded by another error giving a more specific reason for the failure; check log data and look up that error also, for more actions to take. The driver may not attempt to reply to this request; if not, the session which sent it may hang. Most likely the previous error was fatal and the driver is about to "die", then will either attempt an auto-reset or else require a manual shutdown and restart.

CAUSE: While processing a diagnostic input-output request message, the driver encountered an error ("Cause"= 32-bit status returned by the call to vg_dvr_copy_send_to_isr). Probably no comm frame was available.

ACTION: This informational error should be preceded by another error giving a more specific reason for the failure; check log data and look up that error also, for more actions to take. The driver may not attempt to reply to this request; if not, the session which sent it may hang. Most likely the previous error was fatal and the driver is about to "die", then will either attempt an auto-reset or else require a manual shutdown and restart.

CAUSE: Before attempting to forward a diagnostic input-output request message to its ISR, the driver discovered the ISR was already in a "dead" state and unable to process requests request ("Cause"= 16-bit encoded value, giving driver input event code and current state: HP use only).

ACTION: If the operator already knows the driver is in the process of being closed, this error can be ignored. The driver attempted to send an error reply for the diagnostic request. The ISR may also be "dead" as a result of a serious previous error. A diagnostic reset action may clear this condition.

CAUSE: While processing a diagnostic register read-write request message, the driver encountered an error ("Cause"= 32-bit status returned by the call to vg_dvr_copy_send_to_isr). Probably no comm frame was available.

ACTION: This informational error should be preceded by another error giving a more specific reason for the failure; check log data and look up that error also, for more actions to take. The driver may not attempt to reply to this request; if not, the session which sent it may hang. Most likely the previous error was fatal and the driver is about to "die", then will either attempt an auto-reset or else require a manual shutdown and restart.

CAUSE: While attempting to forward a diagnostic hardware-control request to its ISR, the driver encountered an error ("Cause"= 32-bit status returned by the call to vg_dvr_copy_send_to_isr). Probably no comm frame was available.

ACTION: This informational error should be preceded by another error giving a more specific reason for the failure; check log data and look up that error also, for more actions to take. Most likely the previous error was fatal and the driver is about to "die", then will either attempt an auto-reset or else require a manual shutdown and restart.

CAUSE: Before attempting to forward a diagnostic hardware-control request to its ISR, the driver discovered the ISR was already in a "dead" state and unable to process requests ("Cause"= 16-bit encoded value, giving driver input event code and current state: HP use only).

ACTION: If the operator already knows the driver is in the process of being closed, this error can be ignored. The driver attempted to send an error reply for the diagnostic request. The ISR may also be "dead" as a result of a serious previous error. A diagnostic reset action may clear this condition.

CAUSE: Before attempting to forward a diagnostic register read-write request message to its ISR, the driver discovered the ISR was already in a "dead" state and unable to process requests request ("Cause"= 16-bit encoded value, giving driver input event code and current state: HP use only).

ACTION: If the operator already knows the driver is in the process of being closed, this error can be ignored. The driver attempted to send an error reply for the diagnostic request. The ISR may also be "dead" as a result of a serious previous error. A diagnostic reset action may clear this condition.

CAUSE: A general error occurred during processing of an input event by the main driver DVR state machine, and the code where the error occurred neglected to specify a sublocation code value, so the value 4450 was used.

ACTION: Note all logged error messages. The main problem is described by whatever was logged. But the driver also needs to be fixed to specify a unique sublocation for those errors. Please see Appendix A “Submitting an SR ”

CAUSE: The main driver DVR state machine was passed an input event for which there is no processing implemented. Either there is a driver bug or some data corruption has occurred ("Cause"= 32-bit ordinal value of the input event code: HP use only).

ACTION: Try to determine which operator or program actions led to this error. Then see Appendix A “Submitting an SR ”

After this problem occurs, the driver will enter a "broken" state where is may not respond to further requests. If possible, run the VGPBA tool program, and use it to force a driver dump, then forward the resulting NETDMP##.PUB.SYS file to Hewlett-Packard for analysis. After a dump, the driver will attempt to auto-reset itself and continue. You may also use VGPBA to attempt a manual reset of the driver, after which it may be possible to continue.

CAUSE: Some module on the system has sent the driver a message having an unknown message descriptor. The driver does not implement any messages having that descriptor ("Cause"= 32-bit value of the message descriptor field).

ACTION: The driver took no action on the message, and dropped it. However, if the problem occurs frequently, your system may not be set up properly. The driver traces the message which it received. If you can repeat the problem, first enable link tracing. Then reproduce the problem, stop tracing, and save the resulting trace data file for analysis by Hewlett-Packard. See Appendix A “Submitting an SR ”

CAUSE: During ISR processing, an attempt by the ISR to wake up the driver by sending a message to it failed ("Cause"= 32-bit status returned by the call to send_msg).

ACTION: This error is likely an indication of a more serious system software problem, and may be followed by a system abort. Probably all message frames have been exhausted by some module running on the system. Further recovery actions may not be possible; if the system fails, take a memory dump and reboot.

The driver wakeup did not occur, so a link hang is now possible. It is also possible that if a system abort does not occur, other activity, such as transmissions by upper layer protocols, will awaken the driver, such that normal operation continues. If the link hangs and a system abort does not occur, try using VGPBA to attempt a manual reset, or try stopping and restarting all networks using the link driver.

CAUSE: While attempting to request action from its DVR module, the driver's ISR found that no available communication frames were available on the referenced queue ("Cause" is not used here).

ACTION: This is a fatal software error. The number of available comm frames is not configurable, and the driver cannot operate if frames run out. After reporting this error, the driver will attempt a driver dump, then will auto-reset and attempt to continue. Typically followed by another error giving more information about what kind of comm the driver was trying to send; check log data for that error and look it up also.

Collect binary copies of all dump files (NETDMP##.PUB.SYS) on tape for analysis by Hewlett-Packard and see Appendix A “Submitting an SR ”

CAUSE: While attempting to request action from its DVR module, the driver's ISR found that no available communication frames were available on the referenced queue ("Cause" is not used here).

ACTION: The driver logs this error, then attempts to continue. However, the problem could indicate some serious internal problems within the buffer manager or its data structures, or with the way the system is configured. Note all log messages, especially the "Cause" status for this error, and see Appendix A “Submitting an SR ” If the problem persists, take a system memory dump immediately after the problem has occurred.

CAUSE: When attempting to post a queued request for a new buffer manager buffer from a read pool, to replenish the inbound buffer cache for one of its bound protocols, the driver's ISR encountered an error that was not one of the few legal errors it expected, or was able to handle ("Cause"= 32-bit status returned by the call to bmgr_get_buffer).

ACTION: The driver logs this error, then attempts to continue. However, the problem could indicate some serious internal problems within the buffer manager or its data structures, or with the way the system is configured. Note all log messages, especially the "Cause" status for this error. If the problem persists, wait until it occurs again, then use Control-B at the console to halt the system, take a memory dump, and reboot. See Appendix A “Submitting an SR ”

CAUSE: While attempting to send a reply to an earlier request message forwarded by the driver from an upper level subsystem or tool, the driver's ISR encountered an error on the send ("Cause"= 32-bit status returned by the call to send_msg).

ACTION: This error is sometimes fatal, causing the remainder of the driver's processing to be skipped. May be followed by another error giving more information about what kind of reply the ISR was trying to send; check log data for that error and look it up also. If the link does not seem to be responding, attempt to shut down and restart the network and/or link. If the problem persists, wait until it occurs again, then use Control-B at the console to halt the system, take a memory dump, and reboot. See Appendix A “Submitting an SR ”

CAUSE: After verifying the PHY chip on the adapter card had been successfully reset, the driver checked the ID of the PHY, but found it did not match any ID expected for this kind of adapter card ("Cause"= 32-bit PHY ID obtained from the card).

ACTION: Replace the adapter card. The motherboard and PMC board may be mismatched, the PHY chip may have gone bad, or your software may be out of date. Only the upper 12 bits of the ID need to match the expected value, which varies depending on adapter card type.

The link did not connect. Following this error, the driver may "die" and require a manual shutdown of the network. If the same problem persists even after replacement with a known good card, see Appendix A “Submitting an SR ”

CAUSE: After initializing the PCI bus on the adapter card, the driver checked the ID of the LAN controller chip, but found it did not match any of the known ID's expected ("Cause"= 32-bit chip ID obtained from the card).

ACTION: Replace the adapter card.

The link did not start. If the same problem persists even after replacement with a known good card, contact Hewlett-Packard; your software could be out of date, but a patch may be available. Or, depending on the exact cause, a knowledgeable Hewlett-Packard Support Representative may be able to use VGPBA diagnostics to modify your adapter card's EEPROM to work temporarily with your older software.

CAUSE: After trying repeatedly, the ID the driver is still receiving the wrong ID from the PCI controller chip on the adapter card ("Cause"= the last 32-bit chip ID obtained from the card).

ACTION: Replace the adapter card.

The link did not start. If the same problem persists even after replacement with a known good card, contact Hewlett-Packard: your software could be out of date, but a patch may be available. It is unlikely this would be a system HP-PB bus hardware problem.

CAUSE: A power failure appears to have occurred during a hard reset of the adapter card during startup ("Cause" is not used here).

ACTION: This is an informational error only. The driver should have then attempted to recover from the powerfail. If you suspect a powerfail has not occurred, and the same problem occurs on every restart, the adapter card or system HP-PB hardware may have failed. Replace the adapter card. Then, if the problem still persists, contact your Hewlett-Packard Service Representative for help in diagnosing your system hardware.

CAUSE: After performing a hard reset of the adapter card during startup, the HP-PB interface chip did not report "ready" status, or reported an error ("Cause"= 32-bit io_status value read from the chip).

ACTION: Replace the adapter card.

The link did not start. If the same problem persists even after replacement with a known good card, contact your Hewlett-Packard Representative; your software could be out of date, but a patch may be available. It is unlikely this would be caused by a system HP-PB bus hardware problem.

CAUSE: While attempting to alter the loopback mode during diagnostic testing, the driver read from the network command register on the LAN controller chip of the adapter card, but encountered an error. Most likely a power failure has occurred ("Cause"= 32-bit status returned by the call to vg_dio_read8).

ACTION: If a power failure has actually occurred, this error can be ignored; the driver should recover automatically. But if the same problem happens every time, see Appendix A “Submitting an SR ”

CAUSE: While attempting to alter the loopback mode during diagnostic testing, the driver read from the generic control register on the PHY chip of the adapter card, but encountered an error. Most likely the PHY has failed, but a power failure may have occurred ("Cause"= 32-bit status returned by the call to vg_mii_read16).

ACTION: If a power failure has actually occurred, this error can be ignored; the driver should recover automatically. Otherwise, the MII bus may have failed; replace the adapter card. If the same problem persists, see Appendix A “Submitting an SR ”

CAUSE: While attempting to alter 100VG-AnyLAN loopback mode during diagnostic testing, the driver read from the PHY control register on the PHY chip of the adapter card, but encountered an error. Most likely the PHY has failed, but a power failure may have occurred ("Cause"= 32-bit status returned by the call to vg_mii_read16).

ACTION: If a power failure has actually occurred, this error can be ignored; the driver should recover automatically. Otherwise, the MII bus may have failed; replace the adapter card. If the same problem persists, see Appendix A “Submitting an SR ”

CAUSE: While attempting to alter 100Base-T loopback mode during diagnostic testing, the driver read from a loopback control register on the PHY chip of the adapter card, but encountered an error. Most likely the PHY has failed, but a power failure may have occurred ("Cause"= 32-bit status returned by the call to vg_mii_read16).

ACTION: If a power failure has actually occurred, this error can be ignored; the driver should recover automatically. Otherwise, the MII bus may have failed; replace the adapter card. If the same problem persists, see Appendix A “Submitting an SR ”

CAUSE: While attempting to alter 10Base-T loopback mode during diagnostic testing of a 100VG-AnyLAN adapter card, the driver read from a PHY control register in the LAN controller chip of the card, but encountered an error. Most likely the chip has failed, but a power failure may have occurred ("Cause"= 32-bit status returned by the call to vg_mii_read16).

ACTION: If a power failure has actually occurred, this error can be ignored; the driver should recover automatically. Otherwise, the MII bus may have failed; replace the adapter card. If the same problem persists, see Appendix A “Submitting an SR ”

CAUSE: While attempting to initiate DMA to send some transmit data to the adapter card, driver software found its data structures to be in an unexpected state ("Cause" is not used here). The state of all transmit queues was not one of the legal states predicted at design time.

ACTION: This is a fatal software error. The driver will not attempt to continue. After reporting this error, the driver will die, then will either attempt an auto-reset or else require a manual shutdown and restart. If the problem persists, first activate link tracing, reproduce the problem, stop tracing, and save the resulting link trace file. Then see Appendix A “Submitting an SR ”

CAUSE: During diagnostic loopback testing, the driver was asked to prepare a data block for transmission, but the block length or memory allocation was beyond the driver's DMA capabilities ("Cause"= 32-bit total length of the requested transmission).

ACTION: This problem should only be seen in diagnostics, however it should not be occurring at all. Specify a shorter loopback length, and see Appendix A “Submitting an SR ”

CAUSE: While beginning a 100VG-AnyLAN link training sequence, the driver started to reset the PHY chip, but encountered an error while trying to get or reset a timer ("Cause"= 32-bit status from the call to vg_start_timer). This timer was to be used to wait for the PHY reset to finish; the driver cannot connect the link if a PHY timer cannot be started. If this error is reported, it is because the driver has already encountered some other error.

ACTION: Typically preceded by another error message giving better information about the original cause; check log data for that error and look it up also. The driver did not dump, but will still attempt to auto-reset itself, up to a total of 12 times or more.

If the problem persists, the system may be low on timers; try stopping some applications before retrying again.

CAUSE: During a 100VG-AnyLAN link training sequence, the driver found the PHY chip was not reset yet, and started to reset it again, but encountered an error while trying to get or reset a timer ("Cause"= 32-bit status from the call to vg_start_timer). This timer was to be used to wait again for the PHY reset to finish; the driver cannot connect the link if a PHY timer cannot be started. If this error is reported, it is because the driver has already encountered some other error.

ACTION: Typically preceded by another error message giving better information about the original cause; check log data for that error and look it up also. The driver did not dump, but will still attempt to auto-reset itself, up to a total of 12 times or more. If the problem persists, the system may be low on timers; try stopping some applications before retrying again.

CAUSE: During a 100VG-AnyLAN link training sequence, the driver tried 3 times to reset the PHY chip, but it still did not go "ready" ("Cause" is not used here).

ACTION: This is a fatal hardware error. Replace the adapter card.

The driver cannot connect the link if the PHY will not reset. The driver will enter a "broken" state and await a manual shutdown by the operator. If you wish you may try running the VGPBA diagnostic and attempt a reset, however it is unlikely this will fix the problem. If the problem persists with a known good card, see Appendix A “Submitting an SR ”

CAUSE: During a 100VG-AnyLAN link training sequence, the driver started to power up the PHY chip, but encountered an error while trying to get or reset a timer ("Cause"= 32-bit status from the call to vg_start_timer). This timer was to be used to wait for the PHY power-up to finish; the driver cannot connect the link if a PHY timer cannot be started. If this error is reported, it is because the driver has already encountered some other error.

ACTION: Typically preceded by another error message giving better information about the original cause; check log data for that error and look it up also. The driver did not dump, but will still attempt to auto-reset itself, up to a total of 12 times or more.If the problem persists, the system may be low on timers; try stopping some applications before retrying again.

CAUSE: During a 100VG-AnyLAN link training sequence, after powering up the PHY chip, the driver encountered an error while trying to read the PHY ID ("Cause"= 32-bit status from the call to vg_isr_init_phy_id). If this error is reported, it is because the driver has already encountered some other error.

ACTION: Typically preceded by another error message giving better information about the original cause; check log data for that error and look it up also. The driver did not dump, but will still attempt to auto-reset itself, up to a total of 12 times or more. Most likely there is an adapter card hardware problem.

CAUSE: During a 100VG-AnyLAN link training sequence, the driver attempted to enable MII interrupts, but encountered an error trying to read from the serial I/O register on the LAN controller chip ("Cause"= 32-bit status from the call to vg_dio_read8). Most likely a powerfail has occurred.

ACTION: If a power failure has actually occurred, this error can be ignored; the driver should recover automatically. But if the same problem happens every time, see Appendix A “Submitting an SR ”

CAUSE: During a 100VG-AnyLAN link training sequence, the driver attempted to disable broadcast packets, but encountered an error trying to read from the network command register on the LAN controller chip ("Cause"= 32-bit status from the call to vg_dio_read8). Most likely a powerfail has occurred.

ACTION: If a power failure has actually occurred, this error can be ignored; the driver should recover automatically. But if the same problem happens every time, see Appendix A “Submitting an SR ”

CAUSE: During a 100VG-AnyLAN link training sequence, the driver attempted to clear PHY interrupts, but encountered an error trying to read from the generic status register on the PHY chip ("Cause"= 32-bit status from the call to vg_mii_read16). Most likely a powerfail has occurred.

ACTION: If a power failure has actually occurred, this error can be ignored; the driver should recover automatically. Otherwise, the MII bus may have failed; replace the adapter card. If the same problem persists, see Appendix A “Submitting an SR ”

CAUSE: During a 100VG-AnyLAN link training sequence, the driver attempted to clear PHY interrupts, but encountered an error trying to read from the PHY status register on the PHY chip ("Cause"= 32-bit status from the call to vg_mii_read16). Most likely a powerfail has occurred.

ACTION: If a power failure has actually occurred, this error can be ignored; the driver should recover automatically. Otherwise, the MII bus may have failed; replace the adapter card. If the same problem persists, see Appendix A “Submitting an SR ”

CAUSE: During a 100VG-AnyLAN link training sequence, the driver attempted to clear PHY statistics, but encountered an error trying to read all statistics from the LAN controller chip ("Cause"= 32-bit status from the call to vg_isr_read_clr_tlan_stats). Most likely a powerfail has occurred.

ACTION: If a power failure has actually occurred, this error can be ignored; the driver should recover automatically. If the same problem persists, see Appendix A “Submitting an SR ”

CAUSE: During a 100VG-AnyLAN link training sequence, the driver attempted to request a test interrupt, but encountered an error trying to read from the PHY control register on the PHY chip ("Cause"= 32-bit status from the call to vg_mii_read16). Most likely a powerfail has occurred.

ACTION: If a power failure has actually occurred, this error can be ignored; the driver should recover automatically. Otherwise, the MII bus may have failed; replace the adapter card. If the same problem persists, see Appendix A “Submitting an SR ”

CAUSE: During a 100VG-AnyLAN link training sequence, the driver requested a test interrupt, then encountered an error while trying to get or reset a timer ("Cause"= 32-bit status from the call to vg_start_timer). This timer was to be used to verify the test interrupt arrives; the driver cannot connect the link if a PHY timer cannot be started. If this error is reported, it is because the driver has already encountered some other error.

ACTION: Typically preceded by another error message giving better information about the original cause; check log data for that error and look it up also. The driver did not dump, but will still attempt to auto-reset itself, up to a total of 12 times or more. If the problem persists, the system may be low on timers; try stopping some applications before retrying again.

CAUSE: During a 100VG-AnyLAN link training sequence, the driver received the expected test interrupt, but encountered an error while trying to stop and release a timer ("Cause"= 32-bit status from the call to vg_stop_timer). This timer was used to wait for the test interrupt to arrive. If this error is reported, it is because the driver has already encountered some other error.

ACTION: This is a warning that some timer resources may have been lost. The link did not connect. Typically preceded by another error message giving better information about the original cause; check log data for that error and look it up also. Unless this happens constantly, the system should continue to run, and the driver will probably retry the connect. If the problem happens every time, see Appendix A “Submitting an SR ”

CAUSE: During a 100VG-AnyLAN link training sequence, the driver's ISR module attempted to send a training request to its DVR module, but encountered an error ("Cause"= 32-bit status returned by the call to vg_isr_copy_send_to_dvr). Probably no comm frame was available.

ACTION: This informational error should be preceded by another error giving a more specific reason for the failure; check log data and look up that error also, for more actions to take. Most likely the previous error was fatal and the driver is about to "die", then will either attempt an auto-reset or else require a manual shutdown and restart. The driver stopped trying to connect the link.

CAUSE: During a 100VG-AnyLAN link training sequence, the driver requested a test interrupt from the PHY chip on the adapter card, but received a timeout instead ("Cause" is not used here). The driver cannot connect the link if PHY interrupts do not work.

ACTION: Replace the adapter card. The link did not connect. If the problem persists with a known good card, see Appendix A “Submitting an SR ”

CAUSE: During a 100VG-AnyLAN link training sequence, the driver attempted to enable broadcast packets, but encountered an error trying to read from the network command register on the LAN Controller chip ("Cause"= 32-bit status from the call to vg_dio_read8). Most likely a powerfail has occurred.

ACTION: If a power failure has actually occurred, this error can be ignored; the driver should recover automatically. But if the same problem happens every time, see Appendix A “Submitting an SR ”

CAUSE: During a 100VG-AnyLAN link training sequence, the driver attempted to signal a training failure, but encountered an error trying to read from the PHY control register on the PHY chip ("Cause"= 32-bit status from the call to vg_mii_read16). Most likely a powerfail has occurred.

ACTION: If a power failure has actually occurred, this error can be ignored; the driver should recover automatically. Otherwise, the MII bus may have failed; replace the adapter card. If the same problem persists, see Appendix A “Submitting an SR ”

CAUSE: While beginning a 100Base-T connect sequence, the driver started to reset the PHY chip, but encountered an error while trying to get or reset a timer ("Cause"= 32-bit status from the call to vg_start_timer). This timer was to be used to wait for the PHY reset to finish; the driver cannot connect the link if a PHY timer cannot be started. If this error is reported, it is because the driver has already encountered some other error.

ACTION: Typically preceded by another error message giving better information about the original cause; check log data for that error and look it up also. The driver did not dump, but will still attempt to auto-reset itself, up to a total of 12 times or more. If the problem persists, the system may be low on timers; try stopping some applications before retrying again.

CAUSE: During a 100Base-T connect sequence, the driver found the PHY chip was not reset yet, and started to reset it again, but encountered an error while trying to get or reset a timer ("Cause"= 32-bit status from the call to vg_start_timer). This timer was to be used to wait again for the PHY reset to finish; the driver cannot connect the link if a PHY timer cannot be started. If this error is reported, it is because the driver has already encountered some other error.

ACTION: Typically preceded by another error message giving better information about the original cause; check log data for that error and look it up also. The driver did not dump, but will still attempt to auto-reset itself, up to a total of 12 times or more. If the problem persists, the system may be low on timers; try stopping some applications before retrying again.

CAUSE: During a 100Base-T connect sequence, the driver tried 3 times to reset the PHY chip, but it still did not go "ready" after the reset ("Cause" is not used here).

ACTION: This is a fatal hardware error. Replace the adapter card.

The driver cannot connect the link if the PHY will not reset. The driver will enter a "broken" state and await a manual shutdown by the operator. If you wish you may try running the VGPBA diagnostic and attempt a reset, however it is unlikely this will fix the problem. If the problem persists with a known good card, see Appendix A “Submitting an SR ”

CAUSE: During a 100Base-T connect sequence, after resetting the PHY chip, the driver encountered an error while trying to read the PHY ID ("Cause"= 32-bit status from the call to vg_isr_init_phy_id). If this error is reported, it is because the driver has already encountered some other error.

ACTION: Typically preceded by another error message giving better information about the original cause; check log data for that error and look it up also. The driver did not dump, but will still attempt to auto-reset itself, up to a total of 12 times or more. Most likely there is an adapter card hardware problem.

CAUSE: During a 100Base-T connect sequence, the driver told the PHY to connect or autonegotiate, then encountered an error while trying to stop and release a timer ("Cause"= 32-bit status from the call to vg_start_timer). This timer was used to wait for the link-up signal to arrive. If this error is reported, it is because the driver has already encountered some other error.

ACTION: This is a warning that some timer resources may have been lost. The link did not connect. Typically preceded by another error message giving better information about the original cause; check log data for that error and look it up also. Unless this happens constantly, the system should continue to run, and the driver will probably retry the connect. If the problem happens every time, see Appendix A “Submitting an SR ”

CAUSE: During a 100Base-T connect sequence, the driver attempted to check for presence of a link signal, but encountered an error trying to read from the generic status register on the PHY chip ("Cause"= 32-bit status from the call to vg_mii_read16). Most likely a powerfail has occurred.

ACTION: If a power failure has actually occurred, this error can be ignored; the driver should recover automatically. Otherwise, the MII bus may have failed; replace the adapter card. If the same problem persists, see Appendix A “Submitting an SR ”

CAUSE: During a 100Base-T connect sequence, the driver attempted to check for presence of a link signal, but encountered an error trying to read from the generic status register on the PHY chip ("Cause"= 32-bit status from the call to vg_mii_read16). Most likely a powerfail has occurred.

ACTION: If a power failure has actually occurred, this error can be ignored; the driver should recover automatically. Otherwise, the MII bus may have failed; replace the adapter card. If the same problem persists, see Appendix A “Submitting an SR ”

CAUSE: If this error occurs, it is probably because the link has reported a remote fault. Usually this means the adapter card and the hub or switch to which it is connected, have failed to agree on a link speed and duplex setting acceptable to both.

ACTION: Verify that the cable is securely connected to the adapter card at one end, and to a 100Base-TX or 10Base-T hub at the other.

Verify the cable is a correctly wired, Category-5 UTP cable. Category 3 or 4 cables are not acceptable.

If a crossover cable is being used, make sure it is correctly wired, and that you have software version A00550B0 or later.

Check the configuration of the hub or switch port to which the adapter card is connected. Adjust that configuration and, if necessary, use NMMGR to adjust the configuration of the link, so that something will match. If necessary, specify a forced speed and duplex setting, and disable autonegotiation, at both ends.

CAUSE: During a 100Base-T connect sequence, the driver found the link was not connected yet, but encountered an error while trying to get or reset a timer ("Cause"= 32-bit status from the call to vg_start_timer). This timer was to be used to wait again for the link connect to finish; the driver cannot connect the link if a PHY timer cannot be started. If this error is reported, it is because the driver has already encountered some other error.

ACTION: Typically preceded by another error message giving better information about the original cause; check log data for that error and look it up also. The driver did not dump, but will still attempt to auto-reset itself, up to a total of 12 times or more. If the problem persists, the system may be low on timers; try stopping some applications before retrying again.

CAUSE: If this error occurs, it is because the link did not connect within 25 to 30 seconds after it was instructed to do so.

ACTION: Verify that the cable is securely connected to the adapter card at one end, and to a 100Base-TX or 10Base-T hub at the other.

Verify the cable is a correctly wired, Category-5 UTP cable. Category 3 or 4 cables are not acceptable.

If a crossover cable is being used, make sure it is correctly wired, and that you have software version A00550B0 or later.

Check the configuration of the hub or switch port to which the adapter card is connected. Adjust that configuration and, if necessary, use NMMGR to adjust the configuration of the link, so that something will match. If necessary, specify a forced speed and duplex setting, and disable autonegotiation, at both ends.

CAUSE: The link appears to be connected, but the driver thinks it is still waiting for it to connect.

ACTION: This error should not occur. If it happens frequently, see Appendix A “Submitting an SR ”

CAUSE: During a 100Base-T connect sequence after the link came up, the driver attempted to check the final connect settings, but encountered an error trying to read from the generic status register on the PHY chip ("Cause"= 32-bit status from the call to vg_mii_read16). Most likely a powerfail has occurred.

ACTION: If a power failure has actually occurred, this error can be ignored; the driver should recover automatically. Otherwise, the MII bus may have failed; replace the adapter card. If the same problem persists, see Appendix A “Submitting an SR ”

CAUSE: During a 100Base-T connect sequence after the link came up, the driver attempted to check the final connect settings, but encountered an error trying to read from the autonegotiation advertisement register on the PHY chip ("Cause"= 32-bit status from the call to vg_mii_read16). Most likely a powerfail has occurred.

ACTION: If a power failure has actually occurred, this error can be ignored; the driver should recover automatically. Otherwise, the MII bus may have failed; replace the adapter card. If the same problem persists, see Appendix A “Submitting an SR ”

CAUSE: During a 100Base-T connect sequence after the link came up, the driver attempted to check the final connect settings, but encountered an error trying to read from the autonegotiation advertisement register on the PHY chip ("Cause"= 32-bit status from the call to vg_mii_read16). Most likely a powerfail has occurred.

ACTION: If a power failure has actually occurred, this error can be ignored; the driver should recover automatically. Otherwise, the MII bus may have failed; replace the adapter card. If the same problem persists, see Appendix A “Submitting an SR ”

CAUSE: During a 100Base-T connect sequence after the link came up, the driver attempted to check the final connect settings, but encountered an error trying to read from the link partner capabilities register on the PHY chip ("Cause"= 32-bit status from the call to vg_mii_read16). Most likely a powerfail has occurred.

ACTION: If a power failure has actually occurred, this error can be ignored; the driver should recover automatically. Otherwise, the MII bus may have failed; replace the adapter card. If the same problem persists, see Appendix A “Submitting an SR ”

CAUSE: During a 100Base-T connect sequence after the link came up, the driver attempted to check the final connect settings, but encountered an error trying to read from the autonegotiation expansion register on the PHY chip ("Cause"= 32-bit status from the call to vg_mii_read16). Most likely a powerfail has occurred.

ACTION: If a power failure has actually occurred, this error can be ignored; the driver should recover automatically. Otherwise, the MII bus may have failed; replace the adapter card. If the same problem persists, see Appendix A “Submitting an SR ”

CAUSE: During a 100Base-T connect sequence after the link came up, the driver attempted to check the final speed and duplex settings, but encountered an error trying to read from the PHY address register on the PHY chip ("Cause"= 32-bit status from the call to vg_mii_read16). Most likely a powerfail has occurred. This error cannot occur on older PHY chips.

ACTION: If a power failure has actually occurred, this error can be ignored; the driver should recover automatically. Otherwise, the MII bus may have failed; replace the adapter card. If the same problem persists, see Appendix A “Submitting an SR ”

CAUSE: During a 100Base-T connect sequence, the driver attempted to adjust the duplex setting of the LAN controller chip, but encountered an error trying to read from the network command register on that chip ("Cause"= 32-bit status from the call to vg_dio_read8). Most likely a powerfail has occurred.

ACTION: If a power failure has actually occurred, this error can be ignored; the driver should recover automatically. But if the same problem happens every time, see Appendix A “Submitting an SR ”

CAUSE: During a 100Base-T connect sequence, after the link failed to connect, the driver started a retry, but encountered an error while trying to stop and release a timer ("Cause"= 32-bit status from the call to vg_stop_timer). This timer was used to wait for the link to connect. If this error is reported, it is because the driver has already encountered some other error.

ACTION: This is a warning that some timer resources may have been lost. The link did not connect. Typically preceded by another error message giving better information about the original cause; check log data for that error and look it up also. Unless this happens constantly, the system should continue to run, and the driver will probably retry the connect. If the problem happens every time, see Appendix A “Submitting an SR ”

CAUSE: While a 100Base-T link was connected, the driver received a notification the link may be down, but when it went to check, it encountered an error trying to read from the generic status register on the PHY chip ("Cause"= 32-bit status from the call to vg_mii_read16). Most likely a powerfail has occurred.

ACTION: If a power failure has actually occurred, this error can be ignored; the driver should recover automatically. Otherwise, the MII bus may have failed; replace the adapter card. If the same problem persists, see Appendix A “Submitting an SR ”.

CAUSE: While beginning a 10Base-T connect sequence on a 100VG-AnyLAN adapter card, the driver started to reset the PHY chip, but encountered an error while trying to get or reset a timer ("Cause"= 32-bit status from the call to vg_start_timer). This timer was to be used to wait for the PHY reset to finish; the driver cannot connect the link if a PHY timer cannot be started. If this error is reported, it is because the driver has already encountered some other error.

ACTION: Typically preceded by another error message giving better information about the original cause; check log data for that error and look it up also. The driver did not dump, but will still attempt to auto-reset itself, up to a total of 12 times or more.

If the problem persists, the system may be low on timers; try stopping some applications before retrying again.

CAUSE: During a 10Base-T connect sequence on a 100VG-AnyLAN adapter card, after resetting the PHY chip, the driver attempted to check if the reset had finished, but encountered an error trying to read from the generic status register on the chip ("Cause"= 32-bit status from the call to vg_mii_read16). Most likely a powerfail has occurred.

ACTION: If a power failure has actually occurred, this error can be ignored; the driver should recover automatically. Otherwise, the MII bus may have failed; replace the adapter card. If the same problem persists, see Appendix A “Submitting an SR ”

CAUSE: During a 10Base-T connect sequence on a 100VG-AnyLAN adapter card, the driver found the PHY chip was not reset yet, and started to reset it again, but encountered an error while trying to get or reset a timer ("Cause"= 32-bit status from the call to vg_start_timer). This timer was to be used to wait again for the PHY reset to finish; the driver cannot connect the link if a PHY timer cannot be started. If this error is reported, it is because the driver has already encountered some other error.

ACTION: Typically preceded by another error message giving better information about the original cause; check log data for that error and look it up also. The driver did not dump, but will still attempt to auto-reset itself, up to a total of 12 times or more. If the problem persists, the system may be low on timers; try stopping some applications before retrying again.

CAUSE: During a 10Base-T connect sequence on a 100VG-AnyLAN adapter card, the driver tried 3 times to reset the PHY chip, but it still did not go "ready" ("Cause" is not used here).

ACTION: This is a fatal hardware error. Replace the adapter card.

The driver cannot connect the link if the PHY will not reset. The driver will enter a "broken" state and await a manual shutdown by the operator. If you wish you may try running the VGPBA diagnostic and attempt a reset, however it is unlikely this will fix the problem. If the problem persists with a known good card, see Appendix A “Submitting an SR ”

CAUSE: During a 10Base-T connect sequence on a 100VG-AnyLAN adapter card, the driver started to power up the PHY chip, but encountered an error while trying to get or reset a timer ("Cause"= 32-bit status from the call to vg_start_timer). This timer was to be used to wait for the PHY power-up to finish; the driver cannot connect the link if a PHY timer cannot be started. If this error is reported, it is because the driver has already encountered some other error.

ACTION: Typically preceded by another error message giving better information about the original cause; check log data for that error and look it up also. The driver did not dump, but will still attempt to auto-reset itself, up to a total of 12 times or more.

If the problem persists, the system may be low on timers; try stopping some applications before retrying again.

CAUSE: During a 10Base-T connect sequence on a 100VG-AnyLAN adapter card, after resetting the PHY chip, the driver encountered an error while trying to read the PHY ID ("Cause"= 32-bit status from the call to vg_isr_init_phy_id). If this error is reported, it is because the driver has already encountered some other error.

ACTION: Typically preceded by another error message giving better information about the original cause; check log data for that error and look it up also. The driver did not dump, but will still attempt to auto-reset itself, up to a total of 12 times or more. Most likely there is an adapter card hardware problem.

CAUSE: During a 10Base-T connect sequence on a 100VG-AnyLAN adapter card, the driver attempted to enable MII interrupts, but encountered an error trying to read from the serial I/O register on the LAN Controller chip ("Cause"= 32-bit status from the call to vg_dio_read8). Most likely a powerfail has occurred.

ACTION: If a power failure has actually occurred, this error can be ignored; the driver should recover automatically. But if the same problem happens every time, see Appendix A “Submitting an SR ”

CAUSE: During a 10Base-T connect sequence on a 100VG-AnyLAN adapter card, the driver attempted to clear PHY interrupts, but encountered an error trying to read from the generic status register on the PHY chip ("Cause"= 32-bit status from the call to vg_mii_read16). Most likely a powerfail has occurred.

ACTION: If a power failure has actually occurred, this error can be ignored; the driver should recover automatically. Otherwise, the MII bus may have failed; replace the adapter card. If the same problem persists, see Appendix A “Submitting an SR ”

CAUSE: During a 10Base-T connect sequence on a 100VG-AnyLAN adapter card, the driver attempted to clear PHY interrupts, but encountered an error trying to read from the PHY status register on the PHY chip ("Cause"= 32-bit status from the call to vg_mii_read16). Most likely a powerfail has occurred.

ACTION: If a power failure has actually occurred, this error can be ignored; the driver should recover automatically. Otherwise, the MII bus may have failed; replace the adapter card. If the same problem persists, see Appendix A “Submitting an SR ”

CAUSE: During a 10Base-T connect sequence on a 100VG-AnyLAN adapter card, the driver attempted to request a test interrupt, but encountered an error trying to read from the PHY control register on the PHY chip ("Cause"= 32-bit status from the call to vg_mii_read16). Most likely a powerfail has occurred.

ACTION: If a power failure has actually occurred, this error can be ignored; the driver should recover automatically. Otherwise, the MII bus may have failed; replace the adapter card. If the same problem persists, see Appendix A “Submitting an SR ”

CAUSE: During a 10Base-T connect sequence on a 100VG-AnyLAN adapter card, the driver requested a test interrupt, then encountered an error while trying to get or reset a timer ("Cause"= 32-bit status from the call to vg_start_timer). This timer was to be used to verify the test interrupt arrives; the driver cannot connect the link if a PHY timer cannot be started. If this error is reported, it is because the driver has already encountered some other error.

ACTION: Typically preceded by another error message giving better information about the original cause; check log data for that error and look it up also. The driver did not dump, but will still attempt to auto-reset itself, up to a total of 12 times or more. If the problem persists, the system may be low on timers; try stopping some applications before retrying again.

CAUSE: During a 10Base-T connect sequence on a 100VG-AnyLAN adapter card, the driver received the expected test interrupt, but encountered an error while trying to stop and release a timer ("Cause"= 32-bit status from the call to vg_stop_timer). This timer was used to wait for the test interrupt to arrive. If this error is reported, it is because the driver has already encountered some other error.

ACTION: This is a warning that some timer resources may have been lost. The link did not connect. Typically preceded by another error message giving better information about the original cause; check log data for that error and look it up also. Unless this happens constantly, the system should continue to run, and the driver will probably retry the connect. If the problem happens every time, see Appendix A “Submitting an SR ”

CAUSE: During a 10Base-T connect sequence on a 100VG-AnyLAN adapter card, the driver requested a test interrupt from the PHY chip, but received a timeout instead ("Cause" is not used here). The driver cannot connect the link if PHY interrupts do not work.

ACTION: Replace the adapter card. The link did not connect. If the problem persists with a known good card, see Appendix A “Submitting an SR ”

CAUSE: During a 10Base-T connect sequence on a 100VG-AnyLAN adapter card, the driver received the expected link-connected interrupt, but encountered an error while trying to stop and release a timer ("Cause"= 32-bit status from the call to vg_stop_timer). This timer was used to wait for any interrupt to arrive. If this error is reported, it is because the driver has already encountered some other error.

ACTION: This is a warning that some timer resources may have been lost. The link did not connect. Typically preceded by another error message giving better information about the original cause; check log data for that error and look it up also. Unless this happens constantly, the system should continue to run, and the driver will probably retry the connect. If the problem happens every time, see Appendix A “Submitting an SR ”

CAUSE: During a 10Base-T connect sequence on a 100VG-AnyLAN adapter card, the driver received a remote fault interrupt, but encountered an error while trying to stop and release a timer ("Cause"= 32-bit status from the call to vg_stop_timer). This timer was used to wait for any interrupt to arrive. If this error is reported, it is because the driver has already encountered some other error.

ACTION: This is a warning that some timer resources may have been lost. The link did not connect. Typically preceded by another error message giving better information about the original cause; check log data for that error and look it up also. Unless this happens constantly, the system should continue to run, and the driver will probably retry the connect. If the problem happens every time, see "Appendix A “Submitting an SR ”

CAUSE: During a 10Base-T connect sequence on a 100VG-AnyLAN adapter card, when a timeout occurred instead of an interrupt, the driver attempted to check for presence of a link signal, but encountered an error trying to read from the generic status register on the PHY chip ("Cause"= 32-bit status from the call to vg_mii_read16). Most likely a powerfail has occurred.

ACTION: If a power failure has actually occurred, this error can be ignored; the driver should recover automatically. Otherwise, the MII bus may have failed; replace the adapter card. If the same problem persists, see Appendix A “Submitting an SR ”

CAUSE: During a 10Base-T connect sequence on a 100VG-AnyLAN adapter card, when a timeout occurred instead of an interrupt, the driver attempted to check for presence of a link signal, but encountered an error trying to read from the generic status register on the PHY chip ("Cause"= 32-bit status from the call to vg_mii_read16). Most likely a powerfail has occurred.

ACTION: If a power failure has actually occurred, this error can be ignored; the driver should recover automatically. Otherwise, the MII bus may have failed; replace the adapter card. If the same problem persists, see Appendix A “Submitting an SR ”

CAUSE: During a 10Base-T connect sequence on a 100VG-AnyLAN adapter card, when a timeout occurred instead of an interrupt, the driver noticed a remote fault condition, but encountered an error while trying to stop and release a timer ("Cause"= 32-bit status from the call to vg_stop_timer). This timer was used to wait for any interrupt to arrive. If this error is reported, it is because the driver has already encountered some other error.

ACTION: The driver should not be stopping a timer here; please see Appendix A “Submitting an SR ”

The other problem is a remote fault is being detected; check cabling and configuration settings.

CAUSE: If this error occurs, it is because the link did not connect within 25 to 30 seconds after it was instructed to do so.

ACTION: Verify that the cable is securely connected to the adapter card at one end, and to a 100Base-TX or 10Base-T hub at the other.

Verify the cable is a correctly wired, Category-5 UTP cable. Category 3 or 4 cables are not acceptable.

If a crossover cable is being used, make sure it is correctly wired, and that you have software version A00550B0 or later.

Check the configuration of the hub or switch port to which the adapter card is connected. Adjust that configuration and, if necessary, use NMMGR to adjust the configuration of the link, so that something will match. If necessary, specify a forced speed and duplex setting, and disable autonegotiation, at both ends.

CAUSE: During a 10Base-T connect sequence on a 100VG-AnyLAN adapter card, the driver attempted to adjust the duplex setting of the LAN controller chip, but encountered an error trying to read from the network command register on that chip ("Cause"= 32-bit status from the call to vg_dio_read8). Most likely a powerfail has occurred.

ACTION: If a power failure has actually occurred, this error can be ignored; the driver should recover automatically. But if the same problem happens every time, see Appendix A “Submitting an SR ”

CAUSE: During a 10Base-T connect sequence on a 100VG-AnyLAN adapter card, after the link failed to connect, the driver started a retry, but encountered an error while trying to stop and release a timer ("Cause"= 32-bit status from the call to vg_stop_timer). This timer was used to wait for the link to connect. If this error is reported, it is because the driver has already encountered some other error.

ACTION: This is a warning that some timer resources may have been lost. The link did not connect. Typically preceded by another error message giving better information about the original cause; check log data for that error and look it up also. Unless this happens constantly, the system should continue to run, and the driver will probably retry the connect. If the problem happens every time, see Appendix A “Submitting an SR ”

CAUSE: During a 10Base-T connect sequence on a 100VG-AnyLAN adapter card, after the link failed to connect, the driver started a retry, but encountered an error while trying to stop and release a timer ("Cause"= 32-bit status from the call to vg_stop_timer). This timer was used to wait for the link to connect. If this error is reported, it is because the driver has already encountered some other error.

ACTION: This is a warning that some timer resources may have been lost. The link did not connect. Typically preceded by another error message giving better information about the original cause; check log data for that error and look it up also. Unless this happens constantly, the system should continue to run, and the driver will probably retry the connect. If the problem happens every time, see Appendix A “Submitting an SR ”

CAUSE: While a 10Base-T link on a 100VG-AnyLAN adapter card was connected, the driver received a notification the link may be down, but when it went to check, it encountered an error trying to read from the generic status register on the PHY chip ("Cause"= 32-bit status from the call to vg_mii_read16). Most likely a powerfail has occurred.

ACTION: If a power failure has actually occurred, this error can be ignored; the driver should recover automatically. Otherwise, the MII bus may have failed; replace the adapter card. If the same problem persists, see Appendix A “Submitting an SR ”

CAUSE: After attempting to connect the link, the driver's ISR module determined the link did come up, then encountered an error trying to notify the DVR module of the connect ("Cause"= 32-bit status from the call to vg_isr_copy_send_to_dvr). Probably no comm frame was available.

ACTION: This informational error should be preceded by another error giving a more specific reason for the failure; check log data and look up that error also, for more actions to take. Most likely the previous error was fatal and the driver is about to "die", then will either attempt an auto-reset or else require a manual shutdown and restart. The driver stopped trying to connect the link.

CAUSE: This is a generic logging location which reports the driver is having trouble connecting the link. The message varies depending on what the problem is.

After trying repeatedly for 25-30 seconds to connect the link, the driver's ISR module determined the link did not come up ("Cause"= 32-bit status from giving the reason the latest attempt failed, also explained in the Message).

ACTION: This is a warning only. It only appears once, and will not appear again until the link is shut down and restarted.

This informational error should be accompanied by a message specific to the problem. For some reason, the link is not connecting successfully.

Verify that the cable is securely connected to the adapter card at one end, and to a 100Base-TX or 10Base-T hub at the other.

Verify the cable is a correctly wired, Category-5 UTP cable. Category 3 or 4 cables are not acceptable.

If a crossover cable is being used, make sure it is correctly wired, and that you have software version A00550B0 or later.

Check the configuration of the hub or switch port to which the adapter card is connected. Adjust that configuration and, if necessary, use NMMGR to adjust the configuration of the link, so that something will match. If necessary, specify a forced speed and duplex setting, and disable autonegotiation, at both ends.

CAUSE: While attempting to logically disconnect the link, the driver encountered a problem ("Cause" = 32-bit status from the call to Vg_isr_call_phy_state_machine). Probably a power failure or system timer problem has occurred.

ACTION: This informational error should be preceded by another error giving a more specific reason for the failure; check log data and look up that error also, for more actions to take. If a power failure has occurred, this error may be ignored; the driver will soon attempt to recover. Otherwise, most likely the previous error was fatal and the driver is about to "die", then will either attempt an auto-reset or else require a manual shutdown and restart.

CAUSE: After attempting to disconnect the link, the driver's ISR module determined the link did disconnect, then encountered an error trying to notify the DVR module of the disconnect ("Cause"= 32-bit status from the call to Vg_isr_copy_send_to_dvr). Probably no comm frame was available.

ACTION: This informational error should be preceded by another error giving a more specific reason for the failure; check log data and look up that error also, for more actions to take. Most likely the previous error was fatal and the driver is about to "die", then will either attempt an auto-reset or else require a manual shutdown and restart.

CAUSE: After an attempt failed to connect the link, the driver's ISR module started to prepare for a later retry, then encountered an error while trying to get or reset a timer ("Cause"= 32-bit status from the call to vg_start_timer). This timer was to be used to awaken the driver so it could retry the connect; the driver cannot connect the link if a PHY timer cannot be started. If this error is reported, it is because the driver has already encountered some other error.

ACTION: Typically preceded by another error message giving better information about the original cause; check log data for that error and look it up also. The driver did not dump, but will still attempt to auto-reset itself, up to a total of 12 times or more. If the problem persists, the system may be low on timers; try stopping some applications before retrying again.

CAUSE: The LAN Controller chip on the adapter card has failed to produce any interrupt from normal activity for over 5 seconds. It has also failed, for an additional 5 seconds, to respond to the driver's inquiry by producing a test interrupt. The driver has decided the card is dead or hung ("Cause" is not used here).

ACTION: This is a fatal hardware error. Replace the adapter card.

The driver will enter a "broken" state and await a manual shutdown by the operator. If you wish you may try running the VGPBA diagnostic and attempt a reset. If the problem persists with a known good card, see Appendix A “Submitting an SR ”

CAUSE: The driver was in the middle of a periodic check of whether the card is still healthy, but encountered an error while trying to get or reset a timer ("Cause"= 32-bit status from the call to vg_start_timer). This same timer has been used repeatedly to reawaken the driver so it can check the card, so occurrence of this error probably indicates a larger system problem or corruption of data structures. If this error is reported, it is because the driver has already encountered some other error.

ACTION: Typically preceded by another error message giving better information about the original cause; check log data for that error and look it up also. The driver did not dump, but will still attempt to auto-reset itself, up to a total of 12 times or more. If the problem persists, the system may be low on timers; try stopping some applications before retrying again.

CAUSE: The driver was in the middle of a periodic check of whether the card is still healthy, but encountered an error trying to read from the generic status register on the PHY chip ("Cause"= 32-bit status from the call to vg_mii_read16). Most likely a hardware problem has occurred, not a power failure.

ACTION: The MII bus may have failed; replace the adapter card. If the same problem persists, see Appendix A “Submitting an SR ” If a power failure has actually occurred, this error can be ignored; the driver should recover automatically.

CAUSE: While attempting to de-select a PHY chip during diagnostic loopback testing of the adapter card, the driver encountered some kind of lower level error ("Cause"= 32-bit status from the call to vg_isr_set_loopback_mode).

ACTION: This informational error is typically preceded by another error message giving better information about the original cause; check log data for that error and look it up also. Depending on the cause of that error, you may decide that replacement of the adapter card is necessary.

Since diagnostic testing is in progress, the driver should report the error, then attempt to continue. However, later tests may also fail as a result of this error.

CAUSE: During a diagnostic test of adapter card memory, a test segment took too long, so the driver tried to initiate a brief pause, but encountered an error while trying to get or reset a timer ("Cause"= 32-bit status from the call to vg_start_timer). This timer was to be used to awaken the driver so the test could continue. If this error is reported, it is because the driver has already encountered some other error.

ACTION: Typically preceded by another error message giving better information about the original cause; check log data for that error and look it up also. The driver did not dump, but will still attempt to auto-reset itself, up to a total of 12 times or more, even though this happened during diagnostic testing. If the problem persists, the system may be low on timers; try stopping some applications before retrying again.

CAUSE: While the link was disconnected, the driver received an interrupt from the PHY chip on the adapter card, and began to initiate a link reconnect, but encountered an error while trying to stop and release a timer ("Cause"= 32-bit status from the call to vg_stop_timer). This timer was used to reawaken the driver for a reconnect attempt if no interrupt arrived. If this error is reported, it is because the driver has already encountered some other error.

ACTION: This is a warning that some timer resources may have been lost. The link did not connect. Typically preceded by another error message giving better information about the original cause; check log data for that error and look it up also. Unless this happens constantly, the system should continue to run, and the driver will probably retry the connect. If the problem happens every time, see Appendix A “Submitting an SR ”

CAUSE: During a link connect attempt, the driver received an interrupt from the PHY chip on the adapter card and passed that to a lower level, but the lower level returned an error ("Cause"= 32-bit status from the call to vg_isr_call_phy_state_machine).

ACTION: This informational error is typically preceded by another error message giving better information about the original cause; check log data for that error and look it up also. At this level, the error is just logged, then the driver will attempt to continue, if the lower level error was not already fatal.

CAUSE: While the link was connected and working, the driver received an interrupt from the PHY chip on the adapter card and passed that to a lower level, but the lower level returned an error ("Cause"= 32-bit status from the call to vg_isr_call_phy_state_machine). Probably the link has unexpectedly disconnected.

ACTION: This informational error is typically preceded by another error message giving better information about the original cause; check log data for that error and look it up also. At this level, the error is just logged, then the driver will attempt to continue, if the lower level error was not already fatal.

CAUSE: During a link connect attempt, an interval timer used to control the PHY chip on the adapter card popped and the driver passed that to a lower level, but the lower level returned an error (in older software, "Cause" is not used here; otherwise "Cause"= 32-bit status from the call to vg_isr_call_phy_state_machine).

ACTION: This informational error is typically preceded by another error message giving better information about the original cause; check log data for that error and look it up also. At this level, the error is just logged, then the driver will attempt to continue, if the lower level error was not already fatal.

CAUSE: While the link was disconnected. the driver initiated a link reconnect attempt, but received an error from lower level software used to control the PHY chip on the adapter card (in older software, "Cause" is not used here; otherwise "Cause"= 32-bit status from the call to vg_isr_call_phy_state_machine).

ACTION: This informational error is typically preceded by another error message giving better information about the original cause; check log data for that error and look it up also. At this level, the error is just logged, then the driver will attempt to continue, if the lower level error was not already fatal.

CAUSE: The driver received a new bind (rendezvous) from an upper layer protocol, at a time when the driver was not able to process these requests, such as before receiving its initial configuration data, during shutdown, or after a fatal software error ("Cause"= 16-bit encoded value, giving driver input event code and current state: HP use only).

ACTION: This problem most likely occurred while starting a new network subsystem. Attempt to determine which subsystem was being started when the error occurred and, if possible, which upper layer protocol was binding. The bind failed. The driver logged the error, then attempted to send an error reply message back to the protocol module and continue.

Check the system console; if the driver is shutting down or doing a dump, wait until that completes. In these cases, several protocols may experience this same error. If the driver is not shutting down or dying, the protocol may be sending binds to the driver at the wrong time. See Appendix A “Submitting an SR ” and file an SR against the network subsystem being started.

CAUSE: The driver received a bind (rendezvous) from an upper layer protocol module, but the pointer to the information block was not specified ("Cause" is not used here).

ACTION: This problem most likely occurred while starting a new network subsystem. Attempt to determine which subsystem was being started when the error occurred and, if possible, which upper layer protocol was binding. The bind failed. The driver logged the error, then attempted to send an error reply message back to the protocol module and continue.

Either there is a bug in the driver or upper layer protocol software, or there is a system software mismatch. You may require additional software patches; contact your Hewlett-Packard Representative for assistance.

CAUSE: The driver received a bind (rendezvous) from an upper layer protocol module, but the specified length of the information block header was not the length expected ("Cause"= 32-bit value giving the bad length which was specified).

ACTION: This problem most likely occurred while starting a new network subsystem. Attempt to determine which subsystem was being started when the error occurred and, if possible, which upper layer protocol was binding. The bind failed. The driver logged the error, then attempted to send an error reply message back to the protocol module and continue.

Either there is a bug in the driver or upper layer protocol software, or there is a system software mismatch. You may require additional software patches; contact your Hewlett-Packard Representative for assistance.

CAUSE: The driver received a bind (rendezvous) from an upper layer protocol module, but the specified length of the information block body was not the length expected ("Cause"= 32-bit value giving the bad length which was specified).

ACTION: This problem most likely occurred while starting a new network subsystem. Attempt to determine which subsystem was being started when the error occurred and, if possible, which upper layer protocol was binding. The bind failed. The driver logged the error, then attempted to send an error reply message back to the protocol module and continue.

Either there is a bug in the driver or upper layer protocol software, or there is a system software mismatch. You may require additional software patches; contact your Hewlett-Packard Representative for assistance.

CAUSE: The driver received a bind (rendezvous) from an upper layer protocol module, but the specified open ID was out of range of legal open ID values for this driver ("Cause"= 32-bit value giving the bad ID which was specified).

ACTION: This problem most likely occurred while starting a new network subsystem. Attempt to determine which subsystem was being started when the error occurred and, if possible, which upper layer protocol was binding. The bind failed. The driver logged the error, then attempted to send an error reply message back to the protocol module and continue.

Either there is a bug in the driver or upper layer protocol software, or there is a system software mismatch. You may require additional software patches; contact your Hewlett-Packard Representative for assistance.

CAUSE: The driver received a bind (rendezvous) from an upper layer protocol module, but the pointer to that protocol's inbound buffer pool was not specified ("Cause" is not used here).

ACTION: This problem most likely occurred while starting a new network subsystem. Attempt to determine which subsystem was being started when the error occurred and, if possible, which upper layer protocol was binding. The bind failed. The driver logged the error, then attempted to send an error reply message back to the protocol module and continue.

Either there is a bug in the driver or upper layer protocol software, or there is a system software mismatch. You may require additional software patches; contact your Hewlett-Packard Representative for assistance.

CAUSE: The driver received a bind (rendezvous) from an upper layer protocol module, but the specified SDI address family was not one of the values supported by the driver ("Cause"= 32-bit value giving the bad address family which was specified).

ACTION: This problem most likely occurred while starting a new network subsystem. Attempt to determine which subsystem was being started when the error occurred and, if possible, which upper layer protocol was binding. The bind failed. The driver logged the error, then attempted to send an error reply message back to the protocol module and continue.

Either there is a bug in the driver or upper layer protocol software, or there is a system software mismatch. You may require additional software patches; contact your Hewlett-Packard Representative for assistance.

CAUSE: The driver received a bind (rendezvous) from an upper layer protocol module, but when it attempted to save information about that protocol's inbound buffer pool, a lower level routine reported an error, as described by the Message ("Cause" is not used here). Most likely the either the table is full, there is an internal problem with the Buffer Manager, or the size of physical buffers in the pool is smaller than the minimum supported by the driver.

ACTION: This problem most likely occurred while starting a new network subsystem. Attempt to determine which subsystem was being started when the error occurred and, if possible, which upper layer protocol was binding.

The bind failed. The driver logged the error, then attempted to send an error reply message back to the protocol module and continue.

If the table is full, too many protocols are started; close some unnecessary subsystems and try again. Otherwise there may be something wrong with the buffer pool or Buffer Manager, system memory may be low, or there may be a driver bug. Shut down the network and restart it. If the problem happens every time, see Appendix A “Submitting an SR ”

CAUSE: The driver received a bind (rendezvous) from an upper layer protocol module, but when it attempted to save information about that protocol's address (SAP), a lower-level routine reported an error, as described by the Message ("Cause"= 32-bit encoded value of the SAP being bound). Most likely either the address is already in the driver's table, or the table is full.

ACTION: This problem most likely occurred while starting a new network subsystem. Attempt to determine which subsystem was being started when the error occurred and, if possible, which upper layer protocol was binding.

The bind failed. The driver logged the error, then attempted to send an error reply message back to the protocol module and continue.

If a duplicate address is in the table already, either an attempt has been made to start the same subsystem twice, or a previous instance of that subsystem did not properly shut down; a system reboot may be required to shut it. Otherwise there could be a driver bug, if two protocols are truly different but the driver thinks they are the same. Shut down the network and restart it. If the problem happens every time, see Appendix A “Submitting an SR ”

CAUSE: The driver received a bind (rendezvous) from an upper layer protocol module and added it to driver tables, but encountered an error trying to obtain a block of buffers from that protocol's inbound buffer pool ("Cause"= 32-bit status from the call to vg_isr_fill_buf_cache). Most likely a serious, unexpected Buffer Manager error was reported on a call to bmgr_get_buffer, which was not one of the expected, legal errors the driver is designed to handle.

ACTION: This problem most likely occurred while starting a new network subsystem. Attempt to determine which subsystem was being started when the error occurred and, if possible, which upper layer protocol was binding.

The bind failed. The driver logged the error, then attempted to clean up, send an error reply message back to the protocol module, and continue. There may be something wrong with the buffer pool or Buffer Manager, system memory may be low, or there may be a driver bug. Shut down the network and restart it. If the problem happens every time, see Appendix A “Submitting an SR ”

CAUSE: An upper layer protocol has successfully bound (rendezvoused) to the link driver ("Addr"= 32-bit encoded protocol address (SAP) value for this protocol module). Being bound means the driver can now route incoming data frames to this protocol.

ACTION: None. This is an informational message only. A similar message is logged later, when the protocol unbinds. If this is the first bind, the link driver will now attempt to reconnect the link.

CAUSE: While beginning a driver start or restart operation, the driver tried to set the heartbeat timer, but encountered an error ("Cause"= 32-bit status from the call to vg_start_timer). This timer was to be used to periodically awaken the driver so it could verify card health; the driver cannot start if a PHY timer cannot be started. If this error is reported, it is because the driver has already encountered some other error.

ACTION: Typically preceded by another error message giving better information about the original cause; check log data for that error and look it up also. The driver did not dump, but will still attempt to auto-reset itself, up to a total of 12 times or more.

If the problem persists, the system may be low on timers; try stopping some applications before retrying again.

CAUSE: While beginning a driver start or restart operation, the driver tried to initialize the adapter card registers, but lower level software reported an error ("Cause= 32-bit status from the call to vg_isr_init_card_regs). If this error is reported, it is because the driver has already encountered some other error.

ACTION: Typically preceded by another error message giving better information about the original cause; check log data for that error and look it up also. If necessary, replace the adapter card.

CAUSE: The driver received an unbind (separate) from an upper layer protocol module, but the specified rendezvous ID was out of range of legal rendezvous ID values for this driver ("Cause"= 32-bit value giving the bad ID which was specified). The protocol was supposed to pass a rendezvous ID value previously returned to it by the driver, when that protocol did a bind.

ACTION: This problem most likely occurred while stopping a running network subsystem. Attempt to determine which subsystem was being stopped when the error occurred and, if possible, which upper layer protocol was unbinding.

The unbind failed. The driver logged the error, then attempted to send an error reply message back to the protocol module and continue. The driver still thinks the protocol is bound. Future attempts to start that same protocol will probably fail until the entire network is stopped or the system is rebooted.

Either there is a bug in the driver or upper layer protocol software, memory data corruption has occurred, or there is a system software mismatch. You may require additional software patches; contact your Hewlett-Packard Representative for assistance.

CAUSE: The driver received an unbind (separate) from an upper layer protocol module, but the driver's corresponding rendezvous table entry state indicated no bind had occurred or an unbind had already occurred ("Cause"= 32-bit value giving the bad ID which was specified). The protocol may be trying to unbind twice, or unbind from the wrong link.

ACTION: This problem most likely occurred while stopping a running network subsystem. Attempt to determine which subsystem was being stopped when the error occurred and, if possible, which upper layer protocol was unbinding.

The unbind failed. The driver logged the error, then attempted to send an error reply message back to the protocol module and continue. The driver still thinks the protocol is bound. Future attempts to start that same protocol will probably fail until the entire network is stopped or the system is rebooted.

Either there is a bug in the driver or upper layer protocol software, memory data corruption has occurred, or there is a system software mismatch. You may require additional software patches; contact your Hewlett-Packard Representative for assistance.

CAUSE: An upper layer protocol has begun to unbind (separate) from the link driver ("Addr"= 32-bit encoded protocol address (SAP) value for this protocol module). Once unbound, the driver can no longer route incoming data frames to this protocol.

ACTION: None. This is an informational message only. A similar message is logged earlier, when the protocol binds. If this is the last bind, the link driver will now attempt to disconnect the link.

If any errors occur as a result of the unbind, they will appear after, not before, this log event; the unbind will still complete, and the protocol will be successfully unbound.

CAUSE: After completing a start or restart operation, the driver's ISR then encountered an error trying to notify the DVR module of the restart completion ("Cause"= 32-bit status from the call to Vg_isr_copy_send_to_dvr). Probably no comm frame was available.

ACTION: This informational error should be preceded by another error giving a more specific reason for the failure; check log data and look up that error also, for more actions to take. Most likely the previous error was fatal and the driver is about to "die", then will either attempt an auto-reset or else require a manual shutdown and restart.

CAUSE: After completing a trace enable request, the driver's ISR then encountered an error trying to notify the DVR module of the request completion ("Cause"= 32-bit status from the call to Vg_isr_copy_send_to_dvr). Probably no comm frame was available.

ACTION: This informational error should be preceded by another error giving a more specific reason for the failure; check log data and look up that error also, for more actions to take. Most likely the previous error was fatal and the driver is about to "die", then will either attempt an auto-reset or else require a manual shutdown and restart.

CAUSE: After completing a trace disable request, the driver's ISR then encountered an error trying to notify the DVR module of the request completion ("Cause"= 32-bit status from the call to Vg_isr_copy_send_to_dvr). Probably no comm frame was available.

ACTION: This informational error should be preceded by another error giving a more specific reason for the failure; check log data and look up that error also, for more actions to take. Most likely the previous error was fatal and the driver is about to "die", then will either attempt an auto-reset or else require a manual shutdown and restart.

CAUSE: While initializing for 100VG-AnyLAN link training, the driver's ISR attempted to copy a training frame into adapter card memory, but encountered an error while trying to construct the necessary data structure ("Cause"= 32-bit status from the call to vg_isr_build_util_step). Probably no DMA step was available.

ACTION: This is a fatal error. The link may require a manual shutdown and restart to recover from this error. In later versions, the driver may "die", then will either attempt an auto-reset or else require a manual shutdown and restart. DMA steps are a well-controlled driver resource, and should not run out. If this problem happens repeatedly, see Appendix A “Submitting an SR ”

CAUSE: The driver received a port message which it does not implement, or containing a function code which it does not implement ("Cause"= 32-bit ISR state machine input event tag value (HP use only).

ACTION: This is an informational error only. If this error occurred as part of a driver reset operation, it may be ignored.

The driver traced the unknown message then ignored it. The driver did not attempt to return an error reply to the message sender. That sender may now be hung, awaiting a reply. Attempt to determine what action caused the error. Activate link tracing, reproduce the problem, then stop link tracing and save the resulting NMTCnnnn.PUB.SYS trace data file. See Appendix A “Submitting an SR ”

CAUSE: The driver received a utility register access request from an upper level tool program such as PVGUTIL, at a time when the driver was not able to process these requests, such as before initializing the adapter card, during shutdown, or after a fatal software error ("Cause"= 16-bit encoded value, giving driver input event code and current state: HP use only).

ACTION: This problem most likely occurred while diagnosing some previous problem. It will not be possible to complete these requests at this time. The driver logged the error, then attempted to send an error reply message back to the sender and continue.

Check the system console; if the driver is shutting down or doing a dump, wait until that completes. If this happens regardless of when the operation is attempted, see Appendix A “Submitting an SR ”

CAUSE: The driver received a utility register access request from an upper level tool program such as PVGUTIL, but the register number specified was out of the range of legal register values for the selected register set ("Cause"= 32-bit value of the selected register-set number, not register number: HP use only).

ACTION: This is an informational error only. Retry the operation using a legal register number for the register set you have selected.

This problem most likely occurred while diagnosing some previous problem. The driver logged the error, then attempted to send an error reply message back to the sender and continue.

CAUSE: The driver received a utility I/O request from an upper level tool program such as PVGUTIL, at a time when the driver was not able to process these requests, such as initializing the adapter card, during shutdown, or after a fatal software error ("Cause"= 16-bit encoded value, giving driver input event code and current state: HP use only).

ACTION: This problem most likely occurred while diagnosing some previous problem. It will not be possible to complete these requests at this time. The driver logged the error, then attempted to send an error reply message back to the sender and continue.

Check the system console; if the driver is shutting down or doing a dump, wait until that completes. If this happens regardless of when the operation is attempted, see Appendix A “Submitting an SR ”

CAUSE: The driver received a utility I/O request from an upper level tool program such as PVGUTIL, but encountered an error while trying to construct the necessary data structure ("Cause"= 32-bit status from the call to vg_isr_build_util_step). Probably no DMA step was available.

ACTION: This problem most likely occurred while diagnosing some previous problem. The driver logged the error, then attempted to send an error reply message back to the sender and continue. DMA steps are a well-controlled driver resource, and should not run out. If this problem happens repeatedly, note whether you were trying to do a read or a write, then see Appendix A “Submitting an SR ”

CAUSE: After completing a utility I/O request, the driver's ISR then encountered an error trying to notify the DVR module of the request completion ("Cause"= 32-bit status from the call to Vg_isr_copy_send_to_dvr). Probably no comm frame was available.

ACTION: This informational error should be preceded by another error giving a more specific reason for the failure; check log data and look up that error also, for more actions to take. Most likely the previous error was fatal and the driver is about to "die", then will either attempt an auto-reset or else require a manual shutdown and restart.

CAUSE: A general error occurred during processing of an input event by the main driver ISR state machine, and the code where the error occurred neglected to specify a sublocation code value, so the value 8990 was used.

ACTION: Note all logged error messages. The main problem is described by whatever was logged. But the driver also needs to be fixed to specify a unique sublocation for those errors. Please see Appendix A “Submitting an SR ”

CAUSE: The main driver ISR state machine was passed an input event for which there is no processing implemented. Either there is a driver bug or some data corruption has occurred ("Cause"= 32-bit ordinal value of the input event code: HP use only).

ACTION: Try to determine which operator or program actions led to this error. Then see Appendix A “Submitting an SR ”

After this problem occurs, the driver will enter a "broken" state where is may not respond to further requests. If possible, run the VGPBA tool program, and use it to force a driver dump, then forward the resulting NETDMP##.PUB.SYS file to Hewlett-Packard for analysis. After a dump, the driver will attempt to auto-reset itself and continue. You may also use VGPBA to attempt a manual reset of the driver, after which it may be possible to continue.

CAUSE: The driver finished transferring a data frame and was preparing to pass it to an upper layer protocol, when it discovered the rendezvous ID associated with the frame was out of range of legal ID values for this driver ("Cause"= 32-bit value giving the bad ID which was specified). The driver avoided a SysAbort by making this check.

ACTION: This is a fatal error. The driver will attempt to perform a dump of all host context memory data structures, then reset itself and continue. Save the resulting NETDMP##.PUB.SYS dump data file for analysis by Hewlett-Packard. If the problem occurs frequently, wait for the problem to occur, then quickly take a system memory dump. See Appendix A “Submitting an SR ”.

CAUSE: The driver finished transferring a data frame and passed it to an upper layer protocol, but the protocol's read completor returned an error which was not one of the expected, legal errors the driver was able to handle ("Cause"= 32-bit status returned from the read completor).

ACTION: This is an informational error only. The driver incremented a statistic, logged the error, then attempted to free the read buffer and continue. However, the protocol may not have received the inbound frame, therefore some applications could be hung.

There may be a problem in the upper layer protocol. Also, if the protocol had already freed the buffer, this may have resulted in a SysAbort from the Buffer Manager. If the problem occurs frequently, start link tracing, reproduce the problem, then stop link tracing and save the resulting NMTC####. PUB.SYS file for analysis by Hewlett-Packard, and see Appendix A “Submitting an SR ”

CAUSE: The driver finished transferring a data frame, but encountered an error while trying to send the frame to an upper layer protocol via a port message ("Cause"= 32-bit status returned by the call to send_msg).

ACTION: This error is reported at a low level, where the actual send fails. It should be followed by a another error giving more information. Locate that error and look it up also. The driver will now attempt to clean up and continue.

CAUSE: The driver finished transferring a data frame, but encountered an error while trying to send the frame to an upper layer protocol via a port message ("Cause"= 32-bit status returned by the call to vg_send_msg).

ACTION: This is an informational error only. The driver has incremented a statistic, logged the error, and will now attempt to free the receive buffer and continue. However, the protocol may not have received the inbound frame, therefore some applications could be hung.

There is probably a problem in the upper layer protocol. Also, if the protocol had already freed the buffer, this may have resulted in a SysAbort from the Buffer Manager. If the problem occurs frequently, start link tracing, reproduce the problem, then stop link tracing and save the resulting NMTC####. PUB.SYS file for analysis by Hewlett-Packard, and see Appendix A “Submitting an SR ”

CAUSE: The driver finished transferring a diagnostic loopback data frame, but then discovered it was either not in loopback mode anymore, or there was no pending diagnostic request message ("Cause"= 32-bit encoded value, giving driver current state: HP use only).

ACTION: This problem most likely occurred while diagnosing some previous problem. It an informational error only, and the driver will log it and attempt to continue. If this happens frequently, see Appendix A “Submitting an SR ”

CAUSE: During a diagnostic loopback test, the driver finished transferring a diagnostic loopback data frame, but encountered an error while trying to stop and release a timer ("Cause"= 32-bit status from the call to vg_stop_timer). This timer was used to verify loopback data arrives. If this error is reported, it is because the driver has already encountered some other error.

ACTION: This is a warning that some timer resources may have been lost. The link did not connect. Typically preceded by another error message giving better information about the original cause; check log data for that error and look it up also. Unless this happens constantly, the system should continue to run, and the driver will probably retry the connect. If the problem happens every time, see Appendix A “Submitting an SR ”

CAUSE: A driver receive-frame DMA operation completed, but in doing a quick check of the DMA'ed data, the driver found all ones in the first 4 words, indicating some kind of driver/adapter card bug has occurred ("Cause"= 32-bit address of the DMA step against which the corruption was detected). Probably the driver attempted to perform a DMA transfer which was not a 4-byte multiple in length.

ACTION: This is a warning that some timer resources may have been lost. The link did not connect. Typically preceded by another error message giving better information about the original cause; check log data for that error and look it up also. Unless this happens constantly, the system should continue to run, and the driver will probably retry the connect. If the problem happens every time, see Appendix A “Submitting an SR ”

CAUSE: A driver DMA operation completed, but when the driver read from an adapter card register (io_dma_link) to determine where DMA ended, it found all ones. The driver has decided this indicated a power failure has occurred ("Cause" is not used here).

ACTION: If a power failure has actually occurred, this error can be ignored; the driver should recover automatically. But if the same problem happens all the time, see Appendix A “Submitting an SR ”

CAUSE: When processing a received data frame, the driver successfully obtained a new buffer, then was unable to obtain a DMA step to transfer the frame into that buffer ("Cause"= 32-bit value of the ring number which was out of steps: HP use only).

ACTION: This error indicates a bug in the link driver. The driver is designed to avoid this situation through use of various queues and checks. If the problem happens often, see Appendix A “Submitting an SR ”

The driver reused the buffer and dropped the received packet. Upper layer protocols typically retransmit lost packets, so operation of the system and applications should continue with only minimal degradation.

CAUSE: When processing an interrupt for a received data frame, the driver was not able to locate the adapter card data memory frame containing the data ("Cause" is not used here). The driver thinks there are no more adapter card memory frames in which to receive incoming frames, yet the card has reported another frame anyway. The driver is designed to maintain synchronization with the card, therefore it appears that either an out-of-sync condition exists, or the card has a problem.

ACTION: The driver acknowledged and dropped the interrupt and the received packet. Many upper layer protocols typically retransmit lost packets, so operation of the system and applications may continue with only minimal degradation.

Exhausting all receive resources would be a highly unusual condition. If all receive resources have really been exhausted, network load may be extremely high, and/or the HP-PB bus may be preventing frames from being returned to the card in a timely manner; incoming frames are probably now being dropped. Otherwise there may be a bug in the link driver. If the problem happens often, see Appendix A “Submitting an SR ”

CAUSE: When processing an interrupt for a received diagnostic loopback data frame, the driver was not able to locate the adapter card data memory frame containing the data ("Cause" is not used here).

ACTION: This error indicates a bug in the link driver. The driver thinks there are no more adapter card memory frames in which to receive incoming frames, yet the card has reported another frame anyway. The driver is designed to maintain synchronization with the card, therefore is appears that either an out-of-sync condition exists, or the card has a problem.

Note that exhausting all receive resources would be a highly unusual condition, especially for loopback testing. If all receive resources have really been exhausted, the HP-PB bus may be preventing frames from being returned to the card in a timely manner. If the problem happens repeatedly, see Appendix A “Submitting an SR ”

The driver acknowledged and dropped the interrupt and the received frame. The diagnostic should detect a timeout error then continue.

CAUSE: The link driver received an adapter check interrupt from the LAN Controller chip on the adapter card, indicating a fatal error has been detected ("Cause"= 32-bit hex value of the channel parameter register in the chip: see the following list).

ACTION: This error typically indicates a driver bug has resulted in incorrect use of the LAN Controller chip, however it could also indicate an adapter card hardware problem. The driver will now attempt to perform a dump of all host context data structures and adapter card memory, then reset itself and continue. Decode the "Cause" to determine the next action to take.

The "Cause" field is chip-specific, and is decoded as follows. At the time of the failure:

CAUSE: The link driver has received an interrupt from the card during normal operation, but the driver should have specifically disabled that interrupt at startup ("Cause"= 16-bit value of the LAN Controller chip's host interrupt register: HP use only).

ACTION: The driver will attempt to perform a dump of all host context data structures and adapter card memory, then reset itself and continue. Save the resulting NETDMP##.PUB.SYS file for possible analysis by Hewlett-Packard.

But first, replace the adapter card and see if this corrects the problem. If not, see Appendix A “Submitting an SR ”

CAUSE: 100VG-AnyLAN link training failed because the LAN Controller chip unexpectedly reported a statistics overflow interrupt during 100VG-AnyLAN link training. A hardware failure state was then signaled.

This code would only appear in the formatted PHY chip trace from a 100VG-AnyLAN link connect failure. It would not appear in a log event. Seeing this error implies you are already using link tracing to try to debug a problem, or are analyzing driver context data directly.

ACTION: The driver cleared statistics already, so none should overflow during link training unless there is a problem.

There could be a hardware or configuration problem with the 100VG-AnyLAN hub or switch. Check the wiring. Try plugging the card into a different port on the 100VG-AnyLAN hub or switch. Replace the transceiver module in the switch if it has one. If this does not solve the problem, replace the adapter card.

If the problem remains, use NMMGR to modify the LINK configuration for this link, to enable link tracing at startup. Reproduce the problem, then shut down the link and save the resulting NMTCnnnn.PUB.SYS trace data file for analysis by Hewlett-Packard. See Appendix A “Submitting an SR ”

CAUSE: 100VG-AnyLAN link training failed because, after the LAN Controller chip reported receiving a training frame, the driver tried to check if the frame was completely transferred into adapter card memory, but detected a powerfail instead. A power failure state was then signaled.

This code would only appear in the formatted PHY chip trace from a 100VG-AnyLAN link connect failure. It would not appear in a log event. Seeing this error implies you are already using link tracing to try to debug a problem, or are analyzing driver context data directly.

ACTION: If a power failure has actually occurred, this error can be ignored; the driver should recover automatically. If the problem happens every time, see Appendix A “Submitting an SR ”

CAUSE: 100VG-AnyLAN link training failed because after the LAN Controller chip reported receiving a training frame, it had still not finished transferring frame data into adapter card memory even after the driver waited 64 microseconds. A hardware failure state was then signaled.

This code would only appear in the formatted PHY chip trace from a 100VG-AnyLAN link connect failure. It would not appear in a log event. Seeing this error implies you are already using link tracing to try to debug a problem, or are analyzing driver context data directly.

ACTION: Replace the adapter card. If the problem continues, see Appendix A “Submitting an SR ”

CAUSE: 100VG-AnyLAN link training failed because the LAN Controller chip unexpectedly reported an interrupt of a type which the driver should have specifically disabled at startup. A hardware failure state was then signaled.

This code would only appear in the formatted PHY chip trace from a 100VG-AnyLAN link connect failure. It would not appear in a log event. Seeing this error implies you are already using link tracing to try to debug a problem, or are analyzing driver context data directly.

ACTION: Replace the adapter card. If the problem continues, there may be a driver startup bug; see Appendix A “Submitting an SR ”

CAUSE: 100VG-AnyLAN link training failed because, after the LAN Controller chip reported a training frame was sent, the driver tried to check if the frame was completely transferred out of adapter card memory, but detected a powerfail instead. A power failure state was then signaled.

This code would only appear in the formatted PHY chip trace from a 100VG-AnyLAN link connect failure. It would not appear in a log event. Seeing this error implies you are already using link tracing to try to debug a problem, or are analyzing driver context data directly.

ACTION: If a power failure has actually occurred, this error can be ignored; the driver should recover automatically. If the problem happens every time, see Appendix A “Submitting an SR ”

CAUSE: 100VG-AnyLAN link training failed because after the LAN Controller chip reported a training frame was sent, it had still not finished transferring frame data out of adapter card memory even after the driver waited 64 microseconds. A hardware failure state was then signaled.

This code would only appear in the formatted PHY chip trace from a 100VG-AnyLAN link connect failure. It would not appear in a log event. Seeing this error implies you are already using link tracing to try to debug a problem, or are analyzing driver context data directly.

ACTION: Replace the adapter card. If the problem continues, see Appendix A “Submitting an SR ”

CAUSE: 100VG-AnyLAN link training failed because after the LAN Controller chip reported a training frame was sent, the driver's ISR module detected an unexpected connect state. A software failure state was then signaled.

This code would only appear in the formatted PHY chip trace from a 100VG-AnyLAN link connect failure. It would not appear in a log event. Seeing this error implies you are already using link tracing to try to debug a problem, or are analyzing driver context data directly.

ACTION: This probably indicates a driver bug. If the problem happens frequently, use NMMGR to modify the LINK configuration for this link, to enable link tracing at startup. Reproduce the problem, then shut down the link and save the resulting NMTCnnnn.PUB.SYS trace data file for analysis by Hewlett-Packard. See Appendix A “Submitting an SR ”

CAUSE: 100VG-AnyLAN link training failed because, after the LAN Controller chip reported a status interrupt, the driver tried to read the network status register, but detected a powerfail instead. A power failure state was then signaled.

This code would only appear in the formatted PHY chip trace from a 100VG-AnyLAN link connect failure. It would not appear in a log event. Seeing this error implies you are already using link tracing to try to debug a problem, or are analyzing driver context data directly.

ACTION: If a power failure has actually occurred, this error can be ignored; the driver should recover automatically. If the problem happens every time, see Appendix A “Submitting an SR ”

CAUSE: 100VG-AnyLAN link training failed because, after the LAN Controller chip reported a status interrupt, the driver tried to read the PHY status register on the PHY chip, but detected an error. A hardware failure state was then signaled. Probably a powerfail occurred.

If a power failure has actually occurred, this error can be ignored; the driver should recover automatically. Otherwise, the MII bus may have failed; replace the adapter card. If the same problem persists, see Appendix A “Submitting an SR ”

CAUSE: 100VG-AnyLAN link training failed because, after the LAN Controller chip reported a status interrupt, the driver tried to read a statistics register, but detected a powerfail instead. A power failure state was then signaled.

This code would only appear in the formatted PHY chip trace from a 100VG-AnyLAN link connect failure. It would not appear in a log event. Seeing this error implies you are already using link tracing to try to debug a problem, or are analyzing driver context data directly.

ACTION: If a power failure has actually occurred, this error can be ignored; the driver should recover automatically. If the problem happens every time, see Appendix A “Submitting an SR ”

CAUSE: 100VG-AnyLAN link training failed because, after the LAN Controller chip reported a status interrupt, the driver tried to read the generic register on the PHY chip, but detected an error. A hardware failure state was then signaled. Probably a powerfail occurred.

If a power failure has actually occurred, this error can be ignored; the driver should recover automatically. Otherwise, the MII bus may have failed; replace the adapter card. If the same problem persists, see Appendix A “Submitting an SR ”

CAUSE: 100VG-AnyLAN link training failed because the LAN Controller chip reported a status interrupt, then when the driver tried to read the channel parameter register from the chip, a powerfail was detected instead. A hardware failure state was then signaled.

ACTION: If a power failure has actually occurred, this error can be ignored; the driver should recover automatically. Otherwise, the adapter card may have failed, or there may be a driver bug causing the adapter checks. Replace the adapter card.

If the same problem continues to occur, use NMMGR to modify the LINK configuration for this link, to enable link tracing at startup. Reproduce the problem, then shut down the link and save the resulting NMTCnnnn.PUB.SYS trace data file for analysis by Hewlett-Packard. See Appendix A “Submitting an SR ”

CAUSE: 100VG-AnyLAN link training failed because the LAN Controller chip unexpectedly reported running out of receive buffers. A hardware failure state was then signaled.

ACTION: If the driver was already low on receive buffers at the time the link was trying to reconnect, this error may be ignored; the driver should retry the link connect automatically.

Note that exhausting all receive resources would be a highly unusual condition. If all receive resources have really been exhausted, network load may be extremely high, and/or the HP-PB bus may be preventing frames from being returned to the card in a timely manner.

There could be a hardware or configuration problem with the 100VG-AnyLAN hub or switch. Check the wiring. Try plugging the card into a different port on the hub or switch. Replace the transceiver module in the switch if it has one. If this does not solve the problem, replace the adapter card.

If the problem remains, use NMMGR to modify the LINK configuration for this link, to enable link tracing at startup. Reproduce the problem, then shut down the link and save the resulting NMTCnnnn.PUB.SYS trace data file for analysis by Hewlett-Packard. See Appendix A “Submitting an SR ”

CAUSE: The driver's ISR module awoke to process a DVR request or an interrupt, but after reading status from the HP-PB interface chip on the adapter card, the driver discovered a fatal error bit had been set ("Cause"= 32-bit status value read from the chip: HP use only).

ACTION: The driver already verified the bit was not set because of a power failure. The HP-PB chip has signaled a fatal error.

There may be a hardware problem with the adapter card or the HP-PB bus. Replace the adapter card.

If the same problem still occurs, there could be excessive activity on the HP-PB bus the card is attached to. Under heavy DMA load, the HP-PB chip might encounter a timeout while trying to complete an HP-PB slave transaction, and post a fatal error. Try to reduce other bus activity by pausing applications. If the system has multiple HP-PB busses, move the card to a less active bus.

If the problem persists, there may be a hardware problem with the HP-PB bus itself. Contact your Hewlett-Packard Representative for assistance in determining paths or correcting bus hardware problems.

If the problem still cannot be traced to bus hardware, see Appendix A “Submitting an SR ”