trap from DEBUG_LOCKS

[Kris Kennaway]

Kostik Belousov wrote:
> On Sun, Nov 04, 2007 at 05:17:20PM +0100, Kris Kennaway wrote:
>> The insta-panic at boot on sparc64 with RELENG_7 seems to be fixed, but 
>> at the point when it mounts root I get the following panic when 
>> DEBUG_LOCKS is enabled:
>>
>> panic: trap: memory address not aligned
>> cpuid = 9
>> KDB: enter: panic
>> [thread pid 1 tid 100006 ]
>> Stopped at      kdb_enter+0x68: ta              %xcc, 1
>> db> wh
>> Tracing pid 1 tid 100006 td 0xfffff800020709c0
>> panic() at panic+0x204
>> trap() at trap+0x56c
>> -- memory address not aligned sfar=0xe2f47c27 sfsr=0x40029 %o7=0xc03cd524 --
>> stack_save() at stack_save+0x18
>> _lockmgr() at _lockmgr+0x4c
>> vfs_busy() at vfs_busy+0x1d4
>> vfs_mount_alloc() at vfs_mount_alloc+0x58
>> vfs_mountroot() at vfs_mountroot+0x2e4
>> start_init() at start_init+0x58
>> fork_exit() at fork_exit+0x9c
>> fork_trampoline() at fork_trampoline+0x8
> 
> Could you, please, show me the content of the registers and disassembly
> for the stack_save() ? (Last time I looked into sparc64 assembly, was 3
> years ago).

db> wh
Tracing pid 1 tid 100006 td 0xfffff800020709c0
panic() at panic+0x204
trap() at trap+0x56c
-- memory address not aligned sfar=0xe2f47c27 sfsr=0x40029 %o7=0xc03cd584 --
stack_save() at stack_save+0x18
_lockmgr() at _lockmgr+0x4c
vfs_busy() at vfs_busy+0x1d4
vfs_mount_alloc() at vfs_mount_alloc+0x58
vfs_mountroot() at vfs_mountroot+0x2e4
start_init() at start_init+0x58
fork_exit() at fork_exit+0x9c
fork_trampoline() at fork_trampoline+0x8

stack_save:     save            %sp, -0xc0, %sp
stack_save+0x4: call            stack_zero
stack_save+0x8: or              %g0, %i0, %o0
stack_save+0xc: flushw
stack_save+0x10:        ldx             [%fp + 0x86f], %g1
stack_save+0x14:        add             %g1, 0xffe, %l0
stack_save+0x18:        ldx             [%l0 + 0x78], %o1
stack_save+0x1c:        sethi           %hi(0xbffffc00), %g1
stack_save+0x20:        or              %g1, 0x3ff, %g1
stack_save+0x24:        subcc           %o1, %g1, %g0
stack_save+0x28:        bleu,pn         stack_save+0x50
stack_save+0x2c:        sethi           %hi(0x0), %g1
stack_save+0x30:        or              %g1, 0x0, %g1
stack_save+0x34:        sllx            %g1, 32, %g1
stack_save+0x38:        sethi           %hi(0xc0616c00), %g2
stack_save+0x3c:        add             %g1, %g2, %g1
stack_save+0x40:        ldx             [%g1 + 0x370], %g1
stack_save+0x44:        subcc           %o1, %g1, %g0
stack_save+0x48:        bleu,pt         stack_save+0x78
stack_save+0x4c:        sethi           %hi(0x0), %g1

db> show reg
g0                   0
g1                   0
g2          0xc0572c00  dumppcb+0x500
g3             0xca8ff
g4                 0xa  pcpup+0x3
g5          0xfffff8000140fff8
g6          0xe2f47980
g7          0xe22dfa90
i0                0x12  pcpup+0xb
i1          0xc04df530
i2          0xe2f46d78
i3                 0xa  pcpup+0x3
i4          0xe2f46e50
i5                   0
i6          0xe2f46501
i7          0xc0213a40  kdb_enter+0x60
tnpc        0xc0213a4c  kdb_enter+0x6c
tpc         0xc0213a48  kdb_enter+0x68
tstate      0x4415001601
kdb_enter+0x68: ta              %xcc, 1

(It looks like it is not dumping all registers)

Kris