Error Message

The following two panic stacks may be observed:

Mar 25 11:23:11 systemA ^Mpanic[cpu12]/thread=2a1038d5b00:
Mar 25 11:23:11 systemA unix: [ID 237512 kern.notice] bad stack overflow at TL 1
Mar 25 11:23:11 systemA unix: [ID 100000 kern.notice]
Mar 25 11:23:11 systemA unix: [ID 293396 kern.notice] %tl %tpc              %tnpc             %tstate        %tt
Mar 25 11:23:11 systemA unix: [ID 785305 kern.notice]  1  0000000010afe220  0000000010afe224  4480001601        031
Mar 25 11:23:11 systemA unix: [ID 418325 kern.notice]     %gl: 00  %ccr: 44  %asi: 80  %cwp: 1  %pstate: 16
Mar 25 11:23:11 systemA unix: [ID 225901 kern.notice]     %gl: 01
Mar 25 11:23:11 systemA unix: [ID 216294 kern.notice] %g0-3: 0000000000000000 000000000000000a 000002a1038d4ce8 0000000015081c6a
Mar 25 11:23:11 systemA unix: [ID 600269 kern.notice] %g4-7: 0000000015081c6a 0000000000000001 0000000000000000 0000000000000031
Mar 25 11:23:11 systemA unix: [ID 225901 kern.notice]     %gl: 00
Mar 25 11:23:11 systemA unix: [ID 216294 kern.notice] %g0-3: 0000000000000000 0000000000002000 0000000000000000 000000000012d4be
Mar 25 11:23:11 systemA unix: [ID 600269 kern.notice] %g4-7: 00006400533fe000 0000000000000000 0000000000000000 000002a1038d5b00
Mar 25 11:23:11 systemA unix: [ID 531632 kern.notice] Register window 1, caller volkio_to_iomem_copy+114
Mar 25 11:23:11 systemA unix: [ID 454034 kern.notice] %o0-3: 000002a1038d4ce8 0000000000002000 000000007fffffff 0000000000000000
Mar 25 11:23:11 systemA %o4-7: 000064003a46fcd0 0000000000000001 000002a1038d4261 000000007b613acc
Mar 25 11:23:11 systemA unix: [ID 960796 kern.notice] %l0-3: 0000000000001000 ffffffffffffffff 000000000000010c 0000000000000100
Mar 25 11:23:11 systemA %l4-7: 0000000000000100 1234567f00000005 0000000000000040 0000000010afc400
Mar 25 11:23:11 systemA unix: [ID 567577 kern.notice] %i0-3: 800064007d5ab9e8 00006400533fe000 0000000000001000 000064003a46fcd0
Mar 25 11:23:11 systemA %i4-7: fffffffffffff000 0000000000000001 000002a1038d4421 000000007b6496e8
Mar 25 11:23:11 systemA unix: [ID 531632 kern.notice] Register window 0, caller volsio_stabilize+f0
Mar 25 11:23:11 systemA unix: [ID 960796 kern.notice] %l0-3: 0000000070f86b60 000064007089f818 800064007d5ac9e8 000002a1038d4ce8
Mar 25 11:23:11 systemA %l4-7: 800064007d5ab9e8 0000000000000000 0000000000004010 000064007dd63ab0
Mar 25 11:23:11 systemA unix: [ID 567577 kern.notice] %i0-3: 0000000000001000 0000000000001000 0000000000000000 0000000000001000
Mar 25 11:23:11 systemA %i4-7: 0000000000004000 0000000000000000 000002a1038d4511 000000007b5b9d34
Mar 25 11:23:11 systemA unix: [ID 531632 kern.notice] Register window 7, caller vol_mv_write_start+9cc
Mar 25 11:23:11 systemA unix: [ID 960796 kern.notice] %l0-3: 0000640068bb6c00 0000000000000008 0000000000000000 0000000000000001
Mar 25 11:23:11 systemA %l4-7: fffffffffffffffe 0000000000000002 0000000000000006 0000000000011180
Mar 25 11:23:11 systemA unix: [ID 567577 kern.notice] %i0-3: 0000000000000000 0000640070259a70 000064007d5aa6c8 000002a1038d5070
Mar 25 11:23:11 systemA %i4-7: 00006400702598c0 000064007dd63ab0 000002a1038d45d1 000000007b502e28
Mar 25 11:23:11 systemA unix: [ID 654429 kern.notice] Register windows were not flushed to memory. Stack commands may show stale frames.

