3 Diagnostics



This chapter provides an overview of the diagnostic tools available to you.

Diagnostic Overview

There are three types of diagnostics and a verification program available for troubleshooting the GT Graphics Subsystem, as follows:

Internal Self Test

Overview

To understand how the internal self test works, see Figure 3-1 and the explanation below.

Host CPU Openboot PROM

When the system unit is powered up, the Host CPU OpenBoot PROM runs a series of diagnostics, known as the system unit power-on self test (POST). The system unit POST, among other things, probes for a default frame buffer (in this case, the GT Graphics Subsystem). The CPU attempts to read address zero, the starting address for valid SBus openboot PROMs.

If the system unit POST gets the proper response from reading the SBus Adapter Board openboot PROM, it assumes a device is plugged into the slot. The CPU openboot PROM code then proceeds to move or copy the GT Openboot PROM FORTH code into CPU memory. If the system unit POST fails the probe, it halts and indicates an error on the four keyboard LEDs.

GT Internal Self Test PROM

The GT Graphics Subsystem has its own internal tests, which we refer to here as the internal self test. The internal self test is executed out of the GT Internal Self Test PROM (on the Graphics Processor Front End Board) when the Graphics Tower is powered on with the DIAG/NORM switch in the DIAG position (see "Running the Internal Self Test" on page 38).

    Figure 3-1 GT Graphics Subsystem from a Diagnostic Perspective

GT Openboot PROM

The GT OpenBoot PROM on the Graphics Processor Rendering Pipeline Board is used during the internal self test. The GT OpenBoot PROM has FORTH code routines for drawing and deleting characters on the GT monitor. When the GT system is the only frame buffer in the system or the first frame buffer the CPU finds when probing the SBus slots, the CPU Openboot PROM uses the GT Openboot PROM routines to establish a display device (/dev/console) for the user.

Running the Internal Self Test

When the Graphics Tower is powered-up with the diagnostic switch in the DIAG position, four LED indicators on the rear of the Graphics Tower indicate the diagnostic status of the GT Graphics Subsystem. Figure 3-2 shows the location of the diagnostic switch and indicators.

    Figure 3-2 Graphics Tower Diagnostic Switch and Indicators

To run the internal self test:

    1. Halt the system unit.

    See steps 1 through 5 of "System Power-Down" on page 72.

    2. Power down the Graphics Tower.

    Wait at least two minutes after powering down the Graphics Tower before powering up again. This gives the Graphics Tower time to reset.

Note - You do not have to power down the system unit nor do you have to disconnect the Host Adapter Cable (between the system unit and the GT Graphics Tower). Since the internal self test attempts to display patterns, the monitor should be connected to the GT Graphics Tower.

    3. Place the DIAG/NORM switch in the DIAG position.

    The switch is in the DIAG position when the bottom half of the switch is pressed in.

    4. Power up the Graphics Tower.
    5. Monitor the diagnostic indicators for a failure condition.

    See Table 3-1. The internal self test takes 4 minutes 45 seconds. Where two FRUs are indicated, the first FRU is the most-likely failure.

Resuming Normal Operation

To resume normal system operation following the internal self test:

    1. Place the DIAG/NORM switch in the NORM position.

    The switch is in the NORM position when the top half of the switch is pressed in. You do not have to cycle the power on the GT Graphics Tower.

    2. Recycle the power on the system unit.

    Power off the system unit, wait about two minutes, and power on the system unit.

    Table 3-1 Graphics Tower Diagnostic Indicators

LEDs m = OFF, l = ON Time 8 4 2 1 (Sec.) Display FRU Meaning

