Skip to ContentSun and Oracle Channel Sun How to Buy Log In

SunVTS 2.1 User's Guide

Contained Within

Find More Documentation

Featured Support Resources

Download this book in PDF

CHAPTER 4

SunVTS Testing Environment

This chapter describes the more commonly used features of SunVTS in a typical testing environment. The examples in this chapter use the CDE user interface.

System Mapping

System mapping provides a consistent view of the system configuration, depending on the user's requirements. The SunVTS probe only displays the devices for which tests are present. Devices that are not testable, or for which there is currently no SunVTS test, are not displayed.

There are two types of system mapping:

Physical--which shows the exact location of the device on the system for Field Replaceable Unit (FRU) identification. From the physical mapping, you can determine the actual location of the device(s). When possible, the board number and controller type for the device are also displayed.
Logical--which organizes the devices being probed according to the functional device type, such as disks, graphics, and so forth. The Logical map is determined by the individual device probes. From the Logical view, you can view the system through one or more logical device groups. You can focus on a specific group or on all of the groups on the system.

When you select either the physical or logical button from the user interface, the system mapping is displayed.

Note - This feature is available only on the following server systems: SS1000, SS2000, and Ultra^(TM) Enterprise^(TM) Models 6000, 4000, 3000, and 450.

Test Selection

Use the Test Selection panel to selectively enable the tests you want to run during the testing session.

Choosing Tests in the Test Selection Panel

When you start SunVTS, the SunVTS kernel probes the test system devices. The results of this probe are displayed on the Test Selection panel. There is an associated SunVTS test for most hardware devices on your system.

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.

To indicate the level of system usage, a distinction is made between Connection and Functional system states.

Connection Test Mode

In Connection test mode, the tests determine if the devices are connected to the system you are testing and if they are accessible. Functional testing is not done in this mode, but the devices are accessed to establish system connection and accessibility.

You can safely run this mode when the system is online. When SunVTS testing is started in Connection test mode, each test is run sequentially until all tests are run.

The limited nature of the tests in this mode makes it possible to run periodic checks for configuration verification on the system.

Functional Test Mode

Functional test mode thoroughly checks the operation of the system devices. This mode finds any faults and exercises the system by running tests to increase the load and stress on the system.

Do not run critical applications on the system or use the system for production purposes in Functional test mode.

Note - Solaris is required to be running in Functional test mode. However, the system should not be running critical production software.

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 - You must be sure that the state of the system conforms to assumptions made regarding it before running the tests in the Functional test mode. SunVTS does not verify that the system is Functional test mode or that the assumption made above is true; it does not stop other applications or log out other users.

Functional Test Mode via Solstice SyMON

Solstice SyMON identifies a range of hardware and system status states quickly. For example, it can monitor a major condition such as a CPU failure or a minor condition such as low swap space. You can also monitor hardware performance to detect incipient hardware failures, such as soft read errors on a disk.

To give you this critical performance information, Solstice SyMON analyzes system performance in real time; when performance problems occur, the event system alerts you, if desired, to the status of most system components.

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 4-1 shows the default values of the test execution options in different modes.

TABLE 4-1

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)

Intervention

Certain tests like the serial port test (sptest), require that you intervene before running the test. Attach a loopback connector before running the serial port test. Other tests, like the tape drive test (tapetest), require that you insert scratch media into the device.

After selecting Enable on the Intervention switch, you can select all the tests (see "Test Set" on page 108 and "Selecting Test Groups and Individual Tests" on page 109). This switch serves as a reminder that you may need to intervene before running certain tests; it does not change the test.

Test Set

Use the Test Set switch to select test states. When you start SunVTS, a default set of tests appears on the Test Selection panel. This default selection of tests provides you with a set amount of coverage during the testing session.

You can select or deselect other tests besides the default test set. If you select a different group of tests, you can return to the default test selection by choosing the Default selection on the Tests switch.

If you enable Intervention, you can select all of the tests available by choosing All on the Test Set switch.

You can deselect all the tests with None. This selection is convenient when you only want to run a single test. You can first deselect all the tests and then select the single test you want to run.

Selecting Test Groups and Individual Tests

