This section provides some suggestions about how to test certain types of standard devices.
Tape drivers should be tested by performing several archive and restore operations. The cpio(1) and tar(1) commands can be used for this purpose. Use the dd(1M) command to write an entire disk partition to tape. Next, read back the data, and write the data to another partition of the same size. Then compare the two copies. The mt(1) command can exercise most of the I/O controls that are specific to tape drivers. See the mtio(7I) man page. Try to use all the options. These three techniques can test the error-handling capabilities of tape drivers:
Remove the tape and try various operations
Write-protect the tape and try a write
Turn off power in the middle of different operations
Tape drivers typically implement exclusive-access open(9E) calls. These open() calls can be tested by opening a device and then having a second process try to open the same device.
Disk drivers should be tested in both the raw and block device modes. For block device tests, create a new file system on the device. Then try to mount the new file system. Then try to perform multiple file operations.
Copy another (unmounted) partition of the same size to the raw device. Then use a command such as fsck(1M) to verify the correctness of the copy. The new partition can also be mounted and then later compared to the old partition on a file-by-file basis.
Asynchronous drivers can be tested at the basic level by setting up a login line to the serial ports. A good test is to see whether a user can log in on this line. To sufficiently test an asynchronous driver, however, all the I/O control functions must be tested, with many interrupts at high speed. A test involving a loopback serial cable and high data transfer rates can help determine the reliability of the driver. You can run uucp(1C) over the line to provide some exercise. However, because uucp performs its own error handling, verify that the driver is not reporting excessive numbers of errors to the uucp process.
These types of devices are usually STREAMS-based. See the STREAMS Programming Guide for more information.
Network drivers can be tested using standard network utilities. The ftp(1) and rcp(1) commands are useful because the files can be compared on each end of the network. The driver should be tested under heavy network loading, so that various commands can be run by multiple processes.
Heavy network loading includes the following conditions:
Traffic to the test machine is heavy.
Traffic among all machines on the network is heavy.
Network cables should be unplugged while the tests are executing to ensure that the driver recovers gracefully from the resulting error conditions. Another important test is for the driver to receive multiple packets in rapid succession, that is, back-to-back packets. In this case, a relatively fast host on a lightly loaded network should send multiple packets in quick succession to the test machine. Verify that the receiving driver does not drop the second and subsequent packets.
These types of devices are usually STREAMS-based. See the STREAMS Programming Guide for more information.
Drivers supporting SR-IOV require additional testing. Standard bare-metal testing is also required, and the utilities used for bare-metal testing such as ftp and rcp for network devices can be used.
See Chapter 21, SR-IOV Drivers for information about SR-IOV Drivers.
Use the following commands to test the status of the Virtual Functions (VFs):
VF enabled – hotplug install
VF disabled – hotplug uninstall
VF assigned – hotplug list
Use the ldm (1M) command in addition to the hotplug commands when testing the status of VFs on a SPARC system.
It is also important to test SR-IOV devices in a variety of virtualized configurations. Try the following options when testing SR-IOV drivers on both SPARC and x86 platforms:
Do not configure any Virtual Functions (VFs)
Configure only one VF
Increase configured VFs by powers of 2 until the maximum number of VFs is reached
On SPARC platforms, test the functionality with a varying number of IO Domains and varying distribution of the VFs within those domains. Try the following configurations:
Assign a single VF to a single IO Domain
Assign powers of 2 VFs (up to the maximum) to a single IO Domain
Create 2,4, or 8 IO Domains and assign varying numbers of VF to each of the domains
Assign some VFs to the root domain and assign some VFs to an IO Domain
Test the following features if the device or the platform support it :
Boot the IO Domain from a VF
Physically hotplug or unplug the SR-IOV card
Perform dynamic reconfiguration operations on the SR-IOV card
If your device is supported on multiple versions of Oracle Solaris, a final testing can be performed by mixing the OS versions across the Root and IO Domains for some of the tests.