Asset ID: |
1-72-1968668.1 |
Update Date: | 2015-02-27 |
Keywords: | |
Solution Type
Problem Resolution Sure
Solution
1968668.1
:
SuperCluster: machine panic in kobj_load_module
Related Items |
- Solaris Operating System
- Oracle SuperCluster M6-32 Hardware
- Oracle Database - Enterprise Edition
- Oracle SuperCluster T5-8 Hardware
- Oracle SuperCluster T5-8 Half Rack
- SPARC SuperCluster T4-4
|
Related Categories |
- PLA-Support>Eng Systems>Exadata/ODA/SSC>SPARC SuperCluster>DB: SuperCluster_EST
|
Created from <SR 3-10138544051>
Applies to:
Oracle SuperCluster M6-32 Hardware - Version All Versions to All Versions [Release All Releases]
SPARC SuperCluster T4-4 - Version All Versions to All Versions [Release All Releases]
Oracle SuperCluster T5-8 Hardware - Version All Versions to All Versions [Release All Releases]
Oracle SuperCluster T5-8 Half Rack - Version All Versions to All Versions [Release All Releases]
Oracle Database - Enterprise Edition - Version 11.2.0.4 to 12.1.0.2 [Release 11.2 to 12.1]
Oracle Solaris on SPARC (64-bit)
Symptoms
machine panic in kobj_load_module
dmesg form core and panic thread
-0.64s| [Oracle OKS] mallocing log buffer, size=10485760
-0.63s| [Oracle OKS] log buffer = 0x100809aae028, size 10485760
-0.63s| NOTICE: [Oracle OKS] ODLM hash size 16384
|
-0.63s| NOTICE: OKSK-00004: Module load succeeded. Build information: (LOW DEBUG) USM_11.2.0.4.0ACFSPSU_SOLARIS.SPARC64_140725 2014/08/06 22:57:36
-0.21s| pseudo-device: oracleadvm0
-0.21s| oracleadvm0 is /pseudo/oracleadvm@0
-0.21s| NOTICE: ADVMK-00001: Module load succeeded. Build information: (LOW DEBUG) - USM_11.2.0.4.0ACFSPSU_SOLARIS.SPARC64_140725 built on 2014/08/06 23:02:23.
0.01s|
| panic[cpu48]/thread=2a106d1fc60:
0.01s| vmem_xalloc(): size == 0
0.02s|
|
0.02s| 000002a106d1f4b0 genunix:vmem_xalloc+a34 (300009b4da8, 0, 400000, 0, 300009b5008, ffffffffffffffff)
0.03s| %l0-3: 0000000000000008 ffffffffffffffff 00000000012e8c00 00000300009b59f8
| %l4-7: fffffffffffffff8 0000000000000000 0000000000000000 0000000000100000
0.06s| 000002a106d1f690 genunix:vmem_alloc+108 (300009b4da8, 0, 100, 0, ffffffffffffffff, 0)
0.08s| %l0-3: 0000000000004000 0000100505c15e38 0000000000000001 0000000000000000
| %l4-7: 0000000000010000 0000000000000000 0000000000000000 0000000000000000
0.10s| 000002a106d1f750 unix:kobj_text_alloc+c (300009b4da8, 0, 1038f800, 0, 0, 200000)
0.12s| %l0-3: 0000000000003000 fffffffffffffff8 000000000000000f 0000000000200002
| %l4-7: 0000000000000000 0000000000000007 0000000000000000 0000000000000007
0.15s| 000002a106d1f810 unix:get_progbits+164 (1006fbbf9e00, 100720cddc70, 1038f800, 300009b4da8, 106a6c00, 0)
0.17s| %l0-3: ffffffffffffffff 00001007f838cce0 00001006de8e4178 000010067b51e928
| %l4-7: 000000001054c6c0 0000000000000000 000000001038f940 0000000000000000
0.19s| 000002a106d1f8c0 unix:kobj_load_module+330 (1006749ea1b8, 100720cddc70, 3c0, 46, 1, 1006fbbf9e00)
0.21s| %l0-3: 00000000000003c0 000010067b4f3870 000010067b4f3860 0000000010656800
| %l4-7: 0000000010396800 000000000000000f 0000000000000000 00001006fbbf9e08
0.24s| 000002a106d1f970 genunix:modload_thread+5c (2a1008332e0, 0, 2a106d1fa48, 1038f9c0, 1, 12ee000)
0.25s| %l0-3: 000003000011a000 0000000000000000 0000000000000000 000002a10775dc60
| %l4-7: 0019827c416f94d4 0000000000000004 0000000000000001 0000000006d95ae3
0.28s|
==== panic kernel thread: 0x2a106d1fc60 PID: 0 on CPU: 48 ====
cmd: sched(genunix:modload_thread)
t_procp: 0x1038f9c0 (proc_sched)
p_as: 0x10396a48 (kas)
p_zone: 0x106a4158 (global)
t_stk: 0x2a106d1fa50 sp: 0x1054ba01 t_stkbase: 0x2a106d10000
t_pri: 99 (SYS) pctcpu: 0.000176
t_transience: 10 (TRANSIENT) t_wkld_flags: 0
t_cpupart: 0x1054c6e8(0) last CPU: 48
idle: 450040 hrticks (0.000450040s)
start: Sat Jan 17 20:04:01 2015
age: 0 seconds (0 seconds)
t_state: TS_ONPROC
t_flag: 0x10808 (T_TALLOCSTK|T_PANIC|T_PUSHPAGE)
t_proc_flag: 0 (none set)
t_schedflag: 3 (TS_LOAD|TS_DONT_SWAP)
t_acflag: 0 (none set)
p_flag: 1 (SSYS)
pc: unix:panicsys+0x48: call unix:setjmp
void unix:panicsys+0x48((const char *)0x12e8f60, (va_list)0x2a106d1f538, (struct regs *)0x1054c3c0, (int)1, 0x4480001600, , , , , , , , 0x12e8f60, 0x2a106d1f538)
unix:vpanic_common+0x78(0x12e8f60, 0x2a106d1f538, 0, 1, 2, 0)
void unix:panic+0x1c((const char *)0x12e8f60, (void *)0, 8, 0, 0, 0, ...)
void *genunix:vmem_xalloc+0xa34((vmem_t *)0x300009b4da8, (size_t)0, (size_t)8, (size_t)0, (size_t)0, (void *)0, (void *)0, (int))
void *genunix:vmem_alloc+0x108((vmem_t *)0x300009b4da8, (size_t)0, (int)0x100)
caddr_t unix:kobj_text_alloc+0xc((vmem_t *)0x300009b4da8, (size_t)0)
unix:get_progbits+0x164(0x1006fbbf9e00, 0x100720cddc70)
unix:kobj_load_module+0x330(0x1006749ea1b8, 1)
void genunix:modload_thread+0x5c((struct loadmt *)0x2a1008332e0)
unix:thread_start+4()
-- end of kernel thread's stack --
Changes
Install, Upgrade or usage of 11.2.0.4 -12.1.0.2 DB .
Cause
This is due to the Unpublished bug 18185024
<Bug 18185024> - t5 ssc: machine panic in kobj_load_module during grid install
NOTE: This can happen outside of the install process as well
Solution
Contact support to obtain patch for Unpublished Bug 18185024
References
<BUG:18185024> - T5 SSC: MACHINE PANIC IN KOBJ_LOAD_MODULE DURING GRID INSTALL
Attachments
This solution has no attachment