You can select entire test groups or individual tests from the Tests Selection panel. There are checkboxes in front of each test and test group (FIGURE 4-1). By clicking on the test group box, you can select or deselect all the tests in that group. Also, by clicking on a test box, you can select or deselect that one test.

Selecting only the tests you want to run fine-tunes your testing session.

FIGURE 4-1

Test Execution Options

You can customize your SunVTS environment by setting option variables, as follows:

System options affect the overall SunVTS environment, such as determining when to stop testing, whether verbose messages from a test are displayed, and so on.
Test specific options are the set of options that accompany each test, and pertain to that test only. For example, the amount of media to test in a disk test, the amount of memory to test in memory test, the remote host address in a net test, and so on.

TABLE 4-2

System Option	Description
`Stress`	Performs stress testing
`Core File`	Creates a Core file. If the <`SunVTS bin`> directory is writable then core.<*testname>.xxxxxx is the Core file name, where <testname> is the test that dumped core, and where xxxxxx* is a character string generated by the system to make the file name unique. When `core_file` is disabled, a message indicating the signal that caused the failure is displayed and logged. See "Log Files" on page 91 in Chapter 3.
`Max Errors`	States the maximum allowable number of errors before stopping (0 makes the SunVTS kernel continue testing regardless of errors)
`Max Passes`	Specifies the maximum number of passes a test can run
`Max Time`	States, in minutes, the time limit a test can run (0 = no limit)
`Number of Instances`	Indicates the number of instances (processes) of scalable tests that can run on the same processor
`Processor Affinity`	Tests can be bound to a specific processor via this option
`Run On Error`	Continues testing until the `max_errs` number is reached
`Verbose`	Displays verbose messages in the SunVTS console window

Some options in the Connection test mode or in Functional test mode when invoked through the Solstice SyMON diagnostic interface have preassigned values that cannot be changed. This prevents changing or setting values for these options that may not be safe when the system is online (see "Test Selection" on page 106 for more information on system states and testing modes).

The set of SunVTS option variables are classified into three categories:

Options applied at the system or root level
Options applied at the groups level
Options applied at the test level

For example, Max Time is applied at the system level, Group Concurrency is applied at the group level, and Verbose is applied at the individual test level.

SunVTS provides a mechanism for setting the options so tests in all the groups are affected globally. You can restrict the settings to all the tests and sub-groups in one group, or you can limit the effect to just one test.

When you assign a value to an option globally, that value applies to all the groups and tests below it. Similarly, setting an option at the group level causes the value to trickle down to all the sub-groups and tests below it. This is a powerful way to customize the SunVTS testing environment. For example, you can disable the Verbose option at the system level and then enable it only for a particular group (or only a particular test) so that just the verbose messages from that particular group (or test) are displayed.

You can modify the effects of these options using locks and overrides. Use the Group Lock and Test Lock at the group and test levels; and use the System Override and Group Override at the global and group levels.

Enabling the Group Lock prevents an option set at a higher level from affecting a specific group or test and the sub-groups and tests below it. Similarly, you can set the Test Lock to protect the option setting of a test. You can use the overrides to void the lock protection. For example, setting System Override nullifies all the locks, and setting Group Override for a particular group nullifies all the locks below that group.

Setting Options

In the Test Option panel, you can select and deselect tests. You can also change the global options for each test group and change the specific options for each test (see FIGURE 4-2).

FIGURE 4-2

Note - Your test system configuration determines the appearance of this panel.

Advanced Options

Since options generally trickle down from the system level to the tests, there are ways to prevent test or group options from being reset by global option settings. However, to do this, the Global and Group option menus have Override buttons for the locks that exist below that level. You select these special options from the Advanced options menu.

Scalability of Tests

Use the scalability feature to scale the number of test instances or processes to stress single or multiprocessor systems. You can modify the scalable test options so that each test instance runs simultaneously with a different option. Combined with the

processor affinity mask, SunVTS provides a flexible testing environment. You can determine the amount of stress by the number of test instances you select using the options described below.

