On Fri, 14 May 2010, Alan Cox wrote:
On 5/14/2010 1:44 AM, Benjamin Kaduk wrote:
On Fri, 14 May 2010, Kostik Belousov wrote:
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.
HEAD with 202897 reverted works;
HEAD with the patch below does not work
Hm, but the "Cannot access memory" is preceeded by "Unread portion of the
kernel message buffer:\n"; I don't remember whether that was there before.
I'll compile another kernel from stock HEAD to check if that's actually
due to the patch (or just poor memory on my part).
Any other thoughts, Alan?
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
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
