CHAPTER 1

Introduction

---

The Sun Validation and Test Suite (SunVTS) software runs multiple diagnostic hardware tests from a single user interface. SunVTS verifies the configuration, functionality, and reliability of most hardware controllers and devices.

SunVTS works from either the Common Desktop Environment (CDE) user interface or the OPEN LOOK (OL) user interface, which lets you set test parameters quickly and easily while running the diagnostic tests. The sample screens and menus in this manual are of SunVTS using the CDE user interface.

This manual describes SunVTS Version 2.1, which is on the SMCC Updates CD. The default installation directory for SunVTS is /opt/SUNWvts. When you are installing SunVTS, you can specify a different directory to install the software.

---

Accessing SunVTS

You can access SunVTS from various interfaces: CDE, OL, or the TTY interface. SunVTS tests can be run from a shell command line, using the command line syntax for each test. The SunVTS kernel probes for hardware devices installed on your system or on a remote system. Table 1-1 describes the various SunVTS system interfaces.

TABLE 1-1

SunVTS System Interfaces	Description
Graphical User Interfaces (GUIs)	Lets users select tests and test options by pointing and clicking with a mouse button. You can use the CDE or OL interface
TTY Interface	Lets users run SunVTS from a terminal or modem attached to a serial port. This feature requires that you use the keyboard instead of using the mouse, and it displays one screen of information at a time. However, it emulates the window system whenever possible
Command Line Interface	Lets users run each of the SunVTS tests individually from a shell command line using the command line syntax. Each test description contains the corresponding command line syntax. For more information about running individual tests from the command line, refer to the specific test description in this manual and "Standard Command Line Arguments" on page 2.

Standard Command Line Arguments

Different types of command line arguments can be applied to a test: generic command arguments (common to all tests), and test-specific command arguments. Because the code for each test defines test-specific arguments, this section only addresses generic command parameters.

The standard usage for all SunVTS tests is:

Usage: testname [-scruvdtelnf] [-p number][-i number] [-w number] [-o test specific arguments]

The following table defines the standard SunVTS command line arguments:

TABLE 1-2

Argument	Definition
-s	Runs a test in SunVTS mode
-c	Enables a core dump; the test creates a core file if a system crash occurs
-r	Runs on Error; if an error occurs, the test continues the next test sequence instead of exiting
-u	Displays the Usage statement
-v	Runs the test in Verbose mode; the test displays VERBOSE messages that tell more about the testing process
-d	Runs the test in Debug mode; the test displays DEBUG messages to help programmers debug their test code
-t	Runs the test in test function trace mode; the test displays TRACE messages that track down function calls and sequences currently being used by the test code
-e	Runs in stress mode; the test runs under increased system load
-l	Runs in online mode
-n	Runs in Connection test mode
-f	Runs in Functional test mode
-i number	Defines the number of instances for scalable tests
-p number	Defines the number of passes
-w number	For scalable tests, defines which instance the test is assigned

Test-Specific Arguments

Test-specific arguments should follow the format specified in the getsubopt(3c) man page. There should be at least one test-specific argument, as described in TABLE 1-3.

TABLE 1-3

Argument	Definition
-o	Separate each test-specific argument by commas, with no space after the each comma. For example: # ./sample -v -o dev=/dev/audio,volume=78 The test option format is specified by the man page getsubopt(3C).

Test Modes

SunVTS has two test modes that you can select during testing. The test modes are Connection, and Functional. For more information about these test modes, refer to the specific test description in this manual.

Hardware Verification

The SunVTS kernel automatically probes the system kernel for installed hardware devices. Those devices are then displayed on the SunVTS control panel with the appropriate tests and test options. This provides a quick check of your hardware setup.

---

Hardware and Software Requirements

The SunVTS Version 2.1 software runs on any system with the Solaris 2.5, or 2.5.1 operating environment installed. The operating system kernel must be configured to support all peripherals that are to be tested.

Software Requirements

The default Graphical User Interface (GUI) is the Common Desktop Environment (CDE). The CDE GUI requires that the CDE end user software be installed, or at least the SUNWdtbas package from it. See your system administrator for assistance with installing the CDE software. The CDE GUI runs on either the OPEN LOOK desktop or the CDE desktop.

You must meet the following requirements to run SunVTS with the OPEN LOOK GUI:

• Run Solaris 2.5 operating system
• Run OPEN LOOK, Version 3.3
• Set the correct openwin path Set the OPENWINHOME environment variable to point to the location where OPEN LOOK is installed on your system. You can ignore this requirement if you use the default location, /usr/openwin.

Otherwise, use the following command and substitute the pathname variable for the actual path where OPEN LOOK is installed.

% setenv OPENWINHOME pathname

Check the existing OPENWINHOME by typing env.

• Set the correct library path. Set the LD_LIBRARY_PATH environment variable to point to the location of the Windows library directory on your system. If you use the default location, /usr/openwin/lib, you can ignore this requirement.

Otherwise, use the following command and substitute the pathname variable for the actual path where OPEN LOOK library is installed.

% setenv LD_LIBRARY_PATH pathname

· Check the existing LD_LIBRARY_PATH by typing env.

Testing Multiple Frame Buffers

These rules apply when you test multiple frame buffers (displays) simultaneously:

• You can test multiple frame buffers on a system at the same time, but only one frame buffer can run the OPEN LOOK software.

• To avoid incorrect test failures, the frame buffer that runs the OPEN LOOK software must have window locking enabled. Any other frame buffers must have window locking disabled.

---

Caution - If window locking is disabled (unlocked) on frame buffers that are running OPEN LOOK software, the SunVTS tests can return spurious error messages if you move the mouse during testing. Even a slight mouse movement can cause a test to fail.

---

• By default, SunVTS enables window locking on the console monitor (frame buffers that are pointed by /dev/fb).
• If you are running a frame buffer test from a command line, you can disable window locking by specifying a command line argument (see the test command line descriptions in this manual). For example, when running the generic frame buffer test (fbtest), use the lock=e/d option to disable or enable frame buffer locking. Frame buffer locking is being enabled in the example below:

#./fbtest -o dev=cgthree0,lock=e

Remote Testing

The frame buffer locking option does not work when you start sunvts or vtsk remotely. In this case, set the frame buffer locking option to disable. Do not run any graphic programs (including vtsui) on that frame buffer during graphic testing.