trap from DEBUG_LOCKS

[Kostik Belousov]

On Tue, Nov 06, 2007 at 12:04:46AM +0100, Kris Kennaway wrote:
> 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

Sorry for the delay in answer.

Yes, unfortunately, ddb does not provide the %loX registers values,
and %lo0 is the most interesting there. I don't understand where the
unaligned stack frame comes from. Patch below might help (it was not
even compile-tested), but it should be a performance hog.

diff --git a/sys/sparc64/sparc64/db_trace.c b/sys/sparc64/sparc64/db_trace.c
index 49ea4e6..b081d5d 100644
--- a/sys/sparc64/sparc64/db_trace.c
+++ b/sys/sparc64/sparc64/db_trace.c
@@ -302,14 +302,15 @@ void
 stack_save(struct stack *st)
 {
 	struct frame *fp;
-	db_expr_t addr;
+	db_expr_t addr, fr_fp;
 	vm_offset_t callpc;
 
 	stack_zero(st);
 	addr = (db_expr_t)__builtin_frame_address(1);
 	fp = (struct frame *)(addr + SPOFF);
 	while (1) {
-		callpc = fp->fr_pc;
+		callpc = (db_addr_t)db_get_value((db_addr_t)&fp->fr_pc,
+		    sizeof(fp->fr_pc), FALSE);
 		if (!INKERNEL(callpc))
 			break;
 		/* Don't bother traversing trap frames. */
@@ -320,6 +321,8 @@ stack_save(struct stack *st)
 			break;
 		if (stack_put(st, callpc) == -1)
 			break;
-		fp = (struct frame *)(fp->fr_fp + SPOFF);
+		fr_fp = (db_addr_t)db_get_value((db_addr_t)&fp->fr_fp,
+		    sizeof(fp->fr_fp), FALSE);
+		fp = (struct frame *)(fr_fp + SPOFF);
 	}
 }
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-sparc64/attachments/20071112/53a7110a/attachment.pgp