Date: Tue, 17 Aug 2004 19:48:44 -0700 (PDT) From: Don Lewis <truckman@FreeBSD.org> To: grog@FreeBSD.org Cc: radek@raadradd.com Subject: Re: Current method of dumping a processor? Message-ID: <200408180248.i7I2minn007733@gw.catspoiler.org> In-Reply-To: <200408180210.i7I2AFbg007683@gw.catspoiler.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 17 Aug, Don Lewis wrote: > On 17 Aug, Greg 'groggy' Lehey wrote: >> On Friday, 13 August 2004 at 1:07:41 +0200, Radek Kozlowski wrote: >>> On Fri, Aug 13, 2004 at 07:28:59AM +0930, Greg 'groggy' Lehey wrote: >>>> I've tried it on kernels built in January, May and yesterday. In each >>>> case, I did: >>>> >>>> dumpon /dev/ad0s2b >>>> >>>> (for appropriate values of ad0s2b). All kernels include ddb. I >>>> entered the debugger with ctrl-alt-esc and entered "panic". The >>>> kernel from January dumps just fine. The kernels from May and August >>>> hang. >>>> >>>> Am I doing something wrong? Has something else changed? Does anybody >>>> else have this problem? >>> >>> I also had this problem back in June when I was trying to get a crash >>> dump, but nobody replied (see >>> http://lists.freebsd.org/pipermail/freebsd-current/2004-June/029434.html). >>> I then learnt that I can use call doadump in ddb and have been using >>> that since then. >> >> Thanks. Yes, this seems to work. Are we agreed that it's a bug that >> the 'panic' command just hangs? > > Try the patch below. I suspect that syncer_shutdown() is the most > likely culprit, but a number of the other shutdown_pre_sync handlers > could potentially hang. They should probably be tweaked to only execute > if they can run without blocking. > > > Index: sys/kern/vfs_subr.c > =================================================================== > RCS file: /home/ncvs/src/sys/kern/vfs_subr.c,v > retrieving revision 1.522 > diff -u -r1.522 vfs_subr.c > --- sys/kern/vfs_subr.c 16 Aug 2004 08:33:37 -0000 1.522 > +++ sys/kern/vfs_subr.c 18 Aug 2004 01:54:56 -0000 > @@ -60,6 +60,7 @@ > #include <sys/malloc.h> > #include <sys/mount.h> > #include <sys/namei.h> > +#include <sys/reboot.h> > #include <sys/sleepqueue.h> > #include <sys/stat.h> > #include <sys/sysctl.h> > @@ -1742,6 +1743,8 @@ > { > struct thread *td; > > + if (howto & RB_NOSYNC) > + return; > td = FIRST_THREAD_IN_PROC(updateproc); > sleepq_remove(td, &lbolt); > mtx_lock(&sync_mtx); > There is a patch below for another problem I found when I broke into DDB and executed panic(). The system paniced a second time after the crash dump succeeded. Geom could be fixed to not call malloc() in the MOD_SHUTDOWN case, but it is probably better not to invoke the module shutdown handlers if the system panics. Dump complete panic: malloc(M_WAITOK) in interrupt context cpuid = 0; KDB: enter: panic [thread 100075] Stopped at kdb_enter+0x2b: nop db> tr kdb_enter(c0811deb) at kdb_enter+0x2b panic(c0810484,c07e67b9,c22520c0,c0847360,2) at panic+0x131 malloc(8,c086a260,102) at malloc+0x74 g_modevent(c22520c0,2,c0847360) at g_modevent+0x59 module_shutdown(0,104,c224d00c,0,c0811e0f) at module_shutdown+0x2d boot(104,104,c23d2c60,0,c0837748) at boot+0x61f panic(c07dcc32,e8eb8bdc,c0461620,c062804b,0) at panic+0x17f db_panic(c062804b,0,ffffffff,e8eb8b50,0) at db_panic+0xd db_command(c08b8404,c08406c0,c0837748,c0837764,c07dcc40) at db_command+0x264 db_command_loop(0,0,e8eb8c08,e8eb8bf4,e8eb8c3c) at db_command_loop+0x5c db_trap(3,0,3,c23d2c60,e8eb8c88) at db_trap+0xdd kdb_trap(3,0,e8eb8c90) at kdb_trap+0x8b trap(18,10,10,f9,c23bd000) at trap+0x4ac calltrap() at calltrap+0x5 --- trap 0x3, eip = 0xc062804b, esp = 0xe8eb8cd0, ebp = 0xe8eb8cd0 --- kdb_enter(c082df9e) at kdb_enter+0x2b siointr1(c23bd000,c0916000,0,c082dd62,6ad) at siointr1+0xce siointr(c23bd000) at siointr+0x21 intr_execute_handlers(c225d490,e8eb8d44,4,bfbfe090,c0796543) at intr_execute_han dlers+0xa9 lapic_handle_intr(34) at lapic_handle_intr+0x2e Xapic_isr1() at Xapic_isr1+0x33 --- interrupt, eip = 0x8059717, esp = 0xbfbfe058, ebp = 0xbfbfe090 --- Index: sys/kern/kern_module.c =================================================================== RCS file: /home/ncvs/src/sys/kern/kern_module.c,v retrieving revision 1.45 diff -u -r1.45 kern_module.c --- sys/kern/kern_module.c 15 Jul 2004 08:26:05 -0000 1.45 +++ sys/kern/kern_module.c 18 Aug 2004 02:27:17 -0000 @@ -37,6 +37,7 @@ #include <sys/proc.h> #include <sys/lock.h> #include <sys/mutex.h> +#include <sys/reboot.h> #include <sys/sx.h> #include <sys/module.h> #include <sys/linker.h> @@ -94,6 +95,8 @@ { module_t mod; + if (arg2 & RB_NOSYNC) + return; MOD_SLOCK; TAILQ_FOREACH(mod, &modules, link) MOD_EVENT(mod, MOD_SHUTDOWN);
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200408180248.i7I2minn007733>