Date: Fri, 14 May 2010 12:39:42 -0500 From: Alan Cox <alc@cs.rice.edu> To: Benjamin Kaduk <kaduk@MIT.EDU> Cc: Kostik Belousov <kostikbel@gmail.com>, alc@freebsd.org, freebsd-current@freebsd.org, attilio@freebsd.org Subject: Re: kgdb unuseable with cores on current (for some people) Message-ID: <4BED8ADE.1030100@cs.rice.edu> In-Reply-To: <alpine.GSO.1.10.1005140243030.29136@multics.mit.edu> References: <alpine.GSO.1.10.1005140013260.29136@multics.mit.edu> <20100514053907.GL83316@deviant.kiev.zoral.com.ua> <alpine.GSO.1.10.1005140243030.29136@multics.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On 5/14/2010 1:44 AM, Benjamin Kaduk wrote:
> On Fri, 14 May 2010, Kostik Belousov wrote:
>
>> On Fri, May 14, 2010 at 12:55:35AM -0400, Benjamin Kaduk wrote:
>>> Hi all,
>>>
>>> As was revealed in a recent thread here [1], several people have been
>>> unable to use kgdb on coredumps for the past few months (but
>>> possibly not
>>> everyone).
>>>
>>> I am one of those affected, and have narrowed the breakage with a
>>> binary
>>> search to between SVN revisions 202883 and 202954 (that is, Jan 23
>>> 1200h
>>> and Jan 25 0000h). Looking at the changes, alc's revision 202897 and
>>> attilio's revision 202933 look to be the most plausible culprits in
>>> terms
>>> of what they touched. I will continue with my bisection, but with
>>> only 36
>>> revisions in play, it is probably worth looking for the bug in parallel
>>> with the bisection.
>>
>> Try reverting r202897 on fresh HEAD. I very much doubt that r202933
>> can be responsible.
>>
>
> Indeed, 202933 was cleared of blame in the latest bisection. I'm
> currently pulling up to HEAD and will try reverting 202897.
I suspect the following is needed:
Index: vm/vm_page.c
===================================================================
--- vm/vm_page.c (revision 207823)
+++ vm/vm_page.c (working copy)
@@ -108,6 +108,7 @@ __FBSDID("$FreeBSD$");
#include <sys/kernel.h>
#include <sys/limits.h>
#include <sys/malloc.h>
+#include <sys/msgbuf.h>
#include <sys/mutex.h>
#include <sys/proc.h>
#include <sys/sysctl.h>
@@ -375,6 +376,14 @@ vm_page_startup(vm_offset_t vaddr)
new_end + vm_page_dump_size, VM_PROT_READ | VM_PROT_WRITE);
bzero((void *)vm_page_dump, vm_page_dump_size);
#endif
+#ifdef __amd64__
+ pa = DMAP_TO_PHYS((vm_offset_t)msgbufp);
+ last_pa = pa + round_page(MSGBUF_SIZE);
+ while (pa < last_pa) {
+ dump_add_page(pa);
+ pa += PAGE_SIZE;
+ }
+#endif
/*
* Compute the number of pages of memory that will be available for
* use (taking into account the overhead of a page structure per
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4BED8ADE.1030100>