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

[Alan Cox]

On 05/30/2014 01:32, John-Mark Gurney wrote:
> 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?

I'm afraid not.  The dump below shows a perfectly normal, in-use page. 
If this page had actually been free prior to the vm_page_alloc() call,
then other fields, like dirty, would have been different.  In other
words, this isn't just a problem with the wire count.

What object is vm_page_alloc() being performed on?

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