From owner-freebsd-arm@freebsd.org Wed Aug 19 01:42:26 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3217E9BB973 for ; Wed, 19 Aug 2015 01:42:26 +0000 (UTC) (envelope-from amdmi3@amdmi3.ru) Received: from vps.amdmi3.ru (vps.amdmi3.ru [109.234.38.216]) by mx1.freebsd.org (Postfix) with ESMTP id EB34E2AE; Wed, 19 Aug 2015 01:42:25 +0000 (UTC) (envelope-from amdmi3@amdmi3.ru) Received: from hive.panopticon (unknown [78.153.152.119]) by vps.amdmi3.ru (Postfix) with ESMTPS id 7EF9AB059C; Wed, 19 Aug 2015 04:42:23 +0300 (MSK) Received: from hades.panopticon (hades.panopticon [192.168.0.32]) by hive.panopticon (Postfix) with ESMTP id 82217F0E; Wed, 19 Aug 2015 04:39:48 +0300 (MSK) Received: by hades.panopticon (Postfix, from userid 1000) id 9F66E31C8C; Wed, 19 Aug 2015 04:38:34 +0300 (MSK) Date: Wed, 19 Aug 2015 04:38:34 +0300 From: Dmitry Marakasov To: Ian Lepore Cc: "freebsd-arm@FreeBSD.org" Subject: Re: Instability likely related to new pmap on Cubieboard A10 Message-ID: <20150819013834.GD79354@hades.panopticon> References: <20150819002103.GC79354@hades.panopticon> <1439944961.242.150.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1439944961.242.150.camel@freebsd.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 01:42:26 -0000 * Ian Lepore (ian@freebsd.org) wrote: > > I've just tried latest HEAD on cubieboard A10, and discovered that > > it's completely unstable. Kernel boots without problems, however > > right after init is started many processes crash with sigsegv and > > other errors, and it ends with either hang or a panic. Examples > > below. With kernel built with `nooptions ARM_NEW_PMAP' these > > problems go away. Feel free to ask for any additional info. > > > > --- > > [...] > > --- > > That is, frankly, just hard to accept as real. ARM_NEW_PMAP has been > the default for like 8 months. If it was that broken, the first report > of it would have come in much earlier than this. That seems more like > some sort of broken or corrupted binary, and perhaps the problem went > away not because the option changed, but because changing the option > rebuilt whatever was corrupted. > > Actually, given that everything was fine until userland started, and > "bad syscall" shows up a lot in the errors, a kernel/userland mismatch > also seems like a good candidate. I've just rebuilt it again just to be sure, same thing - kernel with ARM_NEW_PMAP misbehaves. I'd add: - Both kernels were built with the same commands, from the same revision and with the clean /usr/obj; only difference is presence of `nooptions ARM_NEW_PMAP` - Both kernels use the same world, built from the same revision. It was not touched when changing kernels -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://amdmi3.ru