Date: Fri, 15 Feb 2019 14:01:18 -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: <6445CE54-26AA-4E21-B17E-921D72D4081A@yahoo.com> In-Reply-To: <20190215151710.35545a26@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>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2019-Feb-15, at 13:17, Justin Hibbits <chmeeedalf@gmail.com> wrote: > On Fri, 15 Feb 2019 11:51:26 -0800 > Mark Millard via freebsd-ppc <freebsd-ppc@freebsd.org> 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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6445CE54-26AA-4E21-B17E-921D72D4081A>