RPI-B VM panic

Alan Cox alc at rice.edu
Thu Jun 12 17:12:35 UTC 2014


On 06/12/2014 01:03, Hans Petter Selasky wrote:
> On 06/11/14 22:47, Alan Cox wrote:
>>
>> On Jun 11, 2014, at 3:45 PM, Hans Petter Selasky wrote:
>>
>>> On 06/11/14 22:20, Alan Cox wrote:
>>>>
>>>> On Jun 11, 2014, at 3:07 PM, Hans Petter Selasky wrote:
>>>>
>>>>> kernel:     file format elf32-littlearm
>>>>>
>>>>
>>>> Then this problem is unrelated to the one that I just fixed.  It's
>>>> also not a problem that I've seen before.
>>>
>>> It is happening after your recent patches to -current, optimising
>>> the "page ordering". Happens every now and then during boot when
>>> stack is growing looks like.
>>
>> More precisely, which commit is that?
>>
>
>> commit 7d20e37fb658b0e2cd7f3c13dac8022e0e866a21
>> Author: alc <alc at FreeBSD.org>
>> Date:   Sun May 12 16:50:18 2013 +0000
>>
>>     Refactor vm_page_alloc()'s interactions with
>> vm_reserv_alloc_page() and
>>     vm_page_insert() so that (1) vm_radix_lookup_le() is never called
>> while the
>>     free page queues lock is held and (2) vm_radix_lookup_le() is
>> called at most
>>     once.  This change reduces the average time that the free page
>> queues lock
>>     is held by vm_page_alloc() as well as vm_page_alloc()'s average
>> overall
>>     running time.
>>
>>     Sponsored by:       EMC / Isilon Storage Division
>>
>
>

That's not exactly a recent commit.  It was 13 months ago.  And, this
code is exercised by all page allocations except for page table pages
and uma_small_alloc().

What this assertion is telling us is that somewhere else we have screwed
up the vm object to which we are now trying to allocate a page.

Try the attached patch.  It will provide additional information the next
time that the assertion fails.

Has anyone else seen this assertion fail?

-------------- next part --------------
Index: vm/vm_page.c
===================================================================
--- vm/vm_page.c	(revision 267411)
+++ vm/vm_page.c	(working copy)
@@ -975,7 +975,9 @@ vm_page_insert_after(vm_page_t m, vm_object_t obje
 		msucc = TAILQ_FIRST(&object->memq);
 	if (msucc != NULL)
 		KASSERT(msucc->pindex > pindex,
-		    ("vm_page_insert_after: msucc doesn't succeed pindex"));
+		    ("vm_page_insert_after: msucc %p (%ju) doesn't succeed pindex %ju\n"
+"object %p type %d",
+msucc, (uintmax_t)msucc->pindex, (uintmax_t)pindex, object, object->type));
 
 	/*
 	 * Record the object/offset pair in this page


More information about the freebsd-arm mailing list