l l l l 6 Blank None Alternately flashing on and off three times - normal operation at the beginning of the test. m m m m 2 Blank FE Failed i860 self-test or 1/w lookup table test. m m m l 2 Blank FE Failed Local Data Memory (ROM-based) test. m m l m 2 Blank FE Failed Front End registers test. m m l l 2 Blank RP/FE Failed GT Openboot PROM checksum test. m l m m 11 Blank FE Failed copy from ROM to RAM or Local Data Memory (RAM-based) test. m l m l 2 Blank RP/FE Failed test of Front End Local Bus, Setup Processor, or Edge Walker or Pixel Bus Multiplexer register. m l l m 2 Blank FB/RP Failed test of Pixel Bus or Pixel Formatter registers. m l l l 2 Blank FB Failed test of Pixel Processor registers or Frame Buffer output section registers. l m m m 7 White FB Failed test of Frame Buffer cursor plane, monochrome access mode. l m m l 213 Figure 3-3 FB Failed test of WID LUTs, CLUTs, shadow RAM, image, depth, or window/fast clear/cursor plane memory. l m l m 4 Figure 3-3 RP Failed test of DSPs, IEEE-to-TI floating point converter, DSP 1/x table lookup, input/output FIFOs, or Setup Processor shared memory. l m l l 16 Figure 3-4 RP Failed test of Rendering Pipeline, accelerator path. Draws diagram on screen through Rendering Pipeline, using DSP0 then DSP1. l l m m 8 Figure 3-4 FB Failed checksum test of previous image in Frame Buffer image buffer A and depth plane. l l m l 2 Figure 3-4 None All tests pass. LEDs advance to next display. l l l m 2 Figure 3-4 None All tests pass. LEDs advance to next display. l l l l Figure 3-4 None All tests pass. Test done. Where: FE = Graphics Processor Front End, RP = Graphics Processor Rendering Pipeline, FB = Frame Buffer

When the internal self test is first started, the diagnostic indicators all flash on and off three times before the test sequence begins. Each test displays for a minimum of 2 seconds so you can observe the test progression.

If a monitor is attached, you can observe patterns as the tests progress. These patterns are shown in the following two figures. Figure 3-3 shows the eight blocks that display as the result of the Frame Buffer test of the plane groups. the screen will flicker and flash. This is normal.

    Figure 3-3 Console View of Plane Groups Test

Figure 3-4 shows the patterns displayed by the Rendering Pipeline and Frame Buffer tests. Wherever the colors Red, Green, and Blue are identified, they should be the pure RGB colors.

Three anti-aliased lines run diagonally from the upper left to the lower right. The line in the middle is red, the other two are green, Three non-anti-aliased lines run diagonally from the top right to the bottom left. These lines are red at one end and blue at the other, with all the blending colors in between.

There are four equilateral triangles. The top triangle is green and flat-shaded. The right triangle is a vertex-shaded, non-anti-aliased. The left and bottom triangles are vertex-shaded, anti-aliased.

There are four purple dots in the center of the intersections of the six lines.

    Figure 3-4 Console View of Patterns Tests

gtprobe Test

The gtprobe test is a standalone utility that checks for proper operation of the interface to the GT Graphics Subsystem. This test can be run from an attached auxiliary terminal, from a remote log in terminal, or from the system terminal.

This test performs the following operations:

    If the routine reaches the MIA test register, it writes test patterns to the register and reads one back for verification.

Note - This test must be run from an attached auxiliary terminal or from a remote log in terminal. If you can see anything on the attached system monitor, gtprobe probably won't find any problems.

The gtprobe command is as follows:

    gtprobe -v

      where -v is the verbose option which causes gtprobe to print several sequence messages in addition to the basic messages.

To run the gtprobe test:

    1. Become superuser.
    2. Type the following command:

    You should see a series of messages something like this:

    3. Check the messages to see that gtprobe has found the gt device.

    At start up, gtprobe prints all devices that are installed in each SBus slot (slots 1, 2, and 3). If gtprobe doesn't find a GT device, it will default to the first empty SBus slot.

    In the above example, the gt device is in SBus slot 1. If gtprobe found the SBus slot, accept the default (press Return). If gtprobe did not find the SBus slot, the GT openboot SBus probe sequence did not detect a GT device during boot time. Type the slot number you believe to have the SBus Adapter Board and press Return.

    If you accept the default and press Return, you should now see a series of messages something like this:

If you don't see the complete message, all the way to

    Done verifying the GT Openboot PROM's checksum.

gtprobe has found a problem. Analyze the messages to determine the nature of the problem, such as one of the following:

If you do see the complete message, gtprobe has passed without finding any errors.

SunDiag Diagnostics

The diagnostics described here can be run either as a stand-alone program or under the standard SunDiag. SunDiag probes the system kernel for installed hardware devices then displays a control panel with the devices it found.

The GT SunDiag diagnostics consist of a sequence of subtests that can accurately locate and identify failing FRUs. All tests are non-destructive and maintain the system integrity during and after the tests are run.

Caution - While running the SunDiag diagnostic, do not run a Pixrects application or any other application that uses the GT accelerator port. If you do, you will disturb the SunDiag tests, resulting in possible false errors.

Note - The GT SunDiag diagnostics requires approximately 1.5M bytes of disk space in the /tmp directory to extract its working files. If this space is not available, the diagnostic will fail and report warning and error messages indicating lack of disk space.

Test Operation

You can run SunDiag one of four ways:

Running SunDiag from SunView or OpenWindows

The following information is written with the assumption that you are familiar with the SunDiag On-line System Exerciser. If not, read the SunDiag User's Guide.

To start SunDiag:

    1. Become superuser.
    2. Type one of the following commands:

    For SunOS 4.x, type:

    For Solaris 2.x, type:

    Figure 3-5 shows an example SunDiag window (SunView version).

    Figure 3-5 The SunDiag Interface

    3. Look for the control panel on the right side of the SunDiag window.

    See Figure 3-6. SunDiag automatically probes for available devices. A check mark means that the device is enabled for testing. If the gt device is not shown, the GT Graphics Subsystem is not properly installed.

    Figure 3-6 The SunDiag Control Panel

    4. Press the option button for each device you want to test.

    To test the GT Graphics Subsystem, enable the "Graphics Tower GT0" test under "User Tests" on the SunDiag control panel. SunDiag 2.0.4 does not allow you to make sub-test selections for the GT diagnostics. By default, SunDiag runs all of the available tests, except the interactive tests. See "Test Descriptions" on page 53. The Graphics Tower tests take about 12 minutes to run, if run without any other tests.

    Subsequent versions of SunDiag will allow you to select specific tests by way of an Option button.

Note - To avoid excessive test cycle times when testing the GT Graphics Subsystem, follow these instructions:
1. Enable Single Pass on the SunDiag Options menu.
2. Enable Verbose on the SunDiag Options menu.
3. Do not select any other diagnostic tests.
Following this procedure will ensure that gttest will run once, report status as each test routine executes, and then exit.

    5. Press the Start button on the Control Panel to start testing.

    Error messages display in the console window (lower left corner of the interface menu). The SunDiag error messages are described on page 58.

Running SunDiag with the TTY Interface

The SunDiag tty interface lets you run SunDiag from a remote workstation over the network, or from a terminal attached to one of the system unit serial ports. See the SunDiag User's Guide.

To start SunDiag with the tty interface from SunOS 4.x:

To start SunDiag with the tty interface from Solaris 2.x:

Running SunDiag Tests with On-Line Commands

The GT system-level diagnostic program is gttest. You do not need to be superuser to run the tests from the command line. You do have to change to the sundiag directory.

Run the on-line command tests from the SunOS 4.x operating system as follows:

Run the on-line command tests from the Solaris 2.x operating system as follows:

Command Line Arguments

The gttest command accepts the following command line arguments:

D=device_path_name

    device_path_name is the full path name of the device under test. The default is /dev/gt0.

S=n

    n indicates the test number of the subtest to be run. Select from the subtests, on the next page. You can run multiple subtests by adding the subtest numbers. For example, n=0x3 runs both test 1 and test 2; n=0x180 runs both test 0x080 and test 0x0100. (Note that you do not need the leading zeros.) To run all tests, select n=0x7FFFF.

