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

[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)

_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ppc
To unsubscribe, send any mail to "[email protected]"