The following reply was made to PR kern/29291; it has been noted by GNATS.

From: fredb@immanent.net (Frederick Bruckman)
To: kessi@teles.de, gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/29291: No kernel crash dump on panic
Date: Fri, 11 Feb 2005 17:09:29 -0600 (CST)

 In article <20050208165500.5355563B845@narn.netbsd.org>,
 	kessi@teles.de writes:
 
 > A LKM, called tlsload, owns an interface to trigger a kernel crash dump. This interface calls panic. I think, the expected result is a
 > kernel crash dump or core dump, but no dump is written.
 > 
 > Feb  8 13:17:06 iswitch2 /netbsd: --- syscall (number 54) ---
 > Feb  8 13:17:06 iswitch2 /netbsd: 0x480f43b3:
 > Feb  8 13:17:06 iswitch2 /netbsd: End traceback...
 > Feb  8 13:17:06 iswitch2 /netbsd: syncing disks... 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 giving up
 > Feb  8 13:17:06 iswitch2 /netbsd: 
 > Feb  8 13:17:06 iswitch2 /netbsd: dumping to dev 4,1 offset 1511
 > Feb  8 13:17:06 iswitch2 /netbsd: dump i/o error
 > Feb  8 13:17:06 iswitch2 /netbsd: 
 > Feb  8 13:17:06 iswitch2 /netbsd: 
 > Feb  8 13:17:06 iswitch2 /netbsd: sd0(ahc1:0:6:0): polling command not done
 > Feb  8 13:17:06 iswitch2 /netbsd: panic: scsipi_execute_xs
 
 In my experience, after a failed "sync" attempt, the scsi driver is usually
 too horked for the dump to take. If you set DDB_ONPANIC in the kernel config
 or with sysctl (see panic(9)), you'll drop into ddb, where you can try to skip
 the sync with "reboot 0x104". The 0x4 flag means "don't sync". (See ddb(4)).
 The apparently undocumented 0x100 flag means "try to dump".
 
 
 Frederick