RPI-B VM panic

[Alan Cox]

On 06/12/2014 12:53, Hans Petter Selasky wrote:
> 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
>

Use the ddb command "object", not "vmochk".

> ....
>
>> 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
>
>
>