Skip to main content

Problems Resolved in Oracle Solaris 11.4


Problems Resolved in Oracle Solaris 11.4
The following table lists the problems resolved in Oracle Solaris 11.4. You might encounter them in supported releases earlier than Oracle Solaris 11.4.
Table 3-51  Problems Resolved in Oracle Solaris 11.4
Bug 25028104
Model SPARC M12-2S, SPARC M10-4S
Description If the root complex is dynamically added/deleted by dynamic reconfiguration of the physical partition, the PCIe end point device under the added/deleted root complex may not be reflected to the PCIe end point device configuration information shown by the XSCF showpparinfo(8) command.
Workaround [How to restore]
Execute the svcadm command in the control domain to restart the ldoms/ldmd services.
# svcadm restart ldoms/ldmd
Bug 26822709
26934364
Model SPARC M12-2S, SPARC M10-4S
Description On the control domain with SRU 11.3.8.7.0 (Oracle VM Server for SPARC 3.4) or later installed, dynamic reconfiguration of the physical partition with the XSCF deleteboard(8) command may fail.
This phenomenon may occur when the following conditions are met.
1) Memory degradation has occurred (*1).

2) The PPAR DR policy is set to "ratio" or "auto" (*2).
Or

1) hvdump-reboot is set to "off" (*3).

2) The physical partition has been reset due to the XSCF reset command with the xir option or a hardware error.

3) The PPAR DR policy is set to "ratio" or "auto" (*2). 

*1 How to check the memory degradation
primary# ldm list-devices -a -S memory
If the STATUS value is "fail" in the output, you can determine that the memory area has been degraded by SIZE from the PA (physical address) displayed on the same line.
*2 How to check the PPAR DR policy
primary# svccfg -s ldmd listprop ldmd/fj_ppar_dr_policy
ldmd/fj_ppar_dr_policy astring auto
In this case, the PPAR DR policy is set to "auto".
*3 How to check hvdump-reboot
primary# ldm list-hvdump
hvdump=on
hvdump-reboot=off
In this case, hvdump-reboot is set to "off".
Workaround This has been modified with SRU 11.3.29.5.0.
Change the PPAR DR policy to "targeted" in the following way.
primary# svcadm disable ldmd
primary# svccfg -s ldmd setprop ldmd/fj_ppar_dr_policy=targeted
primary# svcadm refresh ldmd
primary# svcadm enable ldmd
[How to restore]
Restart the physical partition with the XSCF poweroff(8) and poweron(8) commands.
Example: Physical partition is 0
XSCF> poweroff -y -p 0
XSCF> poweron -y -p 0
Bug 26822709
26934364
Model SPARC M12-1, SPARC M12-2, SPARC M12-2S, SPARC M10-1, SPARC M10-4, SPARC M10-4S
Description On the control domain with SRU 11.3.2.4.0 (Oracle VM Server for SPARC 3.3) or later installed, the Oracle Solaris ldm remove-memory command with the -g option for memory operation may fail.
This phenomenon may occur when the following conditions are met.
1) Memory degradation has occurred (*1).
Or

1) hvdump-reboot is set to "off" (*2).

2) The physical partition has been reset due to the XSCF reset(8) command with the xir option
or
a hardware error.

*1 How to check memory degradation
primary# ldm list-devices -a -S memory
If the STATUS value is "fail" in the output, the memory area has been degraded by SIZE from the PA (physical address) displayed on the same line.
*2 How to check hvdump-reboot
primary# ldm list-hvdump
hvdump=on
hvdump-reboot=off
In this case, hvdump-reboot is set to "off".
Workaround This has been modified with SRU 11.3.29.5.0.
Bug 26822709
26934364
Model SPARC M12-1, SPARC M12-2, SPARC M12-2S, SPARC M10-1, SPARC M10-4, SPARC M10-4S
Description On the control domain with SRU 11.3.2.4.0 (Oracle VM Server for SPARC 3.3) or later installed, the Oracle Solaris ldm list-rsrc-group command may display memory amounts with incorrect values.
This phenomenon may occur when the following conditions are met.
1) Memory degradation has occurred (*1).
Or

1) hvdump-reboot is set to "off" (*2).

