Date: Tue, 28 Apr 2020 20:17:22 +0000 From: Glen Barber <gjb@freebsd.org> To: Mark Millard <marklmi@yahoo.com> Cc: bob prohaska <fbsd@www.zefox.net>, freebsd-arm@freebsd.org Subject: Re: Trouble booting the April 23 snapshot for rpi3 Message-ID: <20200428201722.GI9584@FreeBSD.org> In-Reply-To: <46FAA17D-6104-4DAC-A0AA-63ED4DDD72DC@yahoo.com> References: <20200428195759.GA7169@www.zefox.net> <46FAA17D-6104-4DAC-A0AA-63ED4DDD72DC@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--ltaNo38lfiiImPbJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 28, 2020 at 01:11:58PM -0700, Mark Millard via freebsd-arm wrot= e: >=20 >=20 > On 2020-Apr-28, at 12:57, bob prohaska <fbsd at www.zefox.net> wrote: >=20 > > In trying to boot the April 23 RPI3 snapshot the machine is > > reporting what looks like an old problem: > >=20 > > ---<<BOOT>>--- > > KDB: debugger backends: ddb > > KDB: current backend: ddb > > 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 #0 r360211: Thu Apr 23 08:12:13 UTC 2020 > > root@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENE= RIC arm64 > > FreeBSD clang version 10.0.0 (git@github.com:llvm/llvm-project.git llvm= org-10.0.0-0-gd32170dbd5b) > > WARNING: WITNESS option enabled, expect reduced performance. > > VT(efifb): resolution 1920x1200 > > module firmware already present! > > KLD file umodem.ko is missing dependencies > > Starting CPU 1 (1) > > panic: Failed to start CPU 1 (1), error -1 > >=20 > > cpuid =3D 0 > > time =3D 1 > > KDB: stack backtrace: > > db_trace_self() at db_trace_self_wrapper+0x28 > > pc =3D 0xffff00000075c2d4 lr =3D 0xffff0000001088b8 > > sp =3D 0xffff000000010590 fp =3D 0xffff000000010790 > >=20 > > db_trace_self_wrapper() at vpanic+0x194 > > pc =3D 0xffff0000001088b8 lr =3D 0xffff000000415a74 > > sp =3D 0xffff0000000107a0 fp =3D 0xffff0000000107f0 > >=20 > > vpanic() at panic+0x44 > > pc =3D 0xffff000000415a74 lr =3D 0xffff00000041581c > > sp =3D 0xffff000000010800 fp =3D 0xffff0000000108b0 > >=20 > > panic() at start_cpu+0x224 > > pc =3D 0xffff00000041581c lr =3D 0xffff00000076a5b0 > > sp =3D 0xffff0000000108c0 fp =3D 0xffff0000000108c0 > >=20 > > start_cpu() at cpu_init_fdt+0x34 > > pc =3D 0xffff00000076a5b0 lr =3D 0xffff0000007698b0 > > sp =3D 0xffff0000000108d0 fp =3D 0xffff000000010930 > >=20 > > cpu_init_fdt() at ofw_cpu_early_foreach+0x180 > > pc =3D 0xffff0000007698b0 lr =3D 0xffff00000020c648 > > sp =3D 0xffff000000010940 fp =3D 0xffff000000010990 > >=20 > > ofw_cpu_early_foreach() at mp_start+0x8c > > pc =3D 0xffff00000020c648 lr =3D 0xffff000000470490 > > sp =3D 0xffff0000000109a0 fp =3D 0xffff0000000109f0 > >=20 > > mp_start() at mi_startup+0x12c > > pc =3D 0xffff000000470490 lr =3D 0xffff0000003a9ac4 > > sp =3D 0xffff000000010a00 fp =3D 0xffff000000010a20 > >=20 > > mi_startup() at virtdone+0x5c > > pc =3D 0xffff0000003a9ac4 lr =3D 0xffff00000000108c > > sp =3D 0xffff000000010a30 fp =3D 0x0000000000000000 > >=20 > > KDB: enter: panic > > [ thread pid 0 tid 0 ] > > Stopped at 0 > > db>=20 > > db> bt > > Tracing pid 0 tid 0 td 0xffff000000cedb80 > > db_trace_self() at db_stack_trace+0xfc > > pc =3D 0xffff00000075c2d4 lr =3D 0xffff000000105cbc > > sp =3D 0xffff000000010180 fp =3D 0xffff000000010190 > >=20 > > db_stack_trace() at db_command+0x228 > > pc =3D 0xffff000000105cbc lr =3D 0xffff000000105920 > > sp =3D 0xffff0000000101a0 fp =3D 0xffff000000010250 > >=20 > > db_command() at db_command_loop+0x54 > > pc =3D 0xffff000000105920 lr =3D 0xffff0000001056c8 > > sp =3D 0xffff000000010260 fp =3D 0xffff0000000102b0 > >=20 > > db_command_loop() at db_trap+0xf4 > > pc =3D 0xffff0000001056c8 lr =3D 0xffff000000108a20 > > sp =3D 0xffff0000000102c0 fp =3D 0xffff0000000104e0 > >=20 > > db_trap() at kdb_trap+0x1cc > > pc =3D 0xffff000000108a20 lr =3D 0xffff00000045e10c > > sp =3D 0xffff0000000104f0 fp =3D 0xffff000000010550 > >=20 > > kdb_trap() at do_el1h_sync+0xf4 > > pc =3D 0xffff00000045e10c lr =3D 0xffff00000077a8a4 > > sp =3D 0xffff000000010560 fp =3D 0xffff0000000105b0 > >=20 > > do_el1h_sync() at handle_el1h_sync+0x78 > > pc =3D 0xffff00000077a8a4 lr =3D 0xffff00000075e878 > > sp =3D 0xffff0000000105c0 fp =3D 0xffff000000010700 > >=20 > > handle_el1h_sync() at kdb_enter+0x34 > > pc =3D 0xffff00000075e878 lr =3D 0xffff00000045d730 > > sp =3D 0xffff000000010710 fp =3D 0xffff000000010790 > >=20 > > kdb_enter() at vpanic+0x1b0 > > pc =3D 0xffff00000045d730 lr =3D 0xffff000000415a90 > > sp =3D 0xffff0000000107a0 fp =3D 0xffff0000000107f0 > >=20 > > vpanic() at panic+0x44 > > pc =3D 0xffff000000415a90 lr =3D 0xffff00000041581c > > sp =3D 0xffff000000010800 fp =3D 0xffff0000000108b0 > >=20 > > panic() at start_cpu+0x224 > > pc =3D 0xffff00000041581c lr =3D 0xffff00000076a5b0 > > sp =3D 0xffff0000000108c0 fp =3D 0xffff0000000108c0 > >=20 > > start_cpu() at cpu_init_fdt+0x34 > > pc =3D 0xffff00000076a5b0 lr =3D 0xffff0000007698b0 > > sp =3D 0xffff0000000108d0 fp =3D 0xffff000000010930 > >=20 > > cpu_init_fdt() at ofw_cpu_early_foreach+0x180 > > pc =3D 0xffff0000007698b0 lr =3D 0xffff00000020c648 > > sp =3D 0xffff000000010940 fp =3D 0xffff000000010990 > >=20 > > ofw_cpu_early_foreach() at mp_start+0x8c > > pc =3D 0xffff00000020c648 lr =3D 0xffff000000470490 > > sp =3D 0xffff0000000109a0 fp =3D 0xffff0000000109f0 > >=20 > > mp_start() at mi_startup+0x12c > > pc =3D 0xffff000000470490 lr =3D 0xffff0000003a9ac4 > > sp =3D 0xffff000000010a00 fp =3D 0xffff000000010a20 > >=20 > > mi_startup() at virtdone+0x5c > > pc =3D 0xffff0000003a9ac4 lr =3D 0xffff00000000108c > > sp =3D 0xffff000000010a30 fp =3D 0x0000000000000000 > >=20 > > db>=20 > >=20 > > Reboot fails with cpu reset failed. This looks to my eye like > > the problem discussed in the thread "Re: Panic on Rpi3 at r358976" > > but that conversation ended in mid-March and I thought was resolved. > >=20 > > Is anybody else having trouble with this snapshot? The filename is > > FreeBSD-13.0-CURRENT-arm64-aarch64-RPI3-20200423-r360211.img >=20 > What version of u-boot-rpi3 materials is in the snapshot? Is > it based on: Quarterly packages? Latest packages? Its own > build of the most-recent sysutils/u-boot-rpi3 source at > the time? >=20 > My guess: Based on the quarterly package --and quarterly may > not have been updated at the time of the snapshot build. >=20 It is based on the latest branch, but more specifically the port is built from a checkout of head from the ports tree. Glen --ltaNo38lfiiImPbJ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEjRJAPC5sqwhs9k2jAxRYpUeP4pMFAl6oj1IACgkQAxRYpUeP 4pMkqBAAk4dKPM9awQjzc1xiBx3AjxqAg5QEape2NGNgN9uAKM3If4fsI1/rfNpB 24dSJ5zQU6XPJjLWIxwAs+KrO89KxiYigp5OnZ8jw85agFIgVzcemZfgBqrgjGRU O+HrxJ9PlznqoNJT5ht6d5eeKvAP7VOYgPZfMK67v8k+nXNNcO9ysa+6SQ1853QC vf4Hesl9oA8ZZcvbtiNuZTE/bHjjRgxOWHevOYC7eTJy29cMfQ6lmXUIWlHkRgRD 4Rv9kXmexOGcwL/Vl5mEqh8PoT5vepEo/lDHKvA6iPvU1/hdseOVlomnhvsEZdLr TtSbbHMd66sK05qrhgL2aj7ItIfJx1lHA+GG8vAlcQLIhykEZ0LniF/oIZ4AU2rL u88wkaUM1I0I/IfulgQEanXng4Kr7LClLe9yg5uRTGzexw608k37HXVYW3xVtGil AUAikCsdmZFKA3uDdaYghWBs1reX7P/+Tt1nTycvSHQzcbn33r31z9RGtCu/eBhx mWMPObeGwPL6jDWx4heJZkU0hqkWpJJg2x/Aj+4Tf7dnBHwuppuCEL1hxzT6JtUh OXVpBLeeKdDMHVXQy218LDSj9x4CZTON72EZ2+XY4A5pob6COP04jzuArzqd6E6k Sn+ekwBuNe0uz1lXcJks+O8M6itwS9JQSQGLVX0zaDt9hFzivGE= =GUxZ -----END PGP SIGNATURE----- --ltaNo38lfiiImPbJ--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200428201722.GI9584>