- 最后登录
- 2023-8-16
- 在线时间
- 1686 小时
- 威望
- 2135
- 金钱
- 50532
- 注册时间
- 2011-10-12
- 阅读权限
- 200
- 帖子
- 5207
- 精华
- 39
- 积分
- 2135
- UID
- 2
|
2#
发表于 2011-12-26 20:17:47
诊断信息:
1. 你安装的是 11.2 GI的哪个版本? 11.2.0.2 or 11.2.0.3 or 11.2.0.1 ?
2. MOS上的 相关信息
Windows: Can not Install Clusterware on x64 with More Than 32 Processors/Cores/Threads [ID 1177387.1]
- Applies to:
- Oracle Server - Enterprise Edition - Version: 10.2.0.1 to 11.2.0.2 - Release: 10.2 to 11.2
- Microsoft Windows x64 (64-bit)
- Symptoms
- Oracle Clusterware installation(10.2 - 11.1 CRS or 11.2 Grid Infrastructure) fails with a blue screen, WinDbg shows BugCheck D1 (DRIVER_IRQL_NOT_LESS_OR_EQUAL) against orafencedrv.sys or orafenceservice.sys or ntkrnlmp.exe on x64 Windows cluster with more than 32 Logical Processor(s).
- OR
- Oracle Clusterware fails to start with same symptoms after Logical Processor(s) are increased to above 32
- To find out the number of Logical Processor(s):
- ~~~~
- Run "msinfo32" from the command line or via the "Run" option.
- There will be a section like this.
- ~~~~~
- ...
- System Type x64-based PC
- Processor Intel(R) Xeon(R) CPU E7540 @ 2.00GHz, 2000 Mhz, 6 Core(s), 12 Logical Processor(s)
- Processor Intel(R) Xeon(R) CPU E7540 @ 2.00GHz, 2000 Mhz, 6 Core(s), 12 Logical Processor(s)
- Processor Intel(R) Xeon(R) CPU E7540 @ 2.00GHz, 2000 Mhz, 6 Core(s), 12 Logical Processor(s)
- Processor Intel(R) Xeon(R) CPU E7540 @ 2.00GHz, 2000 Mhz, 6 Core(s), 12 Logical Processor(s)
- ....
- This shows 4 physical CPUs each of which has 12 Logical Processors. This equals 48 ( 4 x 12 ) processors as far as the orafenceservice.sys is concerned and will cause the problem mentioned in this note.
- Cause
- The issue is caused by bug 10637621, relevant information can be seen in the following bugs:
- Bug:9901433 BLUE SCREEN OCCURED DURING INSTALLING CLUSTERWARE for 11.1.0.7.
- Bug:10027132 DURING INSTALLATION GI WIN X64 11.2 SERVER BUGCHECKS 0XD1 IN ORAFENCESERVIC.SYS and was determined to be a duplicate of Bug:9901433.
- Bug:10637621 11.2.0.2 WIN GI INSTALL @ BUGCHECKS WITH 0XD1 IN ORAFENCESERVICE.SYS
- The x64 fencing code currently has a limit of 32 processors.
- Solution
- bug 10637621 is fixed in :
- 10.2.0.4 Patch 43 patch 11731126
- 10.2.0.5 Patch 9 patch 12332704
- 11.2.0.2 Patch 3 patch 11731184
- It's recommended to apply latest patches to fix the issue; if patch is unavailable, please engage Oracle Support to request.
- As the issue affects initial clusterware configuration, here's a few workarounds:
- 1. Reduce number of CPUs to below 32, install clusterware, apply necessary patches and restore original number of CPUs.
- 2. OR install on node with less than 32 CPU, apply necessary patches and clone it to target cluster.
- 3. Or for 11.2.0.2 and above, utilize new feature Software Update Option to apply the patch before clusterware is configured. Refer to screenshots for details.
- References
- BUG:10027132 - DURING INSTALLATION GI WIN X64 11.2 SERVER BUGCHECKS 0XD1 IN ORAFENCESERVIC.SYS
- BUG:10637621 - 11.2.0.2 WIN GI INSTALL BUGCHECKS WITH 0XD1 IN ORAFENCESERVICE.SYS
- BUG:9901433 - BLUE SCREEN OCCURED DURING INSTALLING CLUSTERWARE.
复制代码
Hdr: 10027132 11.2.0.1 PCW 11.2.0.1 OSD PRODID-5 PORTID-233 9901433
Abstract: DURING INSTALLATION GI WIN X64 11.2 SERVER BUGCHECKS 0XD1 IN ORAFENCESERVIC.SYS
----
PROBLEM:
--------
Windows Win2008 R2 x64
Two Node Dell 910 cluster.
During the installation process of 11.2 GI, when the GI Configuration
Assistant runs the server on which the installer runs will bug check with xD1
in OraFenceService.SYS ( OraFenceService+5456 )
This will occur no matter which of the two nodes is used as install node.
This is also reproducable on another idential 2 node cluster.
Unless the server is configured to not reboot on a bugcheck the server will
go into a tight reboot cycle always with the same bugcheck code on the same
driver.
DIAGNOSTIC ANALYSIS:
--------------------
From the buchcheck analysis it appears that the OraFenceService.sys is loaded
and then tries to write to NonPagedPoolExpansionStart but this fails.
-------
WRITE_ADDRESS: unable to get nt!MmNonPagedPoolExpansionStart
-------
The same issue occurs when the server goes into a reboot cycle after the
initial bugcheck during the GI install.
WORKAROUND:
-----------
None.
RELATED BUGS:
-------------
REPRODUCIBILITY:
----------------
TEST CASE:
----------
STACK TRACE:
------------
******************************************************************************
*
*
*
* Bugcheck Analysis
*
*
*
******************************************************************************
*
DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pageable (or completely invalid) address at
an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If kernel debugger is available get stack backtrace.
Arguments:
Arg1: 0000000000000000, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000008, value 0 = read operation, 1 = write operation
Arg4: 0000000000000000, address which referenced memory
Debugging Details:
------------------
WRITE_ADDRESS: unable to get nt!MmNonPagedPoolExpansionStart
0000000000000000
CURRENT_IRQL: 2
FAULTING_IP:
+0
00000000`00000000 ?? ???
PROCESS_NAME: System
DEFAULT_BUCKET_ID: VISTA_RC
BUGCHECK_STR: 0xD1
TRAP_FRAME: fffff88002c78d60 -- (.trap fffff88002c78d60)
............
MODULE_NAME: OraFenceService
IMAGE_NAME: OraFenceService.SYS
DEBUG_FLR_IMAGE_TIMESTAMP: 4b4fd03c
SYMBOL_NAME: OraFenceService+5456
FAILURE_BUCKET_ID: X64_0xD1_W_OraFenceService+5456
BUCKET_ID: X64_0xD1_W_OraFenceService+5456
Followup: MachineOwner
--------- |
|