Sun Firetrademark Midrange Systems Firmware 5.18.0 Release Notes

This document provides general information and system limitations for firmware release 5.18.0 on Sun Fire E6900/E4900/6800/4810/4800/3800 systems.

This document contains the following topics:

Firmware Documentation for Sun Fire Midrange and Entry-Level Midrange Systems

The following documentation sets are included with the 5.18.0 firmware:

For firmware upgrade and downgrade information on entry-level midrange (E2900/V1280/Netra 1280) systems, refer to the Sun Fire Entry-Level Midrange System Administration Guide.

New Features

DHCP Network Boot Changes

5.18.0 firmware modifies the behavior of the OpenBoot PROM when booting off of the network using the DHCP protocol.

During the network boot process, clients use TFTP to download an initial boot binary (such as inetboot) from a TFTP boot server specified by the DHCP server. If the DHCP server does not tell the client the name of the file to be downloaded, the OpenBoot PROM uses a default file name for the TFTP request. In previous firmware releases the default boot file name was the client's IP address expressed as a string of eight hexadecimal characters (for example, a client whose IP address was would request a file named C0A86401). While this behavior is correct for non-DHCP network boots, it is incorrect for network booting with DHCP.

Starting in this release, the default boot file name used by the OpenBoot PROM is constructed from the client's platform type. Unless the DHCP server specifies a different boot file name, midrange platforms request a file named SUNW.Sun-Fire while entry-level midrange platforms request a file named SUNW.Netra-T12. This behavior is consistent with the net boot server setup tools distributed with Solaris software.

With this change, you might (depending upon your network boot configurations) see net boot errors after installing the new firmware. Specifically, if the requested boot file does not exist on the TFTP boot server, the OpenBoot PROM issues the following message and fails to boot the Solaris Operating System:

ERROR: get_tftp_file: TFTP error 2: Access violation

Workarounds: This situation can be corrected in several ways, including (but not limited to):

The DHCP network boot process supports configurations in which the DHCP server and the TFTP boot server are different machines. If the DHCP server and other network components are configured correctly, the DHCP and TFTP servers can exist on different IP subnets. However, the OpenBoot PROM firmware in previous releases assumes that the DHCP server and the TFTP server are the same machine even if the DHCP server indicates otherwise.

Starting with this release, the OpenBoot PROM handles configurations correctly in which the DHCP and TFTP servers are not the same machine, including when they are on different subnets. For cross-subnet TFTP configurations, note that the DHCP server must be configured to provide proper Router and Subnet values to the client.

With this change, if your DHCP servers are improperly configured (providing incorrect Router or Subnet values to clients), you might see net boot errors after installing the new firmware. OpenBoot PROM firmware on the client might issue one or both of the following messages in that situation:

ERROR: get_arp_info: Timeout waiting for ARP packet
ERROR: tftp_get_reply: Timeout waiting for TFTP packet

Workaround: To eliminate these error messages, verify that the Router and Subnet values sent to the client by the DHCP server are correct.

General Information

Firmware Compatibility

System boards running firmware versions 5.12.x through 5.18.x firmware are compatible with each other, but system boards running 5.11.x are not compatible with system boards running firmware versions 5.12.x through 5.18.x. You can check the firmware compatibility of your boards by running the
showboards -p version -v command. The information displayed indicates whether the firmware for each board is compatible with the ScApp version running on the SC.

Update all your system boards to the same firmware version and activate the new firmware version on your domains as soon as possible. Activate the domain firmware by running the setkeyswitch off and setkeyswitch on commands. For details on updating your system firmware and verifying firmware compatibility, refer to the file included with this firmware release.

UltraSPARC IV CPU/Memory boards require 5.16.0 firmware or greater. The UltraSPARC IV CPU/Memory boards will not run on firmware releases earlier than 5.16.0. COD boards must be running a firmware version that supports COD, which was introduced in firmware release 5.14.0.

Firmware Upgrade and Downgrade

Instructions for upgrading firmware are provided in the file included with this firmware release for Sun Fire midrange systems.The file also contains instructions for downgrading to an earlier version of the firmware.

E6900/E4900 systems and systems that contain UltraSPARC IV CPU/Memory boards must run firmware version 5.16.0 or greater. Earlier firmware versions do not support the UltraSPARC IV CPU/Memory boards.

Midrange systems with SC V2s can be downgraded from 5.18.0 to earlier firmware releases, but note that those earlier releases will not support bug fixes made in 5.18.0.

caution icon

Caution - If you have a redundant system controller (SC) configuration, you must first upgrade the firmware on the spare SC, then on the main SC, as explained in the Install.infofile.

Power Supply Failures

In some cases powering off or powering on a power supply after you upgrade to firmware version 5.14.x or greater can cause a power supply fault on Sun Fire 6800/4810/4800/3800 systems.

Note - The faults described here do not apply to the A184 and A185 power supplies.

The power supply failure might exhibit the following characteristics:

Use the following workarounds to resolve the power supply failure. Start with
Workaround 1. If this workaround is unsuccessful, perform Workaround 2. If the second workaround is unsuccessful, perform Workaround 3.

Known Limitations for Sun Fire Midrange Systems

This section describes only those bugs with potentially significant impact. The README file lists all bugs, including those seen only internally at Sun.

