Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 3 May 2019 20:22:05 -0700
From:      Mark Millard <marklmi@yahoo.com>
To:        Justin Hibbits <chmeeedalf@gmail.com>, FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>
Subject:   The first 2 handle_kernel_slb_spill calls on the 2-socket/2-cores-each G5 example context: as expected? (short)
Message-ID:  <9D9A51A9-C8A6-475F-B241-0A3C3546D3D6@yahoo.com>
References:  <9D9A51A9-C8A6-475F-B241-0A3C3546D3D6.ref@yahoo.com>

next in thread | previous in thread | raw e-mail | index | archive | help
[This is from the -r347003 experiment context, not my
normal environment.]

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:

KDB: debugger backends: ddb
KDB: current backend: ddb
handle_kernel_slb_spill: type=0x380 dar=0x3d99348 srr0=0xa869bc
handle_kernel_slb_spill: type=0x380 dar=0x10000000 srr0=0xa869bc

That is as far as it gets, as far as output goes, with that
unconditional printf in place.

(I was not sure I'd get anything from this experiment.)

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.

Are these expected? Is their presence handled?

===
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?9D9A51A9-C8A6-475F-B241-0A3C3546D3D6>