From owner-freebsd-ppc@freebsd.org Sun Apr 14 02:44:07 2019
Return-Path: <owner-freebsd-ppc@freebsd.org>
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 <freebsd-ppc@mailman.ysv.freebsd.org>;
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 <freebsd-ppc@freebsd.org>; 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 <marklmi@yahoo.com>
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 <freebsd-ppc@freebsd.org>,
Justin Hibbits <chmeeedalf@gmail.com>
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 <freebsd-ppc.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-ppc/>
List-Post: <mailto:freebsd-ppc@freebsd.org>
List-Help: <mailto:freebsd-ppc-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=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: <owner-freebsd-ppc@freebsd.org>
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 <freebsd-ppc@mailman.ysv.freebsd.org>;
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 <freebsd-ppc@freebsd.org>; 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 <marklmi@yahoo.com>
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: <B9138DF6-72B5-44AB-B7CD-F04F6D40B555@yahoo.com>
References: <1E438A62-1B2F-4A1D-9537-B1135CE1C89D@yahoo.com>
To: FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>,
Justin Hibbits <chmeeedalf@gmail.com>
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 <freebsd-ppc.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-ppc/>
List-Post: <mailto:freebsd-ppc@freebsd.org>
List-Help: <mailto:freebsd-ppc-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=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 <marklmi at yahoo.com> 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: <owner-freebsd-ppc@freebsd.org>
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 <freebsd-ppc@mailman.ysv.freebsd.org>;
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 <freebsd-ppc@freebsd.org>; 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 <powerpc@localmail.freebsd.org>; 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 <powerpc@FreeBSD.org>; 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 <powerpc@FreeBSD.org>; 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 <powerpc@FreeBSD.org>; 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: <bug-237208-25139-ytyZkJwsn2@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-237208-25139@https.bugs.freebsd.org/bugzilla/>
References: <bug-237208-25139@https.bugs.freebsd.org/bugzilla/>
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 <freebsd-ppc.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-ppc/>
List-Post: <mailto:freebsd-ppc@freebsd.org>
List-Help: <mailto:freebsd-ppc-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=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 <pkubaj@anongoth.pl> ---
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: <owner-freebsd-ppc@freebsd.org>
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 <freebsd-ppc@mailman.ysv.freebsd.org>;
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 <freebsd-ppc@freebsd.org>; 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 <powerpc@localmail.freebsd.org>; 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 <powerpc@FreeBSD.org>; 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 <powerpc@FreeBSD.org>; 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 <powerpc@FreeBSD.org>; 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: <bug-237208-25139-NULx8ILHPE@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-237208-25139@https.bugs.freebsd.org/bugzilla/>
References: <bug-237208-25139@https.bugs.freebsd.org/bugzilla/>
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 <freebsd-ppc.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-ppc/>
List-Post: <mailto:freebsd-ppc@freebsd.org>
List-Help: <mailto:freebsd-ppc-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=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 <pkubaj@anongoth.pl> ---
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: <owner-freebsd-ppc@freebsd.org>
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 <freebsd-ppc@mailman.ysv.freebsd.org>;
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 <freebsd-ppc@freebsd.org>; 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 <powerpc@localmail.freebsd.org>; 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 <powerpc@FreeBSD.org>; 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 <powerpc@FreeBSD.org>; 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 <powerpc@FreeBSD.org>; 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: <bug-237208-25139-UsTgTaRofO@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-237208-25139@https.bugs.freebsd.org/bugzilla/>
References: <bug-237208-25139@https.bugs.freebsd.org/bugzilla/>
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 <freebsd-ppc.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-ppc/>
List-Post: <mailto:freebsd-ppc@freebsd.org>
List-Help: <mailto:freebsd-ppc-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=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: <owner-freebsd-ppc@freebsd.org>
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 <freebsd-ppc@mailman.ysv.freebsd.org>;
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 <freebsd-ppc@freebsd.org>; 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 <marklmi@yahoo.com>
In-Reply-To: <B9138DF6-72B5-44AB-B7CD-F04F6D40B555@yahoo.com>
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>
<B9138DF6-72B5-44AB-B7CD-F04F6D40B555@yahoo.com>
To: FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>,
Justin Hibbits <chmeeedalf@gmail.com>
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 <freebsd-ppc.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-ppc/>
List-Post: <mailto:freebsd-ppc@freebsd.org>
List-Help: <mailto:freebsd-ppc-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=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 <marklmi@yahoo.com> 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 <marklmi at yahoo.com> 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: <Apple OHCI root HUB> at usbus1
. . .
ada0 at ata2 bus 0 scbus2 target 0 lun 0
ada0: <OWC Mercury Electra 3G SSD 560ABBF0> 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: <PIONEER DVD-RW DVR-111D 1.23> 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: <owner-freebsd-ppc@freebsd.org>
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 <freebsd-ppc@mailman.ysv.freebsd.org>;
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 <freebsd-ppc@freebsd.org>; 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 <ppc@mailman.ysv.freebsd.org>; 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 <ppc@FreeBSD.org>; 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 <ppc@FreeBSD.org>; 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 <ppc@FreeBSD.org>; 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: <bug-233863-21-K2Cp8FI842@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-233863-21@https.bugs.freebsd.org/bugzilla/>
References: <bug-233863-21@https.bugs.freebsd.org/bugzilla/>
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 <freebsd-ppc.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-ppc/>
List-Post: <mailto:freebsd-ppc@freebsd.org>
List-Help: <mailto:freebsd-ppc-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=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 <marklmi26-fbsd@yahoo.com> ---
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: <owner-freebsd-ppc@freebsd.org>
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 <freebsd-ppc@mailman.ysv.freebsd.org>;
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 <freebsd-ppc@freebsd.org>; 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 <marklmi@yahoo.com>
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>
<af38e008-d9f9-9364-56c5-56387cbcf95d@blastwave.org>
<465DBF40-EEF5-4D4A-95F6-DF17EB5B130B@yahoo.com>
<5aecd21e-e53c-f14c-0bdc-8732fa88fed6@blastwave.org>
<A4E361A0-4C6C-4E37-BB04-AB52094F4206@yahoo.com>
<55E83F50-197D-43C7-B4D6-E69A5AEC2630@yahoo.com>
To: Dennis Clarke <dclarke@blastwave.org>
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 <freebsd-ppc.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-ppc/>
List-Post: <mailto:freebsd-ppc@freebsd.org>
List-Help: <mailto:freebsd-ppc-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Apr 2019 07:06:48 -0000
On 2019-Apr-13, at 11:39, Mark Millard <marklmi at yahoo.com> wrote:
> [My adjustment to fdt_add_subnode_namelen was inept.]
>=20
> On 2019-Apr-12, at 16:17, Mark Millard <marklmi at yahoo.com> wrote:
>=20
>> On 2019-Apr-12, at 14:20, Dennis Clarke <dclarke a t blastwave.org> =
wrote:
>>=20
>>> On 4/12/19 4:51 PM, Mark Millard wrote:
>>>> On 2019-Apr-12, at 13:13, Dennis Clarke <dclarke at blastwave.org> =
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 <sys/sched.h>
#include <sys/smp.h>
=20
+#include <dev/ofw/openfirm.h>
+
#include <machine/bus.h>
#include <machine/intr_machdep.h>
#include <machine/md_var.h>
@@ -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: <owner-freebsd-ppc@freebsd.org>
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 <freebsd-ppc@mailman.ysv.freebsd.org>;
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 <freebsd-ppc@freebsd.org>; 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 <marklmi@yahoo.com>
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>
<B9138DF6-72B5-44AB-B7CD-F04F6D40B555@yahoo.com>
<125F273F-6F0B-49BB-87AE-8B94DE621407@yahoo.com>
To: FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>,
Justin Hibbits <chmeeedalf@gmail.com>
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 <freebsd-ppc.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-ppc/>
List-Post: <mailto:freebsd-ppc@freebsd.org>
List-Help: <mailto:freebsd-ppc-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=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 <marklmi@yahoo.com> 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 <marklmi@yahoo.com> 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 <marklmi at yahoo.com> 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: <Apple OHCI root HUB> at usbus1
> . . .
> ada0 at ata2 bus 0 scbus2 target 0 lun 0
> ada0: <OWC Mercury Electra 3G SSD 560ABBF0> 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: <PIONEER DVD-RW DVR-111D 1.23> 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 <sys/sched.h>
#include <sys/smp.h>
=20
+#include <dev/ofw/openfirm.h>
+
#include <machine/bus.h>
#include <machine/intr_machdep.h>
#include <machine/md_var.h>
@@ -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: <owner-freebsd-ppc@freebsd.org>
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 <freebsd-ppc@mailman.ysv.freebsd.org>;
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 <freebsd-ppc@freebsd.org>; 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 <ppc@mailman.ysv.freebsd.org>; 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 <ppc@FreeBSD.org>; 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 <ppc@FreeBSD.org>; 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 <ppc@FreeBSD.org>; 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: <bug-233863-21-uRDLohRFNn@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-233863-21@https.bugs.freebsd.org/bugzilla/>
References: <bug-233863-21@https.bugs.freebsd.org/bugzilla/>
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 <freebsd-ppc.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-ppc/>
List-Post: <mailto:freebsd-ppc@freebsd.org>
List-Help: <mailto:freebsd-ppc-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=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 <marklmi26-fbsd@yahoo.com> ---
(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: <owner-freebsd-ppc@freebsd.org>
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 <freebsd-ppc@mailman.ysv.freebsd.org>;
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 <freebsd-ppc@freebsd.org>; 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 <powerpc@localmail.freebsd.org>; 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 <powerpc@FreeBSD.org>; 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 <powerpc@FreeBSD.org>; 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 <powerpc@FreeBSD.org>; 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: <bug-237208-25139-Sc22DqIY2Q@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-237208-25139@https.bugs.freebsd.org/bugzilla/>
References: <bug-237208-25139@https.bugs.freebsd.org/bugzilla/>
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 <freebsd-ppc.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-ppc/>
List-Post: <mailto:freebsd-ppc@freebsd.org>
List-Help: <mailto:freebsd-ppc-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=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 <pkubaj@anongoth.pl> ---
(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: <owner-freebsd-ppc@freebsd.org>
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 <freebsd-ppc@mailman.ysv.freebsd.org>;
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 <freebsd-ppc@freebsd.org>; 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 <powerpc@localmail.freebsd.org>; 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 <powerpc@FreeBSD.org>; 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 <powerpc@FreeBSD.org>; 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 <powerpc@FreeBSD.org>; 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: <bug-237208-25139-ABlvtdfZHy@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-237208-25139@https.bugs.freebsd.org/bugzilla/>
References: <bug-237208-25139@https.bugs.freebsd.org/bugzilla/>
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 <freebsd-ppc.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-ppc/>
List-Post: <mailto:freebsd-ppc@freebsd.org>
List-Help: <mailto:freebsd-ppc-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=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 <pkubaj@anongoth.pl> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #203697|text/x-log |text/plain
mime type| |
--- Comment #5 from Piotr Kubaj <pkubaj@anongoth.pl> ---
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: <owner-freebsd-ppc@freebsd.org>
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 <freebsd-ppc@mailman.ysv.freebsd.org>;
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 <freebsd-ppc@freebsd.org>; 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 <powerpc@localmail.freebsd.org>; 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 <powerpc@FreeBSD.org>; 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 <powerpc@FreeBSD.org>; 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 <powerpc@FreeBSD.org>; 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: <bug-237208-25139-TeCDKH6eLh@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-237208-25139@https.bugs.freebsd.org/bugzilla/>
References: <bug-237208-25139@https.bugs.freebsd.org/bugzilla/>
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 <freebsd-ppc.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-ppc/>
List-Post: <mailto:freebsd-ppc@freebsd.org>
List-Help: <mailto:freebsd-ppc-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=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 <pkubaj@anongoth.pl> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #203698|text/x-log |text/plain
mime type| |
--- Comment #6 from Piotr Kubaj <pkubaj@anongoth.pl> ---
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: <owner-freebsd-ppc@freebsd.org>
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 <freebsd-ppc@mailman.ysv.freebsd.org>;
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 <freebsd-ppc@freebsd.org>; 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 <powerpc@localmail.freebsd.org>; 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 <powerpc@FreeBSD.org>; 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 <powerpc@FreeBSD.org>; 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 <powerpc@FreeBSD.org>; 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: <bug-237208-25139-S8Qub8g4Se@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-237208-25139@https.bugs.freebsd.org/bugzilla/>
References: <bug-237208-25139@https.bugs.freebsd.org/bugzilla/>
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 <freebsd-ppc.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-ppc/>
List-Post: <mailto:freebsd-ppc@freebsd.org>
List-Help: <mailto:freebsd-ppc-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=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 <pkubaj@anongoth.pl> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #203699|text/x-log |text/plain
mime type| |
--- Comment #7 from Piotr Kubaj <pkubaj@anongoth.pl> ---
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: <owner-freebsd-ppc@freebsd.org>
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 <freebsd-ppc@mailman.ysv.freebsd.org>;
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 <freebsd-ppc@freebsd.org>; 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 <marklmi@yahoo.com>
In-Reply-To: <C328187B-03F0-4621-8097-D4D546B31F9E@yahoo.com>
Date: Mon, 15 Apr 2019 21:44:44 -0700
Content-Transfer-Encoding: 7bit
Message-Id: <A4172282-514E-4710-963A-F5932A390D33@yahoo.com>
References: <C328187B-03F0-4621-8097-D4D546B31F9E@yahoo.com>
To: FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>,
Justin Hibbits <chmeeedalf@gmail.com>
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 <freebsd-ppc.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-ppc/>
List-Post: <mailto:freebsd-ppc@freebsd.org>
List-Help: <mailto:freebsd-ppc-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=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 <marklmi at yahoo.com> 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: <owner-freebsd-ppc@freebsd.org>
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 <freebsd-ppc@mailman.ysv.freebsd.org>;
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 <freebsd-ppc@freebsd.org>; 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 <powerpc@localmail.freebsd.org>; 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 <powerpc@FreeBSD.org>; 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 <powerpc@FreeBSD.org>; 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 <powerpc@FreeBSD.org>; 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: <bug-237208-25139-uN94IklLGS@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-237208-25139@https.bugs.freebsd.org/bugzilla/>
References: <bug-237208-25139@https.bugs.freebsd.org/bugzilla/>
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 <freebsd-ppc.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-ppc/>
List-Post: <mailto:freebsd-ppc@freebsd.org>
List-Help: <mailto:freebsd-ppc-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=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: <owner-freebsd-ppc@freebsd.org>
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 <freebsd-ppc@mailman.ysv.freebsd.org>;
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 <freebsd-ppc@freebsd.org>; 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 <marklmi@yahoo.com>
In-Reply-To: <20190306223611.75c8a87e@titan.knownspace>
Date: Tue, 16 Apr 2019 14:26:39 -0700
Cc: freebsd-ppc <freebsd-ppc@freebsd.org>
Content-Transfer-Encoding: 7bit
Message-Id: <984188AE-93A9-4321-99EC-522C2E0CE9A9@yahoo.com>
References: <D9B56EE2-35C7-44A2-9229-D9E4AECAD3E1@yahoo.com>
<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 <chmeeedalf@gmail.com>
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 <freebsd-ppc.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-ppc/>
List-Post: <mailto:freebsd-ppc@freebsd.org>
List-Help: <mailto:freebsd-ppc-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=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 <chmeeedalf at gmail.com> wrote:
> On Wed, 6 Mar 2019 18:35:42 -0800
> Mark Millard <marklmi at yahoo.com> 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 <marklmi at yahoo.com> wrote:
>>
>>
>>
>>> On 2019-Mar-6, at 13:19, Justin Hibbits <chmeeedalf at gmail.com>
>>> wrote:
>>>> On Mon, 4 Mar 2019 19:43:09 -0800
>>>> Mark Millard via freebsd-ppc <freebsd-ppc@freebsd.org> 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: <owner-freebsd-ppc@freebsd.org>
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 <freebsd-ppc@mailman.ysv.freebsd.org>;
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 <freebsd-ppc@freebsd.org>; 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 <freebsd-ppc@freebsd.org>; 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 <chmeeedalf@gmail.com>
To: Mark Millard <marklmi@yahoo.com>
Cc: freebsd-ppc <freebsd-ppc@freebsd.org>
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: <D9B56EE2-35C7-44A2-9229-D9E4AECAD3E1@yahoo.com>
<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 <freebsd-ppc.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-ppc/>
List-Post: <mailto:freebsd-ppc@freebsd.org>
List-Help: <mailto:freebsd-ppc-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Apr 2019 21:42:16 -0000
On Tue, 16 Apr 2019 14:26:39 -0700
Mark Millard <marklmi@yahoo.com> 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: <owner-freebsd-ppc@freebsd.org>
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 <freebsd-ppc@mailman.ysv.freebsd.org>;
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 <freebsd-ppc@freebsd.org>; 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 <marklmi@yahoo.com>
In-Reply-To: <20190416164210.26827a6d@titan.knownspace>
Date: Tue, 16 Apr 2019 15:36:31 -0700
Cc: freebsd-ppc <freebsd-ppc@freebsd.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <8141B858-08B0-4B88-8439-747023A98822@yahoo.com>
References: <D9B56EE2-35C7-44A2-9229-D9E4AECAD3E1@yahoo.com>
<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 <chmeeedalf@gmail.com>
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 <freebsd-ppc.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-ppc/>
List-Post: <mailto:freebsd-ppc@freebsd.org>
List-Help: <mailto:freebsd-ppc-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=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 <chmeeedalf at gmail.com> =
wrote:
> On Tue, 16 Apr 2019 14:26:39 -0700
> Mark Millard <marklmi at yahoo.com> 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: <owner-freebsd-ppc@freebsd.org>
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 <freebsd-ppc@mailman.ysv.freebsd.org>;
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 <freebsd-ppc@freebsd.org>; 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 <marklmi@yahoo.com>
In-Reply-To: <8141B858-08B0-4B88-8439-747023A98822@yahoo.com>
Date: Tue, 16 Apr 2019 17:20:56 -0700
Cc: freebsd-ppc <freebsd-ppc@freebsd.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <306BC23A-3261-41BE-AB0B-4264E864DAA5@yahoo.com>
References: <D9B56EE2-35C7-44A2-9229-D9E4AECAD3E1@yahoo.com>
<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 <chmeeedalf@gmail.com>
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 <freebsd-ppc.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-ppc/>
List-Post: <mailto:freebsd-ppc@freebsd.org>
List-Help: <mailto:freebsd-ppc-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=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 <marklmi at yahoo.com> 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 <chmeeedalf at gmail.com> =
wrote:
>=20
>> On Tue, 16 Apr 2019 14:26:39 -0700
>> Mark Millard <marklmi at yahoo.com> 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: <owner-freebsd-ppc@freebsd.org>
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 <freebsd-ppc@mailman.ysv.freebsd.org>;
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 <freebsd-ppc@freebsd.org>; 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 <marklmi@yahoo.com>
In-Reply-To: <306BC23A-3261-41BE-AB0B-4264E864DAA5@yahoo.com>
Date: Tue, 16 Apr 2019 19:06:59 -0700
Cc: freebsd-ppc <freebsd-ppc@freebsd.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <0CC10B05-F0FD-483C-911D-20F5AC2DB427@yahoo.com>
References: <D9B56EE2-35C7-44A2-9229-D9E4AECAD3E1@yahoo.com>
<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 <chmeeedalf@gmail.com>
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 <freebsd-ppc.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-ppc/>
List-Post: <mailto:freebsd-ppc@freebsd.org>
List-Help: <mailto:freebsd-ppc-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=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 <marklmi at yahoo.com> 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 <marklmi at yahoo.com> 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 <chmeeedalf at gmail.com> =
wrote:
>>=20
>>> On Tue, 16 Apr 2019 14:26:39 -0700
>>> Mark Millard <marklmi at yahoo.com> 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: <owner-freebsd-ppc@freebsd.org>
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 <freebsd-ppc@mailman.ysv.freebsd.org>;
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 <freebsd-ppc@freebsd.org>; 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 <powerpc@localmail.freebsd.org>; 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 <powerpc@FreeBSD.org>; 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 <powerpc@FreeBSD.org>; 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 <powerpc@FreeBSD.org>; 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: <bug-237208-25139-iGcwrIitiX@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-237208-25139@https.bugs.freebsd.org/bugzilla/>
References: <bug-237208-25139@https.bugs.freebsd.org/bugzilla/>
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 <freebsd-ppc.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-ppc/>
List-Post: <mailto:freebsd-ppc@freebsd.org>
List-Help: <mailto:freebsd-ppc-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=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 <gustavo.romero@protonmail.com> ---
(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: <owner-freebsd-ppc@freebsd.org>
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 <freebsd-ppc@mailman.ysv.freebsd.org>;
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 <freebsd-ppc@freebsd.org>; 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 <powerpc@localmail.freebsd.org>; 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 <powerpc@FreeBSD.org>; 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 <powerpc@FreeBSD.org>; 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 <powerpc@FreeBSD.org>; 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: <bug-237208-25139-VJST98VSiU@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-237208-25139@https.bugs.freebsd.org/bugzilla/>
References: <bug-237208-25139@https.bugs.freebsd.org/bugzilla/>
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 <freebsd-ppc.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-ppc/>
List-Post: <mailto:freebsd-ppc@freebsd.org>
List-Help: <mailto:freebsd-ppc-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=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 <gustavo.romero@protonmail.com> ---
(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: <owner-freebsd-ppc@freebsd.org>
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 <freebsd-ppc@mailman.ysv.freebsd.org>;
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 <freebsd-ppc@freebsd.org>; 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 <marklmi@yahoo.com>
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 <freebsd-ppc@freebsd.org>,
Justin Hibbits <chmeeedalf@gmail.com>
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 <freebsd-ppc.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-ppc/>
List-Post: <mailto:freebsd-ppc@freebsd.org>
List-Help: <mailto:freebsd-ppc-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=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:
<powermac_smp_timebase_sync> li r3,0
<powermac_smp_timebase_sync+0x4> rldicl r5,r4,32,32
<powermac_smp_timebase_sync+0x8> mttbl r3
<powermac_smp_timebase_sync+0xc> mttbu r5
<powermac_smp_timebase_sync+0x10> mttbl r4
<powermac_smp_timebase_sync+0x14> 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: <owner-freebsd-ppc@freebsd.org>
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 <freebsd-ppc@mailman.ysv.freebsd.org>;
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 <freebsd-ppc@freebsd.org>; 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 <freebsd-ppc@freebsd.org>;
Wed, 17 Apr 2019 23:18:04 +0000 (UTC)
From: Mark Millard <marklmi@yahoo.com>
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: <A80FE8F0-D419-40C5-A760-0D5D98752680@yahoo.com>
Date: Wed, 17 Apr 2019 16:18:03 -0700
To: FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>
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 <freebsd-ppc.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-ppc/>
List-Post: <mailto:freebsd-ppc@freebsd.org>
List-Help: <mailto:freebsd-ppc-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=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:
<powermac_smp_timebase_sync> stwu r1,-32(r1)
<powermac_smp_timebase_sync+0x4> stw r31,24(r1)
<powermac_smp_timebase_sync+0x8> mr r31,r1
<powermac_smp_timebase_sync+0xc> li r0,0
<powermac_smp_timebase_sync+0x10> mtsprg 4,r0
<powermac_smp_timebase_sync+0x14> li r9,0
<powermac_smp_timebase_sync+0x18> mtsprg 5,r9
<powermac_smp_timebase_sync+0x1c> mtsprg 4,r4
<powermac_smp_timebase_sync+0x20> lwz r11,0(r1)
<powermac_smp_timebase_sync+0x24> lwz r31,-8(r11)
<powermac_smp_timebase_sync+0x28> mr r1,r11
<powermac_smp_timebase_sync+0x2c> 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: <owner-freebsd-ppc@freebsd.org>
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 <freebsd-ppc@mailman.ysv.freebsd.org>;
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 <freebsd-ppc@freebsd.org>; 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 <powerpc@localmail.freebsd.org>; 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 <powerpc@FreeBSD.org>; 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 <powerpc@FreeBSD.org>; 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 <powerpc@FreeBSD.org>; 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: <bug-237208-25139-mpmYAJnPSB@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-237208-25139@https.bugs.freebsd.org/bugzilla/>
References: <bug-237208-25139@https.bugs.freebsd.org/bugzilla/>
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 <freebsd-ppc.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-ppc/>
List-Post: <mailto:freebsd-ppc@freebsd.org>
List-Help: <mailto:freebsd-ppc-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=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 <pkubaj@FreeBSD.org> ---
(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: <owner-freebsd-ppc@freebsd.org>
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 <freebsd-ppc@mailman.ysv.freebsd.org>;
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 <freebsd-ppc@freebsd.org>; 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 <powerpc@localmail.freebsd.org>; 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 <powerpc@FreeBSD.org>; 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 <powerpc@FreeBSD.org>; 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 <powerpc@FreeBSD.org>; 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: <bug-237370-25139@https.bugs.freebsd.org/bugzilla/>
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 <freebsd-ppc.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-ppc/>
List-Post: <mailto:freebsd-ppc@freebsd.org>
List-Help: <mailto:freebsd-ppc-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=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: <owner-freebsd-ppc@freebsd.org>
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 <freebsd-ppc@mailman.ysv.freebsd.org>;
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 <freebsd-ppc@freebsd.org>; 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 <marklmi@yahoo.com>
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 <brde@optusnet.com.au>, Konstantin Belousov <kib@freebsd.org>
To: FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>,
freebsd-hackers Hackers <freebsd-hackers@freebsd.org>
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 <freebsd-ppc.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-ppc/>
List-Post: <mailto:freebsd-ppc@freebsd.org>
List-Help: <mailto:freebsd-ppc-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=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: <owner-freebsd-ppc@freebsd.org>
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 <freebsd-ppc@mailman.ysv.freebsd.org>;
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 <freebsd-ppc@freebsd.org>; 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 <marklmi@yahoo.com>
In-Reply-To: <50CFD7F1-6892-4375-967B-4713517C2520@yahoo.com>
Date: Thu, 18 Apr 2019 22:17:46 -0700
Cc: Bruce Evans <brde@optusnet.com.au>, Konstantin Belousov <kib@freebsd.org>
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-ppc@freebsd.org>,
freebsd-hackers Hackers <freebsd-hackers@freebsd.org>
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 <freebsd-ppc.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-ppc/>
List-Post: <mailto:freebsd-ppc@freebsd.org>
List-Help: <mailto:freebsd-ppc-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=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 <marklmi@yahoo.com> 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: <owner-freebsd-ppc@freebsd.org>
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 <freebsd-ppc@mailman.ysv.freebsd.org>;
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 <freebsd-ppc@freebsd.org>; 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 <marklmi@yahoo.com>
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: <B2B3221D-71F9-48ED-9CA3-FE3650F1C377@yahoo.com>
Date: Fri, 19 Apr 2019 15:20:59 -0700
To: FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>,
Justin Hibbits <chmeeedalf@gmail.com>
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 <freebsd-ppc.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-ppc/>
List-Post: <mailto:freebsd-ppc@freebsd.org>
List-Help: <mailto:freebsd-ppc-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=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: <owner-freebsd-ppc@freebsd.org>
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 <freebsd-ppc@mailman.ysv.freebsd.org>;
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 <freebsd-ppc@freebsd.org>; 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 <marklmi@yahoo.com>
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: <F0A58D08-4A99-4483-A419-200A1485E73E@yahoo.com>
Date: Fri, 19 Apr 2019 15:56:06 -0700
To: FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>,
Justin Hibbits <chmeeedalf@gmail.com>
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 <freebsd-ppc.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-ppc/>
List-Post: <mailto:freebsd-ppc@freebsd.org>
List-Help: <mailto:freebsd-ppc-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=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: <owner-freebsd-ppc@freebsd.org>
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 <freebsd-ppc@mailman.ysv.freebsd.org>;
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 <freebsd-ppc@freebsd.org>; 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 <marklmi@yahoo.com>
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: <B2B3221D-71F9-48ED-9CA3-FE3650F1C377@yahoo.com>
To: FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>,
Justin Hibbits <chmeeedalf@gmail.com>
In-Reply-To: <B2B3221D-71F9-48ED-9CA3-FE3650F1C377@yahoo.com>
Message-Id: <D7464FDC-A6C4-47C6-BEC6-9C7A6206E5B7@yahoo.com>
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 <freebsd-ppc.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-ppc/>
List-Post: <mailto:freebsd-ppc@freebsd.org>
List-Help: <mailto:freebsd-ppc-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Apr 2019 23:00:14 -0000
On 2019-Apr-19, at 15:20, Mark Millard <marklmi at yahoo.com> 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: <owner-freebsd-ppc@freebsd.org>
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 <freebsd-ppc@mailman.ysv.freebsd.org>;
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 <freebsd-ppc@freebsd.org>; 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 <marklmi@yahoo.com>
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: <F0A58D08-4A99-4483-A419-200A1485E73E@yahoo.com>
To: FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>,
Justin Hibbits <chmeeedalf@gmail.com>
In-Reply-To: <F0A58D08-4A99-4483-A419-200A1485E73E@yahoo.com>
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 <freebsd-ppc.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-ppc/>
List-Post: <mailto:freebsd-ppc@freebsd.org>
List-Help: <mailto:freebsd-ppc-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=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 <marklmi at yahoo.com> 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: <owner-freebsd-ppc@freebsd.org>
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 <freebsd-ppc@mailman.ysv.freebsd.org>;
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 <freebsd-ppc@freebsd.org>; 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 <ppc@mailman.ysv.freebsd.org>; 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 <ppc@FreeBSD.org>; 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 <ppc@FreeBSD.org>; 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 <ppc@FreeBSD.org>; 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: <bug-233863-21-Rugtzxf3LS@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-233863-21@https.bugs.freebsd.org/bugzilla/>
References: <bug-233863-21@https.bugs.freebsd.org/bugzilla/>
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 <freebsd-ppc.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-ppc/>
List-Post: <mailto:freebsd-ppc@freebsd.org>
List-Help: <mailto:freebsd-ppc-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=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 <marklmi26-fbsd@yahoo.com> ---
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: <owner-freebsd-ppc@freebsd.org>
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 <freebsd-ppc@mailman.ysv.freebsd.org>;
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 <freebsd-ppc@freebsd.org>; 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 <marklmi@yahoo.com>
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>
<af38e008-d9f9-9364-56c5-56387cbcf95d@blastwave.org>
<465DBF40-EEF5-4D4A-95F6-DF17EB5B130B@yahoo.com>
<5aecd21e-e53c-f14c-0bdc-8732fa88fed6@blastwave.org>
<A4E361A0-4C6C-4E37-BB04-AB52094F4206@yahoo.com>
<55E83F50-197D-43C7-B4D6-E69A5AEC2630@yahoo.com>
<1B999D64-036F-4553-B024-93D0150FD60D@yahoo.com>
To: Dennis Clarke <dclarke@blastwave.org>
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 <freebsd-ppc.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-ppc/>
List-Post: <mailto:freebsd-ppc@freebsd.org>
List-Help: <mailto:freebsd-ppc-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=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 <marklmi at yahoo.com> wrote:
> On 2019-Apr-13, at 11:39, Mark Millard <marklmi at yahoo.com> wrote:
>=20
>> [My adjustment to fdt_add_subnode_namelen was inept.]
>>=20
>> On 2019-Apr-12, at 16:17, Mark Millard <marklmi at yahoo.com> wrote:
>>=20
>>> On 2019-Apr-12, at 14:20, Dennis Clarke <dclarke a t blastwave.org> =
wrote:
>>>=20
>>>> On 4/12/19 4:51 PM, Mark Millard wrote:
>>>>> On 2019-Apr-12, at 13:13, Dennis Clarke <dclarke at blastwave.org> =
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 <sys/sched.h>
> #include <sys/smp.h>
>=20
> +#include <dev/ofw/openfirm.h>
> +
> #include <machine/bus.h>
> #include <machine/intr_machdep.h>
> #include <machine/md_var.h>
> @@ -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: <owner-freebsd-ppc@freebsd.org>
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 <freebsd-ppc@mailman.ysv.freebsd.org>;
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 <freebsd-ppc@freebsd.org>; 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 <marklmi@yahoo.com>
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: <B5B1CC39-1D75-42F4-9661-62DA9D029D34@yahoo.com>
Date: Fri, 19 Apr 2019 20:36:16 -0700
To: FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>,
Justin Hibbits <chmeeedalf@gmail.com>
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 <freebsd-ppc.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-ppc/>
List-Post: <mailto:freebsd-ppc@freebsd.org>
List-Help: <mailto:freebsd-ppc-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=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: <owner-freebsd-ppc@freebsd.org>
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 <freebsd-ppc@mailman.ysv.freebsd.org>;
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: <B5B1CC39-1D75-42F4-9661-62DA9D029D34@yahoo.com>
In-Reply-To: <B5B1CC39-1D75-42F4-9661-62DA9D029D34@yahoo.com>
From: Justin Hibbits <chmeeedalf@gmail.com>
Date: Fri, 19 Apr 2019 22:48:31 -0500
Message-ID: <CAHSQbTBJtUc70XZgEk449-dLEhOydsypxD2NpVNsrxy0NcxnNA@mail.gmail.com>
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 <marklmi@yahoo.com>
Cc: FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>,
Nathan Whitehorn <nwhitehorn@freebsd.org>
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 <freebsd-ppc.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-ppc/>
List-Post: <mailto:freebsd-ppc@freebsd.org>
List-Help: <mailto:freebsd-ppc-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 20 Apr 2019 03:48:46 -0000
On Fri, Apr 19, 2019 at 10:36 PM Mark Millard <marklmi@yahoo.com> 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: <owner-freebsd-ppc@freebsd.org>
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 <freebsd-ppc@mailman.ysv.freebsd.org>;
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 <freebsd-ppc@freebsd.org>; 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 <marklmi@yahoo.com>
In-Reply-To: <CAHSQbTBJtUc70XZgEk449-dLEhOydsypxD2NpVNsrxy0NcxnNA@mail.gmail.com>
Date: Fri, 19 Apr 2019 21:42:34 -0700
Cc: FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>,
Nathan Whitehorn <nwhitehorn@freebsd.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <2E386EE0-782D-47CB-978B-B5A010AFCF88@yahoo.com>
References: <B5B1CC39-1D75-42F4-9661-62DA9D029D34@yahoo.com>
<CAHSQbTBJtUc70XZgEk449-dLEhOydsypxD2NpVNsrxy0NcxnNA@mail.gmail.com>
To: Justin Hibbits <chmeeedalf@gmail.com>
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 <freebsd-ppc.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-ppc/>
List-Post: <mailto:freebsd-ppc@freebsd.org>
List-Help: <mailto:freebsd-ppc-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 20 Apr 2019 04:42:40 -0000
On 2019-Apr-19, at 20:48, Justin Hibbits <chmeeedalf at gmail.com> =
wrote:
> On Fri, Apr 19, 2019 at 10:36 PM Mark Millard <marklmi@yahoo.com> =
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: <owner-freebsd-ppc@freebsd.org>
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 <freebsd-ppc@mailman.ysv.freebsd.org>;
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 <freebsd-ppc@freebsd.org>; 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 <ppc@mailman.ysv.freebsd.org>; 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 <ppc@FreeBSD.org>; 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 <ppc@FreeBSD.org>; 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 <ppc@FreeBSD.org>; 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: <bug-233863-21-dOa4ZWunxW@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-233863-21@https.bugs.freebsd.org/bugzilla/>
References: <bug-233863-21@https.bugs.freebsd.org/bugzilla/>
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 <freebsd-ppc.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-ppc/>
List-Post: <mailto:freebsd-ppc@freebsd.org>
List-Help: <mailto:freebsd-ppc-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=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 <marklmi26-fbsd@yahoo.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #203812|0 |1
is obsolete| |
--- Comment #18 from Mark Millard <marklmi26-fbsd@yahoo.com> ---
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: <owner-freebsd-ppc@freebsd.org>
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 <freebsd-ppc@mailman.ysv.freebsd.org>;
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 <freebsd-ppc@freebsd.org>; 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 <marklmi@yahoo.com>
In-Reply-To: <2E386EE0-782D-47CB-978B-B5A010AFCF88@yahoo.com>
Date: Fri, 19 Apr 2019 22:28:26 -0700
Cc: FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>,
Nathan Whitehorn <nwhitehorn@freebsd.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <1C697AD4-6CAC-4C33-8D77-72D9B53A7648@yahoo.com>
References: <B5B1CC39-1D75-42F4-9661-62DA9D029D34@yahoo.com>
<CAHSQbTBJtUc70XZgEk449-dLEhOydsypxD2NpVNsrxy0NcxnNA@mail.gmail.com>
<2E386EE0-782D-47CB-978B-B5A010AFCF88@yahoo.com>
To: Justin Hibbits <chmeeedalf@gmail.com>
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 <freebsd-ppc.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-ppc/>
List-Post: <mailto:freebsd-ppc@freebsd.org>
List-Help: <mailto:freebsd-ppc-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=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 <marklmi at yahoo.com> wrote:
> On 2019-Apr-19, at 20:48, Justin Hibbits <chmeeedalf at gmail.com> =
wrote:
>=20
>> On Fri, Apr 19, 2019 at 10:36 PM Mark Millard <marklmi@yahoo.com> =
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: <owner-freebsd-ppc@freebsd.org>
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 <freebsd-ppc@mailman.ysv.freebsd.org>;
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 <freebsd-ppc@freebsd.org>; 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 <marklmi@yahoo.com>
In-Reply-To: <1C697AD4-6CAC-4C33-8D77-72D9B53A7648@yahoo.com>
Date: Fri, 19 Apr 2019 23:08:10 -0700
Cc: FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>,
Nathan Whitehorn <nwhitehorn@freebsd.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <C93E2906-864D-40F3-80A0-73DA5F7DA3E7@yahoo.com>
References: <B5B1CC39-1D75-42F4-9661-62DA9D029D34@yahoo.com>
<CAHSQbTBJtUc70XZgEk449-dLEhOydsypxD2NpVNsrxy0NcxnNA@mail.gmail.com>
<2E386EE0-782D-47CB-978B-B5A010AFCF88@yahoo.com>
<1C697AD4-6CAC-4C33-8D77-72D9B53A7648@yahoo.com>
To: Justin Hibbits <chmeeedalf@gmail.com>
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 <freebsd-ppc.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-ppc/>
List-Post: <mailto:freebsd-ppc@freebsd.org>
List-Help: <mailto:freebsd-ppc-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=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 <marklmi at yahoo.com> 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 <marklmi at yahoo.com> wrote:
>=20
>> On 2019-Apr-19, at 20:48, Justin Hibbits <chmeeedalf at gmail.com> =
wrote:
>>=20
>>> On Fri, Apr 19, 2019 at 10:36 PM Mark Millard <marklmi@yahoo.com> =
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: <owner-freebsd-ppc@freebsd.org>
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 <freebsd-ppc@mailman.ysv.freebsd.org>;
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 <freebsd-ppc@freebsd.org>; 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 <marklmi@yahoo.com>
In-Reply-To: <C93E2906-864D-40F3-80A0-73DA5F7DA3E7@yahoo.com>
Date: Sat, 20 Apr 2019 14:14:22 -0700
Cc: FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>,
Nathan Whitehorn <nwhitehorn@freebsd.org>
Content-Transfer-Encoding: 7bit
Message-Id: <D80DF79C-89A0-43C5-8D73-8CF1255AB17B@yahoo.com>
References: <B5B1CC39-1D75-42F4-9661-62DA9D029D34@yahoo.com>
<CAHSQbTBJtUc70XZgEk449-dLEhOydsypxD2NpVNsrxy0NcxnNA@mail.gmail.com>
<2E386EE0-782D-47CB-978B-B5A010AFCF88@yahoo.com>
<1C697AD4-6CAC-4C33-8D77-72D9B53A7648@yahoo.com>
<C93E2906-864D-40F3-80A0-73DA5F7DA3E7@yahoo.com>
To: Justin Hibbits <chmeeedalf@gmail.com>
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 <freebsd-ppc.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-ppc/>
List-Post: <mailto:freebsd-ppc@freebsd.org>
List-Help: <mailto:freebsd-ppc-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=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 <marklmi at yahoo.com> 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: <owner-freebsd-ppc@freebsd.org>
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 <freebsd-ppc@mailman.ysv.freebsd.org>;
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 <freebsd-ppc@freebsd.org>; 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 <ppc@mailman.ysv.freebsd.org>; 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 <ppc@FreeBSD.org>; 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 <ppc@FreeBSD.org>; 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 <ppc@FreeBSD.org>; 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: <bug-233863-21-v2EKoowwX2@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-233863-21@https.bugs.freebsd.org/bugzilla/>
References: <bug-233863-21@https.bugs.freebsd.org/bugzilla/>
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 <freebsd-ppc.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-ppc/>
List-Post: <mailto:freebsd-ppc@freebsd.org>
List-Help: <mailto:freebsd-ppc-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=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 <marklmi26-fbsd@yahoo.com> ---
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: <owner-freebsd-ppc@freebsd.org>
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 <freebsd-ppc@mailman.ysv.freebsd.org>;
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 <freebsd-ppc@freebsd.org>; 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 <ppc@mailman.ysv.freebsd.org>; 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 <ppc@FreeBSD.org>; 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 <ppc@FreeBSD.org>; 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 <ppc@FreeBSD.org>; 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: <bug-233863-21-58iIfaxOqg@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-233863-21@https.bugs.freebsd.org/bugzilla/>
References: <bug-233863-21@https.bugs.freebsd.org/bugzilla/>
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 <freebsd-ppc.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-ppc/>
List-Post: <mailto:freebsd-ppc@freebsd.org>
List-Help: <mailto:freebsd-ppc-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-ppc>,
<mailto:freebsd-ppc-request@freebsd.org?subject=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 <marklmi26-fbsd@yahoo.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #203844|0 |1
is obsolete| |
--- Comment #20 from Mark Millard <marklmi26-fbsd@yahoo.com> ---
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.=