My Oracle Support Banner

Some 3rd party drivers can panic after upgrading to Solaris 11.4 SRU30 or later (Doc ID 2756820.1)

Last updated on APRIL 29, 2021

Applies to:

Solaris Operating System - Version 11.4 to 11.4 [Release 11.0]
Information in this document applies to any platform.

Symptoms

Servers that have been recently upgraded to Solaris 11.4 SRU30 or Solaris 11.4 SRU31 can suffer a BAD TRAP panic occurring in 3rd party driver code.

Some examples of panic string and stack are shown below.

For MVFS:

-- trap data type: 0x31 (data access MMU miss) rp: 0x2a106a651a0 --
addr: 0xfffffe702ab82298
pc: 0x7bed3030 mvfs:mfs_getview+0xe0: ldx [%i5 + 0x18], %o0
npc: 0x7bed3034 mvfs:mfs_getview+0xe4: or %l6, 0x192, %l5 (0x70d92)
global: %g1 0x7be6d7d4
%g2 0 %g3 0x1abae
%g4 0x640059427040 %g5 3
%g6 0 %g7 0x64003a201900
out: %o0 0xfffffe702ab82280 %o1 0x64005a4ad988
%o2 0 %o3 0
%o4 0xffffffffffffffff %o5 0x640059267488
%sp 0x2a106a64a41 %o7 0x7bed301c
loc: %l0 0 %l1 0x3f
%l2 0 %l3 0x40
%l4 0x38 %l5 0x208920a8
%l6 0x70c00 %l7 0x30000064000
in: %i0 0x64005a4ab440 %i1 0
%i2 0 %i3 0x64005927c880
%i4 0x640059267488 %i5 0xfffffe702ab82280
%fp 0x2a106a64af1 %i7 0x7beba8b0
<trap>mvfs:mfs_getview+0xe0(, 0, 0)
mvfs:mfs_root+0x38()
mvfs:mvfs_sun5_root(0x640050574b70, 0x2a106a65500) - frame recycled
int genunix:fsop_root+0x10((vfs_t *)0x640050574b70, (vnode_t **)0x2a106a65500)
int genunix:traverse+0x6c((vnode_t **)0x2a106a655e0, , , , , 0x6400595ccc00)
int genunix:lookuppnvp+0x48c((struct pathname *)0x2a106a658d8, (struct pathname *)0, (int)0x21, (vnode_t **)0, (vnode_t **)0x2a106a65ab0, (vnode_t *)0x6400271c1a40, (vnode_t *)0x6400271c1a40, (cred_t *)0x64003a16e418)
int genunix:lookuppnatcred+0x110((struct pathname *)0x2a106a658d8, (struct pathname *)0, (int)0x21, (vnode_t **)0, (vnode_t **)0x2a106a65ab0, (vnode_t *)0, (cred_t *)0x64003a16e418)
int genunix:lookupnameatcred+0x44((char *)0x60038ba650, (enum uio_seg)0, (int)0x21, (vnode_t **)0, (vnode_t **)0x2a106a65ab0, (vnode_t *)0, (cred_t *)0x64003a16e418)
int genunix:lookupname+0x20((char *)0x60038ba650, (enum uio_seg)0, (int)0x21, (vnode_t **)0, (vnode_t **)0x64003a16e418)
int genunix:statvfs+0x1c((char *), (struct statvfs *)0x7fc6ffb9fbc60)
unix:_syscall_no_proc_exit+0x5c()

 

For VxFS:

