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 is comprised of many individual tests that support testing of a wide range of products and peripherals. Many of the tests are capable of testing devices in a 32-bit or 64-bit Solaris environment.

Use SunVTS to test one device or multiple devices. Some of the major test categories are:

• Audio Tests

• Communication (Serial and Parallel) Tests

• Graphic/Video Tests

• Memory Tests

• Network Tests

• Peripherals (Disks, Tape, CD-ROM, Printer, Floppy) Tests

• Processor Tests

• Storage Tests

Such flexibility means that the proper test modes and options need to be selected to maximize its effectiveness. This book covers the individual test options and requirements. For overall test configuration modes and options refer to the SunVTS 3.0 User's Guide.

This manual describes SunVTS Version 3.0 tests, that are distributed on the Sun Computer Systems Supplement CD.

The default installation directory for SunVTS is /opt/SUNWvts. However, when you are installing SunVTS, you can specify a different directory. Refer to the SunVTS 3.0 User's Guide for installation information.

Requirements

SunVTS revision 3.0 was first introduced, and designed to run in the Solaris 7 operating environment.

The operating system kernel must be configured to support all peripherals that are to be tested.

The system must be booted and the SunVTS packages must be installed. Refer to the SunVTS 3.0 User's Guide for more information.

Some SunVTS tests have special requirements such as the connection of loopback connectors, installation of test media, or the availability of disk space. These requirements are listed for each test in the corresponding chapter in this book.

Test Modes

Two modes of testing are available--Connection test and Functional test. These modes differ in their assumptions about the state of the system you are testing and your objectives.

Only one test mode can be selected per test session. Each mode is described below:

Connection Test Mode

In Connection test mode, the tests determine if the devices are connected to the system you are testing and verifies that they are accessible.

Device functionality is not verified, however, you can safely run this mode when the system is online.

Functional Test Mode

In Functional test mode, the tests fully exercise all aspects of the selected devices and their associated device drivers.

In Functional test mode you can run a single test in to verify the functionality of a single device, or run multiple tests on all system devices for full system verification.

For thorough testing, the tests use a significant portion of the system resources. For this reason, do not run critical applications on the system or use the system for production purposes while testing in Functional test mode.

In Functional test mode, tests expect all system resources that are associated with the device to be available for testing. If the test cannot access a device, it registers a failure. The tests do not economize on runtime, but focus on achieving complete coverage and thoroughly exercising the device.

---

Note -

SunVTS does not verify that the system is in a safe offline state for Functional mode testing. You must be sure that your applications and the SunVTS diagnostic will not compete for system resources. For more information regarding runtime considerations refer to the SunVTS 3.0 User's Guide.

---

Functional Test Mode via Solstice SyMON

Solstice SyMON identifies a range of hardware and system status states quickly.

Solstice SyMON has an online diagnostic interface, so you can access SunVTS when running SyMON. In this case, Functional test mode does operational testing to find and isolate faults, while minimizing the impact on other applications and users.

When Functional test mode is accessed from SyMON, the system may be running critical production software. The tests are sensitive to this fact and usually try to achieve as much coverage as possible within the constraints imposed. In this mode, some of the test parameters, execution options, and some system level options are fixed (have preassigned values) that cannot be changed. This ensures that the system state is not violated by selecting an option or combination of options which could trigger unsafe actions.

Table 1-1 shows the default values of the test execution options in different modes.

Table 1-1 Test Execution Options

Option	Connection Test Mode	Functional Test Mode	Functional Test Mode via SyMON
Stress	Disabled (fixed)	Disabled	Disabled (fixed)
Verbose	Disabled (fixed)	Disabled	Disabled (fixed)
Core File	Disabled (fixed)	Disabled	Disabled (fixed)
Run On Error	Disabled (fixed)	Disabled	Disabled (fixed)
Max Passes	1 (fixed)	0	1 (fixed)
Max Time	0 (fixed)	0	0 (fixed)
Number of Instances	1 (fixed)	Dependent on the number of processors	1 (fixed)

SunVTS User Interfaces

You can run SunVTS tests from various interfaces: The CDE and OL graphical user interfaces, or the TTY interface. SunVTS tests can also be run individually from a shell command line, using the command line syntax for each test (refer to "Running a Test from the Command Line"). Table 1-1 describes the various SunVTS system interfaces. Refer to the SunVTS 3.0 User's Guide for more information on these interfaces.

Table 1-2 SunVTS System Interfaces

SunVTS System Interfaces	Description
Graphical User Interfaces (GUIs)	Users can select tests and test options by pointing and clicking with a mouse button in the CDE or OL interface.
TTY Interface	Users can run SunVTS from a terminal or modem attached to a serial port. This feature requires that you use the keyboard instead of the mouse, and it displays one screen of information at a time.
Command Line execution	Lets users run each of the SunVTS tests individually from a shell command line using the command line syntax. Each test description in this book contains the corresponding command line syntax.
SyMON GUI	Provides access to SunVTS testing through the SyMON monitoring tool. With this interface, the SunVTS tests run in a mode that is non-intrusive to other system activity.

Collection of SunVTS tests

Many individual tests make up the collection of tests in the SunVTS application. Each test is a separate process from the SunVTS kernel. Each test can be run individually from the command line or from the SunVTS user interface.

When SunVTS is started, the SunVTS kernel automatically probes the system kernel to determine the hardware devices. The devices are then displayed on the SunVTS control panel with the appropriate tests and test options. This provides a quick check of your hardware configuration, and no time is wasted trying to run tests that are not applicable to your configuration.

