[issue530] crash from latest -HEAD

Matthew Dillon dillon at apollo.backplane.com
Thu Mar 8 08:59:29 PST 2007

:Peter Avalos <pavalos at theshell.com> added the comment:
:Ok, looks like I got another one from Jan 31 sources:
:at /usr/src/sys/platform/pc32/i386/exception.s:783
:#7  0x00000000 in ?? ()
:#8  0xc028f21f in vm_pageout () at /usr/src/sys/vm/vm_pageout.c:787
:Previous frame inner to this frame (corrupt stack?)
:kernel, vmcore, and possible kernel modules are uploaded to my crash/ on 
:leaf.  Look for *.2.

    The pageout daemon is conking out on this:

    if (m->object->ref_count == 0) {

    m->object is NULL.  So the question is why is there a page without
    an associated object sitting on the inactive queue ?

    I think this is the second time this panic has been reported.

    The only code path I see that could put a page in that state is from
    vm_object_terminate(), when it encounters a wired page while destroying
    an object.  I think that code needs to move the page to the HOLD
    queue in order to fix the problem, but I would like to catch it in the
    act first.

    Here is a patch that will kprintf() pages that I think are causing the
    problem.  If we get this just before a similar crash, and its the
    same page as the one that the pageout code crashed on (The %esi 
    register in the trapframe points to the vm_page in the crash), then
    we will have found it.

    Think you can reproduce it?  It looks like the issue might be related
    to page wiring or a program being terminated while undergoing paging I/O.

Index: vm/vm_object.c
RCS file: /cvs/src/sys/vm/vm_object.c,v
retrieving revision 1.29
diff -u -r1.29 vm_object.c
--- vm/vm_object.c	28 Dec 2006 21:24:02 -0000	1.29
+++ vm/vm_object.c	8 Mar 2007 16:51:04 -0000
@@ -460,6 +460,7 @@
 	} else {
+		kprintf("vm_object_terminate: Warning: Encountered wired page %p\n", p);

More information about the Bugs mailing list