Debugging a vdev

You can use the same techniques to debug a vdev as you use to debug other code in the QNX Neutrino OS.

Reporting the vdev status

The VDEV_CTRL_STATUS callback is invoked when a SIGUSR2 signal is sent to a qvm process instance. If you want your vdev to output information about its status, you can use this callback and the qvm_report() function. The following snippet is from the ser8250 vdev's vd8250_control() function:

case VDEV_CTRL_STATUS:
    qvm_report("dlr=0x%x lcr=0x%x ier=0x%x mcr=0x%x", \
    state->s_dlr, state->s_lcr, state->s_ier, state->s_mcr);
    break;

For more information, see “A guest-host hardware device intermediary (vdev ser8250)” in the “Advanced Topics” chapter, and “Definitions in vdev-core.h” and qvm_report() in the Virtual Device Developer's API Reference.

Debugging

A vdev is a shared library (*.so file) loaded at runtime by the qvm process instances whose configurations require them. This means that you can use familiar techniques to debug your vdev.

Since a vdev is loaded into a qvm process instance, you can attach to that qvm process instance to investigate. For example, you can:

Since your vdev necessarily interacts with a guest, you may also need to do some debugging of the guest driver (see the QHS 2.0 User's Guide “Monitoring and Troubleshooting” chapter). If your vdev is in a VM (qvm process instance) that hosts a Linux guest, you may need to debug the relevant Linux OS module.

For information about debugging problems with vdev option parsing, see “Parsing the vdev options” in the chapter “The Basics: vdev trace”.

For more information about debugging in a QNX Neutrino OS system, see: