Key Users
  Product Detail
  Automated Brochure
  Automated Demos
  Press Releases
  Newsletter
  Brochure
  Testimonials
  Customers
  Analyst Reviews
  Live Demo Request
  ROI

 


 
 
 
    > Newsletter > September 2006 > Ask Al
 
   
 

Ask Al

Question #1
Occasionally when I power on a workstation with a Sun monitor attached, it just sits there with a blank screen. I hear the fans running and the system status LEDs come on but nothing displays on the monitor. Where do I begin troubleshooting something like this?

Answer:
If the Sun system console goes blank or video does not appear on the system console after POR (power-on reset), the most likely causes are:

  • bad monitor
  • bad video cable
  • bad video board
  • system has failed POST (Power-On-Self-Test)
  • bad keyboard

Narrowing down the possibilities can be a relativity simple process. The first step is to eliminate the video board, the video cable, the monitor, and the keyboard. These FRUs can be eliminated simply by connecting a dumb terminal to TTY A and unplugging the keyboard. If NVRAM parameters are set to the default state the system will run POST in verbose mode and direct all POST results to TTY A. At this point, POST results should stream out on the dumb terminal (9600 baud 8 bit one Stop bit no parity) connected to TTY A. If there are no printouts on TTY A:

  • verify that the power supply is operational
  • check all status LEDs on all boards

Most of the time you will see POST results scrolling on the dumb terminal screen. Under normal conditions the graphics card is one of the last things initialized in POST. If POST fails, then the Sun Graphics Card never gets initialized. This results in a blank system. Depending on the type of error, one of three things will occur:

  1. The system will boot and map out the defective component.
  2. The system will halt after POST and display an error message.
  3. The system will halt in POST displaying the last completed message.

When option three occurs use the On-Line! Detective to view the sample POST printout. This information is located at system level under the link for troubleshooting. Choose "Power-On-Self-Test (POST) Printout" so see a sample POST printout. On the sample printout, locate the last test displayed on the dumb terminal. Then look for the very next test. This is the test that failed. The Detective will help you interpret results of that test and suggest what components may be at fault.

In the On-Line! Detective, click on the Troubleshooting tab on the top navigation bar and select "Blank Screen" for comprehensive instructions on troubleshooting a blank screen.

Question #2
What is OpenBoot Diagnostics and how do I use it?

Answer:
OpenBoot Diagnostics is a menu-driven set of diagnostics residing in the Flash PROM. In addition to having POST (Power-On Self-Test), many systems also offer this set of low level user diagnostic tools that allow the user to run specific tests from the Forth ToolKit (ok prompt).

OpenBoot Diagnostics can be very useful in determining root-cause failure on many major components by testing internal registers, confirming subsystem integrity, and verifying device functionality. OpenBoot Diagnostics are only available at the ok prompt and none of the tests will write to and damage the file system. OpenBoot Diagnostics tests the System Board and its different interfaces. Depending of the type and configuration of your system, OpenBoot Diagnostics can help isolate errors in the following system components:

  • Onboard IDE
  • Onboard Fibre Channel
  • TOC Logic
  • PCI Controllers and Peripheral Boards
  • I/O Registers
  • Power Management Controller
  • Environmental sensor
  • System Board (Motherboard)
  • RSC hardware
  • DVD-ROM drive
  • Hard Disk Drive
  • Any PCI card that contains an Onboard self-test on the System Board
  • PCI boards
  • Onboard SCSI
  • Onboard Ethernet
  • Onboard Serial Port
  • Onboard Parallel Port
  • Onboard USB Port

Not all systems offer OpenBoot Diagnostics. If OpenBoot Diagnositics are available, they will be listed in the On-Line! Detective under the system's troubleshooting module.

Displaying OpenBoot Diagnostics Error Messages

Most current versions of OpenBoot Diagnostics use the OpenBoot configuration variable test-args to set keywords to define reporting controls for diagnostic and error messages. This can be very useful in determining the root cause of a failure. When running OpenBoot Diagnostics for extended periods set the error-N variable to a high number so the diagnostics will continue running even if it detects an error. This helps in diagnosing multiple faults and intermittent errors. Also it is best to set the "verbose" switch. This will display more information about the test and failure.

Below is a list of commonly used keywords.

  • debug - provides all debug messages
  • silent - suppresses diskplay of test name
  • verbose - provides detailed test status messages
  • callers=N - sets the number of backtrace callers reported
  • errors=N - sets the number of errors reported before testing is terminated

The following is an example of how to use the variable test-args:
ok setenv test-args verbose,debug,errors=0

Triggering OpenBoot Diagnostics to Run

When a system panics or halts because of a system failure, OpenBoot Diagnostics can be triggered to run rather than automatically rebooting the system. Specific types of reset events can trigger OpenBoot Diagnostics by setting the values of the variables diag-switch? and diag-trigger, as shown below. The diag-level and diag-script must be set to any valid value other than none. Setting the diag-script variable determines which tests are run at the reset event specified by diag-trigger. Valid settings for diag-script are:

  • normai - test all devices shipped with a base system.
  • all - executes all available self-tests, including tests on plug-in cards.
  • none - no diagnostic self-tests are run.

Starting OpenBoot Diagnostics

For most systems follow the procedure below to start running OpenBoot Diagnostics

Note: You cannot run OpenBoot Diagnostics reliably after halting or aborting the operating system with the Stop-A keyboard command (or an equivalent abort key sequence). Therefore, in order to access the ok prompt and run OpenBoot Diagnostics, you must set the OpenBoot configuration variable auto-boot? to false and reset the system.

The following parameters should be set before attempting to run OpenBoot Diagnostics:

1.Set the manufacture mode variable to on. At the ok prompt, type:

ok setenv mfg-mode on

2. Set the diagnostic variable to "true", type:

ok setenv diag-switch? true

3. Set the auto boot variable so the system does not automatically boot into Solaris, type:

ok setenv auto-boot? false

4.Reset the system so the new settings take effect, type:

ok reset-all

5. When the system console returns to the ok prompt type:

ok obdiag

6. When the OpenBoot Diagnostics menu and obdiag> prompt appear, set the configuration variables. If diag-level is set to off, OpenBoot Diagnostics returns a passed status for all tests, but no testing is performed. The following example shows how to set the value for the variable diag-level, which specifies the level of testing performed:

obdiag> setenv diag-level max

7. To execute one or more tests, enter the appropriate OpenBoot Diagnostics menu command and test numbers at the obdiag> prompt. The following example shows the except command, which allows you to execute all tests except those tests you specify in the command:

obdiag> except 3, 4

The On-Line! Detective Troubleshooting Module gives detailed information of how to run OpenBoot Diagnostics via the RSC Console, from the keyswitch and from the command line. The On-Line! Detective also gives a detailed description of each test and test requirements (loop backs, ect.). The Detective has a screen capture of each of the test and it's normal response.

Even if you don't have a machine or can't take the system down that has OpenBoot Diagnostics you can become very proficient at using OpenBoot Diagnostics just by reviewing the OpenBoot Diagnostics Module under the Troubleshooting tab.

Do you have a question you'd like to see answered in a future issue of eKnowledge? Email Allen at: askal@stsolutions.com