As soon as new storage is zoned to the Solaris system, the machine panics. The resulting panic stack is displayed below:
CAT(vmcore.50/11V)> panic
panic on CPU 99
panic string: BAD TRAP: type=31 rp=2a101c533a0 addr=258 mmu_fsr=0 occurred in module "unix" due to a NULL pointer dereference
==== panic kernel thread: 0x2a101c53b00 PID: 0 on CPU: 99 ====
cmd: sched(vxdmp:dmp_daemons_loop)
t_procp: 0x20674e58 (proc_sched)
p_as: 0x20676658 (kas)
p_zone: 0x20906ed8 (global)
t_stk: 0x2a101c538d0 sp: 0x20672f41 t_stkbase: 0x2a101c4c000
t_pri: 60 (SYS) pctcpu: 0.001514
t_transience: 10 (TRANSIENT)
t_cpupart: 0x2051e8a8(0) last CPU: 99
idle: 333300 nsec (0.000333300s)
start: Mon Nov 24 01:49:55 2025
age: 280 seconds (4 minutes 40 seconds)
t_state: TS_ONPROC
t_flag: 0x808(T_TALLOCSTK|T_PANIC)
t_proc_flag: 0 (none set)
t_schedflag: 3 (TS_LOAD|TS_DONT_SWAP)
t_acflag: 4 (TA_NO_ACCOUNTING)
p_flag: 1 (SSYS)
pc: unix:panicsys+0x40: call unix:setjmp
void unix:panicsys+0x40((const char *)0x10132d41, (va_list)0x2a101c53168, (struct regs *)0x206738f0, (int)1, 0x9900081603, , , , , , , , 0x10132d41, 0x2a101c53168)
unix:vpanic_common+0x78(0x10132d41, 0x2a101c53168, 0x7e01, 0x50a, 0x20, 0x20)
void unix:panic+0x1c((const char *)0x10132d41, 0x31, 0x2a101c533a0, 0x258, 0, 0x20875da7, 0x10132d8e, ...)
int unix:die+0x8c((unsigned int)0x31, (struct regs *)0x2a101c533a0, (caddr_t)0x258, (uint_t)0)
void unix:trap+0xb54((struct regs *), (caddr_t)0x258, (uint32_t), (uint32_t))
unix:ktl0+0x7c()
-- trap data type: 0x31 (data access MMU miss) rp: 0x2a101c533a0 LEAF --
addr: 0x258
pc: 0x1002a4a4 unix:mutex_enter+4: casxa [%o0] ASI_P, %g0, %o1 ( casx [%o0] %g0, %o1 )
npc: 0x1002a4a8 unix:mutex_enter+8: brnz,pn %o1, unix:mutex_enter+0x18
global: %g1 0x122d1afc
%g2 0x61c286178cc9 %g3 0x6100850d71e6
%g4 0x8f0ac %g5 0x49d4
%g6 0x1c %g7 0x2a101c53b00
out: %o0 0x258 %o1 0x2a101c53b00
%o2 0x3180 %o3 0x63
%o4 1 %o5 0x702eb000
%sp 0x2a101c52c41 %o7 0x122d1b34
loc: %l0 4 %l1 0x70000
%l2 0xffffffffffffffff %l3 0x11e1a300
%l4 0x18d5 %l5 0x47868c
%l6 0x93a80 %l7 0x258
in: %i0 0x184028eba8480 %i1 0x184025681f7c0
%i2 0 %i3 0xb858
%i4 0x12c %i5 0x2e16
%fp 0x2a101c52d01 %i7 0x122d2ec8
unix:mutex_enter+4(0x258)
void vxdmp:dmp_handle_retry_error+0x13c((vxdmp_buf_t *)0x184028eba8480, (dmpnode_t *)0x184025681f7c0, (node_t *)0)
int vxdmp:dmp_call_strategy+0x24((vxdmp_buf_t *)0x184028eba8480)
int vxdmp:dmp_bypass_strategy+0x104((vxdmp_buf_t *)0x184028eba8480)
void vxdmp:dmp_path_okay+0xf0((vxdmp_buf_t *)0x184028eba8480, (dmpnode_t *)0x184025681f7c0, (node_t *)0x1840256488a80)
void vxdmp:dmp_error_action+0x68((vxdmp_buf_t *), (dmpnode_t *), (node_t *)0x1840256488a80, (uint_t)0)
vxdmp:dmp_process_scsireq((void *)0x1840293650540) - frame recycled
void vxdmp:dmp_daemons_loop+0x164()
unix:thread_start+4()
-- end of kernel thread's stack --
The panic is caused by a null pointer deference bug, related to Dynamic Multipathing (DMP) code.
Volume Manager 9.0.5 addresses the issue. The fix can be obtained here:
https://downloads.infoscale.com/infoscale/REL264791/9.0.5?q=9.0.5&fileNumber=FILE554527&updateNumber=UPD438768
Panic when zoning in new IBM storage on Infoscale 9.0 and Solaris 11.4
SW Download: UPD438768 JIRA: STESC-9882