RPI-B VM panic

[Hans Petter Selasky]

On 06/12/14 19:32, Ian Lepore wrote:
> On Thu, 2014-06-12 at 19:28 +0200, Hans Petter Selasky wrote:
>> On 06/12/14 19:12, Alan Cox wrote:
>>> 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.
>>>
>>
>> Here you go:
>>
>>> panic: vm_page_insert_after: msucc 0xc0993e50 (0) doesn't succeed pindex 4
>>> object 0xc1a2b140 type 0
>>> KDB: enter: panic
>>> [ thread pid 18 tid 100052 ]
>>> Stopped at      $d:     ldrb    r15, [r15, r15, ror r15]!
>>> db>
>
> Could this be related to changing superpages to enabled by default
> recently?  Easy to test by setting vm.pmap.sp_enabled=0 in ubldr
>

Setting the sp_enabled to 0 does not fix the problem.

--HPS