RPI-B VM panic

[Hans Petter Selasky]

On 06/12/14 19:41, Hans Petter Selasky wrote:
> 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

Output from the debugger regarding the object:

> panic: vm_page_insert_after: msucc 0xc0993e50 (0) doesn't succeed pindex 4
> object 0xc1a2b1e0 type 0
> KDB: enter: panic

> db> show vmochk
> vmochk: internal obj is not in a map: ref: 1, size: 2: 0x2, backing_object: 0
> vmochk: internal obj is not in a map: ref: 1, size: 2: 0x2, backing_object: 0

....

> db> show vmopag

....

> new object: 0xc1a2b1e0
>  index(0)run(1)pa(0x1766000)
>  index(1)run(1)pa(0x1e17000)
>  index(2)run(2)pa(0x1772000)
>  index(4)run(1)pa(0x1e6a000)
>  index(5)run(2)pa(0x1775000)
>  index(7)run(1)pa(0x1778000)
>  index(8)run(1)pa(0x1788000)
>  index(9)run(1)pa(0x17e9000)

--HPS