Date: Tue, 7 May 2019 13:06:54 -0500 From: Justin Hibbits <chmeeedalf@gmail.com> To: Mark Millard <marklmi@yahoo.com> Cc: FreeBSD PowerPC ML <freebsd-ppc@freebsd.org> Subject: Re: head -r347003 on 2-socket/2-cores-each G5 PowerMac11,2's: one type of boot-blocking context found Message-ID: <20190507130654.20a269f6@titan.knownspace> In-Reply-To: <D2CEBBBA-40A5-4924-9817-53A8ED81011E@yahoo.com> References: <D2CEBBBA-40A5-4924-9817-53A8ED81011E@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 6 May 2019 22:43:36 -0700
Mark Millard <marklmi@yahoo.com> wrote:
> Every example of boot failure during cpu_mp_unleash,
> where I've had the tracking in place, has had 1 or more
> examples of srr0<DMAP_BASE_ADDRESS (EXC_ISE) in
> handle_kernel_slb_spill before cpu_mp_unleash tries to
> start its first ap.
>
> Every example of boot success, where I've had the tracking
> in place, has had no examples of srr0<DMAP_BASE_ADDRESS
> (EXC_ISE) in handle_kernel_slb_spill before the
> cpu_mp_unleash finished. (Successful boots are rare
> in my current test context, so there are fewer examples
> of this.)
>
> In other words: the original live-G5 information
> for the segment was still present throughout that
> time frame, thus avoiding a slbtrap for such a
> fetch address over the time frame involved.
>
>
>
> In the the code:
>
> rstvec = rstvec_virtbase + reset;
> printf("powermac_smp_start_cpu: about to use *rstvec==4\n");
> *rstvec = 4;
> powerpc_sync();
> (void)(*rstvec);
> powerpc_sync();
> DELAY(1);
> printf("powermac_smp_start_cpu: about to use *rstvec==0\n");
> *rstvec = 0;
> powerpc_sync();
> (void)(*rstvec);
> powerpc_sync();
> printf("powermac_smp_start_cpu: done using *rstvec==0\n");
>
> Every boot failure has had the last line reported by
> FireWire dcons use as the first of those 3 printf's,
> for CPU 2 as the target (of 0-3).
>
> The above code appears to me to execute with MSR.IR=1
> on the bsp.
>
> But, then, what would *rstvec do if there is no ESID=0
> V=1 combination active for the live-G5 information at
> the time? Does that block the exception code that
> is in what would be ESID=0's address range, effectively
> preventing slbtrap from being invoked to enable ESID=0?
>
> In other words: when MSR.IR=1, does there always
> need to be a ESID=0 V=1 entry? Is it appropriate
> to reserve one for ESID=0 V=1 (after invalidating
> any arbitrarily placed ESID=0 V=1 entry present
> before the kernel even started)?
Hi Mark,
Thanks for continuing to look into this. In this case you're
presenting, a ISE shouldn't really matter, because the SLB miss handler
is written to run entirely from real mode to handle the miss. Can you
determine what the addresses were that faulted in the failure cases?
We shouldn't be touching anything below DMAP_BASE at this time, since
we're not yet in userspace, and all mappings should be either KVA or
DMAP.
- Justin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190507130654.20a269f6>