About 1/2 year ago there was a thread about the debug.debugger_on_panic sysctl. The report was that it no longer functioned the same way (i.e. dropped into the debugger instead of panic, when set to zero), and the replies suggested it still worked as designed. We see the same behaviour of entering the debugger. The original thread was at http://lists.freebsd.org/pipermail/freebsd-current/2004-July/031446.html It appears that on RELENG_4 with DDB, the sysctl's behaviour was more like debugger_on_panic_or_trap. i386/i386/trap.c used to check debugger_on_panic before calling kdb_trap (for DDB). In RELENG_4, i386/i386/trap.c had, in trap_fatal(): http://fxr.watson.org/fxr/source/i386/i386/trap.c?v=RELENG4#L964 964 #ifdef KDB 965 if (kdb_trap(&psl)) 966 return; 967 #endif 968 #ifdef DDB 969 if ((debugger_on_panic || db_active) && kdb_trap(type, 0, frame)) 970 return; 971 #endif 972 printf("trap number = %d\n", type); 973 if (type <= MAX_TRAP_MSG) 974 panic("%s", trap_msg[type]); 975 else 976 panic("unknown/reserved trap"); The following patch somewhat restores the previous functionality $ diff -u3 trap.c.orig trap.c --- trap.c.orig Tue Feb 1 10:21:50 2005 +++ trap.c Tue Feb 1 10:26:01 2005 _at__at_ -753,6 +753,7 _at__at_ return((rv == KERN_PROTECTION_FAILURE) ? SIGBUS : SIGSEGV); } +extern int debugger_on_panic; static void trap_fatal(frame, eva) struct trapframe *frame; _at__at_ -820,7 +821,7 _at__at_ } #ifdef KDB - if (kdb_trap(type, 0, frame)) + if (debugger_on_panic && kdb_trap(type, 0, frame)) return; #endif printf("trap number = %d\n", type); If debugger_on_panic=0 and the debugger is entered for other reasons (e.g. key sequence), I suppose there's an issue with something in the debugger causing a trap and then leading to a panic. In RELENG_4 there was a db_active global for this case, but it seems to be gone. I'm not sure of the proper way to fix that, but my concern is mainly that remote units don't sit at a debugger prompt. Ed Maste Sandvine Inc.Received on Tue Feb 01 2005 - 14:56:01 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:27 UTC