My Oracle Support Banner

Currently SAMFS and HSM ( Hierarchical Storage Manager ) is not supported on Solaris 11.4 and will cause system panics (Doc ID 2468614.1)

Last updated on FEBRUARY 04, 2019

Applies to:

Solaris Operating System - Version 11.4 and later
Information in this document applies to any platform.

Symptoms

The system panics in a loop on boot up with a stack similar to:

...

panic[cpu165]/thread=6400bc30ee00: BAD TRAP: type=31 rp=2a11514ef30 addr=18 mmu_fsr=0 occurred in module "unix" due to a NULL pointer dereference

mount: trap type = 0x31
addr=0x18
pid=1642, pc=0x1002a9d4, sp=0x2a11514e7d1, tstate=0x4480001604, context=0xe51
g1-g7: 1, 64006f2ebe40, 2012d0ec, 70c00, fc00, e51, 6400bc30ee00

000002a11514ec60 unix:die+8c (31, 2a11514ef30, 18, 0, 20056400, 1)
%l0-3: 000000001012c710 000000001012c400 0000000000000000 000000001012c400
%l4-7: 000000000000000a 0000000000c00000 000002a11514ed20 0000000000001fff
000002a11514ed40 unix:trap+b54 (2a11514ef30, 1, 31, 18, c1680000, 0)
%l0-3: 0000000000000005 0000000000000001 0000000000000000 00000000c1780000
%l4-7: 00000000d65aa018 0000000000001c00 0000000000000000 0000000000000000
000002a11514ee80 unix:ktl0+7c (20915e30, 64006f2ebe40, 0, bfffffff, 2012d000, 2)
%l0-3: 0000030000148000 0000000020337110 0000004480001604 0000000010040120
%l4-7: 0000000000000000 0000000000000000 0000000000000000 000002a11514ef31
000002a11514efd0 unix:mutex_vector_enter+104 (2, 64006f2ebe40, 2012d100, 2012d000, 20915e30, 20908f68)
%l0-3: 000000002012d000 0000000000000000 0000000000000000 000000002012d0f8
%l4-7: 0000000000000000 0000000000000000 0000000000000000 0000000000040000
000002a11514f080 genunix:dnlc_csupdate+58 (6400c43f5300, 7bf04c60, 20915e30, 2, 0, 0)
%l0-3: 0000000000002000 0000000000000000 000000002087de48 0000640059924050
%l4-7: 0000000000000002 0000000000002940 0000000000000002 000000002087e000
000002a11514f130 samfs:sam_find_component+14a0 (2000, 1000, 2, 70f52000, 70f4fa48, 70c00)
%l0-3: 0000000000000001 0000000000000001 0000000000000000 fff8090086c668bc
%l4-7: 0000000000000000 0000000000000000 0000000000000000 0000000000020800
000002a11514f3a0 samfs:sam_lookup_name+4e8 (6400c54bb0b0, 7bf04c60, 2a11514f548, 0, 6400b85d5c78, 0)
%l0-3: 0000000070f4f000 0000000000000000 0000000000000000 0000000000000001
%l4-7: 00006400c54bb428 0000000000008000 00006400c54bb508 0000000000000000
000002a11514f480 samfs:sam_quota_init+e4 (70f4f9f8, 6400bcdf6000, 70c00, 20000, f000, 0)
%l0-3: 0000000000000008 0000000000000010 0000000000000000 0000000070f4fa48
%l4-7: 00006400bcdf6998 0000000000000000 0000000000008000 00006400bcdf6248
000002a11514f550 samfs:samfs_mount+111c (6400b8544118, 2a11514f628, 2a11514f9b8, 92, 6400bcdf61d0, 91)
%l0-3: 00006400bcdf6248 0000000070f54114 00006400c54a2000 00006400bcdf6000
%l4-7: 000000000007bf0f 000000000007bc00 0000000000000000 0000000000000093
000002a11514f720 genunix:domount+ea8 (6400b8544118, 2a11514f9b8, 6400bc5b9740, 0, 0, 209079c0)
%l0-3: 000002a11514f8e8 0000000000000000 00006400c35222d0 00006400bdc45c30
%l4-7: 0000000000000072 00000000ffbff9fc 0000000000000072 000000002088c6b0
000002a11514f900 genunix:mount+10c (6400bd89cdb8, 2a11514fab8, 2ab4c, 44, ffbffc17, 0)
%l0-3: 00006400bd89cd00 0000000000000008 0000000000000000 0000000000000044
%l4-7: 00000000ffbff9fc 0000000000000072 000000000000af50 00000000ffbf4aa8
000002a11514fa00 genunix:syscall_ap+58 (2a0, ffbffc1c, 15, 6400bd89cd00, ffbf4aa8, af50)
%l0-3: 00006400bd89cf10 0000640059c98500 000000000000ecba 000000000000ecb9
%l4-7: 0000000020889840 000002a11514fb70 000000001096b440 0000000000000008

