Appendix A
Fixed Issues
101
Changes made with the
setenv
and
eeprom
commands take effect immediately.
Changes made with the
bootmode
command are supposed to take effect on the next
reset, no matter what kind of reset it is.
Changes made in any of these three ways are supposed to stay in effect until the next
change. That is, it doesn’t matter how the value of an LDoms variable is changed.
Once changed, the value is supposed to stay in effect until it is changed again.
However, due to this issue, changes made with the
bootmode
command will
become effective only after a power-on reset and will, on every reset (other than a
power-on reset) that follows, override any intervening change made with the
setenv
or
eeprom
commands. That is, the changes made by the
bootmode
command require a power-on reset to be effective. Changes made with the
setenv
or
eeprom
commands will only persist until the next reset, at which point the
variable will revert to the value set by the last
bootmode
command. This persistence
of the
bootmode
setting will persist until the machine is power-cycled. Upon power
cycling, the prior
bootmode
setting will not take effect. Any subsequent change
made by the
setenv
or
eeprom
command will now persist over resets, at least until
the next
bootmode
command followed by a power cycle.
Workaround: Restart the control domain with a power-on reset right after the
bootmode
command is executed, and restart again after the control domain boots to
either OpenBoot or Solaris. The first power-on reset will make the
bootmode
command effective and the second power-on reset will workaround the persistence
issue.
The control domain can be reset using power-on reset with the ALOM CMT
compatibility CLI
powercycle
command. If the control domain is booted to the
Solaris OS, remember to properly shut down the OS before executing the
powercycle
command.
Domain ETM and LDC Deadlock When Transmit
Queue Full (CR 6594506)
This issue is resolved with Solaris patch ID 125369-12 or later.
After certain hardware error events, it is possible that PSH events are no longer
transported between the Service Processor (SP) and the domain. The scenarios
subject to this CR:
■
In a non-LDoms environment, an unrecoverable error in the Solaris domain
■
In an LDoms environment, an unrecoverable error in the control domain
■
In either an LDoms or non-LDoms environment, a fatal error in the system (a fatal
error resets the system at the HW level)