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.

Number of times the driver interrupt service routine was called.

Number of link transitions seen by the driver.

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

Number of times the driver checked the current link status.

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

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

Number of VMS Communications Interface (VCI) user port events reported.

Number of times the device was reset.

PCI BAR0 Control and Status Register (CSR) base address.

Number of unit initializations executed; since unit initialization is only executed once, this counter will be 1.

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 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 timeouts averted by a final check for transmit completion.

Number of chained transmits where the chaining is via system virtual address (SVA) buffer address.

Number of chained transmits where the chaining is via a SVAPTE_SVA-style buffer.

Number of chained transmits where the chaining is via an I/O Buffer Descriptor (IOBD)/Extent-style buffer.

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

Number of transmit chain segments which specified a zero-byte length segment.

Number of transmit requests that exceeded the maximum number of chain segments 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 caused by too few chain segments when coalescing a request to reduce the number of segments needed.

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

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

Number of receives (jumbo packets) completed by the driver that span multiple receive buffers.

Number of receive packets discarded by the driver due to a receive error. By default, the chip does not deliver damaged receive packets to the driver, but it can be instructed to do so with 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 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 Physical Layer (PHY) register.

Ethernet packet size (1518 bytes).

Jumbo packet size (9018 bytes).

Speed and duplex mode requested by a user.

Current link state.

Driver flags.

Current driver state, as follows:

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

Current value of the LAN_FLAGS system parameter.

Amount of the chip packet buffer allocated to transmit buffers vs receive, initial value.

Amount of the chip packet buffer allocated to transmit buffers vs receive, current value.

Minimum delay between interrupts, in units of 256 nanoseconds.

Amount of delay (in microseconds) after transmit completion that an interrupt is generated.

Amount of delay (in microseconds) after receive completion that an interrupt is generated.

System virtual address (VA) of the start of the receive rings.

System VA of the start of the transmit rings.

Total size of the LAN Station Block (LSB) structure.

Unknown, IOSAPIC, MSI, MSI-X, or IOAPIC.

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 state change interrupt was fielded.

Previous time a link state change interrupt was fielded.

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.

History of the last 15 link uptimes, displaying the length of each uptime period.

Time of the last transmit timeout.

Time last averted a transmit timeout.

Time of the last soft error.

Time of the last Cyclic Redundancy Check (CRC) error.

Time of the last receive error.

First 24 bytes of the last packet received with error status.

Time of the last unrecognized unicast packet received.

First 24 bytes of the last unicast packet received that was discarded because receive address filtering did not result in a matching user.

Time of the last unrecognized multicast packet received.

First 24 bytes of the last multicast packet received that was discarded because receive address filtering did not result in a matching user.

Consists of a list of the contents-significant chip registers.

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 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 device, 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 and driver, the driver records the time taken to process each receive buffer. When the receive completes, the driver records the time that processing started. Then it delivers the packet to the user application. When the user returns it, the driver calculates this completion time, creating a histogram of receive times from 10 to 150 milliseconds.

The driver maintains a one-second timer (that runs four times a second). It expects the timer routine to be called close to the timer interval. By looking at the time difference between when a timer is expected to be called and when it actually is called, it is possible to understand the operation of the system and driver. The variance time is used to create a histogram of receive times from 10 to 150 milliseconds.

These are the statistics kept by the device.

Console messages issued by the driver.

Corrupt a transmit or receive packet. When this function is executed, the protocol type is specified; 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 that the corruption is not done again.

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

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

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

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

Lose some packets by corrupting the header of the packet. Corrupt packet 0xaabbccdd, where aa is seconds to corrupt, bb is number to corrupt, cc is byte number 0–255, and dd is what to corrupt with.

For example, to send 32 transmit packets elsewhere (no more than 16 seconds), change the last byte of the destination address to 0x44. For example:

$ MCR LANCP SET DEVICE/TRACE=(MASK=XMTISSUE) EIA
$ MCR LANCP SET DEVICE/DEVICE_SPECIFIC=(FUNCTION="LOSE", VALUE=%x10200544) EIA

To lose just one packet, change the first byte of the packet to 0x00. For example:

$ MCR LANCP SET DEVICE/TRACE=(MASK=XMTISSUE) EIA
$ MCR LANCP SET DEVICE/DEVICE_SPECIFIC=FUNCTION="LOSE" EIA

To lose 255 packets for the rest of the 10-millisecond tick, change the first byte of the packet to 0x00. For example:

$ MCR LANCP SET DEVICE/TRACE=(MASK=XMTISSUE) EIA
$ MCR LANCP SET DEVICE/DEVICE_SPECIFIC=(FUNCTION="LOSE",VALUE=%xFF0000) EIA

