Date: Mon, 15 Apr 2019 21:44:44 -0700 From: Mark Millard <marklmi@yahoo.com> To: FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>, Justin Hibbits <chmeeedalf@gmail.com> Subject: Re: PowerMac11,2 G5 (2 socket, 2 cores each) powerpc64: sometime between -r302214 and -r333594 owfdump -ap leads to 'timeout stopping cpus' and ddb> prompt Message-ID: <A4172282-514E-4710-963A-F5932A390D33@yahoo.com> In-Reply-To: <C328187B-03F0-4621-8097-D4D546B31F9E@yahoo.com> References: <C328187B-03F0-4621-8097-D4D546B31F9E@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[I have a hypothesis for which change made the difference.] On 2019-Apr-9, at 19:10, Mark Millard <marklmi at yahoo.com> wrote: > [32-bit powerpc FreeBSD booting the same machine > does not have the problem, just powerpc64 FreeBSD. > I've been using -ap with ofwdump but it might not > be essential to the observed problem.] > > In trying to track down a problem, where I wanted to use > ofwdump -ap information, I ended up finding and checking > old boot media that happen to be around that target > powerpc64. > > The oldest failing: -r333594 (an 12.x-CURRENT time frame) > The newest working: -r302214 (an 11.x-CURRENT time frame) > (No versions around between those.) > > (As almost always, my powerpc64 builds are experiments > targeted via toolchains more modern than gcc 4.2.1 and the > like.) > > Those listed above long predate any useful usefdt > boots/operations in my context. The 2 powerpc64 builds > before -r302214 worked. > > (The original problem that started this is that usefdt skips > some ofw nodes. Then I found that not having usefdt mode > lead to crashes for ofwdump -ap . So I went looking at > the few historical builds that I found.) > > Modern powerpc64/head FreeBSD without use of usefdt mode fails > somewhat differently: scrolling console messages going by too > fast for me to read after starting ofwdump -ap. (It might be > back-traces.) No ability to get to the ddb> prompt and no > access via the network. But modern FreeBSD has various > blocking issues before one can even get this far. [The note about scrolling console messages was tied to an automatic bt that got another trap that caused another bt --and so on. I still had code for looking at early boot time frames enabled (covering before keyboard input works).] In observing a crash it appears to me from some register content that openfirmware_core had possibly called ofwcall and then an unexpected trap happened, which leads back to stop_cpus_hard via kdb_trap via trap_fatal. That stop_cpus_hard is what reported the "timeout stopping cpus" from what I can tell. (Trying to stop several already stopped cpus?) [The crash also happens on the PowerMac7,2 when used via powerpc64 FreeBSD (but not 32-bit FreeBSD).] Well, one possibility for new traps during some ofwcall use might be: Revision 330610 - (view) (download) (annotate) - [select for diffs] Modified Wed Mar 7 17:08:07 2018 UTC (13 months, 1 week ago) by nwhitehorn File length: 7642 byte(s) Diff to previous 328269 Move the powerpc64 direct map base address from zero to high memory. This accomplishes a few things: - Makes NULL an invalid address in the kernel, which is useful for catching bugs. . . . It is from the time frame between the two examples (failing vs. working). === 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?A4172282-514E-4710-963A-F5932A390D33>