Date: Mon, 25 Apr 2005 12:46:26 +0400 From: Andrew Belashov <bel@orel.ru> To: Kris Kennaway <kris@obsecurity.org> Cc: freebsd-sparc64@freebsd.org Subject: Re: panic upon deleting DDB breakpoint Message-ID: <426CAE62.1090606@orel.ru> In-Reply-To: <20050423080502.GA97360@xor.obsecurity.org> References: <20050423080502.GA97360@xor.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello, Kris! Kris Kennaway wrote: > I did the following on a RELENG_5 machine (in the course of trying to > track down my errno problem previously reported): > > db> break unlink > db> cont > [thread pid 57866 tid 100044 ] > Breakpoint at unlink: save %sp, -0xc0, %sp > db> delete unlink > db> cont > panic: trap: fast data access mmu miss > cpuid = 0 > KDB: enter: panic > [thread pid 57866 tid 100044 ] > Stopped at kdb_enter+0x38: ta %xcc, 1 > db> wh > Tracing pid 57866 tid 100044 td 0xfffff8003f817400 > panic() at panic+0x19c > trap() at trap+0x16c > -- fast data access mmu miss tar=0 %o7=0xc01ab278 -- > unlink() at unlink+0x20 > -- syscall (10, FreeBSD ELF64, unlink) %o7=0x10352c -- > userland() at 0x403a4e68 > user trace: trap %o7=0x10352c > pc 0x403a4e68, sp 0x7fdffffd5e1 > pc 0x1040d8, sp 0x7fdffffdb21 > pc 0x1013b4, sp 0x7fdffffdbe1 > pc 0x40217414, sp 0x7fdffffdca1 > done > > This is repeatable on two machines; I have a coredump. > > (kgdb) bt > #0 doadump () at ../../../kern/kern_shutdown.c:246 > #1 0x00000000c01698b4 in boot (howto=260) at ../../../kern/kern_shutdown.c:409 > #2 0x00000000c0169cc4 in panic (fmt=0xc03ae988 "trap: %s") at ../../../kern/kern_shutdown.c:565 > #3 0x00000000c02e978c in trap (tf=0xee9175c0) at ../../../sparc64/sparc64/trap.c:369 > #4 0x00000000c01d30c4 in unlink (td=0xee917880, uap=0x0) at ../../../kern/vfs_syscalls.c:1585 > #5 0x00000000c01d30b8 in unlink (td=0xee917880, uap=0x0) at ../../../kern/vfs_syscalls.c:1584 > (kgdb) frame 3 > #3 0x00000000c02e978c in trap (tf=0xee9175c0) at ../../../sparc64/sparc64/trap.c:369 > 369 panic("trap: %s", trap_msg[tf->tf_type & ~T_KERNEL]); > (kgdb) frame 4 > #4 0x00000000c01d30c4 in unlink (td=0xee917880, uap=0x0) at ../../../kern/vfs_syscalls.c:1585 > 1585 error = kern_unlink(td, uap->path, UIO_USERSPACE); > (kgdb) frame 5 > #5 0x00000000c01d30b8 in unlink (td=0xee917880, uap=0x0) at ../../../kern/vfs_syscalls.c:1584 > 1584 mtx_lock(&Giant); > (kgdb) > > (Take the above with a grain of salt since gdb53 got the stack trace > wrong). > > I didn't yet try other breakpoints. Doing the same thing on i386 > doesn't cause a panic. Try patch (sparc64_trap.patch) from PR/72998 <http://www.freebsd.org/cgi/query-pr.cgi?pr=sparc64/72998> Or, probably, somewhere (in KDB code?) it is necessary to insert the FLUSHW instruction. -- With Best Regards, Andrew Belashov.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?426CAE62.1090606>