During testing, the hardware tests send the test status and messages to the SunVTS kernel through interprocess communication (IPC) protocols. The kernel passes the status to the user interface and logs the messages.

SunVTS has a shared object library that contains test-specific probing routines. At runtime, the SunVTS kernel dynamically links in and calls these probing routines to initialize its data structure with test-specific information. You can add new tests into the SunVTS environment without recompiling the SunVTS source code.

As of SunVTS 3.0, the SunVTS kernel and most tests support 32-bit and 64-bit operating environments. When the sunvts command is used to start SunVTS, the appropriate tests (32-bit or 64-bit versions) are presented.

32-Bit and 64-Bit Tests

Because each test is a separate program, you can run individual tests directly from the command line. When this is done, care must be taken to run the appropriate test (32-bit or 64-bit) that corresponds to the operating system that is running (32-bit or 64-bit). This is done by running tests from specific directories as follows:

• 32-bit tests--/opt/SUNWvts/bin/testname

• 64-bit tests--/opt/SUNWvts/bin/sparcv9/testname

  • The test is an actual 64-bit binary test if testname is a binary file

  • The test is a 32-bit test capable of running in the 64-bit environment if testname is a symbolic link

---

Note -

The SUNWvtsx package must be installed for 64-bit SunVTS support. For more information on SunVTS packages and installation procedures refer to the SunVTS 3.0 User's Guide.

---

If you use the sunvts command to run SunVTS, SunVTS will automatically allocate 32-bit or 64-bit tests based on the 32-bit or 64-bit Solaris operating environment that is running. Therefore, the only time that you need to be concerned with the 32-bit or 64-bit operation is when you run the SunVTS kernel or SunVTS tests from the command line.

If you are not sure which operating system is running, refer to the Solaris 7 System Administration manuals. In Solaris 7, the following command can be used to identify the application support of your system.

# isainfo -v

---

Note -

The isainfo command is not available in Solaris 2.6 or earlier releases.

---

Running a Test from the Command Line

In some cases it may be more convenient to run a single SunVTS test from the command line rather than through a SunVTS user interface. The following information describes how to do this.

Unless specified, the test runs without the SunVTS kernel (vtsk). All events and errors are sent to stdout or stderr, and are not logged in the log files.

When you run a test in this way, you must specify all test options in the form of command line arguments.

There are two types of command line arguments:

• Standard arguments--common to all tests. Refer to Table 1-3 for details.

• Test specific arguments--unique to a specific test. Refer to the test specific chapters in this book for details.

The standard syntax for all SunVTS tests is:

---

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

---

---

Note -

64-bit tests are located in the sparcv9 subdirectory: /opt/SUNWvts/bin/sparcv9/testname. If a test is not present in this directory, then it may only be available as a 32-bit test. For more information refer to "32-Bit and 64-Bit Tests".

---

Standard Command Line Arguments

The following table defines the standard SunVTS command line arguments:

Table 1-3 Standard Command-line Arguments

Argument	Definition
-s	Run a test as though it were invoked from the SunVTS kernel (vtsk). This causes the test to send output to an RPC port that the SunVTS kernel is using. The default is to send the output to stdout or stderr.
-c	Enables a core image of the test process to be created in the current working directory upon receipt of certain signals, otherwise those signals are caught and handled to prevent a core from being generated. The default is to disable the creation of a core image.
-r	Enables run on error so that when an error occurs, the test continues with the next test sequence instead of exiting. The default is false.
-u	Displays command line usage information.
-v	Runs the test in Verbose mode and displays messages with more detailed information about the testing process. The default is false.
-d	Runs the test in debug mode and displays messages to help programmers debug their test code. The default is false.
-t	Runs the test in test Trace mode and displays messages that track function calls and sequences currently in use by the test code. The default is false.
-e	Runs the test in Stress Mode by increasing the system load. The default is false.
-l	Runs the test in Online Functional mode. This is the same mode that tests run in when executed through SyMON. It is a non-intrusive version that will not significantly affect other applications. See the note below. The default is true.
-n	Runs the test in Connection Mode. See the note below.The default is false.
-f	Runs the test in full Functional test mode. This mode assumes that the test has complete control of the device under test. See the note below. The default is false.
-i number	Defines the number of instances for scalable tests.
-p number	Defines the number of passes.
-w number	For scalable tests, defines to which instance the test is assigned.
-o	Used to indicate that the options and arguments that follow are test specific. Note - separate each test specific argument by commas, with no space after each comma.

---

Note -

If you choose to specify a test mode with the l, n, or f option, specify only one option at a time because only one test mode can be selected at a time.

---

Test-Specific Arguments

There are test-specific arguments, as described in Table 1-4 Test-specific arguments follow the format specified in the getsubopt(3c) man page. For information about test-specific arguments refer to the specific test chapter in this book.

Table 1-4 SunVTS Test-Specific Arguments

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).

To Test Multiple Frame Buffers

The following 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 window environment.

• To avoid incorrect test failures, for those frame buffer tests that have a window locking option, the frame buffer that runs the window environment, such as CDE or 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, the SunVTS tests can return false 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 the /dev/fb named device).

• 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 enable or disable Window Locking. The example below shows the command that enables Window locking (frame buffer locking):

  ---

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

  ---

Remote Testing of Frame Buffers

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