Sun Microsystems, Inc.  Oracle System Handbook - ISO 7.0 May 2018 Internal/Partner Edition
   Home | Current Systems | Former STK Products | EOL Systems | Components | General Info | Search | Feedback

Asset ID: 1-77-2179881.1
Update Date:2017-01-18
Keywords:

Solution Type  Sun Alert Sure

Solution  2179881.1 :   SPARC T4, T5/M5/M6 or T7/S7/M7 Platforms Configured Explicitly for Cross-CPU Migration may Experience Memory Corruption in Oracle VM Server for SPARC Guest Domains and Solaris Kernel Zones  


Related Items
  • SPARC M5-32
  •  
  • SPARC T5-1B
  •  
  • SPARC T7-4
  •  
  • SPARC M7-8
  •  
  • Netra SPARC T4-1 Server
  •  
  • Sun Software - Generic
  •  
  • Solaris Operating System
  •  
  • SPARC M7-4
  •  
  • SPARC S7-2L
  •  
  • SPARC T4-2
  •  
  • Netra SPARC T5-1B Server Module
  •  
  • SPARC S7-2
  •  
  • SPARC T5-2
  •  
  • SPARC T7-2
  •  
  • SPARC T4-1
  •  
  • SPARC T4-1B
  •  
  • SPARC T5-4
  •  
  • Netra SPARC T4-2 Server
  •  
  • SPARC M7-16
  •  
  • SPARC M6-32
  •  
  • SPARC T7-1
  •  
  • SPARC T5-8
  •  
  • Netra SPARC T4-1B
  •  
  • Sun Hardware - Generic
  •  
  • SPARC T4-4
  •  
Related Categories
  • PLA-Support>Sun Systems>Sun_Other>Sun Collections>SN-OTH: Sun Alert
  •  




In this Document
Description
Occurrence
Symptoms
Workaround
Patches
History
References


Applies to:

SPARC T5-1B
SPARC T5-2
SPARC T5-8
SPARC T5-4
SPARC T7-2
SPARC
Netra S7-2
Netra S7-2M
For a complete list of all systems affected, see the "Products" section at the end of this document
_____________________________________________________________________________



Date of Workaround Release: 06-Sep-2016

Original Date of Resolved Release: 19-Dec-2016
10-Jan-2017: Solaris 10 patch withdrawn

Date of Resolved Release: 17-Jan-2017
________________________________________

Description

On SPARC T4, T5/M5/M6 or T7/S7/M7 platforms that are configured explicitly for cross-CPU migration, Oracle VM Server for SPARC (LDoms) guest domains, and Solaris kernel zones, running either Solaris 10 or Solaris 11 may, in rare circumstances, experience memory corruption which could lead to application or system failure or to customer data corruption. This may only occur when the 'cpu-arch' property value is set to 'generic' or 'migration-class1'. This setting causes incorrect architecture dependent libraries to be used. This is not the default setting but has been set in some configurations where guest domains and kernel zones are required to migrate in multiple-architecture environments.

Occurrence

This issue can occur in the following releases:

SPARC: T4, T5/M5/M6 or T7/S7/M7 Platforms

  • Solaris 10 without patch 150400-46
  • Solaris 11.0.0.2.0 through 11.3.12.4.0

Note: This issue only affects Oracle VM Server for SPARC guest domains and Solaris kernel zones if 'cpu-arch' is set to 'generic' or 'migration-class1'. Determining if a system has this setting is dependent upon the feature being used.

For Oracle VM Server for SPARC (LDoms) guest domains:

To determine if guest domains are vulnerable to this issue, run the following command on the primary domain for each of the guest domains:

      # ldm list -l <guest-domain> | grep cpu-arch

If the output contains:

      cpu-arch=generic
or:
      cpu-arch=migration-class1

then that guest domain is vulnerable to this issue.

For Solaris kernel zones:

To determine if Solaris kernel zones are at risk, run the following command on the global zone for each of the kernel zones:

      # zonecfg -z <zonename> info | grep cpu-arch

If the output contains:

      cpu-arch=generic
or:
      cpu-arch=migration-class1

then that kernel zone is vulnerable to this issue.

Symptoms

There are no predictable symptoms that would indicate the described issue has occurred. If the issue described occurs, applications may fail in unpredictable ways or customer data may be corrupted. 

Workaround

To work around the memory corruption issue, it is necessary to correct the value for 'cpu-arch' for each guest domain or clear the values of cpu-arch for each kernel zone. The means for doing this depends upon the feature being used as shown below.

Note: There is no workaround to allow a system to perform live kernel zone or guest domain migration in certain multi-CPU architecture environments until this issue has been resolved.

For Oracle VM Server for SPARC (LDoms) guest domains:

To avoid this issue on Oracle VM Server for SPARC guest domains, for each guest domain that is vulnerable to this issue, change the property value to 'cpu-arch=native'.

Note: Changing this property requires that the guest domain be stopped first as shown below for guest domain 'ldg1':

  1. Stop the guest domain

      # ldm stop ldg1
      LDom ldg1 stopped

  2. Change the value of cpu-arch

      # ldm set-domain cpu-arch=native ldg1

  3. Optionally verify the change:

      # ldm list -l ldg1 | grep cpu-arch
      cpu-arch=native

  4. Restart the guest domain:

      # ldm start ldg1

For Solaris kernel zones:

To avoid this issue on Solaris kernel zones, for each impacted kernel zone, clear the cpu-arch property and reboot the kernel zone.

Note: The kernel zone must be rebooted after the cpu-arch is cleared, as in the following:

  1. Clear the value of cpu-arch:

      # zonecfg -z <zonename> clear cpu-arch

  2. Reboot the kernel zone:

      # zoneadm -z <zonename> reboot

Resolution

This issue is addressed in the following releases:

SPARC Platform

  • Solaris 10 with patch 150400-46 or later
  • Solaris 11.3.13.4.0 or later

Note: Solaris 10 patch 150400-44 which was originally listed as the fix for Solaris 10 has been withdrawn. (There is no release for -45).

Patches

<Patch:150400-46>

History

06-Sep-2016: Document released, status is Workaround
23-Nov-2016: Updated for Solaris 11 release/fix
29-Nov-2016: Updated for Solaris 10 T-Patch release
19-Dec-2016: Updated for Solaris 10 final Patch release, issue is Resolved
10-Jan-2017: Solaris 10 patch 150400-44 has been withdrawn - issue not resolved for S10
17-Jan-2017: Solaris 10 patch 150400-46 released, issue is Resolved

Questions regarding any portion of this document should be addressed to
sunalertpublication_us_group@oracle.com and copy the submitter and
responsible engineer listed below.

Internal Contributor/Submitter: justin.frank@oracle.com
Internal Eng Responsible Engineer: alejandro.j.jimenez@oracle.com
Oracle Knowledge Analyst: david.mariotto@oracle.com
Internal Eng Business Unit Group: Systems
Internal Associated SRs: 3-12795813601 3-12801862811
Internal Resolution Patches: 150400-46

References

<BUG:23731895> - ON LDOM, ORACLE DATABASE TABLE IN MEMORY BECOMES CORRUPTED


Attachments
This solution has no attachment
  Copyright © 2018 Oracle, Inc.  All rights reserved.
 Feedback