Driver version numbered 1–n that is usually identical to the x-n ID displayed in the ANALYZE/IMAGE command output for the driver image. It includes variant information, if applicable. The full driver version includes the target OpenVMS release and is displayed by the SDA LAN/DEVICE=EWA command in the quadword driver version field.

Driver flags including the following bits:

Device type, as follows:

Current link state, as follows:

Number of seconds before transitioning from LinkWait to LinkDown.

Total number of link state up and link state down events.

Number of times the driver has reset the Tulip chip.

Number of times the driver has timed out a transmit, reset the Tulip chip, and completed outstanding I/O requests with error status.

Number of transmits that failed because the Tulip chip stopped transmitting in the middle of a packet due to running out of data (Direct Memory Access (DMA) from the transmit buffer in host memory took too long).

Number of transmits that exceeded the 1518-byte limit and were therefore truncated by the Tulip chip.

Number of receives that failed because the Tulip chip could not DMA the received packet to host memory before its internal First-In First-Out (FIFO) was overrun.

Number of receives that failed because the packet was damaged by a collision that occurred after the first 64 bytes of the packet (a late collision).

Number of times the Tulip chip was started.

Number of setup buffers sent to the Tulip chip for initialization purposes.

Number of times CSR6 (Command Register) was written for initialization purposes.

Number of times a global page was encountered during a chained transmit request, causing the driver to convert an invalid Page Table Entry (PTE) to a valid Page Frame Number (PFN).

Original contents of CSR13 (SIA Connectivity Register); shows how the console or boot driver had set up the Tulip chip.

Number of buffers copied because the transmit request contained too many segments.

Number of transmits that failed because the transmit request did not include enough data.

Number of transmits copied to a longword-aligned buffer to work around a Tulip chip hardware bug where there was only one transmit segment.

Number of times the Tulip chip erroneously indicated that a loss of carrier error occurred on a transmit.

Number of multi-segment transmits that were done to a workaround buffer, including transmits with too many segments or multi-segment longword-aligned workarounds.

Number of transmits descriptors which required multiple buffer addresses to describe. For example, a transmit segment crossed a page boundary and was not physically contiguous.

Number of times the driver interrupt service routine was called.

Number of times a 10Base5 to 10Base2 autosense selection (applies to the DE450 device only).

Number of duplex selection changes done (only applies if autosense mode is selected).

Number of unit initializations executed; since unit initialization is only executed once, this counter will be 1 if map registers were not used to map the device data structures.

Number of unit initializations executed; since unit initialization is only executed once, this counter will be 1 if map registers were used to map the device data structures.

Number of transmit buffers that were described to the Tulip chip using map registers because part of the request existed in memory outside the DMA window.

Number of receive buffers that were described to the Tulip chip using map registers because part of the request existed in memory outside the DMA window.

Number of times errors were recovered in the driver by resetting and reinitializing the Tulip chip without notifying user applications.

Number of times a potential duplex mode mismatch was detected by checking for transmit and receive errors.

Number of times that transmit and receive processing was suspended and the fork process rescheduled to allow fair usage of the CPU by other drivers.

Number of auto-negotiation sequences done.

Auto-negotiation enable flag (1 if enabled).

Current auto-negotiation state.

Counts half-second increments during the auto-negotiation process.

Current autosense state.

Speed setting saved before auto-negotiation is done.

Duplex setting saved before auto-negotiation is done.

Link partner ability mask recorded the last time auto-negotiation was done.

Current value of the LAN_FLAGS system parameter.

Transmit time limit (in seconds) after which a timeout is declared.

Resolution of the transmit timer (the real timeout is limit + interval).

Number of times remaining to do an autosense failover (starts at 1).

Time that the last autosense was initiated.

Current time (at the time which the counters were read).

Time of the last duplex mode mismatch reported.

Time of the last Cyclic Redundancy Check (CRC) or late collision error recorded.

To help determine whether the buffering requirements of the driver and the Tulip chip are sufficient for the system configuration, the driver records the amount of time from fork scheduled to the time the fork is actually run. The data is recorded in 10-millisecond increments from 10 to 310 milliseconds.

This data can be used in conjunction with the number of packets discarded due to insufficient buffers to determine whether the buffering settings of the driver (minimum and maximum receive buffers) and the amount of buffering on the Tulip chip are sufficient for normal operation. If packets are being discarded, the buffering should be increased until the number of packets lost is minimal.

The Tulip chip records how many packets are lost after it runs out of receive buffers. When the driver processes each receive packet, it also reads this "missed packet" counter to identify the fork delay value resulting in the most packets being lost.

Minimum number of receive buffers as set by default or by management request (SETMODE or LANCP command). This is used to determine the "Current minimum limit".

Maximum number of receive buffers as set by default or by management request (SETMODE or LANCP command). This is used to determine the "Current maximum limit".

Minimum number of receive buffers as determined by the driver and by management request, "Minimum buffers requested". The driver will not allow the number of receive buffers in its receive queues to drop below this value. This does not include receive buffers transferred to applications (and not yet returned).

Maximum number of receive buffers as determined by the driver and by management request, "Maximum buffers requested". The driver will deallocate receive buffers until the number allocated does not exceed this maximum. When applications return receive buffers, the number may exceed this maximum, at which point they are deallocated. Note that the driver allows this maximum to be exceeded slightly to limit allocation and deallocation activity. See "Target number of buffers maximum" below.

Current number of receive buffers owned by the driver.

Desired number of receive buffers. As receive activity does not result in lost packets, this number is gradually decreased toward the "Current minimum limit". If packets are lost, this number is dramatically increased toward the "Current maximum limit". When the driver allocates receive buffers, it allocates them until reaching this target number.

Maximum desired number of receive buffers. When an application returns a buffer to the driver, if the current number does not exceed this target maximum, the buffer is kept by the driver. Otherwise, it is deallocated.

Console messages issued by the driver.

Clear the driver counters.

This is useful in debug or test scenarios.

Force all transmit and receive buffers to be described to the Tulip chip using map registers.

If enabled, this setting is displayed in the driver flags in the driver internal counters.

Force a non-fatal (soft) error. The Tulip chip is stopped and restarted.

Specify a receive or transmit packet trace address for use in driver tracing. If the source or destination address does not match one of the four filter addresses, the packet data is not traced. For example, to filter on addresses AA-00-04-00-EF-4F and AB-00-04-01-D2-01, issue the following LANCP commands:

$ MCR LANCP SET DEVICE EWA/DEVICE_SPECIFIC=(FUNCTION="FIL1",VALUE=(%x000400aa,%x4fef))
$ MCR LANCP SET DEVICE EWA/DEVICE_SPECIFIC=(FUNCTION="FIL2",VALUE=(%x010400ab,%x01d2))

Send the periodic System ID messages immediately instead of waiting until expiry of the 8–12-minute System ID timer.

This is a convenient way to get the driver to send two packets.

Stop the Tulip chip, thereby inducing a transmit timeout on the next transmit request.

Override the default transmit timer. The ticks value is in timer ticks and is limited to the range 2–40. If the fast transmit timer is enabled, each tick is 0.25 seconds; otherwise, it is 1 second.

The current setting is displayed in the driver internal counters.

Driver version numbered 1–n that is usually identical to the x-n ID displayed in the ANALYZE/IMAGE command output for the driver image. It includes variant information, if applicable. The full driver version includes the target OpenVMS release and is displayed by the SDA LAN/DEVICE=EIA command in the quadword driver version field.

Driver flags including the following bits:

Device type, as follows:

Current value of the LAN_FLAGS system parameter.

Number of times errors were recovered in the driver by resetting and reinitializing the 82559 chip without notifying user applications.

Number of errors that resulted in notifying user applications.

Number of times a potential duplex mode mismatch was detected by checking for transmit and receive errors.

Current link state, as follows:

Total number of link state up and link state down events.

Number of times auto-negotiation was restarted.

Current auto-negotiation state.

Number of times transmit and receive processing was suspended and the fork process rescheduled to allow fair usage of the CPU by other drivers.

Number of times the driver interrupt service routine was called.

Number of times the driver has reset the 82559 chip.

Number of transmits issued via the Queue I/O (QIO) interface.

Number of unit initializations executed; since unit initialization is only executed once, this counter will be 1 if map registers were not used to map the device data structures.

Number of unit initializations executed; since unit initialization is only executed once, this counter will be 1 if map registers were used to map the device data structures.

Number of receive buffers that were described to the device using map registers because part of the request existed in memory outside the DMA window.

Number of transmit buffer segments that were described to the device using map registers because part of the request existed in memory outside the DMA window.

Number of transmit buffer segments that crossed a page boundary.

Number of times a global page was encountered during a chained transmit request, causing the driver to convert an invalid PTE to a valid PFN.

Number of PTE to PFN translations where the segment crossed a page boundary.

Number of transmit requests consisting of more than one buffer segment.

Number of transmit requests completed with error status (SS$_INCSEGTRA) because the application did not specify the transmit buffer completely.

Number of transmit requests that exceeded the maximum number of chain segments that the driver can handle; the driver then copied some of them to a temporary buffer so that it could transmit the packet.

Number of chained transmit request buffer segments that contained no data.

Number of times the driver has timed out a transmit, reset the 82559 chip, and completed outstanding I/O requests with error status.

Number of transmit requests queued because the link was not available or because too many transmit requests were already outstanding.

Number of control commands issued to the 82559 chip (for example, configuration and address filtering commands).

Number of times the driver issued a start receiver command to the 82559 chip and it did not start after 100 milliseconds, resulting in the need to reset and restart the chip.

Time of the last duplex mode mismatch reported.

Time of the last CRC or late collision error recorded.

Transmit time limit (in seconds) after which a timeout is declared.

Resolution of the transmit timer (the real timeout is limit + interval).

Number of packets transmitted successfully, tallied by the 82559 chip.

Number of transmits that failed due to excessive collisions, tallied by the 82559 chip. These occur in half-duplex mode only.

Number of transmits that failed because a collision was detected later than 512 bit-times into the transmission of the packet, tallied by the 82559 chip. These occur in half-duplex mode only.

Number of transmits that failed because the 82559 chip could not DMA data from the transmit buffers fast enough, tallied by the 82559 chip.

Number of transmits that failed because the 82559 chip detected loss of carrier during the transmission, tallied by the 82559 chip.

Number of successful transmits that were delayed because the medium was busy, tallied by the 82559 chip. These occur in half-duplex mode only.

Number of successfully transmitted packets that encountered exactly one collision during transmission (successful after retransmit), tallied by the 82559 chip. These occur in half-duplex mode only.

Number of successfully transmitted packets that encountered more than one collision during transmission (successful after multiple retransmits), tallied by the 82559 chip. These occur in half-duplex mode only.

Total number of collisions detected on transmit, tallied by the 82559 chip.

Number of flow control pause frames transmitted by the 82559 chip, tallied by the 82559 chip.

Number of receive packets delivered to the LAN driver successfully, tallied by the 82559 chip.

Number of packets received with CRC errors that are an integral number of bytes long, tallied by the 82559 chip. These packets are discarded.

Number of packets received with CRC errors that are not an integral number of bytes long, tallied by the 82559 chip. These packets are discarded.

Number of receive packets discarded due to lack of receive buffers, tallied by the 82559 chip.

Number of receive packets discarded because the internal 82559 receive FIFO overflowed (for example, the 82559 chip was not able to DMA receive data to host memory fast enough), tallied by the 82559 chip.

Number of receive packets discarded because a collision occurred during reception, tallied by the 82559 chip.

Number of receive packets that were shorter than 64 bytes (and therefore discarded), tallied by the 82559 chip.

Number of flow control pause frames received by the 82559 chip, tallied by the 82559 chip.

Number of flow control frames received with an unsupported type, tallied by the 82559 chip.

Number of times the 82559 driver checked and updated the 82559 chip receive unit state.

Number of times the 82559 chip receive unit was in the idle state.

Number of times the 82559 chip receive unit was in the ready state.

Number of times the 82559 chip receive unit was in the ready state with no remaining buffer descriptors (RBDs).

Number of times the 82559 chip receive unit was in the no resources state discarding incoming receive packets.

Number of times the driver delayed an 82559 chip restart to do another receive completion check via a fork.

Bytes remaining in the receive (RX) FIFO before the 82559 chip will request the bus. This is calculated as 128 bytes − 8n, such that 1 = 120 bytes, 2 = 112 bytes, and so on. The default value is 8 (64 bytes).