Force transmit chaining coalescing to exercise this rarely-used code path.

Enable (1) or disable (0) this function.

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.

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 flow control (if the value is zero) or enable flow control (if the value is nonzero).

Enable (1) or disable (0) force promiscuous mode, then reset the device.

Enable (1) or disable (0) auto-promiscuous mode, then reset the device.

Auto-promiscuous mode means the driver will enable promiscuous mode if it needs to according to the hypervisor in use. Enabling promiscuous mode may be needed if the Media Access Control (MAC) address is changed from the default power on address.

Force a non-fatal (soft) error. The device is restarted.

Force a simulated hardware failure by clearing the receive return descriptor ring.

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 every 8 seconds on average.

A value of zero disables this function, and a nonzero value 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 the value is zero, the chip will discard bad received packets. If the value is nonzero, the bad packets will be received and discarded by the driver. This allows the packets to be traced and inspected.

Write a value val to CSR address.

Read a CSR address and print the result.

Write a value val to PHY address.

Enable (1) or disable (0) all messages flag.

Force link indication. If the value is 0 (disabled), do not force the link state.

If the value is 1, force the link to be up.

If the value is 2, force the link to be down.

Enable (1) or disable (0) Bugcheck on transmit timeout.

Enable (1) or disable (0) Bugcheck on long transmit completion.

Enable (1) or disable (0) Bugcheck on long fork.

Enable (1) or disable (0) Bugcheck on long second.

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

Set the transmit timeout value in the range 2 to 10000. The actual timeout will be (setting − 1) × 250 milliseconds.

Disable transmit timeout averting if setting is 4747.

Set to 4747 to avoid trying to avert a transmit timeout. Setting XTMO to 1 artificially causes many transmit timeouts, which exercises the transmit timeout handling. If not set to 4747, the transmit would have been found to have completed and the timeout would be counted as an "averted" transmit timeout.

Reset number of OPCOM messages.

Send the periodic System ID messages now 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 might distract from other traffic you are looking at.

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.

The timevalue is 32 bits, limiting the wait to 4 seconds.

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.

Restart auto-negotiation.

This is used for link handling testing.

Force a link state change interrupt.

Delay the next transmit by n 10-millisecond ticks.

Call INI$BRK.

Measure statistics time, view result in internal counters "Soft errors".

Name of the VirtIO 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.

VirtIO features offered by the device.

VirtIO features offered by the driver.

VirtIO features offered by the device and accepted by the driver.

Last device status read/written.

Time driver reported operational status to the device.

Time device reported that it needs to be reset.

Time device status was last reset.

Number of times the driver interrupt service routine was called.

Number of link transitions seen by the driver.

Number of times the driver checked the current link status.

Number of VCI user port events reported.

Number of times the device was reset.

Number of unit initializations executed; since unit initialization is only executed once, this counter will be 1.

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 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 timeouts averted by a final check for transmit completion.

Number of chained transmits where the chaining is via SVA buffer address.

Number of chained transmits where the chaining is via a SVAPTE_SVA-style buffer.

Number of chained transmits where the chaining is via an IOBD/Extent-style buffer.

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

Number of transmit chain segments which specified a zero-byte length segment.

Number of transmit requests that exceeded the maximum number of chain segments 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 caused by too few chain segments when coalescing a request to reduce the number of segments needed.

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

Number of jumbo packets received.

Number of receives (jumbo packets) completed by the driver that span multiple receive buffers.

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

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.

Ethernet packet size (1518 bytes).

Jumbo packet size (9018 bytes).

Receive filtering commands issued to the device.

Set MAC address commands issued to the device.

Multicast filtering commands issued to the device.

Speed and duplex mode requested by a user.

Current link state.

Driver flags.

Current driver state, as follows:

• 0 – Driver state is undefined.
• 1 – Driver is running, but the link is down. Completing transmits with error status.
• 2 – Driver is running, but the link is down. Queuing transmits for now.
• 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.

Total size of the LSB structure.

Unknown, IOSAPIC, MSI, MSI-X, or IOAPIC.

Physical address (PA) and virtual address (VA), size, and notification offset of the driver ring structures.

PCI capability values

Configuration structure VAs.

Configuration buffer VAs.

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 state change interrupt was fielded.

Previous time a link state change interrupt was fielded.

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.

History of the last 15 link uptimes, displaying the length of each uptime period.

Time of the last transmit timeout.

Time last averted a transmit timeout.

Time of the last soft error.

Time of the last unrecognized unicast packet received.

First 24 bytes of the last unicast packet received that was discarded because receive address filtering did not result in a matching user.

Time of the last unrecognized multicast packet received.

