Date: Fri, 15 Feb 2019 15:26:09 -0800 From: Mark Millard <marklmi@yahoo.com> To: Justin Hibbits <chmeeedalf@gmail.com> Cc: Mark Millard via freebsd-ppc <freebsd-ppc@freebsd.org> Subject: Re: Some evidence about the PowerMac G5 multiprocessor boot hang ups with the modern VM_MAX_KERNEL_ADDRESS value Message-ID: <744610C7-90EB-42A0-8B08-AFA0F12E5994@yahoo.com> In-Reply-To: <20190215160942.1b282f71@ralga.knownspace> References: <11680D15-D43D-4115-AF4F-5F6E4E0022C9@yahoo.com> <9FBCA729-CE80-44CD-8873-431853E55231@yahoo.com> <1F3411CF-3D28-43C0-BEF1-4672B5CC1543@yahoo.com> <20190215151710.35545a26@ralga.knownspace> <6445CE54-26AA-4E21-B17E-921D72D4081A@yahoo.com> <20190215160942.1b282f71@ralga.knownspace>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?744610C7-90EB-42A0-8B08-AFA0F12E5994>