Results of the self-test done by the 82559 chip during driver unit initialization.

To help determine whether the buffering requirements of the driver and the 82559 chip are sufficient for the system configuration, the driver records the amount of time from fork scheduled to the time the fork is actually run. The data is recorded in 10-millisecond increments from 10 to 310 milliseconds.

This data can be used in conjunction with the number of packets discarded due to insufficient buffers to determine whether the buffering settings of the driver (minimum and maximum receive buffers) and the amount of buffering on the 82559 chip are sufficient for normal operation. If packets are being discarded, the buffering should be increased until the number of packets lost is minimal.

To help understand the operation of the system, driver, and 82559 chip, the driver records the time that each transmit buffer is given to the 82559 chip. When the transmit completes, the driver calculates the elapsed time, creating a histogram of transmit times from 10 to 310 milliseconds.

Minimum number of receive buffers as set by default or by management request (SETMODE or LANCP command). This is used to determine the "Current minimum limit".

Maximum number of receive buffers as set by default or by management request (SETMODE or LANCP command). This is used to determine the "Current maximum limit".

Minimum number of receive buffers as determined by the driver and by management request, "Minimum buffers requested". The driver will not allow the number of receive buffers in its receive queues to drop below this value. This does not include receive buffers transferred to applications (and not yet returned).

Maximum number of receive buffers as determined by the driver and by management request, "Maximum buffers requested". The driver will deallocate receive buffers until the number allocated does not exceed this maximum. When applications return receive buffers, the number may exceed this maximum, at which point they are deallocated. Note that the driver allows this maximum to be exceeded slightly to limit allocation and deallocation activity. See "Target number of buffers maximum" below.

Current number of receive buffers owned by the driver.

Desired number of receive buffers. As receive activity does not result in lost packets, this number is gradually decreased toward the "Current minimum limit". If packets are lost, this number is dramatically increased toward the "Current maximum limit". When the driver allocates receive buffers, it allocates them until reaching this target number.

Maximum desired number of receive buffers. When an application returns a buffer to the driver, if the current number does not exceed this target maximum, the buffer is kept by the driver. Otherwise, it is deallocated.

Console messages issued by the driver.

Clear the driver counters.

This is useful in debug or test scenarios.

Force all transmit and receive buffers to be described to the 82559 chip using map registers.

If enabled, this setting is displayed in the driver flags in the driver internal counters.

Force a non-fatal (soft) error. The 82559 chip is stopped and restarted.

Specify a receive or transmit packet trace address for use in driver tracing. If the source or destination address does not match one of the four filter addresses, the packet data is not traced. For example, to filter on addresses AA-00-04-00-EF-4F and AB-00-04-01-D2-01, issue the following LANCP commands:

$ MCR LANCP SET DEVICE EIA/DEVICE_SPECIFIC=(FUNCTION="FIL1",VALUE=(%x000400aa,%x4fef))
$ MCR LANCP SET DEVICE EIA/DEVICE_SPECIFIC=(FUNCTION="FIL2",VALUE=(%x010400ab,%x01d2))

Send the periodic System ID messages immediately instead of waiting until expiry of the 8–12-minute System ID timer.

This is a convenient way to get the driver to send two packets.

Disable the sending of periodic System ID messages.

This is used to disable transmits that may obscure other traffic of interest.

Stop the 82559 chip, thereby inducing a transmit timeout on the next transmit request.

Schedule periodic random resets. The value supplied is AND'ed with (RSCC × 69 069) and, if the result is 3, a reset is done. For example, if the value supplied is 7, a reset is done, on average, every 8 seconds.

A value of 0 disables this function, and a value of n enables it.

This is used to test error handling.

Override the default transmit timer. The ticks value is in timer ticks and is limited to the range 2–40. If the fast transmit timer is enabled, each tick is 0.25 seconds; otherwise, it is 1 second.

The current setting is displayed in the driver internal counters.

For receive DMA, override the number of bytes in the FIFO remaining before requesting the bus, to DMA the data in the FIFO to host memory. The default is 8.

The current setting is displayed in the driver internal counters.

Avoid giving receive buffers to the 82559 chip for a portion of each 2.55-second time period. The time period is defined as the low byte of the current time (EXE$GL_ABSTIM_TICS) minus the starvation time value specified. EXE$GL_ABSTIM_TICS is the current system uptime in 10-millisecond units. For example, setting a starvation value of 50 avoids giving buffers to the 82559 chip for the first 500 milliseconds of each 2.55-second period. A value of 200 starves the 82559 chip for 2 seconds of every 2.55-second period.

This function is useful when investigating application or device behavior under receive buffer starvation conditions.

Delay completion of the next transmit request for the time specified in 10-millisecond units. Since transmits are completed in order, this delays all transmit completion until after the delay. When the delay is completed, the starvation time value is cleared. If the value is set too high, another device-specific function can be issued to change it.

This function is useful for investigating application behavior when transmit completion is delayed.

Wait the specified time (in nanoseconds) at IPL 8 with the driver port lock held.

This is a convenient way to introduce a delay at IPL 8.

Restarts auto-negotiation.

Set the PCI memory write and invalidate feature of the 82559 chip. Only the low bit of the value is used; enable (1) or disable (0) this function.

The current setting is displayed in the driver internal counters.

Set the DMA read alignment feature of the 82559 chip. Only the low bit of the value is used; enable (1) or disable (0) this function. If enabled, the 82559 chip attempts to align read DMA on cache block boundaries.

The current setting is displayed in the driver internal counters.

Set the DMA write alignment feature of the 82559 chip. Only the low bit of the value is used; enable (1) or disable (0) this function. If enabled, the 82559 chip attempts to align write DMA on cache block boundaries.

The current setting is displayed in the driver internal counters.

Console messages are displayed by the driver during initialization, auto-negotiation, and link handling. However, the driver limits the total number of messages displayed. This function resets the count, allowing additional messages to be displayed.

Read Medium Dependent Interface (MDI) registers. The registers are displayed in the driver internal counters.

Corrupt a receive or transmit packet. When this function is completed, the protocol type is specified, and if it matches on a transmit or receive packet, the next packet seen is corrupted by changing the last bit in the VMS Communications Request Packet (VCRP) or Complex Chained Buffer (CXB), XORing it with a 1. The protocol type is then cleared so the corruption is not done again. The corruption is only checked when transmit or receive packet data tracing is being done (in the trace routine), so there is no performance hit for checking each packet to verify if it should be corrupted.

The following example shows how to corrupt a PEDRIVER transmit packet:

$ MCR LANCP SET DEVICE/TRACE EIA
$ MCR LANCP SET DEVICE/DEVICE_SPECIFIC=(FUNCTION="XCOR", VALUE=%x760) EIA

Specify loopvalue to enable (1) or disable (0) loopback mode.

This is useful in test scenarios to run an application in loopback mode, where for standard use the application would not allow selection of loopback mode.

The current setting is displayed in the driver internal counters.

Name of the DEGPA device.

Compilation timestamp of the driver.

Driver version numbered 1–n that is usually identical to the x-n ID displayed in the ANALYZE/IMAGE command output for the driver image. It includes variant information, if applicable. The full driver version includes the target OpenVMS release and is displayed by the SDA LAN/DEVICE=EWA command in the quadword driver version field.

Version number in hexadecimal, read from right to left.

Number of times the driver interrupt service routine was called.

Number of events completed from the event ring, such as link state changes, statistics updates, and multicast address changes.

Number of link state up and link state down events.

Number of times the driver has timed out a transmit, reset the device, and completed outstanding I/O requests with error status.

Number of times the driver has timed out an initialization request, reset the device, and completed outstanding I/O requests with error status.

Number of times the driver has reset the device.

Number of times the driver initiated the device initialization procedure (done at the end of unit initialization and after every device reset and reinitialization).

Number of unit initializations executed; since unit initialization is only executed once, this counter will be 1 if map registers were not used to map the device data structures.

Number of unit initializations executed; since unit initialization is only executed once, this counter will be 1 if map registers were used to map the device data structures.

Number of user startup and shutdown requests processed by the driver; this is typically one or two requests when a user starts up and one when a user stops.

Number of times a global page was encountered during a chained transmit request, causing the driver to convert an invalid PTE to a valid PFN.

Number of transmit requests queued because the link was not available or because too many transmit requests were already outstanding.

Number of transmit requests completed with error status (SS$_INCSEGTRA) because the application did not specify the transmit buffer completely.

Number of transmit requests that exceeded the maximum number of chain segments that the driver can handle; the driver then copied some of them to a temporary buffer so that it could transmit the packet.

Number of transmit requests with a packet length exceeding 1514 bytes (excluding CRC).

Number of transmit requests that were described to the device using map registers because part of the request existed in memory outside the DMA window.

Number of jumbo receive buffers allocated and assigned to the device.

Number of receive buffers that were described to the device using map registers because part of the request existed in memory outside the DMA window, because the receive buffer crossed a page boundary, or because the receive buffer was a jumbo buffer.

Number of times errors were recovered in the driver by resetting and reinitializing the device without notifying user applications.

Number of times a potential duplex mode mismatch was detected by checking for transmit and receive errors.

Number of commands outstanding to the device. Note that this count is adjusted when a command is about to be issued and there are no free command entries (it represents commands that most likely have been completed by the device, but the driver has not freed up the completed entries for reuse yet).

Number of commands issued to the device when the maximum number was outstanding, so the driver had to verify completion of the outstanding commands before queuing or issuing the request.

Commands that the driver has not yet issued to the device.

Event code of the last invalid or unimplemented command request.

Event code of the last unrecognized command request.

Number of times that a rescheduled fork was done. In transmit and receive processing, the driver limits the amount of time spent in the fork process before rescheduling.

Number of 1518-byte receive buffers owned by the device.

Number of 1518-byte buffer deallocations done by the driver because the number of outstanding buffers exceeded the maximum number allowed by the driver.

Number of large receive buffers owned by the device.

Minimum number of large receive buffers owned by the device. This is initially set to 1. After the first jumbo receive, the driver sets the minimum to 32.

Number of jumbo receive buffer allocations done by the driver.

Number of large buffer deallocations done by the driver because the number of outstanding buffers exceeded the maximum number allowed by the driver.

Size of the standard receive buffers. The device allows packets up to 1518 bytes (including header and CRC), plus the VMS receive buffer structure overhead (640 bytes).

This is the Ethernet packet size (1518 bytes).

Size of the jumbo receive buffers. The device allows packets up to 9018 bytes (including header and CRC), plus the VMS receive buffer structure overhead (640 bytes). However, the driver limits the buffer size to the maximum size supported by the pool lookaside lists. The buffer size is 9018 plus 640 bytes of overhead (rounded up to the next 64-byte boundary), which accommodates the full jumbo packet size.

This is the jumbo packet size (9018 bytes).

Speed requested by the driver.

Link control bits set by the driver to use during link initialization.

Current link state determined by the device.

Current value of the LAN_FLAGS system parameter.

Size of jumbo frames. The LAN_FLAGS system parameter bit 6 or the LANCP command SET DEVICE /[NO]JUMBO determines whether the maximum user data size for VMS Communications Interface (VCI) applications is the standard size (1518 bytes, excluding header and CRC) or jumbo size. The default is disabled, LAN_FLAGS bit 6 set to zero.

Determines whether the link state that the driver requests the device to use allows auto-negotiation. The LAN_FLAGS system parameter bit 5 or the LANCP command SET DEVICE /[NO]AUTO determines the setting. The default is enabled.

Set if more receive buffers have been enabled, currently unused.

Device determines whether it is installed in a 32-bit or 64-bit PCI bus and displays the result.

Device determines the PCI bus speed and displays the result.

Current value of the PCI state register which controls the DMA hardware and other PCI characteristics.

Transmit interrupts are generated every n "coalesce value" transmit completions, but no later than n "interrupt delay" microseconds after transmit completion.

Receive interrupts are generated every n "coalesce value" receive completions, but no more than n "interrupt delay" microseconds after receipt of a packet.

Set if the 4-gigabyte workaround buffer is in use. The DEGPA cannot transmit across a 4-gigabyte boundary in memory. If the driver encounters such a transmit request, it copies the transmit packet to a workaround buffer and transmits the workaround buffer.

Number of 4-gigabyte workarounds done for transmit packets.

Number of receive buffers which crossed a 4-gigabyte boundary. The driver orphans these buffers to prevent their use (allocates and never deallocates).