First 24 bytes of the last multicast packet received that was discarded because receive address filtering did not result in a matching user.

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 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 device, 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 and driver, the driver records the time taken to process each receive buffer. When the receive completes, the driver records the time that processing started. Then it delivers the packet to the user application. When the user returns it, the driver calculates this completion time, creating a histogram of receive times from 10 to 150 milliseconds.

The driver maintains a one-second timer (that runs four times a second). It expects the timer routine to be called close to the timer interval. By looking at the time difference between when a timer is expected to be called and when it actually is called, it is possible to understand the operation of the system and driver. The variance time is used to create a histogram of receive times from 10 to 150 milliseconds.

Console messages issued by the driver.

Corrupt a transmit or receive packet. When this function is executed, the protocol type is specified; 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 that the corruption is not done again.

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

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

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

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

Lose some packets by corrupting the header of the packet. Corrupt packet 0xaabbccdd, where aa is seconds to corrupt, bb is number to corrupt, cc is byte number 0–255, and dd is what to corrupt with.

For example, to send 32 transmit packets elsewhere (no more than 16 seconds), change the last byte of the destination address to 0x44. For example:

$ MCR LANCP SET DEVICE/TRACE=(MASK=XMTISSUE) EIA
$ MCR LANCP SET DEVICE/DEVICE_SPECIFIC=(FUNCTION="LOSE", VALUE=%x10200544) EIA

To lose just one packet, change the first byte of the packet to 0x00. For example:

$ MCR LANCP SET DEVICE/TRACE=(MASK=XMTISSUE) EIA
$ MCR LANCP SET DEVICE/DEVICE_SPECIFIC=FUNCTION="LOSE" EIA

To lose 255 packets for the rest of the 10-millisecond tick, change the first byte of the packet to 0x00. For example:

$ MCR LANCP SET DEVICE/TRACE=(MASK=XMTISSUE) EIA
$ MCR LANCP SET DEVICE/DEVICE_SPECIFIC=(FUNCTION="LOSE",VALUE=%xFF0000) EIA

Force transmit chaining coalescing to exercise this rarely-used code path.

Enable (1) or disable (0) this function.

Enable (1) or disable (0) force promiscuous mode, then reset the device.

Allow (1) or disallow (0) transmit interrupt coalescing.

Force a non-fatal (soft) error. The device is 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 every 8 seconds on average.

A value of zero disables this function, and a nonzero value enables it.

This is used to test error handling.

Enable (1) or disable (0) all messages flag.

Force link indication. If the value is 0 (disabled), do not force the link state.

If the value is 1, force the link to be up.

If the value is 2, force the link to be down.

Enable (1) or disable (0) Bugcheck on transmit timeout.

Enable (1) or disable (0) Bugcheck on long transmit completion.

Enable (1) or disable (0) Bugcheck on long fork.

Enable (1) or disable (0) Bugcheck on long second.

Set the transmit timeout value in the range 2 to 10000. The actual timeout will be (setting − 1) × 250 milliseconds.

Disable transmit timeout averting if setting is 4747.

Set to 4747 to avoid trying to avert a transmit timeout. Setting XTMO to 1 artificially causes many transmit timeouts, which exercises the transmit timeout handling. If not set to 4747, the transmit would have been found to have completed and the timeout would be counted as an "averted" transmit timeout.

Reset number of OPCOM messages.

Send the periodic System ID messages now 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 might distract from other traffic you are looking at.

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.

The timevalue is 32 bits, limiting the wait to 4 seconds.

Delay the next transmit by n 10-millisecond ticks.

Call INI$BRK.

Display queue data on the console.

Name of the VMXNET3 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.

As reported by the device.

Number of times the driver interrupt service routine was called.

Number of link transitions seen by the driver.

Number of times the driver checked the current link status.

Number of VCI user port events reported.

Number of times the device was reset.

Values of the PCI Configuration Space Base Address Registers (BAR).

Number of unit initializations executed; since unit initialization is only executed once, this counter will be 1.

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 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 timeouts averted by a final check for transmit completion.

Number of chained transmits where the chaining is via SVA buffer address.

Number of chained transmits where the chaining is via a SVAPTE_SVA-style buffer.

Number of chained transmits where the chaining is via an IOBD/Extent-style buffer.

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

Number of transmit chain segments which specified a zero-byte length segment.

Number of transmit requests that exceeded the maximum number of chain segments 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 caused by too few chain segments when coalescing a request to reduce the number of segments needed.

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

Number of jumbo packets received.

Number of receives (jumbo packets) completed by the driver that span multiple receive buffers.

Number of received segments marked as unwanted.

Number of times receive index was out of sync.

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

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.

