From owner-freebsd-ppc@freebsd.org Sun Apr 14 02:44:07 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 0F7571589ED8 for ; Sun, 14 Apr 2019 02:44:07 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-15.consmr.mail.bf2.yahoo.com (sonic314-15.consmr.mail.bf2.yahoo.com [74.6.132.125]) (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 B668876471 for ; Sun, 14 Apr 2019 02:44:05 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: Df8_IU4VM1lJiVWEV8HRZlUxmwI4uJAkovMvstCX8.knYTPzfYtXhafCb7MedvX uLAWI.oXQZNXoXMSJGtamvL9YdJqnpVpzFm4NKvvL0JByGeqV2ynBjxytPQIs9skIYev_l8H5vOz P8RMaf6tQMSil89KASFwTWz5MscvhQ8Y6u3cGcs80CYfFr9HkyoowyJOjI8clS21U501GQqozNwA 581bMePoz48rf2k7.Kxkt7vgJMbJvgNbjhtoAy_yO7yZvyY0CP0qIPcwtnaor0ZgNpk3igrJvhqn Y1yjv0cRus5PGxbQmldaNlS6kxhVCnndbVximSHsIjBVRlD869oHqqDbpvfRYZW0A8oM71gJ9p8h v9OTJ5tPbosBh2vJLAKyg9Ie_2aD.Bd8pCbnnbew3ifXnrNdHPre6L6UurEKN2uKGpJEk6DPZMbc JGqQPRucH2oW9d_EL.nNBHvY97W_93AzxcGT34YB5r0MOXi2OhZNzjBGusnx275u4ch9T9hd9A0H BGFU2CgYYrUKROdnueO9rEnoPYUMqaWgNQMyI3xqCt6dfW4wH9lx6hlMEHb4jYU9BEGcr5_k1GVl tE1KjEXgPzHVqZkL32PeJObn5qQ8eFhxd_lHgLclUZrMpCw6wuAiYR4EjC.6TvLLOSVMlj_OKVLC BaERoE5.1JxHH.VV_CQaraVtX.n4iy76ENfxpiwdSUo0d7D.U50v.Xtvs2BbsfHpgSJg2pT96wmA StmsD83pH8J0.iHZyHFIFztqrc4WA.w8n_wT6mlm5c9Qk5YP1EJ7LkE1Ig5T98lCHrmxP4w.XY5Y slZ4ra2H05pJbNZTuzcTu0mx4hwH7y6eG2DBEizOmpzPvAk1N9vHB9UvGLe916ovxeM6lmlLZqUJ .EiOKEcRNMcqnWgq8Xuhj86h0cRamA.YB2oQQKkMM80dfDNZsJLX0lxKLT6zbDT72HFCHK8as_vt D.3KMpwOwEpjSpv8EcxpLqvsxF3Xa4yVYlLvuNX2unPgPjMBUENsxWS2ZYlR.MZaYCCfdgxJDyei XGK682XgHgoK.JMCSEFkt_eBR1whTACSsmqlT32VN71cbvTpwXCP0DrsIc3P1JLlWpCP8qk0MAHX GuwDc9ZmW8w-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.bf2.yahoo.com with HTTP; Sun, 14 Apr 2019 02:44:04 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.103]) ([76.115.7.162]) by smtp401.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 7aaece546f95b04bb9e9aa8d7632e71a; Sun, 14 Apr 2019 02:44:02 +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: A usefdt boot-mode problem: openfirmware->fdt translation use vs. some existing powerpc64 or powerpc FreeBSD code, interrupt-parent examples shown Message-Id: <1E438A62-1B2F-4A1D-9537-B1135CE1C89D@yahoo.com> Date: Sat, 13 Apr 2019 19:44:00 -0700 To: FreeBSD PowerPC ML , Justin Hibbits X-Mailer: Apple Mail (2.3445.104.8) X-Rspamd-Queue-Id: B668876471 X-Spamd-Bar: + X-Spamd-Result: default: False [1.97 / 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]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; 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:26101, ipnet:74.6.128.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)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(0.80)[0.805,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(1.37)[ip: (4.02), ipnet: 74.6.128.0/21(1.59), asn: 26101(1.28), country: US(-0.06)]; NEURAL_SPAM_MEDIUM(0.10)[0.103,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.21)[0.206,0]; RCVD_IN_DNSWL_NONE(0.00)[125.132.6.74.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: Sun, 14 Apr 2019 02:44:07 -0000 I'm going to use interrupt-parent as an example of the type of issue. In the below ofwdump -ap diff extractions: - is from without usefdt mode + is from with usefdt mode - Node 0xff963f60: interrupt-controller + Node 0x2767c: interrupt-controller + phandle: + ff 96 3f 60=20 Note that the Node id changes but a phandle is added hiolding the Node id that openfirmware originally had. Picking an example where interrupt-parent is in use: - Node 0xff964428: extint-gpio1 + Node 0x27800: extint-gpio1 + phandle: + ff 96 44 28=20 . . . interrupt-parent: ff 96 3f 60=20 . . . (openfirmware and fdt are no different for the value contained in the interrupt-parent property: it is the openfirmware node id, not the FDT one.) So, for fdt use, comparison to the phandle property value is is how to find/match this interrupt-controller via a interrupt-parent. Direct use of 0xff963f60 as a node id is inappropriate for usefdt mode. The above is very general and I did not try to match the specific nodes to ones the code below would be using, beyond initially sticking to interrupt-parent types of references. I find there is example code around that makes no prevision for finding the interrupt-parent via a phandle comparison. An example is in unin_chip_add_intr : if (OF_getprop(devnode, "interrupt-parent", &iparent, = sizeof(iparent)) <=3D 0) panic("Interrupt but no interrupt parent!\n"); if (OF_searchprop(iparent, "#interrupt-cells", &icells, = sizeof(icells)) <=3D 0) icells =3D 1; For usefdt mode iparent's value is an openfirmware node id, not a fdt = one. It is the phandle property value that would match. Another is in unin_chip_attach: if (OF_getprop(child, "interrupt-parent", = &iparent, sizeof(iparent)) <=3D 0) { . . . } /* Add an interrupt number 0 to the parent. */ irq =3D MAP_IRQ(iparent, 0); (It appears MAP_IRQ uses powerpc_get_irq and I do not see a stage that can involve the phandle property for matching.) Another may be macgpio_attach: OF_searchencprop(child, "interrupt-parent", = &iparent, sizeof(iparent)); resource_list_add(&dinfo->mdi_resources, = SYS_RES_IRQ, 0, MAP_IRQ(iparent, irq[0]), MAP_IRQ(iparent, irq[0]), 1); Other's besides interrupt-parent . . . There are some gpio-parent properties but I did not find code using them. (I may have just missed such.) I quit looking for code use but did find more types of references in the fdt itself . . . l2-cache in, say, a PowerPC,G4 for usefdt mode is another type of example. platform-enableclock and platform-disableclock seem to be be examples (references back to uni-n in what I looked at, but having the openfirmwire node id, not the fdt one). I may not have found all the example types of "needs phandle property value comparisons instead of direct node id use for usefdt mode". This is all from a 2-socket/1-core-each G4 PowerMac3,6 example. [Even any G5 example would be via 32-bit pweorpc FreeBSD. This is because (for a long time now) use of ofwdump -ap crashes powerpc64 PowerMac's. But I've not gone through a G5 example (yet?).] =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-ppc@freebsd.org Sun Apr 14 06:21:25 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 5386A1565D9C for ; Sun, 14 Apr 2019 06:21:25 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-22.consmr.mail.gq1.yahoo.com (sonic309-22.consmr.mail.gq1.yahoo.com [98.137.65.148]) (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 3547483A3D for ; Sun, 14 Apr 2019 06:21:23 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: ZXUouAgVM1k3nG4_u1S_hE_zNrkn7jXPHjb9LYVL5y52KgOvayjTg8Z7txVFycD PzfoUrcJIU_3IfdVIhLkWbdGjFoJQ0jjigJygNHusczThPtdZFu1Pk2mirusxCSVi7oYfKa3POG4 eKMDpb_62IANloUnL_oVP_GHXDSd_wFFiDyjOHkvxGP028YlAGCGgMeVGg83erZuhfbrgUTmP2UY WGt7wtrvMKzNMss06gfR7i5p8reymIkH5LSZEayFa677HxmsGZwZ6SNgXMCUM1mKmhd83qvGtGUI XGM3Lp4Eqi61xwQoUoXOrqE6kxa8nWHe3HPW8VJCf6D2LqSydehTRm9SNMQzIEPCjdPClGnUffUE sFcxkqV1cdlbPI6FRjsRs0EPoLydr0uSPG.VUw1_d6572dtYTSo8hC9tardqIL1HFXBhQkrPdDuc kwt0UTsgwX5XKxAnEFKHzF4DV7kotLocgdn23HqKMk54EFwT1zpD0Xrxel_.rhgWZmXfBESlgtyw xYIHLuKDNsk1dZUj3qYAcSYsTAGFRXEnzWiJ2txQRDWBvIvyrNK2jg2Ked81t28fnwDuUcwDWv4Y YWXfEsKGFSPdmpuftLSzGiWqEMANAhFAFgA.k22YklkRefYTsjUAH_X2xDEaoZ8ZtOR2GR7tw_Mb B.MQbwEc40l6EfQY8yWnuhHE.Re.UDFzlYPCtxMIzvcg8qvYIvn59BrEl.udENcj7VGE7Q4SHCLp rpdT9jBoPb0BBbC3g0svIsDrl7z3rDZEEGnUxWsMy18rSx2sNrC_L369nvAcJGliUh57_55I4Dxf 5QtoiKiBU4cv80PeRFUShOKxOMimq2NNyyjUspG8kgjWUUNXwJqDis2T9EYBNYdRgCQbm4VDZ44C phpM_OowahydwLbe6lt9AlRJ4rzAQSQCgC_odO7u4YMcyzn3ZAlFiDJrXeo.9JcXplz33XaHYIdu dpr6YL1zkx.YQE0cVJT03zRPnSkGvmCsZaSB3Y59jqyEO80vzz2fvmroEPcCMv69of1X9dUkrIJv oaGbNgXYYEwZWmwF6t0EJaDlHDZCs.ORwk2iBBoUpnF5uPEtR_kyGlyPiuhkPunjp1U29.RVZws. C8bRuhg-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Sun, 14 Apr 2019 06:21:16 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.103]) ([76.115.7.162]) by smtp403.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 2d1b661596931a79cb17ec008e865545; Sun, 14 Apr 2019 06:21:14 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Subject: Re: A usefdt boot-mode problem: openfirmware->fdt translation use vs. some existing powerpc64 or powerpc FreeBSD code, interrupt-parent examples shown From: Mark Millard In-Reply-To: <1E438A62-1B2F-4A1D-9537-B1135CE1C89D@yahoo.com> Date: Sat, 13 Apr 2019 23:21:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1E438A62-1B2F-4A1D-9537-B1135CE1C89D@yahoo.com> To: FreeBSD PowerPC ML , Justin Hibbits X-Mailer: Apple Mail (2.3445.104.8) X-Rspamd-Queue-Id: 3547483A3D X-Spamd-Bar: / X-Spamd-Result: default: False [-0.14 / 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)[]; MX_GOOD(-0.01)[cached: mta6.am0.yahoodns.net]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; 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)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.48)[-0.484,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(0.55)[0.553,0]; NEURAL_HAM_LONG(-0.60)[-0.597,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.90)[ip: (2.85), ipnet: 98.137.64.0/21(0.94), asn: 36647(0.75), country: US(-0.06)]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[148.65.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: Sun, 14 Apr 2019 06:21:25 -0000 [I added some debug output that shows odd mixes of openfirmware vs. fdt node ids. This notes an example of what it shows.] On 2019-Apr-13, at 19:44, Mark Millard wrote: > I'm going to use interrupt-parent as an example of the type of issue. >=20 > In the below ofwdump -ap diff extractions: >=20 > - is from without usefdt mode > + is from with usefdt mode >=20 > - Node 0xff963f60: interrupt-controller > + Node 0x2767c: interrupt-controller > + phandle: > + ff 96 3f 60=20 >=20 > Note that the Node id changes but a phandle is added hiolding the > Node id that openfirmware originally had. >=20 > Picking an example where interrupt-parent is in use: >=20 >=20 > - Node 0xff964428: extint-gpio1 > + Node 0x27800: extint-gpio1 > + phandle: > + ff 96 44 28=20 > . . . > interrupt-parent: > ff 96 3f 60=20 > . . . >=20 > (openfirmware and fdt are no different for the value > contained in the interrupt-parent property: it is the > openfirmware node id, not the FDT one.) >=20 > So, for fdt use, comparison to the phandle property value is > is how to find/match this interrupt-controller via a > interrupt-parent. Direct use of 0xff963f60 as a node id > is inappropriate for usefdt mode. >=20 > The above is very general and I did not try to match the > specific nodes to ones the code below would be using, beyond > initially sticking to interrupt-parent types of references. >=20 > I find there is example code around that makes no prevision > for finding the interrupt-parent via a phandle comparison. >=20 > An example is in unin_chip_add_intr : >=20 > if (OF_getprop(devnode, "interrupt-parent", &iparent, = sizeof(iparent)) > <=3D 0) > panic("Interrupt but no interrupt parent!\n"); >=20 > if (OF_searchprop(iparent, "#interrupt-cells", &icells, = sizeof(icells)) > <=3D 0) > icells =3D 1; >=20 > For usefdt mode iparent's value is an openfirmware node id, not a fdt = one. > It is the phandle property value that would match. >=20 > Another is in unin_chip_attach: >=20 > if (OF_getprop(child, "interrupt-parent", = &iparent, > sizeof(iparent)) <=3D 0) { > . . . > } > /* Add an interrupt number 0 to the parent. */ > irq =3D MAP_IRQ(iparent, 0); >=20 > (It appears MAP_IRQ uses powerpc_get_irq and I do not see a stage > that can involve the phandle property for matching.) >=20 > Another may be macgpio_attach: >=20 > OF_searchencprop(child, "interrupt-parent", = &iparent, > sizeof(iparent)); > resource_list_add(&dinfo->mdi_resources, = SYS_RES_IRQ, > 0, MAP_IRQ(iparent, irq[0]), > MAP_IRQ(iparent, irq[0]), 1); >=20 > Other's besides interrupt-parent . . . >=20 > There are some gpio-parent properties but I did not find code using > them. (I may have just missed such.) I quit looking for code use > but did find more types of references in the fdt itself . . . >=20 > l2-cache in, say, a PowerPC,G4 for usefdt mode is another type of > example. >=20 > platform-enableclock and platform-disableclock seem to be be > examples (references back to uni-n in what I looked at, but > having the openfirmwire node id, not the fdt one). >=20 > I may not have found all the example types of "needs phandle property > value comparisons instead of direct node id use for usefdt mode". >=20 > This is all from a 2-socket/1-core-each G4 PowerMac3,6 example. >=20 > [Even any G5 example would be via 32-bit pweorpc FreeBSD. This is > because (for a long time now) use of ofwdump -ap crashes powerpc64 > PowerMac's. But I've not gone through a G5 example (yet?).] In powerpc_register_pic I added the printf shown below: powerpc_register_pic(device_t dev, uint32_t node, u_int irqs, u_int = ipis, u_int atpic) . . . for (idx =3D 0; idx < npics; idx++) { p =3D &piclist[idx]; printf("idx,npics: p->node, node, p->dev, dev: %u,%u: = %x, %x, %x, %x\n",idx,npics,p->node,node,p->dev,dev); if (p->node !=3D node) continue; if (node !=3D 0 || p->dev =3D=3D dev) break; } p =3D &piclist[idx]; p->dev =3D dev; p->node =3D node; p->irqs =3D irqs; p->ipis =3D ipis; if (idx =3D=3D npics) { #ifdef DEV_ISA p->base =3D (atpic) ? 0 : nirqs; #else p->base =3D nirqs; #endif irq =3D p->base + irqs + ipis; nirqs =3D MAX(nirqs, irq); npics++; } It shows for usefdt mode booting of a 2-socket/1-core-each G5 = PowerMac11,2: idx,npics: p->node, node, p->dev, dev: 0,1: ff981488, 4e88, 0, 1e95600 So piclist[0].node has a value for/from openfirmware instead of fdt. But the caller supplied a fdt node value, not an openfirmware one. The loop will not match the two, even if the fdt node has a phandle property that lists the 0xff981488 value. The later code would then add a separate entry in piclist with the fdt node id and increment npics. Looks to me like the intent for usefdt mode was likely to not have any openfirmware id value in any piclist[?].node field. (True?) This sort of thing appears to be involved in why usefdt mode crashes on the example 2-socket/1-core-each G5 PowerMac7,2 . The code directly putting the openfirmware value (that it was given) into the piclist is: powerpc_get_irq(uint32_t node, u_int pin) . . . piclist[idx].dev =3D NULL; piclist[idx].node =3D node; piclist[idx].irqs =3D 124; piclist[idx].ipis =3D 4; piclist[idx].base =3D nirqs; nirqs +=3D (1 << 25); npics++; . . . This goes back to MAP_IRQ use with openfirmware node id values. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-ppc@freebsd.org Sun Apr 14 10:59:17 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 BF5D9157111E for ; Sun, 14 Apr 2019 10:59:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 621908B65A for ; Sun, 14 Apr 2019 10:59:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by freefall.freebsd.org (Postfix) id 2FEA9135A2; Sun, 14 Apr 2019 10:59:17 +0000 (UTC) Delivered-To: powerpc@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [96.47.72.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id 291B3135A1 for ; Sun, 14 Apr 2019 10:59:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DF9AD8B651 for ; Sun, 14 Apr 2019 10:59:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 1BD2F16241 for ; Sun, 14 Apr 2019 10:59:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x3EAxF27044976 for ; Sun, 14 Apr 2019 10:59:15 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x3EAxFAB044975 for powerpc@FreeBSD.org; Sun, 14 Apr 2019 10:59:15 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: powerpc@FreeBSD.org Subject: [Bug 237208] java/openjdk11: port to powerpc64 Date: Sun, 14 Apr 2019 10:59:16 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: pkubaj@anongoth.pl X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: java@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-Rspamd-Queue-Id: 621908B65A X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.98 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.985,0]; ASN(0.00)[asn:11403, ipnet:2610:1c1:1::/48, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,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: Sun, 14 Apr 2019 10:59:18 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D237208 --- Comment #1 from Piotr Kubaj --- Testing now. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-ppc@freebsd.org Sun Apr 14 11:21:05 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 DB0BA1571ADE for ; Sun, 14 Apr 2019 11:21:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7C2168C318 for ; Sun, 14 Apr 2019 11:21:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by freefall.freebsd.org (Postfix) id 500CE13B50; Sun, 14 Apr 2019 11:21:04 +0000 (UTC) Delivered-To: powerpc@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [96.47.72.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id 4D20A13B4F for ; Sun, 14 Apr 2019 11:21:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EC25B8C313 for ; Sun, 14 Apr 2019 11:21:03 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 2ACC31654D for ; Sun, 14 Apr 2019 11:21:03 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x3EBL3UR093576 for ; Sun, 14 Apr 2019 11:21:03 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x3EBL3jK093575 for powerpc@FreeBSD.org; Sun, 14 Apr 2019 11:21:03 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: powerpc@FreeBSD.org Subject: [Bug 237208] java/openjdk11: port to powerpc64 Date: Sun, 14 Apr 2019 11:21:02 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: pkubaj@anongoth.pl X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: java@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-Rspamd-Queue-Id: 7C2168C318 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.99 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.986,0]; ASN(0.00)[asn:11403, ipnet:2610:1c1:1::/48, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,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: Sun, 14 Apr 2019 11:21:05 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D237208 --- Comment #2 from Piotr Kubaj --- When compiling the port, I get: root@talos:$/usr/ports/java/openjdk11$ make =3D=3D=3D> openjdk11-11.0.2.9.4 depends on executable: zip - found =3D=3D=3D> openjdk11-11.0.2.9.4 depends on package: autoconf>0 - found =3D=3D=3D> openjdk11-11.0.2.9.4 depends on file: /usr/local/include/cups/= cups.h - found =3D=3D=3D> openjdk11-11.0.2.9.4 depends on executable: bash - found =3D=3D=3D> openjdk11-11.0.2.9.4 depends on executable: gmake - found =3D=3D=3D> openjdk11-11.0.2.9.4 depends on package: libiconv>=3D1.14_11 -= found =3D=3D=3D> openjdk11-11.0.2.9.4 depends on package: pkgconf>=3D1.3.0_1 - = found =3D=3D=3D> openjdk11-11.0.2.9.4 depends on executable: gcc8 - found =3D=3D=3D> openjdk11-11.0.2.9.4 depends on file: /usr/local/bin/as - found =3D=3D=3D> openjdk11-11.0.2.9.4 depends on file: /usr/local/libdata/pkgconfig/x11.pc - found =3D=3D=3D> openjdk11-11.0.2.9.4 depends on file: /usr/local/libdata/pkgconfig/xext.pc - found =3D=3D=3D> openjdk11-11.0.2.9.4 depends on file: /usr/local/libdata/pkgco= nfig/xi.pc - found =3D=3D=3D> openjdk11-11.0.2.9.4 depends on file: /usr/local/libdata/pkgconfig/xrender.pc - found =3D=3D=3D> openjdk11-11.0.2.9.4 depends on file: /usr/local/libdata/pkgco= nfig/xt.pc - found =3D=3D=3D> openjdk11-11.0.2.9.4 depends on file: /usr/local/libdata/pkgconfig/xtst.pc - found =3D=3D=3D> openjdk11-11.0.2.9.4 depends on shared library: libasound.so -= found (/usr/local/lib/libasound.so) =3D=3D=3D> openjdk11-11.0.2.9.4 depends on shared library: libfontconfig.= so - found (/usr/local/lib/libfontconfig.so) =3D=3D=3D> openjdk11-11.0.2.9.4 depends on shared library: libfreetype.so= - found (/usr/local/lib/libfreetype.so) =3D=3D=3D> openjdk11-11.0.2.9.4 depends on shared library: libgif.so - fo= und (/usr/local/lib/libgif.so) =3D=3D=3D> openjdk11-11.0.2.9.4 depends on shared library: liblcms2.so - = found (/usr/local/lib/liblcms2.so) =3D=3D=3D> openjdk11-11.0.2.9.4 depends on shared library: libpng16.so - = found (/usr/local/lib/libpng16.so) =3D=3D=3D> openjdk11-11.0.2.9.4 depends on shared library: libjpeg.so - f= ound (/usr/local/lib/libjpeg.so) =3D=3D=3D> Configuring for openjdk11-11.0.2.9.4 env: ./configure: No such file or directory =3D=3D=3D> Script "configure" failed unexpectedly. Please report the problem to java@FreeBSD.org [maintainer] and attach the "/usr/local/poudriere/ports/default/java/openjdk11/work/openjdk-jdk11u-jdk-= 11.0.2-9-4/config.log" including the output of the failure of your make command. Also, it might be a good idea to provide an overview of all packages installed on your system (e.g. a /usr/local/sbin/pkg-static info -g -Ea). *** Error code 1 Stop. make: stopped in /usr/local/poudriere/ports/default/java/openjdk11 --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-ppc@freebsd.org Sun Apr 14 13:28:27 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 DB3771576204 for ; Sun, 14 Apr 2019 13:28:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7943F6AC24 for ; Sun, 14 Apr 2019 13:28:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by freefall.freebsd.org (Postfix) id 50FC916256; Sun, 14 Apr 2019 13:28:26 +0000 (UTC) Delivered-To: powerpc@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [96.47.72.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id 4DDB616255 for ; Sun, 14 Apr 2019 13:28:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 15E1E6AC21 for ; Sun, 14 Apr 2019 13:28:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 3A7E7177EE for ; Sun, 14 Apr 2019 13:28:25 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x3EDSPQ5070163 for ; Sun, 14 Apr 2019 13:28:25 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x3EDSPZI070162 for powerpc@FreeBSD.org; Sun, 14 Apr 2019 13:28:25 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: powerpc@FreeBSD.org Subject: [Bug 237208] java/openjdk11: port to powerpc64 Date: Sun, 14 Apr 2019 13:28:23 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: mikael.urankar@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: java@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: attachments.isobsolete attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-Rspamd-Queue-Id: 7943F6AC24 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.99 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.993,0]; ASN(0.00)[asn:11403, ipnet:96.47.64.0/20, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,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: Sun, 14 Apr 2019 13:28:27 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D237208 mikael.urankar@gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #203597|0 |1 is obsolete| | --- Comment #3 from mikael.urankar@gmail.com --- Created attachment 203672 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D203672&action= =3Dedit patch Can you try this patch instead? --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-ppc@freebsd.org Mon Apr 15 02:44:56 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 5689515871AC for ; Mon, 15 Apr 2019 02:44:56 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-33.consmr.mail.ne1.yahoo.com (sonic317-33.consmr.mail.ne1.yahoo.com [66.163.184.44]) (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 CB0EE8C00D for ; Mon, 15 Apr 2019 02:44:54 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 694wvtQVM1kdZ8Rj.ijMszGODVy8QI5VTkkUJPJaTcXBbAOFIAU7n2i3xIndO7x rizOigcDSoucq._0QFPMfULCBr9T89.7.r9hZbQwHbLOGHPkeUMSu4piL.UbFI8SYhAC6fZqeX21 _W_b_h5hkFshcx6NB51qP.bCfhYucsL65emkawTdq5Cxyn8O0kQPBsP7SSYWFjvRrHn_BHeimiW. 19JyW7qGuTq7yudOACFQhiNoyyKa7JUfHm59QiXu44THWQ7d60.ip1xa2K1Xwngb1.KjtSo2vfNA 6mNSxJ9QcnWUkmvcgFNPXE1eZ5h7IGYvuEv5OwqBIP5J2Ntu9GnNSjYz8W82._F6CG9NK0J_iEnc KvPQsHy4iHLX7xBvWys1RWG2aAypeUA4kPtFrpCB4CNr.aY_TnRTBHxC6QrdnJAr.xklBK6lF9Q3 .M4Pn9BAaJrld8LB2NUBEMMFZLN5dWugDrenQPS.KDkU7z5a8esyNCbq2aEAXDjlAKB.OoejRLMZ dG5wWIW3Qehp2MahkBUQNcnehFebNXHVDsEL5kDv1u2f8TbmkRpPAZsg_x._9nw5N3KE6Aoe_TuX WAbxVaUsm32gLSELHWOj0UGsPwuuZngCmXIYDMW3cNSidXu9WNsOlOaMFfYT6Z7TleMJGCIX.nlb d0ZZt289FcjMyaLsMISXmpRUjJFOKTtsOW.RqiamHplCnR8xTubkM5wL4iMe5w9hmi0eS.v4NKI1 p8xRvhmHBUbZBFrSrHhATBstgPauGHNAaIVX4vERIB_INVi2bIVyMV8O2yMfu.y9UsNjmf7f6N.X isr3fu82CJzMFT8C6rlgFc8TCB7btLmJIyvjGmRFk5tvUp7ZHW0837HOLvuOhC98GLTYoz4emBxT ZmnIXgmUvbW7FyLwZaPkqhM_Osa5xylyk6P8klMfEb7WCOdI70jLDvAUgLrUbZ.8Ki1Yp0WxFsQ2 pIhTQpFZe.QFpV2PVRuyMTiu2K0pvOZnH3z6rzyD4GoirjubCa2_wC4iPguhjWYCLPnVztKvddu1 shbdH8y2e4tTXxXj7b_95bKdLS4bA.TKmZEGT8sahMlLGQOi8vcuiyDco7WpwwI1w8NL5o.C.uga Gc5KvIQ-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.ne1.yahoo.com with HTTP; Mon, 15 Apr 2019 02:44:53 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.103]) ([76.115.7.162]) by smtp425.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID a08d72dd3d140ef59f0198471e840f82; Mon, 15 Apr 2019 02:44:50 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Subject: Re: A usefdt boot-mode problem: openfirmware->fdt translation use vs. some existing powerpc64 or powerpc FreeBSD code, interrupt-parent examples shown From: Mark Millard In-Reply-To: Date: Sun, 14 Apr 2019 19:44:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <125F273F-6F0B-49BB-87AE-8B94DE621407@yahoo.com> References: <1E438A62-1B2F-4A1D-9537-B1135CE1C89D@yahoo.com> To: FreeBSD PowerPC ML , Justin Hibbits X-Mailer: Apple Mail (2.3445.104.8) X-Rspamd-Queue-Id: CB0EE8C00D X-Spamd-Bar: ++++ X-Spamd-Result: default: False [4.17 / 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]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; 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:36646, ipnet:66.163.184.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)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(0.92)[0.921,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(2.34)[ip: (9.19), ipnet: 66.163.184.0/21(1.43), asn: 36646(1.15), country: US(-0.06)]; NEURAL_SPAM_MEDIUM(0.67)[0.666,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.75)[0.751,0]; RCVD_IN_DNSWL_NONE(0.00)[44.184.163.66.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: Mon, 15 Apr 2019 02:44:56 -0000 [I tried adjusting one thing that I'd listed and it let the PowerMac7.2 get farther into the boot sequence without messing up the PowerMac11,2 or PowerMac3,6 booting.] On 2019-Apr-13, at 23:21, Mark Millard wrote: > [I added some debug output that shows odd mixes of openfirmware > vs. fdt node ids. This notes an example of what it shows.] >=20 > On 2019-Apr-13, at 19:44, Mark Millard wrote: >=20 >> I'm going to use interrupt-parent as an example of the type of issue. >>=20 >> In the below ofwdump -ap diff extractions: >>=20 >> - is from without usefdt mode >> + is from with usefdt mode >>=20 >> - Node 0xff963f60: interrupt-controller >> + Node 0x2767c: interrupt-controller >> + phandle: >> + ff 96 3f 60=20 >>=20 >> Note that the Node id changes but a phandle is added hiolding the >> Node id that openfirmware originally had. >>=20 >> Picking an example where interrupt-parent is in use: >>=20 >>=20 >> - Node 0xff964428: extint-gpio1 >> + Node 0x27800: extint-gpio1 >> + phandle: >> + ff 96 44 28=20 >> . . . >> interrupt-parent: >> ff 96 3f 60=20 >> . . . >>=20 >> (openfirmware and fdt are no different for the value >> contained in the interrupt-parent property: it is the >> openfirmware node id, not the FDT one.) >>=20 >> So, for fdt use, comparison to the phandle property value is >> is how to find/match this interrupt-controller via a >> interrupt-parent. Direct use of 0xff963f60 as a node id >> is inappropriate for usefdt mode. >>=20 >> The above is very general and I did not try to match the >> specific nodes to ones the code below would be using, beyond >> initially sticking to interrupt-parent types of references. >>=20 >> I find there is example code around that makes no prevision >> for finding the interrupt-parent via a phandle comparison. >>=20 >> An example is in unin_chip_add_intr : >>=20 >> if (OF_getprop(devnode, "interrupt-parent", &iparent, = sizeof(iparent)) >> <=3D 0) >> panic("Interrupt but no interrupt parent!\n"); >>=20 >> if (OF_searchprop(iparent, "#interrupt-cells", &icells, = sizeof(icells)) >> <=3D 0) >> icells =3D 1; >>=20 >> For usefdt mode iparent's value is an openfirmware node id, not a fdt = one. >> It is the phandle property value that would match. >>=20 >> Another is in unin_chip_attach: >>=20 >> if (OF_getprop(child, "interrupt-parent", = &iparent, >> sizeof(iparent)) <=3D 0) { >> . . . >> } >> /* Add an interrupt number 0 to the parent. */ >> irq =3D MAP_IRQ(iparent, 0); >>=20 >> (It appears MAP_IRQ uses powerpc_get_irq and I do not see a stage >> that can involve the phandle property for matching.) >>=20 >> Another may be macgpio_attach: >>=20 >> OF_searchencprop(child, "interrupt-parent", = &iparent, >> sizeof(iparent)); >> resource_list_add(&dinfo->mdi_resources, = SYS_RES_IRQ, >> 0, MAP_IRQ(iparent, irq[0]), >> MAP_IRQ(iparent, irq[0]), 1); >>=20 >> Other's besides interrupt-parent . . . >>=20 >> There are some gpio-parent properties but I did not find code using >> them. (I may have just missed such.) I quit looking for code use >> but did find more types of references in the fdt itself . . . >>=20 >> l2-cache in, say, a PowerPC,G4 for usefdt mode is another type of >> example. >>=20 >> platform-enableclock and platform-disableclock seem to be be >> examples (references back to uni-n in what I looked at, but >> having the openfirmwire node id, not the fdt one). >>=20 >> I may not have found all the example types of "needs phandle property >> value comparisons instead of direct node id use for usefdt mode". >>=20 >> This is all from a 2-socket/1-core-each G4 PowerMac3,6 example. >>=20 >> [Even any G5 example would be via 32-bit pweorpc FreeBSD. This is >> because (for a long time now) use of ofwdump -ap crashes powerpc64 >> PowerMac's. But I've not gone through a G5 example (yet?).] >=20 > In powerpc_register_pic I added the printf shown below: >=20 > powerpc_register_pic(device_t dev, uint32_t node, u_int irqs, u_int = ipis, > u_int atpic) > . . . > for (idx =3D 0; idx < npics; idx++) { > p =3D &piclist[idx]; > printf("idx,npics: p->node, node, p->dev, dev: %u,%u: = %x, %x, %x, %x\n",idx,npics,p->node,node,p->dev,dev); > if (p->node !=3D node) > continue; > if (node !=3D 0 || p->dev =3D=3D dev) > break; > } > p =3D &piclist[idx]; > p->dev =3D dev; > p->node =3D node; > p->irqs =3D irqs; > p->ipis =3D ipis; > if (idx =3D=3D npics) { > #ifdef DEV_ISA > p->base =3D (atpic) ? 0 : nirqs; > #else > p->base =3D nirqs; > #endif > irq =3D p->base + irqs + ipis; > nirqs =3D MAX(nirqs, irq); > npics++; > } >=20 >=20 > It shows for usefdt mode booting of a 2-socket/1-core-each G5 = PowerMac11,2: >=20 > idx,npics: p->node, node, p->dev, dev: 0,1: ff981488, 4e88, 0, 1e95600 >=20 > So piclist[0].node has a value for/from openfirmware instead of fdt. > But the caller supplied a fdt node value, not an openfirmware one. >=20 > The loop will not match the two, even if the fdt node has a phandle > property that lists the 0xff981488 value. The later code would then > add a separate entry in piclist with the fdt node id and increment > npics. >=20 > Looks to me like the intent for usefdt mode was likely to not have any > openfirmware id value in any piclist[?].node field. (True?) [Note: The above guess work for piclist[?].node seems to be wrong.] > This sort of thing appears to be involved in why usefdt mode crashes > on the example 2-socket/1-core-each G5 PowerMac7,2 . >=20 > The code directly putting the openfirmware value (that it was > given) into the piclist is: >=20 > powerpc_get_irq(uint32_t node, u_int pin) > . . . > piclist[idx].dev =3D NULL; > piclist[idx].node =3D node; > piclist[idx].irqs =3D 124; > piclist[idx].ipis =3D 4; > piclist[idx].base =3D nirqs; > nirqs +=3D (1 << 25); > npics++; > . . . >=20 > This goes back to MAP_IRQ use with openfirmware node id values. I adjusted to be using the following in unin_chip_add_intr : # svnlite diff /usr/src/sys/powerpc/powermac/uninorth.c Index: /usr/src/sys/powerpc/powermac/uninorth.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/powerpc/powermac/uninorth.c (revision 345758) +++ /usr/src/sys/powerpc/powermac/uninorth.c (working copy) @@ -181,7 +181,7 @@ <=3D 0) panic("Interrupt but no interrupt parent!\n"); =20 - if (OF_searchprop(iparent, "#interrupt-cells", &icells, = sizeof(icells)) + if (OF_searchprop(OF_node_from_xref(iparent), = "#interrupt-cells", &icells, sizeof(icells)) <=3D 0) icells =3D 1; =20 This get farther into the boot sequence: subsystem a800000 boot_run_interrupt_driven_config_hooks(0)... max66900: 2 sensors = detected. max66901: 2 sensors detected. ugen1.1: at usbus1 . . . ada0 at ata2 bus 0 scbus2 target 0 lun 0 ada0: ATA8-ACS SATA 2.x device ada0: Serial Number OW140507AS1363504 ada0: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO 512bytes) ada0: 114473MB (234441648 512 byte sectors) cd0 at ata0 bus 0 scbus0 target 0 lun 0 cd0: Removable CD-ROM SCSI device cd0: Serial Number FFDP051360WL cd0: 66.700MB/s transfers (UDMA4, ATAPI 12bytes, PIO 65534bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present But boot_run_interrupt_driven_config_hooks never reports "done.". =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-ppc@freebsd.org Mon Apr 15 07:01:06 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 70A8A158AEE0 for ; Mon, 15 Apr 2019 07:01:06 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id F1A0E6C69C for ; Mon, 15 Apr 2019 07:01:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id A9DDD158AEDF; Mon, 15 Apr 2019 07:01:05 +0000 (UTC) Delivered-To: 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 972FD158AEDD for ; Mon, 15 Apr 2019 07:01:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9CF646C698 for ; Mon, 15 Apr 2019 07:01:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id B028CF1A for ; Mon, 15 Apr 2019 07:01:03 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x3F713fG087980 for ; Mon, 15 Apr 2019 07:01:03 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x3F713Hv087979 for ppc@FreeBSD.org; Mon, 15 Apr 2019 07:01:03 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: ppc@FreeBSD.org Subject: [Bug 233863] r345425 on PowerMac G5 may require kern.smp.disabled=1 and must set usefdt=1 which causes net interface reorder Date: Mon, 15 Apr 2019 07:01:01 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: marklmi26-fbsd@yahoo.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: ppc@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.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: Mon, 15 Apr 2019 07:01:06 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D233863 --- Comment #15 from Mark Millard --- Created attachment 203683 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D203683&action= =3Dedit Investigatory sys/powerpc/powermac/hrowpic.c sys/powerpc/powermac/uninorth.c sys/powerpc/powerpc/openpic.c patches Besides the other patches, adding 2 instances of using OF_xref_from_node and 1 instance of using OF_node_from_xref has finally enabled also booting the 2-socket/1-core-each G5 PowerMac7,2 in usefdt mode. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-ppc@freebsd.org Mon Apr 15 07:06:48 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 D5ACB156A0B9 for ; Mon, 15 Apr 2019 07:06:47 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-56.consmr.mail.ne1.yahoo.com (sonic307-56.consmr.mail.ne1.yahoo.com [66.163.190.31]) (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 6CCCD6C934 for ; Mon, 15 Apr 2019 07:06:46 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: lOfegvsVM1mQS_6EuLuzS57nvcghIh3C0sk8oNROQG7pO3N5pSbCsESlg4np1Ic prQEZilrKPg_wDq0phgS_ufgvZTgjp0.y6vaZSJKXlLvLUWnYZwBlF9Rh_tGqDxCn7k5_F0hhYaE iVNki7FqYF0K6uXsEY1BXVW_WJnpxjGNIoNrtcnEAVZjxT3PX5m4s5s51KA_.X.f0gv2i76YzzAQ qMn1ZzfwYevfbatnWBCs430OkyhTYG03HxH.rLu.n6V1OsttI2zr5p_qFjPUlHPVkGvfORnmq6By pkXpVG6BS.eamRijqZ9Zp2D_NNeILvhI0e9L.7Ci.jDRn9c_0MB9C9fru9GmJ3PBnEybCSESH2MS 7frSlr_Quh4qe2ROfVzLP3jFZCwJJRoYKHCijU_v94eoKRPiQJSfp6QE7AEdCub9gMDJSB32erNz WWvRM2ScUIy0DKdijQ.FwSeHgsmOr9k6aHSudQg30ckQugdRfh3dpSmj0OY1yGG4Vkj4OUb_j6Dl cHcjzh58HJ9hi98_2QME4ncO7_c9KSBfJul0uLGyG6ThwL7HBf4FL3wsO3FBdH5vEOO00d3FeTkE _BXl3Uw0IyACyIN8T4TBRZGIQ7AWEQek9zkx7i3.kpUlBCazA9IlO1svY3tuxfShkB8gCRe2W30u ix3SsKmWBs6Ko2vvJTAiOzdsiPcyYM2KT3Ya1w9fkvvJ9PiU5b8Rum_awVH6thCJUaVuWYUXR1SZ QCtgeK5_ulKxc6y8tXygT7fOrS9JzRH6rFYW7H4yFJHIXoFghiHForz5_azLXNPEnuU0iNNCijUV P6L4oYrP2i7h2Ab5RJRnIhYO801R9i8nI27pYURdE2sWNDyZBSxoCBGfvVgKwOwOU2C483ynj3wd RuJAS9dbtB1G5uAoDpk6KZva2cnK1wmUiYH95PBQuB9nbRRdP2RXYKnY4IBfn9ahUO5kfTUZRP2y UO7X8QKSQ4EQNBBJe0xuO6ChORxBHRA7IA8pQAY9mtdjNOGaXxsrHwHz7ACg_LJsBE7dUcOh7jGE 0rdlh7oHu8iC7EoGfzeDURVaeC.88o8mmefC_Oh_612NoHCF5.NFXEVg.WDW9oHkue5JYnoBx9fg fijZb Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.ne1.yahoo.com with HTTP; Mon, 15 Apr 2019 07:06:38 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.103]) ([76.115.7.162]) by smtp415.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 00472f5fffa3fea533b9a3da76e8c247; Mon, 15 Apr 2019 07:06:37 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Subject: Re: Patches to allow usefdt mode that works on a 2 socket PowerMac3, 6 example too --and makes more work on 2-socket/1-core-each PowerMac11, 2 From: Mark Millard In-Reply-To: <55E83F50-197D-43C7-B4D6-E69A5AEC2630@yahoo.com> Date: Mon, 15 Apr 2019 00:06:36 -0700 Cc: freebsd-ppc@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <1B999D64-036F-4553-B024-93D0150FD60D@yahoo.com> References: <988F644F-D5E7-4FB4-AAB3-A72E9DA88CE6@yahoo.com> <465DBF40-EEF5-4D4A-95F6-DF17EB5B130B@yahoo.com> <5aecd21e-e53c-f14c-0bdc-8732fa88fed6@blastwave.org> <55E83F50-197D-43C7-B4D6-E69A5AEC2630@yahoo.com> To: Dennis Clarke X-Mailer: Apple Mail (2.3445.104.8) X-Rspamd-Queue-Id: 6CCCD6C934 X-Spamd-Bar: / X-Spamd-Result: default: False [-0.22 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(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]; DKIM_TRACE(0.00)[yahoo.com:+]; MX_GOOD(-0.01)[cached: mta6.am0.yahoodns.net]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.30)[-0.297,0]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; 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:36646, ipnet:66.163.184.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)[]; NEURAL_HAM_MEDIUM(-0.11)[-0.109,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.28)[-0.279,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.97)[ip: (2.35), ipnet: 66.163.184.0/21(1.43), asn: 36646(1.15), country: US(-0.06)]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[31.190.163.66.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: Mon, 15 Apr 2019 07:06:48 -0000 On 2019-Apr-13, at 11:39, Mark Millard wrote: > [My adjustment to fdt_add_subnode_namelen was inept.] >=20 > On 2019-Apr-12, at 16:17, Mark Millard wrote: >=20 >> On 2019-Apr-12, at 14:20, Dennis Clarke = wrote: >>=20 >>> On 4/12/19 4:51 PM, Mark Millard wrote: >>>> On 2019-Apr-12, at 13:13, Dennis Clarke = wrote: >>>>> On 4/12/19 3:19 PM, Mark Millard via freebsd-ppc wrote: >>> . >>> . >>> . >>>>>=20 >>>>> Would you be so kind as to paste all this into : >>>>>=20 >>>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D233863 >>>>>=20 >>>>> Really I would like to run some tests and follow up in the bug = reports. >>>> Okay I'll paste them in as attachments. But be warned: >>>=20 >>> Fair warning received loud and clear :-) >>>=20 >>>> The 2 files do not deal with threads being stuck sleeping >>>> (and, so, the fans going) or other such. The stuck-sleeping >>>> problem happens for both multi-socket G5's and multi-socket >>>> G4's. (I do not have access to single-socket multi-core >>>> powerpc64 or powerpc machines to test.) >>>=20 >>> I have multiple G5 type boxen and will try them out. At least try >>> to. >>>=20 >>>> So do not expect too much from these patches: They address >>>> some necessary issues but are not sufficient for everything. >>>>=20 >>>=20 >>> Of course. No problem. >>>=20 >>>=20 >>>> These patches for the openfirmware->fdt translation are >>>> closer to being reasonable for FreeBSD official use >>>> than my highly context-specific stuck-sleeping patches for >>>> usefdt mode. >>>=20 >>> Well to be frank we know this is for mac g5 hardware and thus having >>> them working at all in any fashion is better than the current = situation. >>> Apple made a ton of them and they are dirt cheap and available as >>> opposed to the IBM Power situation which is expensive and just in >>> datacenters. >>=20 >>=20 >> I have added another attachment with patches for having hang-ups >> at AP startup happen less often. These are in AIM-specific code >> and so has less of a chance of causing other contexts problems. >> They are also powerpc64 specific. Again, the patches are >> investigatory and not in a form for direct check-in to FreeBSD. >>=20 >> This pair of patches narrows the time period over which threads >> from the stages: >>=20 >> SI_SUB_KTHREAD_INIT =3D 0xe000000, /* init process*/ >> SI_SUB_KTHREAD_PAGE =3D 0xe400000, /* pageout daemon*/ >> SI_SUB_KTHREAD_VM =3D 0xe800000, /* vm daemon*/ >> SI_SUB_KTHREAD_BUF =3D 0xea00000, /* buffer daemon*/ >> SI_SUB_KTHREAD_UPDATE =3D 0xec00000, /* update daemon*/ >> SI_SUB_KTHREAD_IDLE =3D 0xee00000, /* idle procs*/ >> #ifndef EARLY_AP_STARTUP >> SI_SUB_SMP =3D 0xf000000, /* start the APs*/ >> #endif=20 >>=20 >> can conflict with starting an AP via an slb replacement position >> picked via expressions like mftb()%n_slbs . It does this by=20 >> explicitly picking and setting up a slb slot for its use just >> before starting the AP. >>=20 >> (The AP has to be part way along before it can do its own >> automatic-random-slb-slot-replacements from what I can tell.) >>=20 >> The patches do not remove the race and still do sometimes fail to >> prevent getting a hang-up on a AP start. But it greatly decreased >> the rate of hangups in my testing. (So it is a good source of >> evidence about the original problem.) >>=20 >> If EARLY_AP_STARTUP was supported and used, the AP startup would >> not have hang-up problems from mftb()%n_slbs based slb >> replacements for other threads. >>=20 >> The patches are a hack, rather than a general/complete fix --and >> I do not expect to see them in FreeBSD. But they do help set up >> a better context for investigating other things. >=20 > The disabling of blocking duplicate paths in fdt_add_subnode_namelen > was done incorrectly. I'll replace the attachment after building > and testing. I think this is the explanation for the PowerMac11,2 > shutdown -r or -p problems. >=20 > The code should have just disabled the return, more like: >=20 > if (offset >=3D 0) > #if 0 > // Some Macintoshes have identical package-to-pathname results for > // multiple nodes of the same type and unit under the parent node. > // Avoid blocking this for fdt. > return -FDT_ERR_EXISTS; > #else > ; > #endif > else if (offset !=3D -FDT_ERR_NOTFOUND) > return offset; >=20 > Instead the messed up change did the "return offset;" and > so did not do the addition of the node, instead returning > the pre-existing one to be manipulated. I've managed to boot the 2-socket/1-core-each G5 PowerMac7,2 in usefdt mode. I've added another attachment for patching 3 more files, also shown below: Index: /usr/src/sys/powerpc/powermac/hrowpic.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/powerpc/powermac/hrowpic.c (revision 345758) +++ /usr/src/sys/powerpc/powermac/hrowpic.c (working copy) @@ -169,7 +169,7 @@ hrowpic_write_reg(sc, HPIC_ENABLE, HPIC_SECONDARY, 0); hrowpic_write_reg(sc, HPIC_CLEAR, HPIC_SECONDARY, 0xffffffff); =20 - powerpc_register_pic(dev, ofw_bus_get_node(dev), 64, 0, FALSE); + powerpc_register_pic(dev, = OF_xref_from_node(ofw_bus_get_node(dev)), 64, 0, FALSE); return (0); } =20 Index: /usr/src/sys/powerpc/powermac/uninorth.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/powerpc/powermac/uninorth.c (revision 345758) +++ /usr/src/sys/powerpc/powermac/uninorth.c (working copy) @@ -181,7 +181,7 @@ <=3D 0) panic("Interrupt but no interrupt parent!\n"); =20 - if (OF_searchprop(iparent, "#interrupt-cells", &icells, = sizeof(icells)) + if (OF_searchprop(OF_node_from_xref(iparent), = "#interrupt-cells", &icells, sizeof(icells)) <=3D 0) icells =3D 1; =20 Index: /usr/src/sys/powerpc/powerpc/openpic.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/powerpc/powerpc/openpic.c (revision 345758) +++ /usr/src/sys/powerpc/powerpc/openpic.c (working copy) @@ -37,6 +37,8 @@ #include #include =20 +#include + #include #include #include @@ -220,7 +222,7 @@ for (cpu =3D 0; cpu < sc->sc_ncpu; cpu++) openpic_write(sc, OPENPIC_PCPU_TPR(cpu), 0); =20 - powerpc_register_pic(dev, node, sc->sc_nirq, 4, FALSE); + powerpc_register_pic(dev, OF_xref_from_node(node), sc->sc_nirq, = 4, FALSE); =20 /* If this is not a cascaded PIC, it must be the root PIC */ if (sc->sc_intr =3D=3D NULL) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-ppc@freebsd.org Mon Apr 15 07:36:00 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 2E001156AA6D for ; Mon, 15 Apr 2019 07:36:00 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-20.consmr.mail.gq1.yahoo.com (sonic301-20.consmr.mail.gq1.yahoo.com [98.137.64.146]) (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 AEFD56D61D for ; Mon, 15 Apr 2019 07:35:58 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: bCsaal4VM1kYRTD4H5WvzS5E.9.te3RoQaMJ_bO5PlUavnXvxK3R4y26YAOB1oK RgqgQKpZOrUx3iriKn6rqkyj8kmHmtj2eC1lC9E8y9a9TtdCgR76CqSqMTkSOOGEGSnA5wYxGjvu TKLjUzDh6FQS8L1orOhDKyrFCMPv77Rcts5cnPsvSW5Iyzjm6HBoGqWwYm_bdP3TxNsumryYKq8S wl_Q9UDNZZ.kbAU_CUal42rtFZJhlb0qND4Fk4F4Q0UBckfiqRxDYsT17_vi82LpJvZykxofsyH1 OcInOceetsSvYG4VOvyY2ppDUO0geyJCq4Nqz0kWbMWtF6tXA7MM3TTI5BOAu0AzjccjP3Du2tLO muCE7aulr0DPF6SEm6CJbash5mUVL1u2mMWGXMfTsfVRx45eQxVrQdhtH88m4.1EdmKpt.7SVzl8 6kVfuq2loHWvI5Mj2EUpj2ZZm8XXDSZzu4Mk8rtOrAzcHq_mYw9ucno4r_P3BdV1egeB4b2z1eWS HP8gHUWnzz5_rmK_8Kt1WrlRusex2mC0SkavXJdoYgyxeS3zJ2TVbzwZCVsBHi5fJpQc4zfMpbBO PRfcq30i7zJdNUR59McTzX8A2mzbg4p6QGdW_2jo1iL6rVxcBT8gDVvD9GtIP6jOQMUbezJ4LKM7 Gt65f5fEhQ8z8QVtcTmknx.RuX10jZIbODPlS8L3EwyVV_VqI0PaEkdFGSelIjJDVwk96fj1XwCY v_iwfg74_H9_bmu4UKoBbDiGZxCyov03jZy.hwWde.iJR1CG6uAKtHUQLH9fzSOK1tMulhoW3zdY XcH8eJHo_Lzr5OFNvfe0kMs6c2Q_X_45C4WEUcELcAcKLmUPr9AYym_gJc4WrtcLDLGDOJhG5Mnc bVpjwMp2CsgVtaEJ.AN3smio3jp_qfSTpOLB3GyGD6lsf6n2J8VH8vwOIxV8GLjo9qzkM3QCeSi_ qehaY3fDNEn5C.MDAi07164H470SToZ8_L6zo.p0CvX3V2XtAVeq46c7SPwYdqUFD2G4jd87.fDP sBczs4EuxectSDBg7A3Vt84JWyeiRTYTw.HfwRNTP_qUR_UjxiK5KwxMhUBmx2RGjsEae3_BOlyT zL8PCDQ-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Mon, 15 Apr 2019 07:35:56 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.103]) ([76.115.7.162]) by smtp425.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 4196db8a743589a4e3c91a7d230247f0; Mon, 15 Apr 2019 07:35:53 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Subject: Re: A usefdt boot-mode problem: openfirmware->fdt translation use vs. some existing powerpc64 or powerpc FreeBSD code, interrupt-parent examples shown From: Mark Millard In-Reply-To: <125F273F-6F0B-49BB-87AE-8B94DE621407@yahoo.com> Date: Mon, 15 Apr 2019 00:35:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <418AA654-3739-4567-9D73-C849B7904BE2@yahoo.com> References: <1E438A62-1B2F-4A1D-9537-B1135CE1C89D@yahoo.com> <125F273F-6F0B-49BB-87AE-8B94DE621407@yahoo.com> To: FreeBSD PowerPC ML , Justin Hibbits X-Mailer: Apple Mail (2.3445.104.8) X-Rspamd-Queue-Id: AEFD56D61D X-Spamd-Bar: +++ X-Spamd-Result: default: False [3.38 / 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]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; 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)[]; 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)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(0.91)[0.910,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(1.77)[ip: (7.23), ipnet: 98.137.64.0/21(0.94), asn: 36647(0.75), country: US(-0.06)]; NEURAL_SPAM_MEDIUM(0.57)[0.568,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.64)[0.636,0]; RCVD_IN_DNSWL_NONE(0.00)[146.64.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: Mon, 15 Apr 2019 07:36:00 -0000 [Adjusting 2 more files got the PowerMac7,2 to boot in usefdt mode.] On 2019-Apr-14, at 19:44, Mark Millard wrote: > [I tried adjusting one thing that I'd listed and it let the > PowerMac7.2 get farther into the boot sequence without messing > up the PowerMac11,2 or PowerMac3,6 booting.] >=20 > On 2019-Apr-13, at 23:21, Mark Millard wrote: >=20 >> [I added some debug output that shows odd mixes of openfirmware >> vs. fdt node ids. This notes an example of what it shows.] >>=20 >> On 2019-Apr-13, at 19:44, Mark Millard wrote: >>=20 >>> I'm going to use interrupt-parent as an example of the type of = issue. >>>=20 >>> In the below ofwdump -ap diff extractions: >>>=20 >>> - is from without usefdt mode >>> + is from with usefdt mode >>>=20 >>> - Node 0xff963f60: interrupt-controller >>> + Node 0x2767c: interrupt-controller >>> + phandle: >>> + ff 96 3f 60=20 >>>=20 >>> Note that the Node id changes but a phandle is added hiolding the >>> Node id that openfirmware originally had. >>>=20 >>> Picking an example where interrupt-parent is in use: >>>=20 >>>=20 >>> - Node 0xff964428: extint-gpio1 >>> + Node 0x27800: extint-gpio1 >>> + phandle: >>> + ff 96 44 28=20 >>> . . . >>> interrupt-parent: >>> ff 96 3f 60=20 >>> . . . >>>=20 >>> (openfirmware and fdt are no different for the value >>> contained in the interrupt-parent property: it is the >>> openfirmware node id, not the FDT one.) >>>=20 >>> So, for fdt use, comparison to the phandle property value is >>> is how to find/match this interrupt-controller via a >>> interrupt-parent. Direct use of 0xff963f60 as a node id >>> is inappropriate for usefdt mode. >>>=20 >>> The above is very general and I did not try to match the >>> specific nodes to ones the code below would be using, beyond >>> initially sticking to interrupt-parent types of references. >>>=20 >>> I find there is example code around that makes no prevision >>> for finding the interrupt-parent via a phandle comparison. >>>=20 >>> An example is in unin_chip_add_intr : >>>=20 >>> if (OF_getprop(devnode, "interrupt-parent", &iparent, = sizeof(iparent)) >>> <=3D 0) >>> panic("Interrupt but no interrupt parent!\n"); >>>=20 >>> if (OF_searchprop(iparent, "#interrupt-cells", &icells, = sizeof(icells)) >>> <=3D 0) >>> icells =3D 1; >>>=20 >>> For usefdt mode iparent's value is an openfirmware node id, not a = fdt one. >>> It is the phandle property value that would match. >>>=20 >>> Another is in unin_chip_attach: >>>=20 >>> if (OF_getprop(child, "interrupt-parent", = &iparent, >>> sizeof(iparent)) <=3D 0) { >>> . . . >>> } >>> /* Add an interrupt number 0 to the parent. */ >>> irq =3D MAP_IRQ(iparent, 0); >>>=20 >>> (It appears MAP_IRQ uses powerpc_get_irq and I do not see a stage >>> that can involve the phandle property for matching.) >>>=20 >>> Another may be macgpio_attach: >>>=20 >>> OF_searchencprop(child, "interrupt-parent", = &iparent, >>> sizeof(iparent)); >>> resource_list_add(&dinfo->mdi_resources, = SYS_RES_IRQ, >>> 0, MAP_IRQ(iparent, irq[0]), >>> MAP_IRQ(iparent, irq[0]), 1); >>>=20 >>> Other's besides interrupt-parent . . . >>>=20 >>> There are some gpio-parent properties but I did not find code using >>> them. (I may have just missed such.) I quit looking for code use >>> but did find more types of references in the fdt itself . . . >>>=20 >>> l2-cache in, say, a PowerPC,G4 for usefdt mode is another type of >>> example. >>>=20 >>> platform-enableclock and platform-disableclock seem to be be >>> examples (references back to uni-n in what I looked at, but >>> having the openfirmwire node id, not the fdt one). >>>=20 >>> I may not have found all the example types of "needs phandle = property >>> value comparisons instead of direct node id use for usefdt mode". >>>=20 >>> This is all from a 2-socket/1-core-each G4 PowerMac3,6 example. >>>=20 >>> [Even any G5 example would be via 32-bit pweorpc FreeBSD. This is >>> because (for a long time now) use of ofwdump -ap crashes powerpc64 >>> PowerMac's. But I've not gone through a G5 example (yet?).] >>=20 >> In powerpc_register_pic I added the printf shown below: >>=20 >> powerpc_register_pic(device_t dev, uint32_t node, u_int irqs, u_int = ipis, >> u_int atpic) >> . . . >> for (idx =3D 0; idx < npics; idx++) { >> p =3D &piclist[idx]; >> printf("idx,npics: p->node, node, p->dev, dev: %u,%u: = %x, %x, %x, %x\n",idx,npics,p->node,node,p->dev,dev); >> if (p->node !=3D node) >> continue; >> if (node !=3D 0 || p->dev =3D=3D dev) >> break; >> } >> p =3D &piclist[idx]; >> p->dev =3D dev; >> p->node =3D node; >> p->irqs =3D irqs; >> p->ipis =3D ipis; >> if (idx =3D=3D npics) { >> #ifdef DEV_ISA >> p->base =3D (atpic) ? 0 : nirqs; >> #else >> p->base =3D nirqs; >> #endif >> irq =3D p->base + irqs + ipis; >> nirqs =3D MAX(nirqs, irq); >> npics++; >> } >>=20 >>=20 >> It shows for usefdt mode booting of a 2-socket/1-core-each G5 = PowerMac11,2: >>=20 >> idx,npics: p->node, node, p->dev, dev: 0,1: ff981488, 4e88, 0, = 1e95600 >>=20 >> So piclist[0].node has a value for/from openfirmware instead of fdt. >> But the caller supplied a fdt node value, not an openfirmware one. >>=20 >> The loop will not match the two, even if the fdt node has a phandle >> property that lists the 0xff981488 value. The later code would then >> add a separate entry in piclist with the fdt node id and increment >> npics. >>=20 >> Looks to me like the intent for usefdt mode was likely to not have = any >> openfirmware id value in any piclist[?].node field. (True?) >=20 > [Note: The above guess work for piclist[?].node seems to be wrong.] >=20 >> This sort of thing appears to be involved in why usefdt mode crashes >> on the example 2-socket/1-core-each G5 PowerMac7,2 . >>=20 >> The code directly putting the openfirmware value (that it was >> given) into the piclist is: >>=20 >> powerpc_get_irq(uint32_t node, u_int pin) >> . . . >> piclist[idx].dev =3D NULL; >> piclist[idx].node =3D node; >> piclist[idx].irqs =3D 124; >> piclist[idx].ipis =3D 4; >> piclist[idx].base =3D nirqs; >> nirqs +=3D (1 << 25); >> npics++; >> . . . >>=20 >> This goes back to MAP_IRQ use with openfirmware node id values. >=20 > I adjusted to be using the following in unin_chip_add_intr : >=20 > # svnlite diff /usr/src/sys/powerpc/powermac/uninorth.c > Index: /usr/src/sys/powerpc/powermac/uninorth.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /usr/src/sys/powerpc/powermac/uninorth.c (revision 345758) > +++ /usr/src/sys/powerpc/powermac/uninorth.c (working copy) > @@ -181,7 +181,7 @@ > <=3D 0) > panic("Interrupt but no interrupt parent!\n"); >=20 > - if (OF_searchprop(iparent, "#interrupt-cells", &icells, = sizeof(icells)) > + if (OF_searchprop(OF_node_from_xref(iparent), = "#interrupt-cells", &icells, sizeof(icells)) > <=3D 0) > icells =3D 1; >=20 >=20 > This get farther into the boot sequence: >=20 > subsystem a800000 > boot_run_interrupt_driven_config_hooks(0)... max66900: 2 sensors = detected. > max66901: 2 sensors detected. > ugen1.1: at usbus1 > . . . > ada0 at ata2 bus 0 scbus2 target 0 lun 0 > ada0: ATA8-ACS SATA 2.x device > ada0: Serial Number OW140507AS1363504 > ada0: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO 512bytes) > ada0: 114473MB (234441648 512 byte sectors) > cd0 at ata0 bus 0 scbus0 target 0 lun 0 > cd0: Removable CD-ROM SCSI device > cd0: Serial Number FFDP051360WL > cd0: 66.700MB/s transfers (UDMA4, ATAPI 12bytes, PIO 65534bytes) > cd0: Attempt to query device size failed: NOT READY, Medium not = present >=20 > But boot_run_interrupt_driven_config_hooks never reports "done.". The following were the 2 recent changes that finally allowed the PowerMac7,2 to boot in usefdt mode (and vt instead of sc): Index: /usr/src/sys/powerpc/powermac/hrowpic.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/powerpc/powermac/hrowpic.c (revision 345758) +++ /usr/src/sys/powerpc/powermac/hrowpic.c (working copy) @@ -169,7 +169,7 @@ hrowpic_write_reg(sc, HPIC_ENABLE, HPIC_SECONDARY, 0); hrowpic_write_reg(sc, HPIC_CLEAR, HPIC_SECONDARY, 0xffffffff); =20 - powerpc_register_pic(dev, ofw_bus_get_node(dev), 64, 0, FALSE); + powerpc_register_pic(dev, = OF_xref_from_node(ofw_bus_get_node(dev)), 64, 0, FALSE); return (0); } =20 Index: /usr/src/sys/powerpc/powerpc/openpic.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/powerpc/powerpc/openpic.c (revision 345758) +++ /usr/src/sys/powerpc/powerpc/openpic.c (working copy) @@ -37,6 +37,8 @@ #include #include =20 +#include + #include #include #include @@ -220,7 +222,7 @@ for (cpu =3D 0; cpu < sc->sc_ncpu; cpu++) openpic_write(sc, OPENPIC_PCPU_TPR(cpu), 0); =20 - powerpc_register_pic(dev, node, sc->sc_nirq, 4, FALSE); + powerpc_register_pic(dev, OF_xref_from_node(node), sc->sc_nirq, = 4, FALSE); =20 /* If this is not a cascaded PIC, it must be the root PIC */ if (sc->sc_intr =3D=3D NULL) The PowerMac11,2 and PowerMac3,6 still boot. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-ppc@freebsd.org Mon Apr 15 08:28:00 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 459B8156C015 for ; Mon, 15 Apr 2019 08:28:00 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id CB5B76EDCB for ; Mon, 15 Apr 2019 08:27:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 86EBD156C014; Mon, 15 Apr 2019 08:27:59 +0000 (UTC) Delivered-To: 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 749BD156C013 for ; Mon, 15 Apr 2019 08:27:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1083F6EDC9 for ; Mon, 15 Apr 2019 08:27:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 57DAB1BF4 for ; Mon, 15 Apr 2019 08:27:58 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x3F8Rw1t076444 for ; Mon, 15 Apr 2019 08:27:58 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x3F8RwiF076443 for ppc@FreeBSD.org; Mon, 15 Apr 2019 08:27:58 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: ppc@FreeBSD.org Subject: [Bug 233863] r345425 on PowerMac G5 may require kern.smp.disabled=1 and must set usefdt=1 which causes net interface reorder Date: Mon, 15 Apr 2019 08:27:57 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: marklmi26-fbsd@yahoo.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: ppc@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.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: Mon, 15 Apr 2019 08:28:00 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D233863 --- Comment #16 from Mark Millard --- (In reply to Mark Millard from comment #15) I should have noted that for the PowerMac7,2 configuration involved, booting with kern..vty=3Dvt instead of kern.vty=3Dsc is required. For scons ( kern.vty=3Dsc ) the display stops updating just after the "Kernel entry at . . ." message, before even it clears the screen. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-ppc@freebsd.org Mon Apr 15 14:47:30 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 EB5E81575B7A for ; Mon, 15 Apr 2019 14:47:29 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 94B3E844A5 for ; Mon, 15 Apr 2019 14:47:29 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by freefall.freebsd.org (Postfix) id 84FDB8345; Mon, 15 Apr 2019 14:47:29 +0000 (UTC) Delivered-To: powerpc@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id 815ED8344 for ; Mon, 15 Apr 2019 14:47:29 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DABEF844A2 for ; Mon, 15 Apr 2019 14:47:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 0D5275540 for ; Mon, 15 Apr 2019 14:47:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x3FElQlX074062 for ; Mon, 15 Apr 2019 14:47:26 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x3FElQ42074061 for powerpc@FreeBSD.org; Mon, 15 Apr 2019 14:47:26 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: powerpc@FreeBSD.org Subject: [Bug 237208] java/openjdk11: port to powerpc64 Date: Mon, 15 Apr 2019 14:47:26 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: pkubaj@anongoth.pl X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: java@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-Rspamd-Queue-Id: 94B3E844A5 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.99 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.995,0]; ASN(0.00)[asn:11403, ipnet:2610:1c1:1::/48, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,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: Mon, 15 Apr 2019 14:47:30 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D237208 --- Comment #4 from Piotr Kubaj --- (In reply to mikael.urankar from comment #3) Now: # # A fatal error has been detected by the Java Runtime Environment: # # SIGILL (0x4) at pc=3D0x0000000819df229c, pid=3D79124, tid=3D102195 # # JRE version: OpenJDK Runtime Environment (11.0.2+9) (build 11.0.2+9-4) # Java VM: OpenJDK 64-Bit Server VM (11.0.2+9-4, mixed mode, tiered, compre= ssed oops, serial gc, bsd-ppc64) # Problematic frame: # v ~StubRoutines::jbyte_disjoint_arraycopy # # Core dump will be written. Default location: /usr/local/poudriere/ports/default/java/openjdk11/work/openjdk-jdk11u-jdk-1= 1.0.2-9-4/make/javac.core # # An error report file with more information is saved as: # /usr/local/poudriere/ports/default/java/openjdk11/work/openjdk-jdk11u-jdk-1= 1.0.2-9-4/make/hs_err_pid79124.log Compiled method (c1) 7468 131 1 java.util.Arrays::copyOfRan= ge (63 bytes) total in heap [0x000000081a970a90,0x000000081a9717e8] =3D 3416 relocation [0x000000081a970bf0,0x000000081a970cd0] =3D 224 constants [0x000000081a970d00,0x000000081a970d80] =3D 128 main code [0x000000081a970d80,0x000000081a971300] =3D 1408 stub code [0x000000081a971300,0x000000081a971530] =3D 560 oops [0x000000081a971530,0x000000081a971538] =3D 8 metadata [0x000000081a971538,0x000000081a9715c8] =3D 144 scopes data [0x000000081a9715c8,0x000000081a9716c0] =3D 248 scopes pcs [0x000000081a9716c0,0x000000081a9717d0] =3D 272 dependencies [0x000000081a9717d0,0x000000081a9717d8] =3D 8 nul chk table [0x000000081a9717d8,0x000000081a9717e8] =3D 16 Compiled method (nm) 7483 236 n 0 java.lang.Class::isArray (native) total in heap [0x000000081a98ce10,0x000000081a98d160] =3D 848 relocation [0x000000081a98cf70,0x000000081a98cf78] =3D 8 main code [0x000000081a98cf80,0x000000081a98d160] =3D 480 Could not load hsdis-ppc64.so; library not loadable; PrintAssembly is disab= led # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp # # # A fatal error has been detected by the Java Runtime Environment: # # SIGILL (0x4) at pc=3D0x0000000819df291c, pid=3D79308, tid=3D101052 # # JRE version: OpenJDK Runtime Environment (11.0.2+9) (build 11.0.2+9-4) # Java VM: OpenJDK 64-Bit Server VM (11.0.2+9-4, mixed mode, tiered, compre= ssed oops, g1 gc, bsd-ppc64) # Problematic frame: # v ~StubRoutines::jbyte_disjoint_arraycopy # # Core dump will be written. Default location: /usr/local/poudriere/ports/default/java/openjdk11/work/openjdk-jdk11u-jdk-1= 1.0.2-9-4/make/hotspot/javac.core # # An error report file with more information is saved as: # /usr/local/poudriere/ports/default/java/openjdk11/work/openjdk-jdk11u-jdk-1= 1.0.2-9-4/make/hotspot/hs_err_pid79308.log Compiled method (c2) 15848 437 4=20=20=20=20=20=20 java.lang.AbstractStringBuilder::append (45 bytes) total in heap [0x0000000842175e10,0x0000000842176c50] =3D 3648 relocation [0x0000000842175f70,0x0000000842176000] =3D 144 constants [0x0000000842176000,0x0000000842176100] =3D 256 main code [0x0000000842176100,0x0000000842176800] =3D 1792 stub code [0x0000000842176800,0x0000000842176928] =3D 296 metadata [0x0000000842176928,0x0000000842176968] =3D 64 scopes data [0x0000000842176968,0x0000000842176b20] =3D 440 scopes pcs [0x0000000842176b20,0x0000000842176c00] =3D 224 dependencies [0x0000000842176c00,0x0000000842176c08] =3D 8 handler table [0x0000000842176c08,0x0000000842176c20] =3D 24 nul chk table [0x0000000842176c20,0x0000000842176c50] =3D 48 Compiled method (c2) 15859 437 4=20=20=20=20=20=20 java.lang.AbstractStringBuilder::append (45 bytes) total in heap [0x0000000842175e10,0x0000000842176c50] =3D 3648 relocation [0x0000000842175f70,0x0000000842176000] =3D 144 constants [0x0000000842176000,0x0000000842176100] =3D 256 main code [0x0000000842176100,0x0000000842176800] =3D 1792 stub code [0x0000000842176800,0x0000000842176928] =3D 296 metadata [0x0000000842176928,0x0000000842176968] =3D 64 scopes data [0x0000000842176968,0x0000000842176b20] =3D 440 scopes pcs [0x0000000842176b20,0x0000000842176c00] =3D 224 dependencies [0x0000000842176c00,0x0000000842176c08] =3D 8 handler table [0x0000000842176c08,0x0000000842176c20] =3D 24 nul chk table [0x0000000842176c20,0x0000000842176c50] =3D 48 Could not load hsdis-ppc64.so; library not loadable; PrintAssembly is disab= led # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp # # # A fatal error has been detected by the Java Runtime Environment: # # SIGILL (0x4) at pc=3D0x0000000819df2f6c, pid=3D79364, tid=3D102206 # # JRE version: OpenJDK Runtime Environment (11.0.2+9) (build 11.0.2+9-4) # Java VM: OpenJDK 64-Bit Server VM (11.0.2+9-4, mixed mode, tiered, compre= ssed oops, g1 gc, bsd-ppc64) # Problematic frame: # v ~StubRoutines::arrayof_jbyte_disjoint_arraycopy # # Core dump will be written. Default location: /usr/local/poudriere/ports/default/java/openjdk11/work/openjdk-jdk11u-jdk-1= 1.0.2-9-4/make/hotspot/javac.core # # An error report file with more information is saved as: # /usr/local/poudriere/ports/default/java/openjdk11/work/openjdk-jdk11u-jdk-1= 1.0.2-9-4/make/hotspot/hs_err_pid79364.log Compiled method (c1) 19895 515 3=20=20=20=20=20=20 jdk.internal.org.objectweb.asm.ByteVector::enlarge (51 bytes) total in heap [0x000000081a5de910,0x000000081a5df0d8] =3D 1992 relocation [0x000000081a5dea70,0x000000081a5deaa0] =3D 48 constants [0x000000081a5deb00,0x000000081a5deb80] =3D 128 main code [0x000000081a5deb80,0x000000081a5def80] =3D 1024 stub code [0x000000081a5def80,0x000000081a5deff0] =3D 112 metadata [0x000000081a5deff0,0x000000081a5df010] =3D 32 scopes data [0x000000081a5df010,0x000000081a5df060] =3D 80 scopes pcs [0x000000081a5df060,0x000000081a5df0c0] =3D 96 dependencies [0x000000081a5df0c0,0x000000081a5df0c8] =3D 8 nul chk table [0x000000081a5df0c8,0x000000081a5df0d8] =3D 16 Compiled method (c1) 19996 515 3=20=20=20=20=20=20 jdk.internal.org.objectweb.asm.ByteVector::enlarge (51 bytes) total in heap [0x000000081a5de910,0x000000081a5df0d8] =3D 1992 relocation [0x000000081a5dea70,0x000000081a5deaa0] =3D 48 constants [0x000000081a5deb00,0x000000081a5deb80] =3D 128 main code [0x000000081a5deb80,0x000000081a5def80] =3D 1024 stub code [0x000000081a5def80,0x000000081a5deff0] =3D 112 metadata [0x000000081a5deff0,0x000000081a5df010] =3D 32 scopes data [0x000000081a5df010,0x000000081a5df060] =3D 80 scopes pcs [0x000000081a5df060,0x000000081a5df0c0] =3D 96 dependencies [0x000000081a5df0c0,0x000000081a5df0c8] =3D 8 nul chk table [0x000000081a5df0c8,0x000000081a5df0d8] =3D 16 Compiled method (c1) 20003 263 3=20=20=20=20=20=20 jdk.internal.org.objectweb.asm.ClassWriter::newUTF8 (70 bytes) total in heap [0x000000081a54e890,0x000000081a54f310] =3D 2688 relocation [0x000000081a54e9f0,0x000000081a54ea88] =3D 152 constants [0x000000081a54eb00,0x000000081a54eb80] =3D 128 main code [0x000000081a54eb80,0x000000081a54ef80] =3D 1024 stub code [0x000000081a54ef80,0x000000081a54f130] =3D 432 metadata [0x000000081a54f130,0x000000081a54f188] =3D 88 scopes data [0x000000081a54f188,0x000000081a54f200] =3D 120 scopes pcs [0x000000081a54f200,0x000000081a54f2e0] =3D 224 dependencies [0x000000081a54f2e0,0x000000081a54f2e8] =3D 8 nul chk table [0x000000081a54f2e8,0x000000081a54f310] =3D 40 Compiled method (c1) 20033 363 3=20=20=20=20=20=20 jdk.internal.org.objectweb.asm.ClassWriter::newStringishItem (68 bytes) total in heap [0x000000081a57cb10,0x000000081a57d568] =3D 2648 relocation [0x000000081a57cc70,0x000000081a57cd08] =3D 152 constants [0x000000081a57cd80,0x000000081a57ce00] =3D 128 main code [0x000000081a57ce00,0x000000081a57d200] =3D 1024 stub code [0x000000081a57d200,0x000000081a57d3b0] =3D 432 metadata [0x000000081a57d3b0,0x000000081a57d408] =3D 88 scopes data [0x000000081a57d408,0x000000081a57d488] =3D 128 scopes pcs [0x000000081a57d488,0x000000081a57d548] =3D 192 dependencies [0x000000081a57d548,0x000000081a57d550] =3D 8 nul chk table [0x000000081a57d550,0x000000081a57d568] =3D 24 Could not load hsdis-ppc64.so; library not loadable; PrintAssembly is disab= led # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp # Logs are attached. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-ppc@freebsd.org Mon Apr 15 14:47:47 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 EE7831575BA7 for ; Mon, 15 Apr 2019 14:47:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8B6ED844D6 for ; Mon, 15 Apr 2019 14:47:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by freefall.freebsd.org (Postfix) id 522C2836C; Mon, 15 Apr 2019 14:47:46 +0000 (UTC) Delivered-To: powerpc@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id 4E797836B for ; Mon, 15 Apr 2019 14:47:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F2310844D3 for ; Mon, 15 Apr 2019 14:47:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 568DC5542 for ; Mon, 15 Apr 2019 14:47:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x3FEljKX074375 for ; Mon, 15 Apr 2019 14:47:45 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x3FElj7o074374 for powerpc@FreeBSD.org; Mon, 15 Apr 2019 14:47:45 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: powerpc@FreeBSD.org Subject: [Bug 237208] java/openjdk11: port to powerpc64 Date: Mon, 15 Apr 2019 14:47:45 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: pkubaj@anongoth.pl X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: java@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: attachments.mimetype attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-Rspamd-Queue-Id: 8B6ED844D6 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.99 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.995,0]; ASN(0.00)[asn:11403, ipnet:96.47.64.0/20, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,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: Mon, 15 Apr 2019 14:47:47 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D237208 Piotr Kubaj changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #203697|text/x-log |text/plain mime type| | --- Comment #5 from Piotr Kubaj --- Created attachment 203697 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D203697&action= =3Dedit log1 --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-ppc@freebsd.org Mon Apr 15 14:48:05 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 3AB4A1575BF3 for ; Mon, 15 Apr 2019 14:48:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B092B84513 for ; Mon, 15 Apr 2019 14:48:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by freefall.freebsd.org (Postfix) id A35C28382; Mon, 15 Apr 2019 14:48:04 +0000 (UTC) Delivered-To: powerpc@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id 9ECAA8381 for ; Mon, 15 Apr 2019 14:48:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 61A478450F for ; Mon, 15 Apr 2019 14:48:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id AF9395547 for ; Mon, 15 Apr 2019 14:48:03 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x3FEm3dY074669 for ; Mon, 15 Apr 2019 14:48:03 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x3FEm3sX074668 for powerpc@FreeBSD.org; Mon, 15 Apr 2019 14:48:03 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: powerpc@FreeBSD.org Subject: [Bug 237208] java/openjdk11: port to powerpc64 Date: Mon, 15 Apr 2019 14:48:03 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: pkubaj@anongoth.pl X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: java@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: attachments.mimetype attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-Rspamd-Queue-Id: B092B84513 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.99 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.995,0]; ASN(0.00)[asn:11403, ipnet:2610:1c1:1::/48, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,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: Mon, 15 Apr 2019 14:48:05 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D237208 Piotr Kubaj changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #203698|text/x-log |text/plain mime type| | --- Comment #6 from Piotr Kubaj --- Created attachment 203698 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D203698&action= =3Dedit log2 --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-ppc@freebsd.org Mon Apr 15 14:48:29 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 BB6EB1575C4D for ; Mon, 15 Apr 2019 14:48:28 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5A6C284583 for ; Mon, 15 Apr 2019 14:48:28 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by freefall.freebsd.org (Postfix) id 47D9083C0; Mon, 15 Apr 2019 14:48:28 +0000 (UTC) Delivered-To: powerpc@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id 4497383BF for ; Mon, 15 Apr 2019 14:48:28 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 09F7E8457F for ; Mon, 15 Apr 2019 14:48:28 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 433BE554B for ; Mon, 15 Apr 2019 14:48:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x3FEmRLV075067 for ; Mon, 15 Apr 2019 14:48:27 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x3FEmRwY075066 for powerpc@FreeBSD.org; Mon, 15 Apr 2019 14:48:27 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: powerpc@FreeBSD.org Subject: [Bug 237208] java/openjdk11: port to powerpc64 Date: Mon, 15 Apr 2019 14:48:27 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: pkubaj@anongoth.pl X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: java@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: attachments.mimetype attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-Rspamd-Queue-Id: 5A6C284583 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.99 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.995,0]; ASN(0.00)[asn:11403, ipnet:96.47.64.0/20, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,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: Mon, 15 Apr 2019 14:48:29 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D237208 Piotr Kubaj changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #203699|text/x-log |text/plain mime type| | --- Comment #7 from Piotr Kubaj --- Created attachment 203699 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D203699&action= =3Dedit log3 --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-ppc@freebsd.org Tue Apr 16 04:44:57 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 9D8B21588CD6 for ; Tue, 16 Apr 2019 04:44:57 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-23.consmr.mail.gq1.yahoo.com (sonic303-23.consmr.mail.gq1.yahoo.com [98.137.64.204]) (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 A73C273411 for ; Tue, 16 Apr 2019 04:44:55 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: W0Is_WAVM1kO4KXOXFwCyjL29sWNa0VVlNGqZEZZ64Enz9LBQZJtGTcfS4tvES0 KAjibSK6NmblLA0j88fN.O976RI21wBdIBrYhHQcEGEr.F66Dq23NrYPWeqcIuo6349x7EG0y.S7 Vb3tMTgHVYEZDqk8SH7r1_CQHn1J46iy1uC56D21kwdar07q6FkRCOYY3AutZUZbU77YlAxctjPM vQSRsjEscNC2xZmHj9100MQ2iv_tB5jIRtLeuz1eVZdLJFWjP2qxqY2vvx7lXI28HDBw0yBK0Jex UMTChQ6yv.LzMNVaaOty6UeugZQXQtALDv5w1wyRFLIsM4r0h8_ue5bCJYsgcUrzNEfzJOsxo5Tl ls_Nvxfr2peoC3zwVBf8b5ppYMmcXwcz6RNRgGe_rRD3g9hmTGTGDYFEIE0f6CbXYP.d4Rtw1SrP f9xVk4dK076Neiu_9SG4pRMExdXQ3Rz7ep1Fg3rRKaXhum4jakZ_kiHRjD7tXzx58N2cQHUT6QdH scFduMI8OFmKUV7frJubG6yPTCitKLMuXZtmyD.beufZeGMml_WotYVNd55xr0TYWFYUaxrrzSPC ndLm1h9MOY33DAYyqwD7tJunTQYpY90_EuUXJkHkwhapNzMxXokRn0Ud8R2_yauBwtxIU4mBYjAh h39RU4ImwgNX9ruhxP5rr_GyAIieHw_H7RC10jqTYafo5I3lljbzK9wQQAxiq.4T6KswIleIf4eK 3SmHVIUcZw16ARaPzm_V6s5k2Fs92YEUBOyGYh9Qffb_zuP3g2NaijviYG5Rm9rkbPhvMTK76ZYB xRm01_6ZQND.wXSDaxauw7beJ5Fjh1iDU_ZIWUkcc6ScsPYtzJt7PNAOhDv2Y8UAWh_lKjMyhw.u 6j.HJnaErQ28RLM2vzND8JOSK6CJSM6IQ3.FyXzxJkUusnhnE74WU7UquSiwOVOafNhlH0iUW5L. xRKqYgFQQEPDyioXbYHB6AWbcOFDdhtAiyChElxCydUAxw_1NVpYJI3BCUzzb6AIeP2K6FWUdhw5 yBk3rIjlhK51Vje7v6k2ZeG2Vk.Z_QQFXM1Rcqxdb0AbDFAChVLeHzQmI0as6cgAHLtlk4PPHjEo hSxE.0Q-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Tue, 16 Apr 2019 04:44:48 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.103]) ([76.115.7.162]) by smtp410.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 3ed51b32dff3ccf68a761fb9dbcd14a7; Tue, 16 Apr 2019 04:44:45 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Subject: Re: PowerMac11,2 G5 (2 socket, 2 cores each) powerpc64: sometime between -r302214 and -r333594 owfdump -ap leads to 'timeout stopping cpus' and ddb> prompt From: Mark Millard In-Reply-To: Date: Mon, 15 Apr 2019 21:44:44 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: To: FreeBSD PowerPC ML , Justin Hibbits X-Mailer: Apple Mail (2.3445.104.8) X-Rspamd-Queue-Id: A73C273411 X-Spamd-Bar: - X-Spamd-Result: default: False [-1.19 / 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]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; 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)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.61)[-0.609,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(0.15)[0.149,0]; NEURAL_HAM_LONG(-0.89)[-0.887,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.66)[ip: (1.69), ipnet: 98.137.64.0/21(0.94), asn: 36647(0.75), country: US(-0.06)]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[204.64.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: Tue, 16 Apr 2019 04:44:57 -0000 [I have a hypothesis for which change made the difference.] On 2019-Apr-9, at 19:10, Mark Millard wrote: > [32-bit powerpc FreeBSD booting the same machine > does not have the problem, just powerpc64 FreeBSD. > I've been using -ap with ofwdump but it might not > be essential to the observed problem.] > > In trying to track down a problem, where I wanted to use > ofwdump -ap information, I ended up finding and checking > old boot media that happen to be around that target > powerpc64. > > The oldest failing: -r333594 (an 12.x-CURRENT time frame) > The newest working: -r302214 (an 11.x-CURRENT time frame) > (No versions around between those.) > > (As almost always, my powerpc64 builds are experiments > targeted via toolchains more modern than gcc 4.2.1 and the > like.) > > Those listed above long predate any useful usefdt > boots/operations in my context. The 2 powerpc64 builds > before -r302214 worked. > > (The original problem that started this is that usefdt skips > some ofw nodes. Then I found that not having usefdt mode > lead to crashes for ofwdump -ap . So I went looking at > the few historical builds that I found.) > > Modern powerpc64/head FreeBSD without use of usefdt mode fails > somewhat differently: scrolling console messages going by too > fast for me to read after starting ofwdump -ap. (It might be > back-traces.) No ability to get to the ddb> prompt and no > access via the network. But modern FreeBSD has various > blocking issues before one can even get this far. [The note about scrolling console messages was tied to an automatic bt that got another trap that caused another bt --and so on. I still had code for looking at early boot time frames enabled (covering before keyboard input works).] In observing a crash it appears to me from some register content that openfirmware_core had possibly called ofwcall and then an unexpected trap happened, which leads back to stop_cpus_hard via kdb_trap via trap_fatal. That stop_cpus_hard is what reported the "timeout stopping cpus" from what I can tell. (Trying to stop several already stopped cpus?) [The crash also happens on the PowerMac7,2 when used via powerpc64 FreeBSD (but not 32-bit FreeBSD).] Well, one possibility for new traps during some ofwcall use might be: Revision 330610 - (view) (download) (annotate) - [select for diffs] Modified Wed Mar 7 17:08:07 2018 UTC (13 months, 1 week ago) by nwhitehorn File length: 7642 byte(s) Diff to previous 328269 Move the powerpc64 direct map base address from zero to high memory. This accomplishes a few things: - Makes NULL an invalid address in the kernel, which is useful for catching bugs. . . . It is from the time frame between the two examples (failing vs. working). === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-ppc@freebsd.org Tue Apr 16 10:01:32 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 8575A156C338 for ; Tue, 16 Apr 2019 10:01:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 19EEC85186 for ; Tue, 16 Apr 2019 10:01:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by freefall.freebsd.org (Postfix) id E3AAA18F35; Tue, 16 Apr 2019 10:01:31 +0000 (UTC) Delivered-To: powerpc@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [96.47.72.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id DFACC18F34 for ; Tue, 16 Apr 2019 10:01:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 88F0D85184 for ; Tue, 16 Apr 2019 10:01:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id D9273FBF9 for ; Tue, 16 Apr 2019 10:01:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x3GA1ULo065785 for ; Tue, 16 Apr 2019 10:01:30 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x3GA1Uwp065784 for powerpc@FreeBSD.org; Tue, 16 Apr 2019 10:01:30 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: powerpc@FreeBSD.org Subject: [Bug 237208] java/openjdk11: port to powerpc64 Date: Tue, 16 Apr 2019 10:01:31 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: mikael.urankar@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: java@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-Rspamd-Queue-Id: 19EEC85186 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.99 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.989,0]; ASN(0.00)[asn:11403, ipnet:96.47.64.0/20, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,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: Tue, 16 Apr 2019 10:01:32 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D237208 --- Comment #8 from mikael.urankar@gmail.com --- (In reply to Piotr Kubaj from comment #4) I can't reproduce on my G5 :/ It builds fine on 11.2 and 12.0: http://mikael.urankar.free.fr/FreeBSD/powerpc64/openjdk11-11.0.2.9.4_120ppc= 64.log http://mikael.urankar.free.fr/FreeBSD/powerpc64/openjdk11-11.0.2.9.4.log --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-ppc@freebsd.org Tue Apr 16 21:26:47 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 EDFB7157E081 for ; Tue, 16 Apr 2019 21:26:46 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-25.consmr.mail.gq1.yahoo.com (sonic303-25.consmr.mail.gq1.yahoo.com [98.137.64.206]) (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 1BA15814A3 for ; Tue, 16 Apr 2019 21:26:44 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: slZkX6YVM1nTrv7E13d.loknuSsgevLvJIuVWWEkIoPjBB6e2edsmyBgkO0KAT8 y7ScIbnKBvSxb4QWx7HsSGYTmMJ3T0bwTbxcxfvI46kPWCZEumksH0Oifdx8dh2c3OjnzfPpbmLL _lBfg2NzmNoXSvxQZTMyrLQODsc7SDEzeK4wMkilfFKXeRbDspTR8YlRtuB4QymkEkNbVTSzyJeK Zk7iu5Kskii8eERabCB.PiV9h0UIAO9MZ3QjB3VHPCfjh1vlKZMqGHiGPqFVt5CbPhOfnSjHUqHJ xdSV6MWwSzPDJUmCqOwp5NIVDQiTA3h6bHH3ef4xiYNdFkxrPQadE4km20W9wVVY55YuL3X2cdq1 RSB6wYWzkgWPn916lVMZ6qkLbSOuRrp7lm6V6vayvUKZPOEzXDfza97REbcv4iFXgXbuet2U1mKo xi8gqAhy6PgZzlmRsDAdgnfMN06LUC46YuEn6ZfZ1vRl2YjLjw_NN9IrVf5IWIFZLolV1p2CHIew 2PK23U.gKnwxTM68vzQi51LA.N5bqOqxwAxyOPp_M7D1FOqqtX7QC9KDWPrG9R6y3x1k6BJnMJBp mE7pSwm8IFTlVh3Pep6JexK077Tl9mSWMp0zNdRRWWHHY57Fm_iwaZSASc4tkobQ4pofuWYo1w1A SH_NkBpGSobCgcHiDfKiU1Wb9B8QDrQfsS5j07yY1aw8yKXTdPJxQF0t2QplnpL9Jdas5FJftrbO NqKke24.08.8yjO39o8H_P1EGCugXrxZiBeHgUWIKfdH0E70cK048D.ieCRlga4dTaLCE0sheTk7 fWjLEpmBa9oWoLTUuKqRl6HQu._gv1wnQuO31pEWWowYJtNu0ZRr1Ew6qCn_qhcHrAGyVEWIsf37 xAwZW2fCL.jB6_7Ha2554wmPOzG.dMQAy.g8Oa8UiXT6MlQY8j_AQQwrKy_QorxeAHFbS9d.SsbD LNx8118dgLRWX3P7wmG4H8xt.k17IW6r2IEfORvgPbLCsDDB2sTUbrY5KGFa2YXcaPD.mSCETNRc tVQe_bNuaeB6w80fzVKySLvYFFjOgAtaNKiIxhQPHHqxF_nULnHCc.CJ52G2VvUyWEdcwpl595A4 - Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Tue, 16 Apr 2019 21:26:43 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.103]) ([76.115.7.162]) by smtp403.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 1135979b6d7e4fb92bf7daa05a32ff78; Tue, 16 Apr 2019 21:26:40 +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 -r344018 powerpc64 variant on Powermac G5 (2 sockets, 2 cores each): [*buffer arena] shows up more . . .? [mpc85xx_smp_timebase_sync problem too] From: Mark Millard In-Reply-To: <20190306223611.75c8a87e@titan.knownspace> Date: Tue, 16 Apr 2019 14:26:39 -0700 Cc: freebsd-ppc Content-Transfer-Encoding: 7bit Message-Id: <984188AE-93A9-4321-99EC-522C2E0CE9A9@yahoo.com> References: <20190306151914.44ea831c@titan.knownspace> <8668AAF7-9E6A-4278-9D1B-2ECDBD3804AA@yahoo.com> <99AD89F8-0F90-48BE-A060-DA12FD7129E6@yahoo.com> <20190306223611.75c8a87e@titan.knownspace> To: Justin Hibbits X-Mailer: Apple Mail (2.3445.104.8) X-Rspamd-Queue-Id: 1BA15814A3 X-Spamd-Bar: +++ X-Spamd-Result: default: False [3.45 / 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.87)[0.875,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(1.66)[ip: (6.66), ipnet: 98.137.64.0/21(0.93), asn: 36647(0.75), country: US(-0.06)]; NEURAL_SPAM_MEDIUM(0.66)[0.657,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.77)[0.769,0]; RCVD_IN_DNSWL_NONE(0.00)[206.64.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: Tue, 16 Apr 2019 21:26:47 -0000 [Looks to me like the use and content of mpc85xx_smp_timebase_sync have the same type of problems I noted for the proposed powermac patch.] On 2019-Mar-6, at 20:36, Justin Hibbits wrote: > On Wed, 6 Mar 2019 18:35:42 -0800 > Mark Millard wrote: > >> [The patch is definitely wrong via a 3rd use of >> platform_smp_timebase_sync that I'd not noted before. Details at the >> end.] >> >> On 2019-Mar-6, at 16:39, Mark Millard wrote: >> >> >> >>> On 2019-Mar-6, at 13:19, Justin Hibbits >>> wrote: >>>> On Mon, 4 Mar 2019 19:43:09 -0800 >>>> Mark Millard via freebsd-ppc wrote: >>>> >>>>> [It is possible that the following is tied to my hack to >>>>> avoid threads ending up stuck-sleeping. But I ask about >>>>> an alternative that I see in the code.] >>>>> >>>>> Context: using the modern powerpc64 VM_MAX_KERNEL_ADDRESS >>>>> and using usefdt=1 on an old Powermac G5 (2 sockets, 2 cores >>>>> each). Hacks are in use to provide fairly reliable booting >>>>> and to avoid threads getting stuck sleeping. >>>>> >>>>> Before the modern VM_MAX_KERNEL_ADDRESS figure there were only >>>>> 2 or 3 bufspacedaemon-* threads as I remember. Now there are 8 >>>>> (plus bufdaemon and its worker), for example: >>>>> >>>>> root 23 0.0 0.0 0 288 - DL 15:48 0:00.39 >>>>> [bufdaemon/bufdaemon] root 23 0.0 0.0 0 288 - >>>>> DL 15:48 0:00.05 [bufdaemon/bufspaced] root 23 0.0 >>>>> 0.0 0 288 - DL 15:48 0:00.05 [bufdaemon/bufspaced] >>>>> root 23 0.0 0.0 0 288 - DL 15:48 0:00.05 >>>>> [bufdaemon/bufspaced] root 23 0.0 0.0 0 288 - >>>>> DL 15:48 0:00.05 [bufdaemon/bufspaced] root 23 0.0 >>>>> 0.0 0 288 - DL 15:48 0:00.05 [bufdaemon/bufspaced] >>>>> root 23 0.0 0.0 0 288 - DL 15:48 0:00.07 >>>>> [bufdaemon/bufspaced] root 23 0.0 0.0 0 288 - >>>>> DL 15:48 0:00.05 [bufdaemon/bufspaced] root 23 0.0 >>>>> 0.0 0 288 - DL 15:48 0:00.56 [bufdaemon// worker] >>>>> >>>>> I'm sometimes seeing processes showing [*buffer arena] that >>>>> seemed to wait for a fairly long time with that status, not >>>>> something I'd seen historically for those same types of >>>>> processes for a similar overall load (not much). During such >>>>> times trying to create processes to look around at what is >>>>> going on seems to also wait. (Probably with the same status?) >>>>> >>>> >>>> Hi Mark, >>>> >>>> Can you try the attached patch? It might be overkill in the >>>> synchronization, and I might be using the wrong barriers to be >>>> considered correct, but I think this should narrow the race down, >>>> and synchronize the timebases to within a very small margin. The >>>> real correct fix would be to suspend the timebase on all cores, >>>> which is feasible (there's a GPIO for the G4s, and i2c for G5s), >>>> but that's a non-trivial extra work. >>>> >>>> Be warned, I haven't tested it, I've only compiled it (I don't >>>> have a G5 to test with anymore). >>>> >>> >>> Sure, I'll try it when the G5 is again available: it is doing >>> a time consuming build. >>> >>> I do see one possible oddity: tracing another >>> platform_smp_timebase_sync use in the code . . . >>> >>> DEVMETHOD(cpufreq_drv_set, pmufreq_set) >>> >>> static int >>> pmufreq_set(device_t dev, const struct cf_setting *set) >>> { >>> . . . >>> error = pmu_set_speed(speed_sel); >>> . . . >>> } >>> >>> int >>> pmu_set_speed(int low_speed) >>> { >>> . . . >>> platform_sleep(); >>> . . . >>> } >>> >>> PLATFORMMETHOD(platform_sleep, powermac_sleep), >>> >>> void >>> powermac_sleep(platform_t platform) >>> { >>> >>> *(unsigned long *)0x80 = 0x100; >>> cpu_sleep(); >>> } >>> >>> void >>> cpu_sleep() >>> { >>> . . . >>> platform_smp_timebase_sync(timebase, 0); >>> . . . >>> } >>> >>> PLATFORMMETHOD(platform_smp_timebase_sync, >>> powermac_smp_timebase_sync), >>> >>> The issue: >>> >>> I do not see any matching platform_smp_timebase_sync(timebase, 1) >>> or other CPUs doing a powermac_smp_timebase_sync in this sequence. >>> >>> (If this makes testing the patch inappropriate, let me know.) >>> >> >> More important: There is also a use of: >> >> /* The following is needed for restoring from sleep. */ >> platform_smp_timebase_sync(0, 1); >> >> in cpudep_ap_setup . That in turn happens during cpu_reset_handler >> before machdep_ap_bootstrap is called (which does >> platform_smp_timebase_sync as well) : >> >> cpu_reset_handler: >> GET_TOCBASE(%r2) >> >> ld %r1,TOC_REF(tmpstk)(%r2) /* get new SP */ >> addi %r1,%r1,(TMPSTKSZ-48) >> >> bl CNAME(cpudep_ap_early_bootstrap) /* Set PCPU */ >> nop >> lis %r3,1@l >> bl CNAME(pmap_cpu_bootstrap) /* Turn on virtual >> memory */ nop >> bl CNAME(cpudep_ap_bootstrap) /* Set up PCPU and >> stack */ nop >> mr %r1,%r3 /* Use new stack */ >> bl CNAME(cpudep_ap_setup) >> nop >> GET_CPUINFO(%r5) >> ld %r3,(PC_RESTORE)(%r5) >> cmpldi %cr0,%r3,0 >> beq %cr0,2f >> nop >> li %r4,1 >> bl CNAME(longjmp) >> nop >> 2: >> #ifdef SMP >> bl CNAME(machdep_ap_bootstrap) /* And away! */ >> nop >> #endif >> >> Thus overall for ap's there is the sequence: >> >> platform_smp_timebase_sync(0, 1); >> . . . >> while (ap_letgo == 0) >> __asm __volatile("or 31,31,31"); >> __asm __volatile("or 6,6,6"); >> >> /* >> * Set timebase as soon as possible to meet an implicit >> rendezvous >> * from cpu_mp_unleash(), which sets ap_letgo and then >> immediately >> * sets timebase. >> * >> * Note that this is instrinsically racy and is only relevant >> on >> * platforms that do not support better mechanisms. >> */ >> platform_smp_timebase_sync(ap_timebase, 1); >> >> for each ap . So the (ap) case in powermac_smp_timebase_sync >> will wait with tb==0 (from cpudep_ap_setup) and the later calls >> from machdep_ap_bootstrap will not wait and will be after the >> unleash but not just local to powermac_smp_timebase_sync: >> >> static void >> powermac_smp_timebase_sync(platform_t plat, u_long tb, int ap) >> { >> static int cpus; >> static int unleash; >> >> if (ap) { >> atomic_add_int(&cpus, 1); >> while (!atomic_load_acq_int(&unleash)) >> ; >> } else { >> atomic_add_int(&cpus, 1); >> while (atomic_load_int(&cpus) != mp_ncpus) >> ; >> atomic_store_rel_int(&unleash, 1); >> } >> >> mttb(tb); >> } >> >> In the end cpus will have double counts of the ap cpus instead >> of matching mp_ncpus. >> >> cpufreq_drv_set activity is a seperate, additional issue from this. >> >> === >> Mark Millard >> marklmi at yahoo.com >> ( dsl-only.net went >> away in early 2018-Mar) >> > > As mentioned, I had only compiled it. Your examination of the code > path demonstrates that the patch is insufficient, and would hang at > unleash anyway. The sleep/wake logic probably needs to be updated > anyway. It was written for a G4 powerbook primarily for the PMU-based > cpufreq driver, so some bits might need to be moved around. Orthogonal > to this issue, though. It appears to me that the overall sequence: platform_smp_timebase_sync(0, 1); // called from cpudep_ap_setup . . . // The following are from in machdep_ap_bootstrap . . . while (ap_letgo == 0) __asm __volatile("or 31,31,31"); __asm __volatile("or 6,6,6"); . . . platform_smp_timebase_sync(ap_timebase, 1); calls mpc85xx_smp_timebase_sync twice per ap and that the 2nd call has tb_ready && mp_ncpus<=cpu_done for each such ap, leading to a lack of coordination of the activity that 2nd time for each ap: static void mpc85xx_smp_timebase_sync(platform_t plat, u_long tb, int ap) { static volatile bool tb_ready; static volatile int cpu_done; if (ap) { /* APs. Hold off until we get a stable timebase. */ while (!tb_ready) atomic_thread_fence_seq_cst(); mttb(tb); atomic_add_int(&cpu_done, 1); while (cpu_done < mp_ncpus) atomic_thread_fence_seq_cst(); } else { /* BSP */ freeze_timebase(rcpm_dev, true); tb_ready = true; mttb(tb); atomic_add_int(&cpu_done, 1); while (cpu_done < mp_ncpus) atomic_thread_fence_seq_cst(); freeze_timebase(rcpm_dev, false); } } === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-ppc@freebsd.org Tue Apr 16 21:42:16 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 54A65157E934 for ; Tue, 16 Apr 2019 21:42:16 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-it1-x129.google.com (mail-it1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6EF2A8219C for ; Tue, 16 Apr 2019 21:42:15 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by mail-it1-x129.google.com with SMTP id q14so1267376itk.0 for ; Tue, 16 Apr 2019 14:42:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=smToOd8sQTx2I6XkU726u3taB5cVb8dsSx7ad9BrsFs=; b=DEziiWpXBEHom2jnpw7c5ztj/GQZMUqjC0OP++sCnwUmhJlMO8ia9JL5vrfhdB6zRc dsjL1i5k93GKAiEos1adCDz9uRDjj9/U5rXlDm6q38KiR/4ZhauZfVOcq8aIYObKLG10 kxANheOuA4X9e5mkYYEE1263xABwm3R4hvxxQdBvn53DprGOrtOLq/y6WJkWFyaUwNhp RVSj5+WeIE8MDNT2x7Tg93ucitsYybEifOKQqSZyWOSIc48ZlItHLglZ4iabSJSdmjdZ eABQhqSovzm+H/SvAU6esCANeU+4g/tKqW1OyUCyqFO6d+2JV5UNjhRUAAHtv8TRLeuo 4bQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=smToOd8sQTx2I6XkU726u3taB5cVb8dsSx7ad9BrsFs=; b=OYktcvhMPgIq4hvkhVm6BkoO9Ex9McldGRLZJZYa96/08TbfanMPVAJoPL+EStXt4K 9Y1Th8FzV3QI7jhUq+y+F5llgpL+K2DXLpzQ+romVS6QtLGRIqrJg9ubFH+j9W5PXDP4 KACWNSPi9ctYoXAs93UiLJJGbvo8VyDt8pIZ2tjNyaMRmkAsMG1+eA8hv1SEC+K1dRzQ 8QpR5KYUNp1s7sRf+SW0zOREBPO1lgqB1U5su71X4mk2DI3xQavAg3/MLigWMz6cOP4M eKvulv2JZ+ZjmrxXUvdMZvAlwayhGnBQidQ9GvFovFd38UP+t18T5TmSTOsHVbZ7Rr/p 3Dow== X-Gm-Message-State: APjAAAVmk9MB+XcxD9lXJMI6Bq4kq5yoU+ebqzs+BZNfdTEZbaI84ot7 villsJ3yj466Gy9vUloAtZQ= X-Google-Smtp-Source: APXvYqzSBcIfKlsGDxu2RWv6Q1utN/JzaW3p/UHUAAjs5FW+wwtyCuO9NMNXPWBfv+q4vYRcfW9yFA== X-Received: by 2002:a24:7688:: with SMTP id z130mr27371047itb.57.1555450934584; Tue, 16 Apr 2019 14:42:14 -0700 (PDT) Received: from titan.knownspace (173-25-245-129.client.mchsi.com. [173.25.245.129]) by smtp.gmail.com with ESMTPSA id o17sm18846012iob.62.2019.04.16.14.42.13 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 16 Apr 2019 14:42:14 -0700 (PDT) Date: Tue, 16 Apr 2019 16:42:10 -0500 From: Justin Hibbits To: Mark Millard Cc: freebsd-ppc Subject: Re: head -r344018 powerpc64 variant on Powermac G5 (2 sockets, 2 cores each): [*buffer arena] shows up more . . .? [mpc85xx_smp_timebase_sync problem too] Message-ID: <20190416164210.26827a6d@titan.knownspace> In-Reply-To: <984188AE-93A9-4321-99EC-522C2E0CE9A9@yahoo.com> References: <20190306151914.44ea831c@titan.knownspace> <8668AAF7-9E6A-4278-9D1B-2ECDBD3804AA@yahoo.com> <99AD89F8-0F90-48BE-A060-DA12FD7129E6@yahoo.com> <20190306223611.75c8a87e@titan.knownspace> <984188AE-93A9-4321-99EC-522C2E0CE9A9@yahoo.com> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; powerpc64-portbld-freebsd13.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 6EF2A8219C X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=DEziiWpX; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of chmeeedalf@gmail.com designates 2607:f8b0:4864:20::129 as permitted sender) smtp.mailfrom=chmeeedalf@gmail.com X-Spamd-Result: default: False [-6.84 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(-2.84)[ip: (-8.91), ipnet: 2607:f8b0::/32(-3.01), asn: 15169(-2.21), country: US(-0.06)]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; SUBJECT_HAS_QUESTION(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_SHORT(-0.99)[-0.990,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-ppc@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[9.2.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; RCVD_TLS_LAST(0.00)[] 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, 16 Apr 2019 21:42:16 -0000 On Tue, 16 Apr 2019 14:26:39 -0700 Mark Millard wrote: > [Looks to me like the use and content of mpc85xx_smp_timebase_sync > have the same type of problems I noted for the proposed powermac > patch.] > ... > > > > As mentioned, I had only compiled it. Your examination of the code > > path demonstrates that the patch is insufficient, and would hang at > > unleash anyway. The sleep/wake logic probably needs to be updated > > anyway. It was written for a G4 powerbook primarily for the > > PMU-based cpufreq driver, so some bits might need to be moved > > around. Orthogonal to this issue, though. > > It appears to me that the overall sequence: > > platform_smp_timebase_sync(0, 1); // called from > cpudep_ap_setup . . . > // The following are from in machdep_ap_bootstrap . . . > while (ap_letgo == 0) > __asm __volatile("or 31,31,31"); > __asm __volatile("or 6,6,6"); > . . . > platform_smp_timebase_sync(ap_timebase, 1); > > calls mpc85xx_smp_timebase_sync twice per ap and that the > 2nd call has tb_ready && mp_ncpus<=cpu_done for each such > ap, leading to a lack of coordination of the activity that > 2nd time for each ap: > > static void > mpc85xx_smp_timebase_sync(platform_t plat, u_long tb, int ap) > { > static volatile bool tb_ready; > static volatile int cpu_done; > > if (ap) { > /* APs. Hold off until we get a stable timebase. */ > while (!tb_ready) > atomic_thread_fence_seq_cst(); > mttb(tb); > atomic_add_int(&cpu_done, 1); > while (cpu_done < mp_ncpus) > atomic_thread_fence_seq_cst(); > } else { > /* BSP */ > freeze_timebase(rcpm_dev, true); > tb_ready = true; > mttb(tb); > atomic_add_int(&cpu_done, 1); > while (cpu_done < mp_ncpus) > atomic_thread_fence_seq_cst(); > freeze_timebase(rcpm_dev, false); > } > } > Not for mpc85xx. This is call is only in the AIM cpudep_ap_setup, and really shouldn't be there anyway. The original code to just set the timebase was there to set it to 0 just as a semi-sane value until the core got to a stable state. The original code was literally "mttb(0)" for G4, and a check for hypervisor with mttb(0). Had that been sufficient, the platform_smp_timebase_sync() would not be a problem to do the real sync as I had mentioned in my patch before. The powermac patch that I had provided was derived from this well-working mpc85xx patch. However, I had neglected to check that the sync wasn't used elsewhere as well. If the cpudep_ap_setup() use is removed, then this should work fine. - Justin From owner-freebsd-ppc@freebsd.org Tue Apr 16 22:36:41 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 587F1157F889 for ; Tue, 16 Apr 2019 22:36:41 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-55.consmr.mail.gq1.yahoo.com (sonic316-55.consmr.mail.gq1.yahoo.com [98.137.69.31]) (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 2F28E83664 for ; Tue, 16 Apr 2019 22:36:40 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 5VuPOWsVM1kFgy3BpDHfcjDfI9YOPYwb9hNMDa535Q50R1pNjFs6t_hWrBGPsdK WJ6HxbqFXCA_2QJZgqtuC5quO8C_TNInxdlkkw78USbJCgStcCiighZfcOgo_EgYjZS3nUwaMHki YF7CzEZd.Qz.H6jdtx4O_aEHpjXFdgMS_VsbYqcahkqVF6gvji06lm7k9Z0jaD84yLdJ0mihPYx8 O3e3xPvaCnB9lGV3SY2f6rQQtAXsB.ul7I7UPxlywHiQsZLWdnBXkoBVW27RCtycNPpfTm.IEcds cKVbgavPrQwRmMxYDvCxKT8rkxGGft8IQLqKZkbZNlFTPyiPu9wsQYpcovVAc32YWmVqqTpHTjfz dtjdEKLQsCfpDU99SRgZgiWF5KrXcCEFRDgzYUbwnrG2Z6hUR.L5CrRfzoj4xHJJS77Q4.SGfC5R rl5ex1XOaJlIemkF4De13AiuTm5mToKd5apnQi7TM4ML2MiEWLrIO025Hp_Mf.E0nYA5U.umkOUh 6ouyuLy1f7YGHFqIljJDUAzg9yzYneOkjnJ9JS3c_d38WHpFsEkftVnPz06FZ2v1P0QnnrvD6FUf rSKMMq5ew.l.p_WpGahQGEl9FWhdcTZdY9Gipa7LFmTRpFkMgkwYQgDE0U008R_tc9gg2gbes8je AkkV0sNfuilsQmFzZnKrr0AOI0uyMcrCKj..obCD4zONzrFMKpYU8zMJ2CZ6eVIKZdcDrzgpDNIe _l4thndedz2YjPIeBD_7_qhDhYOBRfziaQ2HZdCa8WKwth0XDc3dX7.rsnIAEcEfrv1cX1Asfo2a IHe4BBvLVQPaxEZjXOQwhKaXrRXB9BlVvL3wt3zHKQsnsJBGh.pzn9.eubah0xCxmqDNTDaHPhha ZSJ9_X.DsRAV4SRM2WHPOGrXDA2oIDMUEonvdzcooII312KCxdu_Q2vP5WTs5bqdzgkH2Ka4J0vU BGCiS3W4jtzfqq0_tqU82R0EE0hoOjBYIPKOc7xRLUdTiW52cabagYoA3pWSH88FNgeZZv76snlw EsWwG5J0Kt8OLnTUQaB7WcQ3EOVPVctF1apx5Ixh0jP2zRAoOyM8Aai2iYUIPFiZv6VGXHBYl18w - Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Tue, 16 Apr 2019 22:36:33 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.103]) ([76.115.7.162]) by smtp407.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID f94e9700034709e41d45d13590326b7b; Tue, 16 Apr 2019 22:36:32 +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 -r344018 powerpc64 variant on Powermac G5 (2 sockets, 2 cores each): [*buffer arena] shows up more . . .? [mpc85xx_smp_timebase_sync problem too] From: Mark Millard In-Reply-To: <20190416164210.26827a6d@titan.knownspace> Date: Tue, 16 Apr 2019 15:36:31 -0700 Cc: freebsd-ppc Content-Transfer-Encoding: quoted-printable Message-Id: <8141B858-08B0-4B88-8439-747023A98822@yahoo.com> References: <20190306151914.44ea831c@titan.knownspace> <8668AAF7-9E6A-4278-9D1B-2ECDBD3804AA@yahoo.com> <99AD89F8-0F90-48BE-A060-DA12FD7129E6@yahoo.com> <20190306223611.75c8a87e@titan.knownspace> <984188AE-93A9-4321-99EC-522C2E0CE9A9@yahoo.com> <20190416164210.26827a6d@titan.knownspace> To: Justin Hibbits X-Mailer: Apple Mail (2.3445.104.8) X-Rspamd-Queue-Id: 2F28E83664 X-Spamd-Bar: +++ X-Spamd-Result: default: False [3.76 / 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.81)[0.808,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(1.95)[ip: (8.14), ipnet: 98.137.64.0/21(0.93), asn: 36647(0.75), country: US(-0.06)]; NEURAL_SPAM_MEDIUM(0.72)[0.723,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.78)[0.784,0]; RCVD_IN_DNSWL_NONE(0.00)[31.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: Tue, 16 Apr 2019 22:36:41 -0000 [Unfortunately cpufreq_drv_set leads to additional platform_smp_timebase_sync(timebase, 0) use.] On 2019-Apr-16, at 14:42, Justin Hibbits = wrote: > On Tue, 16 Apr 2019 14:26:39 -0700 > Mark Millard wrote: >=20 >> [Looks to me like the use and content of mpc85xx_smp_timebase_sync >> have the same type of problems I noted for the proposed powermac >> patch.] >>=20 > ... >>>=20 >>> As mentioned, I had only compiled it. Your examination of the code >>> path demonstrates that the patch is insufficient, and would hang at >>> unleash anyway. The sleep/wake logic probably needs to be updated >>> anyway. It was written for a G4 powerbook primarily for the >>> PMU-based cpufreq driver, so some bits might need to be moved >>> around. Orthogonal to this issue, though. =20 >>=20 >> It appears to me that the overall sequence: >>=20 >> platform_smp_timebase_sync(0, 1); // called from >> cpudep_ap_setup . . . >> // The following are from in machdep_ap_bootstrap . . . >> while (ap_letgo =3D=3D 0) >> __asm __volatile("or 31,31,31"); >> __asm __volatile("or 6,6,6"); >> . . . >> platform_smp_timebase_sync(ap_timebase, 1); >>=20 >> calls mpc85xx_smp_timebase_sync twice per ap and that the >> 2nd call has tb_ready && mp_ncpus<=3Dcpu_done for each such >> ap, leading to a lack of coordination of the activity that >> 2nd time for each ap: >>=20 >> static void >> mpc85xx_smp_timebase_sync(platform_t plat, u_long tb, int ap) >> { >> static volatile bool tb_ready; >> static volatile int cpu_done; >>=20 >> if (ap) { >> /* APs. Hold off until we get a stable timebase. */ >> while (!tb_ready) >> atomic_thread_fence_seq_cst(); >> mttb(tb); >> atomic_add_int(&cpu_done, 1); >> while (cpu_done < mp_ncpus) >> atomic_thread_fence_seq_cst(); >> } else { >> /* BSP */ >> freeze_timebase(rcpm_dev, true); >> tb_ready =3D true; >> mttb(tb); >> atomic_add_int(&cpu_done, 1); >> while (cpu_done < mp_ncpus) >> atomic_thread_fence_seq_cst(); >> freeze_timebase(rcpm_dev, false); >> } >> } >>=20 >=20 > Not for mpc85xx. This is call is only in the AIM cpudep_ap_setup, and > really shouldn't be there anyway. Sorry for having looked in the wrong source. > The original code to just set the > timebase was there to set it to 0 just as a semi-sane value until the > core got to a stable state. The original code was literally "mttb(0)" > for G4, and a check for hypervisor with mttb(0). Had that been > sufficient, the platform_smp_timebase_sync() would not be a problem to > do the real sync as I had mentioned in my patch before. >=20 > The powermac patch that I had provided was derived from this > well-working mpc85xx patch. However, I had neglected to check that = the > sync wasn't used elsewhere as well. If the cpudep_ap_setup() use is > removed, then this should work fine. Unfortunately there is use from cpufreq_drv_set getting to cpu_sleep's platform_smp_timebase_sync use as well: /usr/src/sys/powerpc/powerpc/mp_machdep.c: = platform_smp_timebase_sync(ap_timebase, 1); /usr/src/sys/powerpc/powerpc/mp_machdep.c: = platform_smp_timebase_sync(ap_timebase, 0); /usr/src/sys/powerpc/aim/aim_machdep.c: = platform_smp_timebase_sync(timebase, 0); that last is in cpu_sleep. Tracing towards what ultimately uses = cpu_sleep . . . void powermac_sleep(platform_t platform) { *(unsigned long *)0x80 =3D 0x100; cpu_sleep(); } is used as platform_sleep. pu_mu_set_speed calls platform_sleep and is called by pmufreq_set. pmufreq_set is used as cpufreq_drv_set. At least on the PowerMac11,2, this seems to be in use for powerd if powerpd is started. It also looks like such use does not try to make the other aps track the change, just ap=3D=3D0 . That may explain much of the variability across CPUs for usefdt mode! It looks to me like the ap=3D=3D0 case in the platform_smp_timebase_sync use in cpu_sleep would not be well behaved under the patch, even for that one ap: static void powermac_smp_timebase_sync(platform_t plat, u_long tb, int ap) { + static int cpus; + static int unleash; + + if (ap) { + atomic_add_int(&cpus, 1); + while (!atomic_load_acq_int(&unleash)) + ; + } else { + atomic_add_int(&cpus, 1); + while (atomic_load_int(&cpus) !=3D mp_ncpus) + ; + atomic_store_rel_int(&unleash, 1); + } =20 mttb(tb); } The else would increment cpus beyond mp_cpus and the loop would be stuck. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-ppc@freebsd.org Wed Apr 17 00:21:07 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 9EFBE1581D66 for ; Wed, 17 Apr 2019 00:21:07 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic302-22.consmr.mail.gq1.yahoo.com (sonic302-22.consmr.mail.gq1.yahoo.com [98.137.68.148]) (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 2B5B187E3D for ; Wed, 17 Apr 2019 00:21:05 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 5lzxx.gVM1nbhgPZb21_zBGR1KKA.a4OYW6rfGKhF6tbLyoerey.ynNooQtSCOo CMCfif88fbBsAfjHi.d53ZrYAMuCJbEfU_bNlt_tpdAYGvnL4y2eiv6hxKhXgGd0iYHBarcCc6FF 3jtvMIYiIHBVfBHUs65Bk16LSxTdAvOBSVCupSSKakrRzT8WVIigYhJ2LhSAu9MUqQL0i0CgfnAB Wu4EtqVuWwuFo2Nkvl3KCGF4cApcmCiYQWB5EMwf5svybtgjMPQ_bj_Gw6Y06kIIsiPKoVxwkYcB GZVbMMuTnS1j5Xg2JmAiYsYqrALxu_uAFfrKgDci5fJiGaHQofgkxgk69iI_zKfHKxwsRDk6ffDn IWkpbccOaKFgLkv4cO_sf84XCBKmcsYiLE9TixLiF3GnIQbjbxoAhVB7Km98BYdDaWw91P1dOOgQ KXGjlmeyn9SWaDgGqx5t0o86_DSwL23k_8.PWNv7bPJ3aiaTDQNmf_k9TMXzfLj2zS16HrATLKnU X2q6fg5LMI1hD9NR1xNKFGLAimm5Nuqg03HW2USKnamOmkwcLAhlYeI.3K_Sckt.SMu0iFPm42dQ G.AOonWwRw1JstiAdqBMlyIhgg0ky.8NXJAfkFYrJUxgrcoifJYQF15xApAIxc7KTrghX3Ola1s8 E8JSVQcphTduVDrI2zDghhNtVMjmrZNhqnNTumFWmHpIkp1PkYf8gGb5Qd8YPmZZTAp0PeOWNW7z xDhIlG2.Mo.Vf9NVWx8CIWv5cG5ATt31xivr60tWy3jl_fUQJrnzvwiDkE9FLV6_JjY.ysYyDkdb jumWC7bFSfQ2hJJh3ATc4RMnSt61b.SYp9avbvWk7oAMqp0ga.6XO6zxqw4tJvkMfvoAO932GiWE LW2oRU7RIyBwBnTTnHt.Xu7nC1XCClBIbDDayGas_qcX1BRtRJuQly46h34MHi3FmPI9CaNp.qy9 VC4yxXa8gCpGFg5G8f0HWpYYYhWSc1wEerVGh0x_AQep0TQoG0M48lNGxhifld5FveNTcbctR3Xa VRzGJkJuhB4YFbzcWUGdw9W1JKQ3TMYJbrWZ766KGtEX8cBj7y708oHbeuzwblNaYj4yLlZ490Z7 .7YvsAnkQII_E6mBmD.5kvkM- Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.gq1.yahoo.com with HTTP; Wed, 17 Apr 2019 00:20:57 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.103]) ([76.115.7.162]) by smtp427.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 52c00388fd3233c48737238e1b07c9c0; Wed, 17 Apr 2019 00:20:56 +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 -r344018 powerpc64 variant on Powermac G5 (2 sockets, 2 cores each): [*buffer arena] shows up more . . .? [mpc85xx_smp_timebase_sync problem too] From: Mark Millard In-Reply-To: <8141B858-08B0-4B88-8439-747023A98822@yahoo.com> Date: Tue, 16 Apr 2019 17:20:56 -0700 Cc: freebsd-ppc Content-Transfer-Encoding: quoted-printable Message-Id: <306BC23A-3261-41BE-AB0B-4264E864DAA5@yahoo.com> References: <20190306151914.44ea831c@titan.knownspace> <8668AAF7-9E6A-4278-9D1B-2ECDBD3804AA@yahoo.com> <99AD89F8-0F90-48BE-A060-DA12FD7129E6@yahoo.com> <20190306223611.75c8a87e@titan.knownspace> <984188AE-93A9-4321-99EC-522C2E0CE9A9@yahoo.com> <20190416164210.26827a6d@titan.knownspace> <8141B858-08B0-4B88-8439-747023A98822@yahoo.com> To: Justin Hibbits X-Mailer: Apple Mail (2.3445.104.8) X-Rspamd-Queue-Id: 2B5B187E3D X-Spamd-Bar: +++ X-Spamd-Result: default: False [3.67 / 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.79)[0.788,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(1.89)[ip: (7.82), ipnet: 98.137.64.0/21(0.93), asn: 36647(0.75), country: US(-0.06)]; NEURAL_SPAM_MEDIUM(0.68)[0.685,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.82)[0.820,0]; RCVD_IN_DNSWL_NONE(0.00)[148.68.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: Wed, 17 Apr 2019 00:21:07 -0000 [Looks a little odder in the details than I initially thought: the 0 in platform_smp_timebase_sync(timebase, 0) does not mean the bsp instead of some other ap. I've still not found a reasonable way to not have the sleep-gets-stuck issue for usefdt mode.] On 2019-Apr-16, at 15:36, Mark Millard wrote: > [Unfortunately cpufreq_drv_set leads to additional > platform_smp_timebase_sync(timebase, 0) use.] >=20 > On 2019-Apr-16, at 14:42, Justin Hibbits = wrote: >=20 >> On Tue, 16 Apr 2019 14:26:39 -0700 >> Mark Millard wrote: >>=20 >>> [Looks to me like the use and content of mpc85xx_smp_timebase_sync >>> have the same type of problems I noted for the proposed powermac >>> patch.] >>>=20 >> ... >>>>=20 >>>> As mentioned, I had only compiled it. Your examination of the code >>>> path demonstrates that the patch is insufficient, and would hang at >>>> unleash anyway. The sleep/wake logic probably needs to be updated >>>> anyway. It was written for a G4 powerbook primarily for the >>>> PMU-based cpufreq driver, so some bits might need to be moved >>>> around. Orthogonal to this issue, though. =20 >>>=20 >>> It appears to me that the overall sequence: >>>=20 >>> platform_smp_timebase_sync(0, 1); // called from >>> cpudep_ap_setup . . . >>> // The following are from in machdep_ap_bootstrap . . . >>> while (ap_letgo =3D=3D 0) >>> __asm __volatile("or 31,31,31"); >>> __asm __volatile("or 6,6,6"); >>> . . . >>> platform_smp_timebase_sync(ap_timebase, 1); >>>=20 >>> calls mpc85xx_smp_timebase_sync twice per ap and that the >>> 2nd call has tb_ready && mp_ncpus<=3Dcpu_done for each such >>> ap, leading to a lack of coordination of the activity that >>> 2nd time for each ap: >>>=20 >>> static void >>> mpc85xx_smp_timebase_sync(platform_t plat, u_long tb, int ap) >>> { >>> static volatile bool tb_ready; >>> static volatile int cpu_done; >>>=20 >>> if (ap) { >>> /* APs. Hold off until we get a stable timebase. */ >>> while (!tb_ready) >>> atomic_thread_fence_seq_cst(); >>> mttb(tb); >>> atomic_add_int(&cpu_done, 1); >>> while (cpu_done < mp_ncpus) >>> atomic_thread_fence_seq_cst(); >>> } else { >>> /* BSP */ >>> freeze_timebase(rcpm_dev, true); >>> tb_ready =3D true; >>> mttb(tb); >>> atomic_add_int(&cpu_done, 1); >>> while (cpu_done < mp_ncpus) >>> atomic_thread_fence_seq_cst(); >>> freeze_timebase(rcpm_dev, false); >>> } >>> } >>>=20 >>=20 >> Not for mpc85xx. This is call is only in the AIM cpudep_ap_setup, = and >> really shouldn't be there anyway. >=20 > Sorry for having looked in the wrong source. >=20 >> The original code to just set the >> timebase was there to set it to 0 just as a semi-sane value until the >> core got to a stable state. The original code was literally = "mttb(0)" >> for G4, and a check for hypervisor with mttb(0). Had that been >> sufficient, the platform_smp_timebase_sync() would not be a problem = to >> do the real sync as I had mentioned in my patch before. >>=20 >> The powermac patch that I had provided was derived from this >> well-working mpc85xx patch. However, I had neglected to check that = the >> sync wasn't used elsewhere as well. If the cpudep_ap_setup() use is >> removed, then this should work fine. >=20 > Unfortunately there is use from cpufreq_drv_set getting to cpu_sleep's > platform_smp_timebase_sync use as well: >=20 > /usr/src/sys/powerpc/powerpc/mp_machdep.c: = platform_smp_timebase_sync(ap_timebase, 1); > /usr/src/sys/powerpc/powerpc/mp_machdep.c: = platform_smp_timebase_sync(ap_timebase, 0); > /usr/src/sys/powerpc/aim/aim_machdep.c: = platform_smp_timebase_sync(timebase, 0); >=20 > that last is in cpu_sleep. Tracing towards what ultimately uses = cpu_sleep . . . >=20 > void > powermac_sleep(platform_t platform) > { >=20 > *(unsigned long *)0x80 =3D 0x100; > cpu_sleep(); > } >=20 > is used as platform_sleep. >=20 > pu_mu_set_speed calls platform_sleep and is called by pmufreq_set. > pmufreq_set is used as cpufreq_drv_set. >=20 > At least on the PowerMac11,2, this seems to be in use for > powerd if powerpd is started. >=20 > It also looks like such use does not try to make the other aps > track the change, just ap=3D=3D0 . >=20 > That may explain much of the variability across CPUs for usefdt mode! >=20 > It looks to me like the ap=3D=3D0 case in the = platform_smp_timebase_sync > use in cpu_sleep would not be well behaved under the patch, > even for that one ap: >=20 > static void > powermac_smp_timebase_sync(platform_t plat, u_long tb, int ap) > { > + static int cpus; > + static int unleash; > + > + if (ap) { > + atomic_add_int(&cpus, 1); > + while (!atomic_load_acq_int(&unleash)) > + ; > + } else { > + atomic_add_int(&cpus, 1); > + while (atomic_load_int(&cpus) !=3D mp_ncpus) > + ; > + atomic_store_rel_int(&unleash, 1); > + } >=20 > mttb(tb); > } >=20 > The else would increment cpus beyond mp_cpus and the loop > would be stuck. cpu_sleep getting to powermac_smp_timebase_sync seems to be based on cpu_reset_handler doing the longjmp in: GET_CPUINFO(%r5) ld %r3,(PC_RESTORE)(%r5) cmpldi %cr0,%r3,0 beq %cr0,2f nop li %r4,1 bl CNAME(longjmp) nop 2: #ifdef SMP bl CNAME(machdep_ap_bootstrap) /* And away! */ nop #endif The PC_RESTORE related test is tied to: PCPU_SET(restore, &resetjb); in cpu_sleep. The usage is: if (setjmp(resetjb) =3D=3D 0) { . . . timebase =3D mftb(); . . . while (1) mtmsr(msr); } platform_smp_timebase_sync(timebase, 0); ... So it seems there is a platform_smp_timebase_sync(timebase, 0) for every cpu that gets cpu_reset_handler invoked, even the cpu's that are not the bsp. I had assumed the ", 0" meant a bsp context previously. There is: static u_quad_t timebase =3D 0; So timebase is not preserved for each cpu if more than one ends up in cpu_sleep. I'm not sure the timebase value is synchronized across cpus. (It is not volatile either. I'm not sure that the code generation would always store and load the value from memory.) Overall it looks like the ", 0" is (ambiguously) intending to indicate that the platform_smp_timebase_sync activity should be unsynchronized with other cpus. May be a distinct, alternate argument value for that that is explicitly handled? So I'm still not to a stage of having a reasonable workaround for the "sleep gets stuck" problem for usefdt mode. (Just an inappropriate avoidance-hack.) https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D233863 has investigative patches for other usefdt tied issues, patches that could be useful starting points for official updates. But the hack that I've been using to avoid stuck-sleeps is not appropriate --and so is not submitted. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-ppc@freebsd.org Wed Apr 17 02:07:10 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 8105B1583422 for ; Wed, 17 Apr 2019 02:07:10 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-3.consmr.mail.bf2.yahoo.com (sonic308-3.consmr.mail.bf2.yahoo.com [74.6.130.42]) (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 4F8B48A386 for ; Wed, 17 Apr 2019 02:07:09 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: gfyCQ4kVM1nnCax45zVhTD6TkH6on3_GFlDYDqrOYRH8cuw5B1WbpVakcBwnlZU Kkl8nXQ2E8oYfyTuq986TaiIyrs92Ss5XAA4u9pnlkgpBWgKmAHJzo66uJ3mfwG6PHVnePUUaPK0 PofbocINqiJCO8bLDkX3HOi9ibVfStWS8FDs5M9gcXbCsfnmMCimrATzQwIc0ituHEWHxhoLW34S _EwmNVmDdSyZdaj1ZOcq223fe660._s_OmIbNSdBLC3dT6FN0QvM6SMxUiWnP7b21fPjFzUW2QfY Yx6oY4WmlEN0SuVJuMISq5i4hrpOM7P3mjEDluMyqhvxcTXwbEEv9crowHzaBf0FmRy5f5.EWfMg xTlyp1mzUT47IosKezbXZQUK.yWafN8adTq6WVb_X13mmstCkFNESwmkZOuQzlWflcv43jY41ct0 eeKHrc2_rZKkM6NbSwmj.S1SPmmO7vf6OlVW8O0JC5vQPWat48qNiQkhRoWjiYCern3CBlCyfk9t NEHKqbV0uddDN0HnMW5GS6M6ukcH7EIU0gHWu7CG9pkztGPmctRrsSS9M.zg46vMO1R9L6abyJ5e TsLmmaGEa4YuBjGXtU0nfEi0mOmYW4Y.ZDe3Z638KQINkjJc6Vs_Wbbr23lAfuBmyhAPy9XCe2VC 4StOGQGFqRu0Ipf3RD4kqtgfc_xA8IQAHzCqf7gBKrxVvVffRAQBCZRr9TRJszUfNrgq20B8TetG 6OYuAWaNYuiJHcbMGAW6.uc5mBGlKFbnQfPUuLzdrzpOhNLmZ1tBNZEAafDO8r6u9XCzci2cTUHC A2k9QK_29T5uJe.SMvNBaC8n5BV.qex3geySHq7c5DWjBxREESpLDTa08xx7KjKIfRIv5fG4Whr5 fK3FsT5toNhwLFmpmK.rCVRoQn.9qWSj7JC26dkiIXdA6L_eoTpCrRjlWchGmi2QHU.cyl01v96u .k3jEXJtbPAknG3vywaGJlsB4nplg9uC_lOop8KJXLgfE01LpM112ZmdarXW7fWF7tbYXjXuBMX6 sLUVsu0nwsBY9dC4lsWXedR60JJgQboOQz2xX3c2f6IrizOPBGhMCH3.eXQiSeW374fBpOlLnumC t4hiFMqtq_seA3mHP_DlToEud2A-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.bf2.yahoo.com with HTTP; Wed, 17 Apr 2019 02:07:03 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.103]) ([76.115.7.162]) by smtp432.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 02be651f3c2f2bcf7b4c536d12630005; Wed, 17 Apr 2019 02:07: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 -r344018 powerpc64 variant on Powermac G5 (2 sockets, 2 cores each): [*buffer arena] shows up more . . .? [mpc85xx_smp_timebase_sync problem too] From: Mark Millard In-Reply-To: <306BC23A-3261-41BE-AB0B-4264E864DAA5@yahoo.com> Date: Tue, 16 Apr 2019 19:06:59 -0700 Cc: freebsd-ppc Content-Transfer-Encoding: quoted-printable Message-Id: <0CC10B05-F0FD-483C-911D-20F5AC2DB427@yahoo.com> References: <20190306151914.44ea831c@titan.knownspace> <8668AAF7-9E6A-4278-9D1B-2ECDBD3804AA@yahoo.com> <99AD89F8-0F90-48BE-A060-DA12FD7129E6@yahoo.com> <20190306223611.75c8a87e@titan.knownspace> <984188AE-93A9-4321-99EC-522C2E0CE9A9@yahoo.com> <20190416164210.26827a6d@titan.knownspace> <8141B858-08B0-4B88-8439-747023A98822@yahoo.com> <306BC23A-3261-41BE-AB0B-4264E864DAA5@yahoo.com> To: Justin Hibbits X-Mailer: Apple Mail (2.3445.104.8) X-Rspamd-Queue-Id: 4F8B48A386 X-Spamd-Bar: ++ X-Spamd-Result: default: False [2.92 / 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:26101, ipnet:74.6.128.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.80)[0.805,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(1.43)[ip: (4.34), ipnet: 74.6.128.0/21(1.59), asn: 26101(1.27), country: US(-0.06)]; NEURAL_SPAM_MEDIUM(0.53)[0.526,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.67)[0.672,0]; RCVD_IN_DNSWL_NONE(0.00)[42.130.6.74.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: Wed, 17 Apr 2019 02:07:10 -0000 [Experiments produced an unexpected result, from what I can tell. I note them.] On 2019-Apr-16, at 17:20, Mark Millard wrote: > [Looks a little odder in the details than I initially thought: the > 0 in platform_smp_timebase_sync(timebase, 0) does not mean the bsp > instead of some other ap. I've still not found a reasonable way > to not have the sleep-gets-stuck issue for usefdt mode.] >=20 > On 2019-Apr-16, at 15:36, Mark Millard wrote: >=20 >> [Unfortunately cpufreq_drv_set leads to additional >> platform_smp_timebase_sync(timebase, 0) use.] >>=20 >> On 2019-Apr-16, at 14:42, Justin Hibbits = wrote: >>=20 >>> On Tue, 16 Apr 2019 14:26:39 -0700 >>> Mark Millard wrote: >>>=20 >>>> [Looks to me like the use and content of mpc85xx_smp_timebase_sync >>>> have the same type of problems I noted for the proposed powermac >>>> patch.] >>>>=20 >>> ... >>>>>=20 >>>>> As mentioned, I had only compiled it. Your examination of the = code >>>>> path demonstrates that the patch is insufficient, and would hang = at >>>>> unleash anyway. The sleep/wake logic probably needs to be updated >>>>> anyway. It was written for a G4 powerbook primarily for the >>>>> PMU-based cpufreq driver, so some bits might need to be moved >>>>> around. Orthogonal to this issue, though. =20 >>>>=20 >>>> It appears to me that the overall sequence: >>>>=20 >>>> platform_smp_timebase_sync(0, 1); // called from >>>> cpudep_ap_setup . . . >>>> // The following are from in machdep_ap_bootstrap . . . >>>> while (ap_letgo =3D=3D 0) >>>> __asm __volatile("or 31,31,31"); >>>> __asm __volatile("or 6,6,6"); >>>> . . . >>>> platform_smp_timebase_sync(ap_timebase, 1); >>>>=20 >>>> calls mpc85xx_smp_timebase_sync twice per ap and that the >>>> 2nd call has tb_ready && mp_ncpus<=3Dcpu_done for each such >>>> ap, leading to a lack of coordination of the activity that >>>> 2nd time for each ap: >>>>=20 >>>> static void >>>> mpc85xx_smp_timebase_sync(platform_t plat, u_long tb, int ap) >>>> { >>>> static volatile bool tb_ready; >>>> static volatile int cpu_done; >>>>=20 >>>> if (ap) { >>>> /* APs. Hold off until we get a stable timebase. */ >>>> while (!tb_ready) >>>> atomic_thread_fence_seq_cst(); >>>> mttb(tb); >>>> atomic_add_int(&cpu_done, 1); >>>> while (cpu_done < mp_ncpus) >>>> atomic_thread_fence_seq_cst(); >>>> } else { >>>> /* BSP */ >>>> freeze_timebase(rcpm_dev, true); >>>> tb_ready =3D true; >>>> mttb(tb); >>>> atomic_add_int(&cpu_done, 1); >>>> while (cpu_done < mp_ncpus) >>>> atomic_thread_fence_seq_cst(); >>>> freeze_timebase(rcpm_dev, false); >>>> } >>>> } >>>>=20 >>>=20 >>> Not for mpc85xx. This is call is only in the AIM cpudep_ap_setup, = and >>> really shouldn't be there anyway. >>=20 >> Sorry for having looked in the wrong source. >>=20 >>> The original code to just set the >>> timebase was there to set it to 0 just as a semi-sane value until = the >>> core got to a stable state. The original code was literally = "mttb(0)" >>> for G4, and a check for hypervisor with mttb(0). Had that been >>> sufficient, the platform_smp_timebase_sync() would not be a problem = to >>> do the real sync as I had mentioned in my patch before. >>>=20 >>> The powermac patch that I had provided was derived from this >>> well-working mpc85xx patch. However, I had neglected to check that = the >>> sync wasn't used elsewhere as well. If the cpudep_ap_setup() use is >>> removed, then this should work fine. Not with your patch, just the original code, I tried removing the platform_smp_timebase_sync(0, 1) in cpudep_ap_setup . The consequence was that the variability in time across cpus got much worse (wider range of times). The scale on which my hack had been calibrated was not nearly sufficient to prevent there being lots of stuck-sleeping. (I did not try to see if recalibrating the range it spans would make things work again.) I experimented with powerpd vs. lack of it under these conditions, and its cpufreq activity seem to sometimes limit the variability, rather than making it worse. (It was not sufficient to make things reasonable.) I've put back the platform_smp_timebase_sync(0, 1) in cpudep_ap_setup for now. With that, my hack and its old caliberation again makes things work without stuck-sleeping problems. It almost makes me wonder if the mttb(0) that it causes is needed to reach a usable tb status for setting other values later. That might partially explain the comment: /* The following is needed for restoring from sleep. */ platform_smp_timebase_sync(0, 1); It reads like it was observed at some point to be important to the operation. >> Unfortunately there is use from cpufreq_drv_set getting to = cpu_sleep's >> platform_smp_timebase_sync use as well: >>=20 >> /usr/src/sys/powerpc/powerpc/mp_machdep.c: = platform_smp_timebase_sync(ap_timebase, 1); >> /usr/src/sys/powerpc/powerpc/mp_machdep.c: = platform_smp_timebase_sync(ap_timebase, 0); >> /usr/src/sys/powerpc/aim/aim_machdep.c: = platform_smp_timebase_sync(timebase, 0); >>=20 >> that last is in cpu_sleep. Tracing towards what ultimately uses = cpu_sleep . . . >>=20 >> void >> powermac_sleep(platform_t platform) >> { >>=20 >> *(unsigned long *)0x80 =3D 0x100; >> cpu_sleep(); >> } >>=20 >> is used as platform_sleep. >>=20 >> pu_mu_set_speed calls platform_sleep and is called by pmufreq_set. >> pmufreq_set is used as cpufreq_drv_set. >>=20 >> At least on the PowerMac11,2, this seems to be in use for >> powerd if powerpd is started. >>=20 >> It also looks like such use does not try to make the other aps >> track the change, just ap=3D=3D0 . >>=20 >> That may explain much of the variability across CPUs for usefdt mode! >>=20 >> It looks to me like the ap=3D=3D0 case in the = platform_smp_timebase_sync >> use in cpu_sleep would not be well behaved under the patch, >> even for that one ap: >>=20 >> static void >> powermac_smp_timebase_sync(platform_t plat, u_long tb, int ap) >> { >> + static int cpus; >> + static int unleash; >> + >> + if (ap) { >> + atomic_add_int(&cpus, 1); >> + while (!atomic_load_acq_int(&unleash)) >> + ; >> + } else { >> + atomic_add_int(&cpus, 1); >> + while (atomic_load_int(&cpus) !=3D mp_ncpus) >> + ; >> + atomic_store_rel_int(&unleash, 1); >> + } >>=20 >> mttb(tb); >> } >>=20 >> The else would increment cpus beyond mp_cpus and the loop >> would be stuck. >=20 > cpu_sleep getting to powermac_smp_timebase_sync seems to be based > on cpu_reset_handler doing the longjmp in: >=20 > GET_CPUINFO(%r5) > ld %r3,(PC_RESTORE)(%r5) > cmpldi %cr0,%r3,0 > beq %cr0,2f > nop > li %r4,1 > bl CNAME(longjmp) > nop > 2: > #ifdef SMP > bl CNAME(machdep_ap_bootstrap) /* And away! */ > nop > #endif >=20 > The PC_RESTORE related test is tied to: >=20 > PCPU_SET(restore, &resetjb); >=20 > in cpu_sleep. The usage is: >=20 > if (setjmp(resetjb) =3D=3D 0) { > . . . > timebase =3D mftb(); > . . . > while (1) > mtmsr(msr); > } > platform_smp_timebase_sync(timebase, 0); > ... >=20 > So it seems there is a platform_smp_timebase_sync(timebase, 0) > for every cpu that gets cpu_reset_handler invoked, even the > cpu's that are not the bsp. >=20 > I had assumed the ", 0" meant a bsp context previously. >=20 > There is: >=20 > static u_quad_t timebase =3D 0; >=20 > So timebase is not preserved for each cpu if more than > one ends up in cpu_sleep. I'm not sure the timebase value > is synchronized across cpus. (It is not volatile either. > I'm not sure that the code generation would always > store and load the value from memory.) >=20 > Overall it looks like the ", 0" is (ambiguously) intending to > indicate that the platform_smp_timebase_sync activity should > be unsynchronized with other cpus. May be a distinct, alternate > argument value for that that is explicitly handled? >=20 >=20 >=20 > So I'm still not to a stage of having a reasonable workaround > for the "sleep gets stuck" problem for usefdt mode. (Just an > inappropriate avoidance-hack.) >=20 > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D233863 has > investigative patches for other usefdt tied issues, patches > that could be useful starting points for official updates. > But the hack that I've been using to avoid stuck-sleeps is > not appropriate --and so is not submitted. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-ppc@freebsd.org Wed Apr 17 14:41:08 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 D48B9156DE69 for ; Wed, 17 Apr 2019 14:41:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 717CA82562 for ; Wed, 17 Apr 2019 14:41:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by freefall.freebsd.org (Postfix) id 5C364107B2; Wed, 17 Apr 2019 14:41:07 +0000 (UTC) Delivered-To: powerpc@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [96.47.72.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id 55B67107B1 for ; Wed, 17 Apr 2019 14:41:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0367A8255E for ; Wed, 17 Apr 2019 14:41:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 489E81F222 for ; Wed, 17 Apr 2019 14:41:06 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x3HEf6mJ032283 for ; Wed, 17 Apr 2019 14:41:06 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x3HEf6H7032282 for powerpc@FreeBSD.org; Wed, 17 Apr 2019 14:41:06 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: powerpc@FreeBSD.org Subject: [Bug 237208] java/openjdk11: port to powerpc64 Date: Wed, 17 Apr 2019 14:41:06 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: gustavo.romero@protonmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: java@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-Rspamd-Queue-Id: 717CA82562 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.98 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.978,0]; ASN(0.00)[asn:11403, ipnet:96.47.64.0/20, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,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: Wed, 17 Apr 2019 14:41:08 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D237208 --- Comment #9 from Gustavo Romero --- (In reply to Piotr Kubaj from comment #4) Hi Piotr and Mikael, Is the SIGILL JVM crash still happening? Piotr, the illegal instruction executed in the arraycopy stubs looks to be a 'mtdscr', i.e. an instruction used to adjust the depth of the data prefetch prior to the bulk copy. However I can't make sense of that yet because availability of m{t,f}dscr is proved at runtime before the emission by the compiler. Logs show that m{t,f}dscr is not available indeed:=20 CPU:total 16 (initial active 16) ppc64 fsqrt isel lxarxeh cmpb popcntb popc= ntw fcfids vand lqarx aes vpmsumb mfdscr vsx ldbrx stdbrx sha darn That JVM on POWER9 reports it has VSX and DARN support but not DSCR? The instruction that caused the crash in question is also using DSCR SPR number= 3, which is not privileged either. Does: int main() { asm("mtspr 3, 0;"); } crashes with a SIGILL? --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-ppc@freebsd.org Wed Apr 17 14:57:45 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 E6452156E474 for ; Wed, 17 Apr 2019 14:57:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 870BF82E80 for ; Wed, 17 Apr 2019 14:57:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by freefall.freebsd.org (Postfix) id 5DB9710B8A; Wed, 17 Apr 2019 14:57:44 +0000 (UTC) Delivered-To: powerpc@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [96.47.72.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id 5633C10B88 for ; Wed, 17 Apr 2019 14:57:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DE11B82E7B for ; Wed, 17 Apr 2019 14:57:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 1E3991F4F2 for ; Wed, 17 Apr 2019 14:57:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x3HEvgkn068504 for ; Wed, 17 Apr 2019 14:57:42 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x3HEvguE068503 for powerpc@FreeBSD.org; Wed, 17 Apr 2019 14:57:42 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: powerpc@FreeBSD.org Subject: [Bug 237208] java/openjdk11: port to powerpc64 Date: Wed, 17 Apr 2019 14:57:43 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: gustavo.romero@protonmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: java@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-Rspamd-Queue-Id: 870BF82E80 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.98 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.977,0]; ASN(0.00)[asn:11403, ipnet:96.47.64.0/20, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,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: Wed, 17 Apr 2019 14:57:45 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D237208 --- Comment #10 from Gustavo Romero --- (In reply to Gustavo Romero from comment #9) Logs show that m{t,f}dscr is not available indeed:=20 CPU:total 16 (initial active 16) ppc64 fsqrt isel lxarxeh cmpb popcntb popc= ntw fcfids vand lqarx aes vpmsumb mfdscr vsx ldbrx stdbrx sha darn Sorry, mfdscr IS available. I'm blind... heh Still odd tho. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-ppc@freebsd.org Wed Apr 17 20:17:53 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 C78021578598 for ; Wed, 17 Apr 2019 20:17:53 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-21.consmr.mail.gq1.yahoo.com (sonic310-21.consmr.mail.gq1.yahoo.com [98.137.69.147]) (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 9CD4391D4F for ; Wed, 17 Apr 2019 20:17:52 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 72lzrCAVM1nMOvs1I7r1FZTQtgUOlzIKyikRFMRunGQ90xF97r1ZQI6jWNpYMsV UkQqT0bk0qCpi9IYO_ML0SAlamWpCoLMv1LaEBtW6a9AMYDhVgSsAUZv25spSrD7CyXMjFTev0Ck kR1BhnUb3TzdEw.UfNmgGzriploMtsJHGW63vxRRWE1hD3Va6ID9l6wH6Vs286NK4eB8mtmgJw.F JyYk.OATGdKTkbbIEarz9ld4cfqYAt4UDoi9qmpxPkUFe7yN0Z7WmN8hKrJmABXflt3G7jM0QJ8j lBg1d5.hBwiVzCBMJwxsMgmlnNoinDnY.WIeK4K6qa9XOTeC3FxoHr5DF2xsujTOOKZ76qAZrcOK WYGz3SeZ1yQCYytg32HYSOZYaux__5OdwkrhGzIJSKqgjOm57.Lkcp0smxorNH4jT3KhOwnT3rli K7iMJY1ow4BKpVj4b8IKvkQ5tnAjqatL0cPLmLHe3YXSg1zuuvgRuCITe5dtkpVwULgpppQ.mz8h VzKgYUdvaCnoaCRTkANxdnIGjhDD6.R23CEFfH3whLo4zaCNNBXEp4n7n7ReP9M7_.QajXjOSdQq Hfiypzi5Tjx67Bw5wJnzrFH7xx2skA0St9dEx8wYLBf3RytOfdTQ.YDfBN1slEzgWRvWJB7DSuPX HXOo7y051XVzaG2.2n_DDtDoJ9JwYhuMkSAsyQa9ZuhYUV2BvkRcbWgYdhGa2ETkW4HRiNjJld6M JRskKZvHmR9wiMMOybOSLHxlZgdLcA.sOyBfpjSou0csgydsu2269.p7Lax7VLtzMQBX0FYaWWTz AuA9oYQFve9_4IHX9JzC0u5XpILGRC9pzMOeqZZGB8Vq0CwyMVasmssvcNEWE9SG7X511EBSL8eP i0ivjKq5kEq93IXA51mk5_XOZI6IJshDzqmt0WiFm0tyVBXkAIv9LoIaMJdPX.ksilRHT25jEH94 4FQG5qmxOhHkoa6Vi9HM5fdUPN8bywHX75R0FzD_CVDe_VVmyrhQUFgWiep2JJ7jclDgc1AoNmNx Qs_1jAaWO1dqLZbnx7JyIbaCh1Dh1QPrwoD4OGsOsfFH6Ka7ZQUY5sQbT5KCCwL2w4t3.5t9M9Q- - Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Wed, 17 Apr 2019 20:17:44 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.103]) ([76.115.7.162]) by smtp425.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 96dbaab0920c7e42b9cb7a2c7fef1910; Wed, 17 Apr 2019 20:17:40 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Subject: powerpc64 and 32-bit FreeBSD, powerpc mttb(time) use vs. interrupts: should interrupts be disabled around the 3 mtspr's? Message-Id: <1202CA56-C1A7-441C-9854-F5790C8F9D7B@yahoo.com> Date: Wed, 17 Apr 2019 13:17:39 -0700 To: FreeBSD PowerPC ML , Justin Hibbits X-Mailer: Apple Mail (2.3445.104.8) X-Rspamd-Queue-Id: 9CD4391D4F X-Spamd-Bar: ++ X-Spamd-Result: default: False [2.68 / 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]; NEURAL_HAM_SHORT(-0.35)[-0.353,0]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(1.05)[ip: (3.62), ipnet: 98.137.64.0/21(0.93), asn: 36647(0.74), country: US(-0.06)]; SUBJECT_ENDS_QUESTION(1.00)[]; 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)[]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; NEURAL_SPAM_MEDIUM(0.57)[0.570,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.92)[0.924,0]; RCVD_IN_DNSWL_NONE(0.00)[147.69.137.98.list.dnswl.org : 127.0.5.0]; RCVD_TLS_LAST(0.00)[] 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: Wed, 17 Apr 2019 20:17:54 -0000 For: static __inline void mttb(u_quad_t time) { mtspr(TBR_TBWL, 0); mtspr(TBR_TBWU, (uint32_t)(time >> 32)); mtspr(TBR_TBWL, (uint32_t)(time & 0xffffffff)); } an example use of the powerpc code is: li r3,0 rldicl r5,r4,32,32 mttbl r3 mttbu r5 mttbl r4 blr Nothing about this prevents interrupts between powermac_smp_timebase_sync+0x8 and powermac_smp_timebase_sync+0xc or between powermac_smp_timebase_sync+0xc and powermac_smp_timebase_sync+0x8=10 . The code sequence is not atomic for the time base assignment. Should mttb be something more like: static __inline void mttb(u_quad_t time) { const uint32_t high= time>>32; const uint32_t low= time&0xffffffffu; const register_t predisable_msr= intr_disable(); mtspr(TBR_TBWL, 0); mtspr(TBR_TBWU, high); mtspr(TBR_TBWL, low); intr_restore(predisable_msr); } Or is the mttb usage guaranteed to only be in contexts without any interrupts? === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-ppc@freebsd.org Wed Apr 17 23:18:15 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 EC841157C4B4 for ; Wed, 17 Apr 2019 23:18:14 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-22.consmr.mail.gq1.yahoo.com (sonic301-22.consmr.mail.gq1.yahoo.com [98.137.64.148]) (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 8F61997EA4 for ; Wed, 17 Apr 2019 23:18:13 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: brRvIaAVM1mwrEFUuNV0kLY86eADCjMvb1MfHj70TCF30lBQJMBqRheGtj4Q_do Y53C3gss.3XqNDJSxHAfk9rmBrImjBG08wSB1xHmoeUFT4Cd7g_2vempUwxJx2guoh9nZ_OTnfRU CuYwzs1vuuksi_C7Dp7WOSmi0ARIVoDexUry1q_tFoFAxCIg1YMdl1LslCpCrMwXiZJf_s7iA3PP 3oNSvhLz46YF8n6_h5DCxjrBFbfxt6tO_NBhgR81n1YkiY.EvdT6VADrfealaccDogM6k1kuc9_E MgBLbjKwPTkcaIJQeRExgqkyBRa2Vvc3jUpyAsI7NqIHEU39wTobxqsBYApgSkNuEi.gL4F5YT.j HSULw79Q75Kkhu2Bf8.IiY.etYZ0OsRtH6jyFOQj97rWk96w4JVg6eP7j3xgRZbG3qnzGTe5PFA5 Eg5fYyjhumSlX51jpu2SsUD6W3bLI.bCVc_7MIOihxXtVRB1bzXvZrUatu6wlbQId4HIEcqJeEuT N5FpqpNSvllTSDKEjJ5TDJRMSpMY_cIuqzgyDz_q3dY6TmMNJrUSNAM4YV6xVz3gOFZP3Kd.soa5 5GI4eaz7qoX7gfSCv._qyFN.t3Q52eNZSRLejj.Kn_nVDi8vYIsv4F7y0gJCYunR8NgznJkNd6Y_ T5BC2tdHJe.l.lRrnuG7WirIGYxg.9JiEJ.OoHqz2297wuE6TQXvs6Xo1owMimmy.c6uRmStKUcT 6KweJf1iEwdxWqCM0BuZmCE6N9XnLj.Z8X5TTyvubEfANLFd5o8ANkYdbUobbmkVpX2k9ElQusYm Rf_HeUu7hdLhew7ZChXVSKuGj_I5UV1KbXCr3I.eJwGAhFbk0OFKQra8J59nhMyZwKBaNshuBZEM I3RZ_o0pnPTG7JU1taNb_PHJwWjrX0cTB.R1DxS0i_ZY2esbOXDXVrHNpZMK1JAPJjqMMl2SgoNY c_8DC3XIZDZAMnrz9FUqr7ow1IssW.FR1RvwZ_ZluboaBbxdocqi2q71Lh1Q.oNFjvv0TdO8myYo D0VlC8u0i8SPsJMxOriogObb609ExmVN4Zh5pLqTvtf2jiD4_qplkJ0y66A-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Wed, 17 Apr 2019 23:18:04 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.103]) ([76.115.7.162]) by smtp419.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 65f501aa283e099c1d549634cb89d9f7 for ; Wed, 17 Apr 2019 23:18:04 +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: 32-bit powerpc vs. 64-bit FreeBDS powermac_smp_timebase_sync and mttb: sets upper part to zero vs. not Message-Id: Date: Wed, 17 Apr 2019 16:18:03 -0700 To: FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3445.104.8) X-Rspamd-Queue-Id: 8F61997EA4 X-Spamd-Bar: +++ X-Spamd-Result: default: False [3.54 / 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]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; 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)[]; 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)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.75)[0.754,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-ppc@freebsd.org]; NEURAL_SPAM_MEDIUM(0.80)[0.797,0]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(1.63)[ip: (6.55), ipnet: 98.137.64.0/21(0.93), asn: 36647(0.74), country: US(-0.06)]; NEURAL_SPAM_LONG(0.86)[0.863,0]; RCVD_IN_DNSWL_NONE(0.00)[148.64.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: Wed, 17 Apr 2019 23:18:15 -0000 [In exploring why there is the time problems that lead to sleep-gets-stuck, I ran into the below. It seems odd but I've not found it tied to the failures.] Both 32-bit and 64-bit PowerPC have a 64-bit Time Base Register. But how it is used is an odd mix above mttb(time) for how the TBR register is set for 32-bit powerpc vs. powerpc64 FreeBSD. (32-bit FreeBSD runs on some powerpc64 hardware, as well.) 32-bit powerpc FreeBSD uses types u_long and u_int in some places, both 32-bits in that context: typedef u_int timecounter_get_t(struct timecounter *) powermac_smp_timebase_sync(platform_t plat, u_long tb, int ap) That last even leads to the high 32-bits bits being set to zero explicitly. (Shown later.) 64-bit powerpc does not do that last part: u_long is 64-bits 64-bit powerpc does truncate for timecounter_get_t: u_int is 32 bits for powerpc64. The code: static __inline void mttb(u_quad_t time) { mtspr(TBR_TBWL, 0); mtspr(TBR_TBWU, (uint32_t)(time >> 32)); mtspr(TBR_TBWL, (uint32_t)(time & 0xffffffff)); } is used in powermac_smp_timebase_sync (which is bound to platform_smp_timebase_sync for the context): static void powermac_smp_timebase_sync(platform_t plat, u_long tb, int ap) { =20 mttb(tb); } 32-bit powerpc: necessarily (time >> 32) =3D=3D 0u because of the = "u_long tb". 64-bit powerpc: not necessarily, u_long tb holds 64 bits. The details for 32-bit powerpc FreeBSD are: stwu r1,-32(r1) stw r31,24(r1) mr r31,r1 li r0,0 mtsprg 4,r0 li r9,0 mtsprg 5,r9 mtsprg 4,r4 lwz r11,0(r1) lwz r31,-8(r11) mr r1,r11 blr which sets the upper 32 bits of the tbr to zero via "mtsprg 5,r9", where previously "li r9,0". But some parts of the code are u_quad_t based, with platform_smp_timebase_sync use implicitly truncating: (Note: mftb returns u_quad_t but timecounter_get_t based access is truncated.) volatile static u_quad_t ap_timebase; . . . platform_smp_timebase_sync(ap_timebase, 1); SO: truncated on = 32-bit powerpc FreeBSD only . . . ap_timebase =3D mftb() + 10; SO: not truncating here. . . . platform_smp_timebase_sync(ap_timebase, 0); SO: 32-bit powerpc = FreeBSD only: truncating static u_quad_t timebase =3D 0; . . . timebase =3D mftb(); SO: not truncating here. . . . platform_smp_timebase_sync(timebase, 0); SO: 32-bit powerpc = FreeBSD only: truncating u_quad_t tb, ttb; NOTE: The code below is = never-32-bit-truncating. . . . tb =3D mftb(); ttb =3D tb + howmany((uint64_t)n * 1000000, ps_per_tick); while (tb < ttb) tb =3D mftb(); I'm unclear on why ap_timebase and timebase above are u_quad_t instead of u_long, given the intended use with platform_smp_timebase_sync . Debugging ability to see more? Note: there is a: /usr/src/sys/powerpc/aim/mp_cpudep.c: platform_smp_timebase_sync(0, = 1); but for both 32-bit powerpc FreeBSD and powerpc64 FreeBSD that sets the TBR to zero for all 64 bits. (Removal of this on at least 32-bit powerpc FreeBSD causes problems with wider TBR disagreements across cpus.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-ppc@freebsd.org Thu Apr 18 06:52:46 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 A9E0C1589CC6 for ; Thu, 18 Apr 2019 06:52:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4AA14811D3 for ; Thu, 18 Apr 2019 06:52:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by freefall.freebsd.org (Postfix) id 3C54B125A; Thu, 18 Apr 2019 06:52:46 +0000 (UTC) Delivered-To: powerpc@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [96.47.72.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id 38E001259 for ; Thu, 18 Apr 2019 06:52:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D8E32811D2 for ; Thu, 18 Apr 2019 06:52:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 20E3F818A for ; Thu, 18 Apr 2019 06:52:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x3I6qiHB029379 for ; Thu, 18 Apr 2019 06:52:44 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x3I6qioi029376 for powerpc@FreeBSD.org; Thu, 18 Apr 2019 06:52:44 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: powerpc@FreeBSD.org Subject: [Bug 237208] java/openjdk11: port to powerpc64 Date: Thu, 18 Apr 2019 06:52:44 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: pkubaj@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: java@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-Rspamd-Queue-Id: 4AA14811D3 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.98 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.981,0]; ASN(0.00)[asn:11403, ipnet:96.47.64.0/20, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,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: Thu, 18 Apr 2019 06:52:46 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D237208 --- Comment #11 from Piotr Kubaj --- (In reply to Gustavo Romero from comment #10) Looks ok. root@talos:$~$ cat test.c int main() { asm("mtspr 3, 0;"); } root@talos:$~$ cc test.c root@talos:$~$ ./a.out root@talos:$~$ echo $? 1 --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-ppc@freebsd.org Thu Apr 18 21:42:21 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 2B574157D39B for ; Thu, 18 Apr 2019 21:42:21 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B90B4823A6 for ; Thu, 18 Apr 2019 21:42:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by freefall.freebsd.org (Postfix) id AACD8EA91; Thu, 18 Apr 2019 21:42:20 +0000 (UTC) Delivered-To: powerpc@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [96.47.72.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id A6DD1EA90 for ; Thu, 18 Apr 2019 21:42:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6CEDC823A1 for ; Thu, 18 Apr 2019 21:42:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id C13E5102E0 for ; Thu, 18 Apr 2019 21:42:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x3ILgJjk040925 for ; Thu, 18 Apr 2019 21:42:19 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x3ILgJbq040924 for powerpc@FreeBSD.org; Thu, 18 Apr 2019 21:42:19 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: powerpc@FreeBSD.org Subject: [Bug 237370] java/openjdk12: port to powerpc64 Date: Thu, 18 Apr 2019 21:42:17 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: hamiltcl@verizon.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: java@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter cc flagtypes.name attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-Rspamd-Queue-Id: B90B4823A6 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.98 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.979,0]; ASN(0.00)[asn:11403, ipnet:96.47.64.0/20, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,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: Thu, 18 Apr 2019 21:42:21 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D237370 Bug ID: 237370 Summary: java/openjdk12: port to powerpc64 Product: Ports & Packages Version: Latest Hardware: powerpc OS: Any Status: New Severity: Affects Some People Priority: --- Component: Individual Port(s) Assignee: java@FreeBSD.org Reporter: hamiltcl@verizon.net CC: powerpc@FreeBSD.org Assignee: java@FreeBSD.org CC: powerpc@FreeBSD.org Flags: maintainer-feedback?(java@FreeBSD.org) Created attachment 203773 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D203773&action= =3Dedit Patch to add powerpc64 support Adds powerpc64 support.=20=20 Uses bootstrap provided by https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D237208 --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-ppc@freebsd.org Fri Apr 19 04:36:31 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 DBCFA1585169 for ; Fri, 19 Apr 2019 04:36:30 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-8.consmr.mail.gq1.yahoo.com (sonic308-8.consmr.mail.gq1.yahoo.com [98.137.68.32]) (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 84C988D65D for ; Fri, 19 Apr 2019 04:36:29 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: zifi6gMVM1maUKrXsjrazmqUDrou5z2vRtV7EQuyIMLvYXmqCPKykO6i11jAByj mFTo9VwqsmxbBS7vxcr33WTGlxP3J7xXOVEWlEQMXITRudWlyV_04qBa0feY.fBgn3rk27lImQcv YgVQqngEwkN2jeHwIp.V937XqSN9dRKAvw2UQ59fUgp5ssCdE0q7fxp33DmjVjgZpbL0BgV66.7C KznQ6FrQjBhBdpA1tutj4_wKYOQKnN3GRlNeHJl7a93LUEPw1_v2x21.0FMxvqYd0ocpxf0dx8m8 vw.OkUt1qRYl5KqSG8betcNMyDBZO4KfFxgbeD4bHNwoXA3fGp16FUgc8s0fBuRMgtb6XSGI_qjN 1b3BHq.M5AV.tEcXZ5kgRnpv08fRKkfDkPfA1HoBcjmoYNtpqKJNDEQYqvCCF9ui.TZLY4F8RDwX _MxuBC1ROihnwo4Aczr06WlfAP46vEh7Z37SvVbG2nHhcP8NSElQcWh9_q_3js.z3vtVr8JOTD3r APuzNwY6kytxXCup6cHJuri.gGRuPK3ehTLFToLn.QMHKw5YN4rRSEMk3X9EAH.87BJQS_hi9P7P bhfwek6EhwZjJLSQ7tFKm6tm_LeyO.pAU2yS6M8.HJPDExkcEF3zRCbuxvE7ey0muh7FeG1GZNoj t9Sh3_B3DdigsfaStvTlFNTg_DRIOf5WilcYH_n_oI0G5rHrPLOsfdcx67RZHHQ7xQpysnzoFeSR 2u6kGkk9GLoQexA4tjEKKTkym.7WL5ahIcQN.6VwjgSsLVbJGEIusYmzTDauNrWdJXuGYLQnBh1Y ZUkQ_KXm.H2qTSE9Zho4P23uK3EzV7h7tDNRrDrT4pfS2McTEHoehIGKMiczVFLvYtpnIRnybjfs xvA.gIxA2jMsO4DfyeILaGDjSZ9SSKOcmINMFPLbl9DSWvKdbudnNasZG9whV_6Z6eZvF_9vME_g QRkxIdHTlF88X2.MQPTkWmbEBy.Ql9u.6FwGSle0arqpWFMOsbeNVO7QxQFs3VMmPV3nTuYI3gzQ 4FK6CamSjLHK3AVIicx6DM72XVKLE7zSC.fRNEe3Bke67rzFVAxZWbTJFGUln6hSoP7_3vP0COPk mO7tFef8t5DXya.F4g_YbizkPUZfPFFob Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Fri, 19 Apr 2019 04:36:22 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.103]) ([76.115.7.162]) by smtp412.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID cb8240f959e44ad1296b1c03198b64c7; Fri, 19 Apr 2019 04:36:20 +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: powerpc64 or 32-bit power context: FreeBSD lwsync use vs. th->th_generation handling (and related th-> fields) looks broken to me Message-Id: <50CFD7F1-6892-4375-967B-4713517C2520@yahoo.com> Date: Thu, 18 Apr 2019 21:36:19 -0700 Cc: Bruce Evans , Konstantin Belousov To: FreeBSD PowerPC ML , freebsd-hackers Hackers X-Mailer: Apple Mail (2.3445.104.8) X-Rspamd-Queue-Id: 84C988D65D X-Spamd-Bar: + X-Spamd-Result: default: False [1.59 / 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]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; 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)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_SPAM_SHORT(0.97)[0.972,0]; NEURAL_HAM_LONG(-0.31)[-0.314,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; NEURAL_SPAM_MEDIUM(0.42)[0.415,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[32.68.137.98.list.dnswl.org : 127.0.5.0]; IP_SCORE(1.03)[ip: (3.52), ipnet: 98.137.64.0/21(0.93), asn: 36647(0.74), country: US(-0.06)]; FREEMAIL_CC(0.00)[optusnet.com.au] 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: Fri, 19 Apr 2019 04:36:31 -0000 First I review below lwsync behavior. It is based on a = comparison/contrast paper for the powerpc vs. arm memory models. It sets context for later material specific to powerpc64 or 32-bit powerpc FreeBSD. "For a write before a read, separated by a lwsync, the barrier will = ensure that the write is committed before the read is satisfied but lets the read be satisfied = before the write has been propagated to any other thread." (By contrast, sync, guarantees that the write has propagated to all = threads before the read in question is satisfied, the read having been separated from the = write by the sync.) Another wording in case it helps (from the same paper): "The POWER lwsync does *not* ensure that writes before the barrier have = propagated to any other thread before sequent actions, though it does keep writes = before and after an lwsync in order as far as [each thread is] concerned". (Original used = plural form: "all threads are". I tired to avoid any potential implication of cross = (hardware) "thread" ordering constraints for seeing the updates when lwsync is = used.) Next I note FreeBSD powerpc64 and 32-bit powerpc details that happen to involve lwsync, though lwsync is not the only issue: atomic_store_rel_int(&th->th_generation, ogen); and: gen =3D atomic_load_acq_int(&th->th_generation); with: static __inline void \ atomic_store_rel_##TYPE(volatile u_##TYPE *p, u_##TYPE v) \ { \ \ powerpc_lwsync(); \ *p =3D v; \ } and: static __inline u_##TYPE \ atomic_load_acq_##TYPE(volatile u_##TYPE *p) \ { \ u_##TYPE v; \ \ v =3D *p; \ powerpc_lwsync(); \ return (v); \ } \ also: static __inline void atomic_thread_fence_acq(void) { powerpc_lwsync(); } First I list a simpler-than-full-context example to try to make things clearer . . . Here is a sequence, listing in an overall time order, omitting other activity, despite the distinct cpus, (N!=3DM): (Presume th->th_generation=3D=3Dogen-1 initially, then:) cpu N: atomic_store_rel_int(&th->th_generation, ogen); (same th value as for cpu M below) cpu M: gen =3D atomic_load_acq_int(&th->th_generation); For the above sequence: There is no barrier between the store and the later load at all. This is important below. So, if I have that much right . . . Now for more actual "load side" context: (Presume, for simplicity, that there is only one=20 timehands instance instead of 2 or more timehands. So th does not vary below and is the same on both cpu's in the later example sequence of activity.) do { th =3D timehands; gen =3D atomic_load_acq_int(&th->th_generation); *bt =3D th->th_offset; bintime_addx(bt, th->th_scale * tc_delta(th)); atomic_thread_fence_acq(); } while (gen =3D=3D 0 || gen !=3D th->th_generation); For simplicity of referring to things: I again show a specific sequence in time. I only show the &th->th_generation activity from cpu N, again for simplicity. (Presume timehands->th_generation=3D=3Dogen-1 initially and that M!=3DN:) cpu M: th =3D timehands; (Could be after the "cpu N" lines.) cpu N: atomic_store_rel_int(&th->th_generation, ogen); (same th value as for cpu M) cpu M: gen =3D atomic_load_acq_int(&th->th_generation); cpu M: *bt =3D th->th_offset; cpu M: bintime_addx(bt, th->th_scale * tc_delta(th)); cpu M: atomic_thread_fence_acq(); cpu M: gen !=3D th->th_generation (evaluated to false or to true) So here: A) gen ends up with: gen=3D=3Dogen-1 || gen=3D=3Dogen (either is allowed because of the lack of any barrier between the store and the involved load). B) When gen=3D=3Dogen: there was no barrier before the assignment to gen to guarantee other th-> field-value staging relationships. C) When gen=3D=3Dogen: gen!=3Dth->th_generation false does not guarantee the *bt=3D. . . and bintime_addx(. . .) activities were based on a coherent set of th-> field-values. If I'm correct about (C) then the likes of the binuptime and sbinuptime implementations appear to be broken on powerpc64 and 32-bit powerpc unless there are extra guarantees always present. So have I found at least a powerpc64/32-bit-powerpc FreeBSD implementation problem? Note: While I'm still testing, I've seen problems on the two 970MP based 2-socket/2-cores-each G5 PowerMac11,2's that I've so far not seen on three 2-socket/1-core-each PowerMacs, two such 7455 G4 PowerMac3,6's and one such 970 G5 PowerMac7,2. The two PowerMac11,2's are far more tested at this point. But proving that any test-failure is specifically because of (C) is problematical. Note: arm apparently has no equivalent of lwsync, just of sync (aka. hwsync and sync 0). If I understand correctly, PowerPC/Power has the weakest memory model of the modern tier-1/tier-2 architectures and, so, they might be broken for memory model handling when everything else is working. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-ppc@freebsd.org Fri Apr 19 05:17:54 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 E4B071585B2C for ; Fri, 19 Apr 2019 05:17:53 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-28.consmr.mail.bf2.yahoo.com (sonic317-28.consmr.mail.bf2.yahoo.com [74.6.129.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 C8E318E3DF for ; Fri, 19 Apr 2019 05:17:51 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: ONTDAVYVM1mCwjts_5U0JptmTjyOc4J_qbeARDcUcxcO1jZ7zvOlGDXgcuHQl2q iyzkuZBgM1qm0pV.XLKsWLreRKw6hJvtWVRqGqMvvuBTclku3hngm.p6C58JXD4hUT4q5Rtzl99t 6qSOkLZPoxhGSz0wyAc0NlyXwLA1SiHiUZBrLLUGbd4XU4f8Kt8FWDeKx0aVNPkuvPXiMwLr..oj X_7ZmCDnCkAIDChRulJfb0MWJQg0fmg6wP5xxzMje4dfHloAor5KaqlJWk_dKfvRRukF7_Bntg04 CyNmO.UKwdPasuFD3C43Vlti4hBW8EYgLYlU1e5Idlyu4BYkUV80QwJrIBKRwdnDU_FaaTUJzzed 5HWT2UadxgAvUiEiP70yddNsSMDinQI3bdB7BZnDGKs__LKmHcEgsGBjjsJ0BuXYH4_3x0jMEB1w S96lLpwWxbm2mpoG7kf_3KtDfJ00VzcXPHVPMdv33og_uKBhy2xfEQXXF949KC68uBkMVflPdQ4v lepOlP2hhgWttdAtunnFmOagtHQ4O9nTH.F3r9aiNdYZoWzoLSC0iie8WMZ.ya4Ut2Xn5oXbW9OF 4_xWq2BMBL2XEa1jsUYGN_mwlfAFK_SYOvNpmFktivnQJJr84ddNrXH7FaiMvwfSV3DfHVPd851z 5QSd_z9X4HAXkQQnuMmS0sf6zNjrFxTXaZ3syerWsB_iRe7.pBV4oJz_DPeVTX93flWdIafbrp5Z oikdp6FllL8zGsK_IjtoUJ0njk3s39L9IFzxjnM9r3jB3rn7pkV7BJr_ycmh8GkVBvjmXWjeC9zJ g857.dEsOJ_UZXuRDmm1cDMMsxMnjFXWGgRCjhEE1d1GpiuPrr1mCBT5sKlcBEd4iW2PuwhLmus8 TXjdh6oQOXbYuLnxtvQ8iE1rehxD4OCUP9cXLmiFrPRogbiKThAaJFxOxIH029iGQp4u0G67Q7gH Zs1nL5Uo9waevRefWRYsTHx4JmaKqGvA4EaT7OsZckrfeyGpZg2m1Vbn6_95S9Yl1aCmNf0wBp5y 9_goAa_J7TH1rxJGG4QoF456jqqMfUI9q8dxjBm1ygyHKCTouucR2k1jrrgzEMXR_552ZHv6lWi4 lrhd6YDRsB8Pj5xro_cwIgmFnXYUu2hHjkhd7 Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.bf2.yahoo.com with HTTP; Fri, 19 Apr 2019 05:17:50 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.103]) ([76.115.7.162]) by smtp408.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID bb6fba2b6d368dc95857f40b5c5be28e; Fri, 19 Apr 2019 05:17:49 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Subject: Re: powerpc64 or 32-bit power context: FreeBSD lwsync use vs. th->th_generation handling (and related th-> fields) [Correction] From: Mark Millard In-Reply-To: <50CFD7F1-6892-4375-967B-4713517C2520@yahoo.com> Date: Thu, 18 Apr 2019 22:17:46 -0700 Cc: Bruce Evans , Konstantin Belousov Content-Transfer-Encoding: quoted-printable Message-Id: <0FD9ED28-EF4B-4A1C-9FCE-81C4D5BAEBF1@yahoo.com> References: <50CFD7F1-6892-4375-967B-4713517C2520@yahoo.com> To: FreeBSD PowerPC ML , freebsd-hackers Hackers X-Mailer: Apple Mail (2.3445.104.8) X-Rspamd-Queue-Id: C8E318E3DF X-Spamd-Bar: +++ X-Spamd-Result: default: False [3.46 / 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]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(1.67)[ip: (5.54), ipnet: 74.6.128.0/21(1.60), asn: 26101(1.28), country: US(-0.06)]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:26101, ipnet:74.6.128.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)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_SPAM_SHORT(0.99)[0.985,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; NEURAL_SPAM_MEDIUM(0.82)[0.819,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.49)[0.493,0]; RCVD_IN_DNSWL_NONE(0.00)[83.129.6.74.list.dnswl.org : 127.0.5.0]; FREEMAIL_CC(0.00)[optusnet.com.au] 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: Fri, 19 Apr 2019 05:17:54 -0000 [I caught my mental mistake.] On 2019-Apr-18, at 21:36, Mark Millard wrote: > First I review below lwsync behavior. It is based on a = comparison/contrast > paper for the powerpc vs. arm memory models. It sets context for later > material specific to powerpc64 or 32-bit powerpc FreeBSD. >=20 > "For a write before a read, separated by a lwsync, the barrier will = ensure that the write is > committed before the read is satisfied but lets the read be satisfied = before the write has > been propagated to any other thread." >=20 > (By contrast, sync, guarantees that the write has propagated to all = threads before the > read in question is satisfied, the read having been separated from the = write by the > sync.) >=20 > Another wording in case it helps (from the same paper): >=20 > "The POWER lwsync does *not* ensure that writes before the barrier = have propagated to > any other thread before sequent actions, though it does keep writes = before and after > an lwsync in order as far as [each thread is] concerned". (Original = used plural form: > "all threads are". I tired to avoid any potential implication of cross = (hardware) > "thread" ordering constraints for seeing the updates when lwsync is = used.) >=20 >=20 > Next I note FreeBSD powerpc64 and 32-bit powerpc details > that happen to involve lwsync, though lwsync is not the > only issue: >=20 > atomic_store_rel_int(&th->th_generation, ogen); >=20 > and: >=20 > gen =3D atomic_load_acq_int(&th->th_generation); >=20 > with: >=20 > static __inline void \ > atomic_store_rel_##TYPE(volatile u_##TYPE *p, u_##TYPE v) \ > { \ > \ > powerpc_lwsync(); \ > *p =3D v; \ > } >=20 > and: >=20 > static __inline u_##TYPE \ > atomic_load_acq_##TYPE(volatile u_##TYPE *p) \ > { \ > u_##TYPE v; \ > \ > v =3D *p; \ > powerpc_lwsync(); \ > return (v); \ > } \ >=20 > also: >=20 > static __inline void > atomic_thread_fence_acq(void) > { >=20 > powerpc_lwsync(); > } >=20 >=20 >=20 > First I list a simpler-than-full-context example to > try to make things clearer . . . >=20 > Here is a sequence, listing in an overall time > order, omitting other activity, despite the distinct > cpus, (N!=3DM): >=20 >=20 > (Presume th->th_generation=3D=3Dogen-1 initially, then:) >=20 > cpu N: atomic_store_rel_int(&th->th_generation, ogen); > (same th value as for cpu M below) >=20 > cpu M: gen =3D atomic_load_acq_int(&th->th_generation); >=20 >=20 > For the above sequence: >=20 > There is no barrier between the store and the later > load at all. This is important below. >=20 >=20 > So, if I have that much right . . . >=20 > Now for more actual "load side" context: > (Presume, for simplicity, that there is only one=20 > timehands instance instead of 2 or more timehands. So > th does not vary below and is the same on both cpu's > in the later example sequence of activity.) >=20 > do { > th =3D timehands; > gen =3D atomic_load_acq_int(&th->th_generation); > *bt =3D th->th_offset; > bintime_addx(bt, th->th_scale * tc_delta(th)); > atomic_thread_fence_acq(); > } while (gen =3D=3D 0 || gen !=3D th->th_generation); >=20 > For simplicity of referring to things: I again show > a specific sequence in time. I only show the > &th->th_generation activity from cpu N, again for > simplicity. >=20 > (Presume timehands->th_generation=3D=3Dogen-1 initially > and that M!=3DN:) >=20 > cpu M: th =3D timehands; > (Could be after the "cpu N" lines.) >=20 > cpu N: atomic_store_rel_int(&th->th_generation, ogen); > (same th value as for cpu M) >=20 > cpu M: gen =3D atomic_load_acq_int(&th->th_generation); > cpu M: *bt =3D th->th_offset; > cpu M: bintime_addx(bt, th->th_scale * tc_delta(th)); > cpu M: atomic_thread_fence_acq(); > cpu M: gen !=3D th->th_generation > (evaluated to false or to true) >=20 > So here: >=20 > A) gen ends up with: gen=3D=3Dogen-1 || gen=3D=3Dogen > (either is allowed because of the lack of > any barrier between the store and the > involved load). >=20 > B) When gen=3D=3Dogen: there was no barrier > before the assignment to gen to guarantee > other th-> field-value staging relationships. (B) is just wrong: seeing the new value (ogen) does guarantee some about the other th->=20 field-value staging relationships seen, given the lwsync before the store and after the load. > C) When gen=3D=3Dogen: gen!=3Dth->th_generation false > does not guarantee the *bt=3D. . . and > bintime_addx(. . .) activities were based > on a coherent set of th-> field-values. Without (B), (C) does not follow. > If I'm correct about (C) then the likes of the > binuptime and sbinuptime implementations appear > to be broken on powerpc64 and 32-bit powerpc > unless there are extra guarantees always present. >=20 > So have I found at least a powerpc64/32-bit-powerpc > FreeBSD implementation problem? No: I did not find a problem. > Note: While I'm still testing, I've seen problems > on the two 970MP based 2-socket/2-cores-each G5 > PowerMac11,2's that I've so far not seen on three > 2-socket/1-core-each PowerMacs, two such 7455 G4 > PowerMac3,6's and one such 970 G5 PowerMac7,2. > The two PowerMac11,2's are far more tested at > this point. But proving that any test-failure is > specifically because of (C) is problematical. >=20 >=20 > Note: arm apparently has no equivalent of lwsync, > just of sync (aka. hwsync and sync 0). If I > understand correctly, PowerPC/Power has the weakest > memory model of the modern tier-1/tier-2 > architectures and, so, they might be broken for > memory model handling when everything else is > working. >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-ppc@freebsd.org Fri Apr 19 22:21:05 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 7A9DA157A75F for ; Fri, 19 Apr 2019 22:21:05 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-21.consmr.mail.ne1.yahoo.com (sonic309-21.consmr.mail.ne1.yahoo.com [66.163.184.147]) (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 1D66C6E17B for ; Fri, 19 Apr 2019 22:21:03 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 7r328LMVM1mOrvDNopXtmPxBtrYuwzjf0pte6OUxic51OJpuE_cIKk1bGk2je41 4zcS8wX4Xh5bNrlgmj94ikVkIdvmbN1VNvoeUbLEAd80R_skodYFH0jHMSLLA1iVDDe2KDd5aP6T 9GeP_iiPbO0WX1BcMRtBFGZkI7NzgPbkXecqOahIHUE.jcOwdlCvN4HEfkmsiwAWoLFHaay96mJt 0.2pOYicn2LIMJojrCAVGKaIjtbshe1cQPkuW0pOoS3d8c8cCsTDF8y71rKdjv173wQNkTjm3j3p b4IQkcLgWNoYiCMgpjUEaTV3OdHJrQGNcj36MXz4k2QlG0p7rejwNM0iJcdTBhXETc1fIdMjf14M c3RHOSKSb76l64_3WVkAnmrsXPAytntj4Z8Y4ITNVODQMJ26TqjFpdl62zctPSoCqeM_FH5JV5Bt 2uB0hS34COfdUm63UWKeLcNOBEacxt7SD21v185lWBsYtcG0EbrwTYcNBO4sA1_dw85MaCPnz74p Wx6MDmjjgte.ED4V4ApX7CZHGAmb7.neLxCFLngtoKzLTXTSgnWLDO8LEWJP.YvdWN8Sd2fXxlFD ewMnOVGFEY33sfJ4sE0DJ87z3PnvGNULGnMzYrP63ua6ff4oFgbEEm3Tnkk_e7btU94YZyDsb6eo yX9rNQcEfSJKkSTS93JJZz5j4BptCcQFqBUuQazc0N.VsJhNadv0UVY_hw8._VQlcUSFlTRtiz95 69rhKMHaAhKhJ0h5AMNWu7_MLNxsVQQD_wbfX2zw5YT_mXyYEIGSg6dTzVTd3Bs.XfTr1BtnzRKj lto66qVbcSfejtSs0KziYagbQwZD0_JIR45dby1FBrfMc4MbmRQbTYTi.rix7f.SnNMuLFQ1gt4x wS_uQGq_lhAiJhii4MjGEy244GcMq_qkTle8wd8HxxSRCAVi6bjGqg0pwWarAxhmr_LAALhMh04O ZPKpNSkvMkYNgLrZQAjQUsqy1ZvfVCUto9c_mn1S7jrSFwXrYH0w78Br02gMY7csEk0MAA2MaogF _NYU7DohocfnhJSN7AEFC.mJSOcKR3QkIoDAzlCRkZiWMjJASw1r7eJM6XTgJLRvUPg4lOIW1EJs YQE3aJxnACLRpbANqTYh8oQrLoy7CAA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.ne1.yahoo.com with HTTP; Fri, 19 Apr 2019 22:21:03 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.103]) ([76.115.7.162]) by smtp432.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID c8dc8719900c3aa4f1b0048c90573a74; Fri, 19 Apr 2019 22:21:00 +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: head -r346144 vs. "or 27,27,27" use (via cpu_spinwait) Message-Id: Date: Fri, 19 Apr 2019 15:20:59 -0700 To: FreeBSD PowerPC ML , Justin Hibbits X-Mailer: Apple Mail (2.3445.104.8) X-Rspamd-Queue-Id: 1D66C6E17B X-Spamd-Bar: ++ X-Spamd-Result: default: False [2.67 / 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)[]; MX_GOOD(-0.01)[cached: mta6.am0.yahoodns.net]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; 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:36646, ipnet:66.163.184.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.39)[0.387,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(1.55)[ip: (5.23), ipnet: 66.163.184.0/21(1.43), asn: 36646(1.15), country: US(-0.06)]; NEURAL_SPAM_MEDIUM(0.82)[0.818,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.43)[0.428,0]; RCVD_IN_DNSWL_NONE(0.00)[147.184.163.66.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: Fri, 19 Apr 2019 22:21:05 -0000 There still seems to be: /usr/src/sys/powerpc/include/cpu.h:#define cpu_spinwait() = __asm __volatile("or 27,27,27") /* yield */ used in powerpc_ipi_handler and ofw_rendezvous_dispatch and mpc85xx_jog_set_int . (It is not clear to me what the status of "or 27,27,27" is on older processors, like in PowerMacs. 27 was not documented before PowerISA 2.06 . (I looked in 2.03, 2.04, 2.05, 2.06B V2, 2.07, and 3.0B.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-ppc@freebsd.org Fri Apr 19 22:56:12 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 CB9E0157B423 for ; Fri, 19 Apr 2019 22:56:12 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-3.consmr.mail.bf2.yahoo.com (sonic305-3.consmr.mail.bf2.yahoo.com [74.6.133.42]) (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 7E8C76F44C for ; Fri, 19 Apr 2019 22:56:11 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: Fb0mUxsVM1ktbB2ri0N5U9QPUy350fedVeWnjkvJIryRWB0BeXFq5aajGkX.8qF p.p1SLU8iH8IBfSknnjf2ShoGrzRQnSrfLQtpz_7v6UQUs6AwaheO.zD7Vtspogup84IR2RciQay QVnTCK6r5dLZMOQ99dcFQC3pah_.kCfj.P5j2xQr7mA5Rsn6XxhCuCyYZULLG3ih.SoVwwFJ8vFX N2dzCUp3IzkS6Z3wDrC1lA8pCp94YH.ENGvtcGUi48rWLiq9MTYNXADPnAiO14CQc6YKNAr75MIF LJNEjmvsHwrPE1iTkhfADGkakji0T.Sknm8joOhFQbZADweUcqmsRt_ZtXpHh0AqOYMKW.3UdWf1 HMwgYPs__ChioWX8XNCjydUrFHmbhQXpOXO0da9Hyj6uR8wSW.K85Vx2fKkEuApDTeKWerE_XN9F I1gdIzkM5TEMYb71cqTw6LyokR3.rg131IY6G1cBBMOjkycRIgyafau6W8B5AEG5donn6AFokDm_ iuJ_eEY5YuXe0X_qYYXFNlR0NanyqzcW4MyKBlTW9DD4luT4mlhuIUUId2rziZYJMWd8hI.gbE2T bsFnB9PEDeQu_60tWKx1u8nUSkWdPsbLMKODDSQUgDiy8Qvh8MIB_k78DPsuNyQGgHtrj_3tgumu OANFA3y4g6JxLRm9.jY4vxpA52GzHOG6MjOeniqxMYIZI6SenBow10F7PphB6c4dMPdlZiTtyBqd 9sM3wp.ANiU2PpQTfEWgx2Ym8lpnWly3l0KzD0Etsejbo0QoKogw4vFFsPEgvqO_3OPTXpYM8.0W Vc5r6gDr3InJXto1E08_rCTz.co1dPhulhU2MacLyiQqAlf.Ax3sZsX502UXyI1sEhL3Iwhih0wO yKNIC_BKB32yd20chdd8RIBbnRJMLiBGYZYHtuHAd.IOT1TE_P523PE8mx1r2OQAwXAr19mtDmmo ZX7qvHH2CncZYbJtfFhbVQgihYxva1mANsa2BziDCu_uSdXzCBWirdj7NQSpG0mg.B0S.KbZDMEB lDY9FD84uZcYbr6rOWOIXfZAqB4D77O6dGQPQii6vVS5GL_tkZkVGK7dGItm9y_POBxp281qQUwu ww7k8UOSRo7WqZbuaQe6sC2usr.eBRg-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.bf2.yahoo.com with HTTP; Fri, 19 Apr 2019 22:56:09 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.103]) ([76.115.7.162]) by smtp415.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID ce4f661cdbe1c0356ac3c159d9d45773; Fri, 19 Apr 2019 22:56:08 +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: spinlock_enter, head -r346144 (and before) and use of nop_prio_mhigh vs. PowerISA document suggestions for lock code Message-Id: Date: Fri, 19 Apr 2019 15:56:06 -0700 To: FreeBSD PowerPC ML , Justin Hibbits X-Mailer: Apple Mail (2.3445.104.8) X-Rspamd-Queue-Id: 7E8C76F44C X-Spamd-Bar: + X-Spamd-Result: default: False [1.95 / 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]; 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:26101, ipnet:74.6.128.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.07)[0.072,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(1.38)[ip: (4.10), ipnet: 74.6.128.0/21(1.59), asn: 26101(1.27), country: US(-0.06)]; NEURAL_SPAM_MEDIUM(0.73)[0.728,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.28)[0.279,0]; RCVD_IN_DNSWL_NONE(0.00)[42.133.6.74.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: Fri, 19 Apr 2019 22:56:13 -0000 I found the following text in each of the 2.03, 2.04, 2.05, 2.06B V2, 2.07, and 3.0B PowerISA documents, in a "Programming Note" in the "Program Priority Registers" section: ". . . if a program is waiting on a lock (...), it could set low = priority with the result that more processor resources would be diverted to the program = that holds the lock. This diversion of resources may enable the lock-holding program to = complete the operation under the lock more quickly, and then relinquish the lock = to the waiting program." The wording suggests working via normal/medium and lower priorities instead of via normal/medium and higher priorities. (May be more than just the relative priority matters in the behavior changes that result each way? Unfortunately the wording is not very explicit.) All of the documents list "or rx,rx,rx" for: Rx being 31 or 1 or 6 or 2 or 5 or 3 or 7 (listed lowest to highest relative priority), 2 being normal/medium. Some table(s) might not list 3 or 7 in a document but at least one does in each. In the following powerpc64 and 32-bit powerpc FreeBSD seem to be going in the opposite direction relative to normal/medium vs. the suggestion of "low priority": void spinlock_enter(void) { struct thread *td; register_t msr; td =3D curthread; if (td->td_md.md_spinlock_count =3D=3D 0) { nop_prio_mhigh(); msr =3D intr_disable(); td->td_md.md_spinlock_count =3D 1; td->td_md.md_saved_msr =3D msr; } else td->td_md.md_spinlock_count++; critical_enter(); } void spinlock_exit(void) { struct thread *td; register_t msr; td =3D curthread; critical_exit(); msr =3D td->td_md.md_saved_msr; td->td_md.md_spinlock_count--; if (td->td_md.md_spinlock_count =3D=3D 0) { intr_restore(msr); nop_prio_medium(); } } and previously: void spinlock_enter(void) { struct thread *td; register_t msr; =20 td =3D curthread; if (td->td_md.md_spinlock_count =3D=3D 0) { __asm __volatile("or 2,2,2"); /* Set high thread = priority */ msr =3D intr_disable(); td->td_md.md_spinlock_count =3D 1; td->td_md.md_saved_msr =3D msr; } else td->td_md.md_spinlock_count++; critical_enter(); } void spinlock_exit(void) { struct thread *td; register_t msr; td =3D curthread; critical_exit(); msr =3D td->td_md.md_saved_msr; td->td_md.md_spinlock_count--; if (td->td_md.md_spinlock_count =3D=3D 0) { intr_restore(msr); __asm __volatile("or 6,6,6"); /* Set normal thread = priority */ } } (2,2,2 was higher then 6,6,6 but 2,2,2 is normal/medium and 6,6,6 is "medium low" the way the PowerISA documentation reads.) 2.06B V2 and 2.07 also list special meanings for: 27 and 29 and 30. (cpu_spinwait in FreeBSD uses 27.) But 3.0B does not list them any more. 2.07 and 3.0B lists a special meaning for: 26. No prior version that I looked at does. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-ppc@freebsd.org Fri Apr 19 23:00:14 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 96676157B52C for ; Fri, 19 Apr 2019 23:00:14 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-15.consmr.mail.bf2.yahoo.com (sonic310-15.consmr.mail.bf2.yahoo.com [74.6.135.125]) (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 B0C706F594 for ; Fri, 19 Apr 2019 23:00:13 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: fobXpkcVM1kQ_tN65GFShGg57Z5o.3HWMSYDosV9NBtz6fLDh1584XWyhG8ye19 2Z1GJ8WciY0Pjd3fpKz.S6x381vNeIxZ9ES6Nsm_fmNr1VjHHjNL9MmXGrmOhcyd9MSDQvf1JsdY jnH0WeTDOp4vuxtwKExRVbHIi7G0S3GYNBE4e.n30pygLr8eLBTMmDgewrgjrEqlxXKzUypxoi9E oTDgKPAPf8NcT.uIa2kQIyIWbrCK1PPZPcgVMVgnCQixepzGfGfeqPnlFPT3GrghxNnJZGaWLgnM ogxL6teP_vxoZe30R3_5KhZLauoJLm6Kh.i_zU7exxu65SSYtcQEKkCEQucl46wwQ_Tag6WKHac5 MYgbPS5OgvL_zsCVAiRkIRgEK3uIGfyMZsEaxEJfvl.KlEIopD3VsOxyxogXe5oQM0GgG4GGvhK7 4roB0YH_tmivMvTiZs28AdkXi15ntkqx2cBGezp2bAOIGkPhnjK2kuDmm_Lrr7XDcE.DaIKFUuVg 2Bz78RJ4A_aqNoMuPQYoWGq8zatPwQq.vURrVAgdTW8KZ0FhO1cSf6S9eOJLlPzsT.OKMTMItl5H 7Z1p3KcfQ.v1N4hLjKQ4kUhUaoZ6rcY_8nyesr6I_sZMe95loQGno_FjrYdmNdyIZ9fFysxoKoh1 WCg4fW1IYW99n3AtOLwoSv.qa20SsS3d93vAUL3hCrNFhErAk_XqAhFZJ9ulLdIO6VO8jFIY4dmj Z3SMjrH9hBDH4m2fCv72aUuXSg.FrlnJLHWX4ZDulpXaWmMQjNNvLPPn3IT0hnLXQ_CJNiZE_xRM 8bXvbbBdeaxbyRJEe5k1kuja4AumTIQD3Dwwgs8WUoIG6OUKVOEg0FRJX2Ueu873eHMA4_yX7SsI bvRHAcGixBG68HCOw7ft4Hjw1Yh11loafHC0P9u94WZRyCCuWxSahWon3XZuE5VVjGUFPYJiOVDd dTBxR5QrxfXmYd11QWNesyTUvcPU.QIdmUuiqSetGZafYo8fGoKykrjKAP.fZng7iUU4HYj3bM90 VTz2qAFXpNsYbLgWdu38UZUtGbmduGt5928yAQNa_YW3LXXSbu3CD6phMurnB0mYSBUK9g9nVJHi bOrdPjLT4fEcUAv_7hFEi5vbBDX.N6g-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.bf2.yahoo.com with HTTP; Fri, 19 Apr 2019 23:00:12 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.103]) ([76.115.7.162]) by smtp428.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID ddafcb4235b968cea96d8f3844cbd9c7; Fri, 19 Apr 2019 23:00:08 +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: head -r346144 vs. "or 27,27,27" use (via cpu_spinwait) Date: Fri, 19 Apr 2019 16:00:05 -0700 References: To: FreeBSD PowerPC ML , Justin Hibbits In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3445.104.8) X-Rspamd-Queue-Id: B0C706F594 X-Spamd-Bar: ++ X-Spamd-Result: default: False [2.01 / 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]; 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:26101, ipnet:74.6.128.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.30)[0.305,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(1.28)[ip: (3.57), ipnet: 74.6.128.0/21(1.59), asn: 26101(1.27), country: US(-0.06)]; NEURAL_SPAM_MEDIUM(0.73)[0.729,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.21)[0.212,0]; RCVD_IN_DNSWL_NONE(0.00)[125.135.6.74.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: Fri, 19 Apr 2019 23:00:14 -0000 On 2019-Apr-19, at 15:20, Mark Millard wrote: > There still seems to be: >=20 > /usr/src/sys/powerpc/include/cpu.h:#define cpu_spinwait() = __asm __volatile("or 27,27,27") /* yield */ >=20 > used in powerpc_ipi_handler and ofw_rendezvous_dispatch > and mpc85xx_jog_set_int . >=20 > (It is not clear to me what the status of "or 27,27,27" is > on older processors, like in PowerMacs. 27 was not > documented before PowerISA 2.06 . (I looked in 2.03, 2.04, > 2.05, 2.06B V2, 2.07, and 3.0B.) I forgot to mention, PowerISA 3.0B no longer lists information about any of: or 27,27,27 or 29,29,29 or 30,30,30 2.07 and 3.0B do list information for: or 26,26,26 No prior ones do. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-ppc@freebsd.org Sat Apr 20 00:22:37 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 1FE41157D269 for ; Sat, 20 Apr 2019 00:22:37 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-21.consmr.mail.ne1.yahoo.com (sonic315-21.consmr.mail.ne1.yahoo.com [66.163.190.147]) (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 74D8F72C76 for ; Sat, 20 Apr 2019 00:22:35 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: mqgLrPsVM1kCynT2hacAoNo2L75OPP.sO3JpKToTHyyHQIJF1994TpXHUtxD.RU NT6quhMBL9b_OFrr3PknV0r146ffvLDlKJh8au7hTJiuwydNjcGixRRXLRbXzLGA5eESCJm2QImM P3jDHNIPpTZKvD.K09eUG6asvu0M9XlWmPTBNWVRz0Lr5_xQXjnaEIc7OtNC_viheS2jlifM12Km G4GUZ7nKopxxkFYtZ1EJefk.wGQ4nLaV04w1w6m2ODgeDhlQj4Mem.9jC0GoKCi0qcaYVpwGSHUu fWJMMezEbDcdsPC56EHzSBiAvofvFH4w3tg6iiJ1LSP4wkl_TBfgLTKi6ycvtItGXkurgkCSgOYv HYNn54Ki0KwOUXXp2RAVN1k0WxV68kq_LLFDPgakdAiO7xiWQYgJqaQJ2VqEf5ye.fHj0s3BZYzn CdNCjxQJraBPuVtmVRRLqGBPJ9DBG4.j.GvVs0Rc38gKGj2kbNmuc7MiEOzxSLFu0ObEWFdkshYM CX.KNoxAX8QS3W5BKIL4h6Eyj8ajlQzl6sq1WOO.r9mhfDR_.unn.5LtvZKBJuivgZeBE1BpDqu5 rMehwPgJ.t8g7F6TY8H3jec2Tc5sOb1D9auv_fpmRdD8rbP7pRJHs1VVQSHqmRHHc9UjXOhSofBG A1tlHj4TVhR2HmWsHKT004FLVO2pxZkFgWZ5YW8BVf0C3Njscwl2G.LcSwhLjMdd43N46qX14BKN myKOfj_4FvU4hxBYX0AoCghsfAdsFZPUNVPG78wcMtewQwbD6cGPhl6U515xTNOuDjpyDoJAPSIZ J25M7swSzql8_ymHrABzsHfEkpIIcuSQKZdJfmxAoG.Jd2GMWS8_FTKduxBWBjOIJxa.ZlFJpAeh N9P1RojeQIRNzxkgNOO89qRZXVaFL1.JC0fwX8lZLlgWbaw7QOtbUA6oNCjP3M8zlSJFtQhNobGs tD6kvkcXo12gM8JGIi6xTa9GEci3Vp255nIJHeCsoclFlX4Zk2FRX4CM1LLkFZjCo95feBsfEN3F Gxff_i18VZ470rcN6nstOdyk9UG5wOfN.Dk3wNzg6CczUQQpbK1qd7.VE3wYO9s0bmrZhhuFa1DA 8hxZd28LJdGbc75MbIEEWnApq9TSsD9.C Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.ne1.yahoo.com with HTTP; Sat, 20 Apr 2019 00:22:28 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.103]) ([76.115.7.162]) by smtp402.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID c6d030ee6a3b576fa57a7dbe8aa4f053; Sat, 20 Apr 2019 00:22:26 +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: spinlock_enter, head -r346144 (and before) and use of nop_prio_mhigh vs. PowerISA document suggestions for lock code Date: Fri, 19 Apr 2019 17:22:24 -0700 References: To: FreeBSD PowerPC ML , Justin Hibbits In-Reply-To: Message-Id: <300DEA60-E9C3-4BB7-A7EF-980EE58257DB@yahoo.com> X-Mailer: Apple Mail (2.3445.104.8) X-Rspamd-Queue-Id: 74D8F72C76 X-Spamd-Bar: +++ X-Spamd-Result: default: False [3.09 / 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)[]; MX_GOOD(-0.01)[cached: mta6.am0.yahoodns.net]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; 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:36646, ipnet:66.163.184.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.31)[0.308,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(1.76)[ip: (6.26), ipnet: 66.163.184.0/21(1.43), asn: 36646(1.15), country: US(-0.06)]; NEURAL_SPAM_MEDIUM(0.86)[0.864,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.67)[0.668,0]; RCVD_IN_DNSWL_NONE(0.00)[147.190.163.66.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, 20 Apr 2019 00:22:37 -0000 [Looks like nop_prio_mhigh has some vintage-specific behavior, based on if there is a PSPB (Problem State Priority Boost Register) and how it is configured.] On 2019-Apr-19, at 15:56, Mark Millard wrote: > I found the following text in each of the 2.03, 2.04, 2.05, > 2.06B V2, 2.07, and 3.0B PowerISA documents, in a "Programming > Note" in the "Program Priority Registers" section: >=20 > ". . . if a program is waiting on a lock (...), it could set low = priority with the > result that more processor resources would be diverted to the program = that holds the > lock. This diversion of resources may enable the lock-holding program = to complete > the operation under the lock more quickly, and then relinquish the = lock to the waiting > program." >=20 > The wording suggests working via normal/medium and lower > priorities instead of via normal/medium and higher priorities. > (May be more than just the relative priority matters in the > behavior changes that result each way? Unfortunately the > wording is not very explicit.) >=20 > All of the documents list "or rx,rx,rx" for: > Rx being 31 or 1 or 6 or 2 or 5 or 3 or 7 > (listed lowest to highest relative priority), > 2 being normal/medium. Some table(s) might not > list 3 or 7 in a document but at least one does > in each. Actually, going back to 2.03, for example, only lists 31 in one place as well. Only 1, 6, and 2 are in all such tables. > In the following powerpc64 and 32-bit powerpc > FreeBSD seem to be going in the opposite direction > relative to normal/medium vs. the suggestion > of "low priority": >=20 > void > spinlock_enter(void) > { > struct thread *td; > register_t msr; >=20 > td =3D curthread; > if (td->td_md.md_spinlock_count =3D=3D 0) { > nop_prio_mhigh(); > msr =3D intr_disable(); > td->td_md.md_spinlock_count =3D 1; > td->td_md.md_saved_msr =3D msr; > } else > td->td_md.md_spinlock_count++; > critical_enter(); > } >=20 > void > spinlock_exit(void) > { > struct thread *td; > register_t msr; >=20 > td =3D curthread; > critical_exit(); > msr =3D td->td_md.md_saved_msr; > td->td_md.md_spinlock_count--; > if (td->td_md.md_spinlock_count =3D=3D 0) { > intr_restore(msr); > nop_prio_medium(); > } > } >=20 > and previously: >=20 > void > spinlock_enter(void) > { > struct thread *td; > register_t msr; >=20 > td =3D curthread; > if (td->td_md.md_spinlock_count =3D=3D 0) { > __asm __volatile("or 2,2,2"); /* Set high thread = priority */ > msr =3D intr_disable(); > td->td_md.md_spinlock_count =3D 1; > td->td_md.md_saved_msr =3D msr; > } else > td->td_md.md_spinlock_count++; > critical_enter(); > } >=20 > void > spinlock_exit(void) > { > struct thread *td; > register_t msr; >=20 > td =3D curthread; > critical_exit(); > msr =3D td->td_md.md_saved_msr; > td->td_md.md_spinlock_count--; > if (td->td_md.md_spinlock_count =3D=3D 0) { > intr_restore(msr); > __asm __volatile("or 6,6,6"); /* Set normal thread = priority */ > } > } >=20 > (2,2,2 was higher then 6,6,6 but 2,2,2 is > normal/medium and 6,6,6 is "medium low" the > way the PowerISA documentation reads.) >=20 > 2.06B V2 and 2.07 also list special meanings for: > 27 and 29 and 30. (cpu_spinwait in FreeBSD uses 27.) > But 3.0B does not list them any more. >=20 > 2.07 and 3.0B lists a special meaning for: 26. > No prior version that I looked at does. >=20 PSPB (Problem State Priority Boost Register)is not=20 mentioned until 2.07 of the PowerISA (for those I've been looking at). PSPB can count down and force Medium High back to Medium, for example. A hardware form of timed-temporary priority boost when used that way. It appears that medium and lower priorities do not have such a means of control. Nor do higher priorities, just Medium High. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-ppc@freebsd.org Sat Apr 20 03:06:31 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 CF8A51581093 for ; Sat, 20 Apr 2019 03:06:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 6283B77CDB for ; Sat, 20 Apr 2019 03:06:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 22B491581091; Sat, 20 Apr 2019 03:06:30 +0000 (UTC) Delivered-To: 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 0E584158108F for ; Sat, 20 Apr 2019 03:06:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9108F77CD6 for ; Sat, 20 Apr 2019 03:06:29 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id D15A01FF5B for ; Sat, 20 Apr 2019 03:06:28 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x3K36Scv038077 for ; Sat, 20 Apr 2019 03:06:28 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x3K36SGY038068 for ppc@FreeBSD.org; Sat, 20 Apr 2019 03:06:28 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: ppc@FreeBSD.org Subject: [Bug 233863] r345425 on PowerMac G5 may require kern.smp.disabled=1 and must set usefdt=1 which causes net interface reorder Date: Sat, 20 Apr 2019 03:06:28 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: marklmi26-fbsd@yahoo.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: ppc@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.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, 20 Apr 2019 03:06:31 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D233863 --- Comment #17 from Mark Millard --- Created attachment 203812 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D203812&action= =3Dedit Investigatory sys/powerpc/powerpc/mp_machdep.c patch to avoid stuck-sleeping problem So far in preliminary testing on the PowerMac11,2, avoiding the hardware priority change from "or 31,31,31" use when looping to find ap_letgo changed has avoided my hack reporting any cases of applying the workaround. (Nor does the code now do a "or 6,6,6" to put back the orginal hardware priority.) I changed things to be more like sequentially consistent handling and made the bsp slightly more like the APs in hopes of getting more similar timing to when platform_smp_timebase_sync happens. I changed code in machdep_ap_bootstrap and in cpu_mp_unleash . I've also tested a 2-socket/1-core-each 970 G5 PowerMac11,2 a little. It still booted fine and still has never reported the workaround ever having to been applied. I will build 32-bit powerpc FreeBSD and try it as well, including on a 2-socket/1-core-each 7455 G4 PowerMac3,6. I'm actually not surprised that only the multi-core context actually behaves differently for "or 31,31,31" use (setting lowest priority mode): I do not see that being something that happens across sockets but only more locally. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-ppc@freebsd.org Sat Apr 20 03:19:54 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 517431581648 for ; Sat, 20 Apr 2019 03:19:54 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-22.consmr.mail.gq1.yahoo.com (sonic310-22.consmr.mail.gq1.yahoo.com [98.137.69.148]) (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 C2C788036A for ; Sat, 20 Apr 2019 03:19:52 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: FDdSWLcVM1loSVb7IzXCifL_WxIU.W5tMaxT6T3Jg2BfRIs2Yv3YBxlTJVMsbUH lgiAfGQIfHw.1r8wvERdFFMk_VqIvt0iQShB.LzZPIGpKYQ3bL7CkZP25IE8RH4QwfDwF9KhVVLt 5vnNntTz3S1tovvr9A7PzoMYLFbvhStYReY_RKw9PVdNLK_1ARDSV3.zF_DyHIZO.MF1NKtT10DK JinhbAcdeZELOW8qRtVmPh.wrDIW1wQQXaHteSdnEhLeyPofDpv2PONKpshcWLDrlvF7C.lauT.7 LQduvGgde7aEMo54P5.8V4srbtpqdPI4pPmesXT_V6zpZgD4Gi9apADSWiQCdKRNHS9JfgaZJ4xI uKPa2n3vpTeBxSBpyHbgVd0qQxmAn99kMHSVrLmNDstWw2PfEtt.hHUQdQ4fH0WVFm5FYRuHpZxg IGhRUu774XNSgkg.sPJ3YQUw6BWydrmgZjgbDa9ZjbyaoaXJSjUwyJSnq1AAlg6i4Z_MI4L2x_RZ PmLT6mGMdwpCykU8MlfX9KaLV1.I88tMJzTy3SkuenH8IdQu.F5r.FP9MOLsHFYkf8Kf3L0ujcY0 leRVGInbrlSXwu7smA7Dlrnb8ND4z8kVXExq4xdq47EhuD.ZBPGhTSk8sjU3wKqNqvS9soIHWKry ZtyNlUCNbaWF5CIF32BWIqsdOdCRg4Tv9XonNy54akbARN5_Nc48VzEGu2oNbCmFta2o7OMlL7uh 8XKv2T2wWUXbOwIKMqlTfIcRG3Ps_QG8pMJ.mFRDVPyoR6Qhx8SOpGUB6Aaq8YXMjYbMKj3k8vjd L8Xnq8rt.dDLC.pBQW2kls8q48Bd.J_M5VVjS82m7TnLD8qCVEb0WxA020j6VbtgQJRJdChJMiBm GHgFYOJEPIweJS1eCwX2lxtz34.i.QaWUC7MGGcmtl.u9W.kIfdCDQcacX5VImQfrbO1Oa5yeof9 21ZlmGc6HtZXAnm_5WhVs7K3lu_P2OqjZNtq19WEsJXI9M5mUi_pFfWebeFJPfAPKBXRNXvKjymU .6p5Y0s1EnE6.1vTCbK6bkZb65KMUF73b5WyrQprykdhLOI_PQJpH23Czi_BRecc4QluZ.oAGD1z KxuRIJD6j8HbspvGljJtDrmWW376d Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Sat, 20 Apr 2019 03:19:46 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.103]) ([76.115.7.162]) by smtp409.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 34a08568e063d8e914dda18eeadadc54; Sat, 20 Apr 2019 03:09:35 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Subject: Re: Patches to allow usefdt mode that works on a 2 socket PowerMac3, 6 example too --and makes more work on 2-socket/1-core-each PowerMac11, 2 From: Mark Millard In-Reply-To: <1B999D64-036F-4553-B024-93D0150FD60D@yahoo.com> Date: Fri, 19 Apr 2019 20:09:35 -0700 Cc: freebsd-ppc@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <433A1839-8232-4785-91AD-1EF5EAF31294@yahoo.com> References: <988F644F-D5E7-4FB4-AAB3-A72E9DA88CE6@yahoo.com> <465DBF40-EEF5-4D4A-95F6-DF17EB5B130B@yahoo.com> <5aecd21e-e53c-f14c-0bdc-8732fa88fed6@blastwave.org> <55E83F50-197D-43C7-B4D6-E69A5AEC2630@yahoo.com> <1B999D64-036F-4553-B024-93D0150FD60D@yahoo.com> To: Dennis Clarke X-Mailer: Apple Mail (2.3445.104.8) X-Rspamd-Queue-Id: C2C788036A X-Spamd-Bar: - X-Spamd-Result: default: False [-1.41 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(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]; 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]; 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)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.81)[-0.811,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.49)[0.489,0]; NEURAL_HAM_LONG(-0.97)[-0.975,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.40)[ip: (0.38), ipnet: 98.137.64.0/21(0.92), asn: 36647(0.74), country: US(-0.06)]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[148.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, 20 Apr 2019 03:19:54 -0000 [I have added an investigatory patch that so far has stopped the stuck-sleeping problem.] On 2019-Apr-15, at 00:06, Mark Millard wrote: > On 2019-Apr-13, at 11:39, Mark Millard wrote: >=20 >> [My adjustment to fdt_add_subnode_namelen was inept.] >>=20 >> On 2019-Apr-12, at 16:17, Mark Millard wrote: >>=20 >>> On 2019-Apr-12, at 14:20, Dennis Clarke = wrote: >>>=20 >>>> On 4/12/19 4:51 PM, Mark Millard wrote: >>>>> On 2019-Apr-12, at 13:13, Dennis Clarke = wrote: >>>>>> On 4/12/19 3:19 PM, Mark Millard via freebsd-ppc wrote: >>>> . >>>> . >>>> . >>>>>>=20 >>>>>> Would you be so kind as to paste all this into : >>>>>>=20 >>>>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D233863 >>>>>>=20 >>>>>> Really I would like to run some tests and follow up in the bug = reports. >>>>> Okay I'll paste them in as attachments. But be warned: >>>>=20 >>>> Fair warning received loud and clear :-) >>>>=20 >>>>> The 2 files do not deal with threads being stuck sleeping >>>>> (and, so, the fans going) or other such. The stuck-sleeping >>>>> problem happens for both multi-socket G5's and multi-socket >>>>> G4's. (I do not have access to single-socket multi-core >>>>> powerpc64 or powerpc machines to test.) >>>>=20 >>>> I have multiple G5 type boxen and will try them out. At least try >>>> to. >>>>=20 >>>>> So do not expect too much from these patches: They address >>>>> some necessary issues but are not sufficient for everything. >>>>>=20 >>>>=20 >>>> Of course. No problem. >>>>=20 >>>>=20 >>>>> These patches for the openfirmware->fdt translation are >>>>> closer to being reasonable for FreeBSD official use >>>>> than my highly context-specific stuck-sleeping patches for >>>>> usefdt mode. >>>>=20 >>>> Well to be frank we know this is for mac g5 hardware and thus = having >>>> them working at all in any fashion is better than the current = situation. >>>> Apple made a ton of them and they are dirt cheap and available as >>>> opposed to the IBM Power situation which is expensive and just in >>>> datacenters. >>>=20 >>>=20 >>> I have added another attachment with patches for having hang-ups >>> at AP startup happen less often. These are in AIM-specific code >>> and so has less of a chance of causing other contexts problems. >>> They are also powerpc64 specific. Again, the patches are >>> investigatory and not in a form for direct check-in to FreeBSD. >>>=20 >>> This pair of patches narrows the time period over which threads >>> from the stages: >>>=20 >>> SI_SUB_KTHREAD_INIT =3D 0xe000000, /* init process*/ >>> SI_SUB_KTHREAD_PAGE =3D 0xe400000, /* pageout daemon*/ >>> SI_SUB_KTHREAD_VM =3D 0xe800000, /* vm daemon*/ >>> SI_SUB_KTHREAD_BUF =3D 0xea00000, /* buffer daemon*/ >>> SI_SUB_KTHREAD_UPDATE =3D 0xec00000, /* update daemon*/ >>> SI_SUB_KTHREAD_IDLE =3D 0xee00000, /* idle procs*/ >>> #ifndef EARLY_AP_STARTUP >>> SI_SUB_SMP =3D 0xf000000, /* start the APs*/ >>> #endif=20 >>>=20 >>> can conflict with starting an AP via an slb replacement position >>> picked via expressions like mftb()%n_slbs . It does this by=20 >>> explicitly picking and setting up a slb slot for its use just >>> before starting the AP. >>>=20 >>> (The AP has to be part way along before it can do its own >>> automatic-random-slb-slot-replacements from what I can tell.) >>>=20 >>> The patches do not remove the race and still do sometimes fail to >>> prevent getting a hang-up on a AP start. But it greatly decreased >>> the rate of hangups in my testing. (So it is a good source of >>> evidence about the original problem.) >>>=20 >>> If EARLY_AP_STARTUP was supported and used, the AP startup would >>> not have hang-up problems from mftb()%n_slbs based slb >>> replacements for other threads. >>>=20 >>> The patches are a hack, rather than a general/complete fix --and >>> I do not expect to see them in FreeBSD. But they do help set up >>> a better context for investigating other things. >>=20 >> The disabling of blocking duplicate paths in fdt_add_subnode_namelen >> was done incorrectly. I'll replace the attachment after building >> and testing. I think this is the explanation for the PowerMac11,2 >> shutdown -r or -p problems. >>=20 >> The code should have just disabled the return, more like: >>=20 >> if (offset >=3D 0) >> #if 0 >> // Some Macintoshes have identical package-to-pathname results for >> // multiple nodes of the same type and unit under the parent node. >> // Avoid blocking this for fdt. >> return -FDT_ERR_EXISTS; >> #else >> ; >> #endif >> else if (offset !=3D -FDT_ERR_NOTFOUND) >> return offset; >>=20 >> Instead the messed up change did the "return offset;" and >> so did not do the addition of the node, instead returning >> the pre-existing one to be manipulated. >=20 >=20 > I've managed to boot the 2-socket/1-core-each G5 PowerMac7,2 in > usefdt mode. I've added another attachment for patching 3 more > files, also shown below: >=20 > Index: /usr/src/sys/powerpc/powermac/hrowpic.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /usr/src/sys/powerpc/powermac/hrowpic.c (revision 345758) > +++ /usr/src/sys/powerpc/powermac/hrowpic.c (working copy) > @@ -169,7 +169,7 @@ > hrowpic_write_reg(sc, HPIC_ENABLE, HPIC_SECONDARY, 0); > hrowpic_write_reg(sc, HPIC_CLEAR, HPIC_SECONDARY, 0xffffffff); >=20 > - powerpc_register_pic(dev, ofw_bus_get_node(dev), 64, 0, = FALSE); > + powerpc_register_pic(dev, = OF_xref_from_node(ofw_bus_get_node(dev)), 64, 0, FALSE); > return (0); > } >=20 > Index: /usr/src/sys/powerpc/powermac/uninorth.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /usr/src/sys/powerpc/powermac/uninorth.c (revision 345758) > +++ /usr/src/sys/powerpc/powermac/uninorth.c (working copy) > @@ -181,7 +181,7 @@ > <=3D 0) > panic("Interrupt but no interrupt parent!\n"); >=20 > - if (OF_searchprop(iparent, "#interrupt-cells", &icells, = sizeof(icells)) > + if (OF_searchprop(OF_node_from_xref(iparent), = "#interrupt-cells", &icells, sizeof(icells)) > <=3D 0) > icells =3D 1; >=20 > Index: /usr/src/sys/powerpc/powerpc/openpic.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /usr/src/sys/powerpc/powerpc/openpic.c (revision 345758) > +++ /usr/src/sys/powerpc/powerpc/openpic.c (working copy) > @@ -37,6 +37,8 @@ > #include > #include >=20 > +#include > + > #include > #include > #include > @@ -220,7 +222,7 @@ > for (cpu =3D 0; cpu < sc->sc_ncpu; cpu++) > openpic_write(sc, OPENPIC_PCPU_TPR(cpu), 0); >=20 > - powerpc_register_pic(dev, node, sc->sc_nirq, 4, FALSE); > + powerpc_register_pic(dev, OF_xref_from_node(node), = sc->sc_nirq, 4, FALSE); >=20 > /* If this is not a cascaded PIC, it must be the root PIC */ > if (sc->sc_intr =3D=3D NULL) The patch is: # svnlite diff /usr/src/sys/powerpc/powerpc/mp_machdep.c | more Index: /usr/src/sys/powerpc/powerpc/mp_machdep.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/powerpc/powerpc/mp_machdep.c (revision 345758) +++ /usr/src/sys/powerpc/powerpc/mp_machdep.c (working copy) @@ -77,9 +77,10 @@ PCPU_SET(awake, 1); __asm __volatile("msync; isync"); =20 + powerpc_sync(); while (ap_letgo =3D=3D 0) - __asm __volatile("or 31,31,31"); - __asm __volatile("or 6,6,6"); + powerpc_sync(); + isync(); =20 /* * Set timebase as soon as possible to meet an implicit = rendezvous @@ -262,8 +263,11 @@ __asm __volatile("msync; isync"); =20 /* Let APs continue */ - atomic_store_rel_int(&ap_letgo, 1); + ap_letgo=3D 1; // depend on prior sync, no need to lwsync = first =20 + powerpc_sync(); // analogous to what the ap's do (more similar = time frame?) + if (ap_letgo) isync(); + platform_smp_timebase_sync(ap_timebase, 0); =20 while (ap_awake < smp_cpus) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-ppc@freebsd.org Sat Apr 20 03:36:27 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 244F51581F4E for ; Sat, 20 Apr 2019 03:36:27 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-23.consmr.mail.gq1.yahoo.com (sonic304-23.consmr.mail.gq1.yahoo.com [98.137.68.204]) (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 2874980CC9 for ; Sat, 20 Apr 2019 03:36:26 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: w0ZpVtIVM1nMRFFl5jh36Q0XSgfU_JpYZpsUYEvTd2PMuBwczLnth8cYFG7AHHH oO3ugkoyxS0ZH6Hzh62Fa8wvxLdwA0JnNNGEUzvRqvrSRwpRkPBb1usYQj00zC7h5oad5hSJjOXO B1LuzV6.U090DPqyKJrFF4rWf3lYOXUGv4IqDrXecOSwWznYVlANlXlOlGtvFUy6pfTcVsgDRN66 DWzNwzFGnn9wi8QHVMdH998c6xymgUpRPQomejdexKeskcqdhtjhNWUKaFk6YY4cFc1pQQbTxaX2 ni.wdg4GR53NQ83CA0wgt9go3ISK7qNH2aW3jMYAmzliUdbv5S1giGr4OsgbJBzGLOhpukAKvOp_ DII_PHIQVSS8Os8Bdk_3rBV9AxKj9GMmFbA_knz1sXtIhiJVAX_sAWFlG1jsz82PSQUfj.12CEPK RCV5NgNtGgfJf2g4kadCVrjXhBRGju_9DTNk8H5q9zip7DzTtEzoI4p7axws84DHzF7LhmZqCHmn 5pJDM13iFSy1ocXy.nz.G0W1HImUkWOWaOx27aPuOxiOACjE1ESdU4mkmUHxEXoIdKSO42IKvILD N.rIUMrfPl1JOKI97qZrRi5OkjwrlSlxDkbhiV0G.eBLITZ4Xy0K3dYHJyQx1_oZX0QiOvak0zPm nwWXs4SkvJbulPoruyZVOosp5liQpPwtSTkcuQHhCvClK84KOrXumIBA3GC1JXZbmM1tqgp1nH4o Dg_eT4cEpCyT3gOaTGCSTfDzf5OeM6Zxn_1cmqD5.A3pCW4NVSz.476gCAlLa7_gq394hiXfOy3a 2QjI81uJHdG8Cla_lCS.VLwtusWNtIFJWpqhgj5Ieu87q2uW.waa_XCHX6TEhWoIQAZ55A7Yy_NQ .0_Fm8ZD6Vx4LBUURxzk2Tgjl69gOoErYfJMTvz.MX6RmDXd53yPYBQXqRk71WItRiwJE9l.HjyP N3G4EKliO2z2TDn3JmmDrb_.WPguOTo0dXMWjM0rwLvujVnEMe0aF3BrN7RKyPWzLtK6GFTUB.7z LK6FD1NG6kYkicuYuPQew1jOVLIoMxF3mf2h8ECtwIl2RHSXi1Ya15scAGJKPPkZnDqkiYueB8rL kUnmRnUGGVQvpQW5tFNTyK8Vm81mjWfCa Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Sat, 20 Apr 2019 03:36:19 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.103]) ([76.115.7.162]) by smtp416.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 034bf99776395f961cc0d6e4f4eab43b; Sat, 20 Apr 2019 03:36:17 +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: Looks like ap_letgo use needs platform specific code to allow avoiding the "sleep-gets-stuck" problem on PowerMac11,2's . . . Message-Id: Date: Fri, 19 Apr 2019 20:36:16 -0700 To: FreeBSD PowerPC ML , Justin Hibbits X-Mailer: Apple Mail (2.3445.104.8) X-Rspamd-Queue-Id: 2874980CC9 X-Spamd-Bar: +++ X-Spamd-Result: default: False [3.64 / 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)[]; MX_GOOD(-0.01)[cached: mta6.am0.yahoodns.net]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; 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)[]; 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)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(0.90)[0.898,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(2.03)[ip: (8.54), ipnet: 98.137.64.0/21(0.92), asn: 36647(0.74), country: US(-0.06)]; NEURAL_SPAM_MEDIUM(0.54)[0.541,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.68)[0.678,0]; RCVD_IN_DNSWL_NONE(0.00)[204.68.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, 20 Apr 2019 03:36:27 -0000 [Note: My context is tied to getting usefdt mode operable on old PowerMacs. The below is only tested for usefdt mode so far.] The following investigatory patch has so-far stopped my having sleep-gets-stuck problems (only seen on 2-socket/1-core-each 970 MP G5 Powermac11,2's as far as I know): # svnlite diff /usr/src/sys/powerpc/powerpc/mp_machdep.c | more = = Index: = /usr/src/sys/powerpc/powerpc/mp_machdep.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/powerpc/powerpc/mp_machdep.c (revision 345758) +++ /usr/src/sys/powerpc/powerpc/mp_machdep.c (working copy) @@ -77,9 +77,10 @@ PCPU_SET(awake, 1); __asm __volatile("msync; isync"); =20 + powerpc_sync(); while (ap_letgo =3D=3D 0) - __asm __volatile("or 31,31,31"); - __asm __volatile("or 6,6,6"); + powerpc_sync(); + isync(); =20 /* * Set timebase as soon as possible to meet an implicit = rendezvous @@ -262,8 +263,11 @@ __asm __volatile("msync; isync"); =20 /* Let APs continue */ - atomic_store_rel_int(&ap_letgo, 1); + ap_letgo=3D 1; // depend on prior sync, no need to lwsync = first =20 + powerpc_sync(); // analogous to what the ap's do (more similar = time frame?) + if (ap_letgo) isync(); + platform_smp_timebase_sync(ap_timebase, 0); =20 while (ap_awake < smp_cpus) Apparently, the use of "or 31,31,31" causes sizable variations in the time frame when the platform_smp_timebase_sync happens on the various cores across the two 970MPs. It looks something like a platform_ap_letgo_wait is appropriate, with a powermac_ap_letgo_wait specific one, say. (Or, possibly, AIM specific but spanning powermac?) The above patch has booted and operated the 2-socket PowerMac7,2 context fine as well so far. I'll check the G5's and a G4 dual-socket with a 32-bit powerpc build. I've no clue if there are any time-mismatch issues across sockets/cores/hw-threads for the "8-way SMT" contexts with "dozens to hundreds of CPUs". I've only been testing for part of today and I do not have access to any non-PowerMac PowerPC contexts. So this is preliminary but I do not expect "or 31,31,31" is going to be appropriate to the PowerMac11,2 contexts that caused my investigation of the issue. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-ppc@freebsd.org Sat Apr 20 03:48:46 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 801A61582173 for ; Sat, 20 Apr 2019 03:48:46 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-lf1-x143.google.com (mail-lf1-x143.google.com [IPv6:2a00:1450:4864:20::143]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C6588100C; Sat, 20 Apr 2019 03:48:45 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by mail-lf1-x143.google.com with SMTP id d12so5227952lfk.6; Fri, 19 Apr 2019 20:48:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jyf7H1fIBHwuCn33j4bcgXnGU9KEvmMihq+ThkpkCGQ=; b=iHEZwvSnZWMKd7yFZgx7lkXiw7BiRFW+8iQuR1TJukRx8oZSI3WB7WtVznMZ64+pZM bRZMWXE6cUcXdyJuqtTSvPIU7JukjhW3VoAtAxzKDyfxYKHJUehctlXNpiwlv0/HIPZf zFu7EznJqb+r688KSXLHbLlXR8YtHNP1ep6FR/ngUUlTVhNLPR7VPhrW2qqjFiQl6UBU 7kLcySoL9mu9bcI9rCGRMzbQc/4iet1GC+PFeuz8b7QKDSVZWauNbzuSCEL1AKZZkVU0 wpbZGMZHmv2gyRbJjPSlVAtrzzdEOOS61HZ4QcowXxwa4XKfLvr0ky0vS1r9cETHUnnf xi6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jyf7H1fIBHwuCn33j4bcgXnGU9KEvmMihq+ThkpkCGQ=; b=NufUA3cXQ3UpO3y+ghoLl8280p+E7hIx2KI7HCFz5FKST14+yUrz9hZ+64T0ACnj/O +zCrD6bIa3vExEz5rZX91E9NeBXVq5d0WkJY7erHpeLeylsUt1uhYkRavW/jsOYFLXaD vk/6DGr/vNU+TSSCRhyvi2aTZY4dCYlSWjE5cOqUECga4dFFM2hkBk2ZGsCxVTeWKT7e scaEMzVjbepcHEECkyo1vcJGMeRY6hb8WJFwnEmq8+r0LzK0El6DDcCSYRkpkxMpXYXR TnEaazQebqoaywaiY1w9rMTQq5g4ZFQco9MJ82mnqkalyVfbR+OI8uhuYXOozVYVvVdU OnBA== X-Gm-Message-State: APjAAAVdt4zCCdoRAi9PC/YKOum+F7pmr+LsO0SH57z1oglw5ePTHNPR 4ieUjSgVU/09PYL5k1Q9p+JtsDudTm6ji4f4Zn8= X-Google-Smtp-Source: APXvYqy8GyefJLZATvltC8CGGfQGf5v+A9Huzvus4gIGMR6WUt+kpJr/eEpB+YHPz6IaHN1EvyH5dWmWcY1TECrX98Q= X-Received: by 2002:ac2:50ca:: with SMTP id h10mr4043516lfm.31.1555732122766; Fri, 19 Apr 2019 20:48:42 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Justin Hibbits Date: Fri, 19 Apr 2019 22:48:31 -0500 Message-ID: Subject: Re: Looks like ap_letgo use needs platform specific code to allow avoiding the "sleep-gets-stuck" problem on PowerMac11,2's . . . To: Mark Millard Cc: FreeBSD PowerPC ML , Nathan Whitehorn Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4C6588100C X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=iHEZwvSn; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of chmeeedalf@gmail.com designates 2a00:1450:4864:20::143 as permitted sender) smtp.mailfrom=chmeeedalf@gmail.com X-Spamd-Result: default: False [-4.01 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.49)[-0.486,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[3.4.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; IP_SCORE(-0.51)[ip: (2.14), ipnet: 2a00:1450::/32(-2.38), asn: 15169(-2.26), country: US(-0.06)]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.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, 20 Apr 2019 03:48:46 -0000 On Fri, Apr 19, 2019 at 10:36 PM Mark Millard wrote: > > [Note: My context is tied to getting usefdt mode operable on > old PowerMacs. The below is only tested for usefdt mode > so far.] > > The following investigatory patch has so-far stopped my having > sleep-gets-stuck problems (only seen on 2-socket/1-core-each > 970 MP G5 Powermac11,2's as far as I know): > > # svnlite diff /usr/src/sys/powerpc/powerpc/mp_machdep.c | more Index: /usr/src/sys/powerpc/powerpc/mp_machdep.c > =================================================================== > --- /usr/src/sys/powerpc/powerpc/mp_machdep.c (revision 345758) > +++ /usr/src/sys/powerpc/powerpc/mp_machdep.c (working copy) > @@ -77,9 +77,10 @@ > PCPU_SET(awake, 1); > __asm __volatile("msync; isync"); > > + powerpc_sync(); > while (ap_letgo == 0) > - __asm __volatile("or 31,31,31"); > - __asm __volatile("or 6,6,6"); > + powerpc_sync(); > + isync(); > > /* > * Set timebase as soon as possible to meet an implicit rendezvous > @@ -262,8 +263,11 @@ > __asm __volatile("msync; isync"); > > /* Let APs continue */ > - atomic_store_rel_int(&ap_letgo, 1); > + ap_letgo= 1; // depend on prior sync, no need to lwsync first > > + powerpc_sync(); // analogous to what the ap's do (more similar time frame?) > + if (ap_letgo) isync(); > + > platform_smp_timebase_sync(ap_timebase, 0); > > while (ap_awake < smp_cpus) > > Apparently, the use of "or 31,31,31" causes sizable > variations in the time frame when the platform_smp_timebase_sync > happens on the various cores across the two 970MPs. > > It looks something like a platform_ap_letgo_wait is appropriate, > with a powermac_ap_letgo_wait specific one, say. (Or, possibly, > AIM specific but spanning powermac?) > > The above patch has booted and operated the 2-socket PowerMac7,2 > context fine as well so far. I'll check the G5's and a G4 > dual-socket with a 32-bit powerpc build. > > I've no clue if there are any time-mismatch issues across > sockets/cores/hw-threads for the "8-way SMT" contexts with > "dozens to hundreds of CPUs". > > I've only been testing for part of today and I do not have > access to any non-PowerMac PowerPC contexts. So this is > preliminary but I do not expect "or 31,31,31" is going to > be appropriate to the PowerMac11,2 contexts that caused > my investigation of the issue. Those nops are just that on the G5: nops. They do absolutely nothing on any processor that's not multithreaded. On multithreaded CPUs they are priority hints. What most likely 'fixed' the problem for you was the addition of the synchronization primitives in the code path. You can add them without sacrificing the nops. Does this patch fix the boot issue on the G5 quad without the usefdt=1 setting, and without reverting the KVA change? - Justin From owner-freebsd-ppc@freebsd.org Sat Apr 20 04:42:40 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 54162158314C for ; Sat, 20 Apr 2019 04:42:40 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-22.consmr.mail.gq1.yahoo.com (sonic310-22.consmr.mail.gq1.yahoo.com [98.137.69.148]) (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 CA43D82BA2 for ; Sat, 20 Apr 2019 04:42:37 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: iSrJO20VM1l8z2nfpTLCOan2iWEZHnRhhkUmpT8phLDOdtIQG3_UI1d08mLi53s k6XQLFyoQwFVaGCE0RxF33R5OQhuey9S8tNa_9gY920M_emL4PZDhBzyezvBjlYYkhr6epLFdJKm frT7OEqbQXrrDFpSS2qEHqVhFRBRENz0YaGJfRUoxNkL1TxYnSI19A9P7b.E36WKWyXxslsM2hq_ 2U5.K_DUXchIuIFpxQqSfpJxHbZKeDZdPbeIF9tmT5a3dX.qgZtkOB6N6SI2c3HjkXd0ZvUhN_M1 Z4Fy.178wOvK_MCzH0xVfsw62hr04EH1ch2ZqeMBIzvIGBg9rr_8TBVArq2R53IIdN7TcUVEf_7k t2Jaj610WSuoer9UT9mCp_GC5PnnZNovsXWHbaf1HU1IO93TnGcPNDuS1eh4xmyy5.GcTsy9lTgw dDoqRxAgSlrrB3K.sikcKrlHuXhfK7_ACSAL3GisjLpSYdnMx5OqhAvAk6UMy2prhzc_h1zyFWaJ GT403DcOaeMwCP2XLXHTVpZKZMxEFvw4GEmfVkFWSGQIgVl1Sls.y_xFfWDZ7LsGJQHwmHI5krjs yJCRhmvZUcx5g7OZqcwba3zGysEBW.EfL1015WWspgWIryw9iwyYVUsJ5NtTsh6v_teNTKya31PX UcQE0kNTk3veCkzgRARvBNCHEsW0SnzRGDkvDPADbEbUeGAC8tvH1Iv28R2bKARHZrP0ppreT5ND lYoZczpILDTdNHS14B_pYcjm7nqspAjbDTP1KuQlayGXHQUcJaq9Z2jE2HKASougNbP3cr0X.tmT FDKQZ9s4TuRYdxamQ4Ge1PNfmQJtURyqTtVQG9MECK4J31CeG1m9Wnx5i4uZVl8gN8L6SQ27dKVv 0mTHSVp8UY_RDHTBIKkmBwkPMlm8ZDa35HrOGRYx_cCUeNDlHIePNpFU61MLNqy2i1GC5ko6UkBR CsEtpd24wlOD05vBkORhHvBujZ8FLHNt8CNmGJGTLKOttt0ehi2mVef7OJ1js39UXh22Dyzua.6N ojBdWcMwlgwP_13Mo9UZakBcSxGwrR0J_IKJN..BkD_RWz_EV7Ln7vvUTDFaA1QZym63AVMRWTi9 gvemGbcNFYCjIRsZmasDH_X2oNI8.QEG17KCQKm6JGAYRccg9K9Y- Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Sat, 20 Apr 2019 04:42:35 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.103]) ([76.115.7.162]) by smtp418.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID a998c79b0943ce02a0510ad1ff3796ba; Sat, 20 Apr 2019 04:42:35 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Subject: Re: Looks like ap_letgo use needs platform specific code to allow avoiding the "sleep-gets-stuck" problem on PowerMac11,2's . . . From: Mark Millard In-Reply-To: Date: Fri, 19 Apr 2019 21:42:34 -0700 Cc: FreeBSD PowerPC ML , Nathan Whitehorn Content-Transfer-Encoding: quoted-printable Message-Id: <2E386EE0-782D-47CB-978B-B5A010AFCF88@yahoo.com> References: To: Justin Hibbits X-Mailer: Apple Mail (2.3445.104.8) X-Rspamd-Queue-Id: CA43D82BA2 X-Spamd-Bar: - X-Spamd-Result: default: False [-1.87 / 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]; 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)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.97)[-0.969,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(0.30)[0.301,0]; NEURAL_HAM_LONG(-0.99)[-0.993,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.30)[ip: (-0.10), ipnet: 98.137.64.0/21(0.92), asn: 36647(0.74), country: US(-0.06)]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[148.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, 20 Apr 2019 04:42:40 -0000 On 2019-Apr-19, at 20:48, Justin Hibbits = wrote: > On Fri, Apr 19, 2019 at 10:36 PM Mark Millard = wrote: >>=20 >> [Note: My context is tied to getting usefdt mode operable on >> old PowerMacs. The below is only tested for usefdt mode >> so far.] >>=20 >> The following investigatory patch has so-far stopped my having >> sleep-gets-stuck problems (only seen on 2-socket/1-core-each >> 970 MP G5 Powermac11,2's as far as I know): >>=20 >> # svnlite diff /usr/src/sys/powerpc/powerpc/mp_machdep.c | more = Index: = /usr/src/sys/powerpc/powerpc/mp_machdep.c >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- /usr/src/sys/powerpc/powerpc/mp_machdep.c (revision 345758) >> +++ /usr/src/sys/powerpc/powerpc/mp_machdep.c (working copy) >> @@ -77,9 +77,10 @@ >> PCPU_SET(awake, 1); >> __asm __volatile("msync; isync"); >>=20 >> + powerpc_sync(); >> while (ap_letgo =3D=3D 0) >> - __asm __volatile("or 31,31,31"); >> - __asm __volatile("or 6,6,6"); >> + powerpc_sync(); >> + isync(); >>=20 >> /* >> * Set timebase as soon as possible to meet an implicit = rendezvous >> @@ -262,8 +263,11 @@ >> __asm __volatile("msync; isync"); >>=20 >> /* Let APs continue */ >> - atomic_store_rel_int(&ap_letgo, 1); >> + ap_letgo=3D 1; // depend on prior sync, no need to lwsync = first >>=20 >> + powerpc_sync(); // analogous to what the ap's do (more = similar time frame?) >> + if (ap_letgo) isync(); >> + >> platform_smp_timebase_sync(ap_timebase, 0); >>=20 >> while (ap_awake < smp_cpus) >>=20 >> Apparently, the use of "or 31,31,31" causes sizable >> variations in the time frame when the platform_smp_timebase_sync >> happens on the various cores across the two 970MPs. >>=20 >> It looks something like a platform_ap_letgo_wait is appropriate, >> with a powermac_ap_letgo_wait specific one, say. (Or, possibly, >> AIM specific but spanning powermac?) >>=20 >> The above patch has booted and operated the 2-socket PowerMac7,2 >> context fine as well so far. I'll check the G5's and a G4 >> dual-socket with a 32-bit powerpc build. >>=20 >> I've no clue if there are any time-mismatch issues across >> sockets/cores/hw-threads for the "8-way SMT" contexts with >> "dozens to hundreds of CPUs". >>=20 >> I've only been testing for part of today and I do not have >> access to any non-PowerMac PowerPC contexts. So this is >> preliminary but I do not expect "or 31,31,31" is going to >> be appropriate to the PowerMac11,2 contexts that caused >> my investigation of the issue. >=20 > Those nops are just that on the G5: nops. They do absolutely nothing > on any processor that's not multithreaded. On multithreaded CPUs they > are priority hints. I thought PowerISA 2.03 was before multi-threaded (but spanning multi-core). It lists 31,31,31 in a table with other values. Is there a better match to the 970MP vintage of things for me to reference? I'll test: powerpc_sync(); while (ap_letgo =3D=3D 0) { __asm __volatile("or 31,31,31"); powerpc_sync(); } __asm __volatile("or 6,6,6"); isync(); (or some other such if you want). Let me know if you have some specific variation you prefer. > What most likely 'fixed' the problem for you was the addition of the > synchronization primitives in the code path. You can add them without > sacrificing the nops. Does this patch fix the boot issue on the G5 > quad without the usefdt=3D1 setting, and without reverting the KVA > change? We already had an exchange about my forcing an slb entry as needed for pcpup->pc_curpcb to be used. It massively changed the frequency of hangups (rare now). As a reminder, I had added hack_into_slb_if_needed(pcpup->pc_curpcb); in cpudep_ap_bootstrap. This was because other activity from: SI_SUB_KTHREAD_INIT =3D 0xe000000, /* init process*/ SI_SUB_KTHREAD_PAGE =3D 0xe400000, /* pageout daemon*/ SI_SUB_KTHREAD_VM =3D 0xe800000, /* vm daemon*/ SI_SUB_KTHREAD_BUF =3D 0xea00000, /* buffer daemon*/ SI_SUB_KTHREAD_UPDATE =3D 0xec00000, /* update daemon*/ SI_SUB_KTHREAD_IDLE =3D 0xee00000, /* idle procs*/ #ifndef EARLY_AP_STARTUP SI_SUB_SMP =3D 0xf000000, /* start the APs*/ #endif=20 was competing for slb entries and doing slb entry replacements in parallel with the ap startup activity so sometimes no slot covered the pcpup->pc_curpcb relted address range. (Replacement slots are picked based on mftb()%n_slbs .) Are you asking me to disable that call and see what happens? With the hack_into_slb_if_needed call and the other patches reported in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D233863 I'm booting and using historical and usefdt modes just fine as far as I've tested. (usefdt mode needing vt.) The patches do not involve reverting the KVA change. One of the test machines is=20 a "G5 quad" and its is the primary one I build on and test. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-ppc@freebsd.org Sat Apr 20 05:17:39 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 5051E15837E7 for ; Sat, 20 Apr 2019 05:17:39 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id D94C48350D for ; Sat, 20 Apr 2019 05:17:38 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 981EB15837E6; Sat, 20 Apr 2019 05:17:38 +0000 (UTC) Delivered-To: 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 865E515837E5 for ; Sat, 20 Apr 2019 05:17:38 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2201F8350A for ; Sat, 20 Apr 2019 05:17:38 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 590D212A9 for ; Sat, 20 Apr 2019 05:17:37 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x3K5HbhV046009 for ; Sat, 20 Apr 2019 05:17:37 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x3K5Hbx3046007 for ppc@FreeBSD.org; Sat, 20 Apr 2019 05:17:37 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: ppc@FreeBSD.org Subject: [Bug 233863] r345425 on PowerMac G5 may require kern.smp.disabled=1 and must set usefdt=1 which causes net interface reorder Date: Sat, 20 Apr 2019 05:17:36 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: marklmi26-fbsd@yahoo.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: ppc@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.isobsolete attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.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, 20 Apr 2019 05:17:39 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D233863 Mark Millard changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #203812|0 |1 is obsolete| | --- Comment #18 from Mark Millard --- Created attachment 203814 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D203814&action= =3Dedit Investigatory sys/powerpc/powerpc/mp_machdep.c patch to avoid stuck-sleeping problem Justin Hibbits reported that the "or 31,31,31" and "or 6,6,6" could be left in (mixed with my other changes) and the 970MP's would not change their boot behavior for the PwerMac11,2. I tried it and he seems to be correct based on a little quick testing. This might avoid needing palatform-specific code for handling the ap_letgo behavior. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-ppc@freebsd.org Sat Apr 20 05:28:41 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 EF9BA1583B69 for ; Sat, 20 Apr 2019 05:28:40 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-15.consmr.mail.bf2.yahoo.com (sonic311-15.consmr.mail.bf2.yahoo.com [74.6.131.125]) (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 9E5F9838B1 for ; Sat, 20 Apr 2019 05:28:39 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 9pW51qMVM1mOaSHsfci6m9rKPFdPyJ0YIobuStnj7nEVhUG1A__NHY1edb_RGVr ZFLKePrp7rjnehtQMlQcG3gVEJTvqgysSOCO7Tue5dz.NZfAF4Z3s4wAIJC9Og.76glDgaH_ZEC1 nub58ey6siEhU7Q7wwgIN5MKjJZt.un71iozp6eW_9AFffI6WX9H93aFwSO6Z0QHGg7.mL8VQeS7 1SNO2KM4nV0VhRbjjACvfsxPOKW3czaUpNWzdldo8O51wqZ8v7xu23BdSqjYsWzO68a3o2fv.yYx ZHOnc5_S_KBejE3tD3Q6dm6SqxBJq7alGhTxiZ9DNExj7jJwbirzz5051cVn00NczJRH6ZiFt.M4 8FIRc3Ty3JVAK6WycLXwMnLreMtZELeDEER9TQuWy7hf9jLoxrs48esJFvwu1urN9LsdQH.WzniX K84QFicKI85RwmpaSdLFQPku6E8yZPlPPDe1h3U4nOqxZn8DQFrxIh63X0sXOLujfPn32rzWYzHu TMDq6F1TIM3u817VPNT7JCeIQz9ARhfnizWwG6mOuwjUmO7QMZvrBCwX2VaX.ymVYvH_KnOAStFn 9._.d2_LTFaLQVcCig_GpLWDLLKZ1yKkMFJznOMX.Fxu8I0E1E_zuT5n5NpW1Y.oDWXJFH4hdS4W 9qjlmOKhS6aR7lfKgc7V34YHC2dgckYp_xjPkYn79qj7fqkcCbe84OdROLqMk3NPqqs5f3AC0kGT NXafCcxSF3oiCuTCVVL5dReyh.P9Prc7OGOqXVHnQnOOGNx5DmEC4UJIzK5y99nAGq_qbpgy1wdb VkGDDU3xV_YvYgIxZiu.j35SFag4j3iEVP1keFK.9LfM3LoVGeNntXcYWoaCmkNawJLZMppPUm0B QD4vh7hejvBmzcYXFqKjPxg3RJxFDBlLp4k9TJP5I_2FcfDB95i5OTz9FZR_W_K.hC8QG.gUFBqo nxmLb7iqifBL3b9UPTgR8kSzWRGZcdWms0doActG_7dvysx8X6C.SH33nSFi5Gf3vEeLm2RD6XKO xei4zkjqIhjiJ4JXlyW7.zs2WXmsm_xqTwKw.rMUHQT1jMfOr2q.PqguRGNGKLEpbT0306O.KfDd oedZcIBhYVlhcoyeA0Sxgy6DkJ9yU1LZkOURWq.8G5yKUlHfexblJvQ-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.bf2.yahoo.com with HTTP; Sat, 20 Apr 2019 05:28:32 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.103]) ([76.115.7.162]) by smtp431.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID c960cde5cbb4bb46736754232f44689a; Sat, 20 Apr 2019 05:28:28 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Subject: Re: Looks like ap_letgo use needs platform specific code to allow avoiding the "sleep-gets-stuck" problem on PowerMac11,2's . . . From: Mark Millard In-Reply-To: <2E386EE0-782D-47CB-978B-B5A010AFCF88@yahoo.com> Date: Fri, 19 Apr 2019 22:28:26 -0700 Cc: FreeBSD PowerPC ML , Nathan Whitehorn Content-Transfer-Encoding: quoted-printable Message-Id: <1C697AD4-6CAC-4C33-8D77-72D9B53A7648@yahoo.com> References: <2E386EE0-782D-47CB-978B-B5A010AFCF88@yahoo.com> To: Justin Hibbits X-Mailer: Apple Mail (2.3445.104.8) X-Rspamd-Queue-Id: 9E5F9838B1 X-Spamd-Bar: ++ X-Spamd-Result: default: False [2.06 / 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]; 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:26101, ipnet:74.6.128.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)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(0.85)[0.851,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(1.23)[ip: (3.33), ipnet: 74.6.128.0/21(1.59), asn: 26101(1.27), country: US(-0.06)]; NEURAL_SPAM_MEDIUM(0.19)[0.187,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.31)[0.309,0]; RCVD_IN_DNSWL_NONE(0.00)[125.131.6.74.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, 20 Apr 2019 05:28:41 -0000 [The or 31,31,31 and or 6,6,6 test behaved as you said.] On 2019-Apr-19, at 21:42, Mark Millard wrote: > On 2019-Apr-19, at 20:48, Justin Hibbits = wrote: >=20 >> On Fri, Apr 19, 2019 at 10:36 PM Mark Millard = wrote: >>>=20 >>> [Note: My context is tied to getting usefdt mode operable on >>> old PowerMacs. The below is only tested for usefdt mode >>> so far.] >>>=20 >>> The following investigatory patch has so-far stopped my having >>> sleep-gets-stuck problems (only seen on 2-socket/1-core-each >>> 970 MP G5 Powermac11,2's as far as I know): >>>=20 >>> # svnlite diff /usr/src/sys/powerpc/powerpc/mp_machdep.c | more = Index: = /usr/src/sys/powerpc/powerpc/mp_machdep.c >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> --- /usr/src/sys/powerpc/powerpc/mp_machdep.c (revision 345758) >>> +++ /usr/src/sys/powerpc/powerpc/mp_machdep.c (working copy) >>> @@ -77,9 +77,10 @@ >>> PCPU_SET(awake, 1); >>> __asm __volatile("msync; isync"); >>>=20 >>> + powerpc_sync(); >>> while (ap_letgo =3D=3D 0) >>> - __asm __volatile("or 31,31,31"); >>> - __asm __volatile("or 6,6,6"); >>> + powerpc_sync(); >>> + isync(); >>>=20 >>> /* >>> * Set timebase as soon as possible to meet an implicit = rendezvous >>> @@ -262,8 +263,11 @@ >>> __asm __volatile("msync; isync"); >>>=20 >>> /* Let APs continue */ >>> - atomic_store_rel_int(&ap_letgo, 1); >>> + ap_letgo=3D 1; // depend on prior sync, no need to lwsync = first >>>=20 >>> + powerpc_sync(); // analogous to what the ap's do (more = similar time frame?) >>> + if (ap_letgo) isync(); >>> + >>> platform_smp_timebase_sync(ap_timebase, 0); >>>=20 >>> while (ap_awake < smp_cpus) >>>=20 >>> Apparently, the use of "or 31,31,31" causes sizable >>> variations in the time frame when the platform_smp_timebase_sync >>> happens on the various cores across the two 970MPs. >>>=20 >>> It looks something like a platform_ap_letgo_wait is appropriate, >>> with a powermac_ap_letgo_wait specific one, say. (Or, possibly, >>> AIM specific but spanning powermac?) >>>=20 >>> The above patch has booted and operated the 2-socket PowerMac7,2 >>> context fine as well so far. I'll check the G5's and a G4 >>> dual-socket with a 32-bit powerpc build. >>>=20 >>> I've no clue if there are any time-mismatch issues across >>> sockets/cores/hw-threads for the "8-way SMT" contexts with >>> "dozens to hundreds of CPUs". >>>=20 >>> I've only been testing for part of today and I do not have >>> access to any non-PowerMac PowerPC contexts. So this is >>> preliminary but I do not expect "or 31,31,31" is going to >>> be appropriate to the PowerMac11,2 contexts that caused >>> my investigation of the issue. >>=20 >> Those nops are just that on the G5: nops. They do absolutely nothing >> on any processor that's not multithreaded. On multithreaded CPUs = they >> are priority hints. >=20 > I thought PowerISA 2.03 was before multi-threaded (but spanning > multi-core). It lists 31,31,31 in a table with other values. Is > there a better match to the 970MP vintage of things for me to > reference? >=20 > I'll test: >=20 > powerpc_sync(); > while (ap_letgo =3D=3D 0) > { > __asm __volatile("or 31,31,31"); > powerpc_sync(); > } > __asm __volatile("or 6,6,6"); > isync(); >=20 > (or some other such if you want). Let me know if you > have some specific variation you prefer. Some quick testing seems to be doing what you indicated. I've updated https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D233863 to have the updated code. >> What most likely 'fixed' the problem for you was the addition of the >> synchronization primitives in the code path. You can add them = without >> sacrificing the nops. Does this patch fix the boot issue on the G5 >> quad without the usefdt=3D1 setting, and without reverting the KVA >> change? >=20 > We already had an exchange about my forcing an slb entry as > needed for pcpup->pc_curpcb to be used. It massively changed > the frequency of hangups (rare now). >=20 > As a reminder, I had added >=20 > hack_into_slb_if_needed(pcpup->pc_curpcb); >=20 > in cpudep_ap_bootstrap. This was because other > activity from: >=20 > SI_SUB_KTHREAD_INIT =3D 0xe000000, /* init process*/ > SI_SUB_KTHREAD_PAGE =3D 0xe400000, /* pageout daemon*/ > SI_SUB_KTHREAD_VM =3D 0xe800000, /* vm daemon*/ > SI_SUB_KTHREAD_BUF =3D 0xea00000, /* buffer daemon*/ > SI_SUB_KTHREAD_UPDATE =3D 0xec00000, /* update daemon*/ > SI_SUB_KTHREAD_IDLE =3D 0xee00000, /* idle procs*/ > #ifndef EARLY_AP_STARTUP > SI_SUB_SMP =3D 0xf000000, /* start the APs*/ > #endif=20 >=20 > was competing for slb entries and doing slb entry replacements in > parallel with the ap startup activity so sometimes no slot covered > the pcpup->pc_curpcb relted address range. (Replacement slots are > picked based on mftb()%n_slbs .) >=20 > Are you asking me to disable that call and see what happens? I've not done anything about disabling the replacement of an slb entry for spanning what pcpup->pc_curpcb-> refers to when there is no such spanning entry already. (The code makes no replacement if an entry does span the address range. So, effectively, then, the code is a no-op for such conditions.) > With the hack_into_slb_if_needed call and the other patches > reported in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D233863 > I'm booting and using historical and usefdt modes just fine > as far as I've tested. (usefdt mode needing vt.) The patches do > not involve reverting the KVA change. One of the test machines is=20 > a "G5 quad" and its is the primary one I build on and test. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-ppc@freebsd.org Sat Apr 20 06:08:24 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 5D8CD158455F for ; Sat, 20 Apr 2019 06:08:24 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-1.consmr.mail.bf2.yahoo.com (sonic301-1.consmr.mail.bf2.yahoo.com [74.6.129.40]) (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 EAFF38486C for ; Sat, 20 Apr 2019 06:08:22 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: aYWouAwVM1k8_orAXUgOPelYqKSCdgkjrtFziZrQ36FG17IeFW9lXnxo.UhIbCH Oz4gmQzlFtkjl.HQjZUtabc8Eq_OyQSapPkia9iHH4DD0BurVWVOUazQfjcgfusQqO7gS9Y6uc1x KHUc7zgctTJSD.hT7SnV9sYHB.6fbUBc1QBUj4vOiQNBXTnBupiMJx712aWg4kGupW.bSfQwa1I. UeRkIGFaOsQ4BGiX.IBJCjh7O5kvnXjGZlXmMR5TUs1mKBSQYMdHgwz0rlDrHuWur0Q98dg50sKe EURFvquOMNwycV9jckPMYGBrCjdJkO3gfuRP1uyszutVeVfCQHhF2l3etW__ilVRWAK46Qq7I1te SMvYidWX1cY6X8S6kX9RuQ6vLOkgkvF3LsyQeUb2cGaTbIB0I3Z9NXh2AdBAqJdaAWlZPj2o0hAm HczREPlm.RO6BJtywJ7s9kt933cYFNd6gXtIqkJSfyEaqZ8J2IPdbny4MojQ5IT2iE4JGHx.gaSm Gc4EwIowSjhg1mtcJz3VaaGVJpqgcsvLrfKC7XoqciVumlzTf7MsdgaPu.PHB8Qj.QFxXb3NpVw4 6Z4wdIBgoHwdaIYIhMRRKmheMZd7qd8vClIenqP_NyPYtfBrGyvN7zuw.Uf6cQEGDgnncuiRt_DX ZNELvlSt8rUjN9RgrdRBycyHQbLCWQfMKjHtOpipIqY2KEkZW2cIhDpcY15hNCJJRpa6K5RcTzSE PYfF5zWs4a2M1DQNS28J45I07X0LEb5.f15VCSv2YAnAfZzdPVN29B1_fudXaZ6fm1kBCBYuKVhB O95HsOiTv8XkIXCJ2Ev4Cj7RaMR9zJ5RwXW.QqTmCog_UXwTrlSWUUL9hcLWtA2x7I21YDO9LV86 f4mICASCCP_rrmhoLoOBiCFLccjQMXVvBmhnsXWc9US._RFqIF_Ge3gsCLVt4v5m0pr8e11QAnWo Lxa6jI0vtWVT4arZ6UxWskRuLxSSuarK9nvoutWjmKlu99CMJk1vGMw5zUMy.VfofX61w4sI1uXw vr96M.VF5IP83H8wa3XNjTsb2hGUgn35X_dEdXxYOE_oIefKIDIU981ukhpdXKsZHMtpKujMu.kX s61drniSRle8c2rjMDdxkKis7y3CHI56jPSyo3cBRF0O5sqI8rq9L0bWX Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.bf2.yahoo.com with HTTP; Sat, 20 Apr 2019 06:08:16 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.103]) ([76.115.7.162]) by smtp423.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 560727f058887618dc31c447f9d31d4c; Sat, 20 Apr 2019 06:08:13 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Subject: Re: Looks like ap_letgo use needs platform specific code to allow avoiding the "sleep-gets-stuck" problem on PowerMac11,2's . . . From: Mark Millard In-Reply-To: <1C697AD4-6CAC-4C33-8D77-72D9B53A7648@yahoo.com> Date: Fri, 19 Apr 2019 23:08:10 -0700 Cc: FreeBSD PowerPC ML , Nathan Whitehorn Content-Transfer-Encoding: quoted-printable Message-Id: References: <2E386EE0-782D-47CB-978B-B5A010AFCF88@yahoo.com> <1C697AD4-6CAC-4C33-8D77-72D9B53A7648@yahoo.com> To: Justin Hibbits X-Mailer: Apple Mail (2.3445.104.8) X-Rspamd-Queue-Id: EAFF38486C X-Spamd-Bar: ++ X-Spamd-Result: default: False [2.49 / 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]; 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:26101, ipnet:74.6.128.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)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(0.86)[0.860,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; NEURAL_SPAM_MEDIUM(0.27)[0.265,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.52)[0.518,0]; RCVD_IN_DNSWL_NONE(0.00)[40.129.6.74.list.dnswl.org : 127.0.5.0]; IP_SCORE(1.36)[ip: (3.98), ipnet: 74.6.128.0/21(1.59), asn: 26101(1.27), 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: Sat, 20 Apr 2019 06:08:24 -0000 [https://wiki.raptorcs.com/wiki/Power_ISA has documents going back to 2.01 .] On 2019-Apr-19, at 22:28, Mark Millard wrote: > [The or 31,31,31 and or 6,6,6 test behaved as you said.] >=20 > On 2019-Apr-19, at 21:42, Mark Millard wrote: >=20 >> On 2019-Apr-19, at 20:48, Justin Hibbits = wrote: >>=20 >>> On Fri, Apr 19, 2019 at 10:36 PM Mark Millard = wrote: >>>>=20 >>>> [Note: My context is tied to getting usefdt mode operable on >>>> old PowerMacs. The below is only tested for usefdt mode >>>> so far.] >>>>=20 >>>> The following investigatory patch has so-far stopped my having >>>> sleep-gets-stuck problems (only seen on 2-socket/1-core-each >>>> 970 MP G5 Powermac11,2's as far as I know): >>>>=20 >>>> # svnlite diff /usr/src/sys/powerpc/powerpc/mp_machdep.c | more = = Index: /usr/src/sys/powerpc/powerpc/mp_machdep.c >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> --- /usr/src/sys/powerpc/powerpc/mp_machdep.c (revision 345758) >>>> +++ /usr/src/sys/powerpc/powerpc/mp_machdep.c (working copy) >>>> @@ -77,9 +77,10 @@ >>>> PCPU_SET(awake, 1); >>>> __asm __volatile("msync; isync"); >>>>=20 >>>> + powerpc_sync(); >>>> while (ap_letgo =3D=3D 0) >>>> - __asm __volatile("or 31,31,31"); >>>> - __asm __volatile("or 6,6,6"); >>>> + powerpc_sync(); >>>> + isync(); >>>>=20 >>>> /* >>>> * Set timebase as soon as possible to meet an implicit = rendezvous >>>> @@ -262,8 +263,11 @@ >>>> __asm __volatile("msync; isync"); >>>>=20 >>>> /* Let APs continue */ >>>> - atomic_store_rel_int(&ap_letgo, 1); >>>> + ap_letgo=3D 1; // depend on prior sync, no need to = lwsync first >>>>=20 >>>> + powerpc_sync(); // analogous to what the ap's do (more = similar time frame?) >>>> + if (ap_letgo) isync(); >>>> + >>>> platform_smp_timebase_sync(ap_timebase, 0); >>>>=20 >>>> while (ap_awake < smp_cpus) >>>>=20 >>>> Apparently, the use of "or 31,31,31" causes sizable >>>> variations in the time frame when the platform_smp_timebase_sync >>>> happens on the various cores across the two 970MPs. >>>>=20 >>>> It looks something like a platform_ap_letgo_wait is appropriate, >>>> with a powermac_ap_letgo_wait specific one, say. (Or, possibly, >>>> AIM specific but spanning powermac?) >>>>=20 >>>> The above patch has booted and operated the 2-socket PowerMac7,2 >>>> context fine as well so far. I'll check the G5's and a G4 >>>> dual-socket with a 32-bit powerpc build. >>>>=20 >>>> I've no clue if there are any time-mismatch issues across >>>> sockets/cores/hw-threads for the "8-way SMT" contexts with >>>> "dozens to hundreds of CPUs". >>>>=20 >>>> I've only been testing for part of today and I do not have >>>> access to any non-PowerMac PowerPC contexts. So this is >>>> preliminary but I do not expect "or 31,31,31" is going to >>>> be appropriate to the PowerMac11,2 contexts that caused >>>> my investigation of the issue. >>>=20 >>> Those nops are just that on the G5: nops. They do absolutely = nothing >>> on any processor that's not multithreaded. On multithreaded CPUs = they >>> are priority hints. >>=20 >> I thought PowerISA 2.03 was before multi-threaded (but spanning >> multi-core). It lists 31,31,31 in a table with other values. Is >> there a better match to the 970MP vintage of things for me to >> reference? https://wiki.raptorcs.com/wiki/Power_ISA has documents going back to 2.01, matching the 970. (I'm not sure of the 970FX and 9070MP details relative to 2.01 .) I had never found anything that early before. or rx,rx,rx being special starts in 2.02 (which spans the Power5 addition). >> I'll test: >>=20 >> powerpc_sync(); >> while (ap_letgo =3D=3D 0) >> { >> __asm __volatile("or 31,31,31"); >> powerpc_sync(); >> } >> __asm __volatile("or 6,6,6"); >> isync(); >>=20 >> (or some other such if you want). Let me know if you >> have some specific variation you prefer. >=20 > Some quick testing seems to be doing what you indicated. > I've updated https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D233863 > to have the updated code. >=20 >>> What most likely 'fixed' the problem for you was the addition of the >>> synchronization primitives in the code path. You can add them = without >>> sacrificing the nops. Does this patch fix the boot issue on the G5 >>> quad without the usefdt=3D1 setting, and without reverting the KVA >>> change? >>=20 >> We already had an exchange about my forcing an slb entry as >> needed for pcpup->pc_curpcb to be used. It massively changed >> the frequency of hangups (rare now). >>=20 >> As a reminder, I had added >>=20 >> hack_into_slb_if_needed(pcpup->pc_curpcb); >>=20 >> in cpudep_ap_bootstrap. This was because other >> activity from: >>=20 >> SI_SUB_KTHREAD_INIT =3D 0xe000000, /* init process*/ >> SI_SUB_KTHREAD_PAGE =3D 0xe400000, /* pageout daemon*/ >> SI_SUB_KTHREAD_VM =3D 0xe800000, /* vm daemon*/ >> SI_SUB_KTHREAD_BUF =3D 0xea00000, /* buffer daemon*/ >> SI_SUB_KTHREAD_UPDATE =3D 0xec00000, /* update daemon*/ >> SI_SUB_KTHREAD_IDLE =3D 0xee00000, /* idle procs*/ >> #ifndef EARLY_AP_STARTUP >> SI_SUB_SMP =3D 0xf000000, /* start the APs*/ >> #endif=20 >>=20 >> was competing for slb entries and doing slb entry replacements in >> parallel with the ap startup activity so sometimes no slot covered >> the pcpup->pc_curpcb relted address range. (Replacement slots are >> picked based on mftb()%n_slbs .) >>=20 >> Are you asking me to disable that call and see what happens? >=20 > I've not done anything about disabling the replacement of an > slb entry for spanning what pcpup->pc_curpcb-> refers to > when there is no such spanning entry already. (The code makes > no replacement if an entry does span the address range. > So, effectively, then, the code is a no-op for such conditions.) >=20 >> With the hack_into_slb_if_needed call and the other patches >> reported in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D233863 >> I'm booting and using historical and usefdt modes just fine >> as far as I've tested. (usefdt mode needing vt.) The patches do >> not involve reverting the KVA change. One of the test machines is=20 >> a "G5 quad" and its is the primary one I build on and test. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-ppc@freebsd.org Sat Apr 20 21:14:36 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 6217515763EB for ; Sat, 20 Apr 2019 21:14:36 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-9.consmr.mail.ne1.yahoo.com (sonic313-9.consmr.mail.ne1.yahoo.com [66.163.185.32]) (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 C8AA572687 for ; Sat, 20 Apr 2019 21:14:35 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: B9qUnGQVM1kP0ZYNl8PcaugSzL4kSQEeTW670Wk41sUE.q8IRcJLEVCjY0SXC9u nz3D2x5spGfuT3UdrIqeu775SJnJH9hkIFjQEfeWV4M_63M6qHjnCJoHZNsikC6_JnGObcGgKgLm PRL9lA3gyM098fKmsWNHW8nukmU_DGQ_4BIGrpCM8m8GUKy_86m3Zu55Mm9r4OLuA7H5wPVCjs8W Vmfyx0mQvMajwXNX4KBFAwxKjWXCIyayQyMeMDgqqDJCzHgQ9P9B.uZYYBdtl1EirxhcijcOeEXt yRdpUUqMds9EUFuQC1L2kD8W3NOg_ns1_pBGY.SwwnohlDVVqfh6AjYM7XYbkXhCTHdS1hbQPu9j qMcoB2OuH1sMgjLTxrWI5dsIzThDQuhxleFqM51ZohCgU81Q0o26vZ7B1Fqj1.n32o0KFpuTtFKI bft7ysmm_5rPtsYyNbwGdZbgLd2cS3qzJ946R6AkoaIF7472B1PKJqJxYQZt2w27xs9Gw.Zyqrue CzPnemzsJyMHezPDXFokTIoOKVEksSpbHsdL5AYXukTMnTk42PE4KeXV6FrAXfE7YIYBYJNISR_i AlfheDIeWmTvndI.mN9kwd8xmWlteDBoojPPmSE9qxHPjB20fwfVPHqJUn9JEsGr79TH33w.jwOs sIR02WsXk59TqNImFoUCbejlV0YlvH_T4abqQJD1XyaPfMPXPGwjeo3Tl.cXU03hGhy7kq6_bxQz zBvJZ.Ural1eJ9qK2cGCrS2aTO8YcDH8NFonhODVbEJXF5UVc4To2jeFob4edV0BPRquFXI1iA1I HK89UvXXghFWu9HXGxzkrZGCEr_MCF1qb28Slmj8msA5CXK.6a1IsADoP37h1_Karu0tjMFtDyKZ URDPTLDWs5Wz9lfxkL.g3iL_PTfbuSg9xpWgVeVc4oWooiSS3pQtuPBGUBNgSKOSb_UwF2jw3rbh GRWmLzN25W0iLwwMm67BRdw.6rOj02BA8ev5M7fWtwsrNftdbYYiEHtCRxXeJtzkgyoDP3RWz.8Y _PiDbLw6moR.oGmIdLyhFIjwHW5VU.u4meLOizpQz_arXdjzpBlllxpyZNXf7gJ4YYjqg7JEHZcu EbFy8CT_ozx6L2f9xv1h9mMWvZpfTSHDge950UpTXVlMwN4Nhatv2 Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.ne1.yahoo.com with HTTP; Sat, 20 Apr 2019 21:14:28 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.103]) ([76.115.7.162]) by smtp413.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 505e49c1107882107ed049dd4d8d1ca6; Sat, 20 Apr 2019 21:14:23 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Subject: Side subject: powerpc64 related PowerMac boot hangs slb details that drove having hack_into_slb_if_needed From: Mark Millard In-Reply-To: Date: Sat, 20 Apr 2019 14:14:22 -0700 Cc: FreeBSD PowerPC ML , Nathan Whitehorn Content-Transfer-Encoding: 7bit Message-Id: References: <2E386EE0-782D-47CB-978B-B5A010AFCF88@yahoo.com> <1C697AD4-6CAC-4C33-8D77-72D9B53A7648@yahoo.com> To: Justin Hibbits X-Mailer: Apple Mail (2.3445.104.8) X-Rspamd-Queue-Id: C8AA572687 X-Spamd-Bar: ++ X-Spamd-Result: default: False [2.69 / 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)[]; MX_GOOD(-0.01)[cached: mta6.am0.yahoodns.net]; DKIM_TRACE(0.00)[yahoo.com:+]; 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:36646, ipnet:66.163.184.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)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(0.94)[0.940,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(1.43)[ip: (4.62), ipnet: 66.163.184.0/21(1.43), asn: 36646(1.14), country: US(-0.06)]; NEURAL_SPAM_MEDIUM(0.33)[0.333,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.50)[0.501,0]; RCVD_IN_DNSWL_NONE(0.00)[32.185.163.66.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, 20 Apr 2019 21:14:36 -0000 [Looks like my memory was wrong about details of what is going on for the slb issue: the context. So, correcting, with newly looked-up detail and avoiding incorrect memories.] On 2019-Apr-19, at 23:08, Mark Millard wrote: . . . >>> Does this patch fix the boot issue on the G5 >>> quad without the usefdt=1 setting, and without reverting the KVA >>> change? >> >> We already had an exchange about my forcing an slb entry as >> needed for pcpup->pc_curpcb to be used. It massively changed >> the frequency of hangups (rare now). >> >> As a reminder, I had added >> >> hack_into_slb_if_needed(pcpup->pc_curpcb); More complete for cpudep_ap_bootstrap : pcpup->pc_curthread = pcpup->pc_idlethread; . . . pcpup->pc_curpcb = pcpup->pc_curthread->td_pcb; . . . #ifdef __powerpc64__ hack_into_slb_if_needed(pcpup->pc_curpcb); // HACK!!! #endif sp = pcpup->pc_curpcb->pcb_sp; The hack_into_slb_if_needed use is there to force pcpup->pc_curpcb-> use being possible this early, in other words enabling: pcpup->pc_idlethread->pc_curpcb-> This is based on expecting handle_kernel_slb_spill to not yet be working for the cpu being started. Later, once enough is set up for the cpu being started, handle_kernel_slb_spill should work. >> in cpudep_ap_bootstrap. This was because other >> activity from: >> >> SI_SUB_KTHREAD_INIT = 0xe000000, /* init process*/ >> SI_SUB_KTHREAD_PAGE = 0xe400000, /* pageout daemon*/ >> SI_SUB_KTHREAD_VM = 0xe800000, /* vm daemon*/ >> SI_SUB_KTHREAD_BUF = 0xea00000, /* buffer daemon*/ >> SI_SUB_KTHREAD_UPDATE = 0xec00000, /* update daemon*/ >> SI_SUB_KTHREAD_IDLE = 0xee00000, /* idle procs*/ >> #ifndef EARLY_AP_STARTUP >> SI_SUB_SMP = 0xf000000, /* start the APs*/ >> #endif >> >> was competing for slb entries and doing slb entry replacements in >> parallel with the ap startup activity so sometimes no slot covered >> the pcpup->pc_curpcb relted address range. (Replacement slots are >> picked based on mftb()%n_slbs .) Ignore the above: I was not thinking of the right context. >> Are you asking me to disable that call and see what happens? > > I've not done anything about disabling the replacement of an > slb entry for spanning what pcpup->pc_curpcb-> refers to > when there is no such spanning entry already. (The code makes > no replacement if an entry does span the address range. > So, effectively, then, the code is a no-op for such conditions.) > >> With the hack_into_slb_if_needed call and the other patches >> reported in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233863 >> I'm booting and using historical and usefdt modes just fine >> as far as I've tested. (usefdt mode needing vt.) The patches do >> not involve reverting the KVA change. One of the test machines is >> a "G5 quad" and its is the primary one I build on and test. Looking up what I though I remembered when writing some of the above (and what I've written in other places) . . . /usr/src/sys/powerpc/aim/moea64_native.c has: void cpu_pcpu_init(struct pcpu *pcpu, int cpuid, size_t sz) { #ifdef __powerpc64__ /* Copy the SLB contents from the current CPU */ memcpy(pcpu->pc_aim.slb, PCPU_GET(aim.slb), sizeof(pcpu->pc_aim.slb)); #endif } cpu_pcpu_init is used via /usr/src/sys/kern/subr_pcpu.c 's pcpu_init : void pcpu_init(struct pcpu *pcpu, int cpuid, size_t size) { bzero(pcpu, size); KASSERT(cpuid >= 0 && cpuid < MAXCPU, ("pcpu_init: invalid cpuid %d", cpuid)); pcpu->pc_cpuid = cpuid; cpuid_to_pcpu[cpuid] = pcpu; STAILQ_INSERT_TAIL(&cpuhead, pcpu, pc_allcpu); cpu_pcpu_init(pcpu, cpuid, size); pcpu->pc_rm_queue.rmq_next = &pcpu->pc_rm_queue; pcpu->pc_rm_queue.rmq_prev = &pcpu->pc_rm_queue; } That is in turn used by powerpc-specific powerpc_init (for the bsp) and by cpu_mp_start for other cpus, with cpu_mp_start used by mp_start during SI_SUB_CPU, much earlier than what I listed before. powerpc_init does the following just for the bsp: /* * Set up per-cpu data for the BSP now that the platform can tell * us which that is. */ if (platform_smp_get_bsp(&bsp) != 0) bsp.cr_cpuid = 0; pc = &__pcpu[bsp.cr_cpuid]; __asm __volatile("mtsprg 0, %0" :: "r"(pc)); pcpu_init(pc, bsp.cr_cpuid, sizeof(struct pcpu)); pc->pc_curthread = &thread0; thread0.td_oncpu = bsp.cr_cpuid; pc->pc_cpuid = bsp.cr_cpuid; pc->pc_hwref = bsp.cr_hwref; cpu_mp_start does (in a loop on the bsp cpu): if (cpu.cr_cpuid != bsp.cr_cpuid) { void *dpcpu; pc = &__pcpu[cpu.cr_cpuid]; dpcpu = (void *)kmem_malloc(DPCPU_SIZE, M_WAITOK | M_ZERO); pcpu_init(pc, cpu.cr_cpuid, sizeof(*pc)); dpcpu_init(dpcpu, cpu.cr_cpuid); The memory for the pcpup->pc_idlethread->pc_curpcb-> use in cpudep_ap_bootstrap is not necessarily covered by the slb material copied from the bsp during cpu_mp_start. This is what lead to my investigative: hack_into_slb_if_needed(pcpup->pc_curpcb); in cpudep_ap_bootstrap . I will note that the hagups have been so rare after the hack_into_slb_if_needed(pcpup->pc_curpcb) addition that I have no evidence of just where the low level hangup is. They could be a completely different issue and I'd not know it yet. I have added a printf that would indicate if cpudep_ap_bootstrap got just past evaluating: pcpup->pc_curpcb->pcb_sp when it (later?) hangs up. But I'm waiting to see a hangup during my other activities in order to see the evidence. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-ppc@freebsd.org Sat Apr 20 23:24:05 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 2995E1578E7A for ; Sat, 20 Apr 2019 23:24:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id B885C772E7 for ; Sat, 20 Apr 2019 23:24:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 7C2991578E74; Sat, 20 Apr 2019 23:24:04 +0000 (UTC) Delivered-To: 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 6AE3A1578E72 for ; Sat, 20 Apr 2019 23:24:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 09803772E5 for ; Sat, 20 Apr 2019 23:24:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 30564B149 for ; Sat, 20 Apr 2019 23:24:03 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x3KNO3dI061688 for ; Sat, 20 Apr 2019 23:24:03 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x3KNO3jt061687 for ppc@FreeBSD.org; Sat, 20 Apr 2019 23:24:03 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: ppc@FreeBSD.org Subject: [Bug 233863] r345425 on PowerMac G5 may require kern.smp.disabled=1 and must set usefdt=1 which causes net interface reorder Date: Sat, 20 Apr 2019 23:24:02 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: marklmi26-fbsd@yahoo.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: ppc@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.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, 20 Apr 2019 23:24:05 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D233863 --- Comment #19 from Mark Millard --- Created attachment 203844 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D203844&action= =3Dedit Investigatory patch for sys/powerpc/aim/mmu_oea64.c I had forgotten my old 2019-Jan-29/30 reports and patch tied to a debug-build KASSERT failure on a old PowerMac. See: https://lists.freebsd.org/pipermail/freebsd-ppc/2019-January/010020.ht= ml (the Jan-30 udpate). It was tied to activity like: unload load /boot/kernel/kernel boot or: unload boot -v /boot/kernel/kernel for seeing the specific KASSERT examples that I got. That justified looking into the code, but looking seemed to indicate the more general problems noted on the list. I'll not repeat the material here. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-ppc@freebsd.org Sat Apr 20 23:33:10 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 AE2E11579172 for ; Sat, 20 Apr 2019 23:33:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 48E4377630 for ; Sat, 20 Apr 2019 23:33:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 0C2D91579170; Sat, 20 Apr 2019 23:33:10 +0000 (UTC) Delivered-To: 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 EC271157916D for ; Sat, 20 Apr 2019 23:33:09 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 82E417762D for ; Sat, 20 Apr 2019 23:33:09 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id CA782B2BF for ; Sat, 20 Apr 2019 23:33:08 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x3KNX85P080426 for ; Sat, 20 Apr 2019 23:33:08 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x3KNX8sJ080425 for ppc@FreeBSD.org; Sat, 20 Apr 2019 23:33:08 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: ppc@FreeBSD.org Subject: [Bug 233863] r345425 on PowerMac G5 may require kern.smp.disabled=1 and must set usefdt=1 which causes net interface reorder Date: Sat, 20 Apr 2019 23:33:08 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: marklmi26-fbsd@yahoo.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: ppc@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.isobsolete attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.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, 20 Apr 2019 23:33:10 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D233863 Mark Millard changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #203844|0 |1 is obsolete| | --- Comment #20 from Mark Millard --- Created attachment 203845 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D203845&action= =3Dedit Investigatory patch for sys/powerpc/aim/mmu_oea64.c The original paste of attachment content (from the original time frame) did not seem to have preserved whitespace details. So I'm just trying again via a modern svnlite diff. --=20 You are receiving this mail because: You are the assignee for the bug.=