From owner-freebsd-arm@freebsd.org Wed Aug 19 00:42:49 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 D17169BCC9A for ; Wed, 19 Aug 2015 00:42:49 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AAA46635 for ; Wed, 19 Aug 2015 00:42:49 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from ilsoft.org (unknown [73.34.117.227]) by outbound1.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Wed, 19 Aug 2015 00:43:06 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t7J0gf6A002466; Tue, 18 Aug 2015 18:42:42 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1439944961.242.150.camel@freebsd.org> Subject: Re: Instability likely related to new pmap on Cubieboard A10 From: Ian Lepore To: Dmitry Marakasov Cc: "freebsd-arm@FreeBSD.org" Date: Tue, 18 Aug 2015 18:42:41 -0600 In-Reply-To: <20150819002103.GC79354@hades.panopticon> References: <20150819002103.GC79354@hades.panopticon> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.12.10 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit 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 00:42:49 -0000 On Wed, 2015-08-19 at 03:21 +0300, Dmitry Marakasov wrote: > Hi! > > 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. -- Ian