From owner-freebsd-ppc@freebsd.org Sat May 4 06:52:55 2019 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AEA46158420E for ; Sat, 4 May 2019 06:52:55 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-21.consmr.mail.gq1.yahoo.com (sonic314-21.consmr.mail.gq1.yahoo.com [98.137.69.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8B7BD746A8 for ; Sat, 4 May 2019 06:52:54 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: wMQMHYAVM1mVOsbUd.dOxMWCAUaSxTj2tTIAuRkIYDmWQZ4rJ4Gu0rxy3o2xD44 3gMwMqn7S6mio11VcboT_6cSnUBbmEiRA1hLocEfXzcwXA2kjoJWDHnxEBMRLx6Rj12rGCC8sbcQ 8Z91vUNRAqA_kW0TdNi1wpvQQqNBsStcDm7LhfA3nuxC.WpDt7O0hVsifp4TURxeEjBDCUOMQzjt wO24v4P3Jc4fTRPweqkuaRgp8MvlcWPOcs3wtiG9xhI94dd6cUvHe_J9A.X.ZyxxrmQcdMZ.Jgdu pN1uUVv0jNSFJxBObJ6rUsSPL6YuFr6k3.4c5hfyYfFdjbJy6A.bwCNM7Yxgn7HuZIqZfX4lMNI8 K7xWcL6az8v3guK_aXM3WmBwDBGB.pCgiPLoC24Ig5pAYsR_0.MfD_VkCxgyEv9Oo9Ostbly2HT0 iF4AtlWEKptUdCAXEzMGlQAkGMsWnzrooX8LRFiBGH_4tK2x.6Kig8BeeOjPNOa9NrRS4898x.mh woPAlQFy9h5yrQ.OVwdYKxhSMqyV9sDbhZUO7zgjdTWsRPnX4hVvKRgoB4fo8WnRR0chKcCY4olJ xParMY7tkFOThjr.tYhPldot91p7y7Sj6f1TkfDvGeWOuYuPIPpgpvPnCXuWjLdwczu8egxA3Cmh vxZJUnrJJusk0hgjWfkf17zHJyGy9vp7NQ4y8R3kgnW7P0AT1Dgv4zRwUxj2MIm9fT8ckRj7WO7U F3g2joYtD.S9AbOWI7znz5PZkr8VVSHFDXPdl13AkZulO_3BqyItzH9MD2RLE.KI2vApSK.El1HG jOy9jQQHs2zifmj.3LNzZGZiD064hoP.MLekSAmE6c3p3eUsmjFiMMUWE8.0xZjs0Sszdh3Fyr2K VofVQdYWYQCzhOPn5Wlk3OULzK3sdmOmdFL7YVEZovAHLFZVAaLKOuI2EILqtH3mWOkfgUImxsMq as7O5HZGQr_ZaeQO2riI2CNan1R9sjGj7az6Cr9hg513fG.Xfm697.RFbkN0iA267URFxMx.sJjF q1s1CoCb0FTQOMrUmdRhO4WxQeh.aGeMLl6IWKGlkbRfBvqLtgZ3WjaIFsM1k79Hx2PRdaOvOlBy xxJMulZ7VvoSKzrbyijlpPPi6t7Sq6l9V2WDxnI0fn6STWLJXcPnfpPqW0DxQJ4PZ.a1SzGcj8FP Flw-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Sat, 4 May 2019 06:52:47 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.103]) ([76.115.7.162]) by smtp417.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 48bc74a7630012afc0739d0bbf5a0b28; Sat, 04 May 2019 06:52:42 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Subject: Re: The first 2 handle_kernel_slb_spill calls on the 2-socket/2-cores-each G5 example context: as expected? (short) Date: Fri, 3 May 2019 23:52:42 -0700 References: <9D9A51A9-C8A6-475F-B241-0A3C3546D3D6.ref@yahoo.com> <9D9A51A9-C8A6-475F-B241-0A3C3546D3D6@yahoo.com> To: Justin Hibbits , FreeBSD PowerPC ML In-Reply-To: <9D9A51A9-C8A6-475F-B241-0A3C3546D3D6@yahoo.com> Message-Id: <2388C664-2D47-4851-95AF-A125CE48C282@yahoo.com> X-Mailer: Apple Mail (2.3445.104.8) X-Rspamd-Queue-Id: 8B7BD746A8 X-Spamd-Bar: +++ X-Spamd-Result: default: False [3.53 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MX_GOOD(-0.01)[cached: mta6.am0.yahoodns.net]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; NEURAL_SPAM_SHORT(0.77)[0.772,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(1.75)[ip: (7.22), ipnet: 98.137.64.0/21(0.87), asn: 36647(0.70), country: US(-0.06)]; NEURAL_SPAM_MEDIUM(0.89)[0.891,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.63)[0.635,0]; RCVD_IN_DNSWL_NONE(0.00)[84.69.137.98.list.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 May 2019 06:52:55 -0000 [A correction --and interesting information from a somewhat later time frame.] On 2019-May-3, at 20:22, Mark Millard 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) ---<>--- (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)