Date: Mon, 12 Nov 2007 14:45:59 +0200 From: Kostik Belousov <kostikbel@gmail.com> To: Kris Kennaway <kris@freebsd.org> Cc: sparc64@freebsd.org Subject: Re: trap from DEBUG_LOCKS Message-ID: <20071112124559.GM37471@deviant.kiev.zoral.com.ua> In-Reply-To: <472FA18E.2020402@FreeBSD.org> References: <472DF090.8070904@FreeBSD.org> <20071105143603.GS37471@deviant.kiev.zoral.com.ua> <472FA18E.2020402@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--70vtA4ZRF8MmM5t7
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
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=
=20
> >>at the point when it mounts root I get the following panic when=20
> >>DEBUG_LOCKS is enabled:
> >>
> >>panic: trap: memory address not aligned
> >>cpuid =3D 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=3D0xe2f47c27 sfsr=3D0x40029 %o7=3D0x=
c03cd524=20
> >>--
> >>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).
>=20
> db> wh
> Tracing pid 1 tid 100006 td 0xfffff800020709c0
> panic() at panic+0x204
> trap() at trap+0x56c
> -- memory address not aligned sfar=3D0xe2f47c27 sfsr=3D0x40029 %o7=3D0xc0=
3cd584 --
> 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
>=20
> 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
>=20
> 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
>=20
> (It looks like it is not dumping all registers)
>=20
> 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;
=20
stack_zero(st);
addr =3D (db_expr_t)__builtin_frame_address(1);
fp =3D (struct frame *)(addr + SPOFF);
while (1) {
- callpc =3D fp->fr_pc;
+ callpc =3D (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) =3D=3D -1)
break;
- fp =3D (struct frame *)(fp->fr_fp + SPOFF);
+ fr_fp =3D (db_addr_t)db_get_value((db_addr_t)&fp->fr_fp,
+ sizeof(fp->fr_fp), FALSE);
+ fp =3D (struct frame *)(fr_fp + SPOFF);
}
}
--70vtA4ZRF8MmM5t7
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (FreeBSD)
iD8DBQFHOEsGC3+MBN1Mb4gRAh9gAJ4+ECdHxTTySDgvZ6rMC7et73Fm2gCgrG+O
lwAc82OG3+UHHK2vNfdY6ls=
=LBfD
-----END PGP SIGNATURE-----
--70vtA4ZRF8MmM5t7--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071112124559.GM37471>