PowerMac11,2 G5 (2 socket, 2 cores each) powerpc64: sometime between -r302214 and -r333594 owfdump -ap leads to 'timeout stopping cpus' and ddb> prompt
Mark Millard
marklmi at yahoo.com
Tue Apr 16 04:44:57 UTC 2019
[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)
More information about the freebsd-ppc
mailing list