Sun Fire Entry-Level Midrange Systems Firmware 5.19.0 Release Notes |
This document provides information on new and revised features, as well as late-breaking news, for firmware release 5.19.0 on Sun Fire E2900 Sun Fire V1280, and Netra 1280 systems.
This document contains the following topics:
This section provides a brief description of the new features in 5.19.0 for Sun Fire entry-level midrange systems.
The 5.19.0 release supports the following:
The watchdog mechanism detects a system hang, or an application hang or crash, should they occur. The watchdog is a timer that is continually reset by a user application as long as the operating system and user application are running.
On Sun Fire entry-level midrange systems, the watchdog is associated with alarm 3.
For information about the watchdog timer and alarm 3, see the Sun Fire Entry-Level Midrange System Administration Guide.
5.19.0 firmware reduces the time required to perform a power-on self-test (POST) operation. Code optimizations as well as the use of parallel testing algorithms have enabled a significant decrease in test time while maintaining the same fault diagnosis coverage as that provided with earlier versions of the firmware.
When comparing the 5.19.0 release to the 5.18.0 release, Sun has measured reductions in POST elapsed time of between 20 and 70 percent. Your experience may differ, depending on your system's configuration and the settings of firmware configuration parameters such as diag-level and verbosity-level. The largest improvements can be seen on systems with UltraSPARC IV or UltraSPARC IV+ processors, containing substantial amounts of memory, and running with
diag-level values of mem1 or mem2.
The 5.19.0 firmware release, when used on systems with domains running the Solaris 10 Operating System, provides information on Solaris-detected hardware fault events. This information is captured by Solaris software and then communicated to the system controller. The system controller reports this information through automatic diagnosis (AD) and domain (DOM) event messages.
The following SC command was added in 5.19.0:
For details on these commands, refer to their descriptions in the Sun Fire Entry-Level Midrange System Controller Command Reference Manual.
Sun Fire E2900 systems require 5.17.0 firmware or greater and the Solaris 8 2/04 or Solaris 9 4/04 operating environments as the minimum Solaris releases. Sun Fire E2900 systems and Sun Fire V1280 systems with UltraSPARC IV+ CPU/Memory boards or PCI-X I/O boards (or both) require 5.19.0 firmware and compatible releases of the Solaris 10 or Solaris 9 operating system (when available) as the minimum Solaris releases.
Certain hardware components require minimum firmware revisions in midrange entry-level systems, as follows:
Instructions for updating firmware (upgrade and downgrade) are provided in the Sun Fire Entry-Level Midrange System Administration Guide.
This section describes only those bugs with potentially significant impact. The README file lists all bugs, including those seen only internally at Sun.
If you change the connection type after updating firmware on entry-level midrange systems from 5.17.x, 5.18.x, or 5.19.x to 5.13.x, then the new connection type (selected in 5.13.x) is not guaranteed once you update firmware back to 5.17.x, 5.18.x, or 5.19.x. If you subsequently update the firmware to 5.17.x, 5.18.x, or 5.19.x from 5.13.x, the original connection type that you had in 5.17.x, 5.18.x, or 5.19.x before the change to 5.13.x will be restored.
Workaround: Set the connection type explicitly (using the setupnetwork command) to ensure system security.
After a domain panic occurs or when a domain encounters errors, output from a subsequent setkeyswitch or testboard operation will show that the board processors have an Unknown status.
Workaround: Reboot the system controller.
A message indicating that there are dropped console messages is displayed when data is being provided by Solaris software or by the OpenBoot PROM faster than the system controller can write it to the console.
If a power failure and SC reboot occurs during an add segment operation, one or more SEEPROM segments may become corrupted upon a reboot. However, even though these error messages display, the availability of the domains is not affected.
If multiple users attempt to connect to the SC using SSH connections in parallel, the SC can panic, displaying the following message on the SC console:
schostname:A> 0x3c27b78 (tSshConn): memPartAlloc: block too big - 40947 in partition 0x3b8c7d0. [0x3c27b78] xrealloc: out of memory (new_size 40947 bytes) |
When used with an abbreviated form for the name of a component, the enablecomponent command sometimes reports component status incorrectly. For example:
Workaround: Use a fully specified component name, such as /N0/IB6/P1/B1/C4.
Use of some unsupported components can generate misleading messages, such as component: does not have grid power. For example:
lom> poweroff all ... /N0/IB6: does not have grid power /N0/IB7: does not have grid power /N0/IB8: does not have grid power /N0/IB9: does not have grid power ... |
Workaround: Verify that all components in the specified IB are supported.
Under some circumstances Ethernet connections to the system controller can hang. However, the serial connection continues to supply access.
Workaround: Reboot the system controller.
Copyright © 2005, Sun Microsystems, Inc. All Rights Reserved.