Sun Fire E6900 Server
 
Sun Fire 3800 Server
 
Sun Fire 6800 Server
 
Sun Fire E4900 Server
 
Sun Fire 4800 Server
 
Sun Fire 4810 Server
 

GCS>Sun Microsystems>Sun Alert>Criteria Category>Availability
 
GCS>Sun Microsystems>Sun Alert>Release Phase>Resolved
 

If the main System Controller (SC) on a Sun Fire 3800, 4800, 4810, 4900, 6800 or 6900 system (with running domains) is reset with the reset button, there is a possibility of a change in hardware configuration which would cause the domains to perform a "fatal" reset. The domains will reset and take action as per the "error-reset-recovery" OBP property, which may include unexpected system outages while domains are recovered.

This issue can occur on the following platforms:

• Sun Fire 3800, 4800, 4810, 4900, 6800, 6900 (without recommended SunFire SCApp firmware update 5.12.6)

if the reset button is used on running domains.

The Sun Fire System Controller (SC) periodically queries system ASICs (Application Specific Integrated Circuits) via JTAG buses to read configuration, monitor environmental states and change domain configuration. If the hardware reset button is used during one of these operations, the JTAG bus may be left in an undefined state. This change in configuration can trigger a fatal reset on affected active domains.

To determine the firmware version of the SCApp, use the "showsc" command from the platform shell as follows:

    SC> showsc
    SC: SSC0

    Main System Controller

    SC Failover: disabled

    Clock failover enabled.

    SC date: Thu Jun 01 12:59:45 CDT 2006

    SC uptime: 25 minutes 58 seconds
    ScApp version: 5.19.6 Build_01

    RTOS version: 45

Shortly after the main System Controller has been reset using the reset button, the domains within the system reboot with an error message similar to the following:

ErrorMonitor: Domain A has a SYSTEM ERROR

In the case of an SC becoming unresponsive, attempts should be made to confirm connectivity via the serial port and network prior to using the reset button. If the SC appears to be hung:

1. Confirm that the SC is actually hung by connecting to the serial port of the SC (with a known good cable)
2. Hit "enter" a few times - if no prompt is returned, the SC is hung
3. If this is the case, halt all domains, using the Solaris "init 0" command (or "shutdown")
4. Reset the SC using the reset button, or power-cycle the whole chassis.

Note: The use of the reset button on running domains should be avoided whenever possible, and the SC should be reset either by the above steps or via ScApp.

This issue is addressed on the following platforms:

• Sun Fire 3800, 4800, 4810, 4900, 6800, 6900 with SunFire SCApp firmware 5.12.6 (as delivered in patch 112127-02 or later)

Note: The patch above addresses the software issue for BugID 4378797. The use of the reset button on running domains should be avoided whenever possible.

29-Sep-2005:

• Update Relief/Workaround section

• Updated Contributing Factors and Resolutions sections
• State: Resolved

References

This has been flagged as a Sun Alert as the impact when the reset button causes domain outages runs counter to what customers expect i.e. that resetting the SC won't affect the running domains.

The Sun Fire System Controller (SC) periodically queries system ASICs (Application Specific Integrated Circuits) via JTAG buses to read configuration, monitor enviromental states and change domain configuration. The design of JTAG is such that reading and writing to the bus must be done in a complete cycle in which the complete command and data bit sequence is serially shifted into the JTAG ring. Any interruption to this will result in an unknown bit pattern being placed on the JTAG bus.

If the SC is performing one of these operations, or has hung during one, and the hardware reset button is used, then the JTAG bus may be left in this undefined state. When the SC reboots it will resume JTAG activity. However, this will result in the remains of the previous operation being commited to the bus which in some rare circumstances may change the configuration of core ASICs. This change in configuration can trigger a fatal reset on affected active domains. This does not happen with a software reset as the SC will complete JTAG operations and quiese the bus before resetting.

There are a number of bugs on this, such as 4378797. The core problem is that if the JTAG master (the SC) does not complete an operation (such as an SC hanging) it will leave a partial command or data sequence on the JTAG ring. When the SC attempts to start a new JTAG command it does not and cannot know what is already in the ring, and thus the placement of a new command will essentially push a random data or command value onto the ring which may cause changes to the configuration of ASICs such as ARs and DXs, with obvious unpleasant results.

There is no software workaround as it is impossible to determine the state of the JTAG ring or to know what was left of the sequence being put into the JTAG ring. A possible hardware fix would be to use a persistant SRAM as a log of the pending JTAG command, however the current generation of SCs lack the hardware for that feature and there are no plans to add it.

References

This solution has no attachment