On 01-May-2000 Matt D. Robinson wrote:
> On Mon, 1 May 2000, Brian Hall wrote:
>|>OK, after wasting some time with memory debugging libraries (dmalloc &
>|>electric
>|>fence), I realized kl_init_kern_info() is failing. I'm tracking down the
>|>reason(s) why now. At least this makes sense- I probably haven't yet made
>|>all
>|>the necessary modifications for it to work on Alpha.
>|>
>|>Hmm, looks like a problem while in cmpreadmem (set cmp_debug=1):
>|>
>|>====================================================
>|>(gdb) run
>|>Starting program: /CDR_UPLOAD/hallb/linux-2.2.13-1.0.3/cmd/lcrash/./lcrash
>|>./map.0 ./vmdump.0
>|>map = ./map.0, vmdump = ./vmdump.0, outfile = stdout
>|>
>|>Please wait...__cmploadindex(): cannot open() index file [2]: No such file
>|>or
>|>directory!
>|>cmppindexcreate(): Number of pages in dump: 12288
>|>cmppindexcreate(): Page size in dump: 8192
>|>..
>|>Attempting to save index "index.10" ... complete.
>|>...............cmpreadmem(): 8 bytes, 0x584c81 (just a page)
>|>__cmppread(): initiating search for 0x584c81
>|>__cmppindex(): hash = 16472, addr = 0x584c81
>|>__cmppindex(): addr = 0x584c81, tmpptr->addr = 0x584000
>|>__cmppread(): page not found! (0x584c81)
>|>
>|>Program exited with code 01.
>|>====================================================
>|>
>|>Now, I have set the system to compress the dump on the swap partition
>|>(DUMP_COMPRESS_PAGES=1); however when I look at the generated vmdump.0 file
>|>is
>|>does not look like it has been RLE encoded- there are long strings of 0x00
>|>repeating throughout the file. The vmdump.0 is ~69MB, while the real memory
>|>size of the machine is 96MB (#pages*pagesize is also 96MB).
>
> Looks like it's probably getting compressed based on your data.
>
>|>Looks to me like either the dump is getting truncated, or the dump
>|>compression
>|>routine has a problem? (DUMP_LEVEL=4, swap partition is 512MB) I am guessing
>|>that sp->s_addr is correct (this is the 0x584c81 being searched for in
>|>cmpreadmem).
>
> The sp->s_addr is probably correct, but the real question is whether
> or not the page is being read in properly. You'll need to find out if
> that page is actually in memory or not (0x584000). You can turn on
> some additional debugging in kl_cmp.c to print out page information from
> the page header as the information is dumped out. Set cmp_debug to 2
> and tell me what it says. If you see all the pages being read, then
> you've got what you need from the dump. If not, then there's a problem
> with compression.
With cmp_debug=2, here are the lines of interest:
__cmppindexcreate(): addr = 0x584000, hash = 16472 , counter = 706 , cur_addr
= 0x393f5a
__cmppindexcreate(): addr = 0x586000, hash = 24664 , counter = 707 , cur_addr
= 0x3951df
The "counter" value ranges from 0 to 12287, so that is all the pages. Looks
like the page is there, and the code fails to fetch it? Bad dog! grrr...
> I'd typically say it isn't compression as I've used that code for 32 and
> 64 bit systems in the past (for a few years). Still, there could be a
> problem.
>
>|>Is the vmdump.0 file supposed to be compressed on the disk if
>|>DUMP_COMPRESS_PAGES=1 ?
>
> Yes ... /sbin/vmdump config sets /proc/sys/vmdump/dump_compress_pages
> to the value based on DUMP_COMPRESS_PAGES.
# more /proc/sys/vmdump/dump_compress_pages
1
Viewing vmdump.0 with mc's hex text viewer, it sure doesn't look compressed to
me. Could you send me a vmdump file that is compressed, so I can see what is
looks like? (maybe just the first 100KB or so)
--
http://www.bigfoot.com/~brihall
Linux Consultant
|