svn commit: r266850 - in head/sys/arm/xscale: i80321 i8134x ixp425 pxa

[John-Mark Gurney]

Olivier Houchard wrote this message on Thu, May 29, 2014 at 19:38 +0200:
> On Thu, May 29, 2014 at 10:19:18AM -0700, Adrian Chadd wrote:
> > On 29 May 2014 10:16, Olivier Houchard <cognet at ci0.org> wrote:
> > > On Thu, May 29, 2014 at 10:14:53AM -0700, Adrian Chadd wrote:
> > >> Have you tested this on xscale hardware?
> > >
> > >
> > > Yeah, my two last commits were an attempt to get the AVILA kernel to boot
> > > again.
> > 
> > Woo! What can I provide to help you do this? :-)
> > 
> > (Drinks? Food? Donations?)
> > 
> > 
> 
> Drinks and food are always appreciated ;)
> It almost boots for me now, except a few userland programs gets SIGSEGV or
> SIGILL along the way, trying to figure out why.

Thanks for fixing ddb... I'm getting panic messages again...  bad
news is that my panic is still around:
panic: vm_page_alloc: page 0xc07e73b0 is wired

Though, interestingly, it looks like sparc64 has a similar panic:
https://www.freebsd.org/cgi/query-pr.cgi?pr=187080

kib, Alan, any clue to why this is happening?  Any suggestions as to
help track it down?

Lastest dump of the vm_page from a tree from today is:
{'act_count': '\x00',
 'aflags': '\x00',
 'busy_lock': 1,
 'dirty': '\xff',
 'flags': 0,
 'hold_count': 0,
 'listq': {'tqe_next': 0xc07e7400, 'tqe_prev': 0xc06e63a0},
 'md': {'pv_kva': 3235893248,
        'pv_list': {'tqh_first': 0x0, 'tqh_last': 0xc07e73e0},
        'pv_memattr': '\x00',
        'pvh_attrs': 0},
 'object': 0xc06e6378,
 'oflags': '\x04',
 'order': '\t',
 'phys_addr': 9424896,
 'pindex': 3581,
 'plinks': {'memguard': {'p': 0, 'v': 3228461644},
            'q': {'tqe_next': 0x0, 'tqe_prev': 0xc06e6a4c},
            's': {'pv': 0xc06e6a4c, 'ss': {'sle_next': 0x0}}},
 'pool': '\x00',
 'queue': '\xff',
 'segind': '\x02',
 'valid': '\xff',
 'wire_count': 1}

This appears to be on the kmem_object list as:
c06e62d8 B kernel_object_store
c06e6378 B kmem_object_store
c06e6418 b old_msync

and you can see the tqh_last would be part of kmem_object_store...

Could this be something bad happening w/ when memory is low?  The
board I'm testing on has only 64MB (54MB avail), so it hits that
pretty quickly...

Thanks for any help you can provide.

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."