Group Concurrency--sets the maximum number of tests you want to run at the same time in the same group.
System Concurrency--sets the maximum number of tests that you can run at the same time in the entire system; it overrides the Group Concurrency option.
Instances--copies of a test that you can run simultaneously on the same device. For example, if a test has eight instances, then you can run eight copies of that test, and each copy can run on either one or all of the processors in the test system (see "Processor Affinity" below). You can set the number of instances with the Number of Instances option (this option only applies to scalable tests).
Processor Affinity--lets you specify the processor on which you want to run the tests; it is only available on multiprocessor systems. Each instance of the test can have a different Processor Affinity. Only one processor can be bound to an instance of the test. When no Processor Affinity is specified, migrating is the default.

Preparing for SunVTS Testing

Before you begin testing, you need to decide how you want to test your system. The SunVTS options let you fine-tune your test sessions. For example, you can choose to test only one specific piece of hardware, or you can test all of the system hardware. Similarly, you can set up SunVTS to verify the system's overall functionality, or you can set it up to stress system capabilities. Stressing the system uses more resources, and requires more testing time.

Loopback Connectors

Certain SunVTS tests require loopback plugs or cables to run successfully. Refer to the SunVTS 2.1 Test Reference Manual for more information about loopback connectors, and which tests require them.

Normal production programs cannot run with the loopback connectors on these devices. Be sure to remove these plugs for normal operation.

Note - The loopback test is not applicable to connection test modes or, when accessed from SyMON, functional test modes, so no loopback connectors are not required under these two modes.

Blank or Scratch CDs, Tapes, and Diskettes

Note - You cannot write to a device in connection test mode or, when accessed from SyMON, in functional test mode.

Insert blank or scratch media (tape, diskette, or CD) into the drive(s), before the system is probed by the SunVTS kernel when first starting the sunvts software application.

For CD tests, load a blank or scratch CD into the drive.
Tape tests require 4mm, 8mm, one-half inch, or one-quarter inch scratch tapes (depending on the type of drive being tested). Make sure the tape heads are properly cleaned.
For hard disk and diskette tests, be sure there is enough space on your disk partition. Double or triple density diskettes (1.4 Mbyte) are required, depending on the diskette drive in your system.

Note - Using old or damaged tapes or diskettes may cause errors in corresponding tests.

Testing Frame Buffers

If you are running SunVTS on a frame buffer that is running a graphics test, a false error may occur. This is not a problem when you are running windows (OPEN LOOK or CDE).

No other graphic application can be run in the same window once you start the graphic test.

· To Activate the Frame Buffer Test

If you are using a GUI, from the Option menu of the graphic test, Select Enable.
If you are working from a command line, you can enable frame buffer locking by specifying a command line argument.
See the test command line arguments in the SunVTS 2.1 Test Reference Manual.


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

Caution - Do not run TTY mode and frame buffer tests concurrently on the console monitor; the frame buffer tests may fail. For information about how to start the TTY interface and connect to a remote machine running the SunVTS kernel, see "In TTY Mode" on page 34 in Chapter 2.

If you are starting SunVTS with vtsui without running vtsk first, you must add the hostname to the xserver using the xhost command.

Note - If window locking is disabled (unlocked) on frame buffers that are running vtsui, or you move the mouse, you will receive spurious error messages. Even slight mouse movements can cause a test to fail.

Testing Multiple Frame Buffers

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

You can test multiple frame buffers on a system simultaneously, but only the console monitor can run windows. The console monitor is the monitor connected to the frame buffer appointed by /dev/fb.
The frame buffer that is running windows must have frame buffer locking enabled to avoid spurious test failures. Other frame buffers must have frame buffer locking disabled.
By default, SunVTS enables frame buffer locking for the console frame buffer (/dev/fb). If your system has more than one frame buffer, you must disable frame buffer locking for all frame buffers except the one running windows. If you are running a frame buffer test from a command line, you can disable or enable frame buffer locking by specifying a command line argument. (See the test command line descriptions in the SunVTS 2.1 Test Reference Manual.) For example, if you were running the generic frame buffer test (fbtest), you would use the lock=Disable/Enable option to disable frame buffer locking:


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

If you start SunVTS from a screen other than the console monitor, Frame buffer locking is not available. You must enable the frame buffer lock for the console monitor, as shown in the example above. The SunVTS user interface cannot display on a monitor if frame buffer locking is disabled.

Starting the Testing Session

Use the Start Button on the SunVTS Control Panel interface to start a test session. This will start testing on the peripherals. Refer to "The Start Button" on page 77 in Chapter 3 for details.