On very rare occasions, the DEGPA does not update a receive return ring pointer correctly. The driver detects this condition and resets the device to clear the condition and continue. This is the number of times the workaround was done.

Current time in 10-millisecond ticks of the counters request from LANCP.

Time in 10-millisecond ticks of the last statistics update from the device.

Time of the last duplex mode mismatch reported.

Time of the last CRC or late collision error recorded.

Transmit time limit (in seconds) after which a timeout is declared.

Resolution of the transmit timer (the real timeout is limit + interval).

To help determine whether the buffering requirements of the driver and the DEGPA are sufficient for the system configuration, the driver records the amount of time from fork scheduled to the time the fork is actually run. The data is recorded in 10-millisecond increments from 10 to 310 milliseconds.

This data can be used in conjunction with the number of packets discarded due to insufficient buffers to determine whether the buffering settings of the driver (minimum and maximum receive buffers) and the amount of buffering on the DEGPA are sufficient for normal operation. If packets are being discarded, the buffering should be increased until the number of packets lost is minimal.

To help understand the operation of the system, driver, and DEGPA, the driver records the time that each transmit buffer is given to the DEGPA. When the transmit completes, the driver calculates the elapsed time, creating a histogram of transmit times from 10 to 310 milliseconds.

Minimum number of receive buffers as set by default or by management request (SETMODE or LANCP command). This is used to determine the "Current minimum limit".

Maximum number of receive buffers as set by default or by management request (SETMODE or LANCP command). This is used to determine the "Current maximum limit".

Minimum number of receive buffers as determined by the driver and by management request, "Minimum buffers requested". The driver will not allow the number of receive buffers in its receive queues to drop below this value. This does not include receive buffers transferred to applications (and not yet returned).

Maximum number of receive buffers as determined by the driver and by management request, "Maximum buffers requested". The driver will deallocate receive buffers until the number allocated does not exceed this maximum. When applications return receive buffers, the number may exceed this maximum, at which point they are deallocated. Note that the driver allows this maximum to be exceeded slightly to limit allocation and deallocation activity. See "Target number of buffers maximum" below.

Current number of receive buffers owned by the driver.

Desired number of receive buffers. As receive activity does not result in lost packets, this number is gradually decreased toward the "Current minimum limit". If packets are lost, this number is dramatically increased toward the "Current maximum limit". When the driver allocates receive buffers, it allocates them until reaching this target number.

Maximum desired number of receive buffers. When an application returns a buffer to the driver, if the current number does not exceed this target maximum, the buffer is kept by the driver. Otherwise, it is deallocated.

Number of packets received with CRC errors that are not an integral number of bytes long. These packets are discarded and then counted by the device.

Number of packets received with CRC errors that are an integral number of bytes long. These packets are discarded and then counted by the device.

Number of successfully transmitted packets that encountered exactly one collision during transmission (successful after retransmit). These occur in half-duplex mode only.

Number of successfully transmitted packets that encountered more than one collision during transmission (successful after multiple retransmits). These occur in half-duplex mode only.

Number of Signal Quality Error (SQE) test errors generated after successful transmission. These are also called heartbeat errors. Some network hardware does not support this test function, so this error happens on every transmit. These occur in half-duplex mode only.

Number of successful transmits that were delayed because the medium was busy. These occur in half-duplex mode only.

Number of times a collision was detected later than 512 bit-times into the transmission of a packet. The transmit fails. These occur in half-duplex mode only.

Number of transmits that failed due to excessive collisions. These occur in half-duplex mode only.

Number of transmits that failed because of an internal Media Access Control (MAC) sublayer error other than late collision, excessive collisions, or carrier sense error.

Number of transmits that failed because the carrier was not present during any or all of the transmission attempts.

Number of received frames that were longer than the jumbo packet size. These packets are discarded and then counted by the device.

Number of receive packets discarded because of an internal MAC sublayer error that is not frame too long, alignment error, or FCS error. These packets are discarded and then counted by the device.

A unique value for each interface. Its value ranges between 1 and the value of ifNumber. The value for each interface must remain constant between reinitializations of the entity's network management system.

The type of interface, distinguished according to the physical/link protocols immediately "below" the network layer in the protocol stack. The value set by the DEGPA is 6 "ethernet-csmacd".

The size of the largest datagram that can be sent/received on the interface, specified in octets. For interfaces that are used for transmitting network datagrams, this is the size of the largest network datagram that can be sent on the interface.

This field is specified by the driver and is set to the jumbo buffer size previously described.

An estimate of the interface's current bandwidth in bits/second. For interfaces which do not vary in bandwidth or for those where no accurate estimation can be made, this object should contain the nominal bandwidth.

The desired state of the interface. The testing state indicates that no operational packets can be passed. The values are: 1 – Up, 2 – Down; 3 – Testing.

This field is always 1 because the driver does not obtain statistical updates from the DEGPA in any other state.

The current operational state of the interface. The testing state indicates that no operational packets can be passed. The values are: 1 – Up, 2 – Down; 3 – Testing.

This field is always 1 because the driver does not obtain statistical updates from the DEGPA in any other state.

The value of sysUpTime at the time the interface entered its current operational state. If the current state was entered prior to the last reinitialization of the local network management subsystem, then this object contains a value of 0.

The number of inbound packets that were chosen to be discarded, even though no errors had been detected to prevent their delivery to a higher-layer protocol. One possible reason for discarding such a packet could be to free up buffer space.

The number of inbound packets that contained errors preventing them from being deliverable to a higher-level protocol.

The number of packets received via the interface that were discarded because of an unknown or unsupported protocol.

The number of outbound packets that were chosen to be discarded even though no errors had been detected to prevent their being transmitted. One possible reason for discarding such a packet could be to free up buffer space.

The number of outbound packets that could not be transmitted because of errors.

The length of the output packet queue (in packets).

The interface's address at the protocol layer immediately "below" the network layer in the protocol stack. For interfaces that do not have such an address (for example, a serial line), this object should contain an octet string of zero length.

A textual string containing information about the interface. This string should include the name of the manufacturer, the product name, and the version of the hardware interface.

The value set by the DEPGA is blank.

The total number of octets received on the interface, including framing characters. This object is a 64-bit version of ifInOctets.

The number of packets (delivered by this sublayer to a higher sublayer) that were not addressed to a multicast or broadcast address at this sublayer. This object is a 64-bit version of ifInUcastPkts.

The number of packets (delivered by this sublayer to a higher sublayer) that were addressed to a multicast address at this sublayer. For a MAC layer protocol, this includes both Group and Functional addresses. This object is a 64-bit version of ifInMulticastPkts.

The number of packets (delivered by this sublayer to a higher sublayer) that were addressed to a broadcast address at this sublayer. This object is a 64-bit version of ifInBroadcastPkts.

The DEGPA does not distinguish between broadcast multicast and non-broadcast multicast. As such, this counter is zero.

The total number of octets transmitted out of the interface, including framing characters. This object is a 64-bit version of ifOutOctets.

The total number of packets that higher-level protocols requested be transmitted and that were not addressed to a multicast of broadcast address at this sublayer, including those that were discarded or not sent. This object is a 64-bit version of ifOutUcastPkts.

The total number of packets that higher-level protocols requested be transmitted and that were addressed to a multicast address at this sublayer, including those that were discarded or not sent. For a MAC layer protocol, this includes both Group and Functional addresses. This object is a 64-bit version of ifOutMulticastPkts.

The total number of packets that high-level protocols requested be transmitted and that were addressed to a broadcast address at this sublayer, including those that were discarded or not sent. This object is a 64-bit version of ifOutBroadcastPkts.

The DEGPA does not distinguish between broadcast multicast and non-broadcast multicast. As such, this counter is zero.

Indicates whether linkUp/linkDown traps should be generated for this interface. By default, this object should have the value enabled (1) for interfaces which do not operate "on top" of any other interface (as defined in the ifStackTable), and disabled (2) otherwise.

This value is set to 2 by the DEGPA.

An estimate of the interface's current bandwidth in units of 1 000 000 bits/second. If this object reports a value of n, then the speed of the interface is somewhere in the range of (n − 500 000) to (n + 499 999). For interfaces that do not vary in bandwidth or for those where no accurate estimation can be made, this object should contain the nominal bandwidth. For a sublayer that has no concept of bandwidth, this object should be 0.

This value is set to 1000 by the DEGPA.

This object has a value of false (2) if this interface only accepts packets/frames that are addressed to this station. This object has a value of true (1) when the station accepts all packets/frames transmitted on the media. The value 1 is only legal on certain types of media. If legal, setting this object to a value of 1 may require the interface to be reset before becoming effective. The value of ifPromiscuousMode does not affect the reception of broadcast and multicast packets/frames by the interface.

This object has the value true (1) if the interface sublayer has a physical connector and the value false (2) otherwise.

Number of times the driver changed the host state. It can be in one of two states, up or down. The driver issues a host state up command when the first user starts, and a host state down when the last user stops.

Unused.

Unused.

Unused.

Unused.

Number of times the driver issued a multicast address add command to the device to add a new multicast address to the multicast filtering table. The driver maintains its own multicast address table and updates the device whenever its table changes.

Number of times the driver issued a multicast address delete command to the device to delete a multicast address from the multicast filtering table. The driver maintains its own multicast address table and updates the device whenever its table changes.

Number of times the driver enabled or disabled promiscuous receive mode. The driver issues these commands whenever a user enables or disables promiscuous mode.

Number of times the driver issued a link negotiate command to the device to cause it to set up the link again. The driver issues this command only when a device-specific (debug) command is issued via LANCP to explicitly set a new link value.

Number of times the driver issues a set MAC address command to change the MAC address of the device. Typically, this is issued by the driver once when DECnet starts.

Unused.

Number of times the driver enabled or disabled all multicast receive mode. The driver issues these commands whenever a user enables or disables all multicast mode.

Number of clear statistics commands the driver issued to the device on device startup. Normally, there is one clear statistics command for every reset that is done, plus any device-specific (debug) commands issued via LANCP to explicitly clear the counters.

Unused.

Unused.

Unused.

Number of commands issued by the driver that were not recognized by the device.

Number of TG_EVENT_FIRMWARE_OPERATIONAL events generated.

Number of TG_EVENT_LINK_STATE_CHANGED events generated.

Number of TG_EVENT_STATS_UPDATED events generated.

Number of TG_EVENT_ERROR events generated.

Number of TG_EVENT_MULTICAST_LIST_UPDATED events generated.

Number of TG_EVENT_RESET_JUMBO_RING events generated.

Number of times the DEGPA device has seen updates to the send producer index.

Number of times the send consumer index was updated.

Number of times the receive return producer index was updated.

Number of interrupts generated by the DEGPA device.

Number of interrupts not generated by the DEPGA device (because of interrupt mitigation).

Number of times the event max coalesce buffer descriptors (BD) threshold was reached.

Number of times the BD_FLAG_COAL_NOW flag was set or that the send max coalesce BD threshold was reached.

Number of times the receive max coalesce BD threshold was reached. When this happens, the firmware updates the receive return producer index for the host.

Number of times a DMA read overrun error occurred.

Number of times a DMA read underrun error occurred.

Number of times a DMA write overrun error occurred.

Number of times a DMA write underrun error occurred.

Number of times a DMA read master abort error occurred.

Number of times a DMA write master abort error occurred.

Number of times the DMA write ring was full.

Number of times the DMA read ring was full.

Number of times the device event ring was full.

Number of times the DMA write ring was full trying to write either the DMA event or event producer to host memory.

Number of times the MAC transmit descriptor ring was full.

Number of times the transmit buffer space was full.

Number of times the device ran out of DMA write descriptors.

Number of times the device ran out of receive buffer descriptors.

Number of times the device could not place a buffer descriptor in the return ring because it was full.

Number of send buffer descriptors currently being processed by the device.

Number of standard (1518 bytes) receive buffer descriptors owned by the device.

Number of jumbo receive buffer descriptors owned by the device.

Unused, always 0.

Number of receive buffer descriptors owned by the device.

Number of transmit buffer descriptors owned by the device.

Number of times a jumbo frame was split into multiple standard buffer descriptors.

Number of times an SBus DMA bug was worked around.

Number of times posting an event was delayed.

Number of receive packets dropped because of late collisions. These occur in half-duplex mode only.

Number of receive packets dropped because of the loss of a link, such as a cable disconnect, broken cable, NIC hardware failure, or link partner hardware failure.

Number of receive packets dropped because of Physical Layer (PHY) decode errors, such as a hardware failure that generates so much noise that the PHY cannot recognize the signal, or some other hardware failure.

