Skip site navigation (1)Skip section navigation (2)
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>