partial memory dump

[Dan Nelson]

In the last episode (Mar 08), Vijay.Singh at nokia.com said:
> Hi, thanks for the quick reply. I do indeed write the bitmap, which
> is a part of the sysdump_hdr structure to the disk. The disk routine
> does not currently report that it had to miss any block. Here is what
> I get from dadump().
> 
> dumpsys() in machdep.c
> 	dumping to dev 20401, offset 0
> 
> dadump()
> 	dodump: 1
> 	USRSTACK: 0xbfbfc000 to 0xe6fa5000
> 	Maxmem: 524288, secsize: 512
> 	dumplo: 0, num: 84872, size: 2097152
> 	next block to write: 90640 @ 8 blocks/req
> 	Dumping bitmap at addr e6fa5000 to sec 16210, 88 sectors
> 	next block to write: 90776 @ 8 blocks/req
> 	Dumping 0x2960 pages of memory to sec 0x16298, 0x14b00 sectors
> 
> This version of dadump() does not implement write combining yet. Do
> you think savecore is not able to find the data blocks correctly in
> the swap?

No, my worry is that the file savecore is writing is not layed out the
way that gdb expects it.  gdb is looking for a vmcore the size of your
physical memory, where (for example) address 0xe6fa5000 in the system
at the time of the crash is at file offset 0xe6fa5000 in vmcore. 
savecore needs to read that bitmap, and make sure it fseek()'s the
output file pointer to the correct location when it writes its blocks. 
If you're already doing this, then I've exhausted my limited coredump
debugging abilities...

I also think you should be modifying /sys/i386/i386/dump_machdep.c
instead of scsi_da.c; that would let your changes work with any disk
backend.  The low-level dadump() function shouldn't really have any
knowledge of what it's writing.  That's something to fix once you're
ready to release you code :)

-- 
	Dan Nelson
	dnelson at allantgroup.com