Number of receive packets aborted by MAC because of remote errors, such as receiving a packet smaller than 64 bytes, a PHY decode error, a collision detected during receipt, or an error occurring during gigabit half-duplex frame extension.

Number of receive packets dropped because of a lack of NIC internal resource, such as memory space or MAC descriptors. This usually occurs because the bus is too slow.

Number of receive packets dropped because the destination address (DA) in the packet does not match our address. This happens regularly on full-duplex repeaters or during switch flooding.

Number of receive packets dropped because the destination address in the packet does not match the multicast address list.

Number of flow control packets received.

Number of receive packets dropped because of lack of space. This usually occurs because the bus is too slow.

Number of receive packets dropped because of collisions. This is caused by two nodes sending messages simultaneously. These occur in half-duplex mode only.

Number of MAC receive attentions, including receive descriptor attention, receive buffer attention, flow control XON sent, flow control XOFF sent, and FIFO overrun.

Number of link state change attentions, including auto-negotiation changed, link state error, and link ready changed.

Number of sync lost attentions.

Number of link config attentions, possibly caused by the link partner changing its link configuration. This does not indicate hardware failure unless the actual number of link configuration changes is smaller than this counter.

Number of times the MAC was reset. This is caused by link loss and attempts to reestablish the link.

Unused.

Number of receive buffer descriptor attentions which is triggered by the number of received buffer descriptors reaching a predefined threshold.

Number of times the receive buffer got cleaned up when it was full and the frame received count was zero. This indicates that the data in the receive buffer was unreliable; this can happen if the remote mode sent continuous error frames.

Number of times the receive buffer got cleaned up when it was full and the frame received count was 1. This could happen if the remote node sent continuous error frames.

Number of times the receive buffer got cleaned up when it was full and the frame received count was greater than 1. This could happen if the remote node sent continuous error frames.

Number of times the device set up a timer to wait for receive buffer space to be freed up when the receive buffer was full. This can happen if the remote node sent continuous error frames.

Number of times the DMA buffer got cleaned up when the receive buffer was full. This can happen if the remote node sent continuous error frames.

Transmit collision histogram. These are updated in half-duplex mode only.

Total number of transmit attentions.

Console messages issued by the driver.

Clear the driver counters.

This is useful in debug or test scenarios.

Force all transmit and receive buffers to be described to the DEGPA using map registers.

If enabled, this setting is displayed in the driver flags in the driver internal counters.

Force a non-fatal (soft) error. The DEGPA is stopped and restarted.

Specify a receive or transmit packet trace address for use in driver tracing. If the source or destination address does not match one of the four filter addresses, the packet data is not traced. For example, to filter on addresses AA-00-04-00-EF-4F and AB-00-04-01-D2-01, issue the following LANCP commands:

$ MCR LANCP SET DEVICE EWA/DEVICE_SPECIFIC=(FUNCTION="FIL1",VALUE=(%x000400aa,%x4fef))
$ MCR LANCP SET DEVICE EWA/DEVICE_SPECIFIC=(FUNCTION="FIL2",VALUE=(%x010400ab,%x01d2))

Send the periodic System ID messages immediately instead of waiting until expiry of the 8–12-minute System ID timer.

This is a convenient way to get the driver to send two packets.

Stop the DEGPA, thereby inducing a transmit timeout on the next transmit request.

Override the default transmit timer. The ticks value is in timer ticks and is limited to the range 2–40. If the fast transmit timer is enabled, each tick is 0.25 seconds; otherwise, it is 1 second.

The current setting is displayed in the driver internal counters.

Wait the specified time (in nanoseconds) at IPL 8 with the driver port lock held.

This is a convenient way to introduce a delay at IPL 8.

Set the requested link settings for the DEGPA, then issue a command to the DEGPA requesting that link negotiation be redone.

Change the interrupt mitigation delay on transmit completion value, the "Transmit interrupt delay" value. This value is in microseconds. If out of range, 1–1000, it is set to 1.

Change the interrupt mitigation delay on receive completion value, the "Receive interrupt delay" value. This value is in microseconds. If out of range, 1–1000, it is set to 1.

Change the interrupt mitigation coalesce on transmit completion value, the "Transmit coalesce value". This value is in number of packets.

Change the interrupt mitigation coalesce on receive completion value, the "Receive coalesce value". This value is in number of packets.

Name of the 5700 device.

Compilation timestamp of the driver.

Driver version numbered 1–n that is usually identical to the x-n ID displayed in the ANALYZE/IMAGE command output for the driver image. It includes variant information, if applicable. The full driver version includes the target OpenVMS release and is displayed by the SDA LAN/DEVICE=EWA command in the quadword driver version field.

Hardware revision level identified by the Broadcom 5700 chip revision. It is displayed as A0, A1, B0, B1, B2, C0, C1, C2. If the version is later than the driver recognizes, it is displayed as >C2, for example. The actual revision is located in bits <31:16> of the Misc Host Control register displayed in the Registers section.

ID of the PHY chip found on the device. Bits <31:10> is the Organizationally Unique Identifier (OUI), bits <9:4> is the model number and bits <3:0> is the revision.

Number of times the driver interrupt service routine was called.

Number of link transitions seen by the driver.

Number of times a second check of the link state avoided a transition from link up to link down.

Number of times the error bit in the status block was set at the same time the fiber link partner was sending configuration data for auto-negotiation.

Number of times the link state change bit was set in the status block.

Number of times the driver checked the current link status.

Number of times the driver executed the auto-negotiation procedure.

Number of times the 5700 chip was reset.

Number of times the 5700 chip reset was retried because the 5700 firmware did not complete initialization the first time.

Number of times the driver initialized the 5700 chip.

Number of unit initializations executed; since unit initialization is only executed once, this counter will be 1 if map registers were not used to map the device data structures.

Number of unit initializations executed; since unit initialization is only executed once, this counter will be 1 if map registers were used to map the device data structures.

Number of user startup and shutdown requests processed by the driver; this is typically one or two requests when a user starts up and one when a user stops.

Number of times a global page was encountered during a chained transmit request, causing the driver to convert an invalid PTE to a valid PFN.

Number of transmit requests queued because the link was not available or because too many transmit requests were already outstanding.

Number of times the driver has timed out a transmit, reset the device, and completed outstanding I/O with error status.

Number of transmit requests completed with error status (SS$_INCSEGTRA) because the application did not specify the transmit buffer completely.

Number of transmit requests that exceeded the maximum number of chain segments that the driver can handle; the driver then copied some of them to a temporary buffer so that it could transmit the packet.

Number of transmit requests with a packet length exceeding 1514 bytes (excluding CRC).

Number of transmit requests that were described to the device using map registers because part of the request existed in memory outside the DMA window.

Number of jumbo receive buffers allocated and assigned to the device.

Number of receive buffers that were described to the device using map registers because part of the request existed in memory outside the DMA window, because the receive buffer crossed a page boundary, or because the receive buffer was a jumbo buffer.

Number of receive packets discarded by the driver due to receive error. By default, the 5700 chip does not deliver damaged receive packets to the driver, but can be asked to do so by a device-specific function.

Number of times the driver detected a receive FIFO overflow.

Number of times errors were recovered in the driver by resetting and reinitializing the device without notifying user applications.

Number of times a potential duplex mode mismatch was detected by checking for transmit and receive errors.

Number of times that a rescheduled fork was done. In transmit and receive processing, the driver limits the amount of time spent in the fork process before rescheduling.

Number of 1518-byte receive buffers owned by the device.

Number of 1518-byte buffer deallocations done by the driver because the number of outstanding buffers exceeded the maximum number allowed by the driver.

Number of large receive buffers owned by the device.

Minimum number of large receive buffers owned by the device. This is initially set to 32. After the first jumbo receive, the driver sets the minimum to 128.

Number of jumbo receive buffer allocations done by the driver.

Number of large buffer deallocations done by the driver because the number of outstanding buffers exceeded the maximum number allowed by the driver.

Size of the standard receive buffers. The device allows packets up to 1518 bytes (including header and CRC), plus the VMS receive buffer structure overhead (640 bytes).

This is the Ethernet packet size (1518 bytes).

Size of the jumbo receive buffers. The device allows packets up to 9018 bytes (including header and CRC), plus the VMS receive buffer structure overhead (640 bytes). However, the driver limits the buffer size to the maximum size supported by the pool lookaside lists. The buffer size is 9018 plus 640 bytes of overhead (rounded up to the next 64-byte boundary), which accommodates the full jumbo packet size.

This is the jumbo packet size (9018 bytes).

Speed and duplex mode requested by a user.

Current link state.

Flow control capabilities reported for the link partner.

Current value of the one-second timer that waits for the link to come back before resetting the device to free pending transmit requests.

Driver flags including the following bits:

Current driver state, as follows:

• 0 – Driver state is undefined.
• 1 – Driver state is resetting.
• 2 – Driver is running, but the link is down. Completing transmits with error status.
• 4 – Driver is running, and the link is up. Processing transmits and receives.
• 8 – Device is not usable.

Current value of the LAN_FLAGS system parameter.

Device determines whether it is installed in a 32-bit or 64-bit PCI bus and displays the result.

Device determines whether it is installed in a low-speed (33-MHz PCI or 66-MHz PCI-X) bus or high-speed (66-MHz PCI or 133-MHz PCI-X) bus and displays the result.

Device determines whether it is installed in a PCI or PCI-X bus and displays the result.

Contents of the MSI_CONTROL register that stores the Message Signaled Interrupts (MSI) status. If MSI is enabled, bit <0> is set. Bits <3:1> are the number of requested messages (always set to 3 by the device). Bits <6:4> are the number of messages allocated to the device by the system. If the /DEBUG qualifier is specified, more MSI context is displayed, such as MSI Address and Data registers.

Contents of the DMA control register which regulates read and write DMA operations.

Transmit interrupts are generated every n "coalesce value" transmit completions, but no later than n "interrupt delay" microseconds after transmit completion.

Receive interrupts are generated every n "coalesce value" receive completions, but no more than n "interrupt delay" microseconds after receipt of a packet.

Total time (in microseconds) waiting for the device during initialization including shutdown.

Total time (in microseconds) waiting for the device during setup of the link.

Transmit time limit (in seconds) after which a timeout is declared.

Resolution of the transmit timer (the real timeout is limit + interval).

Last value written to and read from the Misc Host Control register.

Last value written to and read from the MAC Mode register.

Last value written to and read from the MAC Status register.

Last value written to and read from the MI Status register.

Last value written to and read from the RX Mode register.

Last value written to and read from the TX Status register.

Current system uptime.

Last time the device was reset.

Last time a link up transition occurred.

Last time a link down transition occurred.

Total time the link has been up.

Total time the link has been down.

Last time the driver started auto-negotiation on the fiber NIC.

Last time the driver completed auto-negotiation on the fiber NIC.

Total time spent doing auto-negotiation on the fiber NIC.

Time of the last transmit timeout.

Time of the last soft error.

Time of the last duplex mode mismatch reported.

Time of the last CRC or late collision error recorded.

Auto-negotiation context for driver auto-negotiation on the fiber NIC.

Minimum number of receive buffers as set by default or by management request (SETMODE or LANCP command). This is used to determine the "Current minimum limit".

Maximum number of receive buffers as set by default or by management request (SETMODE or LANCP command). This is used to determine the "Current maximum limit".

Minimum number of receive buffers as determined by the driver and by management request, "Minimum buffers requested". The driver will not allow the number of receive buffers in its receive queues to drop below this value. This does not include receive buffers transferred to applications (and not yet returned).

Maximum number of receive buffers as determined by the driver and by management request, "Maximum buffers requested". The driver will deallocate receive buffers until the number allocated does not exceed this maximum. When applications return receive buffers, the number may exceed this maximum, at which point they are deallocated. Note that the driver allows this maximum to be exceeded slightly to limit allocation and deallocation activity. See "Target number of buffers maximum" below.

Current number of receive buffers owned by the driver.

Desired number of receive buffers. As receive activity does not result in lost packets, this number is gradually decreased toward the "Current minimum limit". If packets are lost, this number is dramatically increased toward the "Current maximum limit". When the 5700 driver allocates receive buffers, it allocates them until reaching this target number.

Maximum desired number of receive buffers. When an application returns a buffer to the driver, if the current number does not exceed this target maximum, the buffer is kept by the driver. Otherwise, it is deallocated.