Suspending the Testing Session

During the testing session, you may need to suspend or pause all tests. For example, you may want to look at messages on the Console panel that have scrolled out of view, or you may want to view and print a log file.

Click the Suspend button to pause all of the SunVTS tests. After the test is paused, the Suspend button becomes a Resume button. Click on the Resume button to continue the testing session.

Resuming the Testing Session

Once the testing session is suspended, it must be resumed before you can continue testing or stop testing. To resume testing, click the Resume button (see FIGURE 4-3). You can now stop the testing by clicking the Stop button.

FIGURE 4-3

Resetting the Test Environment

If you need to start the testing session over again, without quitting SunVTS, click the Reset button. Refer to "The Reset Button" on page 78" in Chapter 3 for details.

Stopping the Testing Session

Once you have adequately tested your system, you can stop the testing session and review the results.

SunVTS ends the test execution automatically for a number of reasons. For example, if you have enabled the Single Pass option on the Option menu, all enabled tests run once and stop, but the elapsed time continues to increment.

Testing stops if an error occurs and the run at error was not set or, if run at error was set but the error count reached the maximum number of errors.

Stop Button

Click the Stop button to stop the testing session. The System Status panel temporarily displays "stopping" while the tests wind down. The amount of time it takes to stop depends on which tests you are running. For example, the tapetest requires time to rewind the tape or remove the mounted partitions and temporary files. A pop-up menu displays the message, "testing completed: xxx pass(es), x error(s)" when testing is complete.

After you stop the testing session, you can view the Test Status panel to see how many passes and errors occurred per test, and you can display or print the log files.

If a test hangs, SunVTS remains in Stop mode, and waits for the test to terminate. (This is probably due to a hardware problem.) Deselect the test, which signals SunVTS to ignore the stopped test and return to Idle mode. Refer to "The Stop Button" on page 77 in Chapter 3 for details.

Monitoring Test Status

While SunVTS is testing the system, you can view the progress of the test by monitoring the panels, windows, and log files.

System Status Panel

The System Status panel displays the current activity of the SunVTS kernel. For example, the status can be idle (when not testing), testing, or stopped (when the maximum number of errors is reached, or when you stop the testing).

This panel also displays the total number of successful system passes (a system pass is when all tests have been run once), and the total number of errors from all tests. The total elapsed time is also displayed on this panel.

Test Status Panel

This panel, located below the System Status panel, displays the status of all selected tests. The status of each selected test is listed as follows:

The Passes count shows how many times the test has completed a run.
The Errors count shows how many times the test exited with an error. If the test has an asterisk (*) by it, that test is currently being run.
The letter "T" is displayed next to the test name when Trace mode is active. While monitoring this panel, you'll notice that some tests take longer to run than others.

The Test Status panel displays information on a limited number of tests. Use the icons on the top of the panel to page through the tests (FIGURE 4-4).

If errors occur, click to display only the tests that produced errors.

Click to display the first page of tests.

Click to page backward.

Click to go to the area of a test group, test, or instance.

Click here to page forward.

Click here to display the last page of tests.

FIGURE 4-4

Performance Meter

This panel displays the performance statistics of the system you are testing. See "OPEN LOOK Performance Meter" on page 75 in Chapter 3 for details.

Console Panel

The Console panel displays the messages sent from the tests and SunVTS kernel. If you enabled verbose messages or system call trace messages on one or more tests, the messages appear in this window. Use the scrollbar to view these messages.

Reviewing Log Files

This section provides information about displaying, printing, and deleting log files. The Log file error message formats are also discussed in this section.

Log Files Menu

The status of testing is stored in three log files. These files contain error information messages. You can access these files from the Log Files menu, which is displayed when you click the Log Files button (see FIGURE 4-5).

FIGURE 4-5

The three log files in this menu are:

SunVTS Error Status Log: /var/opt/SUNWvts/logs/sunvts.err
SunVTS Information Log: /var/opt/SUNWvts/logs/sunvts.info
Solaris System Message Log: /var/adm/messages

The sunvts.err file contains SunVTS test error messages and start and stop times. The status log file, sunvts.info, contains informative messages that are generated when you start and stop SunVTS. The messages file is a log of all the general UNIX messages.