2) The physical partition has been reset due to the XSCF reset(8) command with the xir option
or
a hardware error.

*1 How to check memory degradation
primary# ldm list-devices -a -S memory
If the STATUS value is "fail" in the output, you can determine that the memory area has been degraded by SIZE from the PA (physical address) displayed on the same line.
*2 How to check hvdump-reboot
primary# ldm list-hvdump
hvdump=on
hvdump-reboot=off
In this case, hvdump-reboot is set to "off".
Workaround This has been modified with SRU 11.3.29.5.0.
Bug 24567071
Model SPARC M12-1, SPARC M12-2, SPARC M12-2S
Description If dynamic PCIe bus assignment and the dynamic reconfiguration function for PCIe end points are executed in the following procedure, only one of the two onboard ixgbe ports of the SPARC M12 is recognized.

1. Assign the PCIe bus that is connected to the two onboard ixgbe ports to the root domain by using the dynamic PCIe bus assignment function.

2. Delete the two onboard ixgbe ports under the PCIe bus assigned in step 1 from the root domain by using the dynamic reconfiguration function for PCIe end points.

3. Assign the two ixgbe ports deleted in step 2 to an I/O domain by using the dynamic reconfiguration function for PCIe end points.

4. Delete the two ixgbe ports added in step 3 from the I/O domain by using the dynamic reconfiguration function for PCIe end points.

5. Return the two ixgbe ports deleted in step 4 to the root domain by using the dynamic reconfiguration function for PCIe end points.
Workaround This has been modified with SRU 11.3.17.5.0. Apply SRU 11.3.17.5.0 or later to the control and root domains.
[How to restore]
Using the dynamic PCIe bus assignment function, delete the PCIe bus from the root domain and then assign the PCIe bus to the root domain again.
Bug 24754492
Model SPARC M12-2, SPARC M12-2S, SPARC M10-4, SPARC M10-4S
Description A logical domain panic may occur or the ldmd daemon may generate a core dump when you execute the ldm shrink-socket command to remove memory from logical domains if both of the following conditions are met.
- Oracle Solaris is running in logical domains.

- Multiple memory blocks on the same CPU socket are allocated to logical domains.

You can check memory allocation of each CPU socket's memory by the ldm list-socket command.
In the following example, two memory blocks on CPU socket #0 are allocated to logical domain domain-A.
  # ldm list-socket -o memory domain-A
  
  MEMORY
      PA                          SIZE              SOCKET_ID    BOUND
      0x7e0450000000              16G               0            domain-A
      0x7e08d0000000              1536M             0            domain-A
Workaround This has been modified with SRU 11.3.14.6.0.
Execute the ldm remove-memory command in place of the ldm shrink-socket command to remove memory from logical domains.
Bug 24973255
Model SPARC M12-2, SPARC M12-2S
Description Even when the following settings are implemented for Oracle Solaris kernel zones, warm/live migration of the Oracle Solaris kernel zone that is set with cpu-arch=sparc64-class1 from a SPARC M12 system to a SPARC M10 system may fail.

/etc/system file
-----------------------------------------------------------------

set enable_1ghz_stick = 1
set uhrt_enable=0x0
-----------------------------------------------------------------

For details on settings in the /etc/system file, see "8.2.3  Notes on Oracle Solaris Kernel Zones" in the Fujitsu SPARC M12 and Fujitsu M10/SPARC M10 System Operation and Administration Guide.
This bug occurs when the OS of the Oracle Solaris kernel zone is Oracle Solaris 11.3 SRU 11.3.15.4.0 or Oracle Solaris 11.3 SRU 11.3.16.3.0.
Workaround This has been modified with SRU 11.3.17.5.0. Apply SRU 11.3.17.5.0 to the Oracle Solaris kernel zone for which a warm/live migration is performed.
Bug 21654442
Model SPARC M12-1, SPARC M12-2, SPARC M12-2S, SPARC M10-1, SPARC M10-4, SPARC M10-4S
Description If the Virtual SCSI Host Bus Adapter function is used, the following warning message may be output for the root domain or an I/O domain.
[Example]
vsan: WARNING: vsan_walk_match_func:
iport-dip(40010ef2fd8): dip(40010ef29b8):
prop(class) not found
Workaround This has been modified with SRU 11.2.11.5.0.
This message has no effect on the functioning of the system, ignore it.
Bug 21779989
Model SPARC M12-1, SPARC M12-2, SPARC M12-2S, SPARC M10-1, SPARC M10-4, SPARC M10-4S
Description If you execute the ldm list-hba command supported in Oracle VM Server for SPARC 3.3 in a system with the PCI expansion unit connected, the device alias of SLOT4 and later of the PCI expansion unit is displayed by mistake.
[Example]
# ldm list-hba -l -t -d primary
NAME                      VSAN
----                           ----

