Date: Fri, 19 Aug 2005 22:53:36 -0400 From: Kris Kennaway <kris@obsecurity.org> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: marcel@FreeBSD.org, sparc64@FreeBSD.org, Kris Kennaway <kris@obsecurity.org> Subject: Re: kgdb still broken? Message-ID: <20050820025336.GA94049@xor.obsecurity.org> In-Reply-To: <A4D2B753-A1C2-4686-A656-4DF061AB72A8@xcllnt.net> References: <20050819171555.GA45748@xor.obsecurity.org> <A4D2B753-A1C2-4686-A656-4DF061AB72A8@xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--+HP7ph2BbKc20aGI
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Fri, Aug 19, 2005 at 05:42:33PM -0700, Marcel Moolenaar wrote:
>=20
> On Aug 19, 2005, at 10:15 AM, Kris Kennaway wrote:
>=20
> >When I attempt to run kgdb on a core on sparc64 I get this:
> >
> >kgdb: kvm_read: invalid address (7070707)
> >kgdb: kvm_read: invalid address (ffffd9c1)
> >kgdb: kvm_read: invalid address (4044ac00)
> *snip*
>=20
> >Is it working for you on sparc since your recent fix?
>=20
> Yes. I typically get the above (on any architecture) when the kernel
> is out-of-sync with the core file. Are the core file and kernel in
> sync?
OK, that was it..
It's not making much sense of the backtrace though:
(kgdb) bt
#0 doadump () at /usr/src.6/sys/kern/kern_shutdown.c:233
#1 0x00000000c006a728 in db_fncall (dummy1=3D0, dummy2=3D0, dummy3=3D11, d=
ummy4=3D0x16e9a41a0 "")
at /usr/src.6/sys/ddb/db_command.c:486
#2 0x00000000c006a434 in db_command (last_cmdp=3D0xc040f940, cmd_table=3D0=
x0, aux_cmd_tablep=3D0xc03c8dc8,
aux_cmd_tablep_end=3D0xc03c8de0) at /usr/src.6/sys/ddb/db_command.c:401
#3 0x00000000c006a558 in db_command_loop () at /usr/src.6/sys/ddb/db_comma=
nd.c:452
#4 0x00000000c006d0b8 in db_trap (type=3D1855603632, code=3D0) at /usr/src=
.6/sys/ddb/db_main.c:221
#5 0x00000000c018d208 in kdb_trap (type=3D107, code=3D0, tf=3D0x16e9a4630)=
at /usr/src.6/sys/kern/subr_kdb.c:473
#6 0x00000000c02f6b4c in trap (tf=3D0x16e9a4630) at /usr/src.6/sys/sparc64=
/sparc64/trap.c:307
#7 0x00000000c0048fe0 in tl1_trap ()
#8 0x00000000c0048fe0 in tl1_trap ()
Previous frame identical to this frame (corrupt stack?)
Where ddb showed that the panic correctly (see my mail to -current
entitled 'panic: uma_small_alloc: free page still has mappings!'). =20
gdb53 also gets it right, but I can't examine other threads to see if
they had also panicked.
Kris
--+HP7ph2BbKc20aGI
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (FreeBSD)
iD8DBQFDBpsvWry0BWjoQKURAo/SAJsEQM4GrT6lEfUPLu+S/ojM2AhluACcC5v1
bnsnfYcSrqxnOma8daV4+6s=
=ahPC
-----END PGP SIGNATURE-----
--+HP7ph2BbKc20aGI--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050820025336.GA94049>