Displaying Log Files

You can display any of the three log files by selecting the name of the Log file and then clicking the Display button.

A pop-up window displays the selected log file. Notice that the log file name appears at the top of the window (FIGURE 4-6).

FIGURE 4-6

SunVTS Test Message Syntax

All SunVTS test messages follow this format:


  SUNWvts.testname[.subtest_name].message_number date time testname device_name  
  [FRU_path]ERROR|FATAL|INFO|WARNING|VERBOSE message

TABLE 4-3 lists the SunVTS test message arguments and gives a brief description.

TABLE 4-3

Argument	Description
`SUNWvts`	SunVTS package name
`testname`	SunVTS test name
`subtest_name`	The subtest module name (optional)
`message_number`	The message identifier, which is a unique number for the test. The number is usually within the following ranges: --VERBOSE: 1 - 1999 --INFO: 2000 - 3999 --WARNING: 4000 - 5999 --ERROR/FATAL: 6000 - 7999 --FATAL: 8000 - 9998 (The number 9999 is reserved for any possible old message types in previous SunVTS releases for compatibility reasons.)
`date time`	Tells when the error occurred
`testname`	The name of the test reporting the error
`device_name`	The device being tested when the error occurred
`FRU_path`	A full Solaris device path of the failed FRU; this argument varies, depending on the type of test running when the error occurred; see "Interpreting Failed FRU Information" on page 122 for details
`message`	Contains test messages, in addition to probable cause and recommended action

· Click the Display button on the Log Files menu to display Log Files (FIGURE 4-7).

FIGURE 4-7

· Click the Remove button on the Log Files pop-up window to remove Log Files.

· Click the Print button on the Log Files pop-up window to print Error Logs.

Note - These log files can be very long. Make sure you want the entire file before you print it.

Interpreting Failed FRU Information

When a test fails, SunVTS incorporates information about the failed FRU into the error message. The error message indicates the location of the failed FRU on the system. The location is indicated in the form of a path that starts with the board number to which the FRU is connected.

For example, the FRU path of cpu-unit0 on board number 0 is:


  cpu-unit0(board0)

The FRU path of a disk, c0t0d0, controlled by esp0 on board 0 is:


  c0t0d0(board0/sbi0/esp0)

The FRU path of a disk, c1t0d0, connected to a soc on board 1 is:


  c1t0d0(board1/sbi1/soc1/pln1)

Note - The FRU path feature is available only on the server systems: SS1000, SS2000, Ultra Enterprise 6000, Ultra Enterprise 4000, and Ultra Enterprise 3000.

Debug Features

Use the following options to debug your system:

Verbose--Displays a verbose message indicating that the operation is being performed on the device you are testing.
Core File--Creates a Core file when selected. If the SunVTS bin directory is writable, core.<testname>.xxxxxx is the Core file name, where <testname> is the test that dumped core, and xxxxxx is a character string generated by the system in order to make the file name unique. When Core File is disabled, a message indicating the signal that caused the failure is displayed and logged.
Run On Error Option--Continues testing until the Max Errors number is reached.
Processor Affinity--Lets you attach a process list to a specific processor. If you are an advanced user, you can use this option to isolate faults of a specific processor.

Testing with Record and Replay Options

Use the Start with Record and Replay option to record a sequence of significant events during a testing session, and to replay or view this information at a later time. Once a testing session is recorded, you can use this information to drive the SunVTS kernel so it reproduces the recorded sequence of events. These record and replay features are an effective way to reproduce testing conditions, a helpful debugging tool.

The Record with Replay option can closely reproduce the ordering of the testing events, but it cannot reproduce the time periods of these events because the execution times may vary from one run to another. When scheduling a replay using this option, give consideration only to the ordering and relative scheduling time differences between events during the original run.

These options are limited in the way that they replay a test session because you can only control the Replay option when a command starts, not after the command completes.

The Record with Replay option records the following test events:

Starting
Stopping
Enabling and Disabling Intervention mode
Selecting and Deselecting

The events are recorded in a file called vts_replay_file, which is saved in a log directory that you specify. If no log directory is specified, the /var/opt/SUNWvts/ logs directory is used by default.

