Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 1 Jun 2014 01:11:53 -0700
From:      John-Mark Gurney <jmg@funkthat.com>
To:        Alan Cox <alc@rice.edu>
Cc:        alc@freebsd.org, kib@freebsd.org, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org>, Olivier Houchard <cognet@Xi0.org>
Subject:   Re: svn commit: r266850 - in head/sys/arm/xscale: i80321 i8134x ixp425 pxa
Message-ID:  <20140601081153.GU43976@funkthat.com>
In-Reply-To: <5388ABF1.3030200@rice.edu>
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> <5388ABF1.3030200@rice.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
Alan Cox wrote this message on Fri, May 30, 2014 at 11:04 -0500:
> 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?

Is this enough?  Or do you need more?

panic: vm_page_alloc: page 0xc07e73b0 is wired, obj: 0xc1500b40
KDB: enter: panic
[ thread pid 781 tid 100051 ]
Stopped at      kdb_enter+0x40: ldrb    r15, [r15, r15, ror r15]!
db> show object/f 0xc1500b40
Object 0xc1500b40: type=2, size=0xa, res=9, ref=0, flags=0x0 ruid -1 charge 0
 sref=0, backing_object(0)=(0)+0x0
  memory:=(off=0x0,page=0x8f0000),(off=0x1,page=0x8f1000),(off=0x2,page=0x8ee000),(off=0x3,page=0x8ef000),(off=0x4,page=0x8f3000),(off=0x5,page=0x8f4000)
   ...(off=0x6,page=0x8fa000),(off=0x7,page=0x8fb000),(off=0x8,page=0x8fc000)

If you need more, let me know what/how to get it, and I will...

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

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

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140601081153.GU43976>