-- trap data type: 0x34 (memory address not aligned) rp: 0x2a10334ae80 --
addr: 0xffbffafc
pc: 0x7af83f18 vxfs:vx_root+0x5c: ldx [%g1 + 0x18], %l4
npc: 0x7af83f1c vxfs:vx_root+0x60: ldx [%l4 + 0x18], %l5
global: %g1 0xffbffae4
%g2 0 %g3 0x249259
%g4 0x249258 %g5 0x3000264b7c0
%g6 0 %g7 0x184005103fac0
out: %o0 0x184005103fac0 %o1 0x184005103fac0
%o2 0 %o3 0
%o4 1 %o5 6
%sp 0x2a10334a721 %o7 0x7af83f00
loc: %l0 0x70c00 %l1 0
%l2 0xffbffae4 %l3 0x184002133a010
%l4 0x1840050003b0a %l5 0x40800000344
%l6 0x184005500be00 %l7 0x18400531827a8
in: %i0 0x184004a8038d8 %i1 0x2a10334b130
%i2 0x184002133a010 %i3 0x184005500be00
%i4 0x1840050003b10 %i5 1
%fp 0x2a10334a7d1 %i7 0x10a5a618
<trap>int vxfs:vx_root+0x5c((struct vfs *)0x184004a8038d8, (struct vnode **)0x2a10334b130)
int genunix:fsop_root+0x10((vfs_t *)0x184004a8038d8, (vnode_t **)0x2a10334b130)
int genunix:traverse+0x6c((vnode_t **)0x2a10334b210, , , , , 0x184005309f740)
int genunix:lookuppnvp+0x48c((struct pathname *)0x2a10334b508, (struct pathname *)0, (int)0x21, (vnode_t **)0, (vnode_t **)0x2a10334b708, (vnode_t *)0x18400152ffa40, (vnode_t *)0x18400152ffa40, (cred_t *)0x18400530432b8)
int genunix:lookuppnatcred+0x110((struct pathname *)0x2a10334b508, (struct pathname *)0, (int)0x21, (vnode_t **)0, (vnode_t **)0x2a10334b708, (vnode_t *)0, (cred_t *)0x18400530432b8)
int genunix:lookupnameatcred+0x44((char *)0x985f8, (enum uio_seg)0, (int)0x21, (vnode_t **)0, (vnode_t **)0x2a10334b708, (vnode_t *)0, (cred_t *)0x18400530432b8)
int genunix:lookupnameat+0x20((char *)0x985f8, (enum uio_seg)0, (int)0x21, (vnode_t **)0, (vnode_t **)0x2a10334b708, (vnode_t *)0)
int genunix:vn_openat+0x2fc((char *)0x985f8, (enum uio_seg)0, (int)0x2001, (int)0x104, (struct vnode **)0x2a10334b908, (enum create)0, (mode_t), (struct vnode *)0, (int), (int)4)
int genunix:copen+0x490((int)0xffffffffffd19553, (char *)0x985f8, (int)0x2001, (int)0x104, (uio_seg_t)0, (int)0)
int genunix:uopen+0x18((int)0xffffffffffd19553, (char *)0x985f8, (int)0x2001, (int)0x104)
unix:syscall_trap32+0x23c()

 

For SEOS_syscall:

-- trap data type: 0x34 (memory address not aligned) rp: 0x2a108a30fd0 LEAF --
addr: 0xffbffa4c
pc: 0x1002a924 unix:mutex_enter+4: casxa [%o0] ASI_P, %g0, %o1 ( casx [%o0] %g0, %o1 )
npc: 0x1002a928 unix:mutex_enter+8: brnz,pn %o1, unix:mutex_enter+0x18
global: %g1 0x1840080d07b80
%g2 0x200 %g3 0x1e230
%g4 0x1e22f %g5 0x30004691e40
%g6 0 %g7 0x184007f9e65c0
out: %o0 0xffbffa4c %o1 0x184007f9e65c0
%o2 1 %o3 0
%o4 0xca %o5 0
%sp 0x2a108a30871 %o7 0x7bece34c
loc: %l0 0xffbffa4c %l1 0xffffffffffd19553
%l2 0x300000862c0 %l3 0xffffffffffd19553
%l4 0 %l5 0
%l6 0x2806 %l7 0
in: %i0 0x2a108a31938 %i1 0x2a108a31260
%i2 0x2a108a31694 %i3 0xffffffffffd19553
%i4 0x2a108a31668 %i5 0xffbffa4c
%fp 0x2a108a30971 %i7 0x7bece808
<leaf trap>unix:mutex_enter+4(0xffbffa4c)
SEOS_syscall:set_path_and_startvp+0xc4(0x2a108a31938, 0x2a108a31260, 0x2a108a31694, 0xffffffffffd19553, 0x2a108a31668)
SEOS_syscall:get_realname+0x100(0x7a7, 0xffffffffffd19553, 0x2a108a31938, 0x2a108a31790, 1, 0x2a108a318a0)
SEOS_syscall:check_file_access+0x78(0xffffffffffd19553, 0x2a108a31938, 0x2a108a318a0, 1, 0)
SEOS_syscall:my_chdir+0x98(0xffbffb64, 0x2a108a31a30, 0x18400809d2780, 0x70db3588)
SEOS_syscall:my_cs_chdir+0x80()
unix:_syscall_no_proc_exit32+0x7c()
-- switch to user thread's user stack --

Changes

Solaris engineering has made changes to a kernel interface that is not documented as part of the DDI/DKI.

Those changes do not need to be made public, because 3rd party drivers shouldn't be using the interface.

3rd party drivers using such interfaces are at risk of suffering panics if Solaris engineering decides to change the interface.

Cause

To view full details, sign in with your My Oracle Support account.

Don't have a My Oracle Support account? Click to get started!


In this Document
Symptoms
Changes
Cause
Solution

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.