Test #
(Hex) Test Description 0x 000 001 Direct port - video memories. 0x 000 002 Direct port - CLUTs and WID LUT. 0x 000 004 Accelerator port - front end Local Data Memory. 0x 000 008 Accelerator port - setup processor shared memory. 0x 000 010 Accelerator port - rendering pipeline. 0x 000 020 Accelerator port - video memories. 0x 000 040 Accelerator port - Frame buffer output section. 0x 000 080 Integration test - vectors. 0x 000 100 Integration test - triangles. 0x 000 200 Integration test - spline curves. 0x 000 400 Integration test - viewport clipping. 0x 000 800 Integration test - hidden surface removal. 0x 001 000 Integration test - polygon edges highlighting. 0x 002 000 Integration test - transparency. 0x 004 000 Integration test - depth cueing. 0x 008 000 Integration test - lighting and shading. 0x 010 000 Integration test - text. 0x 020 000 Integration test - picking. 0x 040 000 Integration test - arbitration. 0x 080 000 Integration test - stereo (interactive). 0x 100 000 Integration test - light pen (interactive).
F=k

    k indicates the number of loops for each subtest. The default is 1 (one loop).

B=l

    l indicates the number of loops of each test sequence. The default is 1 (one loop).

On-Line Command Examples

Figure 3-7 shows three examples of SunDiag on-line commands.

    Figure 3-7 SunDiag On-Line Command Examples

Test Descriptions

Figure 3-8 shows an overview of the SunDiag tests. The subtests are run in the order shown in the figure. The subtests assume that the GT Graphics Subsystem has an active working interface with the SPARCstation CPU. If for any reason SunDiag cannot make the connection, further testing is not possible and SunDiag will report a fatal unrecoverable error.

The SunDiag error messages are described starting on page 58.

    Figure 3-8 SunDiag Overview

Direct Port Test

The direct ports tests check the non-accelerated portion of the GT.

Video Memory Array, Tested from Host

The video memory array test selects and tests all 64 by 64 pixrect regions covering the entire video memory planes, including the 2 by 8 alpha/overlay plane, 24-bit depth (Z buffer) plane, 10-bit WID plane, and two cursor planes. The planes are tested both as single-buffered and as double-buffered. The memory is tested with random patterns generated each time the test is started. If the test detects an error, SunDiag reports the defective plane and location.

CLUTs and WID LUT

This test performs a destructive read-write test on the Frame Buffer lookup tables. If the test detects a failure, SunDiag reports the location of the failure.

At the end of the test, red, green, and blue stripes display for approximately 30 seconds for visual verification of the digital-to-analog converters (DACs).

Accelerator Port Test

The accelerator port tests check the accelerated portion of the GT.

Front End Local Data Memory

This test checks the Graphics Processor Front End Board Local Data Memory. The Local Data Memory test is a non-destructive read-write memory test. This test aborts at the first error and reports a memory failure.

Setup Processor Shared Memory Test

The Setup Processor shared memory test verifies that the i860 microprocessor can write and read the setup processor shared memory without error.

Rendering Pipeline

The rendering pipeline tests checks each of the three rendering pipeline stages: setup processor, edge walker, span interpolator, and Pixel Bus Multiplexer. The Edge Walker and Span Interpolator tests are a series of small tests that verify the functionality of the edge walker and span interpolator ASICs in vectors, triangles, Gouraud shading, alpha blending, and anti-aliasing rendering. The results of the tests are verified by means of checksum values accumulated from data output by the Rendering Pipeline. SunDiag reports any subtest failures.

Video Memory Array, Tested from Front End

The video memory array can be accessed by the i860 microprocessor via the Local Bus. This is a destructive read-write test which verifies that all the Frame Buffer video memory locations are good. If the test detects an error, SunDiag reports the defective plane and location.

Frame Buffer Output Section

The Frame Buffer Output Section contains a diagnostic feedback register in the RAMDACs. The Frame Buffer Output Section test creates various windows in the Window ID plane then sets up the look-up tables (LUTs) associated with these values. The test then writes known values to the video memory of these windows. Next, the Frame Buffer is switched into trace mode, which reads the video through the diagnostic feedback register and puts the data into the shadow memory. Finally, the test compares the contents of the shadow memory with the expected values via checksum and determines if the Output Section is operating properly.

Integration Test

The integration test is a sequence of subtests running GT display list programs. These subtests ensure the GT Graphics Subsystem integrity at the system level. The subtests test all features of the hardware at the application level, reading the results from the Frame Buffer with Pixrect calls and verifying the results by comparing against known good images.

