Skip site navigation (1)Skip section navigation (2) 
Date:      Fri, 3 May 2019 23:52:42 -0700
From:      Mark Millard <marklmi@yahoo.com>
To:        Justin Hibbits <chmeeedalf@gmail.com>, FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>
Subject:   Re: The first 2 handle_kernel_slb_spill calls on the 2-socket/2-cores-each G5 example context: as expected? (short)
Message-ID:  <2388C664-2D47-4851-95AF-A125CE48C282@yahoo.com>
In-Reply-To: <9D9A51A9-C8A6-475F-B241-0A3C3546D3D6@yahoo.com>
References:  <9D9A51A9-C8A6-475F-B241-0A3C3546D3D6.ref@yahoo.com> <9D9A51A9-C8A6-475F-B241-0A3C3546D3D6@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help 
[A correction --and interesting information from a somewhat later
time frame.]

On 2019-May-3, at 20:22, Mark Millard <marklmi at yahoo.com> wrote:

> [This is from the -r347003 experiment context, not my
> normal environment.]
>=20
> I stuck a printf in handle_kernel_slb_spill, reporting the type,
> dar, and srr0 values. The resultant build does not get far
> booting but does report the first 2 calls. Typed from a screen
> picture:
>=20
> KDB: debugger backends: ddb
> KDB: current backend: ddb
> handle_kernel_slb_spill: type=3D0x380 dar=3D0x3d99348 srr0=3D0xa869bc
> handle_kernel_slb_spill: type=3D0x380 dar=3D0x10000000 srr0=3D0xa869bc
>=20
> That is as far as it gets, as far as output goes, with that
> unconditional printf in place.
>=20
> (I was not sure I'd get anything from this experiment.)
>=20
> This suggests that the slb is partially(?) populated in the
> hardware before the (adjusted) loop that I've been testing with
> tries to establish coverage of part of the KVA space. The two
> examples reported are from neither the Direct-Map space nor the
> Kernel-Virtual-Address space.
>=20
> Are these expected? Is their presence handled?
>=20

I made the printf in handle_kernel_slb_spill conditional
on a global so I could control when it would try to
print.

I learned that I guessed the ordering wrong on the initial
report:

QUOTE
        #ifdef __powerpc64__
        i =3D 0;
        for (va =3D virtual_avail; va < virtual_end && i<(n_slbs-1)/2; =
va +=3D SEGMENT_LENGTH, i++)
                moea64_bootstrap_slb_prefault(va, 0);
        #endif
enable_handle_kernel_slb_spill_reporting=3D 1;
END QUOTE

gets the lines I originally showed:

handle_kernel_slb_spill: type=3D0x380 dar=3D0x3d99348 srr0=3D0xa869bc
handle_kernel_slb_spill: type=3D0x380 dar=3D0x10000000 srr0=3D0xa869bc

So these were after then loop, not before.

Note: So far those messages always have displayed and
then things were hung-up for this enable placement.


I then commented that enable out and added a
printf:

        pa =3D moea64_bootstrap_alloc(kstack_pages * PAGE_SIZE, =
PAGE_SIZE);
        va =3D virtual_avail + KSTACK_GUARD_PAGES * PAGE_SIZE;
        virtual_avail =3D va + kstack_pages * PAGE_SIZE;
        CTR2(KTR_PMAP, "moea64_bootstrap: kstack0 at %#x (%#x)", pa, =
va);
printf("moea64_bootstrap: kstack0 at %#x (%#x)\n", pa, va);

and also set up an enable just before dpcpu_init's=20
all:

enable_handle_kernel_slb_spill_reporting=3D 1;
        dpcpu_init(dpcpu, curcpu);

The result, when it did not boot, was as below,
again showing a couple of handle_kernel_slb_spill
lines for a not very large addresses and no more
lines after that:

KDB: debugger backends: ddb
KDB: current backend: ddb
moea64_bootstrap: kstack0 at 0x3000 (0x1000)
handle_kernel_slb_spill: type=3D0x380 dar=3D0x22ef8 srr0=3D0xa86690
handle_kernel_slb_spill: type=3D0x480 dar=3D0x22ef8 srr0=3D0xa86690

It is the same addresses but two distinct types. It
also would seem to be the same segment as for:

handle_kernel_slb_spill: type=3D0x380 dar=3D0x3d99348 srr0=3D0xa869bc
(from the earlier placement)


By contrast, interestingly, it did sometimes boot for
this later enable placement, and, when it did boot,
there were no handle_kernel_slb_spill lines output:

KDB: debugger backends: ddb
KDB: current backend: ddb
moea64_bootstrap: kstack0 at 0x3000 (0x1000)
---<<BOOT>>---

(and so on.)


This means that the type=3D0x?80 dar=3D0x22ef8 srr0=3D0xa86690
slb-misses are intermittent for this testing context.


Of course, with more testing I might see more variability.


=3D=3D=3D
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?2388C664-2D47-4851-95AF-A125CE48C282>