Sun Fire 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:
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.
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 192.168.100.1 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.
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 Install.info 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.
Instructions for upgrading firmware are provided in the Install.info file included with this firmware release for Sun Fire midrange systems.The Install.info 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.
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.
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.
This section describes only those bugs with potentially significant impact. The README file lists all bugs, including those seen only internally at Sun.
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 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.
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.
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.
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.
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:
Workaround: Reboot the system controller.
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.
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.
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.
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:
Even though these error messages are displayed, the availability of the domains is not affected.
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.