To help determine whether the buffering requirements of the driver and the 5700 chip are sufficient for the system configuration, the driver records the amount of time from fork scheduled to the time the fork is actually run. The data is recorded in 10-millisecond increments from 10 to 310 milliseconds.

This data can be used in conjunction with the number of packets discarded due to insufficient buffers to determine whether the buffering settings of the driver (minimum and maximum receive buffers) and the amount of buffering on the 5700 chip are sufficient for normal operation. If packets are being discarded, the buffering should be increased until the number of packets lost is minimal.

To help understand the operation of the system, driver, and 5700 chip, the driver records the time that each transmit buffer is given to the 5700 chip. When the transmit completes, the driver calculates the elapsed time, creating a histogram of transmit times from 10 to 310 milliseconds.

After an interrupt, this longword is nonzero. The driver fork process clears the status longword so the driver can recognize whether there is pending work to be done (such as checking the ring indexes for completions or checking the link status). The bits in the longword are defined as follows:

• Bit 1 – Link changed status.
• Bit 2 – Status block updated flag.
• Bit 4 – Status block error.

Unused.

Current position of the 5700 driver in the jumbo receive buffer ring.

Current position of the 5700 driver in the standard receive buffer ring.

Current position of the 5700 driver in the receive return ring.

Current position of the 5700 driver in the send ring.

Number of bytes successfully received.

Number of runt packets less than 64 bytes long received and discarded.

Number of packets successfully received that were not addressed to a multicast or broadcast address.

Number of packets successfully received that were addressed to a multicast address, but not to the broadcast address.

Number of packets successfully received that were addressed to the broadcast address.

Number of packets received with CRC errors that are an integral number of bytes long. These packets are discarded and are counted by the device.

Number of packets received with CRC errors that are not an integral number of bytes long. These packets are discarded and are counted by the device.

Number of XON frames received. An XON frame is a MAC control frame with a pause command and a length equal to zero.

Number of XOFF frames received. An XOFF frame is a MAC control frame with a pause command and a length greater than zero.

Number of other MAC control frames received. These are MAC control frames with no pause command.

Number of times the transmitter was disabled because of a receive of an XOFF frame.

Number of received frames that were longer than the jumbo packet size. These packets are discarded and are counted by the device.

Number of frames received that are longer than the specified maximum frame time (for example, a jabber frame).

Number of frames received with a size less than 64 bytes (including a correct CRC field).

Number of frames received where the 802.3 length field does not match the total frame size.

Number of frames received where the field is in the range of 1523 to 1535 (for example, an invalid type field and a length error).

Number of packets of this size received.

Number of bytes successfully transmitted.

Number of collisions experienced.

Number of XON packets sent in support of flow control.

Number of XOFF packets sent in support of flow control.

Number of flow control sequences done.

Number of transmits that failed because of an internal MAC sublayer error other than late collision, excessive collisions, or carrier sense error.

Number of successfully transmitted packets that encountered exactly one collision during transmission (successful after retransmit). These occur in half-duplex mode only.

Number of successfully transmitted packets that encountered more than one collision during transmission (successful after multiple retransmits). These occur in half-duplex mode only.

Number of successful transmits that were delayed because the medium was busy. These occur in half-duplex mode only.

Number of transmits that failed because of excessive collisions. These occur in half-duplex mode only.

Number of times a collision was detected later than 512 bit-times into the transmission of a packet. The transmit fails. These occur in half-duplex mode only.

Number of successfully transmitted packets that encountered n collisions during transmission (successful after n retransmits). These occur in half-duplex mode only.

Number of successfully transmitted packets that were not addressed to a multicast or broadcast address.

Number of successfully transmitted packets that were addressed to a multicast address but not to the broadcast address.

Number of successfully transmitted packets that were addressed to a broadcast address.

Number of transmits that failed because a carrier was not present during any or all of the transmission attempts.

Number of outbound packets that were chosen to be discarded even though no errors had been detected to prevent their being transmitted. One possible reason for discarding such a packet could be to free up buffer space.

Number of outbound packets that could not be transmitted because of errors.

Number of frames received onto each of the return rings.

Number of frames received but discarded after validation by the receive filters.

Number of times the DMA write queue was full.

Number of times the DMA write high-priority queue was full.

Number of times the NIC ran out of receive buffer descriptors.

Number of inbound packets that were chosen to be discarded even though no errors had been detected to prevent their being deliverable to a higher-layer protocol. One possible reason for discarding such a packet could be to free up buffer space.

Number of inbound packets that contained errors that prevented them from being deliverable to a higher-layer protocol.

Number of times the receive max coalesce frames threshold was reached, resulting in a status block update and interrupt.

Number of frames sent from each of the send rings.

Number of times the DMA read queue was full.

Number of times the DMA read high-priority queue was full.

Number of times the send data completion flow-through-queue (FTQ) was full.

Number of times the NIC has seen updates to any send producer ring index.

Number of times the status block was updated (written to host memory). If the driver is not currently in its interrupt service routine, an interrupt is generated after the update.

Number of interrupts generated by the NIC.

Number of interrupts avoided by the NIC (because of interrupt mitigation).

Number of times the send max coalesce frames threshold was reached, resulting in a status block update and interrupt.

Consists of a list of the contents-significant 5700 chip registers, collected when internal driver counters were requested.

Consists of the Electrically Erasable Programmable Read-Only Memory (EEPROM) contents of the non-volatile memory on the 5700 NIC, which contains manufacturing information.

Console messages issued by the driver.

Clear the driver counters.

This is useful in debug or test scenarios.

Force all transmit and receive buffers to be described to the 5700 chip using map registers.

If enabled, this setting is displayed in the driver flags in the driver internal counters.

Force a non-fatal (soft) error. The 5700 chip is stopped and restarted.

Specify a receive or transmit packet trace address for use in driver tracing. If the source or destination address does not match one of the four filter addresses, the packet data is not traced. For example, to filter on addresses AA-00-04-00-EF-4F and AB-00-04-01-D2-01, issue the following LANCP commands:

$ MCR LANCP SET DEVICE EWA/DEVICE_SPECIFIC=(FUNCTION="FIL1",VALUE=(%x000400aa,%x4fef))
$ MCR LANCP SET DEVICE EWA/DEVICE_SPECIFIC=(FUNCTION="FIL2",VALUE=(%x010400ab,%x01d2))

Send the periodic System ID messages immediately instead of waiting until expiry of the 8–12-minute System ID timer.

This is a convenient way to get the driver to send two packets.

Disable the sending of periodic System ID messages.

This is used to disable transmits that may obscure other traffic of interest.

Stop the 5700 chip, thereby inducing a transmit timeout on the next transmit request.

Override the default transmit timer. The ticks value is in timer ticks and is limited to the range 2–40. If the fast transmit timer is enabled, each tick is 0.25 seconds; otherwise, it is 1 second.

The current setting is displayed in the driver internal counters.

Wait the specified time (in nanoseconds) at IPL 8 with the driver port lock held.

This is a convenient way to introduce a delay at IPL 8.

Schedule periodic random resets. The value supplied is AND'ed with (RSCC × 69 069) and, if the result is 3, a reset is done. For example, if the value supplied is 7, a reset is done, on average, every 8 seconds.

A value of 0 disables this function, and a value of n enables it.

This is used to test error handling.

Send the next packet without a valid CRC.

This is used to generate CRC errors for test purposes.

If value is zero, the chip will discard bad received packets. If value is nonzero, the bad packets will be received and discarded by the driver. This allows the packets to be traced and inspected.

Change the interrupt mitigation delay on transmit completion value, the "Transmit interrupt delay" value. This value is in microseconds. If less than 1, it is set to 1. If greater than 1000, it is set to 1000.

Change the interrupt mitigation delay on receive completion value, the "Receive interrupt delay" value. This value is in microseconds. If less than 1, it is set to 1. If greater than 1000, it is set to 1000.

Change the interrupt mitigation coalesce on transmit completion value, the "Transmit coalesce value". This value is in number of packets. If less than 1, it is set to 1. If greater than 64, it is set to 64.

Change the interrupt mitigation coalesce on receive completion value, the "Receive coalesce value". This value is in number of packets. If less than 1, it is set to 1. If greater than 128, it is set to 128.

If value is clear, disable dynamic interrupt mitigation (DIM). If set, enable DIM. The current setting is displayed in the driver internal counters.

Restart auto-negotiation.

Generate an interrupt.

Delay issuing the next transmit request for the time specified in 10-millisecond units. A maximum of 2000 (20 seconds) is allowed.

This function is useful for investigating application behavior when a transmit request is delayed.

If set to 1 (enable), the driver crashes the system with a NETDLLERR Bugcheck if a transmit timeout occurs. If 0 (disable), transmit timeout results in a device reset.

If enabled, this setting is displayed in the driver flags in the driver internal counters.

If set to 1 (enable), the driver crashes the system with a NETDLLERR Bugcheck if a long transmit occurs. If 0 (disable), a long transmit completion is counted.

If enabled, this setting is displayed in the driver flags in the driver internal counters.

If set to 1 (enable), the driver crashes the system with a NETDLLERR Bugcheck if a long fork occurs. If 0 (disable), a long time to run a fork process is recorded in the counters.

If enabled, this setting is displayed in the driver flags in the driver internal counters.

If set to 1 (enable), the driver crashes the system with a NETDLLERR Bugcheck if a long one second occurs. If 0 (disable), a long time before the one-second timer fork process is run is recorded in the counters.

If enabled, this setting is displayed in the driver flags in the driver internal counters.

Change the setting of the driver flag "all messages". If the "all messages" flag is set, the driver displays all console messages. The default setting is bit 31 of the LAN_FLAGS system parameter. This function allows the "all messages" setting to be set for an individual device rather than all LAN devices on the system.

If enabled, this setting is displayed in the driver flags in the driver internal counters.

Specify loopvalue to enable (1) or disable (0) loopback mode.

This is useful in test scenarios to run an application in loopback mode, where for standard use the application would not allow selection of loopback mode.

The current setting is displayed in the driver internal counters.

Console messages are displayed by the driver during initialization, auto-negotiation, and link handling. However, the driver limits the total number of messages displayed. This function resets the count, allowing additional messages to be displayed.

Corrupt a receive or transmit packet. When this function is completed, the protocol type is specified, and if it matches on a transmit or receive packet, the next packet seen is corrupted by changing the last bit in the VCRP or CXB, XORing it with a 1. The protocol type is then cleared so the corruption is not done again. The corruption is only checked when transmit or receive packet data tracing is being done (in the trace routine), so there is no performance hit for checking each packet to verify if it should be corrupted.

The following example shows how to corrupt a PEDRIVER transmit packet:

$ MCR LANCP SET DEVICE/TRACE EWA
$ MCR LANCP SET DEVICE/DEVICE_SPECIFIC=(FUNCTION="XCOR", VALUE=%x760) EWA

Disable flow control (if value is zero) or enable flow control (if value is nonzero).

Simulate a counter value by writing to device memory where the counters are located and incrementing a value.

Force a hardware bug.

Write the DMA Control Register with the value given.

Write the device register specified with the value given.

Force a link state change interrupt.

(SYS$EW5700_MON.EXE driver only).

If value is zero, disable link state change interrupts. If value is nonzero, enable link state change interrupts.

Force link indication.

Change the link bounce parameters. The values are defined as follows:

If any of the times are not supplied, all of the values are set to the defaults.

Name of the Intel 1Gb device.

Compilation timestamp of the driver.

Driver version numbered 1–n that is usually identical to the x-n ID displayed in the ANALYZE/IMAGE command output for the driver image. It includes variant information, if applicable. The full driver version includes the target OpenVMS release and is displayed by the SDA LAN/DEVICE=EIA command in the quadword driver version field.

Hardware revision level of the chip.

ID of the PHY chip found on the device. Bits <31:10> is the OUI, bits <9:4> is the model number and bits <3:0> is the revision.

Number of times the driver interrupt service routine was called.

Number of link transitions seen by the driver.

Number of times a cable fault was detected for the fiber NIC.

Number of link state changes reported in the interrupt control register.

Number of times the driver checked the current link status.

Number of times the device was reset.

Number of unit initializations executed; since unit initialization is only executed once, this counter will be 1 if map registers were not used to map the device data structures.

Number of unit initializations executed; since unit initialization is only executed once, this counter will be 1 if map registers were used to map the device data structures.

Number of user startup and shutdown requests processed by the driver; this is typically one or two requests when a user starts up and one when a user stops.