Ethernet packet size (1518 bytes).

Jumbo packet size (9018 bytes).

Speed and duplex mode requested by a user.

Current link state.

Driver flags.

Current driver state, as follows:

• 0 – Driver state is undefined.
• 1 – Driver is running, but the link is down. Completing transmits with error status.
• 2 – Driver is running, but the link is down. Queuing transmits for now.
• 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.

Total size of the LSB structure.

Shared structure context.

Unknown, IOSAPIC, MSI, MSI-X, or IOAPIC.

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 state change interrupt was fielded.

Previous time a link state change interrupt was fielded.

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.

History of the last 15 link uptimes, displaying the length of each uptime period.

Time of the last transmit timeout.

Time last averted a transmit timeout.

Time of the last soft error.

Time of the last CRC error.

First 24 bytes of the last packet with a receive error.

Time of the last unrecognized unicast packet received.

First 24 bytes of the last unicast packet received that was discarded because receive address filtering did not result in a matching user.

Time of the last unrecognized multicast packet received.

First 24 bytes of the last multicast packet received that was discarded because receive address filtering did not result in a matching user.

List of device registers and the value last read or written.

List of PCI Configuration Space registers and the values 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 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 device, 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 and driver, the driver records the time taken to process each receive buffer. When the receive completes, the driver records the time that processing started. Then it delivers the packet to the user application. When the user returns it, the driver calculates this completion time, creating a histogram of receive times from 10 to 150 milliseconds.

The driver maintains a one-second timer (that runs four times a second). It expects the timer routine to be called close to the timer interval. By looking at the time difference between when a timer is expected to be called and when it actually is called, it is possible to understand the operation of the system and driver. The variance time is used to create a histogram of receive times from 10 to 150 milliseconds.

Console messages issued by the driver.

Corrupt a transmit or receive packet. When this function is executed, the protocol type is specified; 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 that the corruption is not done again.

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

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

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

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

Lose some packets by corrupting the header of the packet. Corrupt packet 0xaabbccdd, where aa is seconds to corrupt, bb is number to corrupt, cc is byte number 0–255, and dd is what to corrupt with.

For example, to send 32 transmit packets elsewhere (no more than 16 seconds), change the last byte of the destination address to 0x44. For example:

$ MCR LANCP SET DEVICE/TRACE=(MASK=XMTISSUE) EIA
$ MCR LANCP SET DEVICE/DEVICE_SPECIFIC=(FUNCTION="LOSE", VALUE=%x10200544) EIA

To lose just one packet, change the first byte of the packet to 0x00. For example:

$ MCR LANCP SET DEVICE/TRACE=(MASK=XMTISSUE) EIA
$ MCR LANCP SET DEVICE/DEVICE_SPECIFIC=FUNCTION="LOSE" EIA

To lose 255 packets for the rest of the 10-millisecond tick, change the first byte of the packet to 0x00. For example:

$ MCR LANCP SET DEVICE/TRACE=(MASK=XMTISSUE) EIA
$ MCR LANCP SET DEVICE/DEVICE_SPECIFIC=(FUNCTION="LOSE",VALUE=%xFF0000) EIA

Force transmit chaining coalescing to exercise this rarely-used code path.

Enable (1) or disable (0) this function.

Enable (1) or disable (0) force promiscuous mode, then reset the device.

Force a non-fatal (soft) error. The device is 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 every 8 seconds on average.

A value of zero disables this function, and a nonzero value enables it.

This is used to test error handling.

Enable (1) or disable (0) all messages flag.

Force link indication. If the value is 0 (disabled), do not force the link state.

If the value is 1, force the link to be up.

If the value is 2, force the link to be down.

Enable (1) or disable (0) Bugcheck on transmit timeout.

Enable (1) or disable (0) Bugcheck on long transmit completion.

Enable (1) or disable (0) Bugcheck on long fork.

Enable (1) or disable (0) Bugcheck on long second.

Set the transmit timeout value in the range 2 to 10000. The actual timeout will be (setting − 1) × 250 milliseconds.

Disable transmit timeout averting if setting is 4747.

Set to 4747 to avoid trying to avert a transmit timeout. Setting XTMO to 1 artificially causes many transmit timeouts, which exercises the transmit timeout handling. If not set to 4747, the transmit would have been found to have completed and the timeout would be counted as an "averted" transmit timeout.

Reset number of OPCOM messages.

Send the periodic System ID messages now 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 might distract from other traffic you are looking at.

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.

The timevalue is 32 bits, limiting the wait to 4 seconds.

Delay the next transmit by n 10-millisecond ticks.

Call INI$BRK.

Display device registers on the console.

Update queue status from the device.

Display the BAR registers on the console.