Date: Thu, 12 Jun 2014 12:12:31 -0500 From: Alan Cox <alc@rice.edu> To: Hans Petter Selasky <hps@selasky.org>, "arm@freebsd.org" <arm@freebsd.org> Subject: Re: RPI-B VM panic Message-ID: <5399DF7F.4010501@rice.edu> In-Reply-To: <539942C0.5010706@selasky.org> References: <539170AA.2000109@selasky.org> <5396947A.1060601@selasky.org> <5396A0D1.80309@selasky.org> <5396AF63.6040209@selasky.org> <8BA66A45-E08A-475D-A1FA-5047E862681E@rice.edu> <5398B6EA.9030408@selasky.org> <A9433B36-C15C-455E-AB80-3999596936F9@rice.edu> <5398BFD9.60502@selasky.org> <7390A211-C949-4079-B3DA-BF23798B8992@rice.edu> <539942C0.5010706@selasky.org>
next in thread | previous in thread | raw e-mail | index | archive | help
This is a multi-part message in MIME format.
--------------040103050600070308080401
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
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@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?
--------------040103050600070308080401
Content-Type: text/plain; charset=ISO-8859-15;
name="hps_page_insert_after1.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="hps_page_insert_after1.patch"
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
--------------040103050600070308080401--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5399DF7F.4010501>