/SYS/MBU/SASHBA/HBA0/PORTf
[/pci@8000/pci@4/pci@0/pci@0/scsi@0/iport@f]
  :
/SYS/PCI1/SLOT2/HBA0/PORT0/0/f
          SLOT4 is correct.
[/pci@8100/pci@4/pci@0/pci@1/pci@0/pci@0/pci@0/pci@1/pci@0/pci@10/pci@0/pci@0/LSI,sas@0/iport@f]
    init-port w500605b0045c8a90
    Transport Protocol SAS
/pci@8100/pci@4/pci@0/pci@1/pci@0/pci@0/pci@0/pci@1/pci@0/pci@10/pci@0/pci@0/LSI,sas@0/iport@f/smp@w50080e52b93fd03f
    tport w50080e52b93fd03f
c31t50000394281BBA1Ad0s0
    tport w50000394281bba1a
    lun 0
/pci@8100/pci@4/pci@0/pci@1/pci@0/pci@0/pci@0/pci@1/pci@0/pci@10/pci@0/pci@0/LSI,sas@0/iport@f/enclosure@w50080e52b93fd03d,0
    tport w50080e52b93fd03d
    lun 0
 :
Workaround This has been modified with SRU 11.2.11.5.0.
This problem may occur even after SRU 11.3.4.5.0 is applied. In such a case, follow the procedure in "10.12  Saving/Restoring Logical Domain Configuration Information in an XML File" in the Fujitsu SPARC M12 and Fujitsu M10/SPARC M10 System Operation and Administration Guide to save the logical domain configuration information. Then, restore it.
[Alternative method]
If you execute vHBA related commands such as ldm add-vsan, specify the device path instead of the device alias.
[Example]
# ldm add-vsan /pci@8100/pci@4/pci@0/pci@1/pci@0/pci@0/pci@0/pci@1/pci@0/pci@10/pci@0/pci@0/LSI,sas@0/iport@f vsan0 ldom1
Bug 20646928
Model SPARC M12-2S, SPARC M10-4S
Description If you perform dynamic deletion with the dynamic reconfiguration function of the physical partition for a system board with the system volume located in the following environment, system board deletion processing may fail.
[Problem occurrence conditions]
1) A ZFS mirror of the system volume has been created using multiple disks, and
2) the mirroring disk and mirrored disk are located on different system boards, and
3) the system board to which the system volume is assigned has been dynamically deleted.
[Example of output message]
XSCF> deleteboard -c disconnect -m unbind=resource 00-0
PSB#00-0 will be unconfigured from PPAR immediately. Continue?[y|n] :y
All domains are temporarily suspended, proceed?[y|n] :y
Start unconfigure preparation of PSB. [1200sec]
0end
Unconfigure preparation of PSB has completed.
Start unconfiguring PSB from PPAR. [7200sec]
0....\

The removal of PCIE0 from the domain primary failed.
Error message from svc:/ldoms/agents in domain primary:
ERROR: devices or resources are busy.
end
PSB#00-0 could not be unconfigured from PPAR-ID 0
due to operating system or Logical Domains Manager error.
Workaround This has been modified with SRU 11.3.5.6.0.
Bug 25976819
Model SPARC M12-1, SPARC M12-2, SPARC M12-2S, SPARC M10-1, SPARC M10-4, SPARC M10-4S
Description In an environment with Oracle VM Server for SPARC 3.3 or later installed on the control domain, a logical domain may not recognize the replacement CPU after a faulty CPU was automatically replaced.
Workaround This has been modified with SRU 11.3.23.5.0.
[How to restore]
Reboot the logical domain where the problem occurred.
Bug 26052693
Model SPARC M12-2S
Description In an environment with Oracle VM Server for SPARC 3.4.0.3 (SRU 11.3.18.6.0) or later installed on the control domain, if you reboot a logical domain after dynamically reconfiguring physical partitions with the XSCF deleteboard(8) command, then a panic on the logical domain may persist.
[Panic message example]
panic[cpu0]/thread=xxxxxxxx: tilelet_assign_cb: assigning pfns [4a0000, 4a8000) to mgid 39, mnodeid 57: pachunk 12 already assigned to mgid 3b, mnodeid 59
Workaround This has been modified with SRU 11.3.23.5.0.
[How to restore]
Take action as follows for each logical domain where a panic occurred.
- If a panic occurs on the control domain

