![]() | Oracle System Handbook - ISO 7.0 May 2018 Internal/Partner Edition | ||
|
|
![]() |
||||||||||||||||||||||||
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
In this Document
Applies to:SPARC T5-1BSPARC 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 ________________________________________ DescriptionOn 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. OccurrenceThis issue can occur in the following releases: SPARC: T4, T5/M5/M6 or T7/S7/M7 Platforms
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 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 then that kernel zone is vulnerable to this issue. SymptomsThere 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. WorkaroundTo 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 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 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
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> History06-Sep-2016: Document released, status is Workaround Questions regarding any portion of this document should be addressed to Internal Contributor/Submitter: justin.frank@oracle.com References<BUG:23731895> - ON LDOM, ORACLE DATABASE TABLE IN MEMORY BECOMES CORRUPTEDAttachments This solution has no attachment |
||||||||||||||||||||||||
|