or 

panic[cpu42]/thread=2a10c57bb00: BAD TRAP: type=30 rp=2a10c57b200 addr=80000a0069f38000 mmu_fsr=9

sched: data access exception:
MMU sfsr=9: Data or instruction address out of range context 0x0
pid=0, pc=0x10af43a4, sp=0x2a10c57aaa1, tstate=0xf2001607, context=0x0
g1-g7: 2000, 0, 18de1, a006772e000, 0, 1c, 2a10c57bb00

000002a10c57af30 unix:die+fc (30, 2a10c57b200, 80000a0069f38000, 9, 20056400, 1)
  %l0-3: 000000002088f400 0000000000000000 0000000000001000 0000000000000000
  %l4-7: 0000000000002000 000000001012e400 000002a10c57aff0 0000000070afdf70
000002a10c57b010 unix:trap+7d4 (2a10c57b200, 10000, 900000030, 9, 0, 2a10c57b108)
  %l0-3: 0000000000000000 0000000000000000 80000a0069f38000 0000000020336540
  %l4-7: 0000000000010000 0000000000000009 0000000000001c00 80000a0069f38000
000002a10c57b150 unix:ktl0+7c (2a10c57b528, 2000, 7fffffff, 0, a00673fe258, 1)
  %l0-3: 0000030000052000 00000000203375c8 00000000f2001607 00000000100402d0
  %l4-7: 000000001014b950 0000000000000000 0000000000000000 000002a10c57b201
000002a10c57b2a0 vxio:voliomem_range_iter+c (80000a0069f38b78, a006772e000, 1000, b, 80, 1)
  %l0-3: 0000000000001000 ffffffffffffffff 000000000000010c 0000000000000100
  %l4-7: 0000000000000100 0000000000000000 0000000000000040 0000000000000000
000002a10c57b460 vxio:volkio_to_iomem_copy+114 (1000, 1000, 0, 1000, 4000, 0)
  %l0-3: 0000000070abcb60 00000a00a23103f0 80000a0069f39b78 000002a10c57b528
  %l4-7: 80000a0069f38b78 0000000000000000 0000000000004010 00000a00db223680
000002a10c57b550 vxio:volsio_stabilize+f0 (0, a00a1af3a70, a009cc4bb18, 2a10c57b8b0, a00a1af38c0, a00db223680)
  %l0-3: 00000a009ba80c00 0000000000000008 0000000000000000 0000000000000001
  %l4-7: fffffffffffffffe 0000000000000002 0000000000000006 0000000000011180
000002a10c57b610 vxio:vol_mv_write_start+9cc (a00a1af38c0, 2a10c57b8b0, 0, 2, 0, a00d8140000)
  %l0-3: 0000000000000000 0000000000070800 0000000000070aa2 0000000070aa2000
  %l4-7: 0000000070aa2f18 0000000000000004 0000000000010000 0000000000000000
000002a10c57b750 vxio:voliod_iohandle+30 (a00a1af38c0, 1, 2a10c57b8b0, 70b00000, 70b01050, 70b01)
  %l0-3: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
  %l4-7: 0000000000000001 0000000000000000 0000030000052000 0000000000000000
000002a10c57b800 vxio:voliod_loop+26c (0, 70800, 70b6ac30, 70abd010, 70abc3b0, 70b00840)
  %l0-3: 0000000000000002 fffffffffffffbff 0000000000070abc 0000000000000000
  %l4-7: 0000000000070800 0000000000000000 0000000000000000 00000a00a1af38c0

The cause of the panics is as yet unknown. However it has been determined that the panics do not occur if there are no DCOs associated with the mirrored volumes used by Oracle. Mirrored volumes not used by Oracle are not affected.

At the moment the current workaround is to remove the DCOs associated with mirrored volumes used by Oracle. 

Once the DCOs have been removed, it will be necessary to create the /etc/default/vxassist file with the following line:

logtype=none

This will prevent the creation of DCOs when using the vxassist command to create a mirrored volume or when adding a mirror to an existing volume. 

Also since volume snapshots depend on DCOs, the volume snapshot functionality will be affected by the absence of DCOs. It should be noted that the use of the vxsnap command to create a volume snapshot will automatically create a DCO, so it is not recommended at this time to create volume snapshots on mirrored volumes used by Oracle.

Veritas has identified the root-cause of the panic and a hotfix has been created to resolve the issue. 

Please contact Veritas Technical Support for details of the hotfix if needed.