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

[Mark Millard]

On 2019-Feb-15, at 14:09, Justin Hibbits <chmeeedalf at gmail.com> wrote:

> On Fri, 15 Feb 2019 14:01:18 -0800
> Mark Millard <marklmi at yahoo.com> wrote:
> 
>> . . .
>> 
>> Just to be sure, was the 0xc prefix a typo
>> (vs. 0xe as a prefix)?:
>> 
>> 0xc000000000000010
>> vs.
>> 0xe000000000000010
> 
> No, 0xc is correct.  0xc... is the address of the DMAP, and it so
> happens that the upper bits are ignored in real mode, simply by the
> fact that they're not placed onto the address bus.  We take advantage
> of that elsewhere as well.  So writing to 0xc000....10 actually writes
> to 0x0000...10, both in real mode and translated mode.  Writing to this
> at various points when the AP is starting up, we can see just how far
> into the boot it gets.
> 
>> . . .

I got an odd result from a successful boot. But first
notes what I did to the code:

I used 0xc000000000000010 via:

+       *(unsigned long*)0xc000000000000010 = 0x10; // HACK!!!
+       powerpc_sync(); // HACK!!!

just before returning from cpudep_ap_early_bootstrap

+        *(unsigned long*)0xc000000000000010 = 0x20; // HACK!!!
+        powerpc_sync(); // HACK!!!

just before return from pmap_cpu_bootstrap

+        *(unsigned long*)0xc000000000000010 = 0x30; // HACK!!!
+        powerpc_sync(); // HACK!!!

just before return from cpudep_ap_bootstrap

+        *(unsigned long*)0xc000000000000010 = 0x40; // HACK!!!
+        powerpc_sync(); // HACK!!!

just before returning from cpudep_ap_setup

+        *(unsigned long*)0xc000000000000010 = 0x51; // HACK!!!
+        powerpc_sync(); // HACK!!!

just before the ap_letgo loop in machdep_ap_boostrap [so just
after the PCPU_SET(away,1)]

+        *(unsigned long*)0xc000000000000010 = 0x50; // HACK!!!
+        powerpc_sync(); // HACK!!!

just before sched_throw(NULL) in machdep_ap_bootstrap


For CPU 3 just after the two (void)*rstvec related
code sequences powermac_smp_start_cpu reported:

*(unsigned long*)0xc000000000000010=0xffa34878A

For CPU 2 just after the two (void)*rstvec related
code sequences powermac_smp_start_cpu reported:

*(unsigned long*)0xc000000000000010=0x51

For CPU 1 just after the two (void)*rstvec related
code sequences powermac_smp_start_cpu reported:

*(unsigned long*)0xc000000000000010=0x51

It looks to me like something is using the memory
that 0xc000000000000010 maps to.

None of them reported the 0x50 from just before
the sched_throw(NULL) .


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)