Re: Some evidence about the PowerMac G5 multiprocessor boot hang ups with the modern VM_MAX_KERNEL_ADDRESS value
Mark Millard via freebsd-ppc <[email protected]>
| Newsgroups | gmane.os.freebsd.devel.ppc |
|---|---|
| Message-ID | <[email protected]> |
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 <[email protected]> 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) _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ppc To unsubscribe, send any mail to "[email protected]"