From owner-freebsd-arm@freebsd.org Mon Dec 24 07:28:16 2018 Return-Path: Delivered-To: freebsd-arm@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 D14A0135995D for ; Mon, 24 Dec 2018 07:28:16 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-20.consmr.mail.ne1.yahoo.com (sonic303-20.consmr.mail.ne1.yahoo.com [66.163.188.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 7F87E73265 for ; Mon, 24 Dec 2018 07:28:15 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: USfH7uwVM1mN_Vom2xbVmt1a8ZuJMmK5wDkUqu5hPZCed.rUt2Qaz4umdHTYy7C Dd8e_FBRO4PNJTxMx_6t_l.g8j2Kk6VrQfdmTNlISv8eEIZqT4eFgbfDdBLMI3_y6hhpBqtfyPZQ nIxb8IJVE20S33uIMF_RFKAW9TM.LSIkZfOxD0_3zqVgFh9HOv7REpH4JuGMSvSBlK9xFIH_cPBj FpdgT4._gjabkLhVi9fyVpmDoR4Z1gZioe7J2PN2pkyGZvMOc8WDoKy1h9C9Kvxwi66vA33HeVEI 0kFM.JYThO3q7EOfJ04lnGHyjEKUckpstH0LH2..h8ZHm6T81GOUCBjZTElJw8r8aMuXc0bwZmbk iJSZnjcIjrsVsKGul3nlroQOGkuF0n47hanlENF_cXWl1JfO.1x2iaVUcP3eQr1bxHcDJm0bg5LD EZSrQxigTv7PCWd9rdZQiasK4MvJyazvyfWZRNna97D1TSMs26zHu5L5ujudGF6Toj71qh80U.zD tyH9k4NJ07FFdSrrCQzLEOB5.57idmo3qFwycNnGbWc0l13HnNM88_AS.9iOGjody_c1RFw58Bo4 Im.I72NQFyRq0l1Cbgb9DoaNsQSWYyyIu5MWbbjqMRL4bsvx6EQ7eS6Tk3nQU9nzVZyrfBhVgv1c 5Zmtl5VtxTHuBdhqRhmcvT_jqyJD9NwZqa51b8g3fMyyoW683JEQNfd1RF2249hdEQNX7MN3T7Pb tkzeYVu81xsE9UppwiwIgiqBWWc0GnMX5xwOfYLmII2NBPdyBpBXxATwYFqyhnlkiIbtMIiYyTh3 dTuB1WUodjck_FLuOWv2E0JdO4NcsQS3Qy4Bqn5myO9PfwpAG2I1yFyh8nhVPwlQuRteggDGr4xT AmZudsABZmMDmJBm6IwuJVWmvBo16VVWT4hUkUp_w2hatHEctCCNnxJ_KGYGc1YW5kLeQ0tQHxDW BhVLLqZcGAETpJcUW0DrI9etkBFB45qrZLHOgf3BtYv5YUP5WUEBjIziyHyCbMdJKkzcsNnp4QMR gCqqcxmUWXPJ5ECjt4OtrwKeiXDD3.mERDWVyKL1XdRPOdwMkapjw3V93P9YWVS6VFVK2nd9c_jc pExodOY8- Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.ne1.yahoo.com with HTTP; Mon, 24 Dec 2018 07:28:07 +0000 Received: from c-67-170-167-181.hsd1.or.comcast.net (EHLO [192.168.1.109]) ([67.170.167.181]) by smtp427.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID bca93c63249a32ac899d0ee694652ba8; Mon, 24 Dec 2018 07:28:05 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: A reliable port cross-build failure (hangup) in my context (amd64->armv7 cross build, with native-tool speedup involved) From: Mark Millard In-Reply-To: <0154C3AC-D85B-4FCF-BA63-454BC26BC1A2@yahoo.com> Date: Sun, 23 Dec 2018 23:28:04 -0800 Cc: freebsd-arm , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: References: <865A13C8-9749-486E-9F79-5EEDDECBE621@yahoo.com> <0154C3AC-D85B-4FCF-BA63-454BC26BC1A2@yahoo.com> To: freebsd-emulation@freebsd.org, FreeBSD Current , ports-list freebsd X-Mailer: Apple Mail (2.3445.102.3) X-Rspamd-Queue-Id: 7F87E73265 X-Spamd-Bar: / X-Spamd-Result: default: False [-0.95 / 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]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[3]; 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:+]; RCVD_TLS_LAST(0.00)[]; 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.95)[-0.952,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.91)[0.908,0]; NEURAL_HAM_LONG(-0.98)[-0.985,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.59)[ip: (0.88), ipnet: 66.163.184.0/21(1.20), asn: 36646(0.96), country: US(-0.08)]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[146.188.163.66.list.dnswl.org : 127.0.5.0]; RWL_MAILSPIKE_POSSIBLE(0.00)[146.188.163.66.rep.mailspike.net : 127.0.0.17] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2018 07:28:17 -0000 [I built a FreeBSD head -r340288 context and tried ports head -r484783 and the problem repeated.] On 2018-Dec-22, at 12:55, Mark Millard wrote: > [I found my E-mail records reporting successful builds using > qemu-user-static from ports head -r484783 under FreeBSD > head -r340287.] >=20 > On 2018-Dec-22, at 00:10, Mark Millard wrote: >=20 >> [I messed up the freebsd-emulation email address the first time I = sent >> this. I also forgot to indicate the qemu-user-static vintage = relationship.] >>=20 >> I had been reporting intermittent hang-ups for my = amd64->{aarch64,armv7} port cross >> builds in another message sequence. But it turns out that one thing I = ran into >> has hung-up every time, the same way, for amd64->armv7 cross builds: >> multimedia/gstreamer1-qt@qt5 . So I extract the material here into a = separate report >> with some updated notes. >>=20 >> A little context: I had built from ports head -r484783 before under = FreeBSD head >> -r340287 (as I remember the version). Back then it did not have this = problem that it >> now has under FreeBSD head -r341836 . One ports-specific change was = to force perl5.28 >> as the default instead of perl5.26 originally. In fact this is what = drives what is >> being rebuilt for my experiment that caught this. But I doubt the = perl version is >> important to the problem. The context has a Ryzen Threadripper 1950X = and has been >> tested both for FreeBSD under Hyper-V and for the same media = native-booted. Both >> hang-up at the same point as seen via ps or top. The native tools for = cross-build >> speedup were in use. Cross-builds targeting aarch64 did not get this = problem but >> targeting armv7 did. 121 of 129 armv7 ports built before the hang-up = for the first >> armv7 try. >>=20 >> ADDED: The qemu-user-static back with head -r340287 before installing = the >> updated ports would likely be different than the -r484783 vintage. So = both >> FreeBSD and qemu-user-static may have changed over the comparison. >=20 > CORRECTION to ADDED: Back on 2018-Nov-11 I reported successful = cross-builds > based on qemu-user-static from ports head -484783 --all built under = FreeBSD > head -r340287 . So the use of the perl5.28 as the forced-default and = the > newer FreeBSD head version -r341836 as the context are the differences = here. >=20 >> The hang-up: >>=20 >> In the port rebuilds targeting armv7, multimedia/gstreamer1-qt@qt5 = hung-up and timed >> out. Looking during the wait in later tries shows something much like = (from one of the >> examples): >>=20 >> root 33719 0.0 0.0 12920 3528 0 I 11:40 = 0:00.03 | | `-- sh: poudriere[FBSDFSSDjailArmV7-default][02]: = build_pkg (gstreamer1-qt5-1.2.0_14) (sh) >> root 41551 0.0 0.0 12920 3520 0 I 11:43 = 0:00.00 | | `-- sh: = poudriere[FBSDFSSDjailArmV7-default][02]: build_pkg = (gstreamer1-qt5-1.2.0_14) (sh) >> root 41552 0.0 0.0 10340 1744 0 IJ 11:43 = 0:00.01 | | `-- /usr/bin/make -C = /usr/ports/multimedia/gstreamer1-qt FLAVOR=3Dqt5 build >> root 41566 0.0 0.0 10236 1796 0 IJ 11:43 = 0:00.00 | | `-- /bin/sh -e -c (cd = /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.build; if ! = /usr/bin/env QT_SELE >> root 41567 0.0 0.0 89976 12896 0 IJ 11:43 = 0:00.07 | | `-- /usr/local/bin/qemu-arm-static ninja = -j28 -v all >> root 41585 0.0 0.0 102848 25056 0 IJ 11:43 = 0:00.10 | | |-- /usr/local/bin/qemu-arm-static = /usr/local/bin/cmake -E cmake_autogen /wrkdirs/usr/ports/multimedia/g >> root 41586 0.0 0.0 102852 25072 0 IJ 11:43 = 0:00.11 | | `-- /usr/local/bin/qemu-arm-static = /usr/local/bin/cmake -E cmake_autogen /wrkdirs/usr/ports/multimedia/g >>=20 >> or as top showed it: >>=20 >> 41552 root 1 52 0 10M 1744K 0 wait 15 0:00 = 0.00% /usr/bin/make -C /usr/ports/multimedia/gstreamer1-qt FLAVOR=3Dqt5 = build >> 41566 root 1 52 0 10M 1796K 0 wait 1 0:00 = 0.00% /bin/sh -e -c (cd = /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.build; if ! = /usr/bin/env QT_SELECT=3Dqt5 QMAKEMODULES >> 41567 root 2 52 0 88M 13M 0 select 4 0:00 = 0.00% /usr/local/bin/qemu-arm-static ninja -j28 -v all >> 41585 root 2 52 0 100M 24M 0 kqread 8 0:00 = 0.00% /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E = cmake_autogen /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/. >> 41586 root 2 52 0 100M 24M 0 kqread 22 0:00 = 0.00% /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E = cmake_autogen /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/. >>=20 >> So: waiting in kqread trying to run cmake. >>=20 >> Unlike some intermittent hang-ups, attaching-then-detaching via gdb = does not >> resume the hung-up processes. Kills of the processes waiting on = kqread stop >> the build. >>=20 >> Given the prior ports have been built already, building just >> multimedia/gstreamer1-qt@qt5 still gets the hang-up at the same = point. >>=20 >> Building anything that requires multimedia/gstreamer1-qt@qt5 seems to = be >> solidly blocked in my environment. I built a FreeBSD head -r340288 context and tried cross-buiding an amd64->armv7 ports head -r484783 of my usual ports and the problem repeated. I also found evidence that originally in the old time frame I'd disabled part of my originally-intended port builds because of other problems so multimedia/gstreamer1-qt 's build was not being tried. So the qemu-user-static vintage or content may be what to vary to narrow down the problem instead of bisecting FreeBSD kernel or world vintages. clang7 building qemu-user-static or the kernel/world has been eliminated. (I used -r340288 to match a artifact.ci.freebsd.org build, incorrectly expecting to bisect via kernel substitutions.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Mon Dec 24 23:22:04 2018 Return-Path: Delivered-To: freebsd-arm@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 C404B13520C9 for ; Mon, 24 Dec 2018 23:22:04 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-9.consmr.mail.gq1.yahoo.com (sonic316-9.consmr.mail.gq1.yahoo.com [98.137.69.33]) (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 55E6A70583 for ; Mon, 24 Dec 2018 23:22:03 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: jc9vBN0VM1kakff0WoBrDD4DIc.ekchzD54fAUII3y4VkVTxL.MJLdXbDNrgg1y QAo.Qv5U8JH.k8Oot96.To52UGsYIfkKBiZt5UOgdVkr5nhPH20LKsNhx_AGMwbUP.d.JQNsoPCq NS3FlpcGKbphHTUDioV9Gpa4DC0JVQEFXEZEg47vy3TRQgCbA9Kct.es3lf0HJewX4DoetTkt9wA Fuyk2xX1MHCd_U3fxxucxZSCF5zJKvyozFx2P2r6VZkXHiaNREzEOqqyGqIzf0zxS2Z3Cs8djt8. .XJ4z.KzURMeWCKp7DDa5UG4X_5AKMhGSIK9bnFOx5syRbniIj6uyfikxh0LEZ6U86AGxVH9kYTt BfUdUsh2O_twG6xgLG8zgiAhHjTaXLBAR_fmja72_XbSPV_7ld84o7rWgiM0y7EiNsyBZgsRZdNn SuOt3tO2VbH30.TEH_4oihnHYyH8EpS6CMKMe3u6wGqOTnHrMxttUgCwT74ObwMCXl5zs9s2t5O7 p4SdCvH8a6zYfLKMT8rQHA9zwK18asmdVDhHdYN5PFqJ6247h4iudy1EbOYzafkbiQ.x7p2pFNbF HUnmMgsLNHp4R0WC5.zpwzHWgU6w7TIySlQMafItvEodFJxbSu0Sc8ZpcEdLvLsOLsI_BR91K0in xKEF.yC2M_5Mw3m__myYuyFWxCVzG5OWSr7AbQJjC.Q.atO2QQBzQOj4Kqtnfa8FHNgkPEnYpjsn eug27zrYfCHNv28fZGq3H81qxThFo2enaNBeqfvRa2PvmprtjEx.c8Uta7Z0xGSPwBKEsrmghnFV FcE4zZIW9wLjJEm2QP4XvCgHJ18Jb.TiKvlGubDru5fga5lh9pSgoV0qdeewpYleYXhySKEHu3iN U31PDlDKhEf674o_Sg7gPc7Y10wqyUcTUMZFWhzl0zDQAXdGXKkPEt_D1SUdDdjuQNdS7u1r.7Gx cWkd7HHtdrzqTIIgnz36TDZeo0RZBCbjITfxAD1fhpSGcu0fuAss1EbX5UcWg0p71HEAYfW5jBI2 sIzJdNTpJlKfNHWU63NDreDAjmkzVW5jSAzeYG63NKcD9CFaynFONQxCyiThCfys_mtwJn04tBpK FeT9YiuQ- Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Mon, 24 Dec 2018 23:21:55 +0000 Received: from c-67-170-167-181.hsd1.or.comcast.net (EHLO [192.168.1.109]) ([67.170.167.181]) by smtp428.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID d4e2bcc862475bbb020a8fed632a7afe; Mon, 24 Dec 2018 23:21:50 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: A reliable port cross-build failure (hangup) in my context (amd64->armv7 cross build, with native-tool speedup involved) From: Mark Millard In-Reply-To: <0154C3AC-D85B-4FCF-BA63-454BC26BC1A2@yahoo.com> Date: Mon, 24 Dec 2018 15:21:50 -0800 Cc: freebsd-arm , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <5C3F09FE-EA50-452D-98EE-364B7BF3ECD0@yahoo.com> References: <865A13C8-9749-486E-9F79-5EEDDECBE621@yahoo.com> <0154C3AC-D85B-4FCF-BA63-454BC26BC1A2@yahoo.com> To: freebsd-emulation@freebsd.org, FreeBSD Current , ports-list freebsd X-Mailer: Apple Mail (2.3445.102.3) X-Rspamd-Queue-Id: 55E6A70583 X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.74 / 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]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[3]; MX_GOOD(-0.01)[cached: mta6.am0.yahoodns.net]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.30)[-0.305,0]; 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(-1.00)[-0.999,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.07)[ip: (-0.70), ipnet: 98.137.64.0/21(0.63), asn: 36647(0.50), country: US(-0.08)]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[33.69.137.98.list.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2018 23:22:05 -0000 [A native poudreire-devel based build of multimedia/gstreamer1-qt@qt5 did not hang-up and worked fine. Official package build history also provides some evidence.] On 2018-Dec-22, at 12:55, Mark Millard wrote: > [I found my E-mail records reporting successful builds using > qemu-user-static from ports head -r484783 under FreeBSD > head -r340287.] >=20 > On 2018-Dec-22, at 00:10, Mark Millard wrote: >=20 >> [I messed up the freebsd-emulation email address the first time I = sent >> this. I also forgot to indicate the qemu-user-static vintage = relationship.] >>=20 >> I had been reporting intermittent hang-ups for my = amd64->{aarch64,armv7} port cross >> builds in another message sequence. But it turns out that one thing I = ran into >> has hung-up every time, the same way, for amd64->armv7 cross builds: >> multimedia/gstreamer1-qt@qt5 . So I extract the material here into a = separate report >> with some updated notes. >>=20 >> A little context: I had built from ports head -r484783 before under = FreeBSD head >> -r340287 (as I remember the version). Back then it did not have this = problem that it >> now has under FreeBSD head -r341836 . One ports-specific change was = to force perl5.28 >> as the default instead of perl5.26 originally. In fact this is what = drives what is >> being rebuilt for my experiment that caught this. But I doubt the = perl version is >> important to the problem. The context has a Ryzen Threadripper 1950X = and has been >> tested both for FreeBSD under Hyper-V and for the same media = native-booted. Both >> hang-up at the same point as seen via ps or top. The native tools for = cross-build >> speedup were in use. Cross-builds targeting aarch64 did not get this = problem but >> targeting armv7 did. 121 of 129 armv7 ports built before the hang-up = for the first >> armv7 try. >>=20 >> ADDED: The qemu-user-static back with head -r340287 before installing = the >> updated ports would likely be different than the -r484783 vintage. So = both >> FreeBSD and qemu-user-static may have changed over the comparison. >=20 > CORRECTION to ADDED: Back on 2018-Nov-11 I reported successful = cross-builds > based on qemu-user-static from ports head -484783 --all built under = FreeBSD > head -r340287 . So the use of the perl5.28 as the forced-default and = the > newer FreeBSD head version -r341836 as the context are the differences = here. >=20 >> The hang-up: >>=20 >> In the port rebuilds targeting armv7, multimedia/gstreamer1-qt@qt5 = hung-up and timed >> out. Looking during the wait in later tries shows something much like = (from one of the >> examples): >>=20 >> root 33719 0.0 0.0 12920 3528 0 I 11:40 = 0:00.03 | | `-- sh: poudriere[FBSDFSSDjailArmV7-default][02]: = build_pkg (gstreamer1-qt5-1.2.0_14) (sh) >> root 41551 0.0 0.0 12920 3520 0 I 11:43 = 0:00.00 | | `-- sh: = poudriere[FBSDFSSDjailArmV7-default][02]: build_pkg = (gstreamer1-qt5-1.2.0_14) (sh) >> root 41552 0.0 0.0 10340 1744 0 IJ 11:43 = 0:00.01 | | `-- /usr/bin/make -C = /usr/ports/multimedia/gstreamer1-qt FLAVOR=3Dqt5 build >> root 41566 0.0 0.0 10236 1796 0 IJ 11:43 = 0:00.00 | | `-- /bin/sh -e -c (cd = /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.build; if ! = /usr/bin/env QT_SELE >> root 41567 0.0 0.0 89976 12896 0 IJ 11:43 = 0:00.07 | | `-- /usr/local/bin/qemu-arm-static ninja = -j28 -v all >> root 41585 0.0 0.0 102848 25056 0 IJ 11:43 = 0:00.10 | | |-- /usr/local/bin/qemu-arm-static = /usr/local/bin/cmake -E cmake_autogen /wrkdirs/usr/ports/multimedia/g >> root 41586 0.0 0.0 102852 25072 0 IJ 11:43 = 0:00.11 | | `-- /usr/local/bin/qemu-arm-static = /usr/local/bin/cmake -E cmake_autogen /wrkdirs/usr/ports/multimedia/g >>=20 >> or as top showed it: >>=20 >> 41552 root 1 52 0 10M 1744K 0 wait 15 0:00 = 0.00% /usr/bin/make -C /usr/ports/multimedia/gstreamer1-qt FLAVOR=3Dqt5 = build >> 41566 root 1 52 0 10M 1796K 0 wait 1 0:00 = 0.00% /bin/sh -e -c (cd = /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.build; if ! = /usr/bin/env QT_SELECT=3Dqt5 QMAKEMODULES >> 41567 root 2 52 0 88M 13M 0 select 4 0:00 = 0.00% /usr/local/bin/qemu-arm-static ninja -j28 -v all >> 41585 root 2 52 0 100M 24M 0 kqread 8 0:00 = 0.00% /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E = cmake_autogen /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/. >> 41586 root 2 52 0 100M 24M 0 kqread 22 0:00 = 0.00% /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E = cmake_autogen /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/. >>=20 >> So: waiting in kqread trying to run cmake. >>=20 >> Unlike some intermittent hang-ups, attaching-then-detaching via gdb = does not >> resume the hung-up processes. Kills of the processes waiting on = kqread stop >> the build. >>=20 >> Given the prior ports have been built already, building just >> multimedia/gstreamer1-qt@qt5 still gets the hang-up at the same = point. >>=20 >> Building anything that requires multimedia/gstreamer1-qt@qt5 seems to = be >> solidly blocked in my environment. I tried building multimedia/gstreamer1-qt@qt5 on a Orange Pi 2 2nd Edition and the build did not hang-up. This was also based on FreeBSD head -r341836 and ports head -r484783 . This test was set up in part by copying over the /usr/local/poudriere/data/packages/ material from what that did cross build. So, for example, the cmake used should be a binary exact match. The FreeBSD head -r341836 was installed from the same buildworld buildkernel tree that the cross-build's installworld was based on. The problem is somehow specific to cross-builds (and so qemu-user-static being involved). Other evidence (official package build attempts): I looked at beefy16.nyi.freebsd.org 's head-armv7-default and beefy8.nyi.freebsd.org 's head-armv6-default histories and the problem does not exist for the: FreeBSD -r332419 ports -r467121 combination but exists for the later ones, starting with: FreeBSD -r332632 ports -r467547 Interestingly qemu-sbruno (the master port for qemu-user-static) was not updated in that ports range, being from -r463452 . There was a cmake change at -r467437 but the more modern native result suggests cmake is not currently contributing (and, so, likely was not the issue back then). That possibly leaves qemu-user-static for targeting armv7 (and v6) misinterpreting something different from the different FreeBSD versions. For example, there was a change to return EAGAIN instead of EIO for certain conditions, between -r332419 and -r332632 : at -r332631 . (I do not know that it is involved.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Wed Dec 26 22:47:04 2018 Return-Path: Delivered-To: freebsd-arm@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 92DC5135F114 for ; Wed, 26 Dec 2018 22:47:04 +0000 (UTC) (envelope-from freebsd-arm@sentry.org) Received: from shadow.sentry.org (shadow.sentry.org [210.8.237.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "shadow.sentry.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9A17270888 for ; Wed, 26 Dec 2018 22:46:55 +0000 (UTC) (envelope-from freebsd-arm@sentry.org) Received: from shadow.sentry.org (localhost [127.0.0.1]) by shadow.sentry.org (8.15.2/8.15.2) with ESMTP id wBQMY5nw092398 for ; Thu, 27 Dec 2018 09:34:06 +1100 (AEDT) (envelope-from freebsd-arm@sentry.org) Subject: Re: How much memory to compile www/chromium? References: <20181212165313.GA84881@www.zefox.net> <20181212184149.ol44fon2unowu35q@squirrel.exwg.net> <20181212192115.GA85583@www.zefox.net> <20181212202504.4n3mhtx7grbeh6j7@squirrel.exwg.net> <20181214012733.GA92808@www.zefox.net> <20181218174903.GA41072@www.zefox.net> From: Trev To: freebsd-arm@freebsd.org Message-ID: Date: Thu, 27 Dec 2018 09:34:05 +1100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.4 MIME-Version: 1.0 In-Reply-To: <20181218174903.GA41072@www.zefox.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (shadow.sentry.org [0.0.0.0]); Thu, 27 Dec 2018 09:34:06 +1100 (AEDT) X-Rspamd-Queue-Id: 9A17270888 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of freebsd-arm@sentry.org designates 210.8.237.106 as permitted sender) smtp.mailfrom=freebsd-arm@sentry.org X-Spamd-Result: default: False [-0.82 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.83)[-0.833,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.66)[-0.655,0]; TO_DN_NONE(0.00)[]; MX_GOOD(-0.01)[sentinel.sentry.org,garrison.sentry.org,shadow.sentry.org,sentry.org]; NEURAL_HAM_SHORT(-0.02)[-0.018,0]; DMARC_NA(0.00)[sentry.org]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:2764, ipnet:210.8.0.0/14, country:AU]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(-0.01)[country: AU(-0.03)]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Dec 2018 22:47:04 -0000 bob prohaska wrote on 19/12/2018 04:49: > The resulting executable turned up in /usr/local/bin/chrome, which was > slightly surprising;=20 Turns out that's a wrapper script pointing to the executable at=20 /usr/local/share/chromium/chrome > It seems to run, but is too slow to play Youtube videos smoothly. For s= tatic=20 > pages it seems fine. >=20 > The major problem is a complete lack of audio. My major problem is that after compiling for several days (there were=20 quite a few prerequisites) I end up with: $ chrome ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ" All ports were recompiled a week earlier over many days after the jump=20 from 12-CURRENT to 13-CURRENT. (FreeBSD rpi3 13.0-CURRENT FreeBSD=20 13.0-CURRENT r342189 RPI3 arm64.) Arghhhh... From owner-freebsd-arm@freebsd.org Fri Dec 28 08:16:54 2018 Return-Path: Delivered-To: freebsd-arm@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 1E3BB143085A for ; Fri, 28 Dec 2018 08:16:54 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-19.consmr.mail.gq1.yahoo.com (sonic305-19.consmr.mail.gq1.yahoo.com [98.137.64.82]) (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 C15F77764F for ; Fri, 28 Dec 2018 08:16:52 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: y6hfxTIVM1m.UxJCWvaYFp.vJKhuoLDTG_f_sirbOSO1O5EmN7wxLtXZg3PD7u5 IUMsJkJqN6D_bsApJEsaBJ6V0l_ODYd.RS2ZF9KtLSwHqVOQHhCtPNxrovKLhXBypoW8uO2tU1Ct Ge9XCCXnRHzbBs3UfhBOa1PfljZGeWT61nnu3Swe9lvuAyPR51kSxqrTcAwxafFM_aoLD.yQFTkM i1Q.7Cb.KDkgZZZAr30w4Rd2J226rzB3pkojIzxHA6SGT1Acqp90X2GiSA4ODBN7D8g2QQLAUK8t 1kMvbBdMegsL6ToHHxM6sYj9TuJ37xM9Ob2pbhzc5OftI516KbTgZy9CKt2w92Bh1nbPfVNfneZj akbN96c.KD5XLhpJaHaFr1K9_jri2dCxEc_mwUCngJ2HH29Ql1u2wWgcsV5VtyyJSswkYWcQVr6f LvANHL4.RrGX6E5r7_JRdsjeHBQhn79KNHuCu6HNxvdAcZMMoeFdVdU0PlsuhWRorgU7kso2M294 T6JzaKLfYosROjFpVxnd4mVpS8zGG48KaYin7M_PtT7zfmofpaqI7dHFIELoie9nrkij_j6yAuMn TsQdFS5ZUw16cHHtks3zek8ArfZlDQedPjqz1kHnJQofZVJVZxiZ6pUt_kc9zK_LTCIx6zPXLonD RUgp.zXw4hMN8.Gg1uDqaOCWudORkvu2nvwMl6cwzaANKKiTmgLwMnfgng69H8CDUxZbDfx1aui0 ojG1uxneuYppp.i9LRH9vFdUOJiOVnAfI_1C_wCCa6cYE8_pUKt4zLSc5n2xDFOW0eZNXz1l1BQQ 0qOKLd1rS7HcjQXyHUl_lQB2aBkjXGdMF_sbVD3HRx7aQQQARxBijmeidocneyY6lA1wwAb5KyPE GxsaVM5rivSiDPCTCO_ZwWdD3kcLUkuQUQS6g44ksfKqPKEoeVyDFOn4bKM6yMK5ZPGW1MPHdWdW U4G8AFmn4.WlBMFgmyMqsUceZ238hKSJJ.62oZK6fsKVjAA.5lrv1IJ5vlTh4c7Fj9NG18nEsAGK 9YchCBSoC4tS2WRUAbyq5P1LgIazbiV73WNWdHJOEsMAx0ue80hrTCNpt04.F1vGNVRZXyWT6IhZ MMA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Fri, 28 Dec 2018 08:16:51 +0000 Received: from c-67-170-167-181.hsd1.or.comcast.net (EHLO [192.168.1.109]) ([67.170.167.181]) by smtp423.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 8f402acdf959e803df861ac1ea528308; Fri, 28 Dec 2018 08:16:49 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: A reliable port cross-build failure (hangup) in my context (amd64->armv7 cross build, with native-tool speedup involved) From: Mark Millard In-Reply-To: <5C3F09FE-EA50-452D-98EE-364B7BF3ECD0@yahoo.com> Date: Fri, 28 Dec 2018 00:16:48 -0800 Cc: freebsd-arm , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <3946C94A-FCA6-49FE-ADDB-B042BBE50913@yahoo.com> References: <865A13C8-9749-486E-9F79-5EEDDECBE621@yahoo.com> <0154C3AC-D85B-4FCF-BA63-454BC26BC1A2@yahoo.com> <5C3F09FE-EA50-452D-98EE-364B7BF3ECD0@yahoo.com> To: freebsd-emulation@freebsd.org, FreeBSD Current , ports-list freebsd X-Mailer: Apple Mail (2.3445.102.3) X-Rspamd-Queue-Id: C15F77764F X-Spamd-Bar: / X-Spamd-Result: default: False [0.01 / 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]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[3]; 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.41)[-0.406,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.88)[0.875,0]; NEURAL_HAM_LONG(-0.84)[-0.837,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.89)[ip: (3.41), ipnet: 98.137.64.0/21(0.62), asn: 36647(0.49), country: US(-0.08)]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[82.64.137.98.list.dnswl.org : 127.0.5.0]; RWL_MAILSPIKE_POSSIBLE(0.00)[82.64.137.98.rep.mailspike.net : 127.0.0.17] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2018 08:16:54 -0000 [The historical notes are removed and replaced by partial trace information from example hang-ups, not that I've figured out what contributes yet.] I ran into the following while trying to get evidence about the hang-up for an amd64->armv7 cross-build of multimedia/gstreamer1-qt@qt5 . The following from trying to get evidence for the hang-up via a manual run of "make multimedia/gstreamer1-qt FLAVOR=3Dqt5=E2=80=9D in a poudriere bulk -i=E2=80=99s interactive mode for the context that has the hang-up in normal poudriere-devel runs. =46rom top after the hang-up (to identify some context): 14528 root 2 52 0 100M 24M 0 kqread 11 0:00 = 0.00% /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E = cmake_autogen /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/. 14527 root 2 52 0 88M 13M 0 select 22 0:00 = 0.00% /usr/local/bin/qemu-arm-static ninja -j1 -v all from ps -auxd as well (to identify more context): root 10114 0.0 0.0 10328 1756 1 I+J 13:47 0:00.01 | = `-- make FLAVOR=3Dqt5 root 14526 0.0 0.0 10204 1792 1 I+J 13:50 0:00.00 | = `-- /bin/sh -e -c (cd = /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.build; if ! = /usr/bin/env QT_SELE root 14527 0.0 0.0 90304 13084 1 I+J 13:50 0:00.09 | = `-- /usr/local/bin/qemu-arm-static ninja -j1 -v all root 14528 0.0 0.0 102876 25060 1 IJ 13:50 0:00.12 | = `-- /usr/local/bin/qemu-arm-static = /usr/local/bin/cmake -E cmake_autogen /wrkdirs/usr/ports/multimedia/g I had made a qemu-user-static that enabled do_strace when it is used to run cmake or ninja. The only do_strace lines from qemu-arm-static running cmake or ninja mentioning process 14528 are included in the sequence: (Before the below was a long list of "14527 fstatat=E2=80=9D lines. I=E2=80=99ll note that "'Unknown syscall 545=E2=80=9D is from ppoll = use.) 82400 sigprocmask(1,-1610620016,-191968524,-186261416,0,24) =3D 0 82400 sigaction(2,-1610620040,-191968596,-186261584,210460,0) =3D 0 82400 sigaction(15,-1610620040,-191968572,-186261584,210460,0) =3D 0 82400 sigaction(1,-1610620040,-191968548,-186261584,210460,0) =3D 0 82400 gettimeofday(-1610619984,0,4,-186261584,-1610619440,-1610619528) =3D= 0 82400 gettimeofday(-1610619984,0,4,359949,1545969996,0) =3D 0 82400 gettimeofday(-1610620120,0,4,2,-184666112,-1610619520) =3D 0 82400 fstatat(-100,"elements/gstqtvideosink/CMakeFiles", 0x9fffe200, 0) = =3D 0 82400 fstatat(-100,"elements/gstqtvideosink/gstqt5videosink_autogen", = 0x9fffe200, 0) =3D 0 82400 pipe2(-1610620176,0,-1610620108,0,-1610620120,167084) =3D 0 82400 fcntl(5,1,-1610620108,-185863932,-192200556,-1610620228) =3D 0 82400 fcntl(5,2,1,-185863932,-192200556,-1610620228) =3D 0 82400 vfork(0,66450,-186876196,-1610620184,-1610620240,0) =3D 82401 82400 close(6) =3D 0 =3D 0 82400 Unknown syscall 545 82401 setpgid(0,0,-186876196,-1610620184,-1610620240,0) =3D 0 82401 sigprocmask(3,-191586912,0,-1610620184,-1610620240,0) =3D 0 82401 close(5) =3D 0 82401 open("/dev/null",0,0) =3D 5 82401 dup2(5,0,0,-1610620184,-1610620240,0) =3D 0 82401 close(5) =3D 0 82401 fcntl(0,2,0,-1610620184,-1610620240,0) =3D 0 82401 dup2(6,1,0,-1610620184,-1610620240,0) =3D 1 82401 fcntl(1,2,0,-1610620184,-1610620240,0) =3D 0 82401 dup2(6,2,0,-1610620184,-1610620240,0)82400 = sigpending(-1610620072,1,0,-191968524,0,0) =3D 0 The vfork then close(6) sequence for 82400 vs. the later use of 6 in dup2 in 82401 may be rather odd. But it looks like qemu-*-static uses do_freebsd_fork to implement do_freebsd_vfork, despite reporting vfork before calling do_freebsd_vfork. (Does the close(6) appear to indicate a race for native operation of ninja for the period when the address space is shared?) Ninja has Subprocess::Start code that has: #ifdef POSIX_SPAWN_USEVFORK flags |=3D POSIX_SPAWN_USEVFORK; #endif if (posix_spawnattr_setflags(&attr, flags) !=3D 0) Fatal("posix_spawnattr_setflags: %s", strerror(errno)); const char* spawned_args[] =3D { "/bin/sh", "-c", command.c_str(), = NULL }; if (posix_spawn(&pid_, "/bin/sh", &action, &attr, const_cast(spawned_args), environ) !=3D 0) Fatal("posix_spawn: %s", strerror(errno)); that is in use here. I think that this explains the vfork use. It turns out that putting the hung-up build in the background and then killing 82401 with the likes of kill -6 leads to more output that had apparently been buffered. It shows the use of the (amd64 native) /bin/sh that in turn leads to /usr/local/bin/cmake via qemu-arm-static. /bin/sh, being native, gets no do_strace output from qemu-arm-static. 82400 sigpending(-1610620072,1,0,-191968524,0,0) =3D 0 82400 read(5,0x9fffd368,4096) =3D 58 82400 Unknown syscall 545 82400 sigpending(-1610620072,1,0,-191968524,0,0) =3D 0 82400 read(5,0x9fffd368,4096) =3D 0 82400 close(5) =3D 0 82400 wait4(82401,-1610620004,0,0,-191968640,0) =3D 82401 82400 mmap(0,86016,3,201330690,-1,-1610620169) =3D 0xf4777000 82400 gettimeofday(-1610620224,0,4,-1610619944,31,16777216) =3D 0 82400 write(1,0xf4950000,283)[1/129] cd = /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.build/elements/gstqt= videosink && /usr/local/bin/cmake -E cmake_autogen = /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.build/elements/gstqt= videosink/CMakeFiles/gstqt5videosink_autogen.dir/AutogenInfo.cmake Debug =3D 283 82400 write(1,0xf4950000,137)FAILED: = elements/gstqtvideosink/CMakeFiles/gstqt5videosink_autogen = elements/gstqtvideosink/gstqt5videosink_autogen/mocs_compilation.cpp=20 =3D 137 82400 write(1,0xf4950000,275)cd = /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.build/elements/gstqt= videosink && /usr/local/bin/cmake -E cmake_autogen = /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.build/elements/gstqt= videosink/CMakeFiles/gstqt5videosink_autogen.dir/AutogenInfo.cmake Debug =3D 275 82400 write(1,0xf4950000,5) =3D 2 =3D 5 (Note that some 82400 writes are reporting 82401 information:) 82400 write(1,0xf4950000,49)82401 fcntl(2,2,0,-1610620184,-1610620240,0) = =3D 0 =3D 49 82400 write(1,0xf4950000,19)82401 close(6) =3D 0 =3D 19 82400 write(1,0xf4950000,401)82401 execve("/bin/sh",{"/bin/sh","-c","cd = /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.build/elements/gstqt= videosink && /usr/local/bin/cmake -E cmake_autogen = /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.build/elements/gstqt= videosink/CMakeFiles/gstqt5videosink_autogen.dir/AutogenInfo.cmake = Debug",NULL})82401 __sysctl({ 0 3 }, 2, 0x9fffda80, 0x9fffdf64, = 0xf5002097, 0x0000000c) =3D 0 =3D 401 (The /bin/sh activity is not logged: /bin/sh is native amd64 code here. = The below is from the later /usr/local/bin/cmake via qemu-arm-static. . . . (much omitted) . . . 82400 write(1,0xf4950000,60)82401 = mmap(0,28672,3,201330690,-1,-1610621989) =3D 0xf41a0000 =3D 60 82400 write(1,0xf4950000,74)82401 = clock_gettime(4,-1610621832,4,-199622492,-199622492,-199622656) =3D 0 =3D 74 82400 write(1,0xf4950000,62)82401 = kqueue(-199622656,0,53102,0,-199622656,-1610621444) =3D 3 =3D 62 82400 write(1,0xf4950000,81)82401 ioctl(3, 0x20006601 { IO GRP:0x66('f') = CMD:1 LEN:0 }, 0x0000cf6e, ...) =3D 0 =3D 81 . . . (some omitted) . . . (Then there is a fairly long sequence of access's and then a sequence of fstatat's just before:) 82400 write(1,0xf4950000,32)82401 write(9,0xf4e1a945,1) =3D 1 =3D 32 82400 write(1,0xf4950000,61)82401 = clock_gettime(4,-1610622624,4,100863,1,-199483392) =3D 0 =3D 61 82400 write(1,0xf4950000,106)82401 = kevent(3,-1610688200,2,-1610688200,1024,0)qemu: uncaught target signal 6 = (Abort trap) - core dumped =3D 106 82400 write(1,0xf4950000,41)ninja: build stopped: subcommand failed. =3D 41 So it was hung at the kevent until the kill -6 . Via another experiment ninja was at the time waiting in ppoll: Reading symbols from ninja...done. [New LWP 73023] Core was generated by `ninja'. Program terminated with signal SIGABRT, Aborted. #0 0xf4e5e0dc in _ppoll () from /lib/libc.so.7 (gdb) bt #0 0xf4e5e0dc in _ppoll () from /lib/libc.so.7 #1 0x00033bf0 in SubprocessSet::DoWork (this=3D) at = src/subprocess-posix.cc:237 Backtrace stopped: previous frame inner to this frame (corrupt stack?) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Fri Dec 28 12:54:49 2018 Return-Path: Delivered-To: freebsd-arm@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 A5A641437F02 for ; Fri, 28 Dec 2018 12:54:49 +0000 (UTC) (envelope-from toshi@ruby.ocn.ne.jp) Received: from mfdf017.ocn.ad.jp (mfdf017.ocn.ad.jp [153.128.50.72]) by mx1.freebsd.org (Postfix) with ESMTP id 5178B89AB9 for ; Fri, 28 Dec 2018 12:54:48 +0000 (UTC) (envelope-from toshi@ruby.ocn.ne.jp) Received: from mogw0929.ocn.ad.jp (mogw0929.ocn.ad.jp [153.149.227.35]) by mfdf017.ocn.ad.jp (Postfix) with ESMTP id 4BC118825B1 for ; Fri, 28 Dec 2018 21:54:41 +0900 (JST) Received: from mf-smf-unw009c1 (mf-smf-unw009c1.ocn.ad.jp [153.138.219.105]) by mogw0929.ocn.ad.jp (Postfix) with ESMTP id 48E90C8026E; Fri, 28 Dec 2018 21:54:27 +0900 (JST) Received: from ocn-vc-mts-101c1.ocn.ad.jp ([153.153.66.78]) by mf-smf-unw009c1 with ESMTP id crGjg4ISgHkOOcrelg5LsV; Fri, 28 Dec 2018 21:54:27 +0900 Received: from smtp.ocn.ne.jp ([153.149.227.135]) by ocn-vc-mts-101c1.ocn.ad.jp with ESMTP id crelgZn06EH5Bcrelgd5oy; Fri, 28 Dec 2018 21:54:27 +0900 Received: from localhost (p571097-ipngn200409sizuokaden.shizuoka.ocn.ne.jp [180.33.36.97]) by smtp.ocn.ne.jp (Postfix) with ESMTPA; Fri, 28 Dec 2018 21:54:27 +0900 (JST) Date: Fri, 28 Dec 2018 21:54:24 +0900 (JST) Message-Id: <20181228.215424.1441029979323733630.toshi@ruby.ocn.ne.jp> To: freebsd-arm@freebsd.org Subject: difference between buildkernel and release.sh for BBB From: SAITOU Toshihide Received-SPF: pass (mf-ofc-ucb059: domain designate client-ip as permitted sender) client-ip=61.118.33.32; envelope-from=; helo=mogw2030.ocn.ad.jp; X-GPG-fingerprint: 34B3 0B6A 8520 F5B0 EBC7 69F6 C055 9F8A 0D49 F8FC X-Mailer: Mew version 6.8 on Emacs 26.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 5178B89AB9 X-Spamd-Bar: ++++ Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of toshi@ruby.ocn.ne.jp designates 153.128.50.72 as permitted sender) smtp.mailfrom=toshi@ruby.ocn.ne.jp X-Spamd-Result: default: False [4.98 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; URL_IN_SUBJECT(0.40)[release.sh]; RCVD_COUNT_FIVE(0.00)[6]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:153.128.50.0/24]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_DN_NONE(0.00)[]; NEURAL_SPAM_MEDIUM(0.93)[0.928,0]; RCPT_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[ocn.ne.jp]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MX_GOOD(-0.01)[cached: mfgw1.ocn.ad.jp]; NEURAL_SPAM_LONG(0.76)[0.757,0]; MID_CONTAINS_FROM(1.00)[]; NEURAL_SPAM_SHORT(0.70)[0.703,0]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:4713, ipnet:153.128.0.0/11, country:JP]; IP_SCORE(0.90)[ip: (3.04), ipnet: 153.128.0.0/11(2.10), asn: 4713(-0.54), country: JP(-0.09)] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2018 12:54:49 -0000 What is a difference in kernel between these two? make buildkernel TARGET=arm TARGET_ARCH=armv7 KERNCONF=BEAGLEBONE release.sh -c arm/BEAGLEBONE.conf The former kernel can't create spigen0 node. I'm using am335x-boneblack.dtb with the following additions. &am33xx_pinmux { spi0_pins: pinmux-spi0-pins { pinctrl-single,pins = < 0x150 0x0 0x154 0x0 0x158 0x0 0x15c 0x0 >; }; }; &spi0 { status = "okay"; pinctrl-names = "default"; pinctrl-0 = <&spi0_pins>; spigen0 { compatible = "freebsd,spigen"; reg = <0x0>; status = "okay"; }; }; -- SAITOU Toshihide From owner-freebsd-arm@freebsd.org Fri Dec 28 13:13:28 2018 Return-Path: Delivered-To: freebsd-arm@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 2738314385F1; Fri, 28 Dec 2018 13:13:28 +0000 (UTC) (envelope-from melounmichal@gmail.com) Received: from mail-wm1-x343.google.com (mail-wm1-x343.google.com [IPv6:2a00:1450:4864:20::343]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 188EA8A45C; Fri, 28 Dec 2018 13:13:27 +0000 (UTC) (envelope-from melounmichal@gmail.com) Received: by mail-wm1-x343.google.com with SMTP id t200so7734110wmt.0; Fri, 28 Dec 2018 05:13:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:subject:to:cc:references:openpgp:autocrypt:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=JdfPZqVXFSTDaypPNx9VwESn1tLKAY4b6HjsrDtJslo=; b=bu9+24h1dO+/JxYYnWaPP2s3+R+cADexDDheDvowoosSR7dkrdH0uWs8hYSGXcLX3d f3TzO3B8Chq7VxLQXTHwVUCDqfrdkXQblWufbzH97QrVrRqzYQqyOGn1fb+/0Ey621/8 8iq4hIC2o5omM5/DmANFR/84UKBIrba2MQYJS9+A+994NZr5FO4vuz3Jxs+mMq6iET9s hhagzZop6Dfrlzin9A1RZrBgiKKARYxWoZVVtBC0Ra6QO5IGbgdBJoFYW6MWiCUH2zsR 3SCd5UhrUSYGQ1mb2ucIIG2C/z7i2SsHlte0Hc4OH57kzEz6+/N+XzmvZwAh2k+qYD38 aXgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:subject:to:cc:references:openpgp :autocrypt:message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=JdfPZqVXFSTDaypPNx9VwESn1tLKAY4b6HjsrDtJslo=; b=a5Uv5++JU1JdxuveF+OU7Df6WSK+a8o/XeaasACZLkbwAycdhzPo7rv6QPVm4GxPpw 7F3RMdwFgaIR3x5NwFwzpW8es2lqOWazYA+LWu83TSW0fD0mY37H6d3ofs06p4AMo8Mr yuUjjE6KM0c1TIt2b6tI/mO+799Ij0ZGjXk+qMklD38tfJg9pGh5aVESIh7ZyFG7eZyN 8CWLSLiO7HNgFiJzc7fzc2Jzv3mmLN38V9wgYIjww9n9HCZAWyA/7xVklgrTIaLwdnXs O9rn3633PAiY6abx8vJbScLNqnHGxjxmZ08QZs/IprKF0rO6KSHbhN3VmMyJjNtnqJsk jgkA== X-Gm-Message-State: AA+aEWbgAtq/b0PKDoYDeg5lyrfc9Mv6+BQQ0PL6ftuV/j0Nu4enfqch 9X1hkYUX6b3qwN9BNloZOziFrJUQGys= X-Google-Smtp-Source: ALg8bN6qPuX61IRuZjgq1M3f14uv4qIJOj00Y1i5Amq4Jp30ha/r3H0Wg0DIUqAJrjOy7AsXWV77Lg== X-Received: by 2002:a1c:9a0d:: with SMTP id c13mr24826750wme.41.1546002805646; Fri, 28 Dec 2018 05:13:25 -0800 (PST) Received: from [88.208.79.100] (halouny.humusoft.cz. [88.208.79.100]) by smtp.gmail.com with ESMTPSA id k7sm27601306wrl.51.2018.12.28.05.13.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Dec 2018 05:13:24 -0800 (PST) From: Michal Meloun X-Google-Original-From: Michal Meloun Reply-To: mmel@freebsd.org Subject: Re: A reliable port cross-build failure (hangup) in my context (amd64->armv7 cross build, with native-tool speedup involved) To: Mark Millard , freebsd-emulation@freebsd.org, FreeBSD Current , ports-list freebsd Cc: freebsd-arm , FreeBSD Toolchain References: <865A13C8-9749-486E-9F79-5EEDDECBE621@yahoo.com> <0154C3AC-D85B-4FCF-BA63-454BC26BC1A2@yahoo.com> Openpgp: preference=signencrypt Autocrypt: addr=mmel@freebsd.org; prefer-encrypt=mutual; keydata= mQENBFYuVRkBCADZiwLCCne3wG9b9k+R2Neo5zVo2bLaZRfNNY/v9kg283i0sb1Da4EdEiNT 15El5UyozhphUIbIR/zrVpxF1TvvFdoCyzx6a68bNY2d9dBrDcNDZC+XnyDdHQoobN87DWT1 mRVkmbg9LHZ/SVUOkGYuWyE+8UYeDAcUizuXwSK5zFWmeTyIoWNa68ifrWLfQe0p4x5jC/AI VURCi17p360vU4fhgwoMvEEhrRBWCr4DYHToFjIt2WdBy3GR1qoO0+Xkd6G+OoBULo+XDfgu L2WdPvh0K69F9/LgHkMmG5Il7SCe62QGpG2vaCgRV7BQhLX+kxlvM+WrdRatWRml4Y/3ABEB AAG0IE1pY2hhbCBNZWxvdW4gPG1tZWxAZnJlZWJzZC5vcmc+iQFABBMBCgAqAhsDBQsJCAcD BRUKCQgLBRYDAgEAAh4BAheAAhkBBQJZjBHDBQkHICOqAAoJEGkesmtexaqqIKMIAJ9xTp1w ge86ns2ZYOac5++mAgpFatohSlxYUR3gwud3Y3Ej0eumavpv/C26N6dsLnspwRenKdLbIPKe 0N8lI7CcDBIJGiFyY3c4H79QjIkYpRgbWFyCM85zEyVJpB+U7BhsgXE2uwVjE9RNhEP0KBoj sp357uqq1B1+VUO4GJ+RjdmYSOcNrjR8tTfy02456qovGjJ4JcJBlhyK6GzBKvnZSoA0s+QP OMn3gd8gdomMLEJdS3kTsfhLh2rQPZa9EmzafIyjXrirWq4+4fVFgd8SiMZyyTM+Kz30ZSUe 6SmfaQTQ/WLRIl5jku2uYQWlrRIKT9xaQzRWtZO9UgtXFRG5AQ0EVi5VGQEIALqgRkfS21D/ OqWE9mXfh2bIjrp9uC8T0MCuimbsrAdLKNNorGu2nE+rebgX8n5nYM377HOnalPGyOuXvCbQ 8MFVRdWOHxenJjXJialNdBsOf2wLva3vSSVsdoPzibWDIcJqhBOQ3EuhsILyWSPvYYKEiy95 mfhrDtuTTOAYVR9aNQBOENztB2TDJyMx/qZmtGroGV3N0Hqde/znHPtQO8RG5/FQGMfHMI5G FMuycr1ceHnLo/ovrqAl4TYV+UHSHJ+FDE9dt9wXHclWbWbC0yNugchZq6rho5Jjfv4a2v7P pyn3HoDinh1lWP7hYA0ZNExGHekLnXWVqO/lzGS6bMEAEQEAAYkBJQQYAQoADwIbDAUCWYwR wwUJByAjqgAKCRBpHrJrXsWqqrsrB/4g4ESK5TLxUxi8pLWcLPyvwtN4Fmf7VsCVefkhakaG rDPmfvfnG+OFwN60Xqoni7GBeakl01xwT4RINfvVfShDy6cHpLS7QL/M8pzfulVX38MkVkOD yGZhwjE+jyT/kZNA1Olaw3N3IefHq3brskQ7G4d9oPep2DDbw7C4Q76uOBjxy34JVB0WOsB6 NyMQB9h6LGljQtdEddyUqwnRZzzHiGvp0hPtdYQHQZlqbj4FV9lTRK7a8Ega+y7MgmeMiztG zeXyjNP02r3PRHCPagwa57bPxH2aAh4Q7UzBBZ0GTMm7DLKNtCP58WDxblrrhZ+7kHqGK8Fs bdeUpDdEYLVd Message-ID: <13f5e4dd-33fb-2170-e31a-1b5d5f155869@freebsd.org> Date: Fri, 28 Dec 2018 14:13:25 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 188EA8A45C X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=bu9+24h1; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of melounmichal@gmail.com designates 2a00:1450:4864:20::343 as permitted sender) smtp.mailfrom=melounmichal@gmail.com X-Spamd-Result: default: False [-3.17 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_REPLYTO(0.00)[mmel@freebsd.org]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; RCPT_COUNT_FIVE(0.00)[6]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; 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(-0.08)[ip: (2.97), ipnet: 2a00:1450::/32(-1.76), asn: 15169(-1.51), country: US(-0.08)]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.980,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_SHORT(-0.11)[-0.110,0]; NEURAL_HAM_LONG(-0.99)[-0.993,0]; MIME_GOOD(-0.10)[text/plain]; REPLYTO_DOM_NEQ_FROM_DOM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[3.4.3.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]; RCVD_TLS_LAST(0.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2018 13:13:28 -0000 On 24.12.2018 8:28, Mark Millard wrote: > [I built a FreeBSD head -r340288 context and tried ports head > -r484783 and the problem repeated.] > > On 2018-Dec-22, at 12:55, Mark Millard wrote: > >> [I found my E-mail records reporting successful builds using >> qemu-user-static from ports head -r484783 under FreeBSD >> head -r340287.] >> >> On 2018-Dec-22, at 00:10, Mark Millard wrote: >> >>> [I messed up the freebsd-emulation email address the first time I sent >>> this. I also forgot to indicate the qemu-user-static vintage relationship.] >>> >>> I had been reporting intermittent hang-ups for my amd64->{aarch64,armv7} port cross >>> builds in another message sequence. But it turns out that one thing I ran into >>> has hung-up every time, the same way, for amd64->armv7 cross builds: >>> multimedia/gstreamer1-qt@qt5 . So I extract the material here into a separate report >>> with some updated notes. >>> >>> A little context: I had built from ports head -r484783 before under FreeBSD head >>> -r340287 (as I remember the version). Back then it did not have this problem that it >>> now has under FreeBSD head -r341836 . One ports-specific change was to force perl5.28 >>> as the default instead of perl5.26 originally. In fact this is what drives what is >>> being rebuilt for my experiment that caught this. But I doubt the perl version is >>> important to the problem. The context has a Ryzen Threadripper 1950X and has been >>> tested both for FreeBSD under Hyper-V and for the same media native-booted. Both >>> hang-up at the same point as seen via ps or top. The native tools for cross-build >>> speedup were in use. Cross-builds targeting aarch64 did not get this problem but >>> targeting armv7 did. 121 of 129 armv7 ports built before the hang-up for the first >>> armv7 try. >>> >>> ADDED: The qemu-user-static back with head -r340287 before installing the >>> updated ports would likely be different than the -r484783 vintage. So both >>> FreeBSD and qemu-user-static may have changed over the comparison. >> >> CORRECTION to ADDED: Back on 2018-Nov-11 I reported successful cross-builds >> based on qemu-user-static from ports head -484783 --all built under FreeBSD >> head -r340287 . So the use of the perl5.28 as the forced-default and the >> newer FreeBSD head version -r341836 as the context are the differences here. >> >>> The hang-up: >>> >>> In the port rebuilds targeting armv7, multimedia/gstreamer1-qt@qt5 hung-up and timed >>> out. Looking during the wait in later tries shows something much like (from one of the >>> examples): >>> >>> root 33719 0.0 0.0 12920 3528 0 I 11:40 0:00.03 | | `-- sh: poudriere[FBSDFSSDjailArmV7-default][02]: build_pkg (gstreamer1-qt5-1.2.0_14) (sh) >>> root 41551 0.0 0.0 12920 3520 0 I 11:43 0:00.00 | | `-- sh: poudriere[FBSDFSSDjailArmV7-default][02]: build_pkg (gstreamer1-qt5-1.2.0_14) (sh) >>> root 41552 0.0 0.0 10340 1744 0 IJ 11:43 0:00.01 | | `-- /usr/bin/make -C /usr/ports/multimedia/gstreamer1-qt FLAVOR=qt5 build >>> root 41566 0.0 0.0 10236 1796 0 IJ 11:43 0:00.00 | | `-- /bin/sh -e -c (cd /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.build; if ! /usr/bin/env QT_SELE >>> root 41567 0.0 0.0 89976 12896 0 IJ 11:43 0:00.07 | | `-- /usr/local/bin/qemu-arm-static ninja -j28 -v all >>> root 41585 0.0 0.0 102848 25056 0 IJ 11:43 0:00.10 | | |-- /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E cmake_autogen /wrkdirs/usr/ports/multimedia/g >>> root 41586 0.0 0.0 102852 25072 0 IJ 11:43 0:00.11 | | `-- /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E cmake_autogen /wrkdirs/usr/ports/multimedia/g >>> >>> or as top showed it: >>> >>> 41552 root 1 52 0 10M 1744K 0 wait 15 0:00 0.00% /usr/bin/make -C /usr/ports/multimedia/gstreamer1-qt FLAVOR=qt5 build >>> 41566 root 1 52 0 10M 1796K 0 wait 1 0:00 0.00% /bin/sh -e -c (cd /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.build; if ! /usr/bin/env QT_SELECT=qt5 QMAKEMODULES >>> 41567 root 2 52 0 88M 13M 0 select 4 0:00 0.00% /usr/local/bin/qemu-arm-static ninja -j28 -v all >>> 41585 root 2 52 0 100M 24M 0 kqread 8 0:00 0.00% /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E cmake_autogen /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/. >>> 41586 root 2 52 0 100M 24M 0 kqread 22 0:00 0.00% /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E cmake_autogen /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/. >>> >>> So: waiting in kqread trying to run cmake. >>> >>> Unlike some intermittent hang-ups, attaching-then-detaching via gdb does not >>> resume the hung-up processes. Kills of the processes waiting on kqread stop >>> the build. >>> >>> Given the prior ports have been built already, building just >>> multimedia/gstreamer1-qt@qt5 still gets the hang-up at the same point. >>> >>> Building anything that requires multimedia/gstreamer1-qt@qt5 seems to be >>> solidly blocked in my environment. > > > I built a FreeBSD head -r340288 context and tried cross-buiding an > amd64->armv7 ports head -r484783 of my usual ports and the problem > repeated. I also found evidence that originally in the old time frame > I'd disabled part of my originally-intended port builds because of > other problems so multimedia/gstreamer1-qt 's build was not being > tried. > > So the qemu-user-static vintage or content may be what to vary to > narrow down the problem instead of bisecting FreeBSD kernel or world > vintages. clang7 building qemu-user-static or the kernel/world has > been eliminated. > > > (I used -r340288 to match a artifact.ci.freebsd.org build, incorrectly > expecting to bisect via kernel substitutions.) > Mark, this is known problem with qemu-user-static. Emulation of every single interruptible syscall is broken by design (it have signal related races). Theses races cannot be solved without major rewrite of syscall emulation code. Unfortunately, nobody actively works on this, I think. Michal From owner-freebsd-arm@freebsd.org Fri Dec 28 13:13:27 2018 Return-Path: Delivered-To: freebsd-arm@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 9116914385EA; Fri, 28 Dec 2018 13:13:27 +0000 (UTC) (envelope-from melounmichal@gmail.com) Received: from mail-wr1-x443.google.com (mail-wr1-x443.google.com [IPv6:2a00:1450:4864:20::443]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7CC4F8A45B; Fri, 28 Dec 2018 13:13:26 +0000 (UTC) (envelope-from melounmichal@gmail.com) Received: by mail-wr1-x443.google.com with SMTP id q18so20884606wrx.9; Fri, 28 Dec 2018 05:13:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:subject:to:cc:references:openpgp:autocrypt:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=JdfPZqVXFSTDaypPNx9VwESn1tLKAY4b6HjsrDtJslo=; b=JlXyZS8YN5HTFZamWSZi/GNS19YmOybUKCFJMINKQKVaP//C1ztYxVtXyTKZZz2C+2 GJ7paIMr0jXXGOvU9MQ/Xg9nhJ1SR2iEgSW7+BpFV+xTZM8CF5f+CsDPLKlBpfHiR1P8 JAbW/dcQeruHDnhYE4ilPEnuX72Vpc7Deop8/Z63CQg0OV40dlPHPvFpwLLDn9bA2QYK s69MIrtAJQE2SmPvPPxTW+NsmjPGFkUfuYWBRvdhN8t4rosVJ/CJjMw+vp/4cVqBTw9U i7WHPAVnY8owgAkEa2jc92xmIjQuaBl9aYkxdFVVzClGtX7FvXllxp1A6VatUfLSypG3 7avQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:subject:to:cc:references:openpgp :autocrypt:message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=JdfPZqVXFSTDaypPNx9VwESn1tLKAY4b6HjsrDtJslo=; b=O+vJfwClLyPuDMWJhXsJVjq4zzmNx8PeexPSDIy4XZ68RvjLRXBKcEtDjiqOVPZneS vm3cfDsvS1PU+onqmysYHSJkVEq6IiZdbGnh+xi9TN226bDHgX4PuVdDebJTPheO1WpP avv6xg4y8gWCb2br8VwrbHN1FHktEy+JYpPF94+hDMjsgamOSrtgkBjXQX9Vohs+iiCv Fo5KClZ0fLyonaQls59gP9mdrfthDpFsx6gcHhz3AApLe65PVo0VHJrcYV8RWKSHJGeb W190KZ2P4GJKX2S3O1NcMofkOGFIXwGAOYigwZDrP548MrgMLy3p0oC/fvclZPMoSQj0 5NNA== X-Gm-Message-State: AJcUukc1F1VfEf6e2eYt/J5oiZKAWhhVgBuFspDalaEJ4wtpOjB88CWN gOiZ07DFjBgsES7j4IFgkygi6+pBOkI= X-Google-Smtp-Source: ALg8bN602D5pVEoG3DAlRGEYrm/4TOwzvErBayiIVY8/up7lkYhlJC5D/qx5EVapLYPO2DD3TikwSw== X-Received: by 2002:adf:be8b:: with SMTP id i11mr26586057wrh.235.1546002805216; Fri, 28 Dec 2018 05:13:25 -0800 (PST) Received: from [88.208.79.100] (halouny.humusoft.cz. [88.208.79.100]) by smtp.gmail.com with ESMTPSA id g188sm23795644wmf.32.2018.12.28.05.13.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Dec 2018 05:13:24 -0800 (PST) From: Michal Meloun X-Google-Original-From: Michal Meloun Reply-To: mmel@freebsd.org Subject: Re: A reliable port cross-build failure (hangup) in my context (amd64->armv7 cross build, with native-tool speedup involved) To: Mark Millard , freebsd-emulation@freebsd.org, FreeBSD Current , ports-list freebsd Cc: freebsd-arm , FreeBSD Toolchain References: <865A13C8-9749-486E-9F79-5EEDDECBE621@yahoo.com> <0154C3AC-D85B-4FCF-BA63-454BC26BC1A2@yahoo.com> Openpgp: preference=signencrypt Autocrypt: addr=mmel@freebsd.org; prefer-encrypt=mutual; keydata= mQENBFYuVRkBCADZiwLCCne3wG9b9k+R2Neo5zVo2bLaZRfNNY/v9kg283i0sb1Da4EdEiNT 15El5UyozhphUIbIR/zrVpxF1TvvFdoCyzx6a68bNY2d9dBrDcNDZC+XnyDdHQoobN87DWT1 mRVkmbg9LHZ/SVUOkGYuWyE+8UYeDAcUizuXwSK5zFWmeTyIoWNa68ifrWLfQe0p4x5jC/AI VURCi17p360vU4fhgwoMvEEhrRBWCr4DYHToFjIt2WdBy3GR1qoO0+Xkd6G+OoBULo+XDfgu L2WdPvh0K69F9/LgHkMmG5Il7SCe62QGpG2vaCgRV7BQhLX+kxlvM+WrdRatWRml4Y/3ABEB AAG0IE1pY2hhbCBNZWxvdW4gPG1tZWxAZnJlZWJzZC5vcmc+iQFABBMBCgAqAhsDBQsJCAcD BRUKCQgLBRYDAgEAAh4BAheAAhkBBQJZjBHDBQkHICOqAAoJEGkesmtexaqqIKMIAJ9xTp1w ge86ns2ZYOac5++mAgpFatohSlxYUR3gwud3Y3Ej0eumavpv/C26N6dsLnspwRenKdLbIPKe 0N8lI7CcDBIJGiFyY3c4H79QjIkYpRgbWFyCM85zEyVJpB+U7BhsgXE2uwVjE9RNhEP0KBoj sp357uqq1B1+VUO4GJ+RjdmYSOcNrjR8tTfy02456qovGjJ4JcJBlhyK6GzBKvnZSoA0s+QP OMn3gd8gdomMLEJdS3kTsfhLh2rQPZa9EmzafIyjXrirWq4+4fVFgd8SiMZyyTM+Kz30ZSUe 6SmfaQTQ/WLRIl5jku2uYQWlrRIKT9xaQzRWtZO9UgtXFRG5AQ0EVi5VGQEIALqgRkfS21D/ OqWE9mXfh2bIjrp9uC8T0MCuimbsrAdLKNNorGu2nE+rebgX8n5nYM377HOnalPGyOuXvCbQ 8MFVRdWOHxenJjXJialNdBsOf2wLva3vSSVsdoPzibWDIcJqhBOQ3EuhsILyWSPvYYKEiy95 mfhrDtuTTOAYVR9aNQBOENztB2TDJyMx/qZmtGroGV3N0Hqde/znHPtQO8RG5/FQGMfHMI5G FMuycr1ceHnLo/ovrqAl4TYV+UHSHJ+FDE9dt9wXHclWbWbC0yNugchZq6rho5Jjfv4a2v7P pyn3HoDinh1lWP7hYA0ZNExGHekLnXWVqO/lzGS6bMEAEQEAAYkBJQQYAQoADwIbDAUCWYwR wwUJByAjqgAKCRBpHrJrXsWqqrsrB/4g4ESK5TLxUxi8pLWcLPyvwtN4Fmf7VsCVefkhakaG rDPmfvfnG+OFwN60Xqoni7GBeakl01xwT4RINfvVfShDy6cHpLS7QL/M8pzfulVX38MkVkOD yGZhwjE+jyT/kZNA1Olaw3N3IefHq3brskQ7G4d9oPep2DDbw7C4Q76uOBjxy34JVB0WOsB6 NyMQB9h6LGljQtdEddyUqwnRZzzHiGvp0hPtdYQHQZlqbj4FV9lTRK7a8Ega+y7MgmeMiztG zeXyjNP02r3PRHCPagwa57bPxH2aAh4Q7UzBBZ0GTMm7DLKNtCP58WDxblrrhZ+7kHqGK8Fs bdeUpDdEYLVd Message-ID: Date: Fri, 28 Dec 2018 14:13:25 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 7CC4F8A45B X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=JlXyZS8Y; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of melounmichal@gmail.com designates 2a00:1450:4864:20::443 as permitted sender) smtp.mailfrom=melounmichal@gmail.com X-Spamd-Result: default: False [-4.27 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_REPLYTO(0.00)[mmel@freebsd.org]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; RCPT_COUNT_FIVE(0.00)[6]; RCVD_COUNT_THREE(0.00)[3]; 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]; NEURAL_HAM_SHORT(-0.76)[-0.760,0]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(-0.51)[ip: (0.82), ipnet: 2a00:1450::/32(-1.76), asn: 15169(-1.51), country: US(-0.08)]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; 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)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; REPLYTO_DOM_NEQ_FROM_DOM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[3.4.4.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]; RCVD_TLS_LAST(0.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2018 13:13:27 -0000 On 24.12.2018 8:28, Mark Millard wrote: > [I built a FreeBSD head -r340288 context and tried ports head > -r484783 and the problem repeated.] > > On 2018-Dec-22, at 12:55, Mark Millard wrote: > >> [I found my E-mail records reporting successful builds using >> qemu-user-static from ports head -r484783 under FreeBSD >> head -r340287.] >> >> On 2018-Dec-22, at 00:10, Mark Millard wrote: >> >>> [I messed up the freebsd-emulation email address the first time I sent >>> this. I also forgot to indicate the qemu-user-static vintage relationship.] >>> >>> I had been reporting intermittent hang-ups for my amd64->{aarch64,armv7} port cross >>> builds in another message sequence. But it turns out that one thing I ran into >>> has hung-up every time, the same way, for amd64->armv7 cross builds: >>> multimedia/gstreamer1-qt@qt5 . So I extract the material here into a separate report >>> with some updated notes. >>> >>> A little context: I had built from ports head -r484783 before under FreeBSD head >>> -r340287 (as I remember the version). Back then it did not have this problem that it >>> now has under FreeBSD head -r341836 . One ports-specific change was to force perl5.28 >>> as the default instead of perl5.26 originally. In fact this is what drives what is >>> being rebuilt for my experiment that caught this. But I doubt the perl version is >>> important to the problem. The context has a Ryzen Threadripper 1950X and has been >>> tested both for FreeBSD under Hyper-V and for the same media native-booted. Both >>> hang-up at the same point as seen via ps or top. The native tools for cross-build >>> speedup were in use. Cross-builds targeting aarch64 did not get this problem but >>> targeting armv7 did. 121 of 129 armv7 ports built before the hang-up for the first >>> armv7 try. >>> >>> ADDED: The qemu-user-static back with head -r340287 before installing the >>> updated ports would likely be different than the -r484783 vintage. So both >>> FreeBSD and qemu-user-static may have changed over the comparison. >> >> CORRECTION to ADDED: Back on 2018-Nov-11 I reported successful cross-builds >> based on qemu-user-static from ports head -484783 --all built under FreeBSD >> head -r340287 . So the use of the perl5.28 as the forced-default and the >> newer FreeBSD head version -r341836 as the context are the differences here. >> >>> The hang-up: >>> >>> In the port rebuilds targeting armv7, multimedia/gstreamer1-qt@qt5 hung-up and timed >>> out. Looking during the wait in later tries shows something much like (from one of the >>> examples): >>> >>> root 33719 0.0 0.0 12920 3528 0 I 11:40 0:00.03 | | `-- sh: poudriere[FBSDFSSDjailArmV7-default][02]: build_pkg (gstreamer1-qt5-1.2.0_14) (sh) >>> root 41551 0.0 0.0 12920 3520 0 I 11:43 0:00.00 | | `-- sh: poudriere[FBSDFSSDjailArmV7-default][02]: build_pkg (gstreamer1-qt5-1.2.0_14) (sh) >>> root 41552 0.0 0.0 10340 1744 0 IJ 11:43 0:00.01 | | `-- /usr/bin/make -C /usr/ports/multimedia/gstreamer1-qt FLAVOR=qt5 build >>> root 41566 0.0 0.0 10236 1796 0 IJ 11:43 0:00.00 | | `-- /bin/sh -e -c (cd /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.build; if ! /usr/bin/env QT_SELE >>> root 41567 0.0 0.0 89976 12896 0 IJ 11:43 0:00.07 | | `-- /usr/local/bin/qemu-arm-static ninja -j28 -v all >>> root 41585 0.0 0.0 102848 25056 0 IJ 11:43 0:00.10 | | |-- /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E cmake_autogen /wrkdirs/usr/ports/multimedia/g >>> root 41586 0.0 0.0 102852 25072 0 IJ 11:43 0:00.11 | | `-- /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E cmake_autogen /wrkdirs/usr/ports/multimedia/g >>> >>> or as top showed it: >>> >>> 41552 root 1 52 0 10M 1744K 0 wait 15 0:00 0.00% /usr/bin/make -C /usr/ports/multimedia/gstreamer1-qt FLAVOR=qt5 build >>> 41566 root 1 52 0 10M 1796K 0 wait 1 0:00 0.00% /bin/sh -e -c (cd /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.build; if ! /usr/bin/env QT_SELECT=qt5 QMAKEMODULES >>> 41567 root 2 52 0 88M 13M 0 select 4 0:00 0.00% /usr/local/bin/qemu-arm-static ninja -j28 -v all >>> 41585 root 2 52 0 100M 24M 0 kqread 8 0:00 0.00% /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E cmake_autogen /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/. >>> 41586 root 2 52 0 100M 24M 0 kqread 22 0:00 0.00% /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E cmake_autogen /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/. >>> >>> So: waiting in kqread trying to run cmake. >>> >>> Unlike some intermittent hang-ups, attaching-then-detaching via gdb does not >>> resume the hung-up processes. Kills of the processes waiting on kqread stop >>> the build. >>> >>> Given the prior ports have been built already, building just >>> multimedia/gstreamer1-qt@qt5 still gets the hang-up at the same point. >>> >>> Building anything that requires multimedia/gstreamer1-qt@qt5 seems to be >>> solidly blocked in my environment. > > > I built a FreeBSD head -r340288 context and tried cross-buiding an > amd64->armv7 ports head -r484783 of my usual ports and the problem > repeated. I also found evidence that originally in the old time frame > I'd disabled part of my originally-intended port builds because of > other problems so multimedia/gstreamer1-qt 's build was not being > tried. > > So the qemu-user-static vintage or content may be what to vary to > narrow down the problem instead of bisecting FreeBSD kernel or world > vintages. clang7 building qemu-user-static or the kernel/world has > been eliminated. > > > (I used -r340288 to match a artifact.ci.freebsd.org build, incorrectly > expecting to bisect via kernel substitutions.) > Mark, this is known problem with qemu-user-static. Emulation of every single interruptible syscall is broken by design (it have signal related races). Theses races cannot be solved without major rewrite of syscall emulation code. Unfortunately, nobody actively works on this, I think. Michal From owner-freebsd-arm@freebsd.org Fri Dec 28 17:21:57 2018 Return-Path: Delivered-To: freebsd-arm@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 4B548141ABC9 for ; Fri, 28 Dec 2018 17:21:57 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1.eu.mailhop.org (outbound1.eu.mailhop.org [52.28.251.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8B27492869 for ; Fri, 28 Dec 2018 17:21:56 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1546017714; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=meWO96AAW6o0q62gc7OoMlSxYBvVPOLd3ow5hD/L4yIjognDKEwIDCCjkmhGLfhLvrabzy7pmVGF9 5y7kdDoJk6Q6rKAc3QmtYRHgOaC0clkzRcNQtPtxD0SxC+hF+BeLD0jCEX1m0dgF5Q+C0RDI/avPXe sDMY4G8wE6LFMRCxX/G8b3zCcpRklrNAcjWdZYMQP1Hg1Bg4kTiG/e2VNsnAaPsSz9oOBJ7a/fl7Yt rEtqBASG1j6x8/16yp/61gNNvdEqj65WQdSGCZV9cm3vvWsX4/Dy6MA48KuN9bMg17g++93G0vpHsG zOLPcOZOf/NBBmZvmgFZha8kpH0TYoA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:to:from:subject:message-id:dkim-signature:from; bh=2eYG8oXPgZXhEshxK9R6FciYFCHPlJf7aVDpBmOVdas=; b=I3wPrI+ETvdPACotELPGBGUYKmiMOPweHre7Q3+RBW7EhKBtGSXveObdhtcD2/D3iTyaVIFXacUEx yn1lhjxzCqrQcMaBYhjZyzlTcF1Q2B1mddWQDNJxbDVL5CW/8LjTX1fjGYdRuOehtlfPMSOiWt3GHy xAhiLY+9D3EfPu1v3hbCTwhmgw1fyzba/rG1O+MQ+6q5AjNuk1UEnCUlRw6p1FQt5O9ZM8unYV6Q6p o5d7btgufHVamdxAobq5bgKaWJ9n1mTQqA4M1kl2Cuz2U57wohUgH9wZQ7O13Cqo45lIxDOHm211xc p1uDNqxIZ/ZZmbrK8x14OtI1w9K5piQ== ARC-Authentication-Results: i=1; outbound3.eu.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:to:from:subject:message-id:from; bh=2eYG8oXPgZXhEshxK9R6FciYFCHPlJf7aVDpBmOVdas=; b=NIzXz+DDwPhgj5h+cm7W+La7JxcuPMVS/YXCqzaysVNzXfCB1XzEbgBQHmZK2VzbE44mH0yT7xwgK yCE0kdmdjz3okJfoNEU4azU9Cs1dhamWUQ8Rqgpkj28Vg60dn7qQw6ANBgOkO4Er5FZ4AaNGEDRTrc 0RU3cARTnPQXdDbZV9JpxVdux38Rd3+8zD7iCTADohz7xXr7YSQEVeXl7co+k+kY9mpsZCizZNVHoB tbAJiDESDiWz/sM8E7WiY5n9GpZgen1rg5/hdSm9lWQSih8p7Rp2MKkxHdpssSzCMAv1uNy940MkFw xhIC1QlZ2v3vq37locuUHn+3JhAD9Ug== X-MHO-RoutePath: aGlwcGll X-MHO-User: 0ea02aee-0ac5-11e9-8a28-a1efd8da9a94 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound3.eu.mailhop.org (Halon) with ESMTPSA id 0ea02aee-0ac5-11e9-8a28-a1efd8da9a94; Fri, 28 Dec 2018 17:21:52 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id wBSHLlH4024091; Fri, 28 Dec 2018 10:21:47 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1546017707.78877.88.camel@freebsd.org> Subject: Re: difference between buildkernel and release.sh for BBB From: Ian Lepore To: SAITOU Toshihide , freebsd-arm@freebsd.org Date: Fri, 28 Dec 2018 10:21:47 -0700 In-Reply-To: <20181228.215424.1441029979323733630.toshi@ruby.ocn.ne.jp> References: <20181228.215424.1441029979323733630.toshi@ruby.ocn.ne.jp> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 8B27492869 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.990,0]; ASN(0.00)[asn:16509, ipnet:52.28.0.0/16, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2018 17:21:57 -0000 On Fri, 2018-12-28 at 21:54 +0900, SAITOU Toshihide wrote: > What is a difference in kernel between these two? > >   make buildkernel TARGET=arm TARGET_ARCH=armv7 KERNCONF=BEAGLEBONE > >   release.sh -c arm/BEAGLEBONE.conf > > The former kernel can't create spigen0 node. > > > I'm using am335x-boneblack.dtb with the following additions. > > &am33xx_pinmux { >                 spi0_pins: pinmux-spi0-pins { >                         pinctrl-single,pins = < >                                 0x150 0x0 >                                 0x154 0x0 >                                 0x158 0x0 >                                 0x15c 0x0 >                         >; >                 }; > }; > > &spi0 { >                 status = "okay"; >                 pinctrl-names = "default"; >                 pinctrl-0 = <&spi0_pins>; >                 spigen0 { >                         compatible = "freebsd,spigen"; >                         reg = <0x0>; >                         status = "okay"; >                 }; > }; > The release.sh builds a GENERIC kernel, which contains the spigen driver; it looks like the BEAGLEBONE config doesn't have it.  Just add spigen_load=yes to your /boot/loader.conf (or kldload spigen after it boots). -- Ian From owner-freebsd-arm@freebsd.org Fri Dec 28 20:22:28 2018 Return-Path: Delivered-To: freebsd-arm@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 9DEA814213A4 for ; Fri, 28 Dec 2018 20:22:28 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-22.consmr.mail.ne1.yahoo.com (sonic303-22.consmr.mail.ne1.yahoo.com [66.163.188.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 B998F69EDE for ; Fri, 28 Dec 2018 20:22:27 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: owz7Eb8VM1nKZuEr0GgzRC_8Xh7cV3NmPnLnIUUqh58HomsqS6LvefDXXWwRvBB 3fDcM6t_u2I_URGoEsuzttcInBx1VudXdi3db27HCySFzrbYuZKn7Jet6krhrIq5qvEjH1BcHp3R CwFkADlEz6lDPLSOjGk22lz47uIB2VeA0DqlrDrc4afscwDyC1v8gcXT5aYfgnCDLKl8_Fj5pmQk YcgQdBkHllcdPwU36yk8j9GhJ1xeu7508eOfOJknWKDhSQ9AfruXmw6XT.O.mFxzh1GugsvTO_xP qaBTM3KhYmYxW1TXXV4pU7oRwvK4MUai1WOWEOCEOE66ROgtU05ZbfBF_0Nn32PwHpvWd_b2qCgG GnGCes_dSG7_TNCsZVmOTbsygk2vYBD8YADyB31Zfo7j8qB..laZlCmvvJwL5WLW5XoGsz5ak_9P vqzDbQw8EXkt9zVfZ3KfnOM06NALZ039gXGSgwrC._L98HIqQlamxqdXl.aDtvaAls5fA1mEGIH9 Z5j13SlsRDJSv4Yo1ZnZgv3UOmdTWwJhxeLl2.tjEGcfgPQPIpgw5W7AIzQ3JmFu051X7NPyeZu6 wV_ZQF9tf3i_kXHR6eDTRMnEMdEK0b1Bw6eJtrWIAHRV2dSKKUlG8M9HV39fmBoeCXJJS2AOH0mO vjrOucv0UcoiqwvhXPvFiNeaQaE3OcqweNJpmjcIfpZg.wyl2nxVb.gf3sWBlIgxgEDvSTohA2IQ kGCYYCxyW.o6.y1hjlqBhe3lW_AwBp3uUWULjVOu7LtJ46jB6_zAqGJvhvVdpueR8x4_PbXtDEGo YAmuUX1_T7qzB7z1uktlwKYwT47MkixO2knoOJZBLGQ4mll.OPwWghAx0wq4dMIhVs0yiZ4SQBBo HSdeG8gtLEI7Bpr_u.DyG05TPfKeznMIZW0R_d8W.ynbNsIR3iFdTRMx_K1wLnhk2J2yDmwVs9XY gy3p3mWHbr_3e6VQ7l4ic3bnmlHVKun8ZF87U6xnp7wp8kS825Qo6i044kI_PAFIpPaEOZAgMNW1 VFvhAhv5gBliwan.34rCeLTHwVEPEnYZubFBFF.yTmF2bhZ7uV.nFt_MpSFgyH5eG6jCM Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.ne1.yahoo.com with HTTP; Fri, 28 Dec 2018 20:22:20 +0000 Received: from c-67-170-167-181.hsd1.or.comcast.net (EHLO [192.168.1.109]) ([67.170.167.181]) by smtp429.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID b8b32a4346149f25d8f944b89459e9c7; Fri, 28 Dec 2018 20:12:08 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: A reliable port cross-build failure (hangup) in my context (amd64->armv7 cross build, with native-tool speedup involved) From: Mark Millard In-Reply-To: <13f5e4dd-33fb-2170-e31a-1b5d5f155869@freebsd.org> Date: Fri, 28 Dec 2018 12:12:06 -0800 Cc: freebsd-emulation@freebsd.org, FreeBSD Current , ports-list freebsd , freebsd-arm , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: References: <865A13C8-9749-486E-9F79-5EEDDECBE621@yahoo.com> <0154C3AC-D85B-4FCF-BA63-454BC26BC1A2@yahoo.com> <13f5e4dd-33fb-2170-e31a-1b5d5f155869@freebsd.org> To: mmel@freebsd.org X-Mailer: Apple Mail (2.3445.102.3) X-Rspamd-Queue-Id: B998F69EDE X-Spamd-Bar: / X-Spamd-Result: default: False [0.34 / 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]; RCPT_COUNT_FIVE(0.00)[6]; RCVD_COUNT_THREE(0.00)[3]; 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)[]; NEURAL_HAM_MEDIUM(-0.18)[-0.177,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.77)[0.769,0]; NEURAL_HAM_LONG(-0.79)[-0.786,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(1.04)[ip: (3.21), ipnet: 66.163.184.0/21(1.16), asn: 36646(0.93), country: US(-0.08)]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[148.188.163.66.list.dnswl.org : 127.0.5.0]; RWL_MAILSPIKE_POSSIBLE(0.00)[148.188.163.66.rep.mailspike.net : 127.0.0.17] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2018 20:22:28 -0000 On 2018-Dec-28, at 05:13, Michal Meloun = wrote: > Mark, > this is known problem with qemu-user-static. > Emulation of every single interruptible syscall is broken by design = (it > have signal related races). Theses races cannot be solved without = major > rewrite of syscall emulation code. > Unfortunately, nobody actively works on this, I think. >=20 Thanks for the note setting some expectations. On the evidence that I have I expect that more is going on than that: A) The hang-up always happens and always in the same place. So it would appear that no race is involved. B) (A) is true even for varying the number of builders in parallel (so other builds also happening) and the number of jobs allowed per builder. It also fails for only one builder allowed only one process. (I get traces from that last kind of context.) C) The problem started on the package-building servers for armv7 and armv6 without qemu-user-static having an update (FreeBSD and cmake had updates, for example). D) The problem is only observed for targeting armv7 and armv6 as far as I can tell. I've never seen it for aarch64, neither my own builds nor when I looked at the package-building server history. At least that is what got me started. (I've since learned that qemu-user-static uses fork in place of a requested vfork.) My ktrace/kdump experiment yesterday showed something odd for the kevent that hangs in cmake: 93172 qemu-arm-static CALL = kevent(0x3,0x7ffffffe7d40,0x2,0x7ffffffd7d40,0x400,0) 93172 qemu-arm-static STRU struct kevent[] =3D { { ident=3D6, = filter=3DEVFILT_READ, flags=3D0x1, fflags=3D0, data=3D0, = udata=3D0x0 } { ident=3D0x0, filter=3D, flags=3D0, = fflags=3D0x8, data=3D0x1ffff, udata=3D0x0 } } Note the 0x2 argument to kevent and the apparently-odd 2nd entry in the = struct kevent[]. The kevent use is from cmake. So far I've not identified a signal being delivered at a time that would = seem to me to be likely to contribute. (But this is not familiar code so my = judgment is likely not the best.) Note: I normally run FreeBSD using a non-debug kernel, even when using head. (The kernel does have symbols.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Fri Dec 28 21:02:10 2018 Return-Path: Delivered-To: freebsd-arm@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 85CA114227A8 for ; Fri, 28 Dec 2018 21:02:10 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-11.consmr.mail.ne1.yahoo.com (sonic313-11.consmr.mail.ne1.yahoo.com [66.163.185.34]) (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 E02AB6B8F0 for ; Fri, 28 Dec 2018 21:02:09 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: YunzRiIVM1nr0SgP6ANyrg_P3tUJP97UGxFV7wSfjrRDLwErCsaD4RxPSSDQbdU 6cC7_HkfFGYdehkTiZIDQBol57GfbEm1yItYFX59uNGJxnj8aAuffMN1rJ5UuMU_Bd2Fxg23FCvk cmxUq0axAOB0Pnd_kHVyl8SfgnAVLf9fWBxwkboxJx0hQMl0MjpyQOMcq8wgg1dAJiecEhwkqGnK V_yH5jAK4oJJBLFIOaD1.c3x8jm4iW5xRtfKrpEMX9GJsdMl8b5pPr3zrdhpePVHsawhcU9Q496K zwuSxwv8TQJ37HcOjpZhAbxs98xi.zGvXq.XrTeGcq.w0KnrMGAKTaNzZuioWaQ.1j0d2wTiYrq1 u35Y1_8Y4CZBUtpz.LJdQvAPQuMwIkpHxLtci1AStK7DGDDhK8__A_J466ieGxb3ZNZZ9s23O60m EKqqdrW1t0JPu_nA9E36CRkmd288VY97nQXU9fkbWzoX2xg.RkTy.gD.aYy3lSeYEA1Y_vLwRWnl pdSQXlo6dIP0enHrEW_kgJuZ1jMd42EbRqjThIbXk4nVf3XH8jxDPbu1IDvu6bd4LNoBdoz5in_s .a55P9.BF4hN9I7isqA02OBzaWhVHi1CFZ6OXHPeuN79LUzUGZC6ZCwUYk8VWiqJ.hYTGsUoFhqY QJpH2UvufZFSlCfN0ydBOYv.FudEXRQ3qhroi_1OEbZkDJsl01XPmi.1FJnYY4RSChyVv2htGp9. SXF044bDvePT3Vyz_0RQ_AwqmOM1lU.8fOHrX7IS2vfjdHEWxUwXBAzQcKKbOgBi0lWtMspBW7sI FUIFeYC408dKdpSa7PvIawV0JwUs2riLa0WCJhGc0qm36qk2WxYNma.ZttYzouJXem7uilU5DD8A 4b6BFBlcLhoJzxkVqmf.3RJhOV0DwIFWuE2xVkG6BQ4c_x.41fom3SyDSMSnpMc3Y5f04cF5YDxt GGQzECvUDA56P2tAnvRQ4NQhnn92czs95vA8Q1g9LA6LWAK.my0n.u3vhXt3U9Jp4gOxFwauhtwm nThaG3qNsqsWeRo2r9jbNURbkdkSLM118o3m_vjykmOv4J5R9NZQgTtQkomqgboA7R4K.mom9AL9 A8P8- Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.ne1.yahoo.com with HTTP; Fri, 28 Dec 2018 21:02:08 +0000 Received: from c-67-170-167-181.hsd1.or.comcast.net (EHLO [192.168.1.109]) ([67.170.167.181]) by smtp423.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 1c1c880d52b5fc8a1a4126d5be9859e4; Fri, 28 Dec 2018 21:02:08 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: A reliable port cross-build failure (hangup) in my context (amd64->armv7 cross build, with native-tool speedup involved) From: Mark Millard In-Reply-To: <3946C94A-FCA6-49FE-ADDB-B042BBE50913@yahoo.com> Date: Fri, 28 Dec 2018 13:02:06 -0800 Cc: freebsd-arm , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <050F532F-85A8-4FF8-A7B0-178598B06BE1@yahoo.com> References: <865A13C8-9749-486E-9F79-5EEDDECBE621@yahoo.com> <0154C3AC-D85B-4FCF-BA63-454BC26BC1A2@yahoo.com> <5C3F09FE-EA50-452D-98EE-364B7BF3ECD0@yahoo.com> <3946C94A-FCA6-49FE-ADDB-B042BBE50913@yahoo.com> To: freebsd-emulation@freebsd.org, FreeBSD Current , ports-list freebsd X-Mailer: Apple Mail (2.3445.102.3) X-Rspamd-Queue-Id: E02AB6B8F0 X-Spamd-Bar: / X-Spamd-Result: default: False [-0.01 / 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]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[3]; 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: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.25)[-0.254,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.60)[0.595,0]; NEURAL_HAM_LONG(-0.79)[-0.787,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.95)[ip: (2.74), ipnet: 66.163.184.0/21(1.16), asn: 36646(0.93), country: US(-0.08)]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[34.185.163.66.list.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2018 21:02:10 -0000 [Using ktrace/kdump shows an apperent oddity in the kevent use that hang-up in cmake, not that I know it causes the hang-up.] On 2018-Dec-28, at 00:16, Mark Millard wrote: > [The historical notes are removed and replaced by partial trace > information from example hang-ups, not that I've figured out > what contributes yet.] >=20 > I ran into the following while trying to get evidence > about the hang-up for an amd64->armv7 cross-build of > multimedia/gstreamer1-qt@qt5 . >=20 > The following from trying to get evidence for the hang-up > via a manual run of "make multimedia/gstreamer1-qt FLAVOR=3Dqt5=E2=80=9D= > in a poudriere bulk -i=E2=80=99s interactive mode for the context > that has the hang-up in normal poudriere-devel runs. >=20 >=20 > =46rom top after the hang-up (to identify some context): >=20 > 14528 root 2 52 0 100M 24M 0 kqread 11 0:00 = 0.00% /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E = cmake_autogen /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/. > 14527 root 2 52 0 88M 13M 0 select 22 0:00 = 0.00% /usr/local/bin/qemu-arm-static ninja -j1 -v all >=20 > from ps -auxd as well (to identify more context): >=20 > root 10114 0.0 0.0 10328 1756 1 I+J 13:47 0:00.01 = | `-- make FLAVOR=3Dqt5 > root 14526 0.0 0.0 10204 1792 1 I+J 13:50 0:00.00 = | `-- /bin/sh -e -c (cd = /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.build; if ! = /usr/bin/env QT_SELE > root 14527 0.0 0.0 90304 13084 1 I+J 13:50 0:00.09 = | `-- /usr/local/bin/qemu-arm-static ninja -j1 -v = all > root 14528 0.0 0.0 102876 25060 1 IJ 13:50 0:00.12 = | `-- /usr/local/bin/qemu-arm-static = /usr/local/bin/cmake -E cmake_autogen /wrkdirs/usr/ports/multimedia/g >=20 > I had made a qemu-user-static that enabled do_strace when > it is used to run cmake or ninja. >=20 > The only do_strace lines from qemu-arm-static running cmake > or ninja mentioning process 14528 are included in the sequence: >=20 > (Before the below was a long list of "14527 fstatat=E2=80=9D lines. > I=E2=80=99ll note that "'Unknown syscall 545=E2=80=9D is from ppoll = use.) >=20 > 82400 sigprocmask(1,-1610620016,-191968524,-186261416,0,24) =3D 0 > 82400 sigaction(2,-1610620040,-191968596,-186261584,210460,0) =3D 0 > 82400 sigaction(15,-1610620040,-191968572,-186261584,210460,0) =3D 0 > 82400 sigaction(1,-1610620040,-191968548,-186261584,210460,0) =3D 0 > 82400 gettimeofday(-1610619984,0,4,-186261584,-1610619440,-1610619528) = =3D 0 > 82400 gettimeofday(-1610619984,0,4,359949,1545969996,0) =3D 0 > 82400 gettimeofday(-1610620120,0,4,2,-184666112,-1610619520) =3D 0 > 82400 fstatat(-100,"elements/gstqtvideosink/CMakeFiles", 0x9fffe200, = 0) =3D 0 > 82400 fstatat(-100,"elements/gstqtvideosink/gstqt5videosink_autogen", = 0x9fffe200, 0) =3D 0 > 82400 pipe2(-1610620176,0,-1610620108,0,-1610620120,167084) =3D 0 > 82400 fcntl(5,1,-1610620108,-185863932,-192200556,-1610620228) =3D 0 > 82400 fcntl(5,2,1,-185863932,-192200556,-1610620228) =3D 0 > 82400 vfork(0,66450,-186876196,-1610620184,-1610620240,0) =3D 82401 > 82400 close(6) =3D 0 > =3D 0 > 82400 Unknown syscall 545 > 82401 setpgid(0,0,-186876196,-1610620184,-1610620240,0) =3D 0 > 82401 sigprocmask(3,-191586912,0,-1610620184,-1610620240,0) =3D 0 > 82401 close(5) =3D 0 > 82401 open("/dev/null",0,0) =3D 5 > 82401 dup2(5,0,0,-1610620184,-1610620240,0) =3D 0 > 82401 close(5) =3D 0 > 82401 fcntl(0,2,0,-1610620184,-1610620240,0) =3D 0 > 82401 dup2(6,1,0,-1610620184,-1610620240,0) =3D 1 > 82401 fcntl(1,2,0,-1610620184,-1610620240,0) =3D 0 > 82401 dup2(6,2,0,-1610620184,-1610620240,0)82400 = sigpending(-1610620072,1,0,-191968524,0,0) =3D 0 >=20 > The vfork then close(6) sequence for 82400 vs. the later > use of 6 in dup2 in 82401 may be rather odd. But it looks > like qemu-*-static uses do_freebsd_fork to implement > do_freebsd_vfork, despite reporting vfork before > calling do_freebsd_vfork. (Does the close(6) appear to > indicate a race for native operation of ninja for the > period when the address space is shared?) >=20 > Ninja has Subprocess::Start code that has: >=20 > #ifdef POSIX_SPAWN_USEVFORK > flags |=3D POSIX_SPAWN_USEVFORK; > #endif >=20 >=20 > if (posix_spawnattr_setflags(&attr, flags) !=3D 0) > Fatal("posix_spawnattr_setflags: %s", strerror(errno)); >=20 > const char* spawned_args[] =3D { "/bin/sh", "-c", command.c_str(), = NULL }; > if (posix_spawn(&pid_, "/bin/sh", &action, &attr, > const_cast(spawned_args), environ) !=3D 0) > Fatal("posix_spawn: %s", strerror(errno)); >=20 > that is in use here. I think that this explains the vfork use. >=20 >=20 > It turns out that putting the hung-up build in the background > and then killing 82401 with the likes of kill -6 leads to more > output that had apparently been buffered. It shows the use of > the (amd64 native) /bin/sh that in turn leads to > /usr/local/bin/cmake via qemu-arm-static. /bin/sh, being > native, gets no do_strace output from qemu-arm-static. >=20 > 82400 sigpending(-1610620072,1,0,-191968524,0,0) =3D 0 > 82400 read(5,0x9fffd368,4096) =3D 58 > 82400 Unknown syscall 545 > 82400 sigpending(-1610620072,1,0,-191968524,0,0) =3D 0 > 82400 read(5,0x9fffd368,4096) =3D 0 > 82400 close(5) =3D 0 > 82400 wait4(82401,-1610620004,0,0,-191968640,0) =3D 82401 > 82400 mmap(0,86016,3,201330690,-1,-1610620169) =3D 0xf4777000 > 82400 gettimeofday(-1610620224,0,4,-1610619944,31,16777216) =3D 0 > 82400 write(1,0xf4950000,283)[1/129] cd = /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.build/elements/gstqt= videosink && /usr/local/bin/cmake -E cmake_autogen = /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.build/elements/gstqt= videosink/CMakeFiles/gstqt5videosink_autogen.dir/AutogenInfo.cmake Debug > =3D 283 > 82400 write(1,0xf4950000,137)FAILED: = elements/gstqtvideosink/CMakeFiles/gstqt5videosink_autogen = elements/gstqtvideosink/gstqt5videosink_autogen/mocs_compilation.cpp=20 > =3D 137 > 82400 write(1,0xf4950000,275)cd = /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.build/elements/gstqt= videosink && /usr/local/bin/cmake -E cmake_autogen = /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.build/elements/gstqt= videosink/CMakeFiles/gstqt5videosink_autogen.dir/AutogenInfo.cmake Debug > =3D 275 > 82400 write(1,0xf4950000,5) =3D 2 > =3D 5 >=20 > (Note that some 82400 writes are reporting 82401 information:) >=20 > 82400 write(1,0xf4950000,49)82401 = fcntl(2,2,0,-1610620184,-1610620240,0) =3D 0 > =3D 49 > 82400 write(1,0xf4950000,19)82401 close(6) =3D 0 > =3D 19 > 82400 write(1,0xf4950000,401)82401 = execve("/bin/sh",{"/bin/sh","-c","cd = /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.build/elements/gstqt= videosink && /usr/local/bin/cmake -E cmake_autogen = /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.build/elements/gstqt= videosink/CMakeFiles/gstqt5videosink_autogen.dir/AutogenInfo.cmake = Debug",NULL})82401 __sysctl({ 0 3 }, 2, 0x9fffda80, 0x9fffdf64, = 0xf5002097, 0x0000000c) =3D 0 > =3D 401 >=20 > (The /bin/sh activity is not logged: /bin/sh is native amd64 code = here. The > below is from the later /usr/local/bin/cmake via qemu-arm-static. >=20 > . . . (much omitted) . . . >=20 > 82400 write(1,0xf4950000,60)82401 = mmap(0,28672,3,201330690,-1,-1610621989) =3D 0xf41a0000 > =3D 60 > 82400 write(1,0xf4950000,74)82401 = clock_gettime(4,-1610621832,4,-199622492,-199622492,-199622656) =3D 0 > =3D 74 > 82400 write(1,0xf4950000,62)82401 = kqueue(-199622656,0,53102,0,-199622656,-1610621444) =3D 3 > =3D 62 > 82400 write(1,0xf4950000,81)82401 ioctl(3, 0x20006601 { IO = GRP:0x66('f') CMD:1 LEN:0 }, 0x0000cf6e, ...) =3D 0 > =3D 81 >=20 > . . . (some omitted) . . . >=20 > (Then there is a fairly long sequence of access's and then a sequence = of > fstatat's just before:) >=20 >=20 > 82400 write(1,0xf4950000,32)82401 write(9,0xf4e1a945,1) =3D 1 > =3D 32 > 82400 write(1,0xf4950000,61)82401 = clock_gettime(4,-1610622624,4,100863,1,-199483392) =3D 0 > =3D 61 > 82400 write(1,0xf4950000,106)82401 = kevent(3,-1610688200,2,-1610688200,1024,0)qemu: uncaught target signal 6 = (Abort trap) - core dumped > =3D 106 ktrace/kdump shows an oddity for the kevent that hangs-up in cmake (from a different run so a different process ID): 93172 qemu-arm-static CALL = kevent(0x3,0x7ffffffe7d40,0x2,0x7ffffffd7d40,0x400,0) 93172 qemu-arm-static STRU struct kevent[] =3D { { ident=3D6, = filter=3DEVFILT_READ, flags=3D0x1, fflags=3D0, data=3D0, = udata=3D0x0 } { ident=3D0x0, filter=3D, flags=3D0, = fflags=3D0x8, data=3D0x1ffff, udata=3D0x0 } } Note the 0x2 kevent argument and the apparently-odd 2nd entry in the = struct kevent[] . > 82400 write(1,0xf4950000,41)ninja: build stopped: subcommand failed. > =3D 41 >=20 > So it was hung at the kevent until the kill -6 . >=20 >=20 > Via another experiment ninja was at the time waiting > in ppoll: >=20 > Reading symbols from ninja...done. > [New LWP 73023] > Core was generated by `ninja'. > Program terminated with signal SIGABRT, Aborted. > #0 0xf4e5e0dc in _ppoll () from /lib/libc.so.7 > (gdb) bt > #0 0xf4e5e0dc in _ppoll () from /lib/libc.so.7 > #1 0x00033bf0 in SubprocessSet::DoWork (this=3D) at = src/subprocess-posix.cc:237 > Backtrace stopped: previous frame inner to this frame (corrupt stack?) >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Sat Dec 29 03:07:05 2018 Return-Path: Delivered-To: freebsd-arm@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 0C253142F0C1 for ; Sat, 29 Dec 2018 03:07:05 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-22.consmr.mail.ne1.yahoo.com (sonic309-22.consmr.mail.ne1.yahoo.com [66.163.184.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 DFA0E81FC9 for ; Sat, 29 Dec 2018 03:07:03 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: vN.8rycVM1lUUsYKTXHjGDtKvOmNC2LkQhdaty7awDKGTP80OorGcqTMrWBY_sL NupIbID1wcJueTm2fbWLHg6tvKxWawp5VPIl0qo0uO8.ar.q5b3hHj.4zzgRqU_vEAeWvalsyDPD h1q._kI4A5GL2d2IkZ7DDjPonIed3S5AlaPCthzDaYaJcWziZrSNKuBYm9qA4U9KMXS_hBVUpNBo OMRlmi5ULjFJWnRwanZNkYR33GeY6ocKQNo5hatOr1xkiwC9o3YeXKDUraQuYd0ts.w4uNYFudJg S0uopk1.LiUKnRd9bNLBPnd47kgdU5kR6Pwv.GUX7tyBmqQRGzbXyxpRCISc0FuzqU2QzQC1rFnU DPfAzom.c4I1aUk.7lYp3OXxUl6iBU1hviPtzimqZGb5aqcRIGKZkxy_TwyjtlRVYX3s1_L1KGo5 SGeMEFmwNhNJ8dvBJT3O78rFG6.FZVw7yj4u3GGqPbEBJLGehRmVc9aVtVWMtrubzB1glWQoK5zy r7CXWqTuE48AVoZ1SKv89dvvEuLOdMIrHb1q1f8Gouc46IhYTzT.vXbVBvNzQSAqUVeTEr3ED9o1 5wh3HvUyDIWJr1DXeCjkKy8WdkB3wqUBsSzZvyTQ_U9PU3vBl1rb0iepamJYoXjRiSIwIj3yx9cB tFNuUhVLzaLlJTI2AUCRTazGXl1m5yJhZV4sz_76mRDcq6huW53Vs7K1LUvd3mkL3_WM2AlynUzl 5keu07fKhTLNmEIhXHF.SrhHHwu_gREQnsxoRPSH_hP_BMIWNTaBd4eqyjVabV4TG3IIJqSpeLRc IqciDRjr7apAhLB7EXP9bEpju3FMmvl3ohA.gCFLEZtv3zzIA2WmY2tpnVa_q9DZU__j314HGdC7 TiOa4A9dw7qgptiP13IXKhQ3jwFAfyfwLCWDHM5mJhKhTyRLu4XqViWJISlL0ZgjnjLgTowRTpDv JkvPzIqzOiiLgfsw8wGlPoo5G.50JwyaihOkQYbU6ibwfKtOkZ0Q3SWtZnzt8io3CuhckzI0hBms P7jaZKmuioB7FrRydMP0vYs7TETghgZTDvBwy0dOco6K1SyQawkWrV3oNnHWSkxMDi4TC5aWbUL6 Z Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.ne1.yahoo.com with HTTP; Sat, 29 Dec 2018 03:06:56 +0000 Received: from c-67-170-167-181.hsd1.or.comcast.net (EHLO [192.168.1.109]) ([67.170.167.181]) by smtp420.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID a30b0319a9e92381b4c3a8625c6cf7d5; Sat, 29 Dec 2018 02:56:45 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: A reliable port cross-build failure (hangup) in my context (amd64->armv7 cross build, with native-tool speedup involved) From: Mark Millard In-Reply-To: Date: Fri, 28 Dec 2018 18:56:43 -0800 Cc: freebsd-emulation@freebsd.org, FreeBSD Current , ports-list freebsd , freebsd-arm , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <2E3F6196-4652-40D2-937F-8860B6005A35@yahoo.com> References: <865A13C8-9749-486E-9F79-5EEDDECBE621@yahoo.com> <0154C3AC-D85B-4FCF-BA63-454BC26BC1A2@yahoo.com> <13f5e4dd-33fb-2170-e31a-1b5d5f155869@freebsd.org> To: mmel@freebsd.org X-Mailer: Apple Mail (2.3445.102.3) X-Rspamd-Queue-Id: DFA0E81FC9 X-Spamd-Bar: + X-Spamd-Result: default: False [1.14 / 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]; RCPT_COUNT_FIVE(0.00)[6]; RCVD_COUNT_THREE(0.00)[3]; 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: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.113,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.93)[0.934,0]; NEURAL_HAM_LONG(-0.25)[-0.251,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(1.08)[ip: (3.39), ipnet: 66.163.184.0/21(1.15), asn: 36646(0.92), country: US(-0.08)]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[148.184.163.66.list.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Dec 2018 03:07:05 -0000 On 2018-Dec-28, at 12:12, Mark Millard wrote: > On 2018-Dec-28, at 05:13, Michal Meloun = wrote: >=20 >> Mark, >> this is known problem with qemu-user-static. >> Emulation of every single interruptible syscall is broken by design = (it >> have signal related races). Theses races cannot be solved without = major >> rewrite of syscall emulation code. >> Unfortunately, nobody actively works on this, I think. >>=20 >=20 > Thanks for the note setting some expectations. >=20 > On the evidence that I have I expect that more is going on than that: >=20 > A) The hang-up always happens and always in the same place. So > it would appear that no race is involved. >=20 > B) (A) is true even for varying the number of builders in parallel > (so other builds also happening) and the number of jobs allowed per > builder. It also fails for only one builder allowed only one process. > (I get traces from that last kind of context.) >=20 > C) The problem started on the package-building servers for armv7 > and armv6 without qemu-user-static having an update (FreeBSD and > cmake had updates, for example). >=20 > D) The problem is only observed for targeting armv7 and armv6 as > far as I can tell. I've never seen it for aarch64, neither my > own builds nor when I looked at the package-building server > history. >=20 > At least that is what got me started. (I've since learned that > qemu-user-static uses fork in place of a requested vfork.) >=20 > My ktrace/kdump experiment yesterday showed something odd for the > kevent that hangs in cmake: >=20 > 93172 qemu-arm-static CALL = kevent(0x3,0x7ffffffe7d40,0x2,0x7ffffffd7d40,0x400,0) > 93172 qemu-arm-static STRU struct kevent[] =3D { { ident=3D6, = filter=3DEVFILT_READ, flags=3D0x1, fflags=3D0, data=3D0, = udata=3D0x0 } > { ident=3D0x0, filter=3D, flags=3D0, = fflags=3D0x8, data=3D0x1ffff, udata=3D0x0 } } >=20 > Note the 0x2 argument to kevent and the apparently-odd 2nd entry in = the struct > kevent[]. The kevent use is from cmake. >=20 > So far I've not identified a signal being delivered at a time that = would seem > to me to be likely to contribute. (But this is not familiar code so my = judgment > is likely not the best.) >=20 > Note: I normally run FreeBSD using a non-debug kernel, even when using > head. (The kernel does have symbols.) The detail of the signal usage involved leading up to the hang-up, starting from just before the "press return" for the "make FLAVOR=3Dqt5" command that I had entered: The only "Interrupted system call" prior to my killing the hung cmake process was (kdump -H -r -S output): 93172 100717 qemu-arm-static CALL = execve[59](0x10392,0x8605051a0,0x860cf5400) 93172 101706 qemu-arm-static RET nanosleep[240] -1 errno 4 = Interrupted system call 93172 100717 qemu-arm-static NAMI "/bin/sh" 93172 100717 sh RET execve[59] JUSTRETURN 93172 100717 sh CALL readlink[58](0x207a65,0x7fffffffccc0,0x400) This is where ninja (via qemu-arm-static) execve's the amd64-native = /bin/sh (to in turn later run cmake via qemu-arm-static). (This was after the fork = [for the requested vfork].) So it is for the close-down of the thread that was in nanosleep. There were no PSIG's and no sigreturn's prior to the kill according to = the kdump output. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Sat Dec 29 10:34:16 2018 Return-Path: Delivered-To: freebsd-arm@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 6EACC143B9DB for ; Sat, 29 Dec 2018 10:34:16 +0000 (UTC) (envelope-from toshi@ruby.ocn.ne.jp) Received: from mfdf018.ocn.ad.jp (mfdf018.ocn.ad.jp [153.128.50.74]) by mx1.freebsd.org (Postfix) with ESMTP id 61E978F821; Sat, 29 Dec 2018 10:34:15 +0000 (UTC) (envelope-from toshi@ruby.ocn.ne.jp) Received: from mogw1929.ocn.ad.jp (mogw1929.ocn.ad.jp [153.138.215.95]) by mfdf018.ocn.ad.jp (Postfix) with ESMTP id 8BC5CB8BF82; Sat, 29 Dec 2018 19:34:06 +0900 (JST) Received: from mf-smf-unw007c2 (mf-smf-unw007c2.ocn.ad.jp [153.138.219.100]) by mogw1929.ocn.ad.jp (Postfix) with ESMTP id 3E2EB203B5; Sat, 29 Dec 2018 19:33:55 +0900 (JST) Received: from ocn-vc-mts-202c1.ocn.ad.jp ([153.138.219.215]) by mf-smf-unw007c2 with ESMTP id dBqrgdBD1QXHCdBwJgYmbs; Sat, 29 Dec 2018 19:33:55 +0900 Received: from smtp.ocn.ne.jp ([153.149.227.134]) by ocn-vc-mts-202c1.ocn.ad.jp with ESMTP id dBwJgnhpPVBnydBwJgPKNn; Sat, 29 Dec 2018 19:33:55 +0900 Received: from localhost (p571097-ipngn200409sizuokaden.shizuoka.ocn.ne.jp [180.33.36.97]) by smtp.ocn.ne.jp (Postfix) with ESMTPA; Sat, 29 Dec 2018 19:33:55 +0900 (JST) Date: Sat, 29 Dec 2018 19:33:48 +0900 (JST) Message-Id: <20181229.193348.553493805484498183.toshi@ruby.ocn.ne.jp> To: ian@freebsd.org Cc: freebsd-arm@freebsd.org Subject: Re: difference between buildkernel and release.sh for BBB From: SAITOU Toshihide In-Reply-To: <1546017707.78877.88.camel@freebsd.org> References: <20181228.215424.1441029979323733630.toshi@ruby.ocn.ne.jp> <1546017707.78877.88.camel@freebsd.org> X-GPG-fingerprint: 34B3 0B6A 8520 F5B0 EBC7 69F6 C055 9F8A 0D49 F8FC X-Mailer: Mew version 6.8 on Emacs 26.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 61E978F821 X-Spamd-Bar: ++++ Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of toshi@ruby.ocn.ne.jp designates 153.128.50.74 as permitted sender) smtp.mailfrom=toshi@ruby.ocn.ne.jp X-Spamd-Result: default: False [4.98 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; URL_IN_SUBJECT(0.40)[release.sh]; RCVD_COUNT_FIVE(0.00)[6]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:153.128.50.0/24]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[ocn.ne.jp]; NEURAL_SPAM_MEDIUM(0.99)[0.991,0]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.57)[0.573,0]; MX_GOOD(-0.01)[cached: mfgw1.ocn.ad.jp]; RCPT_COUNT_TWO(0.00)[2]; MID_CONTAINS_FROM(1.00)[]; NEURAL_SPAM_LONG(0.99)[0.988,0]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:4713, ipnet:153.128.0.0/11, country:JP]; IP_SCORE(0.74)[ip: (2.23), ipnet: 153.128.0.0/11(2.09), asn: 4713(-0.53), country: JP(-0.09)] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Dec 2018 10:34:16 -0000 On Fri, 28 Dec 2018 10:21:47 -0700, Ian Lepore wrote:= > On Fri, 2018-12-28 at 21:54 +0900, SAITOU Toshihide wrote: >> What is a difference in kernel between these two? >> = >> =A0 make buildkernel TARGET=3Darm TARGET_ARCH=3Darmv7 KERNCONF=3DBEA= GLEBONE >> = >> =A0 release.sh -c arm/BEAGLEBONE.conf >> = >> The former kernel can't create spigen0 node. >> = >> = >> I'm using am335x-boneblack.dtb with the following additions. >> = >> &am33xx_pinmux { >> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0spi0_pins: pinmux-sp= i0-pins { >> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0pinctrl-single,pins =3D < >> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A00x150 0x0 >> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A00x154 0x0 >> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A00x158 0x0 >> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A00x15c 0x0 >> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0>; >> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0}; >> }; >> = >> &spi0 { >> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0status =3D "okay"; >> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0pinctrl-names =3D "d= efault"; >> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0pinctrl-0 =3D <&spi0= _pins>; >> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0spigen0 { >> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0compatible =3D "freebsd,spigen"; >> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0reg =3D <0x0>; >> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0status =3D "okay"; >> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0}; >> }; >> = > = > The release.sh builds a GENERIC kernel, which contains the spigen > driver; it looks like the BEAGLEBONE config doesn't have it. =A0Just = add > spigen_load=3Dyes to your /boot/loader.conf (or kldload spigen after = it > boots). Oh, I see. By kldloading spigen, /dev/spigen0.0 is generated. -- SAITOU Toshihide From owner-freebsd-arm@freebsd.org Sat Dec 29 15:32:32 2018 Return-Path: Delivered-To: freebsd-arm@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 264AC14235F7 for ; Sat, 29 Dec 2018 15:32:32 +0000 (UTC) (envelope-from qroxana@mail.ru) Received: from smtp61.i.mail.ru (smtp61.i.mail.ru [217.69.128.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D17C172DFC for ; Sat, 29 Dec 2018 15:32:30 +0000 (UTC) (envelope-from qroxana@mail.ru) Received: by smtp61.i.mail.ru with esmtpa (envelope-from ) id 1gdGb5-00044b-2x for freebsd-arm@freebsd.org; Sat, 29 Dec 2018 18:32:21 +0300 Date: Sat, 29 Dec 2018 15:31:56 +0000 From: qroxana To: freebsd-arm@freebsd.org Subject: Clang 7.0.1 crashes on AArch64 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-Id: X-77F55803: 689590B63E0A4B015A78504BD2AC2941BBB835E816AB87239D30CED12748B690CC3EA5B4958070651B9C102112A0FF06 X-7FA49CB5: 0D63561A33F958A59492F0E6EFBB427230B6BEF1195C2208CC5F36460A51056C8941B15DA834481FA18204E546F3947CC6602A96AF88C695F6B57BC7E64490618DEB871D839B7333395957E7521B51C2545D4CF71C94A83E9FA2833FD35BB23D27C277FBC8AE2E8B9FC99A4BA45EE8B4A471835C12D1D977C4224003CC8364767815B9869FA544D8D32BA5DBAC0009BE9E8FC8737B5C224958580692B2F72C613AA81AA40904B5D9CF19DD082D7633A0E7DDDDC251EA7DABD81D268191BDAD3D78DA827A17800CE7BC3EBD8B08A2D12DCD04E86FAF290E2D40A5AABA2AD3711975ECD9A6C639B01B78DA827A17800CE703BD12CA7E55A94F998C087C5F8EDFAC75ECD9A6C639B01B4E70A05D1297E1BBC6867C52282FAC85084A3168D6E26DF927F269C8F02392CD5571747095F342E88FB05168BE4CE3AF X-Mailru-Sender: A8F90F45CB8D80DBFE43EF47816AFB39126DA90CE49E821B214D48E692C309678B8F821DF40F5C0D9BBFFF7D229A147FFDD1F2F6C9B53D730D187FEF3E0D57C1D08349341B303650BDF7E317B72FD726EC982BF62A43B37A04568DD965327F405FEEDEB644C299C0ED14614B50AE0675 X-Mras: OK X-Rspamd-Queue-Id: D17C172DFC X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.78 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[mail.ru:s=mail2]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:217.69.128.0/20]; FREEMAIL_FROM(0.00)[mail.ru]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[mail.ru:+]; DMARC_POLICY_ALLOW(-0.50)[mail.ru,reject]; RCVD_IN_DNSWL_NONE(0.00)[41.128.69.217.list.dnswl.org : 127.0.5.0]; MX_GOOD(-0.01)[mxs.mail.ru,mxs.mail.ru]; IP_SCORE(-0.83)[ipnet: 217.69.128.0/20(-4.19), asn: 47764(0.05), country: RU(0.00)]; NEURAL_HAM_SHORT(-0.94)[-0.938,0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[mail.ru]; ASN(0.00)[asn:47764, ipnet:217.69.128.0/20, country:RU]; RCVD_COUNT_TWO(0.00)[2]; DWL_DNSWL_NONE(0.00)[mail.ru.dwl.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Dec 2018 15:32:32 -0000 Hi, After upgrading to Clang 7.0.1, it crashed when compiling various programs on AArch64. They were all terminated at the same place: # lldb /usr/bin/clang -c /usr/obj/usr/src/arm64.aarch64/lib/libc/cc.core Core file '/usr/obj/usr/src/arm64.aarch64/lib/libc/cc.core' (aarch64) was loaded. (lldb) bt * thread #1, name = 'cc', stop reason = signal SIGSEGV * frame #0: 0x0000000002db02b8 clang`::LookupBucketFor() at StringMap.cpp:79 frame #1: 0x0000000003aeaa30 clang`::try_emplace() at StringMap.h:396 frame #2: 0x0000000003aeabac clang`::addOption() [inlined] insert at StringMap.h:387 frame #3: 0x0000000003aeaba8 clang`::addOption() at CommandLine.cpp:151 frame #4: 0x0000000003ae1c00 clang`::addArgument() [inlined] addOption at CommandLine.cpp:194 frame #5: 0x0000000003ae1b44 clang`::addArgument() at CommandLine.cpp:357 frame #6: 0x000000000305207c clang at CommandLine.h:1342 frame #7: 0x0000000003052078 clang at CommandLine.h:1365 frame #8: 0x0000000003051fcc clang at CorrelatedValuePropagation.cpp:67 frame #9: 0x0000000003051fcc clang at CorrelatedValuePropagation.cpp:0 frame #10: 0x00000000011d01a0 clang`handle_static_init(argc=138, argv=0x0000ffffffffcfd8, env=0x0000ffffffffd430) at ignore_init.c:124 frame #11: 0x00000000011d00a8 clang`__start(argc=138, argv=0x0000ffffffffcfd8, env=0x0000ffffffffd430, cleanup=) at crt1.c:83 Thanks From owner-freebsd-arm@freebsd.org Sat Dec 29 17:48:33 2018 Return-Path: Delivered-To: freebsd-arm@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 16F6E1429201 for ; Sat, 29 Dec 2018 17:48:33 +0000 (UTC) (envelope-from dclarke@blastwave.org) Received: from atl4mhfb03.myregisteredsite.com (atl4mhfb03.myregisteredsite.com [209.17.115.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7E38B77E56 for ; Sat, 29 Dec 2018 17:48:30 +0000 (UTC) (envelope-from dclarke@blastwave.org) Received: from atl4mhob05.registeredsite.com (atl4mhob05.registeredsite.com [209.17.115.43]) by atl4mhfb03.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id wBTHllbx002569 for ; Sat, 29 Dec 2018 12:47:47 -0500 Received: from mailpod.hostingplatform.com (atl4qobmail01pod2.registeredsite.com [10.30.77.35]) by atl4mhob05.registeredsite.com (8.14.4/8.14.4) with ESMTP id wBTHleBF008372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Sat, 29 Dec 2018 12:47:40 -0500 Received: (qmail 8944 invoked by uid 0); 29 Dec 2018 17:47:40 -0000 X-TCPREMOTEIP: 174.118.245.214 X-Authenticated-UID: dclarke@blastwave.org Received: from unknown (HELO ?172.16.35.3?) (dclarke@blastwave.org@174.118.245.214) by 0 with ESMTPA; 29 Dec 2018 17:47:40 -0000 Subject: Re: A reliable port cross-build failure (hangup) in my context (amd64->armv7 cross build, with native-tool speedup involved) To: freebsd-arm@freebsd.org References: <865A13C8-9749-486E-9F79-5EEDDECBE621@yahoo.com> <0154C3AC-D85B-4FCF-BA63-454BC26BC1A2@yahoo.com> <13f5e4dd-33fb-2170-e31a-1b5d5f155869@freebsd.org> <2E3F6196-4652-40D2-937F-8860B6005A35@yahoo.com> From: Dennis Clarke Message-ID: Date: Sat, 29 Dec 2018 12:47:39 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:64.0) Gecko/20100101 Thunderbird/64.0 MIME-Version: 1.0 In-Reply-To: <2E3F6196-4652-40D2-937F-8860B6005A35@yahoo.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 7E38B77E56 X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [2.92 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.88)[0.875,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_DN_NONE(0.00)[]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_MEDIUM(0.40)[0.398,0]; RCVD_TLS_LAST(0.00)[]; MX_GOOD(-0.01)[mx1.netsolmail.net]; NEURAL_SPAM_LONG(0.58)[0.583,0]; RCVD_IN_DNSWL_NONE(0.00)[119.115.17.209.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; DMARC_NA(0.00)[blastwave.org]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:19871, ipnet:209.17.112.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.18)[ip: (0.45), ipnet: 209.17.112.0/21(0.28), asn: 19871(0.23), country: US(-0.08)] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Dec 2018 17:48:33 -0000 On 12/28/18 9:56 PM, Mark Millard via freebsd-arm wrote: > > On 2018-Dec-28, at 12:12, Mark Millard wrote: > >> On 2018-Dec-28, at 05:13, Michal Meloun wrote: >> >>> Mark, >>> this is known problem with qemu-user-static. >>> Emulation of every single interruptible syscall is broken by design (it >>> have signal related races). Theses races cannot be solved without major >>> rewrite of syscall emulation code. >>> Unfortunately, nobody actively works on this, I think. >>> Following along here quietly and I had to blink at this a few times. Is there a bug report somewhere within the qemu world related to this 'broken by design' qemu feature? Dennis