The first 2 handle_kernel_slb_spill calls on the 2-socket/2-cores-each G5 example context: as expected? (short)
Mark Millard via freebsd-ppc <[email protected]>
| Newsgroups | gmane.os.freebsd.devel.ppc |
|---|---|
| Message-ID | <[email protected]> |
[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) _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ppc To unsubscribe, send any mail to "[email protected]"