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

book

Article ID: 100076687

calendar_today

Updated On:

Description

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
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. 

 

Resolution

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

 

 

Issue/Introduction

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

Additional Information

SW Download: UPD438768 JIRA: STESC-9882