[OpenAFS-devel] Solaris 10 6/06 (update 2) crash (not the gafs_rename() one)

William Setzer William_Setzer@ncsu.edu
Thu, 20 Jul 2006 16:40:13 -0400


I'm using the OpenAFS 1.4.1 distribution pre-compiled for Solaris 10
sparc.  Under Solaris 10 update 2, I get the following panic if the
machine is running as an NFS server and some (unknown) NFS request
comes in:

   panic[cpu0]/thread=30001bee9c0: 
   BAD TRAP: type=31 rp=2a100866e40 addr=4 mmu_fsr=0 occurred in module "afs" due to a NULL pointer dereference

   nfsd: 
   trap type = 0x31
   addr=0x4
   pid=474, pc=0x7b745200, sp=0x2a1008666e1, tstate=0x9980001603, context=0x3c7
   g1-g7: 0, 1a75f00, 0, 1080, 7ffffc00, 0, 30001bee9c0

   000002a100866b60 unix:die+78 (31, 2a100866e40, 4, 0, 2a100866c20, 1075000)
    %l0-3: 0000000000001fff 0000000000000031 0000000001000000 0000000000002000
    %l4-7: 000000000181a010 000000000181a000 0000000000000000 0000009980001603
   000002a100866c40 unix:trap+8fc (2a100866e40, 5, 1fff, 1c00, 0, 1)
    %l0-3: 0000000000000000 000003000032ebe8 0000000000000031 0000000000000000
    %l4-7: ffffffffffffe000 0000030004bd5fb8 0000000000000001 0000000000000005
   000002a100866d90 unix:ktl0+48 (30004bd5f98, 30004bd5f98, 4, 1, 300022867a0, 30004bd5fb8)
    %l0-3: 0000000000000004 0000000000001400 0000009980001603 0000000001019840
    %l4-7: 000003000227c200 00000000000000cb 0000000000000000 000002a100866e40
   000002a100866ee0 genunix:kmem_cache_alloc+154 (0, 30001bee9c4, 129eb8be, 0, 30001bee9c4, 30001bee9bc)
    %l0-3: 0000000000000001 0000030002286898 0000000000000001 0000030002286870
    %l4-7: 00000300022868c0 000000000000000f 0000000000000001 0000000000000000
   000002a100866fa0 afs:nfs3_to_afs_call+1b4 (3, 2a100867510, 2a100867178, 2a100867170, 2a100867510, 0)
    %l0-3: 000000007b745354 000000007b745550 0000000000000008 000000007bb9e000
    %l4-7: 00000000703ca3e8 0000000000000000 00000000703e1468 0000000000000000
   000002a1008670a0 afs:afs_nfs3_dispatcher+a8 (0, 3, 2a100867510, 2a1008672a8, 2a1008676a0, 980104a5)
    %l0-3: 0000000000000000 0000030002696598 0000000000000022 0000030004180580
    %l4-7: 0000000000000000 0000030002696598 0000000000000000 0000000000000000
   000002a1008671c0 afs:afs_xserver+b3434dc (2a100867510, 2a1008673a8, 30000376988, 2a1008676a0, 30000376728, 1)
    %l0-3: 000002a100867542 0000000000000002 00000000703cd000 00000000703cd000
    %l4-7: 0000030001514218 0000000000000002 0000000000000010 0000000000000001
   000002a1008672c0 nfssrv:common_dispatch+564 (2a1008676a0, 30001502700, 0, 30001514140, 703e21c0, 0)
    %l0-3: 000002a100867540 00000000703e0910 00000300027a0600 000002a1008673a8
    %l4-7: 0000030000376728 0000000000000011 000000007b745c28 000002a1008673a8
   000002a1008675e0 rpcmod:svc_getreq+154 (30001502700, 30002225a40, 30004172db0, 703cae60, 30002cd9500, 0)
    %l0-3: 0000000000000002 0000000000000001 0000000000000000 0000030001502754
    %l4-7: 0000030004172dc8 000000007bb9318c 000003000415d190 0000030001502708
   000002a100867720 rpcmod:svc_run+198 (30004172d48, 0, 1, 0, 30004172d80, 1)
    %l0-3: 000003000032ebe8 0000030004172d90 0000030001502700 00000300027b8180
    %l4-7: 00000300014a3480 0000000000000000 0000000000000000 0000030002225a40
   000002a1008677d0 nfs:nfssys+1c4 (e, ff101f9c, 7b667000, c, c, 1f0)
    %l0-3: 0000000000000000 0000000000000000 00000000b6490000 000000000000b649
    %l4-7: 0000000000000001 0000000000000000 0000000000000000 000000007b6673d0


Due to me not checking up on it, the machine actually panic'ed over a
dozen times.  All gave essentially the same backtrace as above, except
that in two cases it was "genunix:kmem_cache_free" instead of "alloc"
after the "nfs3_to_afs_call".


William