SGI TPL (Hardware: End-User/Prism_Desk_UG - Chapter 4. Troubleshooting and Diagnostics)

Hardware » Books » End-User »
Silicon Graphics Prism Deskside Visualization System Hardware User's Guide
(document number: 007-4772-002 / published: 2005-11-09) table of contents | additional info | download
find in page

Chapter 4. Troubleshooting and Diagnostics
Prev		Next

Chapter 4. Troubleshooting and Diagnostics

If you are experiencing problems with your Silicon Graphics Prism Deskside visualization system, please review the material in this chapter. If you are unable to resolve the problem, contact your service provider as follows:

If you are located in North America, contact the Customer Support Center at 1-800-800-4SGI. SGI personnel will guide you through the troubleshooting process.
If you are located outside of North America, contact your local SGI subsidiary or authorized distributor.

This chapter includes the following sections:

General Troubleshooting

This section covers the following topics:

Environmental Fault Monitoring

The system monitors its environment to ensure proper operation. It will automatically power off if any of the following faults are found:

Any fan spins at less than 80% of nominal speed.
Any temperature sensor registers 158° F (70° C) or above.
Any voltage reaches +/- 20% of nominal.

If your system is powering off unexpectedly, check for these conditions.

Troubleshooting Chart

Table 4-1 lists recommended actions for problems that can occur on your system. For problems that are not listed in this table, use the SGI Electronic Support system to help solve your problem or contact your SGI system support engineer (SSE). More information about the SGI Electronic Support system is provided later in this chapter.

Table 4-1. Troubleshooting Chart

Problem Description	Recommended Action
The system will not power on.	Ensure that the power cord is seated properly in the power receptacle. Ensure that any receptacle circuit breaker is on. If the power cord is plugged in and the circuit breaker is on, contact your SSE.
The system will not boot the operating system.	Check the L1 boot error codes listed in Table 4-3 . Contact your SSE as needed.
The red service-required LED illuminates.	View the L1 display of the failing system; see Table 4-2 for a description of the error message.
The PWR LED of a populated PCI slot is not illuminated.	Reseat the PCI card and reboot the system.
The fault LED of a populated PCI slot is illuminated.	Reseat the PCI card and reboot the system. If the fault LED remains on, replace the PCI card.
The amber LED of a disk drive is illuminated.	Replace the disk drive.

L1 Controller Error Messages

Table 4-2 lists error messages that the L1 controller generates and displays on the L1 display. This display is located on the front of the deskside system. For serial number related errors, check with your service provider for documentation on prevention and solutions.

The serial number error messages listed at the end of Table 4-2 can come across the L1 console from the L1 log. Obtain the contents by using the log command from an L1 prompt.

Actions that could cause serial number error messages include:

Replacing the interface board of a system.

L1 NVRAM memory failure.

Note: In Table 4-2, a voltage warning occurs when a supplied level of voltage is below or above the nominal (normal) voltage by 10 percent. A voltage fault occurs when a supplied level is below or above the nominal voltage by 20 percent.

Table 4-2. L1 Controller Messages

L1 System Controller Message	Message Meaning and Action Needed
Internal voltage messages:
ATTN: x.xV high fault limit reached @ x.xxV	30-second power-off sequence for the module.
ATTN: x.xV low fault limit reached @ x.xxV	30-second power-off sequence for the module.
ATTN: x.xV high warning limit reached @ x.xxV	A higher than nominal voltage condition is detected.
ATTN: x.xV low warning limit reached @ x.xxV	A lower than nominal voltage condition is detected.
ATTN: x.xV level stabilized @ x.xV	A monitored voltage level has returned to within acceptable limits.
Fan messages:
ATTN: FAN # x fault limit reached @ xx RPM	A fan has reached its maximum RPM level. The ambient temp may be too high. Check for failed fans.
ATTN: FAN # x warning limit reached @ xx RPM	A fan has increased its RPM level. Check the ambient temperature. Check to see if the fan stabilizes.
ATTN: FAN # x stabilized @ xx RPM	An increased fan RPM level has returned to normal.
ATTN: TEMP # advisory temperature reached @ xxC xxF	The ambient temperature at the module's air inlet has exceeded 30º C.
ATTN: TEMP # critical temperature reached @ xxC xxF	The ambient temperature at the module's air inlet has exceeded 35º C.
ATTN: TEMP # fault temperature reached @ xxC xxF	The ambient temperature at the module's air inlet has exceeded 40º C.
Temperature messages: high alt.
ATTN: TEMP # advisory temperature reached @ xxC xxF	The ambient temperature at the module's air inlet has exceeded 27º C.
ATTN: TEMP # critical temperature reached @ xxC xxF	The ambient temperature at the module's air inlet has exceeded 31º C.
ATTN: TEMP # fault temperature reached @ xxC xxF	The ambient temperature at the module's air inlet has exceeded 35º C.
Temperature stable message:
ATTN: TEMP # stabilized @ xxC/xxF	The ambient temperature at the module's air inlet has returned to an acceptable level.
Power off messages:
Auto power down in xx seconds	The L1 controller has registered a fault and is shutting down. The message displays every five seconds until shutdown.
Base module appears to have been powered down	The L1 controller has registered a fault and has shut down.
Serial number messages:
Invalid System Serial Number format	See L1 log for details.
No assigned System Serial Number	See L1 log for details.

Under certain circumstances a system software or hardware error can occur prior to the graphics console's ability to display information. In this case you can see the error only on the L1 controller panel or from an optional system console connected to the Console serial port on the back of the system. In these cases an error message is displayed on the L1 display of the form <geoid> ERR <error code> or <geoid> POD <error code>. Most of the time, these errors indicate a serious problem and customer service should be called (please provide the error code to the service representative). See Table 4-3 for a partial list of the L1 Hexadecimal boot error codes.