1. Stop the physical partition.

2. With the XSCF addboard(8) command, return the physical partition to the state before the reconfiguration.

3. Start the physical partition again.

  [Example]
  XSCF> poweroff -y -p 0
  XSCF> addboard -y -c configure -m bind=none -p 0 01-0
  XSCF> poweron -y -p 0
- If a panic occurs on a guest domain
Unbind the resource, and bind the resource again.

  [Example]
  primary# ldm stop-domain guest
  primary# ldm unbind-domain guest
  primary# ldm bind-domain guest
  primary# ldm start-domain guest
Bug 26176351
Model SPARC M12-1, SPARC M12-2, SPARC M12-2S
Description On a logical domain with SRU 11.3.23.5.0 or later installed, even when the power-saving operation of the physical partition is set to "elastic", the CPU frequency may not decrease. This is because Solaris Power Aware Dispatcher (PAD) does not work for the CPU that the logical domain uses.
Workaround This has been modified with SRU 11.3.23.5.0.
Install SRU 11.3.23.5.0 or later on the control domain.
[How to restore]
After starting all of the logical domains on which SRU 11.3.23.5.0 or later is installed, set the power-saving operation to "disabled" with the XSCF setpparmode(8) command. Then, set the power-saving operation to "elastic" again.
[Example]
XSCF> setpparmode -p 0 -y -m powermgmt_policy=disabled
XSCF> setpparmode -p 0 -y -m powermgmt_policy=elastic
Bug 27112303
Model SPARC M12-1, SPARC M12-2, SPARC M12-2S, SPARC M10-1, SPARC M10-4, SPARC M10-4S
Description In an environment with Oracle VM Server for SPARC 3.1.0.1 or later installed on the control domain, the power-saving operation of the physical partition does not work as "elastic" if the following conditions are met:
1) the power-saving operation of the physical partition is set to "elastic"; and
2) the physical partition is operating; and
3) the physical partitions have been dynamically reconfigured with the XSCF deleteboard(8) command or addboard(8) command.

Or
3) the number of CPU Activations has been changed with the XSCF setcod(8) command.
Workaround There is no effective workaround.
[How to restore]
Set the power-saving operation to "disabled" with the XSCF setpparmode(8) command and then set the power-saving operation to "elastic" again.
[Example]
- SPARC M12 system

  XSCF> setpparmode -p 0 -y -m powermgmt_policy=disabled
  XSCF> setpparmode -p 0 -y -m powermgmt_policy=elastic
- SPARC M10 system

  XSCF> setpparmode -p 0 -y -m elastic=off
  XSCF> setpparmode -p 0 -y -m elastic=on
BugID -
Model SPARC M12-1, SPARC M12-2, SPARC M12-2S, SPARC M10-1, SPARC M10-4, SPARC M10-4S
Description When a CPU fails, the fmd daemon may accidentally put another CPU in the faulted state. In that case, the faulty CPU will not be in the faulted state.
There is no way to check whether this problem will occur.
Workaround Every time you boot the control domain, confirm that the ldmd service is online, and then restart the fmd service.
1) Confirm that the ldmd service is online.
primary# svcs ldmd
STATE STIME FMRI
online 15:42:57 svc:/ldoms/ldmd:default

2) Restart the fmd service.
primary# svcadm restart fmd

3) Confirm that the fmd service is online.
primary# svcs fmd
STATE STIME FMRI
online 15:43:44 svc:/system/fmd:default0