syncing file systems... [2] [2] [2] [2] [2] [2] [2] [2] [2] [2] [2] [2] [2] [2] [2] [2] [2] [2] [2] [2] [2] done (not all i/o completed)
Deferred dump not available because:
deferred dump not online (state 4)
retained memory capability not present
Skipping dump - existing dump still on dump device.
rebooting...
Resetting...

...

Note because the panic happens so early in the boot process it is unlikely there will be a crash dump.   The stack trace will need to be collected from the console.   Booting in single user mode and disabling the samfs file system should allow the system to boot.  The system will panic again as soon as any samfs file system is mounted.  In the event that a crash dump is generated the stack may further show:

...

void unix:panicsys+0x40((const char *)0x1012c6c0, (va_list)0x2a10b834ce8, (struct regs *)0x205510a0, (int)1, 0x9900001602, , , , , , , , 0x1012c6c0, 0x2a10b834ce8)
unix:vpanic_common+0x78(0x1012c6c0, 0x2a10b834ce8, 0xa, 0xee6c57bfa53a, 0xee6c57bf9eb2, 0)
void unix:panic+0x1c((const char *)0x1012c6c0, 0x31, 0x2a10b834f30, 0x18, 0, 0x2087364f, 0x1012c710, ...)
int unix:die+0x8c((unsigned int)0x31, (struct regs *)0x2a10b834f30, (caddr_t)0x18, (uint_t)0)
void unix:trap+0xb54((struct regs *), (caddr_t)0x18, (uint32_t), (uint32_t))
unix:ktl0+0x7c()
-- trap data  type: 0x31 (data access MMU miss)  rp: 0x2a10b834f30  LEAF --
 addr: 0x18
pc:  0x1002a9d4 unix:default_mutex_owner_running+0x14:   ldx    [%o2 + 0x18], %o3
npc: 0x1002a9d8 unix:default_mutex_owner_running+0x18:   subcc    %o1, %o3, %g0   ( cmp   %o1, %o3 )
 global:                       %g1                  1
       %g2     0x64006f2c9e40  %g3         0x2012d0ec
       %g4            0x70800  %g5             0xfc00
       %g6             0x10b0  %g7     0x6400abbde500
 out:  %o0         0x20915e30  %o1     0x64006f2c9e40
       %o2                  0  %o3         0xbfffffff
       %o4         0x2012d000  %o5                  2
       %sp      0x2a10b8347d1  %o7         0x100c548c
 loc:  %l0         0x2012d000  %l1                  0
       %l2                  0  %l3         0x2012d0f8
       %l4                  0  %l5                  0
       %l6                  0  %l7            0x40000
 in:   %i0                  2  %i1     0x64006f2c9e40
       %i2         0x2012d100  %i3         0x2012d000
       %i4         0x20915e30  %i5         0x20908f68
       %fp      0x2a10b834881  %i7         0x108f0cd8
<leaf trap>unix:default_mutex_owner_running+0x14(0x20915e30, 0x1002a9c0)
void unix:mutex_vector_enter+0x104((mutex_impl_t *))
...

 

This appears to be due to samfs improperly passing the negative_cache_vnode to dnlc_csupdate instead of dereferencing it first, and dnlc_csupdate then treats it as a mutex.

 

Changes

 Upgrading to Solaris 11.4 from an earlier Solaris version

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
References


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