The first part of the vts_replay_file consists of the SunVTS kernel and test options settings you used when you started recording. This information is used during the replay to restore the original option settings.

The events are recorded after the option settings are saved. Information is recorded in the following format for each event:


  event_type rel_time target_object [instance_num] [event_specific]

The following table describes each event string.

TABLE 4-4 vts_replay_file

Event String	Description
`event_type`	The type of event can be one of the following: START, STOP, SELECT, DESELECT, or INTERVENTION.
`rel_time`	The time (in seconds) since the preceding event.
`target_object`	The object involved in the event, for example, `fpu (fputest)`. This field is ignored if the value is a dash (`-`) as in the case of an INTERVENTION event.
`instance_num`	The instance number of the test. A valid number is required for the START and STOP events. This field has a value of `-1` for INTERVENTION, SELECT, and DESELECT events.
`event_specific`	Any additional event-specific information required to replay the event; this field contains the test command line arguments for the START event. For the INTERVENTION event, the value describes the state--either enabled or disabled. This field is blank in the case of STOP, SELECT, and DESELECT.

Installing `.customtest`

The SunVTS custom test capability provides an alternative interface to run user-developed tests.

· To install a custom test, create a text file called.customtest in the current SunVTS bin directory.

The options you set in the .customtest file become the default options for each test. You can change these options using the pop-up option menus on the SunVTS window interface. However, the Reset button returns the options to the default settings that you specify in the .customtest file.

· To probe a specific device, or to always display a custom test, enter the test label, test name, and options specifications in the .customtest file.

When invoked, SunVTS displays the custom test.

An example of a .customtest file is included in the SunVTS bin directory. The default path is /opt/SUNWvts/bin.

· To Copy the Test Binary to the `sunvts` Installation Directory

Edit the .customtest file according to the format given below.
Restart sunvts or reprobe the system configuration.
Note - If .customtest is renamed as .customtest-<group>, all its user tests will +appear under the specified <group>.

The `.customtest` File Format

The.customtest file is located in the SunVTS installation directory. Each line in this file is made up of two or more fields that are separated by a semicolon where:

The first field is the label or device name (MANDATORY FIELD).
The second field is the test name (MANDATORY FIELD).
The third field is an option line (OPTIONAL FIELD). If used, this field must be in the format specified.

The fourth field is used if the test is scalable. If used, append the keyword SCA to this field.

A user test definition requires a minimum of two fields, separated by a semicolon, as shown in the following .customtest file format examples:


  % your_label_name;your_test_name

· To add the scalability option, append the keyword SCA.


  % your_label_name;your_test_name;SCA

· To custom build an option menu, add an option specification:


  % Option_Name<Option_Type|Value|Default_Value|Command_Line_Option

· To specify more than one option, separate each option by a comma:


  % label_name;test_name;Numeric<NUMERIC|0,100|50|numeric>,  
  Exc_Choice<EXC_CHOICE|Top,Middle,Bottom|Middle|exc_choice>,  
  Inc_Choice<INC_CHOICE|Left,Center,Right|Left+Center+Right|inc_cho  
  ice>,Toggle<TOGGLE|This,That|This|toggle>, Text  
  <TEXT|20|Type_Here|text>, Slidebar<SLIDEBAR|0,10|5|slidebar>,  
  Errors<CYCLE|Yes,No|No|errors>,  
  Cycle<CYCLE|First,Second,Third|First|cycle>;SCA

SunVTS invokes the above test as follows:

% ./test_name -s[vq..] [-i n] -o dev=user[0,1..],Command_Line_Option=Value...

You cannot use the customtest facility with a test probe attached. You must ensure that the binaries are compatible with the version of the Solaris kernel on which SunVTS is currently running.

The `vtsprobe` Utility

Use the vtsprobe utility to display the results of the SunVTS kernel hardware device probe. vtsprobe lists all of the test machine's devices and their configuration information, as well as their corresponding hardware tests.

Note - The SunVTS kernel must be running on the test machine for the vtsprobe command to work. See "Using Other Commands to Start SunVTS" on page 34 in Chapter 2 for instructions on how to start the SunVTS kernel.

Using `vtsprobe` on a Local Machine

Follow the instructions below to use vtsprobe on a local machine.

