From owner-freebsd-ppc@freebsd.org Tue May 7 19:04:20 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 B300E1590BB3 for ; Tue, 7 May 2019 19:04:20 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-20.consmr.mail.gq1.yahoo.com (sonic313-20.consmr.mail.gq1.yahoo.com [98.137.65.83]) (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 87631702EA for ; Tue, 7 May 2019 19:04:19 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: hJacaSEVM1lzXIZ4idHKiJ9CEfwapBSDTeyBjOzGl8b2RjAxEz0Ho06AzTyQTDa B5lPPP.MOdQKq4hcKGQQboSBJf2b6_XzULN5yyQBmBzkX1UNbxrkCksEri5FB0wnT_j9GkNbVV2u ZYdY_BnpDpTevKGrwCGR9Bg5ARkjv7OP348l1qaG9gutLUzbRVVeHOfCm40yYkIimMrimzdroLYx VH9itI5BhcQEoV0sjMkkd8raYgLBKYyAojN2v6rd5VoxDLR8xJCL_xYB8ayYKWi1QhCdwkEcScuL Mk4bWblvliwJH_0RjcEKRSt.qWBAVeNbfl8WUSagbzBFQYiSXVkEyFg5pGFgAW222PqqYkLrhCCp M3qXPe8Fem3XnweS0uhRY3c_TnoTJOvG0dHzpziVcvMgi6ZkfluAjvSf.DQq4iZ9UXmsCvuLROhw TeDZ7omCOT9KqeIwNG.omJvjXBFvbw7EAyfv6yzpUg7xGgYLHTjyqQ4hJ9AVDw.IH45CAXs6ziKa 5xT3V9BVUkNlf7G5Ny5kYijhw9EpLHW9YgL95ngVFyVRsL9sxamZNIzpsR0PDnmEVHHxi.KugYYH 7sPMQYhk72E_fWFrBnuExpNlRcKPSOUNVSZJkHfcEUHvoOrSE9fdLtUsCpfK5S7wR5QfuxkG83L4 16B1sJK_ayQlQKiLJWwEG1KIZEe6ivaH.zSYvoziZjBbZ182iiH2jZCq9jBaMaauVG1Q9zeah8tw PXi2Fht_pvN5i0Cpg2KayL9DcZRFfe2m9OZ0Qx3OkHdC5rkjQ8IYQodhpIfF4zoQAEetiyv89tNd Q.gSoA_9DyaMolPlZM9dwVmnuiQmyPw4x.t50OAi8FUToiltFwqIeHMrc7YxdRxfMec.B6IUv0y3 M8kPdl5ZSKNnGNNlxeNpm2qLjSfpwdCZPA8fBU_y9AoYnt3ZpNm9zKcCdaKq2oeoIvmFyjx_lei1 soT2ejvHA6ymm3M0laIRUjcLnZexhxGXqxWzGSTpw3cujB1Ni4e6hB6cnyqbiTIXLXRgBr.vokjV pKspMEF8.IqLLAGzylxXgHWd9OfEOtl0oszflIMWZZV_7wC2SEPr6d_TxQS4yMqq50gaYwIcj_wL qgbvnTFg0YhwwbvS4ZrXANGNj5t3HPLW5E5xZdiZSWAWe9V8zvxcr7ly4reUYpJkCfpnLigzK16s hXg-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Tue, 7 May 2019 19:04:12 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.103]) ([76.115.7.162]) by smtp422.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 7c86d56f0d82607c2075d6ae5511ef92; Tue, 07 May 2019 18:54:02 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Subject: Re: head -r347003 on 2-socket/2-cores-each G5 PowerMac11,2's: one type of boot-blocking context found From: Mark Millard In-Reply-To: <20190507130654.20a269f6@titan.knownspace> Date: Tue, 7 May 2019 11:54:01 -0700 Cc: FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: References: <20190507130654.20a269f6@titan.knownspace> To: Justin Hibbits X-Mailer: Apple Mail (2.3445.104.8) X-Rspamd-Queue-Id: 87631702EA X-Spamd-Bar: ++ X-Spamd-Result: default: False [2.39 / 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)[]; 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)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.63)[0.629,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; NEURAL_SPAM_MEDIUM(0.42)[0.418,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.44)[0.436,0]; RCVD_IN_DNSWL_NONE(0.00)[83.65.137.98.list.dnswl.org : 127.0.5.0]; IP_SCORE(1.42)[ip: (5.61), ipnet: 98.137.64.0/21(0.87), asn: 36647(0.69), country: US(-0.06)] 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: Tue, 07 May 2019 19:04:20 -0000 On 2019-May-7, at 11:06, Justin Hibbits wrote: > On Mon, 6 May 2019 22:43:36 -0700 > Mark Millard wrote: >=20 >> Every example of boot failure during cpu_mp_unleash, >> where I've had the tracking in place, has had 1 or more >> examples of srr0> handle_kernel_slb_spill before cpu_mp_unleash tries to >> start its first ap. >>=20 >> Every example of boot success, where I've had the tracking >> in place, has had no examples of srr0> (EXC_ISE) in handle_kernel_slb_spill before the >> cpu_mp_unleash finished. (Successful boots are rare >> in my current test context, so there are fewer examples >> of this.) >>=20 >> In other words: the original live-G5 information >> for the segment was still present throughout that >> time frame, thus avoiding a slbtrap for such a >> fetch address over the time frame involved. >>=20 >>=20 >>=20 >> In the the code: >>=20 >> rstvec =3D rstvec_virtbase + reset; >> printf("powermac_smp_start_cpu: about to use *rstvec=3D=3D4\n"); >> *rstvec =3D 4; >> powerpc_sync(); >> (void)(*rstvec); >> powerpc_sync(); >> DELAY(1); >> printf("powermac_smp_start_cpu: about to use *rstvec=3D=3D0\n"); >> *rstvec =3D 0; >> powerpc_sync(); >> (void)(*rstvec); >> powerpc_sync(); >> printf("powermac_smp_start_cpu: done using *rstvec=3D=3D0\n"); >>=20 >> Every boot failure has had the last line reported by >> FireWire dcons use as the first of those 3 printf's, >> for CPU 2 as the target (of 0-3). >>=20 >> The above code appears to me to execute with MSR.IR=3D1 >> on the bsp. >>=20 >> But, then, what would *rstvec do if there is no ESID=3D0 >> V=3D1 combination active for the live-G5 information at >> the time? Does that block the exception code that >> is in what would be ESID=3D0's address range, effectively >> preventing slbtrap from being invoked to enable ESID=3D0? >>=20 >> In other words: when MSR.IR=3D1, does there always >> need to be a ESID=3D0 V=3D1 entry? Is it appropriate >> to reserve one for ESID=3D0 V=3D1 (after invalidating >> any arbitrarily placed ESID=3D0 V=3D1 entry present >> before the kernel even started)? >=20 > Hi Mark, >=20 > Thanks for continuing to look into this. In this case you're > presenting, a ISE shouldn't really matter, because the SLB miss = handler > is written to run entirely from real mode to handle the miss. Can you > determine what the addresses were that faulted in the failure cases? > We shouldn't be touching anything below DMAP_BASE at this time, since > we're not yet in userspace, and all mappings should be either KVA or > DMAP. I'll try to to get examples of all of them for based on my current code code. But in a earlier message I reported several examples from simply sticking a printf in handle_kernel_sb_spill and later making it controllable to report at selective time frames. (The printf's being there lead to earlier hang-ups. I was surprised I got anything.) Remember that the number of handle_kernel_sb_spill calls for srr0 stbx r4,r9,r3 0000000000a869c0 <.memset+0x24> addi r9,r9,1 0000000000a869c4 <.memset+0x28> bdnz 0000000000a869bc <.memset+0x20> The above was from the unconditional printf addition and, as I remember, repeated for: #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; (Note the (n_slbs-1)/2 that I was experimenting with at the time.) The below was from instead enabling later: enable_handle_kernel_slb_spill_reporting=3D 1; dpcpu_init(dpcpu, curcpu); got (eliminating an unrelated line that had a truncated address showing): KDB: debugger backends: ddb KDB: current backend: ddb handle_kernel_slb_spill: type=3D0x380 dar=3D0x22ef8 srr0=3D0xa86690 handle_kernel_slb_spill: type=3D0x480 dar=3D0x22ef8 srr0=3D0xa86690 Both seemed to involve the stdu instruction in: 0000000000a8668c <.memcpy+0x140> ldu r0,-8(r9) 0000000000a86690 <.memcpy+0x144> stdu r0,-8(r11) 0000000000a86694 <.memcpy+0x148> bdnz 0000000000a8668c = <.memcpy+0x140> =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)