Re: Current method of dumping a processor?

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
> _at__at_ -60,6 +60,7 _at__at_
>  #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>
> _at__at_ -1742,6 +1743,8 _at__at_
>  {
>  	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
_at__at_ -37,6 +37,7 _at__at_
 #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>
_at__at_ -94,6 +95,8 _at__at_
 {
 	module_t mod;
 
+	if (arg2 & RB_NOSYNC)
+		return;
 	MOD_SLOCK;
 	TAILQ_FOREACH(mod, &modules, link)
 		MOD_EVENT(mod, MOD_SHUTDOWN);