· To Display the Devices of a Machine Running the SunVTS Kernel

Change directories to the SunVTS bin directory.
The directory path is /opt/SUNWvts/bin by default.
Type vtsprobe to display the list of hardware devices (CODE EXAMPLE 4-1).
CODE EXAMPLE 4-1 vtsprobe Example


  example% vtsprobe  
  
  
  Processor(s)  
       fpu(fputest)  
       Architecture: sparc  
       Type: TI TMS390Z50 SuperSPARC chip  
       system(systest)  
       System Configuration: sun4m SPARCstation 10 (1 X 390Z50)  
       System clock frequency: 40 MHz  
       SBUS clock frequency: 20 MHz  
  Memory

CODE EXAMPLE 4-1 vtsprobe Example (Continued)


       kmem(vmem)  
       Amount: 233580KB  
       mem(pmem)  
       Physical Memory size:48 Mb  
  Network  
       isdn0(isdntest)  
       le0(nettest)  
       Host_Name: example  
       Host Address: 131.155.56.122  
       Host ID: 12347f61  
       Domain Name: widget.com  
  SCSI-Devices(esp0)  
       c0t0d0(rawtest)  
       Logical Name: c0t0d0  
       Capacity: 510.23MB  
       Controller: esp0  
       c0t0d0(fstest)  
       Logical Name: c0t0d0  
       Controller:esp0  
       tape0(tapetest)  
       Drive Type: Exabyte EXB-8200 8mm Helical Scan  
  Comm.Ports  
       zs0(sptest)  
       term/a & term/b  
  Graphics  
       cgsix0(cg6)  
       5000KB required for testing.  
  OtherDevices  
       bpp0(bpptest)  
       Logical name: bpp0  
       diskette(rawtest)  
       Logical Name: diskette  
       Controller:Intel 82077  
       diskette(fstest)  
       Logical Name: diskette  
       Controller: Intel 82077  
       sound0(audio)  
       Audio Device Type: DBRI Speakerbox

Using `vtsprobe` on a Remote Machine

You can also display the hardware devices of a remote machine that is running the SunVTS kernel.

· To Display Devices of a Remote Machine Running the SunVTS Kernel

Change directories to the SunVTS bin directory.
This directory is /opt/SUNWvts/bin by default.
Type vtsprobe -h hostname, where hostname is the host name of the remote machine.
The vtsprobe utility then connects to the remote machine and displays the remote machine's hardware devices.
The output is displayed on the window in which you invoke vtsprobe.

Option Files

Use the Option files to save the current SunVTS global and test-specific options to a file for later use.

The SunVTS user interface provides an Option Files button so you can load, store, or remove an Option file by name. The file name can be any ASCII file name.

When the Option file window is displayed, click the Load button to restore the SunVTS options selection specified.

Although you can manually edit the Option file, you must adhere to strict format requirements. Unnecessary or spurious characters in the Option files may cause unexpected actions with the SunVTS kernel or user interface.

Storing an Option file saves the current settings from the global test options and specific test settings to a file in the /var/opt/SUNWvts/options directory (see FIGURE 4-8).

FIGURE 4-8

· To Save an Option File

Save all the current system and test options as a file, as follows:

Type the Option file name in the test field.
Click the Store button.
After you save an Option file, you can load it at the command line when you start the SunVTS kernel with the -o option. For example, if you create an Option file called test_defaults, you can load this Option file when you start the SunVTS software by typing:


  # ./sunvts -o test_defaults

· To Load a Previously Saved Option File

Note - If the Option file name is .sunvts, it is loaded every time SunVTS comes up by default.

Click the MENU mouse button on the Option File menu button to display the available Option files.
All Option files saved in /var/opt/SUNWvts/options are displayed in the Option File Name menu.

Select the Option file that you want to load.
FIGURE 4-9 shows an example of selecting an Option file named SystemTest.defaults from the Option File Name menu.

FIGURE 4-9

Click the Load button.
After loading the Option file, the SunVTS Control Panel window displays the new Option values.

· To Remove an Option File

Press the MENU mouse button on the Option File Name menu button to display the available Option files.
Select the Option file you want to delete.
Click the Remove button.
After prompting you for confirmation, the Option file is deleted.