These tests use a frame buffer region of 1152 by 900 pixels, in the upper left corner of the screen, regardless of the size screen attached to the system. The tests use previously-generated test images for each color plane (red, green, and blue). These test images are stored in a reduced size (64 times the normal size) to save disk space.

Vectors Generation

This test renders fairly large vector objects with aliased, non-aliased, and shaded vectors.

Triangles Generation

This test renders objects with aliased, non-aliased shaded, and shaded triangles.

Spline Curves Generation

This test renders an object with both parametric and NURBS [1]) curves of different orders.

Viewport Clipping

This test renders and clips an object around and in front on the screen.

Hidden Surface Removal

This test renders objects with the Z-buffer-compare attribute turned on.

Polygons Edges Highlighting

This test renders an object with the edge highlighting attribute turned on.

Transparency

This test renders a scene with two transparency modes (standalone and alpha blend) in various degrees. This results in a two-pass transparency of the objects in the scene.

Depth-Cueing

This test renders an object with the depth-cueing attribute turned on.

Lighting and Shading

This test renders an object with multiple light sources and Gouraud shading for front and back surfaces.

Text Generation

This test generates diverse text lines with different attributes for checking.

Picking

This test has two parts: a pick detect test and a pick echo test.

Animation and Arbitration

This test renders a moving, double-buffered object into the image plane while a second SunOS process performs a read-write test to all planes of the direct port on the Frame Buffer. This test simulates conditions in the real world, where rendering processes and windows operation run concurrently.

Stereo (Interactive)

This test displays an object in stereo mode. The user verifies proper operation by looking at the screen with stereo glasses.

Light Pen (Interactive)

The user can draw and verify the light pen functionality on the screen.

SunDiag Error Messages

The GT SunDiag error messages are described below. The error messages are listed in alphabetical order.


8-BIT COLOR CLUT #n: Look up table error at index [color_index], write [value]. Suspect faulty HFB.

Failed the read-write of the Frame Buffer lookup tables. "#n" is the CLUT number. [color_index] is the color index value. [value] is a hexadecimal value. "HFB" is the GT Frame Buffer Board.


24-BIT COLOR CLUT #n: Look up table error at index [color_index], write [value]. Suspect faulty HFB.

Failed the read-write of the Frame Buffer lookup tables. "#n" is the CLUT number. [color_index] is the color index value. [value] is a hexadecimal value. "HFB" is the GT Frame Buffer Board.


Arbitration Test: Accelerator port drawing in double buffer mode, Direct Port Buffer [A or B] : Pixrect error at [address]. Suspect faulty HFB.

Failed the Arbitration integration test. [address] is the linear address of the bad memory cell. "HFB" is the GT Frame Buffer Board.


Arbitration Test: Accelerator port drawing in double buffer mode, Direct port simultaneous write to both buffers, read from buffer [A or B] : [plane_group] , Pixrect error at [address]. Suspect faulty HFB.

Failed the Arbitration integration test. [plane_group] is one of the following: Image plane A or B, Depth plane, WID plane, Cursor plane, or Fast Clear Plane A or B. [address] is the linear address of the bad memory cell. "HFB" is the GT Frame Buffer Board.


Background process wouldn't die. System error.

A software error. You may have to re-boot the SPARCstation.


Can't open display list file [filename]. Suspect incomplete or incorrect hardware installation. Files may also have been corrupted.

Indicates a software initialization problem. [filename] is the file that SunDiag can't open.


Can't open memory pixrect. Suspect incomplete or incorrect software installation.

A software error.


Can't read display list file [filename]. Suspect incomplete or incorrect hardware installation. Files may also have been corrupted.

Indicates a software initialization problem. [filename] is the display list file that SunDiag can't read.


Communication with Graphics Engine failed. Suspect incomplete or incorrect software installation. Front-End Firmware may also be dead.

SunDiag is unable to communicate with the GT Graphics Subsystem. A software error or hardware error with the GT SBus Adapter Board, HAC Cable, or Front End Board.


Cursor plane error: Failed with error code [code]: [failure]. Suspect faulty HGPFE.

