On Fri, Jul 16, 2004 at 09:39:16PM +0200, Willem Jan Withagen wrote: > From: "Marcel Moolenaar" <marcel_at_xcllnt.net> > > On Fri, Jul 16, 2004 at 07:30:31PM +0200, Willem Jan Withagen wrote: > > > > > > panic: process 82471(sh):2 holds Giant but isn't blocked on a lock > > > > > > cpuid = 1; > > > KDB: enter: panic > > > > > > Is there any purpose in reporting these crashes this way??? > > > > You might want to make sure your debugger backend is DDB and not > > GDB. > > This is what I have: > # Debugging for use in -current > options KDB # Enable kernel debugger support. > options KDB_TRACE > options DDB # Support DDB. > options GDB # Support remote GDB. > options INVARIANTS # Enable calls of extra sanity checking > options INVARIANT_SUPPORT # Extra sanity checks of internal struct > ures, required by INVARIANTS > options WITNESS # Enable checks to detect deadlocks and > cycles > options WITNESS_SKIPSPIN # Don't run witness on spinlocks for spe > ed > > Next to having an SMP/Opteron system. That's all good, and normally this gives you DDB as the default debugger backend. Typically if you only see "KDB: enter: panic", then KDB is using the GDB backend. Hmmm... It may be a good idea to tell people that. Somthing like: KDB: entering ddb: panic or KDB: entering gdb: bootflags requested debugger -- Marcel Moolenaar USPA: A-39004 marcel_at_xcllnt.netReceived on Fri Jul 16 2004 - 18:10:59 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:02 UTC