Re: Some evidence about the PowerMac G5 multiprocessor boot hang ups with the modern VM_MAX_KERNEL_ADDRESS value

On 2019-Feb-15, at 13:17, Justin Hibbits <[email protected]> wrote:

> On Fri, 15 Feb 2019 11:51:26 -0800
> Mark Millard via freebsd-ppc <[email protected]> wrote:
> 
>> Old: 0xe0000000013ff0??
>> New: 0xe000000087fd20??
> 
> The addresses are pretty inconsequential, since they're virtual
> addresses.  It would be nice to be able to profile how far a CPU gets
> in its launch (writing a value to a well-known address,
> 0xc000000000000010, or such, anywhere in the bottom 256 bytes of space
> really).  If you add writes to that address, we can track the progress
> at panic time.  I'd presume all APs would behave the same way, so no
> need for lock management, or isolation between them.

Thanks for the note.

Just to be sure, was the 0xc prefix a typo
(vs. 0xe as a prefix)?:

0xc000000000000010
vs.
0xe000000000000010

The hangs do not produce panics so I'd have to
induce one someplace/somehow if a panic is to be
involved.

Since boots hang only sometimes, a fixed panic point
does not seem appropriate.

Part of the issue is that this is before ddb user input
works as far as I can tell. (I do not have a serial
debug connection.) I'm unable to enter ddb via keyboard
sequences when it is hung up.

Classically I've dealt with this sort of issue by building
in a ddb script that automatically executes, dumping some
information. But that still requires inducing the ddb
session somehow. Historically I was investigating
panics.

But since CPU 0 does complete its CPU 3 sequence and starts
attempting CPU 2, I might get CPU 0 to print value(s)
for the CPU 3 case before it tries for CPU 2.

In summary:

I've been pondering what to do for earlier evidence of why:

A) CPU 0 never sees pc->pc_awake become non zero for CPU
   3 in the examples. (The 2 (void)(*rstvec) complete and
   kicking CPU 2 starts to be attempted.)

B) CPU 0 never completes the sequence of 2 (void)(*rstvec)
   for kicking CPU 2 in the examples.

(It has been some time since I've seen only one Waiting for
CPU message: there have been 2 for hangs in recent times.)

Writing to appropriate memory and reading it later should
help with that.


===
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]"