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>