C H A P T E R 1 |
Introduction |
The Sun Validation and Test Suite (SunVTS) software runs multiple diagnostic hardware tests from a single user interface. SunVTS verifies the connectivity, functionality, and reliability of most hardware controllers and devices.
This manual is a supplement to the SunVTS 5.1 documentation and describes new features, tests, and test enhancements that are developed in the SunVTS 5.1 Patch Set releases. The new features, tests, and test enhancements included in this document are provided in the SunVTS 5.1 Patch Set 5 (PS5) software that is distributed on the Solaris Software Supplement CD.
For overall SunVTS features, test configuration modes, interfaces, and options refer to the SunVTS 5.1 User's Guide. Refer to the SunVTS 5.1 Test Reference Manual for detailed information on SunVTS test software and the full collection of tests released with SunVTS 5.1.
The new features of the SunVTS software introduced in SunVTS 5.1 Patch Set releases are described in Chapter 2.
The following new test is introduced in the SunVTS 5.1 PS5 release:
JNI 2GB FC HBA Test (jnifctest) - described in Chapter 3.
The following tests are enhanced in the SunVTS 5.1 PS5 release:
Level 1 Data Cache Test (l1dcachetest), described in Chapter 4.
System Service Processor Test (ssptest), described in Chapter 7.
The following tests were introduced in the SunVTS 5.1 PS4 release:
Sun Netra 240 Alarm Card Test (n240atest), described in Chapter 8.
RAM Test (ramtest), described in Chapter 9.
The following tests were enhanced in the SunVTS 5.1 PS4 release:
Disk and Floppy Drives Test (disktest), described in Chapter 10.
Sun Fire V880 FC-AL Disk Backplane Test (dpmtest), described in Chapter 11.
Ethernet Loopback Test (netlbtest), described in Chapter 12.
Multiprocessor Test (mptest), described in Chapter 13.
The following tests were introduced or enhanced in previous SunVTS 5.1 Patch Set releases:
Chip Multi-Threading Test (cmttest), described in Chapter 14.
Level 2 Cache Test (l2sramtest), described in Chapter 15.
Alarm Card 2 Test (alarm2test), described in Chapter 16.
Sun XVR-100 Graphics Accelerator Test (pfbtest), described in Chapter 17.
Sun XVR-1200 Graphics Accelerator Test (jfbtest), described in Chapter 18.
Sun XVR-4000 Graphics Accelerator Test (zulutest), described in Chapter 19.
Blade Support Chip Test (bsctest), described in Chapter 20.
Environmental Test (env6test), described in Chapter 21.
I2C Inter-Integrated Circuit Test (i2c2test), described in Chapter 22.
Physical Memory Test (pmemtest), described in Chapter 23.
Virtual Memory Test (vmemtest), described in Chapter 24.
Floating Point Unit Test (fputest), described in Chapter 25.
System Test (systest), described in Chapter 26.
Integer Unit Test (iutest), described in Chapter 27.
The System Service Processor test (ssptest) was previously titled the Remote System Control test (rsctest) in SunVTS 5.1. The reason for this change is that this test now supports Advanced Lights-Out Management hardware in addition to both Remote System Control 1.0 and 2.0 hardware.
SunVTS is composed of many individual tests that support testing of a wide range of products and peripherals. Most 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, DVD-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.
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 User's Guide for installation information.
SunVTS Version 5.1 was first introduced and designed to run in the Solaris 8 2/02 and Solaris 9 operating environments. It is recommended that you run SunVTS 5.1 in either of these operating environments.
The operating system kernel must be configured to support all peripherals that are to be tested.
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.
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.
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:
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 User's Guide. |
If you use the sunvts command to run SunVTS, SunVTS automatically allocates 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 System Administration manuals. In Solaris 8 2/02 and Solaris 9, the following command can be used to identify the application support of your system.
Note - The isainfo command is not available in Solaris 2.6 or earlier releases. |
You can run SunVTS tests from various interfaces: The CDE graphical user interfaces, or the TTY interface. SunVTS tests can also be run individually from a shell tool command line, using the command-line syntax for each test (refer to Running a Test From the Command Line). describes the various SunVTS user interfaces. Refer to the SunVTS User's Guide for more information on these interfaces.
The common way to run SunVTS testing is through a SunVTS user interface--CDE or the TTY interface.
Test configuration, control, and results are easily accessed through buttons and dialog boxes. These buttons and dialog boxes are covered in the SunVTS User's Guide. However, the Test Parameter Options dialog box is unique for each test, and is therefore covered in this manual.
The options displayed in this menu differ for each test, but the lower set of buttons are generic and are described below.
Note - The Test Parameter Options Dialog box descriptions also apply to the Test Parameter Options menu in the TTY interface. |
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:
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] [-i number] [-w number][-o test_specific_arguments]
The following table defines the standard SunVTS command-line arguments:
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. |
There are test-specific arguments, as described in . 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.
Before running a frame buffer test, determine whether the test requires frame buffer locking. Not all frame buffer tests have a locking option. Some tests set the lock automatically. Check the test chapter for each individual test to see if this step is needed. If locking is required, you can set the lock in one of two ways:
If you are using the CDE SunVTS interface, go to the Option menu of the graphic test and select Enable for the frame buffer locking option.
If you are working from the command line, you can enable frame buffer locking with the lock=e/d option. For example, to run the generic frame buffer test (fbtest) with a locked frame buffer, enter:
(See the test command line argument descriptions in the individual test chapters.)
Caution - If you are using the CDE interface for SunVTS, do not conduct frame buffer tests through the dtlogin window. Log in as root and disable the auto-logout option. |
Caution - Do not run TTY mode and frame buffer tests concurrently on the console monitor. The frame buffer test may fail. |
The following rules apply when you test multiple frame buffers (displays) simultaneously:
Only the console monitor can run the window environment (such as CDE). The console monitor is the monitor connected to the frame buffer appointed by
/dev/fb. SunVTS enables frame buffer locking on the console monitor by default.
The frame buffer that is running the window environment must have window locking enabled to avoid false test failures. All other frame buffers must have window locking disabled.
If you start sunvts or vtsk from a screen other than the console monitor, frame buffer locking is not available. In this case:
Disable the window locking option on the remote screen by setting it to d.
Enable frame buffer locking for the console monitor, as shown in the example above. The SunVTS user interface cannot display on a monitor if locking is disabled.
Do not run any graphic programs (including vtsui) on the remote frame buffer during graphic testing.
Copyright © 2003, Sun Microsystems, Inc. All rights reserved.