From owner-freebsd-arm@freebsd.org Sun Mar 15 21:23:18 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 C92D527964E for ; Sun, 15 Mar 2020 21:23:18 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-21.consmr.mail.gq1.yahoo.com (sonic305-21.consmr.mail.gq1.yahoo.com [98.137.64.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 48gXTw54JVz4YVm for ; Sun, 15 Mar 2020 21:23:16 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: Tx7Z7EsVM1mP6Eb_pYn8Uya_WKsDpZI32seInv64fR6sgBSzxk4k85xYuszqv4i bi.khjXPZSMFWurqzKc50Dvx0ngcR5uBaMIw4cmo0gG5_FBRZa7E9jvBwTBOKLyWSwU71PueXQJC IE_7xDoiwNN4S1UeeeXl_j11ekPFne69iukwuP0QteThd0eobqLk6gV1xLlmLhv5J3bgfmtrfr0V Q8RB_9h29HH8oc1TgPj7FbESN3vtPQRXHQFNi5Lx5SX.ueyJLZhqGZ.zJ52vEP8pwLE8rUiKughR YelWe74N9IedlhMjWxt1t7gqGd8NUT7vtglCIRUIxqs0Fsjz65CSe9zcfmmdiMyJvMflOkCKOnDQ e1iNUJx6DoY0gjfA0qbANy09qkWHjovv2flY1_Rm4qVVkqWL1qjuBUP2gR.ia9lAfW2K7udI1Ybx NRSaZsb9.MgeM4pxDuMK3Q8qW7kofIUjJeW.XCw2w1oCtAPgeXmfDbxdWnW834jxvwa._dGKP_qi eN50xABL0i_za1dCg0.mK0NZzMjvbjdehoGCYN_Fhh5UwQ5yywCGEodRnDkIpvna.BhcMjmH3wtX fNefTvQibilCVY0dfUO5WAYXZ0iPDz49lYi4gHrfoGoGCzYoTSwYvEkyjgACiY.qeN_e1cLcW4uT wxNhANOgQzSt00jXCCpRGbW58_bnwM0ytPio9ZcAoqG1eZlg0Xa0t4ybi6sxmet0pCfqQGqANhZX PRlHq0GUwHNCFegzXgObRFiZ3y0E8TeOCL6XLbYjrw9lceMWtcfkf.7QXRgezg9NQ0q_qYkrWJug k5I3yHQmI9vgc9Te38PGbr6LMWuNTcYKqfX7iZmyDMacvVWUXY.XIDKeU.Zn7AlTpLxtsmHHeRb7 Gbw7VWz.xv_bReRo3kHcvYo6rKQJHOrssvTh01.Fxh8Hv2rjJUHqymtqUjBFXZWltwIdF7BqWBDZ ISW_7ngf6QFEN8Oeoz0cNieeD1Z5KyPmu0p4Tg5gnEfr6BSNKOAGF0qLtI0hkMZ2LIc0nmhlXOck p1oFCpTsuqaeE.27wJceETc1n8c0DhBpphgYj99MOMhjiAa7nkg9S5hVHWHD_7GmiyFpnRANdgTK W4WgWVHBtaCJudbEjpzEWzm1Dgfx.loF.Y9lTmW7ayDhTlD92.Ypv6orUEJ0_f036Ojg4t57okvR 3GM4gWq2BmooWiR1LdCRcqzLf95bpRauZyGXkOf92nBCmsSoTahB6exXINT2GGUNbyiKJt7jnTWO 5CL3JbBUE8GAYox7sp2A1upwMa0lX5x3hGyfP_MlhdDrKEHaV5wIcyW8Jla0vvVfjw6mUDTnlBel qjg_P0eQZjCvaQmUo47JfQPJVZoqlR6rhRlM4gqnDG8RzX1W6HrD9y66R9aXhgqF2jMa4S4Su5AJ x7X0wvsI0sstHTl_cklSmHEOfU7BztXQ61_PgxM6XP4JP_ET0nDS4sBg- Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Sun, 15 Mar 2020 21:23:14 +0000 Received: by smtp424.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID bada20bdc6a88f1b686cdd882abd4cac; Sun, 15 Mar 2020 21:23:11 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Subject: Re: Panic on Rpi3 at r358976 From: Mark Millard In-Reply-To: <20200315163147.GA57657@www.zefox.net> Date: Sun, 15 Mar 2020 14:23:09 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <928F18E3-C6DD-439D-9A38-20207DB655CB@yahoo.com> References: <20200315041203.GA55605@www.zefox.net> <8B479A0D-AEBB-4D83-9CE1-D68AFDA568A8@yahoo.com> <20200315163147.GA57657@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3608.60.0.2.5) X-Rspamd-Queue-Id: 48gXTw54JVz4YVm X-Spamd-Bar: + X-Spamd-Result: default: False [1.15 / 15.00]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_GOOD(-0.10)[text/plain]; MV_CASE(0.50)[]; RCVD_COUNT_TWO(0.00)[2]; NEURAL_SPAM_MEDIUM(0.77)[0.767,0]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[84.64.137.98.list.dnswl.org : 127.0.5.0]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCVD_TLS_LAST(0.00)[]; NEURAL_SPAM_LONG(0.88)[0.884,0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.00)[ip: (3.99), ipnet: 98.137.64.0/21(0.83), asn: 36647(0.66), country: US(-0.05)]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0] 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 21:23:18 -0000 On 2020-Mar-15, at 09:31, bob prohaska 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 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)