Number of times a global page was encountered during a chained transmit request, causing the driver to convert an invalid PTE to a valid PFN.

Number of transmit requests queued because the link was not available or because too many transmit requests were already outstanding.

Number of times the driver has timed out a transmit, reset the device, and completed outstanding I/O with error status.

Number of transmit requests completed with error status (SS$_INCSEGTRA) because the application did not specify the transmit buffer completely.

Number of transmit requests that exceeded the maximum number of chain segments that the driver can handle; the driver then copied some of them to a temporary buffer so that it could transmit the packet.

Number of transmit requests with a packet length exceeding 1514 bytes (excluding CRC).

Number of transmit requests that were described to the device using map registers because part of the request existed in memory outside the DMA window.

Number of jumbo receive buffers allocated and assigned to the device.

Number of receive buffers that were described to the device using map registers because part of the request existed in memory outside the DMA window, because the receive buffer crossed a page boundary, or because the receive buffer was a jumbo buffer.

Number of receive packets discarded by the driver due to receive error. By default, the chip does not deliver damaged receive packets to the driver, but can be asked to do so by a device-specific function.

Number of times errors were recovered in the driver by resetting and reinitializing the device without notifying user applications.

Number of times a potential duplex mode mismatch was detected by checking for transmit and receive errors.

Number of times that a rescheduled fork was done. In transmit and receive processing, the driver limits the amount of time spent in the fork process before rescheduling.

Number of errors reading or writing a PHY register.

Size of the standard receive buffers. The device allows packets up to 1518 bytes (including header and CRC), plus the VMS receive buffer structure overhead (640 bytes).

This is the Ethernet packet size (1518 bytes).

Size of the jumbo receive buffers. The device allows packets up to 16 384 bytes (including header and CRC), plus the VMS receive buffer structure overhead (640 bytes). However, the driver limits the packet size to 8192 bytes, so the buffer size is 8192 plus 640 bytes of overhead (rounded up to the next 64-byte boundary).

This is the jumbo packet size (8192 bytes).

Speed and duplex mode requested by a user.

Current link state.

Current value of the one-second timer that waits for the link to come back before resetting the device to free pending transmit requests.

Driver flags.

Current driver state, as follows:

• 0 – Driver state is undefined.
• 1 – Driver state is resetting.
• 2 – Driver is running, but the link is down. Completing transmits with error status.
• 4 – Driver is running, and the link is up. Processing transmits and receives.
• 8 – Device is not usable.

Current value of the LAN_FLAGS system parameter.

Device determines whether it is installed in a 32-bit or 64-bit PCI bus and displays the result.

Device determines whether it is installed in a low-speed (33-MHz PCI or 66-MHz PCI-X) bus or high-speed (66-MHz PCI or 133-MHz PCI-X) bus and displays the result.

Device determines whether it is installed in a PCI or PCI-X bus and displays the result.

Minimum delay between interrupts, in units of 256 nanoseconds.

Number of descriptors that the chip will accumulate before writing them back.

Amount of delay after transmit completion that an interrupt is generated.

Amount of delay after receive completion that an interrupt is generated.

Transmit time limit (in seconds) after which a timeout is declared.

Resolution of the transmit timer (the real timeout is limit + interval).

Current system uptime.

Last time the device was reset.

Last time a link up transition occurred.

Last time a link down transition occurred.

Total time the link has been up.

Total time the link has been down.

Time of the last transmit timeout.

Time of the last soft error.

Time of the last duplex mode mismatch reported.

Time of the last CRC or late collision error recorded.

Minimum number of receive buffers as set by default or by management request (SETMODE or LANCP command). This is used to determine the "Current minimum limit".

Maximum number of receive buffers as set by default or by management request (SETMODE or LANCP command). This is used to determine the "Current maximum limit".

Minimum number of receive buffers as determined by the driver and by management request, "Minimum buffers requested". The driver will not allow the number of receive buffers in its receive queues to drop below this value. This does not include receive buffers transferred to applications (and not yet returned).

Maximum number of receive buffers as determined by the driver and by management request, "Maximum buffers requested". The driver will deallocate receive buffers until the number allocated does not exceed this maximum. When applications return receive buffers, the number may exceed this maximum, at which point they are deallocated. Note that the driver allows this maximum to be exceeded slightly to limit allocation and deallocation activity. See "Target number of buffers maximum" below.

Current number of receive buffers owned by the driver.

Desired number of receive buffers. As receive activity does not result in lost packets, this number is gradually decreased toward the "Current minimum limit". If packets are lost, this number is dramatically increased toward the "Current maximum limit". When the driver allocates receive buffers, it allocates them until reaching this target number.

Maximum desired number of receive buffers. When an application returns a buffer to the driver, if the current number does not exceed this target maximum, the buffer is kept by the driver. Otherwise, it is deallocated.

To help determine whether the buffering requirements of the driver and the chip are sufficient for the system configuration, the driver records the amount of time from fork scheduled to the time the fork is actually run. The data is recorded in 10-millisecond increments from 10 to 310 milliseconds.

This data can be used in conjunction with the number of packets discarded due to insufficient buffers to determine whether the buffering settings of the driver (minimum and maximum receive buffers) and the amount of buffering on the chip are sufficient for normal operation. If packets are being discarded, the buffering should be increased until the number of packets lost is minimal.

To help understand the operation of the system, driver, and chip, the driver records the time that each transmit buffer is given to the chip. When the transmit completes, the driver calculates the elapsed time, creating a histogram of transmit times from 10 to 310 milliseconds.

Number of packets received with CRC errors that are an integral number of bytes long. These packets are discarded and are counted by the device.

Number of packets received with CRC errors that are not an integral number of bytes long. These packets are discarded and are counted by the device.

Number of symbol errors detected. These occur on fiber NICs only.

Number of packets received with error status.

Number of packets missed because the receive FIFO had insufficient space to store incoming packets, either because too few buffers were provided by the driver or because there was insufficient bandwidth on the PCI bus.

Number of successfully transmitted packets that encountered exactly one collision during transmission (successful after retransmit). These occur in half-duplex mode only.

Number of transmits that failed because of excessive collisions. These occur in half-duplex mode only.

Number of successfully transmitted packets that encountered more than one collision during transmission (successful after multiple retransmits). These occur in half-duplex mode only.

Number of times a collision was detected later than 512 bit-times into the transmission of a packet. The transmit fails. These occur in half-duplex mode only.

Total number of collisions that are not late collisions seen by the transmitter.

Number of successful transmits that were delayed because the medium was busy. These occur in half-duplex mode only.

Number of packet transmissions in which the carrier signal was lost shortly after the start of transmission. These occur in UTP, full-duplex mode only.

Number of sequence errors detected where the frame delimiter symbols were seen in an illegal sequence. These occur on fiber NICs only.

Number of packets received in which a carrier extension error was detected.

Number of packets shorter than 64 bytes or longer than 16 384 bytes.

Number of valid XON packets received.

Number of XON packets transmitted.

Number of valid XOFF packets received.

Number of XOFF packets transmitted.

Number of unsupported flow control frames received.

Number of packets of this size received.

Number of good packets received of any legal length.

Number of good broadcast packets received.

Number of good multicast packets received.

Number of good packets transmitted.

Number of good bytes received.

Number of good bytes transmitted.

Number of packets received where there were no available buffers in host memory. The packets are still received as long a there is sufficient space in the receive FIFO and the driver eventually provides more buffers.

Number of good packets received that were less than 64 bytes in length.

Number of packets received with a CRC error that were less than 64 bytes in length.

Number of good packets received that were larger than the maximum packet size.

Number of packets received with a CRC error that were larger than the maximum packet size.

Number of management packets received.

Number of management packets received but lost because the management receive FIFO was full or the packet was longer than 200 bytes.

Number of management packets sent.

Total number of bytes received, regardless of errors or type of packet.

Total number of bytes transmitted, regardless of errors or type of packet.

Total number of packets received, regardless of errors or type of packet.

Total number of packets transmitted, regardless of errors or type of packet.

Number of packets of this size transmitted.

Number of multicast packets transmitted.

Number of broadcast packets transmitted.

Number of TCP segmentation offload transmissions.

Number of TCP segmentation offload transmissions that failed to transmit all of the data.

Console messages issued by the driver.

Clear the driver counters.

This is useful in debug or test scenarios.

Force all transmit and receive buffers to be described to the chip using map registers.

If enabled, this setting is displayed in the driver flags in the driver internal counters.

Force a non-fatal (soft) error. The chip is stopped and restarted.

Specify a receive or transmit packet trace address for use in driver tracing. If the source or destination address does not match one of the four filter addresses, the packet data is not traced. For example, to filter on addresses AA-00-04-00-EF-4F and AB-00-04-01-D2-01, issue the following LANCP commands:

$ MCR LANCP SET DEVICE EIA/DEVICE_SPECIFIC=(FUNCTION="FIL1",VALUE=(%x000400aa,%x4fef))
$ MCR LANCP SET DEVICE EIA/DEVICE_SPECIFIC=(FUNCTION="FIL2",VALUE=(%x010400ab,%x01d2))

Send the periodic System ID messages immediately instead of waiting until expiry of the 8–12-minute System ID timer.

This is a convenient way to get the driver to send two packets.

Disable the sending of periodic System ID messages.

This is used to disable transmits that may obscure other traffic of interest.

Stop the chip, thereby inducing a transmit timeout on the next transmit request.

Override the default transmit timer. The ticks value is in timer ticks and is limited to the range 2–40. If the fast transmit timer is enabled, each tick is 0.25 seconds; otherwise, it is 1 second.

The current setting is displayed in the driver internal counters.

Wait the specified time (in nanoseconds) at IPL 8 with the driver port lock held.

This is a convenient way to introduce a delay at IPL 8.

Change the interrupt mitigation delay on transmit completion value, the "Transmit interrupt delay (μs)" value. This value is in microseconds, limited to 1000. If zero, the delay is disabled.

Change the interrupt mitigation delay on receive completion value, the "Receive interrupt delay (μs)" value. This value is in microseconds, limited to 1000. If zero, the delay is disabled.

Change the interrupt delay value. The value is in microseconds, limited to 1000. If zero, the delay is disabled.

Disable interrupt mitigation. Note that the Transmit Interrupt Delay Value (TIDV) register is set to the minimum value of 1 (specifications state that it cannot be set to 0).

This is used for performance testing when it is desirable to get an interrupt immediately upon transmit and receive completion.

Disable flow control (if value is zero) or enable flow control (if value is nonzero).

Schedule periodic random resets. The value supplied is AND'ed with (RSCC × 69 069) and, if the result is 3, a reset is done. For example, if the value supplied is 7, a reset is done, on average, every 8 seconds.

A value of 0 disables this function, and a value of n enables it.

This is used to test error handling.

Send the next packet without a valid CRC.

This is used to generate CRC errors for test purposes.

If value is zero, the chip will discard bad received packets. If value is nonzero, the bad packets will be received and discarded by the driver. This allows the packets to be traced and inspected.

IEEE VLAN Mode Enable (VME) bit set/clear. If clear, the VLAN tag will not be stripped from the packet so it can be seen in the receive buffer.

Set receive validation CRC check counter. It can be set from 0 to 0xFFFFFFFFFFFFFFFE. 0xFFFFFFFFFFFFFFFF is used to indicate that the next CRC validation should fail, so we can verify what happens after a failure.

Some devices had a manufacturing issue that the driver detects by enabling CRC validation of the first 50 000 received packets. If a receive packet is declared good by the chip, but the driver CRC validation fails, the device is marked offline and unusable.

This allows the number of CRC validations to be changed.

Restart auto-negotiation.

This is used for link handling testing.

Force a link state change interrupt.

This is used for link handling testing.

If zero, disables link state change interrupts.

If nonzero, enables link state change interrupts.

This is used for link handling testing. Note that whether or not this function is disabled, the driver still does a periodic link state check. As such, it would detect a state change, albeit not immediately.

Name of the XFRAME device.

Compilation timestamp of the driver.

Driver version numbered 1–n that is usually identical to the x-n ID displayed in the ANALYZE/IMAGE command output for the driver image. It includes variant information, if applicable. The full driver version includes the target OpenVMS release and is displayed by the SDA LAN/DEVICE=EWA command in the quadword driver version field.

Number of times the driver interrupt service routine was called.

Number of link transitions seen by the driver.

Number of times the device was reset.

Number of times a user started with no other users initialized (initialization requires more work than if the user is not the first user).

