Date: Fri, 15 Feb 2019 18:04:21 -0600 From: Justin Hibbits <chmeeedalf@gmail.com> To: Mark Millard <marklmi@yahoo.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: <20190215180421.61afcae3@ralga.knownspace> In-Reply-To: <744610C7-90EB-42A0-8B08-AFA0F12E5994@yahoo.com> 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> <744610C7-90EB-42A0-8B08-AFA0F12E5994@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 15 Feb 2019 15:26:09 -0800 Mark Millard <marklmi@yahoo.com> wrote: > 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) > Interesting. That value looks like it could be an OpenFirmware phandle. PowerISA does state that the first 256 bytes of memory is free for the OS (or firmware) to use as it sees fit, and we already know address 0x80 is special for OF. Maybe pick another address if you wish to continue this experiment. Can you write at the beginning of machdep_ap_bootstrap() some value, just before the PCPU_SET()? And then right after the sync? - Justin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190215180421.61afcae3>