SC Hangs After Automatic setkeyswitch off (RFE 4454599)

Manual reset of the SC has no effect.

Workaround: Do the following:

1. Connect to each active domain through a network connection, such as telnet or rlogin.

2. Shut down each domain, if possible.

3. Power down the Sun Fire midrange system, then power it up again.

SNMP: FrameManager Does Not Have an Entry in the MIB and Frame State Traps (RFE 4987286)

SNMP is a private interface for the midrange system controllers. This means that Sun Management Center will not receive FrameManager information through SNMP. If you have a loghost, note that FrameManager and RTU statuses can be monitored from the loghost.

Workaround: None.

sgcn_output_line(): OBP console blocked; message data lost (BugID 4939206)

A message indicating that there are dropped console messages is displayed when the system controller requires more time to write data to the I/O than when data is written to the SRAM.

Workaround: None

SC is "hard hung" Doing a dumpconfig to Host With TCP Wrappers (BugID 5028357)

The system controller becomes hard hung when dumpconfig output is sent to a host that has TCP wrappers and a configuration that denies FTP connections.

Workaround: Do not use a host that has TCP wrappers.

Upgrade of Firmware Changes Connection Type (BugID 5060748)

If you change the connection type after downgrading firmware on midrange systems from 5.17.x or 5.18.x to a lower firmware version, the new connection type selected in the lower firmware version is not guaranteed once you update the firmware back to 5.17.x or 5.18.x. If you subsequently update the firmware to 5.17.x or 5.18.x from the lower firmware version, the original connection type that you had in 5.17.x or 5.18.x before the change to a lower firmware version will be restored.

Workaround: To ensure system security, use the setupplatform command to set the connection type explicitly.

Board State Becomes Incorrect After setkeyswitch or testboard Operations (BugID 5066326)

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. For example:

schostname:A> testb sb4
Sep 24 11:01:53 schostname-sc0 Domain-A.POST: Domain A: diag-level = init
Sep 24 11:01:53 schostname-sc0 Domain-A.POST: Domain A: verbosity-level = min
Sep 24 11:01:53 schostname-sc0 Domain-A.POST: Domain A: error-level = max
{/N0/SB4/P0} Unknown
{/N0/SB4/P1} Unknown
{/N0/SB4/P2} Unknown
{/N0/SB4/P3} Unknown

Workaround: Reboot the system controller.

disablecomponent Fails to Blacklist an I/O Card (BugID 5074564)

If you run the disablecomponent or setls command to blacklist an I/O card, the card is not disabled at the OpenBoot PROM (OBP) level.

Workaround: Perform a setkeyswitch off and then a setkeyswitch on operation after disabling the I/O card.

Wanboot "panic - boot: create_ramdisk: fatal error" on Sun Fire Midrange Server Platforms (BugID 5076076)

If you are using a wanboot server to boot a Sun Fire midrange system (E6900, E4900, E2900, 6800, 4810, 4800, 3800 and the V1280), the wanboot server cannot create the ramdisk and is unable to boot the Sun Fire midrange system.

Workaround: None.

ERROR: DomainBufferReader thread error java.lang. NullPointerException (BugID 5088923)

In certain situations, this error message can occur when running reset or shutdown commands from the domain console shell. The error does not affect the availability of the domain. However, the reset or shutdown commands may take an additional 60 seconds to complete.

Workaround: None.

Power Failure May Corrupt SEEPROM Contents (BugID 5093450)

If a power failure and ScApp reboot occur during an add segment operation, one or more SEEPROM segments may become corrupted upon a reboot. The following example log sequence shows illegal tag statements:

Aug 04 14:18:42 schostname-SC0 schostname-sc0 Platform.SC: [ID 470632 local0.error] 
/N0/SB2: SepromSegment(constructor): ID at 0x0042: Illegal Tag 0x00 at 0x002b
Aug 04 14:18:42 schostname-sc0 schostname-sc0 Platform.SC: [ID 576073 local0.error] 
/N0/SB2: SepromSegment(constructor): PE at 0x00bf: Illegal Tag 0x00 at 0x0102
Aug 04 14:18:42 schostname-sc0 schostname-sc0 Platform.SC: [ID 982808 local0.error] 
/N0/SB2: SepromSegment(constructor): PS at 0x01c6: Illegal Tag 0x00 at 0x0000
Aug 04 14:18:42 schostname-sc0 schostname-sc0 Platform.SC: [ID 586548 local0.error] 
/N0/SB2: SepromSegment(constructor): FD at 0x01dd: Illegal Tag 0x00 at 0x0002
Aug 04 14:18:46 schostname-sc0 Platform.SC: [ID 139087 local0.notice] Clear /N0/SB2 invalid segment

Even though these error messages are displayed, the availability of the domains is not affected.

Workaround: None.

Removing an SC, Even Though it Has Been Powered Off, Can Cause a Domain Outage (BugID 5105071)

If you power off an SC from the other SC and then run the showboards -p clock command, the system clock status of the SC (that you powered off) is still displayed. If you then remove the powered-off SC, a domain outage can occur.

Workaround: Before removing an SC, do the following:

1. After powering off the SC, run the showboards -p clock command to check the system clock status of the powered-off SC.

2. If any board in an active domain is using the system clock of the powered-off SC, as indicated in the Signal Used column, do not remove the powered-off SC.