Date: Fri, 30 May 2014 11:04:01 -0500 From: Alan Cox <alc@rice.edu> To: Olivier Houchard <cognet@Xi0.org>, Adrian Chadd <adrian@freebsd.org>, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org>, alc@FreeBSD.org, kib@FreeBSD.org Subject: Re: svn commit: r266850 - in head/sys/arm/xscale: i80321 i8134x ixp425 pxa Message-ID: <5388ABF1.3030200@rice.edu> In-Reply-To: <20140530063228.GD43976@funkthat.com> References: <201405291656.s4TGudoD002868@svn.freebsd.org> <CAJ-Vmon2sup%2Bvd%2Bpi2fdjv5DaxS%2BxtG1FxmfSV%2B%2BrK1KydXRvw@mail.gmail.com> <20140529171641.GA5246@ci0.org> <CAJ-Vmo=h39AYXhPFBx7dzUe%2BQtksPB8QMaAQcoqoM6UiKZe2XA@mail.gmail.com> <20140529173803.GA5294@ci0.org> <20140530063228.GD43976@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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. >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5388ABF1.3030200>