From owner-freebsd-arm@freebsd.org Sun Mar 15 16:31:31 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C9279272980 for ; Sun, 15 Mar 2020 16:31:31 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 48gQ1G1MyJz3JkZ for ; Sun, 15 Mar 2020 16:31:29 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id 02FGVm7Z057713 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 15 Mar 2020 09:31:49 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id 02FGVmg4057712; Sun, 15 Mar 2020 09:31:48 -0700 (PDT) (envelope-from fbsd) Date: Sun, 15 Mar 2020 09:31:47 -0700 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: Panic on Rpi3 at r358976 Message-ID: <20200315163147.GA57657@www.zefox.net> References: <20200315041203.GA55605@www.zefox.net> <8B479A0D-AEBB-4D83-9CE1-D68AFDA568A8@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8B479A0D-AEBB-4D83-9CE1-D68AFDA568A8@yahoo.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-Rspamd-Queue-Id: 48gQ1G1MyJz3JkZ X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net X-Spamd-Result: default: False [3.26 / 15.00]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; IP_SCORE(0.06)[ip: (0.24), ipnet: 50.1.16.0/20(0.12), asn: 7065(-0.03), country: US(-0.05)]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.93)[0.928,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.38)[0.378,0]; R_SPF_NA(0.00)[]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; MID_RHS_WWW(0.50)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2020 16:31:31 -0000 On Sat, Mar 14, 2020 at 09:48:52PM -0700, Mark Millard wrote: > > > On 2020-Mar-14, at 21:12, bob prohaska wrote: > > > Tried to boot a kernel built from r358976 on a Pi3 and got a panic: > > panic: Failed to start CPU 1 (1) > > > > cpuid = 0 > > time = 1 [snippage] > > > > KDB: enter: panic > > [ thread pid 0 tid 0 ] > > Stopped at 0 > > db> reboot > > cpu_reset failed > > > > The Pi3 started at r351836, src was updated to r358976 and > > only the kernel-toolchain and kernel were built/installed. > > > > If this is worth a bug report please let me know. > > Have you done something to deal with the kernel not being > told to avoid touching memory that holds armstub8.bin ? > You do not mention such. > No patches, just a test to see if anything has changed. The lack of errors from psci made me think this might be new. Guess not. > I'm not aware of any changes to sysutils/u-boot-rpi3 or > to sysutils/rpi-firmware ( via its armstub8.bin ) or to > FreeBSD for the issue. You would be doing your own > patching and building as far as I know. > Is there a bug report which can be followed to track progress? If not, would it make sense to start one? It's a little unclear whether this is a ports issue, arm issue or both. Very clearly folks on this list are aware, but isn't obvious if others are. I've reported the cpu_reset failure, but your comments seem much more to the essence of the problem. > (For the rpi4, I kept my investigatory sysutils/u-boot-rpi4 > patch that I used, providing a hackish workaround for now.) > > Anything after head -r356767 ( such as -r356776 ) is > going to show garbage-in/garbage-out behavior that need > not be uniform from version to version. > Head -r356767 seemed prone to crash for other reasons. That's how the system got reverted to r351836. It's slow when accessing microSD but does successfully make buildworld. Thanks for reading, bob prohaska