RPI-B VM panic

[Ian Lepore]

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

-- Ian