Using CP Query Virtual OSA

CP Query Virtual OSA

If you are dealing with a QDIO interface that is functional (so you trust that it is configured properly), but then loses connectivity or slows down for unexplained reasons, the CP Query for virtual OSA devices may help. This information may help whether the virtual OSA represents a dedicated real OSA interface or a virtual NIC coupled to a Guest LAN.

Issue this command from the VM user who owns the virtual device. Since that user is probably running VM TCP/IP, Linux, z/OS, or z/VM you should use "#CP" to issue an immediate command without disrupting the existing activity.

Example:

#cp q v osa
OSA  4400 ON OSA   2804 SUBCHANNEL = 0005
     4400 QDIO-ELIGIBLE       QIOASSIST NOT AVAILABLE
OSA  4401 ON OSA   2805 SUBCHANNEL = 0006
     4401 QDIO-ELIGIBLE       QIOASSIST NOT AVAILABLE
OSA  4402 ON OSA   2806 SUBCHANNEL = 0007
     4402 QDIO ACTIVE         QIOASSIST NOT AVAILABLE
     4402 INP + 01 IOCNT = 00002724  ADP = 092 PROG = 000 UNAVAIL = 036
     4402 OUT + 01 IOCNT = 00000000  ADP = 000 PROG = 000 UNAVAIL = 128
     4402 OUT + 02 IOCNT = 00000000  ADP = 000 PROG = 000 UNAVAIL = 128
     4402 OUT + 03 IOCNT = 00004700  ADP = 000 PROG = 128 UNAVAIL = 000
     4402 OUT + 04 IOCNT = 00000000  ADP = 000 PROG = 000 UNAVAIL = 128

The text "4400 ON OSA 2804" indicates that this is a dedicated OSA interface. If this had been a virtual NIC it would have been "4400 ON NIC 4400" for each device on that simulated adapter.

Virtual device 4402 (real device 2806) is the active data device. We know this because the output includes the line "QDIO ACTIVE" and a summary line is included to describe each queue associated with this device. We can see one input queue (INP) and four output queues (OUT).

Note that the device driver seems to be using the input queue (2724 buffers processed) and output queue 3 (4700 buffers processed). This is typical for the Linux qeth device driver using the OSA Express in QDIO mode.

Since this is a dedicated OSA device and CP is responsible for translating between real and virtual queues, the flag before the queue number is significant. Normally the plus sign (+) is displayed, indicating that the queues are in sync between real and virtual queue states. If, for example, output queue 3 had been displayed with "OUT - 03" instead of "OUT + 03" it would indicate that the real and virtual queue structures are out-of-sync. This flag is not set for VM TCP/IP devices because they use Diagnose x'98' and it is not set for virtual NIC devices because there is no "real" queue structure for comparison. Note that a Linux user may issue "hcp q v osa" to collect this information, and if they do it is VERY likely that they will see an out-of-sync indicator on the output queue for the telnet session because the counters are compared while output is being processed.

The input queue shows normal status. There are 92 buffers in ADP state (adapter owned) and NO buffers in PRG state (program owned). The buffers in adapter state are waiting for input from the adapter. It would be unusual to see buffers in PRG state (program owned). That would imply that:
(a) the adapter failed to alert the virtual machine about these input buffers, or
(b) the device driver failed to read the input buffers, or
(c) the device driver failed to return these buffers to uninitialized state.

The output queue indicates a potential problem. There are NO buffers in ADP state (adapter owned) but 128 buffers in PRG state (program owned). It would be unusual to see buffers in ADP state (adapter owned). Output buffers consistently in ADP state would imply that:
(a) the device driver failed to signal the adapter to process these buffers, or
(b) the adapter failed to process these buffers.
Output buffers consistently in PRG state would imply that the device driver is not performing "cleanup" for buffers that have been successfully sent to the adapter. If this response had indicated that 128 buffers had been processed (instead of 4700) I would have suspected that the driver failed to cleanup output buffers and was unable to continue. However, this interface is still operating properly so I assume this is an older device driver that does not cleanup output buffers until it needs the slot for new output.

This document is written and maintained by:

Dennis Musselwhite
VM/ESA CP Connectivity Development
musselwh@us.ibm.com

The information provided, and views expressed on this site are my own and do not represent the IBM Corporation.