Failed accelerator port video memory test. [code] is the error code number. [failure] is an explanation of the error indicated by [code]. "HGPFE" is the GT Front End Board.


Depth cueing: Error(s) found in [RED], [GREEN], [BLUE} components.

Failed the depth cueing integration test. Only the failing component (RED, GREEN, or BLUE) appears in the message.


Depth plane error: Failed with error code [code]: [failure]. Suspect faulty HGPFE.

Failed accelerator port video memory test. [code] is the error code number. [failure] is an explanation of the error indicated by [code]. "HGPFE" is the GT Front End Board.


Direct Port Buffer [A or B] : [plane_group], Pixrect error at [address]. Suspect faulty HFB.

Failed the direct port video memory test, tested from the host. [plane_group] is one of the following: Image plane A or B, Depth plane, WID plane, or Cursor plane. [address] is the linear address of the bad memory cell. "HFB" is the GT Frame Buffer Board.


Direct port simultaneous write to both buffers, read from buffer [A or B] : [plane_group], Pixrect error at [address]. Suspect faulty HFB.

Failed the direct port video memory test, tested from the host. [plane_group] is one of the following: Image plane A or B, Depth plane, WID plane, or Cursor plane. [address] is the linear address of the bad memory cell. "HFB" is the GT Frame Buffer Board.


Failed to allocate unique WID for 24-bit plane. Suspect incomplete or incorrect software installation.

A problem with system initialization.


Failed to enable the lightpen hardware. Lightpen support may not be present or the hardware may be completely unusable.

This message indicates an unknown problem with the lightpen. The lightpen test can not proceed.


Failed to fork a process. System error.

A software error. May have to re-boot the SPARCstation.


Failed to get monitor mode. Software error.

A software error. May have to re-boot the SPARCstation.


Failed to set diagnostic mode. Software error.

A software error. May have to re-boot the SPARCstation.


Failed to set monitor mode. Software error.

A software error. May have to re-boot the SPARCstation.


Fast Clear Plane [A or B] error: Failed with error code [code]: [failure]. Suspect faulty HGPFE.

Failed accelerator port video memory test. [code] is the error code number. [failure] is an explanation of the error indicated by [code]. "HGPFE" is the GT Front End Board.


Front End (Firmware) not responding. This may indicate that the Firmware has died. Try to run gtconfig.

A hardware problem. SunDiag was unable to communicate with the Front End Board. Indicates a problem with the SBus Adapter Board, HAC cable, or Front End Board.


Got XCPU interrupt, but user_mcb_ptr-trap_instruction = 0x#, expect 0x#. System software error.

A software error. May have to re-boot the SPARCstation.


Got XCPU interrupt, but it's not a trap instruction, error code = # : [message]. This may indicate that the Firmware has died. Try to run gtconfig.

A software error. [message] further describes the problem. May have to re- boot the SPARCstation.


Hidden Surface Removal: *** Error(s) found in [RED], [GREEN], [BLUE} components.

Failed the hidden surface removal integration test. Only the failing component (RED, GREEN, or BLUE) appears in the message.


hk_disconnect failed. System software error.

A software error. May have to re-boot the SPARCstation.


hk_munmap failed. System software error.

A software error. May have to re-boot the SPARCstation.


hk_open failed. GT system is either not initialized or not connected.

A software error. May have to re-boot the SPARCstation.


Image plane [A or B] error: Failed with error code [code]: [failure]. Suspect faulty HGPFE.

Failed accelerator port video memory test. [code] is the error code number. [failure] is an explanation of the error indicated by [code]. "HGPFE" is the GT Front End Board.


LDM error: Failed with error code [code]: [failure]. Suspect faulty HGPFE.

Failed the accelerator port test of the Front End Local Data Memory. [code] is the error code number. [failure] is an explanation of the error indicated by [code]. "HGPFE" is the GT Front End Board.


Lighting and Shading: *** Error(s) found in [RED], [GREEN], [BLUE] components.

Failed the lighting and shading integration test. Only the failing component (RED, GREEN, or BLUE) appears in the message.


Pick Detect misses: %d lines and/or %d triangles inside the pickbox and/or %d lines and triangles outside the pickbox.

