Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 04 Sep 2010 22:54:07 +0300
From:      Andriy Gapon <avg@freebsd.org>
To:        freebsd-current@freebsd.org
Subject:   Re: problem with amd64 minidump
Message-ID:  <4C82A3DF.2000809@freebsd.org>
In-Reply-To: <4C7FA1BF.30206@freebsd.org>
References:  <4C7F782B.8050507@freebsd.org> <4C7FA1BF.30206@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
on 02/09/2010 16:08 Andriy Gapon said the following:
> on 02/09/2010 13:10 Andriy Gapon said the following:
>>
>> Not sure if this is some local issue or a problem in FreeBSD code.
>> I remember minidumps working perfectly well for me, but now I can not get data
>> from them.
>> Example:
>> dmesg -M /var/crash/vmcore.4
>> dmesg: _kvm_vatop: direct map address 0xffffff012fffffe0 not in minidump
>> dmesg: kvm_read: invalid address (0xffffff012fffffe0)
> 
> Not sure if it can help, but it seems that this virtual address in DMAP
> corresponds to a physical address in the last page of RAM.
> Do we use that for anything special?  Message buffer?
> I had a quick look at getmemsize() function in sys/amd64/amd64/machdep.c and it
> looks like the following code in the function could be doing just that:
> 
> Maxmem = atop(phys_avail[pa_indx]);
> 
> /* Trim off space for the message buffer. */
> phys_avail[pa_indx] -= round_page(MSGBUF_SIZE);
> 
> /* Map the message buffer. */
> msgbufp = (struct msgbuf *)PHYS_TO_DMAP(phys_avail[pa_indx]);
> 
> Oh, and yeah:
> (gdb) p msgbufp
> $4 = (struct msgbuf *) 0xffffff012fffffe0
> 
> But we do dump the message buffer.
> But somehow its dmap address is not resolved correctly.
> 
> This should ring a bell for someone knowledgeable of minidump and libkvm code, I
> believe.

Just for the record: this was triggered by having non-default MSGBUF_SIZE, see
r212174 for the fix.

-- 
Andriy Gapon



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C82A3DF.2000809>