Number of unit initializations executed; since unit initialization is only executed once, this counter will be 1 if map registers were not used to map the device data structures.

Number of unit initializations executed; since unit initialization is only executed once, this counter will be 1 if map registers were used to map the device data structures.

Number of user startup and shutdown requests processed by the driver; this is typically one or two requests when a user starts up and one when a user stops.

Number of times a global page was encountered during a chained transmit request, causing the driver to convert an invalid PTE to a valid PFN.

Number of transmit requests queued because the link was not available or because too many transmit requests were already outstanding.

Number of times the driver has timed out a transmit, reset the device, and completed outstanding I/O with error status.

Number of transmit requests completed with error status (SS$_INCSEGTRA) because the application did not specify the transmit buffer completely.

Number of transmit requests that exceeded the maximum number of chain segments that the driver can handle; the driver then copied some of them to a temporary buffer so that it could transmit the packet.

Number of transmit failures needing a transmit copy, but memory could not be allocated for the transmit buffer.

Number of transmit requests with a packet length exceeding 1514 bytes (excluding CRC).

Number of transmit requests that were described to the device using map registers because part of the request existed in memory outside the DMA window.

Number of jumbo receive buffers allocated and assigned to the device.

Number of receive buffers that were described to the device using map registers because part of the request existed in memory outside the DMA window, because the receive buffer crossed a page boundary, or because the receive buffer was a jumbo buffer.

Number of receive packets discarded by the driver due to receive error. By default, the chip does not deliver damaged receive packets to the driver, but can be asked to do so by a device-specific function.

Number of times that a rescheduled fork was done. In transmit and receive processing, the driver limits the amount of time spent in the fork process before rescheduling.

Number of times errors were recovered in the driver by resetting and reinitializing the device without notifying user applications.

Size of the receive buffers. The device allows packets up to 1518 (or jumbo size) bytes (including header and CRC), plus the VMS receive buffer structure overhead (640 bytes).

This is the Ethernet packet size (1518 or jumbo frame size bytes).

Mapping value for receive frames, the maximum value of BOFF (Buffer Offset) that can result in the need for only two map registers. If BOFF is any larger, the buffer spills into a third page (displayed with the /DEBUG qualifier).

Current link state.

Driver flags including the following bits:

Current driver state, as follows:

• 0 – Driver state is undefined.
• 1 – Driver state is resetting.
• 2 – Driver is running, but the link is down. Completing transmits with error status.
• 4 – Driver is running, and the link is up. Processing transmits and receives.
• 8 – Device is not usable.

Current value of the LAN_FLAGS system parameter.

Miscellaneous fields (displayed with the /DEBUG qualifier; intended for use by driver developers):

Size of the driver structure LAN Station Block (LSB) in bytes (displayed with the /DEBUG qualifier).

Addresses of transmit, receive, and mailbox ring structures for the following (displayed with the /DEBUG qualifier):

These fields provide timer information, the transmit timeout value, the periodic timer frequency, and time stamps for link transitions and errors.

PCI config and Base Address Register (BAR) registers (displayed with the /DEBUG qualifier):

DMA window address information (displayed with the /DEBUG qualifier):

Receive buffer information (displayed with the /DEBUG qualifier):

To help determine whether the buffering requirements of the driver and the device are sufficient for the system configuration, the driver records the amount of time from fork scheduled to the time the fork is actually run. The data is recorded in 10-millisecond increments from 10 to 310 milliseconds.

This data can be used in conjunction with the number of packets discarded due to insufficient buffers to determine whether the buffering settings of the driver (minimum and maximum receive buffers) and the amount of buffering on the device are sufficient for normal operation. If packets are being discarded, the buffering should be increased until the number of packets lost is minimal.

To help understand the operation of the system, driver, and XFRAME, the driver records the time that each transmit buffer is given to the device. When the transmit completes, the driver calculates the elapsed time, creating a histogram of transmit times from 10 to 310 milliseconds.

To help understand the operation of the system, driver, and XFRAME, the driver records the time that each receive buffer is transferred to an application. When the application returns, the driver calculates the elapsed time, creating a histogram of receive completion times from 10 to 150 milliseconds.

Device register contents, either 32 or 64-bits (displayed with the /DEBUG qualifier):

Console messages issued by the driver.

Clear the driver counters.

This is useful in debug or test scenarios.

Force all transmit and receive buffers to be described to the chip using map registers.

If enabled, this setting is displayed in the driver flags in the driver internal counters.

Corrupt a receive or transmit packet. When this function is completed, the protocol type is specified, and if it matches on a transmit or receive packet, the next packet seen is corrupted by changing the last bit in the VCRP or CXB, XORing it with a 1. The protocol type is then cleared so the corruption is not done again. The corruption is only checked when transmit or receive packet data tracing is being done (in the trace routine), so there is no performance hit for checking each packet to verify if it should be corrupted.

The following example shows how to corrupt a PEDRIVER transmit packet:

$ MCR LANCP SET DEVICE/TRACE EWA
$ MCR LANCP SET DEVICE/DEVICE_SPECIFIC=(FUNCTION="XCOR", VALUE=%x760) EWA

If value is zero, the chip will discard bad received packets. If value is nonzero, the bad packets will be received and discarded by the driver. This allows the packets to be traced and inspected.

Disable flow control (if value is zero) or enable flow control (if value is nonzero).

Override the default transmit timer. The ticks value is in timer ticks and is not range checked. If the fast transmit timer is enabled, each tick is 0.25 seconds; otherwise, it is 1 second.

The current setting is displayed in the driver internal counters.

Force a non-fatal (soft) error. The chip is stopped and restarted.

Schedule periodic random resets. The value supplied is AND'ed with (RSCC × 69 069) and, if the result is 3, a reset is done. For example, if the value supplied is 7, a reset is done, on average, every 8 seconds.

A value of 0 disables this function, and a value of n enables it.

This is used to test error handling.

Specify a receive or transmit packet trace address for use in driver tracing. If the source or destination address does not match one of the four filter addresses, the packet data is not traced. For example, to filter on addresses AA-00-04-00-EF-4F and AB-00-04-01-D2-01, issue the following LANCP commands:

$ MCR LANCP SET DEVICE EWA/DEVICE_SPECIFIC=(FUNCTION="FIL1",VALUE=(%x000400aa,%x4fef))
$ MCR LANCP SET DEVICE EWA/DEVICE_SPECIFIC=(FUNCTION="FIL2",VALUE=(%x010400ab,%x01d2))

Change the setting of the driver flag "all messages". If the "all messages" flag is set the driver displays all console messages. The default setting is bit 31 of the LAN_FLAGS system parameter. This function allows the "all messages" setting to be set for an individual device rather than all LAN devices on the system.

If enabled, this setting is displayed in the driver flags in the driver internal counters.

Send the periodic System ID messages immediately instead of waiting until expiry of the 8–12-minute System ID timer.

This is a convenient way to get the driver to send two packets.

Disable the sending of periodic System ID messages.

This is used to disable transmits that may obscure other traffic of interest.

Stop the chip, thereby inducing a transmit timeout on the next transmit request.

Wait the specified time (in nanoseconds) at IPL 8 with the driver port lock held.

This is a convenient way to introduce a delay at IPL 8.

Delay issuing the next transmit request for the time specified in 10-millisecond units. A maximum of 2000 (20 seconds) is allowed.

This function is useful for investigating application behavior when a transmit request is delayed.

If set to 1 (enable), the driver crashes the system with a NETDLLERR Bugcheck if a transmit timeout occurs. If 0 (disable), transmit timeout results in a device reset.

If enabled, this setting is displayed in the driver flags in the driver internal counters.

If set to 1 (enable), the driver crashes the system with a NETDLLERR Bugcheck if a long transmit occurs. If 0 (disable), a long transmit completion is counted.

If enabled, this setting is displayed in the driver flags in the driver internal counters.

If set to 1 (enable), the driver crashes the system with a NETDLLERR Bugcheck if a long fork occurs. If 0 (disable), a long time to run a fork process is recorded in the counters.

If enabled, this setting is displayed in the driver flags in the driver internal counters.

Specify loopvalue to enable (1) or disable (0) loopback mode.

This is useful in test scenarios to run an application in loopback mode, where for standard use the application would not allow selection of loopback mode.

The current setting is displayed in the driver internal counters.

Console messages are displayed by the driver during initialization, auto-negotiation, and link handling. However, the driver limits the total number of messages displayed. This function resets the count, allowing additional messages to be displayed.

Write the device register specified with the value given.

Read the device register specified. The value is returned in the internal counters.

Sets the transmit and receive traffic interrupt values, which are in three ranges (0, 1, 2) where the line rate utilization and the frame count values specify when transmit interrupts should be generated.

If clear (0), do not strip the VLAN tag from the packet, so it can be seen in the receive buffer. If set (1), strip the tag from the packet. The default is 1.

Name of the Broadcom BCM57711 10Gb device.

Compilation timestamp of the driver.

Driver version numbered 1–n that is usually identical to the x-n ID displayed in the ANALYZE/IMAGE command output for the driver image. It includes variant information, if applicable. The full driver version includes the target OpenVMS release and is displayed by the SDA LAN/DEVICE=EWA command in the quadword driver version field.

Number of times the driver interrupt service routine was called.

Number of times the driver interrupt service routine was called when the driver was not running (for example, in the "undefined" state).

Number of times the driver interrupt service routine was called but the interrupt was not valid.

Number of link transitions seen by the driver.

Number of times the device was reset.

Number of times the driver went through its initialization procedure.

Number of user startup and shutdown requests processed by the driver; this is typically one or two requests when a user starts up and one when a user stops.

Number of times a global page was encountered during a chained transmit request, causing the driver to convert an invalid PTE to a valid PFN.

Number of transmit requests queued because the link was not available or because too many transmit requests were already outstanding.

Number of times the driver has timed out a transmit, reset the device, and completed outstanding I/O with error status.

Number of transmit requests completed with error status (SS$_INCSEGTRA) because the application did not specify the transmit buffer completely.

Number of transmit requests that exceeded the maximum number of chain segments that the driver can handle; the driver then copied some of them to a temporary buffer so that it could transmit the packet.

Number of transmit failures needing a transmit copy, but memory could not be allocated for the transmit buffer.

Number of transmit requests with a packet length exceeding 1514 bytes (excluding CRC).

Number of jumbo receive buffers allocated and assigned to the device.

Number of receive packets discarded by the driver due to receive error. By default, the chip does not deliver damaged receive packets to the driver, but can be asked to do so by a device-specific function.

Number of times that a rescheduled fork was done. In transmit and receive processing, the driver limits the amount of time spent in the fork process before rescheduling.

Number of times errors were recovered in the driver by resetting and reinitializing the device without notifying user applications.

Current link state.

Current link state requested.

Driver flags including the following bits:

Current driver state, as follows:

• 0 – Driver state is undefined.
• 1 – Driver state is resetting.
• 2 – Driver is running, but the link is down. Completing transmits with error status.
• 4 – Driver is running, and the link is up. Processing transmits and receives.
• 8 – Device is not usable.

Current value of the LAN_FLAGS system parameter.

Miscellaneous fields (many of which are displayed with the /DEBUG qualifier):

These fields provide timer information, the transmit timeout value, the periodic timer frequency, and time stamps for link transitions and errors.

PCI config and BAR registers (displayed with the /DEBUG qualifier):

DMA window address information (displayed with the /DEBUG qualifier):

Receive buffer information:

To help determine whether the buffering requirements of the driver and the BCM57711 chip are sufficient for the system configuration, the driver records the amount of time from fork scheduled to the time the fork is actually run. The data is recorded in 10-millisecond increments from 10 to 310 milliseconds.

This data can be used in conjunction with the number of packets discarded due to insufficient buffers to determine whether the buffering settings of the driver (minimum and maximum receive buffers) and the amount of buffering on the BCM57711 chip are sufficient for normal operation. If packets are being discarded, the buffering should be increased until the number of packets lost is minimal.

To help understand the operation of the system, driver, and BCM57711 chip, the driver records the time that each transmit buffer is given to the device. When the transmit completes, the driver calculates the elapsed time, creating a histogram of transmit times from 10 to 310 milliseconds.

To help understand the operation of the system, driver, and BCM57711 chip, the driver records the time that each receive buffer is transferred to an application. When the application returns, the driver calculates the elapsed time, creating a histogram of receive completion times from 10 to 150 milliseconds.

Console messages issued by the driver.

Clear the driver counters.

This is useful in debug or test scenarios.

