panic upon deleting DDB breakpoint

[Andrew Belashov]

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.