Panic when zoning in new IBM storage on Infoscale 9.0 and Solaris 11.4

Problem

Panic when zoning in new IBM storage on Infoscale 9.0 and Solaris 11.4

Error Message

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
<leaf trap>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 --
 

Cause

The panic is caused by a null pointer deference bug, related to Dynamic Multipathing (DMP) code. 

Solution

Volume Manager 9.0.5 addresses the issue. The fix can be obtained here:
https://www.veritas.com/content/support/en_US/downloads/update.UPD438768