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) > _at__at_ -108,6 +108,7 _at__at_ __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> > _at__at_ -375,6 +376,14 _at__at_ 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 > >Received on Fri May 14 2010 - 16:39:38 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:03 UTC