Date: Sun, 15 Mar 2020 09:31:47 -0700 From: bob prohaska <fbsd@www.zefox.net> To: Mark Millard <marklmi@yahoo.com> Cc: freebsd-arm@freebsd.org, bob prohaska <fbsd@www.zefox.net> Subject: Re: Panic on Rpi3 at r358976 Message-ID: <20200315163147.GA57657@www.zefox.net> In-Reply-To: <8B479A0D-AEBB-4D83-9CE1-D68AFDA568A8@yahoo.com> References: <20200315041203.GA55605@www.zefox.net> <8B479A0D-AEBB-4D83-9CE1-D68AFDA568A8@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Mar 14, 2020 at 09:48:52PM -0700, Mark Millard wrote: > > > On 2020-Mar-14, at 21:12, bob prohaska <fbsd at www.zefox.net> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200315163147.GA57657>