From owner-freebsd-arm@FreeBSD.ORG Fri May 30 06:32:35 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AB8A9973; Fri, 30 May 2014 06:32:35 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 84438245E; Fri, 30 May 2014 06:32:35 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s4U6WSf3057079 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 May 2014 23:32:29 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s4U6WS4K057078; Thu, 29 May 2014 23:32:28 -0700 (PDT) (envelope-from jmg) Date: Thu, 29 May 2014 23:32:28 -0700 From: John-Mark Gurney To: Olivier Houchard Subject: Re: svn commit: r266850 - in head/sys/arm/xscale: i80321 i8134x ixp425 pxa Message-ID: <20140530063228.GD43976@funkthat.com> Mail-Followup-To: Olivier Houchard , Adrian Chadd , "freebsd-arm@freebsd.org" , alc@FreeBSD.org, kib@FreeBSD.org References: <201405291656.s4TGudoD002868@svn.freebsd.org> <20140529171641.GA5246@ci0.org> <20140529173803.GA5294@ci0.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140529173803.GA5294@ci0.org> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Thu, 29 May 2014 23:32:29 -0700 (PDT) Cc: alc@freebsd.org, kib@freebsd.org, "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 06:32:35 -0000 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 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."