Date: Wed, 8 Dec 2004 11:28:24 +0000 (GMT) From: Robert Watson <rwatson@freebsd.org> To: Michael Nottebrock <michaelnottebrock@gmx.net> Cc: freebsd-stable@freebsd.org Subject: Re: crashdumps not working Message-ID: <Pine.NEB.3.96L.1041208112557.98791D-100000@fledge.watson.org> In-Reply-To: <Pine.NEB.3.96L.1041208111915.98791C-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 8 Dec 2004, Robert Watson wrote: > On Tue, 7 Dec 2004, Michael Nottebrock wrote: > > > I recently enabled SW_WATCHDOG in my kernel, but when watchdog triggers > > a panic, no crashdump is taken although dumps are enabled. What could be > > causing this? > > If you drop to the debugger by using the debug.kdb.enter sysctl, and do > "call doadump", followed by a reset, does a dump get generated > successfully? I.e., are they completely broken on your system, or is > this somehow a property of the particular hang you're seeing. (Do the > above with caution and in a situation where you don't mind fscking, > needless to say). It this is an SMP box, you might also try setting debug.kdb.stop_cpus to 0. Normally when entering the debugger, the processor entering the debugger will send an IPI to the other CPUs to stop them in order to quiesce the system state a bit. If one or more processors are in a state where processing the top IPI isn't possible, the procesor entering the debugger will wait for them to stop ... potentially for a very long time, and in a tight loop. Changing the setting to 0 might improve the chances of getting into the debugger (etc). Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1041208112557.98791D-100000>