Table 4-3. L1 Controller Hexadecimal Boot Error Codes

Error code	Message Meaning or Action Needed
0x80	The unit has no DIMM memory - insure that DIMM group 0 is fully populated. See the information in “Installing or Removing a Memory DIMM” in Chapter 3 .
0x81	Write to system controller timed out.
0x82	Request for system reset failed.
0x83	Local master arbitration failed.
0x84	No memory available to allocate hardware configuration structure.
0x85	Can't initialize `klconfig`.
0x87	Disabled by environment variable.
0x88	Call to unimplemented chip specific function.
0x89	System controller communication initialization failed.
0x8b	Nasid assignment failed.
0x8c	Route calculation failed.
0x8d	Critical system controller transaction failed.
0xb0	PAL early self test failed.
0xb1	SAL entered with invalid function code.
0xb2	SAL invoked for firmware recovery.
0xb3	SAL_RESET called with bad parameters.
0xb4	main () returned.
0xb5	PAL_CACHE_INFO failed looking for cache to reload.
0xb6	Cache preloading PAL call failed.
0xb7	Scratch area overflowed the CPU's caches.
0xb8	PAL_MEM_FOR_TEST failed.
0xb9	Bad address calculated for PAL_TEST_PROC
0xba	PAL_COPY_INFO failed.
0xbb	Bad PAL shadow address calculated.
0xbc	PAL_COPY_PAL failed.
0xbd	SDA transfer area overflowed.
0xbe	No PROM segment (e.g. EFI) found.
0xbf	PROM segment (e.g. EFI) exited.
0xc0	Out of SAL->EFI handoff memory.
0xc1	Cache tests failed.
0xc2	Error flashing PROM.
0xc3	Could not write new value to cr.lid.
0xd8	This unit has illegal DIMM population. Check and replace memory, see “Installing or Removing a Memory DIMM” in Chapter 3 .
0xf0	Waiting for primary lock.

Reading Power Supply Status LEDs

Use the LED located on the rear of the power supply to read the condition of the power supply. Table 4-4 shows the LED status and the power supply condition the LED status indicates.

Table 4-4. LED Status and Power Supply Condition

LED Status	Power Supply Condition Indicated
Off	An unlit LED indicates that the power supply is not receiving AC power. Power supplies will not be receiving AC power because either the module is not plugged into power, or an electrical fuse has blown.
Amber	Indicates a fault condition for one of the following reasons: - The voltage limit has been exceeded. - The temperature limit has been exceeded. - The current limit has been exceeded.
Blinking Green	The power supply is receiving AC power, but the main primary DC power has not yet activated.
Green	The power supply is operating properly.

SGI Electronic Support

SGI Electronic Support provides system support and problem-solving services that function automatically, which helps resolve problems before they can affect system availability or develop into actual failures. SGI Electronic Support integrates several services so they work together to monitor your system, notify you if a problem exists, and search for solutions to the problem.

Figure 4-1 shows the sequence of events that occurs if you use all of the SGI Electronic Support capabilities.

Figure 4-1. Full Support Sequence Example

The sequence of events can be described as follows:

Embedded Support Partner (ESP) monitors your system 24 hours a day.
When a specified system event is detected, ESP notifies SGI via e-mail (plain text or encrypted).
Applications that are running at SGI analyze the information, determine whether a support case should be opened, and open a case if necessary. You and SGI support engineers are contacted (via pager or e-mail) with the case ID and problem description.
SGI Knowledgebase searches thousands of tested solutions for possible fixes to the problem. Solutions that are located in SGI Knowledgebase are attached to the service case.
You and the SGI support engineers view and manage the case by using Supportfolio Online as well as search for additional solutions or schedule maintenance.
The solution is implemented.

Most of these actions occur automatically, and you may receive solutions to problems before they affect system availability. You also may be able to return your system to service sooner if it is out of service.

In addition to the event monitoring and problem reporting, SGI Electronic Support monitors both system configuration (to help with asset management) and system availability and performance (to help with capacity planning).

The following three components compose the integrated SGI Electronic Support system:

SGI Embedded Support Partner (ESP) is a set of tools and utilities that are embedded in the operating system. ESP can monitor a single system or group of systems for system events, software and hardware failures, availability, performance, and configuration changes, and then perform actions based on those events. ESP can detect system conditions that indicate potential problems, and then alert appropriate personnel by pager, console messages, or e-mail (plain text or encrypted). You also can configure ESP to notify an SGI call center about problems; ESP then sends e-mail to SGI with information about the event.

SGI Knowledgebase is a database of solutions to problems and answers to questions that can be searched by sophisticated knowledge management tools. You can log on to SGI Knowledgebase at any time to describe a problem or ask a question. Knowledgebase searches thousands of possible causes, problem descriptions, fixes, and how-to instructions for the solutions that best match your description or question.

Supportfolio Online is a customer support resource that includes the latest information about patch sets, bug reports, and software releases.

The complete SGI Electronic Support services are available to customers who have a valid SGI Warranty, FullCare, FullExpress, or Mission-Critical support contract. To purchase a support contract that allows you to use the complete SGI Electronic Support services, contact your SGI sales representative. For more information about the various support contracts, see the following website:

http://www.sgi.com/support/customerservice.html

For more information about SGI Electronic Support, see the following website:

http://www.sgi.com/support/es

Diagnostics

The Silicon Graphics Prism Deskside visualization system is equipped with diagnostics to test the system hardware and diagnose component/part failures. These diagnostics are grouped into the following categories:

Power-on diagnostics (POD)
Power-on diagnostics are PROM-resident tests that run automatically when you power on the system. As the boot process discovers hardware components, it runs power-on diagnostics to verify that each component that is needed to boot the system is working correctly. Refer to “Power-on Diagnostics” for more information about POD.
Online diagnostics
Online diagnostics are tests that verify system hardware while the operating system is running. To prevent data loss, you should use the online diagnostics only when the system is idle. Refer to “Online Diagnostics ” for more information.

All diagnostics are loaded on your system when you receive it. To upgrade to future revisions of the diagnostics, download the appropriate Customer Diagnostics package from Supportfolio (http://support.sgi.com ). Contact your service representative for more information.

Note: The diagnostics described in this document run only on Silicon Graphics Prism visualization systems. They will not work on any other SGI systems.

Power-on Diagnostics

The power-on diagnostics run automatically when you power on or reset the system. As the boot process discovers hardware, it verifies that each component is functional enough to load the operating system.

The power-on diagnostics test the hardware in the following order:

CPU
Super Hub (SHub) ASIC
PROM
Memory DIMMs
Secondary cache
TIO ASICs
PCI slots
Serial ports
Serial Advanced Technology Attach (SATA) controller
Graphics pipe(s)

If the power-on diagnostics complete successfully, the system automatically boots, depending on how the system is configured.

If the power-on diagnostics detect errors, the diagnostics disable the failing hardware and continue testing. When testing completes, the system may or may not be able to boot, depending on the hardware that has been disabled. If the system does not boot, contact your service representative.

Online Diagnostics

Caution: The runalldiags script should be run while the system is idle. If you run the online diagnostics while the system is in use, data may be lost.

Online diagnostics are tests that verify system hardware while the operating system is running. When you run the online diagnostics from the Linux operating system prompt, each diagnostic runs a set of tests for a certain number of loops. The online diagnostics test the following areas of the system:

CPU
Memory
I/O
Graphics
Storage devices
Network devices

The online diagnostics also run a system stress test, which tests all areas of the system under heavy load.

The runalldiags script automatically runs a sequence of online diagnostics. It runs in three modes:

Basic mode verifies memory and performs 30 minutes of stress testing. (If you want to perform regularly scheduled testing, use basic mode.)
Normal mode performs the same tests as basic mode and also performs I/O testing. (The I/O testing may disrupt any serial port devices.)
Extensive mode performs more disruptive I/O testing. (Ethernet is unavailable.) It also performs more intensive CPU, memory, and stress testing. Use this mode only if you suspect there is a problem with the system.

Follow these steps to run the runalldiags script:

Note: You must have root level access to the system to run online diagnostics.

Enter the following command at the Linux command prompt to change to the directory that contains the diagnostics:
#>cd /usr/diags/bin

Enter the following command to start the script:
#>./runalldiags [options]

Note: When you run runalldiags in -normal or -extensive modes, you should run it from the console. The Ethernet testing that runalldiags performs in -normal and -extensive modes disrupts any telnet sessions on the system.

Refer to Table 4-5 for descriptions of the command-line options.

Table 4-5. runalldiags Command-line Options

Option	Description
`-h \| -help`	Displays help information
`-basic`	Runs the script in basic mode
`-normal`	Runs the script in normal mode (default)
`-extensive`	Runs the script in extensive mode
`-host <host>`	Specifies a system to target for network tests
`-d <directory>`	Specifies the directory that contains the online diagnostics

If a diagnostic fails, the script saves the output from the diagnostic in a file in the /tmp directory (for example, /tmp/diagTestOutput.1.olenet). Output from the script indicates the actual name of the file. When a diagnostic fails, the script continues to run the remaining diagnostics.

Online diagnostics display PASS [testname] when a test passes and FAIL [testname] when a test fails. If any of the components do not pass the online diagnostics, contact your service representative. The following two examples show a successful and unsuccessful diagnostic.

Example 1: A Successful Execution

[root@snapper bin]# ./runalldiags -basic
Using /lib/modules/2.4.21-sgi305a8/kernel/arch/ia64/sn/io/drivers/pciba.o
Warning: loading /lib/modules/2.4.21-sgi305a8/kernel/arch/ia64/sn/io/drivers/pciba.o will taint the kernel: no licenseSee http://www.tux.org/lkml/#export-tainted for information about tainted modules
Module pciba loaded, with warnings
Running online diagnostics at Basic level
Time: Tue Mar 17 08:02:51 CST 2005
System Information: Linux snapper.americas.sgi.com 2.4.21-sgi305a8 #1 SMP Fri Dec 17 22:44:01 PST 2004 ia64 ia64 ia64 GNU/Linux
Plan on running: torpedo olcmt pandora
torpedo - CPU Floating Point Unit Diagnostic
PASS(torpedo)
olcmt - Cache/Memory Test    (Check /var/log/messages for error message)
PASS(olcmt)
pandora - System Stress Test
PASS(pandora)
Finished running at Tue Mar 17 08:47:14 CST 2005
Ran: 3  Failed: 0

Example 2: An Unsuccessful Execution

[root@snapper bin]# ./runalldiags -basic
Using /lib/modules/2.4.21-sgi305a8/kernel/arch/ia64/sn/io/drivers/pciba.o
Warning: loading /lib/modules/2.4.21-sgi305a8/kernel/arch/ia64/sn/io/drivers/pciba.o will taint the kernel: no license
  See http://www.tux.org/lkml/#export-tainted for information about tainted modules
Module pciba loaded, with warnings
Running online diagnostics at Basic level
Time: Tue Mar 17 09:00:00 CST 2005
System Information: Linux snapper.americas.sgi.com 2.4.21-sgi305a8 #1 SMP Fri Dec 17 22:44:01 PST 2004 ia64 ia64 ia64 GNU/Linux
Plan on running: torpedo olcmt pandora
torpedo - CPU Floating Point Unit Diagnostic
PASS(torpedo)
olcmt - Cache/Memory Test    (Check /var/log/messages for error message)
PASS(olcmt)
pandora - System Stress Test
FAIL(pandora): see /tmp/diagFailure.0.pandora
Finished running at Tue Mar 17 09:44:17 CST 2005
Ran: 2  Failed: 1

XF86Config File Changes

The following sections provide information about customizing the XF86Config file for various special configurations.

Important: When using a compositor, you must always connect the graphics output cable to the left side (as viewed from the rear of the system) graphics connector.

Configuring a System for Stereo

This section describes how to configure a system to display stereo images.

Stereo sync is supported only on systems using optional ImageSync boards.

Note: Simultaneously running stereo and full scene anti-aliasing can require more graphics-card memory than is available, and thus may not always work correctly.

Note: Stereo may be enabled on either channel of a pipe, but may not be enabled on both channels simultaneously.

Create a copy of the XF86Config file to be customized for stereo:
# cp /etc/X11/XF86Config /etc/X11/XF86Config.Stereo
Edit the XF86Config.Stereo file to include the following line at the end of each “Device” section:
Option "Stereo" "1" Option "StereoSyncEnable" "1"
(see the “Example “Device” Section for Stereo”).
Edit the new XF86Config.Stereo file to include the appropriate stereo modes in the “Monitor” section:
1. Create an appropriate mode (see “Sample Stereo Mode Entries”).
2. Add that mode to the “Monitor” section of your XF86Config.Stereo file (see the “Example “Monitor” Section for Stereo”).
  
  Note: “Mode” and “Modeline” are two alternative formats used to present the same information.
Ensure that the monitor supports the high horizontal sync rate setting. Refer to the documentation for the monitor to determine the horizontal sync rate. Modify the HorizSync setting in the “Monitor” section of the XF86Config.Stereo file. For example:
HorizSync 22-105
Modify the “Screen” section so that you use the appropriate mode setting. For example:
Modes "1280x1024@96"
(see the “Example “Screen” Section for Stereo”).
Make a backup copy of the default /etc/X11/gdm/gdm.conf file:
# cp /etc/X11/gdm/gdm.conf /etc/X11/gdm/gdm.conf-old
Edit the /etc/X11/gdm/gdm.conf file to use the new XF86Config.Stereo file you created:

Replace the line:
command=/usr/X11R6/bin/X
with:
command=/usr/X11R6/bin/X -xf86config /etc/X11/XF86Config.Stereo
Save the gdm.conf file and reboot the system to restart graphics in stereo mode.

Note that a stereo sync signal will not be present until you run a stereo application. One such application is ivview. If your system has ivview installed, you can use it to test the stereo configuration by running:
ivview /usr/share/data/models/X29.iv
and right click to activate the stereo setting on the preferences panel.

Example “Device” Section for Stereo

Section "Device"
    Identifier  "SGI SG-0"
    Driver      "fglrx"
    BusId       "PCI:23:0:0"
# === QBS Management ===
    Option "Stereo"           "1"
    Option "StereoSyncEnable" "1"
EndSection

Sample Stereo Mode Entries

Modeline "1024x768@96" 103.5  1024 1050 1154 1336  768 771 774 807
Modeline "1280x1024@96" 163.28  1280 1300 1460 1600  1024 1027 1033 1063
Modeline "1024x768@100" 113.309 1024 1096 1208 1392 768 769 772 814
Modeline "1024x768@120" 139.054 1024 1104 1216 1408 768 769 772 823 +hsync +vsync
Modeline "1280x1024@100" 190.960 1280 1376 1520 1760 1024 1025 1028 1085 +hsync +vsync
Mode "1280x1024_96s_mirage"
    DotClock       152.928
    HTimings       1280 1330 1390 1500
    VTimings       1024 1026 1030 1062
EndMode

Example “Monitor” Section for Stereo

Section "Monitor"
    Identifier  "Stereo Monitor"
    HorizSync   30-96      # multisync
    VertRefresh 50-160     # multisync
    Modeline "1024x768@96" 103.5  1024 1050 1154 1336  768 771 774 807
EndSection

Example “Screen” Section for Stereo

Section "Screen"
    Identifier          "Screen SG-0"
    Device              "SGI SG-0"
    Monitor             "Stereo Monitor"
    DefaultDepth         24
    SubSection          "Display"
        Depth   24
        Modes   "1280x1024@96"
    EndSubSection
EndSection

Configuring a System for Full Scene Anti-Aliasing

This section describes how to configure a system for global or per-window full scene anti-aliasing.

Note: Simultaneously running stereo and full scene anti-aliasing can require more graphics-card memory than is available, and thus may not work correctly.

Create a copy of the XF86Config file to be customized for full scene anti-aliasing:

# cp /etc/X11/XF86Config /etc/X11/XF86Config.AntiAlias

Note: Automatically-generated XF86Config files should contain the customized multi-sample positions shown in “Example “Device” Section for Full Scene Anti-Aliasing”. If these values are not already present, adding them can significantly improve the quality of your output.

Edit the new XF86Config.AntiAlias file to include the following line at the end of each “Device” section:

Option "FSAAScale" “X”

where X is 1, 2, 4, or 6 (see the example “Device” section “Example “Device” Section for Full Scene Anti-Aliasing”).

Note: Per-window full scene anti-aliasing is accomplished by setting “FSAAScale” to 1. The anti-aliasing level may then be set by the appropriate selection of visuals.
Global anti-aliasing is accomplished by setting “FSAAScale” to 2, 4, or 6. In this case, the setting will apply to all OpenGL windows, regardless of the visual being displayed.

Make a backup copy of the default /etc/X11/gdm/gdm.conf file:
# cp /etc/X11/gdm/gdm.conf /etc/X11/gdm/gdm.conf-old
Edit the /etc/X11/gdm/gdm.conf file to use the new XF86Config.AntiAlias file you created:

Replace the line:
command=/usr/X11R6/bin/X
with:
command=/usr/X11R6/bin/X -xf86config /etc/X11/XF86Config.AntiAlias
Save the gdm.conf file:
Restart graphics: # <CTRL> <ALT> <BKSPC>

Example “Device” Section for Full Scene Anti-Aliasing

Section "Device"
    Identifier  "SGI SG-0"
    Driver      "fglrx"
    BusId       "PCI:23:0:0"
# === FSAA Management ===
    Option "FSAAScale"                  "1"
    Option "FSAADisableGamma"           "no"
    Option "FSAACustomizeMSPos"         "yes"
    Option "FSAAMSPosX0"                "0.250000"
    Option "FSAAMSPosY0"                "0.416666"
    Option "FSAAMSPosX1"                "0.083333"
    Option "FSAAMSPosY1"                "0.083333"
    Option "FSAAMSPosX2"                "0.416666"
    Option "FSAAMSPosY2"                "0.750000"
    Option "FSAAMSPosX3"                "0.750000"
    Option "FSAAMSPosY3"                "0.916666"
    Option "FSAAMSPosX4"                "0.583333"
    Option "FSAAMSPosY4"                "0.250000"
    Option "FSAAMSPosX5"                "0.916666"
    Option "FSAAMSPosY5"                "0.583333"
EndSection

Configuring a System for Dual-Channel Operation

To configure a system for dual-channel operation, follow the steps in this section.

Note: If any pipes managed by an X server have their second channel enabled, then every pipe managed by that X server must have its second channel enabled.

Note: Both channels on a pipe must have the same display resolution.

Create a copy of the XF86Config file to be customized for dual-channel operation:
# cp /etc/X11/XF86Config /etc/X11/XF86Config.DualChannel
Edit the new XF86Config.DualChannel file to include the following line at the end of each “Device” section:
Option "DesktopSetup" mode
where mode is one of the following:
"0x00000100" [this mode clones the managed area] "0x00000200" [this mode scales the managed area by 2 horizontally] "0x00000300" [this mode scales the managed area by 2 vertically]
(see “Example “Device” Section for Dual Channel”).

Note: All pipes managed by the same X server must be set to the same mode.
When using monitors or monitor cables which do not conform to the VESA Display Data Channel (DDC) standard, append the following entry in the “Device” section to enable proper display configuration:
Option "NoDDC" "on"
Make a backup copy of the default /etc/X11/gdm/gdm.conf file:
# cp /etc/X11/gdm/gdm.conf /etc/X11/gdm/gdm.conf-old
Edit the /etc/X11/gdm/gdm.conf file to use the new XF86Config.DualChannel file you created:

Replace the line:
command=/usr/X11R6/bin/X
with:
command=/usr/X11R6/bin/X -xf86config /etc/X11/XF86Config.DualChannel
Save the gdm.conf file:
Restart graphics:

# <CTRL> <ALT> <BKSPC>

Example “Device” Section for Dual Channel

Section "Device"
    Identifier  "SGI SG-0"
    Driver      "fglrx"
    BusId       "PCI:23:0:0"
    Option      "DesktopSetup" "0x00000200"
EndSection

Enabling Overlay Planes

To enable overlay planes, follow these steps:

Note: The option to enable overlay planes only applies to the first channel on the pipe.

Edit the /etc/X11/XF86Config file to include the following line in each “Device” section for which you want overlay planes enabled:
Option "OpenGLOverlay" "On"
Log out from the desktop, then log back in.

Example “Device” Section to Enable Overlay Planes

Section "Device"
    Identifier  "SGI SG-0"
    Driver      "fglrx"
    BusId       "PCI:23:0:0"
    Option      "OpenGLOverlay" "On"
EndSection

Configuring a System for External Genlock or Framelock

External genlock and framelock may be used on systems with at least one optional ImageSync board.

To configure your system to receive an external genlock or framelock signal you must run the setmon command with the appropriate options.

Before running setmon, use printenv DISPLAY to ensure that the DISPLAY environment variable is set to the local system (for example, :0.0). If it is not, use setenv DISPLAY :0.0 to change it (substituting other numbers for :0.0 if appropriate).

To set the system for genlock, execute the following command:

# setmon -ppipenumber -g graphicsformat

where pipenumber is the pipe to which this setting should be applied, and
graphicsformat is one of the timings (modes) listed in the “Monitor” section of the /etc/X11/XF86Config file.

To set the system for framelock, execute the following command:

# setmon -ppipenumber -Lvideoformat  graphicsformat

where pipenumber is the pipe to which this setting should be applied,
videoformat is the input video format to be used as a framelock source, and
graphicsformat is one of the framelock-certified timings (modes) listed in the “Monitor” section of the /etc/X11/XF86Config file that is compatible with the chosen input video format (Table 4-6 provides a list of compatible formats).

Note: The default behavior of setmon is to load the new format for the current session only and to prompt for input to determine if the format should be saved as the default. To save the new format as the default you must be logged in as root.

For more information about the setmon command, see the setmon man page (man setmon).

Note: Framelock-certified timings will include an “f” appended to their name (i.e., “1280x1024_5994f” is certified for NTSC (525 line) video timing).

Table 4-6. Input Video Formats (Framelock)

Input Video Format (Framelock Source)	Format Name	Compatible Graphics Formats
525 line at 59.94Hz (NTSC)	525 (or use the alias NTSC)	1280x1024_5994f 1920x1154_5994f
625 line at 50Hz (PAL)	625 (or use the alias PAL)	1280x1024_50f 1920x1154_50f
720-line progressive-scan at 59.94Hz	720p_5994	1920x1154_5994f
720-line progressive-scan at 60Hz	720p_60	1280x1024_60f 1920x1154_60f 1920x1200_60f
1080-line progressive-scan at 25Hz	1080p_25	1280x1024_50f 1920x1154_50f
1080-line interlaced at 25Hz	1080i_25	1280x1024_50f 1920x1154_50f
1080-line progressive-scan at 29.97Hz	1080p_2997	1920x1154_5994f
1080-line interlaced at 29.97Hz	1080i_2997	1920x1154_5994f
1080-line progressive-scan at 30Hz	1080p_30	1280x1024_60f 1920x1154_60f 1920x1200_60f
1080-line interlaced at 30Hz	1080i_30	1280x1024_60f 1920x1154_60f 1920x1200_60f

Configuring Monitor Positions

When an X-Server is managing multiple monitors, it needs to know their relative positions in order to properly handle cursor cross-over locations.

The monitor positions are specified in the “ServerLayout” section of the /etc/X11/XF86Config file as follows:

Each screen is listed, followed by a list of the screens above, below, to the left, and to the right of it (in that order). Figure 4-2 and the following subsection show an example of four monitors arranged in a line.

Programs started by clicking on an icon appear on the screen from which you invoked them. Note that once a program has been launched, it is not possible to move it from one screen to another.

Figure 4-2. Four Monitors in a Line

Example “ServerLayout” Section for Four Monitors in a Line

Section "ServerLayout"
    Identifier  "Four-in-a-Line"
    Screen "Screen SG-0"        ""      ""      ""      "Screen SG-1"
    Screen "Screen SG-1"        ""      ""      "Screen SG-0"   "Screen SG-2"
    Screen "Screen SG-2"        ""      ""      "Screen SG-1"   "Screen SG-3"
    Screen "Screen SG-3"        ""      ""      "Screen SG-2"   ""
    InputDevice "Mouse1" "CorePointer"
    InputDevice "Keyboard1" "CoreKeyboard"
EndSection

Figure 4-3 and the subsection following it show an example of four monitors arranged in a square.

Figure 4-3. Four Monitors in a Square

Example “ServerLayout” Section for Four Monitors in a Square

Section "ServerLayout"
    Identifier  "Four-in-a-Square"
    Screen "Screen SG-0"        ""      "Screen SG-2"      ""      "Screen SG-1"
    Screen "Screen SG-1"        ""      "Screen SG-3"      "Screen SG-0"   ""
    Screen "Screen SG-2"        "Screen SG-0"      ""      ""   "Screen SG-3"
    Screen "Screen SG-3"        "Screen SG-1"      ""      "Screen SG-2"   ""
    InputDevice "Mouse1" "CorePointer"
    InputDevice "Keyboard1" "CoreKeyboard"
EndSection

Configuring Monitor Types

The system graphics cards support both analog and digital monitors. The type of monitor connected to each graphics card is specified in the “Device” sections of the /etc/X11/XF86Config file.

Table 4-7 lists the allowable options for the MonitorLayout line. If the line is not present, both channels default to AUTO.

Table 4-7. Options for Monitor Layout

Monitor Type	Meaning
AUTO	Automatically select monitor type (default)
TMDS	Digital monitor
CRT	Analog monitor
NONE	No monitor

The format is:

Option      "MonitorLayout" "channel1type, channel2type"

where channel1type is the type (AUTO, TMDS, CRT or NONE) of monitor attached to channel 1 (the left DVI-I connector) for this pipe, and
channel2type is the type (AUTO, TMDS, CRT or NONE) of monitor attached to channel 2 (the right DVI-I connector) for this pipe.

Example “Device” Section for Use With Two Analog Monitors

Section "Device"
    Identifier  "SGI SG-0"
    Driver      "fglrx"
    BusId       "PCI:23:0:0"
    Option      "MonitorLayout" "CRT, CRT"
EndSection

Configuring a System for Multiple Xservers (ProPack^™ 3, Service Pack 4 or later)

Multiple Xservers allows specific subsets of the keyboards, pointing devices, and monitors attached to a Silicon Graphics Prism system to each be managed by a different Xserver.

Note: This section only applies to systems with ProPack 3. For systems with ProPack 4, Service Pack 2 or later, use the configuration described in “Configuring a System for Multiple Xservers (ProPack 4, Service Pack 2 or Later)”. (To determine which ProPack version a system is running, look in the /etc/sgi-release file.)

Note: The use of multiple Xservers requires ProPack 3, Service Pack 4 or a later release of the software.

This section describes a relatively simple configuration. Much more complex configurations are possible, however, and may be accomplished by extending the instructions provided here.

Note: When configuring multiple seats, the best method is to first attach all devices (keyboards, pointing devices, and monitors) and configure the system with a single Xserver. Once this is done, the configuration may be modified to assign individual subsets of these devices to be managed by separate Xservers.

Configuring a system for multi-seat operation involves the following steps, each described in a separate subsection below:

Identify the correct event devices (that is, keyboards and pointing devices) for each seat.
Create and edit an XF86Config.Nserver file for the desired configuration.
Point X to the newly-created XF86Config.Nserver file.

Identifying Event Devices

An “event device” is a keyboard or pointing device. All event devices connected to the system are listed at boot time on lines beginning with the string “input.” These boot messages may be displayed at a Linux command prompt using the dmesg command. The output from the dmesg command can be quite long, and therefore is usually filtered with a grep command. For example:

# dmesg | grep ^input
input0: USB HID v1.10 Keyboard [NOVATEK Generic USB Keyboard] on usb1:4.0
input1: USB HID v1.00 Mouse [Logitech N43] on usb1:5.0
input2: USB HID v1.00 Mouse [Logitech N43] on usb1:6.0
input3: USB HID v1.10 Keyboard [NOVATEK Generic USB Keyboard] on usb1:7.0
input4: USB HID v1.00 Keyboard [SILITEK USB Keyboard and Mouse] on usb1:9.0
input5: USB HID v1.00 Mouse [SILITEK USB Keyboard and Mouse] on usb1:9.1
input6: USB HID v1.00 Mouse [Logitech N43] on usb1:10.0

All input devices detected during boot-up will have device nodes created for them in the /dev/input directory as follows:

Each keyboard will have an associated event* device node.
Each pointing device will have both an associated event* device node and an associated mouse* device node.

The mapping of devices to nodes is by number (that is, input0 maps to event0, input1 maps to event1, and so on). The first input that is a pointing device gets mapped to mouse0, the next input that is a pointing device gets mapped to mouse1, and so on.

The dmesg output shown above would therefore create the following mapping:

input0: event0
input1: event1, mouse0
input2: event2, mouse1
input3: event3
input4: event4
input5: event5, mouse2
input6: event6, mouse3

This mapping can then be used to edit the XF86Config.Nserver file, as described in the next subsection, “Creating a Multi-Seat XF86Config File”.

Creating a Multi-Seat XF86Config File

A multiple-Xserver configuration requires a customized XF86Config file containing a separate ServerLayout section for each Xserver you will be running.

Note: The original ServerLayout section (always identified as “Main Layout”) is typically left unchanged, allowing the system to easily be reconfigured as a single-Xserver system.

Creating a New XF86Config File

Start out by creating a new XF86Config file. The easiest way to do this is to simply make a copy of the system's regular XF86Config file, as follows:

# cp /etc/X11/XF86Config /etc/X11/XF86Config.Nservers

(where N is the number of servers you will be configuring).

Configuring the Input Devices

Next, configure the input devices as follows:

Copy the section beginning:
Section "InputDevice" Identifier "Keyboard1"
and insert a duplicate copy (or copies) below the existing section, until there is one copy for each keyboard (including the original copy in this count).
Edit all the keyboard InputDevice sections, in each one changing the driver from “keyboard” to “evdev” and adding an Option line identifying the appropriate event device (in this example, “/dev/input/event0”). The resulting InputDevice sections will look something like the following:
Section "InputDevice" Identifier "Keyboard1" Driver "evdev" Option "Device" "/dev/input/event0" # ... EndSection
Note: See “Identifying Event Devices” for instructions on how to determine the appropriate event device for each section.

Note: You may assign any number of keyboards to a single Xserver, but no keyboard may be assigned to more than one Xserver.
Copy the section beginning:
Section "InputDevice" Identifier "Mouse1"
and insert a duplicate copy (or copies) below the existing section, until there is one copy for each pointing device (including the original copy in this count).
Edit all the mouse InputDevice sections, changing the Option “Device” line from the default “/dev/input/mice” to one identifying the appropriate event device (in this example, “/dev/input/mouse0”). The resulting InputDevice sections will look something like the following:
Section "InputDevice" Identifier "Mouse1" Driver "mouse" Option "Device" "/dev/input/mouse0" # ... EndSection
Note: See “Identifying Event Devices” for instructions on how to determine the appropriate event device.

Note: You may assign any number of pointing devices to a single Xserver, but no pointing device may be assigned to more than one Xserver.

Configuring the New ServerLayout Sections

In this new XF86Config.Nservers file, perform the following steps:

Copy the section beginning:
Section “ServerLayout” Identifier “Main Layout”
and insert a duplicate copy (or copies) below the existing section, until there is one copy for each Xserver you will have (do NOT include the original “Main Layout” copy in this count).
While leaving the original ServerLayout section identified as “MainLayout,” give each new ServerLayout section a new name. For example, the first server might be named “Layout0”:
Identifier “Layout0”
the next “Layout1,” and so on.
Within each new Server Layout section, disable (delete or comment out) every screen that will not be used in that layout:
Screen "Screen SG-0" "" "" "" "Screen SG-1" # Screen "Screen SG-1" "" "" "Screen SG-0" ""
Note: You may assign any number of screens to a single Xserver, but no screen may be assigned to more than one Xserver.
Edit each Server Layout section to make sure than no remaining uncommented screen lists as adjacent another screen that will be managed by a different Xserver:
Screen "Screen SG-0" "" "" "" "" # Screen "Screen SG-1" "" "" "Screen SG-0" ""
Within each Server Layout section, change the input devices to the correct ones for that Xserver. For example, the first Xserver might use:
InputDevice “Mouse1” “CorePointer” InputDevice “Keyboard1” “CoreKeyboard”
Save the XF86Config.Nservers file.

For an example ServerLayout section from an XF86Config.3server file, see “Example “ServerLayout” Sections for Three Xservers”. In this example, the first two Xservers manage one screen each, while the third Xserver manages two screens.

Example “ServerLayout” Sections for Three Xservers

# **********************************************************************
# ServerLayout sections.
# **********************************************************************

Section "ServerLayout"
    Identifier  "Main Layout"
    Screen "Screen SG-0"        ""      ""      ""      "Screen SG-1"
    Screen "Screen SG-1"        ""      ""      "Screen SG-0"   "Screen SG-2"
    Screen "Screen SG-2"        ""      ""      "Screen SG-1"   "Screen SG-3"
    Screen "Screen SG-3"        ""      ""      "Screen SG-2"   ""
    InputDevice "Mouse1" "CorePointer"
    InputDevice "Keyboard1" "CoreKeyboard"
EndSection

Section "ServerLayout"
    Identifier  "Layout0"
    Screen "Screen SG-0"        ""      ""      ""      ""
    InputDevice "Mouse1" "CorePointer"
    InputDevice "Keyboard1" "CoreKeyboard"
EndSection

Section "ServerLayout"
    Identifier  "Layout1"
    Screen "Screen SG-1"        ""      ""      ""      ""
    InputDevice "Mouse2" "CorePointer"
    InputDevice "Keyboard2" "CoreKeyboard"
EndSection

Section "ServerLayout"
    Identifier  "Layout2"
    Screen "Screen SG-2"        ""      ""      ""      "Screen SG-3"
    Screen "Screen SG-3"        ""      ""      "Screen SG-2"      ""
    InputDevice "Mouse3" "CorePointer"
    InputDevice "Keyboard3" "CoreKeyboard"
EndSection

Pointing X to the New XF86Config.Nserver File

Once you have created the new XF86Config.Nserver file, the last step is to tell X to use the new layouts it contains, rather than the default server layout. To do so, perform the following steps:

Make a backup copy of the default single-server /etc/X11/gdm/gdm.conf file:
# cp /etc/X11/gdm/gdm.conf /etc/X11/gdm/gdm.conf-old
Edit the /etc/X11/gdm/gdm.conf file to use the new server layouts you defined in the XF86Config file:

In the [servers] section, comment out the standard server, then add the new server layouts you will be using:
#0=Standard 0=Layout0 1=Layout1 2=Layout2
Define each new server layout. For example:
[server-Layout0] name=Layout0 server command=/usr/X11R6/bin/X :0 -xf86config /etc/X11/XF86Config.3server -layout Layout0 flexible=true
For an example of a multi-Xserver [servers] section, see “Example /etc/X11/gdm/gdm.conf Servers Section for Three Xservers”.
Save the gdm.conf file and reboot the system.

Example /etc/X11/gdm/gdm.conf Servers Section for Three Xservers

[servers]

#0=Standard
0=Layout0
1=Layout1
2=Layout2

[server-Standard]
name=Standard server
command=/usr/X11R6/bin/X
flexible=true

[server-Layout0]
name=Layout0 server
command=/usr/X11R6/bin/X :0 -xf86config /etc/X11/XF86Config.3server -layout Layout0
flexible=true

[server-Layout1]
name=Layout1 server
command=/usr/X11R6/bin/X :1 -xf86config /etc/X11/XF86Config.3server -layout Layout1
flexible=true

[server-Layout2]
name=Layout2 server
command=/usr/X11R6/bin/X :2 -xf86config /etc/X11/XF86Config.3server -layout Layout2
flexible=true

Configuring a System for Multiple Xservers (ProPack 4, Service Pack 2 or Later)

Multiple Xservers allows specific subsets of the keyboards, pointing devices, and monitors attached to a Silicon Graphics Prism system to each be managed by a different Xserver.

Note: This section only applies to systems with ProPack 4, Service Pack 2 or later. For systems with ProPack 3, use the configuration described in “Configuring a System for Multiple Xservers (ProPack™ 3, Service Pack 4 or later)”. (To determine which ProPack version a system is running, look in the /etc/sgi-release file.)

This section describes a relatively simple configuration. Much more complex configurations are possible, however, and may be accomplished by extending the instructions provided here.

Configuring a system for multi-seat operation involves the following steps, each described in a separate subsection below:

Identify the correct event devices (that is, keyboards and pointing devices) for each seat.
Create and edit an XF86Config.Nserver file for the desired configuration.
Point X to the newly-created XF86Config.Nserver file.

Identifying Keyboards and Pointing Devices

This section explains how to uniquely refer to keyboards and pointing devices for later reference in the XF86Config.Nserver file.

Adding USB Device Rules

Some systems will need rules added to the /etc/udev/udev.rules file to ensure that the keyboard and mouse appear in a predictable location at each reboot. Follow these steps to ensure that the rules are present:

Open the /etc/udev/udev.rules file in a text editor.

Search for the following two lines:

KERNEL="event*",BUS="usb",SYSFS{bInterfaceClass}="03",SYSFS{bInterfaceProtocol}="02",NAME="input/%k",SYMLINK="input/evmouse-%b"
KERNEL="event*",BUS="usb",SYSFS{bInterfaceClass}="03",SYSFS{bInterfaceProtocol}="01",NAME="input/%k",SYMLINK="input/evkbd-%b"

If the lines are already present, proceed to “Creating a Multi-Seat XF86Config File”.
If the lines are not present, insert them before any existing KERNEL="event*" lines.

Finding the Device Names

Follow these steps to find the device names for the keyboards and mice:

Look in the /dev/input/ directory for files beginning with “evkbd” and “evmouse.” For example:
evkbd-2-1:1.0 evkbd-2-2:1.0 evmouse-1-1:1.0 evmouse-1-2:1.0
Record these device names for use when editing the XF86Config.Nserver file, as described in the next subsection, “Creating a Multi-Seat XF86Config File”.
These device names include the USB path where the device is located. As long as the device remains connected to the same USB port, these device names should remain the same.