Date: Sun, 15 Mar 2020 14:23:09 -0700 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: freebsd-arm@freebsd.org Subject: Re: Panic on Rpi3 at r358976 Message-ID: <928F18E3-C6DD-439D-9A38-20207DB655CB@yahoo.com> In-Reply-To: <20200315163147.GA57657@www.zefox.net> References: <20200315041203.GA55605@www.zefox.net> <8B479A0D-AEBB-4D83-9CE1-D68AFDA568A8@yahoo.com> <20200315163147.GA57657@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2020-Mar-15, at 09:31, bob prohaska <fbsd@www.zefox.net> wrote:
> On Sat, Mar 14, 2020 at 09:48:52PM -0700, Mark Millard wrote:
>>=20
>>=20
>> On 2020-Mar-14, at 21:12, bob prohaska <fbsd at www.zefox.net> wrote:
>>=20
>>> Tried to boot a kernel built from r358976 on a Pi3 and got a panic:
>>> panic: Failed to start CPU 1 (1)
>>>=20
>>> cpuid =3D 0
>>> time =3D 1
> [snippage]
>>>=20
>>> KDB: enter: panic
>>> [ thread pid 0 tid 0 ]
>>> Stopped at 0
>>> db> reboot
>>> cpu_reset failed
>>>=20
>>> The Pi3 started at r351836, src was updated to r358976 and
>>> only the kernel-toolchain and kernel were built/installed.=20
>>>=20
>>> If this is worth a bug report please let me know.
>>=20
>> 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.
>>=20
>=20
> No patches, just a test to see if anything has changed.=20
> The lack of errors from psci made me think this might
> be new. Guess not.
psci is in armstub8.bin and is involved in starting CPUs.
(But I did not try to analyze more detail on a RPi3.)
Also, it failed vastly earlier than in your prior
reports, well before any psci messages were output
previously. Using text from a rpi4 boot to show the
sort of things to expect just after "module firmware
already present!" when things are working (with
boot -v being in use to give more context):
Copyright (c) 1992-2020 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights =
reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 13.0-CURRENT #57 r357529M: Sun Feb 9 21:31:10 PST 2020
=
markmi@FBSDFHUGE:/usr/obj/cortexA53_clang/arm64.aarch64/usr/src/arm64.aarc=
h64/sys/GENERIC-NODBG arm64
FreeBSD clang version 9.0.1 (git@github.com:llvm/llvm-project.git =
c1a0a213378a458fbea1a5c77b315c7dce08fd05) (based on LLVM 9.0.1)
VT(efifb): resolution 1824x984
Preloaded elf kernel "/boot/kernel/kernel" at 0xffff000001568000.
Preloaded elf module "/boot/kernel/ucom.ko" at 0xffff000001571020.
Preloaded boot_entropy_cache "/boot/entropy" at 0xffff0000015717f8.
Preloaded elf module "/boot/kernel/umodem.ko" at 0xffff000001571850.
module firmware already present!
Starting CPU 1 (1)
Starting CPU 2 (2)
Starting CPU 3 (3)
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
random: read 4096 bytes from preloaded cache
random: unblocking device.
VIMAGE (virtualized network stack) enabled
ULE: setup cpu 0
ULE: setup cpu 1
ULE: setup cpu 2
ULE: setup cpu 3
. . .
That is not very far into the kernel's booting
activity.
>> 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.
>>=20
>=20
> 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.=20
> I've reported the cpu_reset failure, but your comments seem
> much more to the essence of the problem.
=46rom what has been reported on the lists, it is unlikely
FreeBSD is what would change. Wrong place for a bug
report or for tracking any changes.
For, say, u-boot, it would be upstream that would need a
bug report. The FreeBSD port would at most get one=20
requesting to pick up and use the change --once there
was such a change to pick up.
>> (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.
>>=20
> 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.=20
>=20
Intersting. If -r356767 has problems, it may be that having
armstub8.bin RAM pages avoided might just get you back to
the -r356767 status. I do not know if bisecting before
-r356767 might give useful information on one or more
separate problems or not.
=3D=3D=3D
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?928F18E3-C6DD-439D-9A38-20207DB655CB>