Force a non-fatal (soft) error. The chip is stopped and restarted.

Specify a receive or transmit packet trace address for use in driver tracing. If the source or destination address does not match one of the four filter addresses, the packet data is not traced. For example, to filter on addresses AA-00-04-00-EF-4F and AB-00-04-01-D2-01, issue the following LANCP commands:

$ MCR LANCP SET DEVICE EBA/DEVICE_SPECIFIC=(FUNCTION="FIL1",VALUE=(%x000400aa,%x4fef))
$ MCR LANCP SET DEVICE EBA/DEVICE_SPECIFIC=(FUNCTION="FIL2",VALUE=(%x010400ab,%x01d2))

Send the periodic System ID messages immediately instead of waiting until expiry of the 8–12-minute System ID timer.

This is a convenient way to get the driver to send two packets.

Disable the sending of periodic System ID messages.

This is used to disable transmits that may obscure other traffic of interest.

Wait the specified time (in nanoseconds) at IPL 8 with the driver port lock held.

This is a convenient way to introduce a delay at IPL 8.

If set to 1 (enable), the driver crashes the system with a NETDLLERR Bugcheck if a transmit timeout occurs. If 0 (disable), transmit timeout results in a device reset.

If enabled, this setting is displayed in the driver flags in the driver internal counters.

If set to 1 (enable), the driver crashes the system with a NETDLLERR Bugcheck if a long transmit occurs. If 0 (disable), a long transmit completion is counted.

If enabled, this setting is displayed in the driver flags in the driver internal counters.

If set to 1 (enable), the driver crashes the system with a NETDLLERR Bugcheck if a long fork occurs. If 0 (disable), a long time to run a fork process is recorded in the counters.

If enabled, this setting is displayed in the driver flags in the driver internal counters.

Schedule periodic random resets. The value supplied is AND'ed with (RSCC × 69 069) and, if the result is 3, a reset is done. For example, if the value supplied is 7, a reset is done, on average, every 8 seconds.

A value of 0 disables this function, and a value of n enables it.

This is used to test error handling.

Console messages are displayed by the driver during initialization, auto-negotiation, and link handling. However, the driver limits the total number of messages displayed. This function resets the count, allowing additional messages to be displayed.

Override the default transmit timer. The ticks value is in timer ticks and is not range checked. If the fast transmit timer is enabled, each tick is 0.25 seconds; otherwise, it is 1 second.

The current setting is displayed in the driver internal counters.

Delay issuing the next transmit request for the time specified in 10-millisecond units. A maximum of 2000 (20 seconds) is allowed.

This function is useful for investigating application behavior when a transmit request is delayed.

Name of the Emulex 10Gb device.

Full name of the device returned by the device firmware.

Compilation timestamp of the driver.

Driver version numbered 1–n that is usually identical to the x-n ID displayed in the ANALYZE/IMAGE command output for the driver image. It includes variant information, if applicable. The full driver version includes the target OpenVMS release and is displayed by the SDA LAN/DEVICE=EBA command in the quadword driver version field.

Number of times the driver interrupt service routine was called.

Number of times the driver interrupt service routine was called when the driver was not running (for example, in the "undefined" state).

Number of link transitions seen by the driver.

Number of times the device was reset.

Number of times a global page was encountered during a chained transmit request, causing the driver to convert an invalid PTE to a valid PFN.

Number of transmit requests queued because the link was not available or because too many transmit requests were already outstanding.

Number of times the driver has timed out a transmit, reset the device, and completed outstanding I/O with error status.

Number of transmit requests completed with error status (SS$_INCSEGTRA) because the application did not specify the transmit buffer completely.

Number of transmit requests that exceeded the maximum number of chain segments that the driver can handle; the driver then copied some of them to a temporary buffer so that it could transmit the packet.

Number of transmit failures needing a transmit copy, but memory could not be allocated for the transmit buffer.

Number of transmit requests with a packet length exceeding 1514 bytes (excluding CRC).

Number of TCP transmit requests specifying checksum offload (CKO).

Number of UDP transmit requests specifying CKO.

Number of IP transmit requests specifying CKO.

Number of TCP transmit requests specifying TCP segmentation offload (TSO).

Number of jumbo receive buffers allocated and assigned to the device.

Number of receive packets discarded by the driver due to receive error. By default, the chip does not deliver damaged receive packets to the driver, but can be asked to do so by a device-specific function.

Number of receive packets processed using hardware validated checksums.

Number of receive packets processed using driver large receive offload (LRO) functionality, transferred to a user concatenated to reduce protocol overhead.

Number of times that a rescheduled fork was done. In transmit and receive processing, the driver limits the amount of time spent in the fork process before rescheduling.

Number of user startup and shutdown requests processed by the driver; this is typically one or two requests when a user starts up and one when a user stops.

Number of times errors were recovered in the driver by resetting and reinitializing the device without notifying user applications.

Transmit interrupts are generated every n "coalesce value" transmit completions, but no later than n "interrupt delay" microseconds after transmit completion.

Receive interrupts are generated every n "coalesce value" receive completions, but no more than n "interrupt delay" microseconds after receipt of a packet.

Current link state.

Current link state requested.

Driver flags including the following bits:

Current driver state, as follows:

• 0 – Driver state is undefined.
• 1 – Driver state is resetting.
• 2 – Driver is running, but the link is down. Completing transmits with error status.
• 4 – Driver is running, and the link is up. Processing transmits and receives.
• 8 – Device is not usable.

Current value of the LAN_FLAGS system parameter.

Port number for this device; can be 0 or 1.

Function number for this device; can be 0, 1, 2, or 3 depending on device configuration.

Size of the driver structure LSB in bytes.

These fields provide timer information, the transmit timeout value, the periodic timer frequency, and time stamps for link transitions and errors.

Addresses of transmit, receive, and mailbox ring structures for the following (displayed with the /DEBUG qualifier):

PCI config and BAR registers (displayed with the /DEBUG qualifier):

DMA window address information (displayed with the /DEBUG qualifier):

Receive buffer information:

To help determine whether the buffering requirements of the driver and the BE3 chip are sufficient for the system configuration, the driver records the amount of time from fork scheduled to the time the fork is actually run. The data is recorded in 10-millisecond increments from 10 to 310 milliseconds.

This data can be used in conjunction with the number of packets discarded due to insufficient buffers to determine whether the buffering settings of the driver (minimum and maximum receive buffers) and the amount of buffering on the BE3 chip are sufficient for normal operation. If packets are being discarded, the buffering should be increased until the number of packets lost is minimal.

To help understand the operation of the system, driver, and BE3 chip, the driver records the time that each transmit buffer is given to the device. When the transmit completes, the driver calculates the elapsed time, creating a histogram of transmit times from 10 to 310 milliseconds.

To help understand the operation of the system, driver, and BE3 chip, the driver records the time that each receive buffer is transferred to an application. When the application returns, the driver calculates the elapsed time, creating a histogram of receive completion times from 10 to 150 milliseconds.

Device firmware is initiated at power up and reset, getting to a firmware state where it is ready to accept commands. Commands are written to a device mailbox called the BMBX (boot mailbox) and other structures such as the CQ (Command Queue), CQE (Command Queue Entry), MQ (Mailbox Queue), and MQE (Mailbox Queue Entry).

These counters record the firmware version and timing of firmware ready and BMBX usage information. Some of these counters are only displayed if the /DEBUG qualifier is included.

These fields give more link information (some fields displayed with the /DEBUG qualifier):

Counters for port 0, 1 of this device.

A number of statistics include errors detected by the device.

The QnQ issue is similar to UERR, but it is a hardware condition rather than a firmware-detected fault. The effect is the same. When device firmware supports a driver workaround, the driver can avoid the failure condition by detecting the condition and specifying the transmit request in such a way that the firmware recognizes the condition and can work around it.

Unrecoverable error (UERR) is a fatal firmware condition, where the firmware encounters an error that it cannot proceed from. When a UERR occurs, the firmware stops and cannot be restarted. The UERR status registers (lo and hi) provide more detail. The UERR mask register indicates which UERR status bits are valid.

Boot Mailbox (BMBX) commands are issued in three steps; pre-command (Part 1), write high address (Part 2), and write low address (Part 3). This statistics track the timing for each part.

This table lists each command that can be issued to the device, the number of commands issued, and timing information for each (displayed with the /DEBUG qualifier):

Console messages issued by the driver.

Clear the driver counters.

This is useful in debug or test scenarios.

Force a non-fatal (soft) error. The chip is stopped and restarted.

Specify a receive or transmit packet trace address for use in driver tracing. If the source or destination address does not match one of the four filter addresses, the packet data is not traced. For example, to filter on addresses AA-00-04-00-EF-4F and AB-00-04-01-D2-01, issue the following LANCP commands:

$ MCR LANCP SET DEVICE EBA/DEVICE_SPECIFIC=(FUNCTION="FIL1",VALUE=(%x000400aa,%x4fef))
$ MCR LANCP SET DEVICE EBA/DEVICE_SPECIFIC=(FUNCTION="FIL2",VALUE=(%x010400ab,%x01d2))

Send the periodic System ID messages immediately instead of waiting until expiry of the 8–12-minute System ID timer.

This is a convenient way to get the driver to send two packets.

Disable the sending of periodic System ID messages.

This is used to disable transmits that may obscure other traffic of interest.

Wait the specified time (in nanoseconds) at IPL 8 with the driver port lock held.

This is a convenient way to introduce a delay at IPL 8.

If set to 1 (enable), the driver crashes the system with a NETDLLERR Bugcheck if a transmit timeout occurs. If 0 (disable), transmit timeout results in a device reset.

If enabled, this setting is displayed in the driver flags in the driver internal counters.

If set to 1 (enable), the driver crashes the system with a NETDLLERR Bugcheck if a long transmit occurs. If 0 (disable), a long transmit completion is counted.

If enabled, this setting is displayed in the driver flags in the driver internal counters.

If set to 1 (enable), the driver crashes the system with a NETDLLERR Bugcheck if a long fork occurs. If 0 (disable), a long time to run a fork process is recorded in the counters.

If enabled, this setting is displayed in the driver flags in the driver internal counters.

Schedule periodic random resets. The value supplied is AND'ed with (RSCC × 69 069) and, if the result is 3, a reset is done. For example, if the value supplied is 7, a reset is done, on average, every 8 seconds.

A value of 0 disables this function, and a value of n enables it.

This is used to test error handling.

Console messages are displayed by the driver during initialization, auto-negotiation, and link handling. However, the driver limits the total number of messages displayed. This function resets the count, allowing additional messages to be displayed.

Sets flow control according to the value:

• 0 – Disable flow control.
• 1 – Enable flow control.
• 2 – Force receive flow control only.
• 3 – Force transmit flow control only.

Override the default transmit timer. The ticks value is in timer ticks and is not range checked. If the fast transmit timer is enabled, each tick is 0.25 seconds; otherwise, it is 1 second.

The current setting is displayed in the driver internal counters.

Force a transmit timeout on the next transmit.

Delay issuing the next transmit request for the time specified in 10-millisecond units. A maximum of 2000 (20 seconds) is allowed.

This function is useful for investigating application behavior when a transmit request is delayed.

Change the interrupt mitigation delay on transmit completion, the "Transmit coalesce value (μs)" value. This allowed range is 0 to 1000000 microseconds. If zero, the delay is set to the default of 20 microseconds.

Change the interrupt mitigation delay on receive completion, the "Receive coalesce value (μs)" value. This allowed range is 0 to 1000000 microseconds. If zero, the delay is set to the default of 32 microseconds.

Corrupt a byte in a transmit packet (increment it by 1).

This can be used to lose packets by selecting a byte in the destination address (0–5) to validate handling of lost packets for a protocol.

This can be used to validate IP checksums by corrupting the packet data protected by the checksum after the network stack has calculated the checksum.

If set to 1 (enable), the driver issues every transmit with the QnQ driver workaround, where the driver creates an additional transmit segment for the VLAN tag with special transmit descriptor bits set.

If set to 0 (disable), the driver only does the QnQ workaround if the transmit request requires it.

This is used to validate the QnQ workaround driver support.

If set to 1 (enable), enables the QnQ workaround in the driver.

If set to 0 (disable), disables the QnQ workaround.

By disabling the workaround and issuing a particular transmit request, the BE3 chip locks up. This helps validate the QnQ workaround support, by verifying the problem packet really does cause a lockup, and then verifying the QnQ workaround actually does prevent the lockup.