arla problems under Solaris 2.6

[John Hawkinson]

(rb's announcement reminds me)

Having finally gotten an Ultra 30 wearing my work hat,
I'm back to fiddling with Arla.

Attached is the output from adb from a panic
that I got after mounting (modloading was fine)
xfs under Solaris 2.6, with all current patches.
This is under gcc 2.8.1, and as usual, I can't imagine
that matters.

I'm not sure what to conclude here. It looks like the pointers
in the struct mounta are not accessible in kernel space.
I don't understand why that might be.

{Writing Device Drivers} instructs one not to use
printf(), but instead to use cmn_err(). I didn't think
this was the problem, but I replaced all printf()s with
cmn_err()s, but that paniced in the same place.

Any thoughts? I suppose arla could treat the members
of the struct mounta as opaque and not try to dereference them,
and maybe everything would work.

I'm also a bit confused why this code is even being executed since
xfsdeb's value should still be zero, as far as I know, since I have
not changed it. But somehow it becomes 3f. Perhaps this is a hint
that something is stomping on it?

It seems to happen as part of the load:

# modload xfs
# adb -k /dev/ksyms /dev/mem
xphysmem        7b3f
fsdeb/X
xfsdeb:
xfsdeb:         3f
xfsdeb/W0

not in write mode
$W
xfsdeb/W0
xfsdeb:         0x3f            =       0x0

Interesting! Now I can mount the xfs module without a panic:
# ./mount_xfs /dev/xfs0 /afs

How bizarre.

Just for comparison's sake, adb thinks that xfsdeb is 0 in the module:
# adb xfs
xfsdeb/X
xfsdeb:
xfsdeb:         0
?X
xfsdeb:
xfsdeb:         3f

Oops, it actually does think that it is 3f, I guess I was using
/X when I should have been using ?X.

Anyhow, any comments? Does it make sense that the pointers in the
struct mounta should be opaque?

Thanks.

--jhawk


# adb -k unix.3 vmcore.3
physmem 7b3f
$c
complete_panic(?) + 24
do_panic(0x1,0x301df4ac,0x1040c3f8,0x0,0x20,0x0)
vcmn_err(0x3,0x1040d418,0x3,0x301df4ac,0x608d4040,0x4) + 190
cmn_err(0x3,0x1040d418,0xeffffc08,0xf5,0xf5,0x10406400) + 1c
die(0x31,0x301df690,0xeffffdd8,0x0,0x1040d418,0x0) + a0
trap(0x301df690,0x0,0xefffe000,0x1,0x0,0x5) + 830
0x301df690$<regs
0x301df690:     tstate                          pc              npc
                8               80001e06        1005f4bc        1005f4c0
0x301df718:     y                               g1
                0                               0               60561f80
0x301df6a0:     g1                              g2
                0               60561f80        0               78
0x301df6b0:     g3                              g4
                0               61              0               0
0x301df6c0:     g6                              g7
                0               0               0               608d4040
0x301df6d0:     o0                              o1
                0               effffdd8        0               73
0x301df6e0:     o2                              o3
                0               301df7d4        0               0
0x301df6f0:     o4                              o5
                0               3               0               301df7f7
0x301df700:     o6                              o7
                0               301df720        0               1005f028
301df720$c
?(?) + 0
prf_internal(0x60c8e366,0x25,0x10428258,0x3,0x20,0x0)
prf(0x60c8e348,0x301df960,0x0,0x3,0x301dfa14,0x601d9ec0) + 1c
printf(0x60c8e348,0x600be148,0xeffffdd8,0xeffffdce,0x0,0x0) + 24
xfs_mount(0x600be148,0x60c81b20,0x609cbcf8,0x600c3da0,0x60588008,0x60588000) + 48
mount(0x609cbcf8,0x60c8ea98,0x0,0x0,0x600be148,0x0) + 308
syscall_ap(0x609cbc90,0x301dfae0,0x1042639c,0x11cf0,0x0,0x0) + 68
0x60c8e348/s
rcsid+0xb90:    xfs_mount vfsp = 0x%x path = %s args = '%s'
0x600be148/X
config_ts_maxumdpri+0x1240:     0
0xeffffdd8/s

data address not found
0xeffffdd8/X
msgbuf$<msgbuf
msgbuf:
msgbuf:         magic           size            bufx            bufr
                8724786         1fe8            42c             0
msgbuf+0x10:    gAie = 0x31
                addr=0xeffffdd8
                pid=4257, pc=0x1005f4bc, sp=0x301df720, tstate=0x880001e06, cont
                ext=0x1d2f
                g1-g7: 60561f80, 60561f80, 78, 61, 0, 0, 608d4040
                Begin traceback... sp = 301df720
                Called from 1005f58c, fp=301df858, args=60c8e366 25 10428258 3 2
                0 0
                Called from 1005e938, fp=301df8b8, args=60c8e348 301df960 0 3 30
                1dfa14 601d9ec0
                Called from 60c89f20, fp=301df918, args=60c8e348 600be148 effffd
                d8 effffdce 0 0
                Called from 1007f75c, fp=301df9a0, args=600be148 60c81b20 609cbc
                f8 600c3da0 60588008 60588000
                Called from 100563f0, fp=301dfa18, args=609cbcf8 60c8ea98 0 0 60
                0be148 0
                Called from 1002f084, fp=301dfa80, args=609cbc90 301dfae0 104263
                9c 11cf0 0 0
                Called from 1109c, fp=effffc08, args=effffdce effffdd8 4 11cf0 0
                 0
                End traceback...
                panic[cpu0]/thread=0x608d4040: trap
                syncing file systems...xfs_sync
                 2 done
                 2839 static and sysmap kernel pages
                   29 dynamic kernel data pages
                  143 kernel-pageable pages
                    0 segkmap kernel pages
                    0 segvn kernel pages
                  183 current user process pages
                 3194 total pages (3194 chunks)

                dumping to vp 601d24cc, offset

xfsdeb/X
xfsdeb:
xfsdeb:         3f