Failed the Picking integration test. Only the failing component (RED, GREEN, or BLUE) appears in the message.


Pick Echo failed: *** Error(s) found in [RED], [GREEN], [BLUE} components.

Failed the Picking integration test. Only the failing component (RED, GREEN, or BLUE) appears in the message.


Picking: *** Error(s) found in [RED], [GREEN], [BLUE} components.

Failed the picking integration test. Only the failing component (RED, GREEN, or BLUE) appears in the message.


Poly Edges Highlighting: *** Error(s) found in [RED], [GREEN], [BLUE} components.

Failed the poly edges highlighting integration test. Only the failing component (RED, GREEN, or BLUE) appears in the message.


Rendering Pipeline error: Failed with error code [code]: [failure]. Suspect faulty HGPFE.

Failed the accelerator port Rendering Pipeline test. [code] is the error code number. [failure] is an explanation of the error indicated by [code]. "HGPFE" is the GT Front End Board.


Spline Curves: *** Error(s) found in [RED], [GREEN], [BLUE} components.

Failed the spline curves integration test. Only the failing component (RED, GREEN, or BLUE) appears in the message.


SU Shared RAM error: Failed with error code [code]: [failure]. Suspect faulty HGPFE.

Failed the accelerator port Rendering Pipeline Setup Processor shared RAM test. [code] is the error code number. [failure] is an explanation of the error indicated by [code]. "HGPFE" is the GT Front End Board.


System initialization failed. Suspect incomplete or incorrect software installation. Front-End Firmware may also be dead.

System initialization failed. Most likely a hardware problem with the GT Front End Board.


Texts: Error(s) found in [RED], [GREEN], [BLUE} components.

Failed the texts integration test. Only the failing component (RED, GREEN, or BLUE) appears in the message.


Transparency: *** Error(s) found in [RED], [GREEN], [BLUE} components.

Failed the transparency integration test. Only the failing component (RED, GREEN, or BLUE) appears in the message.


Triangles: *** Error(s) found in [RED], [GREEN], [BLUE} components.

Failed the triangles integration test. Only the failing component (RED, GREEN, or BLUE) appears in the message.


Unable to open /dev/gt#. Check device for existance and/or permission.

SunDiag is unable to open the GT device driver. Make sure that there is a /dev/gt0 device driver and that the permissions are correct.


Vectors: *** Error(s) found in [RED], [GREEN], [BLUE} components.

Failed the vectors integration test. Only the failing component (RED, GREEN, or BLUE) appears in the message.


Viewport Clipping: *** Error(s) found in [RED], [GREEN], [BLUE} components.

Failed the viewport clipping integration test. Only the failing component (RED, GREEN, or BLUE) appears in the message.


WID plane error: Failed with error code [code]: [failure]. Suspect faulty HGPFE.

Failed accelerator port video memory test. [code] is the error code number. [failure] is an explanation of the error indicated by [code]. "HGPFE" is the GT Front End Board.

GT Quicktest

The GT verification program, gt_quicktest, displays wireframe and polygon models within a window. It loads several models and displays them, either singly or in sequence.

To start the GT verification program:

    1. As superuser, type one of the following commands:

    For the Sun)S 4.x operating system, type:

    For the Solaaris 2.x operating system, type:

    The verification tool window will appear. See Figure 3-9.

    Figure 3-9 gt_quicktest window

    2. From the menu area at the top of the window, make the selection you want.

    The selections are described in Table 3-2.

    Table 3-2 gt_quicktest Menu Selections

Button Name Description Auto Cycle Displays each of the three objects for a few seconds at a time. Sun Logo Displays a Sun logo consisting of purple depth-cued polygons. The logo slowly rotates in a light blue background and appears to fade into a background fog. X29 Displays an X29 aircraft rotating on a light purple background. The X29 cockpit is transparent, the body is light gray, the tail cone is black, and the wings and stabilizer are either red or blue. F15 Displays a wireframe F-15 composed of anti-aliased vectors rotating very slowly against a black background. Help Displays a help screen with the information in this table. Quit Exits the gt_quicktest program.
    3. To exit the program, select "Quit" from the menu.