From owner-freebsd-ppc@freebsd.org Sun Jan 31 21:45:40 2021 Return-Path: Delivered-To: freebsd-ppc@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3B8774E8A34 for ; Sun, 31 Jan 2021 21:45:40 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-55.consmr.mail.gq1.yahoo.com (sonic308-55.consmr.mail.gq1.yahoo.com [98.137.68.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DTPl71Y5tz4k7S for ; Sun, 31 Jan 2021 21:45:39 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1612129537; bh=LJlsCrvysXriwrUy8EWtgyFXnHrJVQ5rbdRxidJnUox=; h=Subject:From:Date:To:From:Subject:Reply-To; b=qCLDvf6eXfTeYVbAAw0LuXLvI06vH4tz78VMz4PV8dQjNKQirhE5leDFQ8RPSsW/9gaBO/UUHc+XqeJkc7GrzntKPqL0LQWT36QM2tITYJ5EvQmsNkzPBBvM+5czwXQ2368C6DIEf9TaZohMSWkEn2Xpdd4ETqgKmVBLpyKjandrsmdwBlLIfa1l88CR7jZUGNMiTWOy3xVHQ8hdbq4YyU/gkkm4LECmD+Bfpv+OmWVN+FJY7EwGO3NuiFua1DYsxOgYz2aNsBGKYseh4a3Mb8jeNIjDuP4akV/72qRfJ/SWmUQXEllcvvcrUho+Rft91VfSgTlJyWmAvNjPgLC7Kw== X-YMail-OSG: Tpr6o58VM1lb6OFBN1l7YtyOd9jq1mxg1YN7vupRPGpdjBiiXBB_N.LLEX0OAJ5 WvhqKQA86PiR6kuCormpYLhKUe2OBPtDbq7pAONK7ie862en2MqszrJ57O6wm2RtRxRPpWbY99jR XItnGpjy0Zj6PRFOtn7mn.plIbfHSiu2yPFS.UYksxHyvyZtAFzV8fP.94HB_1yl1oZ8nIX3LLIO 7bYMZY7geLtQJPKGi7q5fFkjLLjrHmjrZjB18NDjyiVJymFx3CDXxgi0429zIIx_pNjzkyM2mXgQ 9J2XXML2QQ49tDNxRhl2zyvdkKgayfFOIIm0_6doOtjFUTBccu31ApxlyRs.yyA3Q.P3PjevcIYm a3Oyk3IQH2VRSHo7FKoZDbRyc2QgUC8qxc3n__E0X3wCea0UQ6X22dHviy.6gWBr0pgnXmMxn9kZ m.hZHhGiZIkvs5hl_2AzBy48pKDfWKWtPMikt50datv4lsICKeP.0eHSI8_5_rlriK.RAzZGtKau Lm4aXKmGEjDhlMlqzkLLRygiKUbT2QWzyqNkgirrz_2bWcJQyzTvP_VawsdICmRY1gEoHGipnbmJ LY1EWbcmjLY3wbLrS2Zhh.ucUyu_MCkxlXIwL1N7UZsStab0.JJZgbhvZAomSdXCtiSxi7rxIv2q .TKGd8Ba8XRAVfsPv8xOoOpkE8_zCXhmw7nxL5D4KYeVTnohjhywqRRzJ2uFzJHVGm7CCElqwcKO MIw8_fBjWHLhJ_VWoRa05S1oH1LYLIYuX3hRKNRiN1WyVLXtcHa7At_5AB7jQl32JPT..BcIB6.P vYwHr1MLDFI24dQB0_N0i1zk9ZKqiXwFSF.SZDU1yJeptXEYIEY0XwEF9PtWYZs4uR2luy0Xp2Yg M2FqPlT354Sn_2xm2x7AImqSnI7bfUY.lJPnLAENGrmmsUZuSfu3zvI_iK76sqJcrYYJRgmrJldj VrYGmOJPJL8YwFQs3iGnbZ_.50idKJRgqI6nLuDKr8UFvplbV0cHlRCDiiksjEbXwKQBfaYPyq2V CI7YksaspYEOXkUQuWjWLFPaRQ4KZISjsyZS7bEYY6aj0_vAAsO7PQIuyIugGB8aEXAC8Vo0EfHC nKNLE0uRQU8HrpOHVWlFBGiLYM4VsA97MqkLlXv1vRnAjedi4Luu8WolH._tESLVYbbOqTH6KcuW awXH4hNzHLIyTQ3Usl_0AAsvkbo7Aau0vfTWgMORULPrfCN1s1GDrKw_3j0dTxxFzEo_ZEfhlkK7 ek.mFVkgEF_KAEIU_lE6BbK4gumSb19wUI57ajVXSLS7s3Lq8KsCQjzFR0.7cf_lS.GZ7bDyWTXL 4umFf.L_czqxwNs0p.5Ef5qKDn9.npaEAMMrAaZgAOvwqB9ym4XlBVqDTMNxK10k5TDWFRLP53fo WOrE0q9HEOFEhP34xCfj2rj3d6TFBOwvXOmwg327fRnUyk3qPv_YgZsV3yewWaxm52rR8Aoiz5kO kLBiFOpKQ6GnEhdnrPoWJJfAZK_2P6.WllmI7E_Aa7Er_lFkUSQtpRYxPe5PHsJIjoXlgtxfPDhJ xXQ3YqFQAj1cELj1fR4iEKhqEuYr3FWKM.CaPFOYqlU8x_YD1z6cO9Quno2zDKJY0_Cklr.bngui zW7YK87WmS6Bir49rCjzG8jwLeDfaBfj05_W2CID3XtgWB1CyLvEaVbnCgagFycIAFnuweI54uHe 5hL4JEW3bRtfHx3RrsfiY6LIKL_7jcInLN0rEng8Zcy8ScBYquKNfD2ww3tGgJFwY.TD_oatQepy ekfLcskTZDNiXY1U8LSThnebPpwwxHhClsWBLNCjuMLlX6VmNSE2Ay5Of_w189lw0duBCzfAmDqp gCXiqID1jdrekvB8ie1CxGLmiydNvusRMsHxulKG.RJ02uswOkJ7NsgBZQxo8VCIAEpW1KcRKEMg bR3eThcCjdektwNjImVTNAgp9dRGrndZdJUn2KssSUqFYFnDlC_MXk1xXyJBU6dXPo3.zmZD3jqD QiYUdJu3UmJHkA7uFx2vRI2ZUrEVmVGEZYjXFrJBDyBbXAjRcOhkeKvyGCra5hvzlRnUa_6rCmIm KJQtSwxz2zqwyyJRuTxLijQDW2Eix5LMMQiOIQjAekoUrFbXqjZlW.N1Fvuli.lZ.KhkoEQs1Cim Z6E2No8xPumYPL.1EUWTwaVS4XdDoraradr.Jn0WGRxszI.I5c1wPXbVT_5HtAP_a66p25aACsPi qu6WwAgnaUXzyYC_.z1HKNBo57s1FjCUmZOxcauF8TDh48T0Vt5BhvvaKmVJSzraAAQY28ZPT9zB nW24q7waLbF7PHN.TFsUsb8CBsFW__ePBwkO_t2H5THEkwJKCbV7EZoAIT5lfWQvBKIsAXn.0Q0N 6CcolI_WMZDL4BMfp4AvWHnZYfOPnngoJHfhb7nWZp328mIF9oK.4_iuZAI8qFE0H64TietEik33 XwUkJGNDpgKxBtXHrvMHRVSME76PsIMPqPyb5QrrsNRTOm4r9bshen7dtH06mGrHFFgLo02FgiuN tEL02H_ge0jrs8DaOB_gGlxzIju8t7T6mnDVbCZ5q4pMzteeQfuRDtnm_ialX5R6Qoi2Y23O317J i Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Sun, 31 Jan 2021 21:45:37 +0000 Received: by smtp425.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 1c36ffd3e1c9da3b4adb9da4b05c2d45; Sun, 31 Jan 2021 21:45:37 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Subject: Re: Expected issue? Old PowerMac G5 [...] vs. USB [...] [RealTek EtherNet] devices (...) From: Mark Millard In-Reply-To: Date: Sun, 31 Jan 2021 13:45:36 -0800 Cc: John-Mark Gurney Content-Transfer-Encoding: quoted-printable Message-Id: References: To: freebsd-ppc X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4DTPl71Y5tz4k7S X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; 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/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.68.31:from]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.68.31:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.31:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.31:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-ppc] X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jan 2021 21:45:40 -0000 [I provide some older context before the new material.] On 2020-Jul-27, at 19:47, Mark Millard wrote: > Context: head -r363590 based context, non-debug build. >=20 > Using a couple of USB EtherNet devices (with different > chip set families from different companies), I get > the like of: >=20 > usb_alloc_device: set address 2 failed (USB_ERR_TIMEOUT, ignored) > usbd_setup_device_desc: getting device descriptor at addr 2 failed, = USB_ERR_TIMEOUT > usbd_req_re_enumerate: addr=3D2, set address failed! (USB_ERR_TIMEOUT, = ignored) > usbd_setup_device_desc: getting device descriptor at addr 2 failed, = USB_ERR_TIMEOUT > usbd_req_re_enumerate: addr=3D2, set address failed! (USB_ERR_TIMEOUT, = ignored) > usbd_setup_device_desc: getting device descriptor at addr 2 failed, = USB_ERR_TIMEOUT > usbd_req_re_enumerate: addr=3D2, set address failed! (USB_ERR_TIMEOUT, = ignored) > usbd_setup_device_desc: getting device descriptor at addr 2 failed, = USB_ERR_TIMEOUT > usbd_req_re_enumerate: addr=3D2, set address failed! (USB_ERR_TIMEOUT, = ignored) > usbd_setup_device_desc: getting device descriptor at addr 2 failed, = USB_ERR_TIMEOUT > ugen2.2: at usbus2 (disconnected) > uhub_reattach_port: could not allocate new device >=20 > when I plug in the device. The one way I've found to avoid that > is to boot using: >=20 > hw.usb.xhci.use_polling=3D1 >=20 > but this appears to have large performance consequences for > receiving data over the device. >=20 > (The only reason I've tried this on a PowerMac G5 is as a test > for a Realtek driver update that John-Mark Gurney has produced > and requested testing of: PowerPC is the only Big Endian type > of context that I have access to. Going the other way, the only > powerpc families that I have access to are in old PowerMacs. > The above is not limited to Realtek chipsets.) >=20 > With the forced polling I get (for the device I originally > intended to test with): >=20 > ugen2.2: at usbus2 > ure0 numa-domain 0 on uhub2 > ure0: = on usbus2 > miibus2: numa-domain 0 on ure0 > rgephy0: PHY 0 on miibus2 > rgephy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, = 1000baseT-FDX, 1000baseT-FDX-master, auto > ue0: on ure0 > ue0: Ethernet address: ### > ue0: link state changed to DOWN >=20 > and: >=20 > ue0: flags=3D8843 metric 0 mtu = 1500 > = options=3D68009b > ether ### > inet 192.168.1.149 netmask 0xffffff00 broadcast 192.168.1.255 > media: Ethernet autoselect (1000baseT ) > status: active > nd6 options=3D29 >=20 > I will note that the USB device is USB3 capable but supports > use on USB2 as well. This was also true of the other device > that I tried that had a different chip set. >=20 >=20 > I do not know if some other types of USB devices also have > such problems on old PowerMacs (or powerpc64 more generally). Newer context: Both old 2-socke-t/2-cores-each PowerMac G5s now suffer Heat Deaths when used for much. So this is tied to attempting to switch to another variant of the G5s that happens to be accessible. But I think the end result is reporting a new problem. Well, I tried using the 2-socket/1-core-each PowerMac G5 but discovered that its gem0 gets regular device timeouts after a while, making EtherNet useless via gem0. This lead to again looking at using USB based EtherNet on this old PowerMac G5. So I tried plugging one of the RealTek USB ethernet devices, with hw.usb.xhci.use_polling=3D1 in place at boot. The result was an immediate, slient death in that the console display stopped responding. For reference: # ~/fbsd-based-on-what-freebsd-main.sh=20 merge-base: 3f43ada98c89bce5ae416e203ba0e81595a5cd88 merge-base: CommitDate: 2021-01-29 19:46:24 +0000 e124d7d5fc88 (HEAD -> mm-src) mm-src snapshot for mm's patched build in = git context. 3f43ada98c89 (freebsd/main, freebsd/HEAD, pure-src, main) Catch up with = 6edfd179c86: mechanically rename IFCAP_NOMAP to IFCAP_MEXTPG. FreeBSD FBSDG5L2 14.0-CURRENT FreeBSD 14.0-CURRENT = mm-src-n244523-e124d7d5fc88 GENERIC64vtsc-NODBG powerpc powerpc64 = 1400003 1400003 I doubt that plugging in a USB "RTL8251/8153 1000BASE-T media interface" should crash the PowerMac G5, but it does, and does so in a way that leaves no access to find evidence with. (I've no serial console for any PowerMac.) So I tried a non-RealTek USB3 capable EtherNet device, both with and without hw.usb.xhci.use_polling=3D1 : axge0 numa-domain 0 on uhub4 axge0: on usbus4 miibus1: numa-domain 0 on axge0 rgephy0: PHY 3 on = miibus1 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, = 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT-FDX, 1000baseT-FDX-master, = 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow ue0: on axge0 ue0: Ethernet address: 00:05:1b:af:1a:21 ue0: link state changed to DOWN ue0: link state changed to UP So far it seems to be working just fine. I'm using it without hw.usb.xhci.use_polling=3D1 . For reference (with some text replaced): ue0: flags=3D8843 metric 0 mtu = 1500 options=3D8000b ether ### inet6 ###%ue0 prefixlen 64 scopeid 0x4 inet6 ### prefixlen 64 autoconf inet 192.168.1.160 netmask 0xffffff00 broadcast 192.168.1.255 media: Ethernet autoselect (1000baseT ) status: active nd6 options=3D23 So the crash appears to be RealTek-device specific in some way, not some sort of generic USB EtherNet problem. I've no clue if the gem0 issue is HW, SW, or some mix, but its failure is not as big of a deal as crashing just from plugging in a USB device. Note: The G5 is doing a poudriere-based build that may take it days, with llvm building yet to start. I have 2 ssh sessions going, one session is running my variant of top and the other is running poudriere(-devel). =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-ppc@freebsd.org Mon Feb 1 12:16:46 2021 Return-Path: Delivered-To: freebsd-ppc@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 121D84FD64D for ; Mon, 1 Feb 2021 12:16:46 +0000 (UTC) (envelope-from mgorny@gentoo.org) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (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 4DTn4F1Fl1z3C3P for ; Mon, 1 Feb 2021 12:16:44 +0000 (UTC) (envelope-from mgorny@gentoo.org) Message-ID: Subject: Looking for shell access for (minimal) LLDB testing From: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= To: freebsd-ppc@freebsd.org Date: Mon, 01 Feb 2021 13:16:38 +0100 Organization: Gentoo Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4DTn4F1Fl1z3C3P X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=gentoo.org; spf=pass (mx1.freebsd.org: domain of mgorny@gentoo.org designates 140.211.166.183 as permitted sender) smtp.mailfrom=mgorny@gentoo.org X-Spamd-Result: default: False [-3.30 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[140.211.166.183:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:140.211.166.183]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; HAS_ORG_HEADER(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[gentoo.org,none]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; R_MIXED_CHARSET(1.00)[subject]; ASN(0.00)[asn:3701, ipnet:140.211.0.0/16, country:US]; MIME_TRACE(0.00)[0:+]; MAILMAN_DEST(0.00)[freebsd-ppc]; RCVD_IN_DNSWL_HI(-0.50)[140.211.166.183:from] X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2021 12:16:46 -0000 Hello, I'm working on modernizing LLDB's FreeBSD support. As a part of that, I have to port all architecture-specific code to a new process plugin architecture, and I'd prefer to test that my code actually works ;-). Sadly, FWICS FreeBSD doesn't work under qemu-system-ppc [1], and my attempts seem to confirm that. For this reason I'd like to ask -- would someone be able to grant me user-privilege shell access to a machine (or VM) running 32-bit FreeBSD on PowerPC for a few days? I probably won't need root access, though rsync(1) installed would be helpful. I'm going to need around 1G of disk space but I can try to squeeze in less than that if necessary. All builds are done on my home machine via a cross-compiler, so I won't be using much CPU or memory, just some network bandwidth to transfer the data. TIA for your help. [1] https://wiki.freebsd.org/QemuRecipes#powerpc -- Best regards, Michał Górny From owner-freebsd-ppc@freebsd.org Mon Feb 1 19:47:19 2021 Return-Path: Delivered-To: freebsd-ppc@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5E495534D63 for ; Mon, 1 Feb 2021 19:47:19 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DTz426dbRz4pp2 for ; Mon, 1 Feb 2021 19:47:14 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id 111Jl2Nw086680 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 1 Feb 2021 11:47:02 -0800 (PST) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id 111Jl20M086679; Mon, 1 Feb 2021 11:47:02 -0800 (PST) (envelope-from jmg) Date: Mon, 1 Feb 2021 11:47:02 -0800 From: John-Mark Gurney To: Mark Millard Cc: freebsd-ppc Subject: Re: Expected issue? Old PowerMac G5 [...] vs. USB [...] [RealTek EtherNet] devices (...) Message-ID: <20210201194702.GU31099@funkthat.com> Mail-Followup-To: Mark Millard , freebsd-ppc References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 11.3-STABLE amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Mon, 01 Feb 2021 11:47:02 -0800 (PST) X-Rspamd-Queue-Id: 4DTz426dbRz4pp2 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of jmg@gold.funkthat.com has no SPF policy when checking 208.87.223.18) smtp.mailfrom=jmg@gold.funkthat.com X-Spamd-Result: default: False [-1.32 / 15.00]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.52)[-0.522]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_TO(0.00)[yahoo.com]; FORGED_SENDER(0.30)[jmg@funkthat.com,jmg@gold.funkthat.com]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[208.87.223.18:from]; ASN(0.00)[asn:32354, ipnet:208.87.216.0/21, country:US]; FROM_NEQ_ENVFROM(0.00)[jmg@funkthat.com,jmg@gold.funkthat.com]; SUBJECT_HAS_QUESTION(0.00)[]; R_DKIM_NA(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[jmg]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[funkthat.com]; AUTH_NA(1.00)[]; SPAMHAUS_ZRD(0.00)[208.87.223.18:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-ppc] X-Mailman-Approved-At: Mon, 01 Feb 2021 21:02:17 +0000 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2021 19:47:19 -0000 Mark Millard wrote this message on Sun, Jan 31, 2021 at 13:45 -0800: > [I provide some older context before the new material.] > > On 2020-Jul-27, at 19:47, Mark Millard wrote: > > > Context: head -r363590 based context, non-debug build. > > > > Using a couple of USB EtherNet devices (with different > > chip set families from different companies), I get > > the like of: > > > > usb_alloc_device: set address 2 failed (USB_ERR_TIMEOUT, ignored) > > usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT > > usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) > > usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT > > usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) > > usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT > > usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) > > usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT > > usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) > > usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT > > ugen2.2: at usbus2 (disconnected) > > uhub_reattach_port: could not allocate new device > > > > when I plug in the device. The one way I've found to avoid that > > is to boot using: > > > > hw.usb.xhci.use_polling=1 > > > > but this appears to have large performance consequences for > > receiving data over the device. > > > > (The only reason I've tried this on a PowerMac G5 is as a test > > for a Realtek driver update that John-Mark Gurney has produced > > and requested testing of: PowerPC is the only Big Endian type > > of context that I have access to. Going the other way, the only > > powerpc families that I have access to are in old PowerMacs. > > The above is not limited to Realtek chipsets.) > > > > With the forced polling I get (for the device I originally > > intended to test with): > > > > ugen2.2: at usbus2 > > ure0 numa-domain 0 on uhub2 > > ure0: on usbus2 > > miibus2: numa-domain 0 on ure0 > > rgephy0: PHY 0 on miibus2 > > rgephy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto > > ue0: on ure0 > > ue0: Ethernet address: ### > > ue0: link state changed to DOWN > > > > and: > > > > ue0: flags=8843 metric 0 mtu 1500 > > options=68009b > > ether ### > > inet 192.168.1.149 netmask 0xffffff00 broadcast 192.168.1.255 > > media: Ethernet autoselect (1000baseT ) > > status: active > > nd6 options=29 > > > > I will note that the USB device is USB3 capable but supports > > use on USB2 as well. This was also true of the other device > > that I tried that had a different chip set. > > > > > > I do not know if some other types of USB devices also have > > such problems on old PowerMacs (or powerpc64 more generally). > > Newer context: Both old 2-socke-t/2-cores-each PowerMac G5s > now suffer Heat Deaths when used for much. So this is tied > to attempting to switch to another variant of the G5s that > happens to be accessible. But I think the end result is > reporting a new problem. > > Well, I tried using the 2-socket/1-core-each PowerMac G5 but > discovered that its gem0 gets regular device timeouts after > a while, making EtherNet useless via gem0. This lead to again > looking at using USB based EtherNet on this old PowerMac G5. > > So I tried plugging one of the RealTek USB ethernet devices, > with hw.usb.xhci.use_polling=1 in place at boot. The result > was an immediate, slient death in that the console display > stopped responding. > > For reference: > > # ~/fbsd-based-on-what-freebsd-main.sh > merge-base: 3f43ada98c89bce5ae416e203ba0e81595a5cd88 > merge-base: CommitDate: 2021-01-29 19:46:24 +0000 > e124d7d5fc88 (HEAD -> mm-src) mm-src snapshot for mm's patched build in git context. > 3f43ada98c89 (freebsd/main, freebsd/HEAD, pure-src, main) Catch up with 6edfd179c86: mechanically rename IFCAP_NOMAP to IFCAP_MEXTPG. > FreeBSD FBSDG5L2 14.0-CURRENT FreeBSD 14.0-CURRENT mm-src-n244523-e124d7d5fc88 GENERIC64vtsc-NODBG powerpc powerpc64 1400003 1400003 > > I doubt that plugging in a USB "RTL8251/8153 1000BASE-T > media interface" should crash the PowerMac G5, but it > does, and does so in a way that leaves no access to find > evidence with. (I've no serial console for any PowerMac.) > > > So I tried a non-RealTek USB3 capable EtherNet device, both > with and without hw.usb.xhci.use_polling=1 : > > axge0 numa-domain 0 on uhub4 > axge0: on usbus4 > miibus1: numa-domain 0 on axge0 > rgephy0: PHY 3 on miibus1 > rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow > ue0: on axge0 > ue0: Ethernet address: 00:05:1b:af:1a:21 > ue0: link state changed to DOWN > ue0: link state changed to UP > > So far it seems to be working just fine. I'm using it > without hw.usb.xhci.use_polling=1 . Is the axge a USB3 or USB3 device? The driver attached to both... [...] > So the crash appears to be RealTek-device specific in some > way, not some sort of generic USB EtherNet problem. My guess is that there's a USB3 issue.. Because an endianness issue in the driver would cause it to not attach or misbehave, it should not cause a hard lock.. I assume it was a hard lock enough that you were unable to break into ddb? Without more information, it will be impossible for me to debug this. > I've no clue if the gem0 issue is HW, SW, or some mix, but > its failure is not as big of a deal as crashing just from > plugging in a USB device. > > > Note: The G5 is doing a poudriere-based build that may take it > days, with llvm building yet to start. I have 2 ssh sessions > going, one session is running my variant of top and the other > is running poudriere(-devel). -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-ppc@freebsd.org Mon Feb 1 21:34:52 2021 Return-Path: Delivered-To: freebsd-ppc@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B11E4537BB6 for ; Mon, 1 Feb 2021 21:34:52 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-25.consmr.mail.gq1.yahoo.com (sonic303-25.consmr.mail.gq1.yahoo.com [98.137.64.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DV1SC4wF7z3GFQ for ; Mon, 1 Feb 2021 21:34:51 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1612215289; bh=ONoTHptmSZfDizFclFIS5EvEstnKEr8TJZKCDgMoDqk=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=bQU+r73kfqCaW8fZ6dzGKmFjxjc94Ij0qpMVhFC0mGL6X4qwPBpi9luhgRKZqCHNXtygBX9GiKaEgHLrXbNfpdqx0J+zZOjuJRaJFPMylCuhQmXTsxoY032Wa/6jdEGw/UNXWXuIcVLIc3m1s/4/yqWiS3dqd2cRopEih2EQ8l7DbzJ84JxXQiHt8DL2IvUnoi3zJ8SfMpxYfOJFnd+o5T9JtXdT5tGn15YsZRT+k0t005orA0vNwC2TercpgGn8cyAhv8VpCMQPM5g6KN+RieFA+WqJj5we37Aaf43IVeas9Yc43+HBZpWOHMKvBdowQrGturqsV36et4zFw6bS5g== X-YMail-OSG: pcpAFXIVM1mHkP1lUvnd_TSEu8RbY_KAr6n2BKQC_NfsrnRPSU8cfrxGBEvw3uF 5GILMSalum.pwxkL8JB_O5XIBzxD.tNZA31IMau3cUNDvn8heMtBas7hI7g.1yvdWeicMlj.8qia d.VwxnacepEfTV6vTWboinG2DHQYaCDoSzebssEV4zkJieKWts.4GKw18cuKLoneZ5E_Cu7cWvMY vn44FuEOAS3uHARGb7Fo648AU_nnxnbmToXx1ZZbaIA8WQ.fMSeL5JCA7IBAztnWsMITYnt6yVIR 7iFGrQxSnodeDeObWAKMWyRL3mB83tCBh629zuXs4a5zDdMKN8ZLoNo9OP4EEg1mLFCdhjATKgqF KE9wToldOt0p1X_UhEn5A1ksQek.WkZItfD5uw5iCpABouOxnHKBMYjla0s.HvFLNMoPLOuCKFIZ bbqZgFbv.gYLzIfOZcgt_b02NI7F_1JT5XLoRIJHiKo.tBwNQ_6lDb0zuVT8AtraAthms9Bo0Fa. okP_yhHgG2IFlHCnidjetE6Zh_nLCbZHRolBXn7rfKKhde30QKQr37.RNsZiAa7Nnqj6TFf7T9YF MuTQ2UH2Z3NKYGXYCV01WkiJCIzig7RDYf44PhNcEtOHc2A5NJUScBQeAV7psbUfd6OfZ0m_eiGy MwRHq4FX.q8KocMnK1wzaDyAl2VAfRCwEhuRhBtR1oRWGfOoCqS1SgME9liT1Bn8IC2QT.Jrjalq Qzc.02ofYpMwalncthOn3S_e3x8n5Qi9na6VEgfAJ6kfRP52Hp1Yjd6SMX7fzaLybGM46rjA.CBe I6TbtWpvDyHjB3HwmQEtnV3W9K1SVX1Vq0wqZxgc3yo.WxlZ9fMSftxXeOJXKYAZ7UGx0n6QIPTu QaM3Iib0ddIQGdqBdgZX.JgblUrLs3_A.AYmHG7WkFjfnodEYMtqh3SO3Nyrw_JTtZ5MdGl8iOMP Ce5lbBfEk_pIf2Ie7NXQ8O8I_S7d0kA1GmgHg44PLV7NIBgOU9aUIQkDobA3iLBCQjgQOJ0oFHSI 5WZjU8TrQosuN2NOxSxIQ35_rFg_HI2ARDrhtmrAuTZ3xwW3O.Ko_fJSVQuOh9cNL3TnkcnCtyKp 8c84E0ZhJgIXh5ge67qUQRjAAVO4N8Umfrvd0Bjsij3MqK9ksCjiINOz4ZEyVUjSfiFkixMV3pTX QGUTsfc91AJfsxPWYaVUUy90qSApgXrLPL9_XkuvB8etm.puak9CZU7hMNswC8XK7GPQu5EAoEg4 6_WV5USpH3.7YzFsJa8IXFNG9z0nkIq_ErmNEKnKVQE6zSxnHoPeIyzGwrAe5ywtcHoT7xtrLRFX OO1IKFR8ApHmkU0M7jhUv8x2BZCEW6ODg5FqEpbvKeAOs5cZ6nEOmI3n4AmZGgxRWo6OTNK9gx1Y Aav4hjxlcypq0bbvU2bLxV4_Yb9cPxAKg2_IBqQ0WoRxFB6moGVaCCFBo431.g9y6icWJQ8I7BxK SKIMik4ugc5Omhnjb95O6XFcy.hxrR0vxpgF5DJqUmHzPADDhGL4XBXCxhatBDcbZjZ__tlQ1pzE EwG3P0WKo8GgylLAiYtOPK0PCNG2aeCIo2nSIaGbANvJNir099WKzKnVQheOK8Q.eusnt6DnZ1k5 0JCX2p_SVW_fxooHXA8zHpwaTQRFjMPq_JWjwCyKLYakevUG8KJgdi3vx5l1pR0Z_tph4FCtiig4 d1l1DYoJ3GRGxzl70QRJcQB8Fk2KOnZ6Vka7Zbl_j5WQ.5rjtKgbKpbXrzj2.1P6IniFnOhkC0fs js7zWz3HQNLCwlhoeb_Qb6WIWxBObIYEsnPNE0Jih15Y75q66wJ9INfX_Ug6iOI9BtCAQ9o9tlj9 0OLyFbTqZjls.yKIK839zpK5_cMPzMTjXYthLcfYLXVZvCY0B3kCOOCsmAVezM8rQLzmSGQVaOr7 wqichahYH30X8iuyZ0mCkV2Nhsnd3.LeIjsHmETNILfv1vNE.swh9YtYUE6CzuVXJlT_9nYnI1Lk grqiT3EBOUvafjXYAM1cA6fIO0JbNJhsvaJx6ak__fw3NpRQFBjVyCeDas5Il0oBgDJQWQITzOn1 MyVEbXOxOsf2PYNc0AXwWircGT2eurrRcq9CZVFK4xLWV3tyrGXvCfQqYi7ke806OXP8TlpnTyPf 0SRRLvCSf2BjGw.QKxMslY_rI0ltV.aAYv2K4drywvLEeSDWR8x6vcPdaTSWGgsNhEcA.qbkJjF9 WWe7dwWIXsw2lxdAEmc7Y3e0st_tTxi7YfbJadAvjXSCh6iScXUvvceVTcJS00H496dGKtsQaebY 5qzjPxwqOGt_CYle1Ke8C86YlO1DDR7U03MoxRIpGO4IDHK_TtcgNgHgB8OyuErLvwPT7_vOAdkn bd5MbXI51aqUqYEnYSIkmHrnvnsalDKwPnh2tTktQiyk8ph2Hxl8tUAlcWxKAl3DM_..B.uZ2dtJ Kl2nYn4DIGOe3Php1Q.P_ERCz2ZLZJtzMNDB1fmjxvHnsPWssFFuQDINawe1YZfoob2Qpz56JivW PU1vk8RobW7Olj4GREYGB3gcFx9ykPIRhEK5hvdJG3SdpvYdphyNOgXF3jwsPT4j8zlXfGB_K8F8 MqBHfXQ-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Mon, 1 Feb 2021 21:34:49 +0000 Received: by smtp402.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID f72139355311cba72726f67b2ad1f9d9; Mon, 01 Feb 2021 21:34:45 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Subject: Re: Expected issue? Old PowerMac G5 [...] vs. USB [...] [RealTek EtherNet] devices (...) From: Mark Millard In-Reply-To: <20210201194702.GU31099@funkthat.com> Date: Mon, 1 Feb 2021 13:34:43 -0800 Cc: freebsd-ppc Content-Transfer-Encoding: quoted-printable Message-Id: <1C53A656-75ED-4E7C-9FB0-6C605BCDEC14@yahoo.com> References: <20210201194702.GU31099@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4DV1SC4wF7z3GFQ X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; 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/20, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.64.206:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.64.206:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.206:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.206:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-ppc] X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2021 21:34:52 -0000 On 2021-Feb-1, at 11:47, John-Mark Gurney wrote: > Mark Millard wrote this message on Sun, Jan 31, 2021 at 13:45 -0800: >> [I provide some older context before the new material.] >>=20 >> On 2020-Jul-27, at 19:47, Mark Millard wrote: >>=20 >>> Context: head -r363590 based context, non-debug build. >>>=20 >>> Using a couple of USB EtherNet devices (with different >>> chip set families from different companies), I get >>> the like of: >>>=20 >>> usb_alloc_device: set address 2 failed (USB_ERR_TIMEOUT, ignored) >>> usbd_setup_device_desc: getting device descriptor at addr 2 failed, = USB_ERR_TIMEOUT >>> usbd_req_re_enumerate: addr=3D2, set address failed! = (USB_ERR_TIMEOUT, ignored) >>> usbd_setup_device_desc: getting device descriptor at addr 2 failed, = USB_ERR_TIMEOUT >>> usbd_req_re_enumerate: addr=3D2, set address failed! = (USB_ERR_TIMEOUT, ignored) >>> usbd_setup_device_desc: getting device descriptor at addr 2 failed, = USB_ERR_TIMEOUT >>> usbd_req_re_enumerate: addr=3D2, set address failed! = (USB_ERR_TIMEOUT, ignored) >>> usbd_setup_device_desc: getting device descriptor at addr 2 failed, = USB_ERR_TIMEOUT >>> usbd_req_re_enumerate: addr=3D2, set address failed! = (USB_ERR_TIMEOUT, ignored) >>> usbd_setup_device_desc: getting device descriptor at addr 2 failed, = USB_ERR_TIMEOUT >>> ugen2.2: at usbus2 (disconnected) >>> uhub_reattach_port: could not allocate new device >>>=20 >>> when I plug in the device. The one way I've found to avoid that >>> is to boot using: >>>=20 >>> hw.usb.xhci.use_polling=3D1 >>>=20 >>> but this appears to have large performance consequences for >>> receiving data over the device. >>>=20 >>> (The only reason I've tried this on a PowerMac G5 is as a test >>> for a Realtek driver update that John-Mark Gurney has produced >>> and requested testing of: PowerPC is the only Big Endian type >>> of context that I have access to. Going the other way, the only >>> powerpc families that I have access to are in old PowerMacs. >>> The above is not limited to Realtek chipsets.) >>>=20 >>> With the forced polling I get (for the device I originally >>> intended to test with): >>>=20 >>> ugen2.2: at usbus2 >>> ure0 numa-domain 0 on uhub2 >>> ure0: on usbus2 >>> miibus2: numa-domain 0 on ure0 >>> rgephy0: PHY 0 on miibus2 >>> rgephy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, = 1000baseT-FDX, 1000baseT-FDX-master, auto >>> ue0: on ure0 >>> ue0: Ethernet address: ### >>> ue0: link state changed to DOWN >>>=20 >>> and: >>>=20 >>> ue0: flags=3D8843 metric 0 = mtu 1500 >>> = options=3D68009b >>> ether ### >>> inet 192.168.1.149 netmask 0xffffff00 broadcast 192.168.1.255 >>> media: Ethernet autoselect (1000baseT ) >>> status: active >>> nd6 options=3D29 >>>=20 >>> I will note that the USB device is USB3 capable but supports >>> use on USB2 as well. This was also true of the other device >>> that I tried that had a different chip set. >>>=20 >>>=20 >>> I do not know if some other types of USB devices also have >>> such problems on old PowerMacs (or powerpc64 more generally). >>=20 >> Newer context: Both old 2-socke-t/2-cores-each PowerMac G5s >> now suffer Heat Deaths when used for much. So this is tied >> to attempting to switch to another variant of the G5s that >> happens to be accessible. But I think the end result is >> reporting a new problem. >>=20 >> Well, I tried using the 2-socket/1-core-each PowerMac G5 but >> discovered that its gem0 gets regular device timeouts after >> a while, making EtherNet useless via gem0. This lead to again >> looking at using USB based EtherNet on this old PowerMac G5. >>=20 >> So I tried plugging one of the RealTek USB ethernet devices, >> with hw.usb.xhci.use_polling=3D1 in place at boot. The result >> was an immediate, slient death in that the console display >> stopped responding. >>=20 >> For reference: >>=20 >> # ~/fbsd-based-on-what-freebsd-main.sh=20 >> merge-base: 3f43ada98c89bce5ae416e203ba0e81595a5cd88 >> merge-base: CommitDate: 2021-01-29 19:46:24 +0000 >> e124d7d5fc88 (HEAD -> mm-src) mm-src snapshot for mm's patched build = in git context. >> 3f43ada98c89 (freebsd/main, freebsd/HEAD, pure-src, main) Catch up = with 6edfd179c86: mechanically rename IFCAP_NOMAP to IFCAP_MEXTPG. >> FreeBSD FBSDG5L2 14.0-CURRENT FreeBSD 14.0-CURRENT = mm-src-n244523-e124d7d5fc88 GENERIC64vtsc-NODBG powerpc powerpc64 = 1400003 1400003 >>=20 >> I doubt that plugging in a USB "RTL8251/8153 1000BASE-T >> media interface" should crash the PowerMac G5, but it >> does, and does so in a way that leaves no access to find >> evidence with. (I've no serial console for any PowerMac.) I'm working on seeing if I can get Firewire/dcons based access going in hopes of getting more evidence that way. I hope that such can be done via a 32-bit PowerMac G4 against the 64-bit PowerMac G5: it looks like the only other G5 no longer can reliably boot (overheating that fast now). >> So I tried a non-RealTek USB3 capable EtherNet device, both >> with and without hw.usb.xhci.use_polling=3D1 : >>=20 >> axge0 numa-domain 0 on uhub4 >> axge0: on usbus4 >> miibus1: numa-domain 0 on axge0 >> rgephy0: PHY 3 on = miibus1 >> rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, = 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT-FDX, 1000baseT-FDX-master, = 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow >> ue0: on axge0 >> ue0: Ethernet address: 00:05:1b:af:1a:21 >> ue0: link state changed to DOWN >> ue0: link state changed to UP >>=20 >> So far it seems to be working just fine. I'm using it >> without hw.usb.xhci.use_polling=3D1 . >=20 > Is the axge a USB3 or USB3 device? The driver attached to both... The axge, like all my USB Ethernet devices, is USB3 capable but is supposed to support use in USB2 contexts. The PowerMac, of course, is old and only has USB2. > [...] >=20 >> So the crash appears to be RealTek-device specific in some >> way, not some sort of generic USB EtherNet problem. >=20 > My guess is that there's a USB3 issue.. Because an endianness > issue in the driver would cause it to not attach or misbehave, it = should > not cause a hard lock.. Both the axge and the ure are USB3 capable devices that are supposed to support use in USB2 contexts. The axge works but the ure leads to the crash. > I assume it was a hard lock enough that you were unable to break into > ddb? Without more information, it will be impossible for me to debug > this. Yep. I CC'd you mostly so if if any other similar reports came in that you would know of my context's prior failure. I am working on seeing if I can get Firewire/dcons to operate in hopes of getting some information about the crash. If I get that going and get some more information, I'll report it with you CC'd again. >> I've no clue if the gem0 issue is HW, SW, or some mix, but >> its failure is not as big of a deal as crashing just from >> plugging in a USB device. >>=20 >>=20 >> Note: The G5 is doing a poudriere-based build that may take it >> days, with llvm building yet to start. I have 2 ssh sessions >> going, one session is running my variant of top and the other >> is running poudriere(-devel). >=20 The poudriere build finished but it was building 32-bit powerpc ports for FreeBSD:14. I've still got FreeBSD:13 ports for=20 64-bit. If I end up needing a FreeBSD:14 gdb/kgdb I'll end up needing to do another round of port builds since no build for powerpc64 is running according to pkg-status.freebsd.org . The last build that completed normally was for FreeBSD:13 . =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-ppc@freebsd.org Mon Feb 1 22:57:59 2021 Return-Path: Delivered-To: freebsd-ppc@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id AA2624EAF85 for ; Mon, 1 Feb 2021 22:57:59 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-21.consmr.mail.gq1.yahoo.com (sonic305-21.consmr.mail.gq1.yahoo.com [98.137.64.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DV3J635qWz3Mby for ; Mon, 1 Feb 2021 22:57:58 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1612220276; bh=8EYrz1a4LI7KhzsMFHgVJU130+oCmJ9zHuY8O+/7S0g=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=dq2TGcanUwPluSiX/NUrbbRW+RPXMUXKLfEjaDDXGISEf3Dqs8WBPfSu52JmLT1MmnFbcflNdJNWAxzsR6UaEaQI4xI9mNR3XEGPFWp+3I/ylYgwfxc9d1f92qyLDFtZRPWajYUJaXad75R3E7VibJfk1h15XqAsOBFdQu+lCWKuWRCCTJHYvn6rF+nP+reoevwbStzT6bEYUenPNhPraCLpdV2gfjzzjYEkGH38QJZJd87mEHN9XKBr6OeaPLrR/1sMBdIQ1xsT8SbWkys+i6kc7DEwQzIeMt7Wpe6WwZwwZuzcoyGcFpPIr4YAVacTm+gDsQrLIvW6IjeZ5quncQ== X-YMail-OSG: H6osAxwVM1lDkcYC0A6KL9Sjw9LKqnHtvCCXOHyER1XnNEMWOV2E1wydR_FmAAb YcEMPYni6_stH3QZP3EiXGAw19sNFTfrYs3UGpiYl7PTc6YGSEwZDp3jrbxCdK.pzVO79mcN.qEJ 5xJGOZolc3Rt4WuSEnGsEE58ggZRFgHHw9JiQxZ7MyDirxg7Wv.Syys33rVknZtSzIOBk5chsY_E iRRWNraSbHaLanAs1xWRlxFUN_PUq2QIWDN7Yni39QSAOcSCCuWnrCZvlhCPAtlr3YJMSlk4tDaM IBtkmBKp7brFVjvQmumFfRb6_NjmpJoKMuN4kJJAMox3Ali72zF5_texU5tb5EqGsGd9O1LFzGj4 zjbVd1NPNpnKUjpXU5tuHQPqjoR9AKqdvZq77ZDjFsw9P0oVJCUo2fL9pU0ZwEInZS9kuDQD2HUp 9.kHYJZwhel4JQutpdfgLWi8D0GiAxUrh7FFvZZE7AZFlINQdNolHqddiShn02ft1J7BXFas0Qhy KBVspHXARgkX4gDZm2wNiRG6pHNGKLol31O7Z_n0vaNimYenmjwGwoefbgW.JgGRiWLYgd99ejST lDr3uTnFiePcrKUFdtutyPzb0NMSzibGz0TnCnz84OWDshMN2wLr49AVwhkPGdaRyTReuP29jXUC wGqEm13fyilYLh34iOVf.lhtNdw12kRhQL5Q9SPBL3vDxdnjqIH1U2q4_9mo9qROpjU4ATRD7bId Ribb4dg6KklfXflKxCPrcGMVEp1sYMzisIRDzVqHjI83uSlQAiztfViW5gtkhUXOtkdXKHeAmUn. 5QNMQVfXBZnFkcx9eI1UJphzePar8Gp1tCdUM6jAgqtAlGGDPAZHr3moltHji8sFDZZrpmBLZCWC 5kLkE1A0wpWS4x1zQkXfxWRNomao6qGZViO_LPuvLmP3V2eUOoEKnnsdYzDFcCIz5PwPKbF6.mhN wYJuzr2jkJXQ08Dvp25QCRPUYo6loM3OAt15WKHzg3DzJqIPzULRAH1GiZmtmkiUt6NsSzWN9BZs omHzCauJ47OOGRoXNkKpGwPomXMqBlnHln8jabUzwMJ4RoiKnkYGyrDqn8jzygVqVKj8wNvOlokb ErLV6Enz03d75TumZEBcUABZIB9.VuBHo01.Gw5zGIENRtnBsm36bR9tsStzCfkYmqDA5u.pvTib iSbNcUFsXUbZghujbOJoDAx.vgjRyXGOamyPUQFaUSZhiJiKVsxULQyjTlyFXETyBAypJCx6Ls7O 46zYvezbo4IoGN4IEK9tVbjzBrqHUqF4SpZ8XLsqmhAqr26SkhsN7WvwzAnNUs97fWx6ey39xw72 hzRx06PLJwVGWqQTu1vDKlpIAe7SL1wvFHRX1VBT7JWDAVPsg06MrXq7P4DMGLLmk0iGJq2ffkMi PipBvuzsLCz3ZrzwQzfqjb4S6pxXrzoOJYoA4ukG.4.JWJSXhDzNDTMObuE5rEafTDN0DEr3f1rT PXsIraT2nLW1_NZUOwEeqZh2d1CP5X1Cpwx_zz3UZOVcgdDW0orl9dYabZxsVww18UeuqFy9WUzq Ys27r7CSFZuvH5t_b4SVU8rmemFfiLBE3nq.UU9IYKXi0j7u2sO6jIdxspT._IgWRCGlJVL35aRa KdnVFV05kZb02kyD79Xz00IvU81kxt1xps8Ijov1ir.LGx956TWADEy0t7avdI4ZZnYyqITBbNK_ hToxhl0NnOjH5czLjQ8se7N3SkdG_x2k6MQOWQ8lJdhuKtCgMVjFUHgs3soe5rfVOM6TxqZB39lZ JHCHV0dhCuSzl9tIqEUI1gIag2bSWOUSX.JIu8lkO29_Ozbe9BmqI04fbRGk0vSF5N3hoI_unJdI qOhcfAZdlSaPjNusnfrJ1S3ql6UJ3hmMffdMBW8frK1F37cw_yDE305rfMo5o53ApegMtbI2ieFO 7fNIq5ktz_dkOWm4g8haIDDoGc.A8jJF476rR.PNrUNfIXeDDK0H.T73s5ELYZET9kXP6XI0xfdI EsaGEdPd.x3XsG2vnYL4oR.yyeFoP2iznLSsc3Y5CvEA3aRG4EhSPWF0IC_pbes3bUgOxbs75Htq iKuGmASVvgAjGsKZrrmZ4Y8.pw7gR2Gfcpa21INcROLHgyxDNTCRJA_0.Pdx3w1S0OG9._F3RJ3r P8dYOL_cL3T8NuGC9RrY3p5VvlkrHLpEfdqwdeJ9fCK26wAN162MImYV7RBAhi7i5cKAl9GH9NET ZjhBKMtv220qop.g00xWM4Cib_cI70uKKcvqktkU2N39vbb_ck1utzL_gZanMoB52hlKOILjcLhc IeRq_lcfaLCj.fKegQwCrmZ2m_b0cwd8bj89IjEyfXc8XONF1vgiu3BWjx0oz7XwchsOc4TQYKLp OUb7jxIku.48cX8EvVFK1TQGl5.Qc33edVYnhnj5cC80lo0vVzgpmRvDA8EcqWHRU6e9pCKRK6rT jyvCizok0lIRC2ZFPDbb1yn_ewFR258Hl_UV331yyFoFvJQUke5sIE7ilhlL_ehfGHiZHRms_rIZ CTwmbm1d2lIxELjE53eZkO85g X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Mon, 1 Feb 2021 22:57:56 +0000 Received: by smtp425.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 8c44dd099c0a5a226026ff7040ed8d14; Mon, 01 Feb 2021 22:57:55 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Subject: Re: Expected issue? Old PowerMac G5 [...] vs. USB [...] [RealTek EtherNet] devices (...) From: Mark Millard In-Reply-To: <1C53A656-75ED-4E7C-9FB0-6C605BCDEC14@yahoo.com> Date: Mon, 1 Feb 2021 14:57:55 -0800 Cc: freebsd-ppc Content-Transfer-Encoding: quoted-printable Message-Id: <0382C932-2BFB-4A5A-9ABD-B4AC2C0AC2BF@yahoo.com> References: <20210201194702.GU31099@funkthat.com> <1C53A656-75ED-4E7C-9FB0-6C605BCDEC14@yahoo.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4DV3J635qWz3Mby X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; 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/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.64.84:from]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.64.84:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.84:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.84:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-ppc] X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2021 22:57:59 -0000 On 2021-Feb-1, at 13:34, Mark Millard wrote: > On 2021-Feb-1, at 11:47, John-Mark Gurney wrote: >=20 >> Mark Millard wrote this message on Sun, Jan 31, 2021 at 13:45 -0800: >>> . . . >=20 > I'm working on seeing if I can get Firewire/dcons based > access going in hopes of getting more evidence that way. >=20 > I hope that such can be done via a 32-bit PowerMac G4 > against the 64-bit PowerMac G5: it looks like the only > other G5 no longer can reliably boot (overheating that > fast now). I see that I had forgotten to say that the initial report was based on a non-debug kernel build's behavior. Sorry. The debug build with dcons and such built in does give more context and allows me to copy/paste the output. and allows me to type at the console. Booting, logging in, and then plugging in the ure results in: ugen4.2: at usbus4 ure0 numa-domain 0 on uhub4 ure0: = on usbus4 panic: lock (sleep mutex) ure0 not locked @ = /usr/fbsd/mm-src/sys/dev/usb/usb_request.c:459 cpuid =3D 1 time =3D 1612216507 KDB: stack backtrace: 0xc0080000c200df70: at kdb_backtrace+0x60 0xc0080000c200e080: at vpanic+0x1e0 0xc0080000c200e130: at panic+0x40 0xc0080000c200e160: at witness_unlock+0x18c 0xc0080000c200e1f0: at __mtx_unlock_flags+0x70 0xc0080000c200e280: at usbd_do_request_flags+0x170 0xc0080000c200e3c0: at usbd_do_request_proc+0x98 0xc0080000c200e430: at ure_miibus_readreg+0x22c 0xc0080000c200e4b0: at mii_attach+0x490 0xc0080000c200e5a0: at ure_attach_post_sub+0x21c 0xc0080000c200e660: at ue_attach_post_task+0x188 0xc0080000c200e760: at usb_process+0x170 0xc0080000c200e820: at fork_exit+0xc4 0xc0080000c200e8c0: at fork_trampoline+0x18 0xc0080000c200e8f0: at -0x4 KDB: enter: panic [ thread pid 15 tid 100146 ] Stopped at kdb_enter+0x78: ori r0, r0, 0x0 db:0:kdb.enter.default>=20 It looks to be that the complaint is from the code: usb_error_t usbd_do_request_flags(struct usb_device *udev, struct mtx *mtx, struct usb_device_request *req, void *data, uint16_t flags, uint16_t *actlen, usb_timeout_t timeout) . . . #if (USB_HAVE_USER_IO =3D=3D 0) if (flags & USB_USER_DATA_PTR) return (USB_ERR_INVAL); #endif if ((mtx !=3D NULL) && (mtx !=3D &Giant)) { USB_MTX_UNLOCK(mtx); USB_MTX_ASSERT(mtx, MA_NOTOWNED); } Doing boot, login, plugin with the axge need not fail (and typically has not so far): axge0 numa-domain 0 on uhub4 axge0: on usbus4 miibus1: numa-domain 0 on axge0 rgephy0: PHY 3 on = miibus1 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, = 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT-FDX, 1000baseT-FDX-master, = 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow if_delmulti_locked: detaching ifnet instance 0xc000000013450000 if_delmulti_locked: detaching ifnet instance 0xc000000013450000 With the axge already plugged in at power up it generally works as well, at least for the debug kernel: axge0 numa-domain 0 on uhub4 axge0: on usbus4 miibus1: numa-domain 0 on axge0 rgephy0: PHY 3 on = miibus1 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, = 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT-FDX, 1000baseT-FDX-master, = 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow ue0: on axge0 ue0: Ethernet address: ### ue0: link state changed to DOWN ue0: link state changed to UP if_delmulti_locked: detaching ifnet instance 0xc000000013030000 Similarly, the ure already plugged in can work: ure0 numa-domain 0 on uhub4 ure0: = on usbus4 miibus1: numa-domain 0 on ure0 rgephy0: PHY 0 on miibus1 rgephy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, = 1000baseT-FDX, 1000baseT-FDX-master, auto ue0: on ure0 ue0: Ethernet address: ### ue0: link state changed to DOWN ue0: link state changed to UP if_delmulti_locked: detaching ifnet instance 0xc0000000130d6800 An interesting point about the "it happens to work this time" example is that ure0 is working without use of hw.usb.xhci.use_polling=3D1 , unlike back during the summer's experiments. However, I did get one failure with the axge(!) (for an already plugged in at power up context) that I've only got a digital camera picture of but it looks just like the earlier ure backtrace in structure, but saying axge instead of ure and having different offsets in those routines: axge_miibus_readreg+0x124 . . . axge_attach_post_sub+0x15c The detailed stack addresses are distinct, of course. Same pid but different tid, as well. So it does possibly suggest that ure and axge share a problem, such as lack of initialization but mixes of lucky and unlucky values showing up. (But I've no more specific evidence that such is a reasonable summary of what is happening.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-ppc@freebsd.org Mon Feb 1 23:46:49 2021 Return-Path: Delivered-To: freebsd-ppc@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 580064EC017 for ; Mon, 1 Feb 2021 23:46:49 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-25.consmr.mail.gq1.yahoo.com (sonic304-25.consmr.mail.gq1.yahoo.com [98.137.68.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DV4NQ75Ktz3QG2 for ; Mon, 1 Feb 2021 23:46:46 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1612223205; bh=mMX3f35KZNj0twwn4lCdZAJvT+2SDoZIBjneFTt4Ba1=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=r2RsCh5H/VzAbcSUfueLUcrcKnb4lgi0df9hKrXrdyZemAZ4ZqgHQQQHc93CzJRlwcF5dII7tKwsFJRTw/PCxAclqi5SQ3JDk7mzbB7/HP792MlXE/8Fu5ZtBl0Vjv1wVe6f8vpHiSCBtEgjBw5ijzlkUpXNJZF1pzDNo5WBKHHa8Up3yIV4s8PhfKq2nEG6N8MfXgEL2bnlcWtXLL2+gD9mCR5iNd9v35QxzArK8CsnmW+XgyNElv/dpHb9LoVBLQ6LAUEnjvT21mGDudMiKKZI19qWWwEWyfUjWWpFgNiThkes84JkOZdv+TSuTRXul4FLZsgX4/XJDuRhu7PyAA== X-YMail-OSG: YziwkB8VM1kKboayETmmeMvtnCO6szHOMXXBVPT2HQcRBJ0E2lpr7sXfZT6GMey 7YMUQl2VWyTrxoeS80jbNyA.ecWjpvcNujtqwV5NdVqfr46oZPpc53ybGKhwJS4xW99kyXYPs3yP odHh.ILivSVUH6LpnvKsxKIF79X1i30XbcM5McekHXRoLEKyjW0Zv03sXE_hZp1RBEq1U43bSyzT HP.HR300DEckmJhmKb21kLtucfvjv4H9L6A5RsVt8f3.Lb_54OtI8QBKADqxXYVZ_Psr4E2U50Hh cUXQYS8Kpe1pa2O5D0WYW9Rh46nJYb1ey7WKZE97TqbVa87oWlnx3jiYkdi5jKJub_9RE2gRMpet GQ4bawKYhKcEgX_AyTNT.XYgoiFDFJJU.B.SWvCKT2.d8KVbku4Ws91ihqzTGPx13Z1ng2z56me5 Hi49xf_cl.9p2PbN17IXKLH8Na.nv6VUnGLuOIJ4JIvCdGjRWISwTr6R9Jx6ZvxxO9znb_OAgngq KMCEHgpPmgBBJPE62MMGCjCz6mz8b9vgMHYPOMV7r3du5kFjVUiY18vrsRgOxAnG3gri8eV7cnTj GcdTQJqXaQZauKWVJG7627l3h_ouaovNtwOtU7ba_oV02Hq0XB587q9qsG4EMjFsgmW934ADtnsU I6I6Yw4MffzpYOoCJgNljX8AaI_KMJYEt2wBPM59c9eAvNFKv5PjufOi73tBqpMFV1O_TKh6M6uR fJmjAjuYJvrjTDl4R_GF0r.QIIvbH4OzSROPh_jgUru2pPpjl1sNnkAgY1Zl6krvXb3LNb._j0ZI Y0vKdzijF2fnSNOwGX1lxXfhhVVvziArfI2UmgdRl.ZBirPCE9IGlejRqeJx5JsEQiB9ywnKApKa 3JlYKPRz90gpLVuGjT2tPtEttZEbMDhyVFZwPNJUAYAcrkWxe7OmlMwo0w3lHZc.7mOfUrD5DCc0 QfyJuPTIZNpFmPVwmLHvCY_vRqC2Hv4fVHTskxuU5i8gPZhdxeWqiuUFxe1OPwHRYslySPg4b.03 AOgiwtvByBbd7ugJgYqZCXPBcSQZvP9Q.nQ1l6K.YgKG7f12XIeYtnQP7LESvfWYkCfJrIfcGuhq 03ZWGX8KnloPAH2bVG7ToQdgFdWWcpIC5Ob9IqUUzK3H6OjW.s3sKRpbHhzKlIRRsoX5cPEmBGZR 1hRP1nTnqpdhPmzMkFv_fN1lqXAk85Ex.HhNqPPnAFa1Z_wkokRiGJj3T.z6g5iv7LyjZRK4b6AB LrxcSJjrznGOraS6VuWV47TW8pLiROWRH2n9D50rSo2H21Sqwv5yakL5RTUnlCpM.OUAjNRs6M0F nkFAnVXJ0FvY0zExpo.yzZq84bKPntkg7AgjVtDa_khXw4bRv5kf3.63ptA3fsZZjMoHHZ57ocE8 nPt6Z8vjv3CmNDGYCBOWcL426eNo1kKRQKlZPyaj5SVBVA61GP36NykNKHNA5zq_tnjpd4bN1eX. LuA.4F3phqSMUKSb65_EzerckJHfgryVmTcsgeJRI_1xUhgrjYmVYDu5mQIt1RNEyg.7E8laphHn wxeHKLv9hUFMoI5oNGc0UTKh9SlEfgQmZ71.G5hUKmt4IH9yi_pkj_D_KTDJxeLEL.nUi3kHcdW2 BZymlwHtH1nQA1gG98zqS7Z3k.vVaE2AT3sL.phLqpqoxZRXcPZ8NGlXd.DArO6VEmGw1LOIbgUp 8M1tsIKYTE8pGWMXHsuoLQfBNwhZS4KKcdJFFtKpexwIAHYcdK89.rIuPrpitds5CSnv9pTJjWpE 6522eFRzA0kpWRKnkcAEQdcnk9BmZxpOWVMIng7D9JyzwWSJJQQEABtoNhVkeobNHgIS7.VlCJ3q Lql0_oLhkrc_JlbhF1zCF20qPrpw1uHcY35Afu_.6A2MvfhguqRIph6bWMpqkYNukbv_6HLOWPFn zkWI7841ofPeoT2XnlccrOBC5cJRchDr1IklSwa3ZhVT4l1jkG4vh4j53taa5eKk4ERWUgVAz_E4 LLUdkDVVGiOTwlSINpCKJ51JXvBNNGRRSyJWyKt1IJvvz52jzMv4sSQAckhhb9FF1_r8FJ5wPs7M LtOwz6CWvhkPmqlRy3k_0ZejsXgbhBHY3QGCxarllBmwxI0_YeFywooF_pfiyKiX0EaU4RG9m8fJ vGHmXESvSwFqbuQUjz2Dr53j60VejCJN55Z8jhbpMw1qvpUHSW6Jomkx_kxZjr5fuqSdCGPlNktZ sE98UVJzICKp2udEgEBcwDL2pyrnUThRM5tDfTC9kkg_fQorm2gNH1hJxhVySi0Ks411Zy93DG_V NFiPw82GXvC9ffCgqz_88vBSuqJKVX6K7_7UGGIzDZ_nAJ9wId1zwBQsxZuVLli.phxa_.JBuQGm KEupiCDq8Xg95WLFYgqXmnI2qegYVRZXIKZPDbOOjyoASiQtxNvE8rAq7gw04OGCgD1ZfeDQTkn6 sVa7KpweNamFrd9trtsJag9nPVoKJgPT4z.kImZOkwOM.4znLhVQc1z3uAjglcT1Sj2yx8snb2L6 cWEoBPj6lIYJLr0oUS21yuCsCNsMUY2WRDXv7lmUJrJG5tkpM.XwcFVDHPX2_PZYmU_pVGp3jzTm CtcU- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Mon, 1 Feb 2021 23:46:45 +0000 Received: by smtp413.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 20f634982610bee05aa3357aed6c82b5; Mon, 01 Feb 2021 23:46:39 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Subject: Re: Expected issue? Old PowerMac G5 [...] vs. USB [...] [RealTek EtherNet] devices (...) From: Mark Millard In-Reply-To: <20210201222854.GV31099@funkthat.com> Date: Mon, 1 Feb 2021 15:46:38 -0800 Cc: freebsd-ppc Content-Transfer-Encoding: quoted-printable Message-Id: <38B76FA1-2564-4EE0-ADAE-D12F693358EB@yahoo.com> References: <20210201194702.GU31099@funkthat.com> <1C53A656-75ED-4E7C-9FB0-6C605BCDEC14@yahoo.com> <20210201222854.GV31099@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4DV4NQ75Ktz3QG2 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; 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/20, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.68.206:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.68.206:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.206:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.206:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-ppc] X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2021 23:46:49 -0000 On 2021-Feb-1, at 14:28, John-Mark Gurney wrote: > Mark Millard wrote this message on Mon, Feb 01, 2021 at 13:34 -0800: >> On 2021-Feb-1, at 11:47, John-Mark Gurney = wrote: >>=20 >>> Mark Millard wrote this message on Sun, Jan 31, 2021 at 13:45 -0800: >>>> . . . >>=20 >> I'm working on seeing if I can get Firewire/dcons based >> access going in hopes of getting more evidence that way. >>=20 >> I hope that such can be done via a 32-bit PowerMac G4 >> against the 64-bit PowerMac G5: it looks like the only >> other G5 no longer can reliably boot (overheating that >> fast now). >=20 > I think that it should just work.. I haven't looked at the dcons code, > but IIRC, it should... If not, it should be easy to fix to make it > work.. I've got a basic telnet/dconschat going, allowing me to copy/paste text reproted via telnet output. I've replied earlier with some information gathered. I'll use some of that background to respond to later questions below. I'll presume context from the prior reply. >>>> So I tried a non-RealTek USB3 capable EtherNet device, both >>>> with and without hw.usb.xhci.use_polling=3D1 : >>>>=20 >>>> axge0 numa-domain 0 on uhub4 >>>> axge0: on usbus4 >>>> miibus1: numa-domain 0 on axge0 >>>> rgephy0: PHY 3 on = miibus1 >>>> rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, = 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT-FDX, 1000baseT-FDX-master, = 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow >>>> ue0: on axge0 >>>> ue0: Ethernet address: 00:05:1b:af:1a:21 >>>> ue0: link state changed to DOWN >>>> ue0: link state changed to UP >>>>=20 >>>> So far it seems to be working just fine. I'm using it >>>> without hw.usb.xhci.use_polling=3D1 . >>>=20 >>> Is the axge a USB3 or USB3 device? The driver attached to both... >>=20 >> The axge, like all my USB Ethernet devices, is USB3 capable but >> is supposed to support use in USB2 contexts. The PowerMac, of >> course, is old and only has USB2. >=20 > Then why bother w/ xhci? Since that should apply only to USB3 > controllers... If your mac isn't USB3 compatible, shouldn't be > detected/probed/used, and you should only have ehci... I've no clue why it operates as it does. But I have example boots for ure0 also working just fine and one where axge0 had the problem. So, both sometimes work just fine, sometimes not. The problem seems to always be at the initial probing, be the device already plugged in a power up vs. plugged in later. If that initial activity works, then the device is generally operational. (I've not tried plug-in/unplug/plug-in/unplug sequences.) > This is why I was puzzled, tweaking xhci implies that the system is > USB3 capable... I'm not aware that I did anything special, other than just plugging in the devices. My kernel configurations are based on GENERIC64 (via includes), with some overrides but not of usb things. > (if xhci changes USB2 behavior, then it needs to be renamed)... No clue. >>> [...] >>>=20 >=20 > Have you verified that it works w/ other operating systems on the Mac? > Could it be that the device itself isn't compatible w/ the USB2 > controller on the mac? I have example boots for ure0 also working just fine and one where axge0 had the problem, all the same FreeBSD 14 build on the same PowerMac G5, just rebooted and trying again. I take that both devices sometimes work just fine as evidence that a USB2 controller compatibility problem in the PowerMac is unlikely for both devices. > Have you tried to add in a USB controller card and use that instead of > the onboard USB controller? No. I've no access to such a separate card as stands. (And there is the "sometimes works" evidence as well.) >>> I assume it was a hard lock enough that you were unable to break = into >>> ddb? Without more information, it will be impossible for me to = debug >>> this. >>=20 >> Yep. I CC'd you mostly so if if any other similar reports >> came in that you would know of my context's prior failure. >=20 > Yeah, I haven't heard of any, (though I've only worked on it for less > than a year)... >=20 >> I am working on seeing if I can get Firewire/dcons to operate >> in hopes of getting some information about the crash. If >> I get that going and get some more information, I'll report >> it with you CC'd again. >=20 > Yeah, dcons is a good choice, and the good thing is that short of a > complete system bus crash, you'll be able to at least get the latest > logs off of the system... And . . . I just got the telnet login console going in the telnet/dconschat so I'm no longer restricted to the display's console for all input. I'm not familiar with the Firewire/dcons context, so read a little, try a little, read . . . =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-ppc@freebsd.org Tue Feb 2 00:07:33 2021 Return-Path: Delivered-To: freebsd-ppc@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6DBA34ECC25 for ; Tue, 2 Feb 2021 00:07:33 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic302-22.consmr.mail.gq1.yahoo.com (sonic302-22.consmr.mail.gq1.yahoo.com [98.137.68.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DV4rM72xWz3RHk for ; Tue, 2 Feb 2021 00:07:31 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1612224449; bh=cO0ITSSori5bnVJn+H5WPKepnYQPCa5/7cilsJBjMwl=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=PshxI0FI/DzQ9bSUrx7sxh7ryKtqThNhihm/Q13Jtl0/2lJNf9UNIgKB1zEBx51tRhZDAUbrmfMtIbdBaqBtr3l39JShe0F45/y+9HXc9wtPfc/dQ5sFdwQWg6p99/p3U8mmdMeqPqbKT7OaC4oc0Z8VcFe0fuNa3EeTViU6wLGSX/LvGycSdLgJ79V6xuyeKwJWlpnKDM8PRyYSxZ08Yf0G2BCsUf68DuvAErVrkXVrBrL+NfmQ1p1653x7acFfPlos+1Sl4v69BPXw0wnbMJZKsjIZucZbGyVZXexRu/FPkWwj+fahYb5c3Kgk7fjhApThoPkg6Fl1qL5XwYCsWw== X-YMail-OSG: 101RQ_sVM1lx2e8FqWuD14F_2YAYexGg8K6loB9oMtHadWwc23XjjZufx01klzD by6j2hYLD4QD3H24neMz64Ud05eUEgkbQ8TdIo3TxXkrUnKijwQvr9sN0G6ZcMxRj8GaW_FFbUFW 8pofP0icHpYG5ujvDKT33ljqFnWD3Ycmw8ayKWDecUZjHR41wxUfrWtTB5wPM7F3QWtSCoLlu8iD mB8mt7FH7SIe3EFgJq5GzomU.RvA.u9.KIlqDQ1ML5fE.lrf63GV6GM9rPRtc8wgkgGbszz6fnWb 7ge5MfiB5mPzrsi9FTFFDYgprzUWYxed2MKTAbkAEwnofXNA4UScB1I9Qp5w41zy6Iz7Q63.6yJg OouKznyj4xoE8i3gUFQF_geehMf.CZTrNxHPzMKUZtyBmN4EPx2bZa_sr0PJiVHxoyEoNFfAijXf IoQYVXmYJzwUM0jFex77ezx31ebfTwN3ELfkpli8JbWkJcbEPL8cvNXM.j7wrjK2H4ccYaOt4Wyj mIVBePHdrSJu5UsWtkuB4QYl22haFENYEIbVG..87Z.wJbYkNCXiLGh7JRXcX9kLf6KlJzTT.jyx gVHpW8LDQK0YnO71zPTbKsZZ3VU1sioq8mmQDgVysNasMZxm.tZltB239H8IEQIILReUCgiVmO_d ryGFMw1fxz96VS0TlQsAWZPceOemdAisPEj0W8PfAfISUiWko40LVrC4W05p4ubfrAYTbxJlb9v7 J2EKfIFPre5Yc0KHqdgDKg_N6J11ePKNns1Th5Qjws2K0q1USJlmpeNLRB_wb3kA3weVBitxY71L Ee3im6BGNTAxZ3WTFVw7fKh.vWhoCW2zdeJzCqr1WN6NykU2xLSyBahbKrBG9X5iBXRDepOyUXhi doMxpzxC.JrTnNcfc1G2IyKKUc4BDqNaj.9HRBUu4__7ty6.DEzM_8FV4l57KxsRUm9w1EESPMh8 QkO5mAEFnM_a4942aWpv3TpM.LgpUOsHXjOeEu5MhGnzbyI08XjTWOZqo4Kd_9yOXqBnuIpOc0.s scwmeMlAWcBcOfbh8EF0gGxJ3GSNCOH9vueY9nm7XsSCyFsMuFSs55Qb3Q.l5MQ1Fg9W2IHFLUrC WWRbpEBdAeUUBHB8D5kuONj9ycwfdJqB4QARVoMJEMyYUIBqG.nA6njOjHRbDlskySDRKLLwFWmy foViXJlLEMy0TVIu6hzKCS1esriqZUhJUNddraF7yboQGjgQiiSEtBSQvj5GqVxanbBbBjX3aE44 6nULT3ChR8j9EfkZ0.AuNYkMCUVhmIQuqf2TBFIS3d33KxhDsXcRuyO6X52upbZr25Krth5ZYwZW 0nWhwbfVryZzpQM6sGRI3JqTAKnB8kqHq7Kp1Ahr6Gk28VuYUfzasacGjbl7X6Kiir8HFLjGThzl fn40QQBx1tj52LY2rLupqhPODc.KNO_SYvXHzNdW8uzlnRfc99knjoGewaVBVKAAaIEjE1pWVOmy YJLhBsE4eG8JL44_rAyYcsWp77qaGk5FfNrK2beM4tTR.PFL2lDgK1g5ZGBEt_9LCihn6DElXI6G i6GgjAoCqwcbOLmqlm95rwmFf7O4uKIbKe9x.M59coxPR9ZOhXcIfOiAZ4oICp1DhhNoWWZiXMlb OHdzg84fhAQu4DqCngybcxj8hDhWSbJkmDaw4BxMBHCPkq7IGOBwlvC3twW00J0qiVt0hL2DaYiL Sy6L2F3_iql_kFqFXUb0YNW2zIaVoPD10Izgm5VkkMNCbSgERkoa47ViIzJGvxLHm6.N9EpBwlMu XGoVqvhrFBAlc.b.lxSeU4CinzrGQlBH3Rl67fiFCi1C92bQJWvT.PNDDT3D1KJOmaXDknViNipL 8hSySYHMT6w2CvUH5c8MNydAntXDev8n31fNUwjqrfQ.UdiFl0dE962oObLRalw5G2ufwfLUPnd6 l0_YssNhtSyH3ek8yMR_vO8BmFJ6SZIP_r0RWTvJXL2tl6rQdIRrS9HnUpiFYw8wzk5NI8r71O8v HdmaSgf5ISOYibuAKNe.g2iI.nj0ky7dIJwyORlYIOOV7RTYnT2Y09mcJDOJ2fgHubJLoAwlod2O QgY4iY8SiHslKrq800Z..w3628m4f2KczaQ8As6nFp6EUQ_G2twK2XlKtDNfGi3iHQHEs0A1nyig 82ZmOQxBrwcDykrGywsUe.KV.2wLQBZBo6A4DkvFmuPFZyq1Mv7kc4TcREe4dsNIyNK1RkCg.MH8 DEJEGnxbeV0Bb5ccxzEXhqls2lG8gG3ouPZSiKxy3jxRne26KDj5qilqWzxR4b4pePuVxLYi4AMl ogB5NBniY9TLCkHcyzO37JPYtzQt0Rb39w8k5fLF20jKggTNtv6hZWlL1UzTI0hQX43HXMPxEIsN Q4DJrsOUNeGJcdiZV3I3Y_evXHGBRs6x9h_20GmiTDbNkwqK9ljkaOJvyA9kqw7t9hA1lbFlMBSF ZByg49xdQfBw29H.loKu7e49bw1yRgwjdgnJCQwcWMiNhP8Ya2lUNU3KAu40JhsZ5dI2TaZHDwJN ZZnyOubJx5axNDlWToxpRTtelyQ-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.gq1.yahoo.com with HTTP; Tue, 2 Feb 2021 00:07:29 +0000 Received: by smtp418.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID c01ab3d3e38cf0f7dea1f63dd6e1091b; Tue, 02 Feb 2021 00:07:27 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Subject: Re: Expected issue? Old PowerMac G5 [...] vs. USB [...] [RealTek EtherNet] devices (...) From: Mark Millard In-Reply-To: <20210201234225.GX31099@funkthat.com> Date: Mon, 1 Feb 2021 16:07:26 -0800 Cc: freebsd-ppc Content-Transfer-Encoding: quoted-printable Message-Id: References: <20210201194702.GU31099@funkthat.com> <1C53A656-75ED-4E7C-9FB0-6C605BCDEC14@yahoo.com> <0382C932-2BFB-4A5A-9ABD-B4AC2C0AC2BF@yahoo.com> <20210201234225.GX31099@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4DV4rM72xWz3RHk X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; 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/20, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.68.148:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.68.148:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.148:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.148:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-ppc] X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2021 00:07:33 -0000 On 2021-Feb-1, at 15:42, John-Mark Gurney wrote: > Mark Millard wrote this message on Mon, Feb 01, 2021 at 14:57 -0800: >> On 2021-Feb-1, at 13:34, Mark Millard wrote: >>=20 >>> On 2021-Feb-1, at 11:47, John-Mark Gurney = wrote: >>>=20 >>>> Mark Millard wrote this message on Sun, Jan 31, 2021 at 13:45 = -0800: >>>>> . . . >>>=20 >>> I'm working on seeing if I can get Firewire/dcons based >>> access going in hopes of getting more evidence that way. >>>=20 >>> I hope that such can be done via a 32-bit PowerMac G4 >>> against the 64-bit PowerMac G5: it looks like the only >>> other G5 no longer can reliably boot (overheating that >>> fast now). >>=20 >> I see that I had forgotten to say that the initial >> report was based on a non-debug kernel build's >> behavior. Sorry. >>=20 >> The debug build with dcons and such built in does give >> more context and allows me to copy/paste the output. >> and allows me to type at the console. >>=20 >> Booting, logging in, and then plugging in the ure >> results in: >>=20 >> ugen4.2: at usbus4 >> ure0 numa-domain 0 on uhub4 >> ure0: on usbus4 >> panic: lock (sleep mutex) ure0 not locked @ = /usr/fbsd/mm-src/sys/dev/usb/usb_request.c:459 >> cpuid =3D 1 >> time =3D 1612216507 >> KDB: stack backtrace: >> 0xc0080000c200df70: at kdb_backtrace+0x60 >> 0xc0080000c200e080: at vpanic+0x1e0 >> 0xc0080000c200e130: at panic+0x40 >> 0xc0080000c200e160: at witness_unlock+0x18c >> 0xc0080000c200e1f0: at __mtx_unlock_flags+0x70 >> 0xc0080000c200e280: at usbd_do_request_flags+0x170 >=20 > This attempted to unload the lock, but somehow, was released = already... >=20 >> 0xc0080000c200e3c0: at usbd_do_request_proc+0x98 >> 0xc0080000c200e430: at ure_miibus_readreg+0x22c >> 0xc0080000c200e4b0: at mii_attach+0x490 >> 0xc0080000c200e5a0: at ure_attach_post_sub+0x21c >> 0xc0080000c200e660: at ue_attach_post_task+0x188 >=20 > lock is dropped here to call _post_sub >=20 >> 0xc0080000c200e760: at usb_process+0x170 >=20 > lock is aquired and held in this function. >=20 >> 0xc0080000c200e820: at fork_exit+0xc4 >> 0xc0080000c200e8c0: at fork_trampoline+0x18 >> 0xc0080000c200e8f0: at -0x4 >> KDB: enter: panic >> [ thread pid 15 tid 100146 ] >> Stopped at kdb_enter+0x78: ori r0, r0, 0x0 >> db:0:kdb.enter.default>=20 >>=20 >> It looks to be that the complaint is from the code: >>=20 >> usb_error_t >> usbd_do_request_flags(struct usb_device *udev, struct mtx *mtx, >> struct usb_device_request *req, void *data, uint16_t flags, >> uint16_t *actlen, usb_timeout_t timeout) >> . . . >> #if (USB_HAVE_USER_IO =3D=3D 0) >> if (flags & USB_USER_DATA_PTR) >> return (USB_ERR_INVAL); >> #endif >> if ((mtx !=3D NULL) && (mtx !=3D &Giant)) { >> USB_MTX_UNLOCK(mtx); >> USB_MTX_ASSERT(mtx, MA_NOTOWNED); >> } >>=20 >> Doing boot, login, plugin with the axge need >> not fail (and typically has not so far): >>=20 >> axge0 numa-domain 0 on uhub4 >> axge0: on usbus4 >> miibus1: numa-domain 0 on axge0 >> rgephy0: PHY 3 on = miibus1 >> rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, = 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT-FDX, 1000baseT-FDX-master, = 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow >> if_delmulti_locked: detaching ifnet instance 0xc000000013450000 >> if_delmulti_locked: detaching ifnet instance 0xc000000013450000 >>=20 >> With the axge already plugged in at power up it generally >> works as well, at least for the debug kernel: >>=20 >> axge0 numa-domain 0 on uhub4 >> axge0: on usbus4 >> miibus1: numa-domain 0 on axge0 >> rgephy0: PHY 3 on = miibus1 >> rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, = 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT-FDX, 1000baseT-FDX-master, = 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow >> ue0: on axge0 >> ue0: Ethernet address: ### >> ue0: link state changed to DOWN >> ue0: link state changed to UP >> if_delmulti_locked: detaching ifnet instance 0xc000000013030000 >>=20 >> Similarly, the ure already plugged in can work: >>=20 >> ure0 numa-domain 0 on uhub4 >> ure0: on usbus4 >> miibus1: numa-domain 0 on ure0 >> rgephy0: PHY 0 on miibus1 >> rgephy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, = 1000baseT-FDX, 1000baseT-FDX-master, auto >> ue0: on ure0 >> ue0: Ethernet address: ### >> ue0: link state changed to DOWN >> ue0: link state changed to UP >> if_delmulti_locked: detaching ifnet instance 0xc0000000130d6800 >>=20 >> An interesting point about the "it happens to >> work this time" example is that ure0 is working >> without use of hw.usb.xhci.use_polling=3D1 , >> unlike back during the summer's experiments. >>=20 >> However, I did get one failure with the axge(!) (for >> an already plugged in at power up context) that I've >> only got a digital camera picture of but it looks >> just like the earlier ure backtrace in structure, >> but saying axge instead of ure and having different >> offsets in those routines: >>=20 >> axge_miibus_readreg+0x124 >> . . . >> axge_attach_post_sub+0x15c >>=20 >> The detailed stack addresses are distinct, of course. >> Same pid but different tid, as well. >>=20 >> So it does possibly suggest that ure and axge share >> a problem, such as lack of initialization but mixes >> of lucky and unlucky values showing up. (But I've >> no more specific evidence that such is a reasonable >> summary of what is happening.) >=20 > I really don't have time to look into this right now.. Okay. Thanks for letting me know. > It does look > like the locking around mii and usb ethernet isn't correct, per above, > where a lock is dropped, but never reaquired... At least in the failing cases. Still leaves the working cases to also explain. Same devices, same PowerMac G5, same FreeBSD build, yet variability in if the lock appears as reacquired vs. not. > The problem is that the functions and how locking is handled is > undocumented (or I can't find the docs in my brief looking, as > functions like usbd_do_request_flags have a man page, but aren't > documented by said man page, where as usbd_do_request_proc is > undocumented)... >=20 > Someone else who works on the USB ethernet framework should take a > look at this issue, but I'm not sure who is currently working and > maintaining it right now... I'll work with them on testing any ure > changes needed to match the locking process... I've no clue who might be interested. May be this note should be forwarded to some other list? > I must be missing something as to why it's working on non-ppc systems, > but failing on ppc systems... >=20 The only thing I can think of that might suggest the variability is that powerpc64 (and 32-bit powerpc) have a somewhat weaker memory model than most processor families and this is a 2-socket/1-core-each powerpc64 context. Such might contribute to the variability for both ure and axge if the memory model is not being fully handled. (Internal race(s) across cpus.) I've no access to other powerpc64 contexts, just the old PowerMac. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-ppc@freebsd.org Mon Feb 1 22:28:58 2021 Return-Path: Delivered-To: freebsd-ppc@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 25C1B4E975A for ; Mon, 1 Feb 2021 22:28:58 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DV2fd2W0Bz3LMJ for ; Mon, 1 Feb 2021 22:28:56 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id 111MSt02092710 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 1 Feb 2021 14:28:55 -0800 (PST) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id 111MSsME092709; Mon, 1 Feb 2021 14:28:54 -0800 (PST) (envelope-from jmg) Date: Mon, 1 Feb 2021 14:28:54 -0800 From: John-Mark Gurney To: Mark Millard Cc: freebsd-ppc Subject: Re: Expected issue? Old PowerMac G5 [...] vs. USB [...] [RealTek EtherNet] devices (...) Message-ID: <20210201222854.GV31099@funkthat.com> Mail-Followup-To: Mark Millard , freebsd-ppc References: <20210201194702.GU31099@funkthat.com> <1C53A656-75ED-4E7C-9FB0-6C605BCDEC14@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1C53A656-75ED-4E7C-9FB0-6C605BCDEC14@yahoo.com> X-Operating-System: FreeBSD 11.3-STABLE amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Mon, 01 Feb 2021 14:28:55 -0800 (PST) X-Rspamd-Queue-Id: 4DV2fd2W0Bz3LMJ X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of jmg@gold.funkthat.com has no SPF policy when checking 208.87.223.18) smtp.mailfrom=jmg@gold.funkthat.com X-Spamd-Result: default: False [-1.80 / 15.00]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_TO(0.00)[yahoo.com]; FORGED_SENDER(0.30)[jmg@funkthat.com,jmg@gold.funkthat.com]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[208.87.223.18:from]; ASN(0.00)[asn:32354, ipnet:208.87.216.0/21, country:US]; R_DKIM_NA(0.00)[]; FROM_NEQ_ENVFROM(0.00)[jmg@funkthat.com,jmg@gold.funkthat.com]; SUBJECT_HAS_QUESTION(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[jmg]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[funkthat.com]; AUTH_NA(1.00)[]; SPAMHAUS_ZRD(0.00)[208.87.223.18:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-ppc] X-Mailman-Approved-At: Tue, 02 Feb 2021 06:26:51 +0000 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2021 22:28:58 -0000 Mark Millard wrote this message on Mon, Feb 01, 2021 at 13:34 -0800: > On 2021-Feb-1, at 11:47, John-Mark Gurney wrote: > > > Mark Millard wrote this message on Sun, Jan 31, 2021 at 13:45 -0800: > >> [I provide some older context before the new material.] > >> > >> On 2020-Jul-27, at 19:47, Mark Millard wrote: > >> > >>> Context: head -r363590 based context, non-debug build. > >>> > >>> Using a couple of USB EtherNet devices (with different > >>> chip set families from different companies), I get > >>> the like of: > >>> > >>> usb_alloc_device: set address 2 failed (USB_ERR_TIMEOUT, ignored) > >>> usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT > >>> usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) > >>> usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT > >>> usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) > >>> usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT > >>> usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) > >>> usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT > >>> usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) > >>> usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT > >>> ugen2.2: at usbus2 (disconnected) > >>> uhub_reattach_port: could not allocate new device > >>> > >>> when I plug in the device. The one way I've found to avoid that > >>> is to boot using: > >>> > >>> hw.usb.xhci.use_polling=1 > >>> > >>> but this appears to have large performance consequences for > >>> receiving data over the device. > >>> > >>> (The only reason I've tried this on a PowerMac G5 is as a test > >>> for a Realtek driver update that John-Mark Gurney has produced > >>> and requested testing of: PowerPC is the only Big Endian type > >>> of context that I have access to. Going the other way, the only > >>> powerpc families that I have access to are in old PowerMacs. > >>> The above is not limited to Realtek chipsets.) > >>> > >>> With the forced polling I get (for the device I originally > >>> intended to test with): > >>> > >>> ugen2.2: at usbus2 > >>> ure0 numa-domain 0 on uhub2 > >>> ure0: on usbus2 > >>> miibus2: numa-domain 0 on ure0 > >>> rgephy0: PHY 0 on miibus2 > >>> rgephy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto > >>> ue0: on ure0 > >>> ue0: Ethernet address: ### > >>> ue0: link state changed to DOWN > >>> > >>> and: > >>> > >>> ue0: flags=8843 metric 0 mtu 1500 > >>> options=68009b > >>> ether ### > >>> inet 192.168.1.149 netmask 0xffffff00 broadcast 192.168.1.255 > >>> media: Ethernet autoselect (1000baseT ) > >>> status: active > >>> nd6 options=29 > >>> > >>> I will note that the USB device is USB3 capable but supports > >>> use on USB2 as well. This was also true of the other device > >>> that I tried that had a different chip set. > >>> > >>> > >>> I do not know if some other types of USB devices also have > >>> such problems on old PowerMacs (or powerpc64 more generally). > >> > >> Newer context: Both old 2-socke-t/2-cores-each PowerMac G5s > >> now suffer Heat Deaths when used for much. So this is tied > >> to attempting to switch to another variant of the G5s that > >> happens to be accessible. But I think the end result is > >> reporting a new problem. > >> > >> Well, I tried using the 2-socket/1-core-each PowerMac G5 but > >> discovered that its gem0 gets regular device timeouts after > >> a while, making EtherNet useless via gem0. This lead to again > >> looking at using USB based EtherNet on this old PowerMac G5. > >> > >> So I tried plugging one of the RealTek USB ethernet devices, > >> with hw.usb.xhci.use_polling=1 in place at boot. The result > >> was an immediate, slient death in that the console display > >> stopped responding. > >> > >> For reference: > >> > >> # ~/fbsd-based-on-what-freebsd-main.sh > >> merge-base: 3f43ada98c89bce5ae416e203ba0e81595a5cd88 > >> merge-base: CommitDate: 2021-01-29 19:46:24 +0000 > >> e124d7d5fc88 (HEAD -> mm-src) mm-src snapshot for mm's patched build in git context. > >> 3f43ada98c89 (freebsd/main, freebsd/HEAD, pure-src, main) Catch up with 6edfd179c86: mechanically rename IFCAP_NOMAP to IFCAP_MEXTPG. > >> FreeBSD FBSDG5L2 14.0-CURRENT FreeBSD 14.0-CURRENT mm-src-n244523-e124d7d5fc88 GENERIC64vtsc-NODBG powerpc powerpc64 1400003 1400003 > >> > >> I doubt that plugging in a USB "RTL8251/8153 1000BASE-T > >> media interface" should crash the PowerMac G5, but it > >> does, and does so in a way that leaves no access to find > >> evidence with. (I've no serial console for any PowerMac.) > > I'm working on seeing if I can get Firewire/dcons based > access going in hopes of getting more evidence that way. > > I hope that such can be done via a 32-bit PowerMac G4 > against the 64-bit PowerMac G5: it looks like the only > other G5 no longer can reliably boot (overheating that > fast now). I think that it should just work.. I haven't looked at the dcons code, but IIRC, it should... If not, it should be easy to fix to make it work.. > >> So I tried a non-RealTek USB3 capable EtherNet device, both > >> with and without hw.usb.xhci.use_polling=1 : > >> > >> axge0 numa-domain 0 on uhub4 > >> axge0: on usbus4 > >> miibus1: numa-domain 0 on axge0 > >> rgephy0: PHY 3 on miibus1 > >> rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow > >> ue0: on axge0 > >> ue0: Ethernet address: 00:05:1b:af:1a:21 > >> ue0: link state changed to DOWN > >> ue0: link state changed to UP > >> > >> So far it seems to be working just fine. I'm using it > >> without hw.usb.xhci.use_polling=1 . > > > > Is the axge a USB3 or USB3 device? The driver attached to both... > > The axge, like all my USB Ethernet devices, is USB3 capable but > is supposed to support use in USB2 contexts. The PowerMac, of > course, is old and only has USB2. Then why bother w/ xhci? Since that should apply only to USB3 controllers... If your mac isn't USB3 compatible, shouldn't be detected/probed/used, and you should only have ehci... This is why I was puzzled, tweaking xhci implies that the system is USB3 capable... (if xhci changes USB2 behavior, then it needs to be renamed)... > > [...] > > > >> So the crash appears to be RealTek-device specific in some > >> way, not some sort of generic USB EtherNet problem. > > > > My guess is that there's a USB3 issue.. Because an endianness > > issue in the driver would cause it to not attach or misbehave, it should > > not cause a hard lock.. > > Both the axge and the ure are USB3 capable devices that are supposed > to support use in USB2 contexts. The axge works but the ure leads to > the crash. Have you verified that it works w/ other operating systems on the Mac? Could it be that the device itself isn't compatible w/ the USB2 controller on the mac? Have you tried to add in a USB controller card and use that instead of the onboard USB controller? > > I assume it was a hard lock enough that you were unable to break into > > ddb? Without more information, it will be impossible for me to debug > > this. > > Yep. I CC'd you mostly so if if any other similar reports > came in that you would know of my context's prior failure. Yeah, I haven't heard of any, (though I've only worked on it for less than a year)... > I am working on seeing if I can get Firewire/dcons to operate > in hopes of getting some information about the crash. If > I get that going and get some more information, I'll report > it with you CC'd again. Yeah, dcons is a good choice, and the good thing is that short of a complete system bus crash, you'll be able to at least get the latest logs off of the system... > >> I've no clue if the gem0 issue is HW, SW, or some mix, but > >> its failure is not as big of a deal as crashing just from > >> plugging in a USB device. > >> > >> > >> Note: The G5 is doing a poudriere-based build that may take it > >> days, with llvm building yet to start. I have 2 ssh sessions > >> going, one session is running my variant of top and the other > >> is running poudriere(-devel). > > The poudriere build finished but it was building 32-bit powerpc > ports for FreeBSD:14. I've still got FreeBSD:13 ports for > 64-bit. If I end up needing a FreeBSD:14 gdb/kgdb I'll end up > needing to do another round of port builds since no build > for powerpc64 is running according to pkg-status.freebsd.org . > The last build that completed normally was for FreeBSD:13 . +1 -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-ppc@freebsd.org Mon Feb 1 23:42:28 2021 Return-Path: Delivered-To: freebsd-ppc@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id DB2044EBF88 for ; Mon, 1 Feb 2021 23:42:28 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DV4HS0XhSz3Q0r for ; Mon, 1 Feb 2021 23:42:27 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id 111NgPXj095705 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 1 Feb 2021 15:42:25 -0800 (PST) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id 111NgPuY095704; Mon, 1 Feb 2021 15:42:25 -0800 (PST) (envelope-from jmg) Date: Mon, 1 Feb 2021 15:42:25 -0800 From: John-Mark Gurney To: Mark Millard Cc: freebsd-ppc Subject: Re: Expected issue? Old PowerMac G5 [...] vs. USB [...] [RealTek EtherNet] devices (...) Message-ID: <20210201234225.GX31099@funkthat.com> Mail-Followup-To: Mark Millard , freebsd-ppc References: <20210201194702.GU31099@funkthat.com> <1C53A656-75ED-4E7C-9FB0-6C605BCDEC14@yahoo.com> <0382C932-2BFB-4A5A-9ABD-B4AC2C0AC2BF@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0382C932-2BFB-4A5A-9ABD-B4AC2C0AC2BF@yahoo.com> X-Operating-System: FreeBSD 11.3-STABLE amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Mon, 01 Feb 2021 15:42:25 -0800 (PST) X-Rspamd-Queue-Id: 4DV4HS0XhSz3Q0r X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of jmg@gold.funkthat.com has no SPF policy when checking 208.87.223.18) smtp.mailfrom=jmg@gold.funkthat.com X-Spamd-Result: default: False [-1.80 / 15.00]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_TO(0.00)[yahoo.com]; FORGED_SENDER(0.30)[jmg@funkthat.com,jmg@gold.funkthat.com]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[208.87.223.18:from]; ASN(0.00)[asn:32354, ipnet:208.87.216.0/21, country:US]; FROM_NEQ_ENVFROM(0.00)[jmg@funkthat.com,jmg@gold.funkthat.com]; SUBJECT_HAS_QUESTION(0.00)[]; R_DKIM_NA(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[jmg]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[funkthat.com]; AUTH_NA(1.00)[]; SPAMHAUS_ZRD(0.00)[208.87.223.18:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-ppc] X-Mailman-Approved-At: Tue, 02 Feb 2021 06:35:21 +0000 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2021 23:42:28 -0000 Mark Millard wrote this message on Mon, Feb 01, 2021 at 14:57 -0800: > On 2021-Feb-1, at 13:34, Mark Millard wrote: > > > On 2021-Feb-1, at 11:47, John-Mark Gurney wrote: > > > >> Mark Millard wrote this message on Sun, Jan 31, 2021 at 13:45 -0800: > >>> . . . > > > > I'm working on seeing if I can get Firewire/dcons based > > access going in hopes of getting more evidence that way. > > > > I hope that such can be done via a 32-bit PowerMac G4 > > against the 64-bit PowerMac G5: it looks like the only > > other G5 no longer can reliably boot (overheating that > > fast now). > > I see that I had forgotten to say that the initial > report was based on a non-debug kernel build's > behavior. Sorry. > > The debug build with dcons and such built in does give > more context and allows me to copy/paste the output. > and allows me to type at the console. > > Booting, logging in, and then plugging in the ure > results in: > > ugen4.2: at usbus4 > ure0 numa-domain 0 on uhub4 > ure0: on usbus4 > panic: lock (sleep mutex) ure0 not locked @ /usr/fbsd/mm-src/sys/dev/usb/usb_request.c:459 > cpuid = 1 > time = 1612216507 > KDB: stack backtrace: > 0xc0080000c200df70: at kdb_backtrace+0x60 > 0xc0080000c200e080: at vpanic+0x1e0 > 0xc0080000c200e130: at panic+0x40 > 0xc0080000c200e160: at witness_unlock+0x18c > 0xc0080000c200e1f0: at __mtx_unlock_flags+0x70 > 0xc0080000c200e280: at usbd_do_request_flags+0x170 This attempted to unload the lock, but somehow, was released already... > 0xc0080000c200e3c0: at usbd_do_request_proc+0x98 > 0xc0080000c200e430: at ure_miibus_readreg+0x22c > 0xc0080000c200e4b0: at mii_attach+0x490 > 0xc0080000c200e5a0: at ure_attach_post_sub+0x21c > 0xc0080000c200e660: at ue_attach_post_task+0x188 lock is dropped here to call _post_sub > 0xc0080000c200e760: at usb_process+0x170 lock is aquired and held in this function. > 0xc0080000c200e820: at fork_exit+0xc4 > 0xc0080000c200e8c0: at fork_trampoline+0x18 > 0xc0080000c200e8f0: at -0x4 > KDB: enter: panic > [ thread pid 15 tid 100146 ] > Stopped at kdb_enter+0x78: ori r0, r0, 0x0 > db:0:kdb.enter.default> > > It looks to be that the complaint is from the code: > > usb_error_t > usbd_do_request_flags(struct usb_device *udev, struct mtx *mtx, > struct usb_device_request *req, void *data, uint16_t flags, > uint16_t *actlen, usb_timeout_t timeout) > . . . > #if (USB_HAVE_USER_IO == 0) > if (flags & USB_USER_DATA_PTR) > return (USB_ERR_INVAL); > #endif > if ((mtx != NULL) && (mtx != &Giant)) { > USB_MTX_UNLOCK(mtx); > USB_MTX_ASSERT(mtx, MA_NOTOWNED); > } > > Doing boot, login, plugin with the axge need > not fail (and typically has not so far): > > axge0 numa-domain 0 on uhub4 > axge0: on usbus4 > miibus1: numa-domain 0 on axge0 > rgephy0: PHY 3 on miibus1 > rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow > if_delmulti_locked: detaching ifnet instance 0xc000000013450000 > if_delmulti_locked: detaching ifnet instance 0xc000000013450000 > > With the axge already plugged in at power up it generally > works as well, at least for the debug kernel: > > axge0 numa-domain 0 on uhub4 > axge0: on usbus4 > miibus1: numa-domain 0 on axge0 > rgephy0: PHY 3 on miibus1 > rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow > ue0: on axge0 > ue0: Ethernet address: ### > ue0: link state changed to DOWN > ue0: link state changed to UP > if_delmulti_locked: detaching ifnet instance 0xc000000013030000 > > Similarly, the ure already plugged in can work: > > ure0 numa-domain 0 on uhub4 > ure0: on usbus4 > miibus1: numa-domain 0 on ure0 > rgephy0: PHY 0 on miibus1 > rgephy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto > ue0: on ure0 > ue0: Ethernet address: ### > ue0: link state changed to DOWN > ue0: link state changed to UP > if_delmulti_locked: detaching ifnet instance 0xc0000000130d6800 > > An interesting point about the "it happens to > work this time" example is that ure0 is working > without use of hw.usb.xhci.use_polling=1 , > unlike back during the summer's experiments. > > However, I did get one failure with the axge(!) (for > an already plugged in at power up context) that I've > only got a digital camera picture of but it looks > just like the earlier ure backtrace in structure, > but saying axge instead of ure and having different > offsets in those routines: > > axge_miibus_readreg+0x124 > . . . > axge_attach_post_sub+0x15c > > The detailed stack addresses are distinct, of course. > Same pid but different tid, as well. > > So it does possibly suggest that ure and axge share > a problem, such as lack of initialization but mixes > of lucky and unlucky values showing up. (But I've > no more specific evidence that such is a reasonable > summary of what is happening.) I really don't have time to look into this right now.. It does look like the locking around mii and usb ethernet isn't correct, per above, where a lock is dropped, but never reaquired... The problem is that the functions and how locking is handled is undocumented (or I can't find the docs in my brief looking, as functions like usbd_do_request_flags have a man page, but aren't documented by said man page, where as usbd_do_request_proc is undocumented)... Someone else who works on the USB ethernet framework should take a look at this issue, but I'm not sure who is currently working and maintaining it right now... I'll work with them on testing any ure changes needed to match the locking process... I must be missing something as to why it's working on non-ppc systems, but failing on ppc systems... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-ppc@freebsd.org Tue Feb 2 08:50:36 2021 Return-Path: Delivered-To: freebsd-ppc@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id EF91052A30E for ; Tue, 2 Feb 2021 08:50:35 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic302-20.consmr.mail.gq1.yahoo.com (sonic302-20.consmr.mail.gq1.yahoo.com [98.137.68.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 4DVJRh5Lr2z4h1J for ; Tue, 2 Feb 2021 08:50:24 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1612255820; bh=sR7OiyYJAtDKDxuJqyFzJI1O6dXJpfHDsfUW5I//lHq=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=ndrX4NJHShORFixsaaT+CIIzFlsni+m/Ul84N5w7aQSRcoTutGX/czdkm4uT6EdX9w3jV5ROErN7KxqroXze3gBFS7Qr8okprK0lDmKr7MhOpH/8GcnvfOBQFUbYkZQ0buQ0j5qJLpK4OT5eTuVg3KGTB24X6CueFOSCgnMaU5Yoa9URNNG3AkpCqUFcnpYOXQ+/1UtB+cLb8EtOyDb7JXt5y7u+pwQEkcUK6YzldYt8FnWKeSopvSP8WLTGDeVlU5/dzzgKzgxGUXLvmZ1RpL+fSDbWieA5nQLcd8ofizy7kPpS2k2tybiNgEWAbk6mxIpXYEXkB+zkLLlqubC+0w== X-YMail-OSG: s7mPGSoVM1kpmdkhbCOfjo5NWqcFWMTIANLF3C4JISn7sdRFPvqhsCzFyd2EeGu VpR7HYkcxbJXLQbROtuJcUUhyTxJZZs.Qy_g9pS9rBnQ4a2DQUQaVPzPXo4DePIXVElNnEbruuNK a9WdNafr4W3lraj.9jDvBNEaa0TB.lnR0I8hpynlx2CnMfMCoQ0g_8oB2YP2l5uTKHVJSXu6_nha NBTGP9v057eSVYy6jvmuvY4Zol6LwDFO2W3JT6A84CltATUV4S.tlUG_11BfjLJ9BEKMgu45geY1 KUHa14bMhikAHHqCATdYC08G9C1Rg_ea.L1doevv33ISnDN8oZv1McXQ3cYYF818jlbLklTHPWxM hZBhJjPX7kFkLMZUKMVFx.GKz5ndrdjpx4vsy9hatfH19QK7fAfio9YcaR8UyCNPmMwAq26kFwzs hr.vKoqik95DMKQj.mcvUEvgZtXyxJF_EtMS377_brw8K9h_3pi.IPwedwTlqFIEO8z5kDK_IJMm z2Z3eMgeQ4jg6oGueYAHv17rTWhmQQkZoydxdUA8s92iqtzm7ikjXvueKcazEh.4c3WflAaJ3YBD XEf.NYF3XH7GZm8vnR27HrKyjS7LTA3m72UlFNKFqc8XwmM_2cSMi6gVPzN0.RnOskn05.GLjP1S 19i5i_xJnkozB3fciPmSuxVcOD1SUhzo2T8rPx9nlCBqpJYBmkc2rOi731wcwt2R8JARno0X5NUJ FDayju0RsgkGgRQb0E_Sa6hwTldfhHi_JEmR6lB5HGKSe0Q8rkZzOMXjBy45uNk8JjAKI1mFPJ.2 VmL27LXw2ZRz_ZTqOi.Oyooqg4IGB.18vLW3AIiPByLq3L_7_14xGVgZCVF4xe5rHFO4ihns96Bi .QHmhh9LQtfTiC58F8x5nNXQXD8j_pxP9z618GF7VZkgMa4ceRlU13WCQqz3CWFVTtWh9JrGeL5. QGkfz8r1ohrV_Srq7RdSLBWK5lDeCSfdXEsv_SafF7009N0tGRzeO1PzEMTiLXHOSmSYMNIx33CD 7GOh.F9aSFsdfoOZNnxJIRfbkgB8pU7m0gzTQFrpRE8VjwP5HMn3jeQ0q._3jbymTiGGaSZMZ7_s HDpLmydpO1gdHlxlpZwfzmQs7FVBBdHkAXNGg9oOvr0btrUrNntHhvzcYPxN5QwPHK07QbBHr_IR GdxJVvITP0NcAuJY9a_1PMR8Bzuje3vGmExz0K2Jq3hhDROoxx4.3.4GPGG6XWQdHRvHL0XDWXSX B4JZDc91JULpRo.rCuQDHagGqb9hhq1rl6_nDfoNfPt66SOWt6P4M97KdXIBjnIHOvY0yyT74CRc eIQ1jQLqInDIKSEpixO2cbz9jwp4DzupsOV66P0.G0CY8u5BhJcRIBt8K9Z9w.WX20z5l0CFtEq4 AlCBDnMh3XvPfaW1yMIbr57izfKABJyc8L4AlR1kbPBUMadj0DTCmEnMlP0J7P8Ca_N0u7A6.Vhw rH.Z3jDJnMiwBs.ZBsRUGGrfvpo.u.5rTA_hunPdkOdFrPSlcbHuk953swpWfgnxi6KMPdH4mQBI El3x8.P6cPTsqlVAPa780HnugqP_qHtZ6cdpQFfR4M9sHsfo5q7kY_uj_xPNpNcOSvkAy_IhejKI QnIKno0o.DN1baejyJqd3k6NPhTIbatPQ9JyDZNij_1WLyp6poXXe2Ly4k.xzpdflOnJZ6JAAbx1 GZga0_ZaM8A_7MfjVUD1j2FEEoQ7kI9R.wW_GzDIW8ltK6hkM5PImqRMn1ntFWHNZ96tGxxTrNsR efD15utwobYKPtIQgWYYYLOrAkkPpq2_4YAwg9UN0CmLIL.RzMdqnVXVY0lUsPykGLVG.akZP9Gc YzeVAMph2okPx85AEt1IV0ME1FOyTSj956mYKlAwoM4PE17fyTIRqIRUohO.V40AmRAVkh24.nfR 3hV9QHpANy6zp3nceNMxpTQzuHfhjv.nTsmOwUo97Q6xj5b2BJ_jQiHmKA9Hi9l1c4eH3L_2GRog V0abA39wZDznSOFlcJa.sCcUyRXvfJyIxdxFVDVe22M9FDGlNEuoEN2Z0iYhJOaW_T65g3NkuM2e o26SyxvK_bnjVJK5YifrTWqhprK9N7fgF5HhBycLqu.HNPSfKG32.8IVSqj_v.2ACjCJlFBGUKl2 oZwHfR6BGZg4cDt1jAkcXx5kB4TuJWJctAglTTYrBryhyq0hpaW35__V.DjpP18RP4yZNl1cc2gv P2nsz5eB_6IxEfSqA7tZeD5G2ZQ4e5sxMdOsG40_A0dX9TNp2YyTYPU.E4v1ezknWGAB3Hn6JezZ 90WAWyemVDPOR6eWXEvHZFCETeozcF9zukeqg5PnfjvfRpJ642LIxZsY7cytu93bMXdoEVFHDdRO fwKTnyEGT33sfZi.JW5t3kETf7eU92SMS6H8plkzh1.PBQcSFzYKDdvT5CvpysTzgnOOfJ1Z7Hp_ XuEwANfAo2xwPFyqmN66QkMOF_kpfBxH0o.gNMedVbF6bthM.xCZnFKHUc4QML9oeSOBpQLhdHVk 3Ti7yJPV8t247dWfAxSsHTQ-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.gq1.yahoo.com with HTTP; Tue, 2 Feb 2021 08:50:20 +0000 Received: by smtp408.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID fcc4e390d0f934cdf0a5240f7e6f576c; Tue, 02 Feb 2021 08:50:14 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Subject: Re: Expected issue? Old PowerMac G5 [...] vs. USB [...] [RealTek EtherNet] devices (...) From: Mark Millard In-Reply-To: <20210201222854.GV31099@funkthat.com> Date: Tue, 2 Feb 2021 00:50:12 -0800 Cc: freebsd-ppc Content-Transfer-Encoding: 7bit Message-Id: References: <20210201194702.GU31099@funkthat.com> <1C53A656-75ED-4E7C-9FB0-6C605BCDEC14@yahoo.com> <20210201222854.GV31099@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4DVJRh5Lr2z4h1J X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; 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/20, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.68.146:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.68.146:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.146:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.146:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-ppc] X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2021 08:50:36 -0000 On 2021-Feb-1, at 14:28, John-Mark Gurney wrote: > Mark Millard wrote this message on Mon, Feb 01, 2021 at 13:34 -0800: >> On 2021-Feb-1, at 11:47, John-Mark Gurney wrote: >> >>> Mark Millard wrote this message on Sun, Jan 31, 2021 at 13:45 -0800: >>>> . . . >>>> So far it seems to be working just fine. I'm using it >>>> without hw.usb.xhci.use_polling=1 . >>> >>> Is the axge a USB3 or USB3 device? The driver attached to both... >> >> The axge, like all my USB Ethernet devices, is USB3 capable but >> is supposed to support use in USB2 contexts. The PowerMac, of >> course, is old and only has USB2. > > Then why bother w/ xhci? Since that should apply only to USB3 > controllers... If your mac isn't USB3 compatible, shouldn't be > detected/probed/used, and you should only have ehci... > > This is why I was puzzled, tweaking xhci implies that the system is > USB3 capable... > > (if xhci changes USB2 behavior, then it needs to be renamed)... Given the variability in behavior I'm seeing, I likely mistook an accidental correspondence back during the summer as a "this makes a difference for whatever reason". I had left material around to remind me that I'd used hw.usb.xhci.use_polling=1 back then, but not any detail. Technically I do not have the knowledge of the software structure to rule out its getting to ehci support indirectly. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-ppc@freebsd.org Wed Feb 3 05:23:10 2021 Return-Path: Delivered-To: freebsd-ppc@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7388C52B6CA for ; Wed, 3 Feb 2021 05:23:10 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-25.consmr.mail.ne1.yahoo.com (sonic312-25.consmr.mail.ne1.yahoo.com [66.163.191.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DVqp53Hqbz3MQr for ; Wed, 3 Feb 2021 05:23:09 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1612329787; bh=Ky7RkUOjnOePdTj4qGXf2H7MvX6bAxrDJz8QGKJyUL9=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=S2OtXD53EtLrUv7wbr9fjxRCMQHiYAj2glJjmURkXF/3Vp6EcX8JUJFLdC5XkJQgkn97xQPc5C99EnRDonTO/R1EwOugv2SH03yCCLUJ2swSInFXalamETeAvq/ODXdEqRNV+d5b1J4861YuwxBR2OKr2StgBIdVYVPZDcZsP87OjD8+enOAU3jKRTNcuXmwesIM0459yhZrDVUSQdnqRgbOHx1QZgjlEAw4I9BI4uVJgzx7eCy1rZP8Xe4XEcObYqr2EOQM7qOK2YbBVObHDjBGhhXfYEDVPOdbKYp1AIC3Sw+h17l8TIEZk3v13+VQySECwo6ASu+tkZPhl0viVQ== X-YMail-OSG: Aq8MvxoVM1kxaOI1qFcPwyclm0uU0wERVMr5JM8Bupsvt9fZMAIgP_nxNJeWBDQ jTNFrIxvdkiNBITPch9Wwt10PhEpMmMS3U9YNE9_lplX690pU22gIzEPceGZVkMbIJwG1xZXsNdM EpW7jf1soSNOY2GkR3f2HxwqhNUFdLwJn3Qb.oewJ2baa1TxqYhck_iQ.YSLDvsswdnhYRCMZpDp J44MKGTh989exgudLJQe9sWEYrzxFBXs5HNbSFUjKW8e8iG5alR3Y4rPDdkhAeq._mduH3KB1HWC yJEZ7A99sKySnWlbDDvmy2UP1t6cdlvc5W_Ij6qsqiQMBAzd8V_3rebso48EVgaKpJknD381Uoi4 5hja895.wrqQ6XBOXMHRZivHtZBY.ltkAmrDgxdo.b0a6QOKusyrud8DNpxWM8QopPFePBzGPt9N Pa9tDfqRVY8I5d7wn3NoqmMA4wU0rUbXdzr.8f3OmY2iDZQPwYJdZz0HQEMqglZd0cZ0VtOjYpjr vZoAfeO0e2BEYgr7I1dG4l4igMEyLQQWT8tu1.sSeQJKU07yhVnVLCuZ71fo4SUsT1doYhHQfKYM sPE0fGoATHRo4LZGxyiXogY_QVywFSdOHybNr7kUgvoFZSdQGRbZo2u5o3Izaw18qaicW7hZ1Pro p3coijnmbMeIbx_hWccJqrMogS9tEM6Ny13.7lsCkW0nLQvGeG0CTlmDuYUb__dUvx88rNHDBkQ. ugzMMmOYDLGujUymD1tfdOm.PakVh.vmjUnezi3ndQzevQ2pVv4O_mHq30jCOZQlWvV5chpVlNfJ ySjVcxmmToYhCvyfdBlo24t547UNUB1sOLq.0YU9fzSAGzRVAE4oZUyiSIqR9YDcSNcd3SI2PakN JCLKqYMVIZjcoustHT5h4W6x7cO3_allKvNAtRudZasYyh1pzCgnbObOdLj6zoO__dXifYTEMTOb 2pW9P3O4RQtqtbOHiJebYu2dYzbs1c.izopqCUVJwMTWOhSb3X00BhX22VBxtAfnzPH6MkEDSMzX zIlCpJbhEbNcakpjIrHfEwjBrL3TYyFF5ezM78Ef0WKXCB5yz4A41JyFNBdvSt2tRN.G2G4XZCPX JBWngoq.EiZCHSWhvVe5Awk9F3MUXTLff1KldRrKPl7wayB0DPllsLE2WzchiFsqxYOE.J.cQek9 MkIWp9L.xKyAE0uZK6aoehnLZ5Jz44pnIzTB3h0vb9JuoOexOJcMujLf4MgXVvkg0l.sIYEbfV74 d5xOaXByughR0vnDEL5T6te3fVYSkKxiu_3dG4ZRaL48zQDLTD2BaMzqujfjmY.DzMTMDwez3LKq bu6hoIgLz3N8iJEhdgw8VN5MlD1Sh7mBeVP4NKCMYr0rmV3_dUxUdPLZdH0eVNhwG3ivdsLMeYFQ JHTHDMUO.ny8sYiNzDIX038I.gwvHUxk4.b8EiHD5aWOueyQLy7M_IKAEebPltGK6mjKVewV6g4c .fb8kdBYdQVv.1DbywxGSn8qHcuvlp1kbzNkhdrmLc7S_Ps8l4UM3zIYJDJP.oZ0Ejdy0KK_mM01 yElsBWIeD1XDKwsvl816O0jOj3NQ5bX7LXFtIWwGILsV86KRuLTE4Z39IEtbx7DMQeZEGZWINQA4 glL5ZzygZ73eN0Wd7Sl_tl8W.CDrmHGh3j50ywW6M2aQQ951lAshkXgXCmJSPFyybMNtFmWKm8AR hX9mW_gybewsq3hkwwZc5ycl4higL.XeKJVgRg4Rhu.LymahJilB.IIff0H5r7CdYBpYaKlbteJt cKL6HoUKy._InNu2Q_X_akYSGnwa3EH1rmfTYxhIOH1PKn.wRYI397FzLswkF1CyfbMF9QmvKVI7 nafxz_lScwjnFleZnuCIDrO4GOlJSitxqxLhJDa80590k2qtQCSvvVMqpJmbD17xGKaih9otqS1n cvsaXluWuhK6j4IGA9T9GsfT1zo6VDw10H07Ac00J9hiyUWoq1RQS7OrFiCQaPIH0DHZYpJUvHPA Br7Q6D2exfkG2Qle3eoOoGr7eBtEjQhFaQtbvc.k6xF5XEuOUFRMbSZOGUTx_fl4fXHu6.iGxV1_ EftoX2TGa7SV8270r42eA2sOU.Gnt9erPfgopXFK1K2HZspBkO7Yn0lxBbq9skNI94_9opqT33eu xmxKXX__E54AlllAbi23WAvO1L2yWZYGW29SJkcLBxTq6xnZlFogNkdWwp1Z9RH_L6YXEV2B2Ta3 72fm3kKGdxGqRd.yuUGtJILiQpVJW2gCYwyP9_9AK10Pq3TVnRKaWabg3pqGip47tM.BVDeM.kEM j2MIku8QH1663ZIY5D7Fmo8lEClSQ3XR9NKR3ywkQBF6lu0FhYmFfpuaXGYXZ6Y3JxEf6IG9VBaM a4M7m4vqmeWijEtb9uDsiWbkWdaiSP843hF6RqBO7NsjYFcQgK2E.Z2g8zLPABC.veUl6DT1RUc2 9zd6cAJYZJeQ- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.ne1.yahoo.com with HTTP; Wed, 3 Feb 2021 05:23:07 +0000 Received: by smtp407.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID d44f865d7c077728cd2d262ad72ace00; Wed, 03 Feb 2021 05:23:04 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Subject: Re: Heat-death of the last of the 2-socket/2-cores-each PowerMac G5s that I have access to Date: Tue, 2 Feb 2021 21:23:03 -0800 References: <27E8A3B1-7278-464E-A284-0B294337B3DA@yahoo.com> To: freebsd-ppc In-Reply-To: Message-Id: <330EC96A-6234-4558-A409-3B1BE7768B69@yahoo.com> X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4DVqp53Hqbz3MQr X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.49 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.99)[-0.990]; 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]; RBL_DBL_DONT_QUERY_IPS(0.00)[66.163.191.206:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[66.163.191.206:from:127.0.2.255]; RCVD_IN_DNSWL_NONE(0.00)[66.163.191.206:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[66.163.191.206:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-ppc] X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2021 05:23:10 -0000 On 2021-Jan-11, at 20:38, Mark Millard wrote: > On 2021-Jan-11, at 17:42, Mark Millard wrote: > >> The last of the 4-core PowerMac G5s that I have access to now shuts >> down for "CPU B0 DIODE TEMP" that "exceeds critical temperature >> (90.0 C)" when I try to rebuild/update ports or such. The other >> 4-core G5 failed for such reasons in similar contexts a few months >> ago.,Interestingly, the two G5s have very different liquid cooling >> systems despite the similar time frame for the failures. >> >> Without the faster G5s, I may just use cross-built world/kernel >> material and see if there is a tolerable but minimal set of ports >> for supporting boot testing/dump inspection and basic operation of >> the slower 2-socket/1-core-each and 1-socket/1-core-each PowerMacs >> that I have access to, avoid things like building devel/llvm* >> ports that take so long. (I have fairly strong time preferences.) > > I've done some more testing and, while use as a (full load/speed) > builder machine is a no-go, it looks like this 4-core G5 can > still be used for boot testing and basic operation without > overheating. The prior failing machine overheated more easily > but might have a similar status if I test it just for such use. > > How long the recently failed G5 will be useful for boot and basic > operation testing, I do not know. But probably longer than for > the originally-failing G5. Looks like the problem has progressed quickly, so booting without instead overheating is now unlikely. It does not appear that I'll be able to provide any testing of 2-socket/2-core-each G5 contexts any more. As for the 2-socket/1-core-each G5, care to guess which goes with which machine, G5 vs. Rock64 (Cortex-A53, not RockPro64), allowing as many cpus to be used for the job as the executing machine has (2 vs. 4): [00:15:31] [01] [00:10:57] Finished ports-mgmt/pkg | pkg-1.15.10: Success vs.: [00:12:27] [01] [00:10:35] Finished ports-mgmt/pkg | pkg-1.15.10: Success Yep, the Rock64 configuration that I use takes about the same time to build pkg as the G5 does, although the Rock64 is a little faster than the G5 for that activity. (pkg builds by itself, so there is no competing job in the above.) The RPi4B configuration (Cortex-A72), MACCHIATObin Double Shot configuration (Cortex-A72), and the OverDrive 1000 configuration (Cortex-A57) that I use are all faster than the 2-socket/1-core-each G5 for doing self-hosted, parallel builds. All 3 are faster than the Rock64 for such activity. The OverDrive 1000 is the fastest of these machines at doing parallel builds, apparently largely due to RAM caching differences and other memory subsystem distinctions. (The cpu clock rate is slower than the A72 configurations are using.) (For doing aarch64 and armv7 port builds, I generally build on the OverDrive and the MACCHIATObin. Of the configurations reported on above, the MACCHIATObin one is the 2nd fastest for parallel builds.) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-ppc@freebsd.org Wed Feb 3 19:31:36 2021 Return-Path: Delivered-To: freebsd-ppc@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 583B7529110 for ; Wed, 3 Feb 2021 19:31:36 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DWBd34VDqz3NJl for ; Wed, 3 Feb 2021 19:31:35 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by mail-io1-xd32.google.com with SMTP id f8so578424ion.4 for ; Wed, 03 Feb 2021 11:31:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=bGpe9TqXOomqAKKPLvzoZRvn3160Yhbs4slNx5XNW58=; b=axFGUNSFoEW2x+1p4r3B9WM9lWJ3QmsrfnwQsImWWVHx26JwLnwswKw4m/tYknrpuE kM5HIIYL058lYJCEtyhFSzP/xZev8lX94Za0l0QGzyr5DiZj6udFYWl2tbkqj2gseu5f fCRbYSTivZDtdZPhT39FiV0ruZsIBRMSDXEltaXdOzCiFRaASdhruzg9I3ob5JemFYaP KG8sMdrG5ZALX1YCSWyHvBDJfTK5Zpvxopg2PrbuW/N6JfrID+Bgf7sZ+nhJeuzgJBKH CiPG7nW0x/k7Biz9rM1t7jd2tydwM1+mws3yr5hInB1Lxa6y0Lde7ES42oAKnENQZZH1 1MOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=bGpe9TqXOomqAKKPLvzoZRvn3160Yhbs4slNx5XNW58=; b=jt730r5g+VhKqx/Z9UwqtyaKS6nYi6kkHokeQrK0TQ02RO2xkSMaXM4VOSYLE/fWoY 7i0z9bdgxb8X+SnKEe4FJq07+6Qrr3E+XziyOce7qjZKq62AcCBMh6decEid7l+o8Xo6 6KqtlXe03jfzZuJnbS0ASI5Qckn5bHbiggCariD7tzNJBlgyRR9bWkpv3OWiksk2JgEJ 5LT66vquwrLDWFwWpkPAqA0pJLFAiB2EmQLdj1K4t99z0qHpM1/+HQhAYHulHf/ixlAQ r/mpxSi8arNRLPMUqMAMOucqMQES6UK0Q2NhzDgbcUuBkZQvXq5RadEplZI6vYXN9bIv bUcQ== X-Gm-Message-State: AOAM531P1IBQAsMKyxFl55LqktdkrZb57/KtQ7qkUSEIlwZcIeFeZm0I z0g/ap1OnKhaXVcKu3OXXbKi731GwDwKng== X-Google-Smtp-Source: ABdhPJx9QgFBCRHtkSykzWm4ThhD8wIgBSWsc4qEHvaDfjGzIOhdPW5F4UhtgFxCF7/fWRhXrSXnuA== X-Received: by 2002:a6b:7717:: with SMTP id n23mr3725819iom.73.1612380694828; Wed, 03 Feb 2021 11:31:34 -0800 (PST) Received: from ralga.knownspace (173-19-125-130.client.mchsi.com. [173.19.125.130]) by smtp.gmail.com with ESMTPSA id g9sm1403212ilp.49.2021.02.03.11.31.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Feb 2021 11:31:34 -0800 (PST) Date: Wed, 3 Feb 2021 13:31:22 -0600 From: Justin Hibbits To: =?UTF-8?B?TWljaGHFgiBHw7Nybnk=?= Cc: freebsd-ppc@freebsd.org Subject: Re: Looking for shell access for (minimal) LLDB testing Message-ID: <20210203133122.6518402f@ralga.knownspace> In-Reply-To: References: X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; powerpc64-portbld-freebsd13.0) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4DWBd34VDqz3NJl X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=axFGUNSF; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of chmeeedalf@gmail.com designates 2607:f8b0:4864:20::d32 as permitted sender) smtp.mailfrom=chmeeedalf@gmail.com X-Spamd-Result: default: False [-3.04 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.04)[-0.042]; RECEIVED_SPAMHAUS_PBL(0.00)[173.19.125.130:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[2607:f8b0:4864:20::d32:from]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-ppc@freebsd.org]; SPAMHAUS_ZRD(0.00)[2607:f8b0:4864:20::d32:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::d32:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-ppc] X-Mailman-Approved-At: Thu, 04 Feb 2021 06:22:51 +0000 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2021 19:31:36 -0000 On Mon, 01 Feb 2021 13:16:38 +0100 Micha=C5=82 G=C3=B3rny wrote: > Hello, >=20 > I'm working on modernizing LLDB's FreeBSD support. As a part of that, > I have to port all architecture-specific code to a new process plugin > architecture, and I'd prefer to test that my code actually works ;-). >=20 > Sadly, FWICS FreeBSD doesn't work under qemu-system-ppc [1], and my > attempts seem to confirm that. For this reason I'd like to ask -- > would someone be able to grant me user-privilege shell access to a > machine (or VM) running 32-bit FreeBSD on PowerPC for a few days? >=20 > I probably won't need root access, though rsync(1) installed would be > helpful. I'm going to need around 1G of disk space but I can try to > squeeze in less than that if necessary. All builds are done on my > home machine via a cross-compiler, so I won't be using much CPU or > memory, just some network bandwidth to transfer the data. >=20 > TIA for your help. >=20 > [1] https://wiki.freebsd.org/QemuRecipes#powerpc >=20 Hi Micha=C5=82, I don't have a 32-bit powerpc system available for you to use, but you should be able to run lldb just fine on the FreeBSD powerpc64 Qemu recipe. Do you need a 32-bit kernel, or just 32-bit userland? If you need a 32-bit kernel, I have successfully run FreeBSD on a Book-E qemu, so if you can build a MPC85XX kernel, you can run in that. - Justin From owner-freebsd-ppc@freebsd.org Thu Feb 4 13:24:38 2021 Return-Path: Delivered-To: freebsd-ppc@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 41A2E543164 for ; Thu, 4 Feb 2021 13:24:38 +0000 (UTC) (envelope-from bacon4000@gmail.com) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DWfR93t8gz3rHK for ; Thu, 4 Feb 2021 13:24:37 +0000 (UTC) (envelope-from bacon4000@gmail.com) Received: by mail-qk1-x733.google.com with SMTP id s77so3222002qke.4 for ; Thu, 04 Feb 2021 05:24:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=T2gVwA3nEdHITNZqEuP8g46PAS3b8IEB5QCLJramjGw=; b=P4O8OvuXl1KPUbmTAXEHy3LniQAvTbvvdyguXW6j4hiW5VK6jjHcBoHkCBH5ettb6D Bfi8yC7SO2srb74MD9nLYAlEsAlKSNr36F5WzT1IH9RsWRhmnHU0TgU7yRYzlOyqMWXk xhL4vJCMMm1jDBK0z1fo1/pBLaVUU7+tttj9d68BVtr6EZh57voWds9kKPCcuSgY266q pcqmqyPbCteKIjzRfWWHVnPJyd8kocOtwob2uH1HNreW0WlWixjWUn8R7nHAOsIA/SWr hwp3wfDsMnJSycuqJcQ2EHOYBzhXXqtz0M9ZVIVrlzJq+zHzyGoP1NKNwADxKW5HQE8Z GDmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=T2gVwA3nEdHITNZqEuP8g46PAS3b8IEB5QCLJramjGw=; b=Cp4PeJQJzwnQmWcdn466svUQBlYq7NY3HRD33TzSq2NYTuxn+edqesqjKIi/hIyXZz 7encmldlZQdxbRuZvblhPDvD4UthwkTYFFoai3O+BaarJSfIYoOaAUz9QzZUfeZtZQMu YEhNPYzMgcT7WU6UWoQowAxnduK96Ev7oRcWMYhyBvkzyINKsduJm4xNQZHeX8s4ZBW9 XJ25tjsJV1l1GSd3cSjqJh1x19Gu5r64KchGFbm4q+g4Y8IGUfPI7e9KaRfQQimmb+fz SuSki3/fXDUvdZSBMIfVS0dV98wrduowlqV792H5o9uysdVrrudBkWdPQZZwzYUSSI0h q4rg== X-Gm-Message-State: AOAM531fkmWCc7y0iNNCInpTZ5MoxEnRfGwZ55BqHhQuvWgE5VVMC7Qg Kfef9Ju7cypXOVa0vyxcRdD8gtGXGo2gHA== X-Google-Smtp-Source: ABdhPJx7klR7qt8yJ4McN2O8zj0hS5LQS3yMrPKFhxHKh+3z8KT52e9paOb5lm4cCcEFV3cEhhbnEw== X-Received: by 2002:a37:4d45:: with SMTP id a66mr7568814qkb.12.1612445076184; Thu, 04 Feb 2021 05:24:36 -0800 (PST) Received: from coral.acadix.biz (2603-6000-a401-3a00-0223-24ff-fe37-c4d7.res6.spectrum.com. [2603:6000:a401:3a00:223:24ff:fe37:c4d7]) by smtp.gmail.com with ESMTPSA id r26sm4671085qtu.51.2021.02.04.05.24.35 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 04 Feb 2021 05:24:35 -0800 (PST) Subject: Re: Looking for shell access for (minimal) LLDB testing To: freebsd-ppc@freebsd.org References: <20210203133122.6518402f@ralga.knownspace> From: Jason Bacon Message-ID: Date: Thu, 4 Feb 2021 07:24:18 -0600 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: <20210203133122.6518402f@ralga.knownspace> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Rspamd-Queue-Id: 4DWfR93t8gz3rHK X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=P4O8OvuX; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of bacon4000@gmail.com designates 2607:f8b0:4864:20::733 as permitted sender) smtp.mailfrom=bacon4000@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[2607:f8b0:4864:20::733:from]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-ppc@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[2607:f8b0:4864:20::733:from:127.0.2.255]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::733:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-ppc] X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2021 13:24:38 -0000 On 2/3/21 1:31 PM, Justin Hibbits wrote: > On Mon, 01 Feb 2021 13:16:38 +0100 > Micha=C5=82 G=C3=B3rny wrote: > >> Hello, >> >> I'm working on modernizing LLDB's FreeBSD support. As a part of that,= >> I have to port all architecture-specific code to a new process plugin >> architecture, and I'd prefer to test that my code actually works ;-). >> >> Sadly, FWICS FreeBSD doesn't work under qemu-system-ppc [1], and my >> attempts seem to confirm that. For this reason I'd like to ask -- >> would someone be able to grant me user-privilege shell access to a >> machine (or VM) running 32-bit FreeBSD on PowerPC for a few days? >> >> I probably won't need root access, though rsync(1) installed would be >> helpful. I'm going to need around 1G of disk space but I can try to >> squeeze in less than that if necessary. All builds are done on my >> home machine via a cross-compiler, so I won't be using much CPU or >> memory, just some network bandwidth to transfer the data. >> >> TIA for your help. >> >> [1] https://wiki.freebsd.org/QemuRecipes#powerpc >> > Hi Micha=C5=82, > > I don't have a 32-bit powerpc system available for you to use, but you > should be able to run lldb just fine on the FreeBSD powerpc64 Qemu > recipe. Do you need a 32-bit kernel, or just 32-bit userland? > > If you need a 32-bit kernel, I have successfully run FreeBSD on a > Book-E qemu, so if you can build a MPC85XX kernel, you can run in that.= > > - Justin > _______________________________________________ > freebsd-ppc@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ppc > To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org" I had some trouble with FreeBSD under qemu a while back and the solution = was to specify am older cpu architecture, namely pseries-2.5: #!/bin/sh -e #########################################################################= # #=C2=A0=C2=A0 Script description: #=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Install/boot FreeBSD-powerpc on qem= u # #=C2=A0=C2=A0 History: #=C2=A0=C2=A0 Date=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Name=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Modification #=C2=A0=C2=A0 2018-07-07=C2=A0 Jason Bacon Begin # #=C2=A0=C2=A0 https://wiki.freebsd.org/QemuRecipes #########################################################################= # usage() { =C2=A0=C2=A0=C2=A0 printf "Usage: $0 install|boot disk-image raw|qcow2 [= cd-image]\n" =C2=A0=C2=A0=C2=A0 exit 1 } #########################################################################= # #=C2=A0=C2=A0 Main #########################################################################= # if [ $# -lt 3 ]; then =C2=A0=C2=A0=C2=A0 usage fi cmd=3D$1 diskimage=3D$2 format=3D$3 case $cmd in install) =C2=A0=C2=A0=C2=A0 cdimage=3D$4 =C2=A0=C2=A0=C2=A0 set -x =C2=A0=C2=A0=C2=A0 if [ ! -e $diskimage ]; then =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 qemu-img create -f $format $d= iskimage 20g =C2=A0=C2=A0=C2=A0 fi =C2=A0=C2=A0=C2=A0 # qemu-system-ppc64 -nographic =C2=A0=C2=A0=C2=A0 # qemu-system-ppc64 -m 2048 -machine pseries-2.5 =C2=A0=C2=A0=C2=A0 qemu-system-ppc64 -m 2048 -machine pseries-2.5 \ =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -cdrom $cdimage -drive file=3D= $diskimage,format=3D$format -boot d =C2=A0=C2=A0=C2=A0 ;; boot) =C2=A0=C2=A0=C2=A0 qemu-system-ppc64 -m 2048 -machine pseries-2.5 \ =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -drive file=3D$diskimage,form= at=3D$format -boot c =C2=A0=C2=A0=C2=A0 ;; *) =C2=A0=C2=A0=C2=A0 usage =C2=A0=C2=A0=C2=A0 ;; esac --=20 Earth is a beta site. From owner-freebsd-ppc@freebsd.org Thu Feb 4 15:51:21 2021 Return-Path: Delivered-To: freebsd-ppc@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A3F5F547454 for ; Thu, 4 Feb 2021 15:51:21 +0000 (UTC) (envelope-from bdragon@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DWjhT47Lqz4X4y for ; Thu, 4 Feb 2021 15:51:21 +0000 (UTC) (envelope-from bdragon@FreeBSD.org) Received: from auth2-smtp.messagingengine.com (auth2-smtp.messagingengine.com [66.111.4.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: bdragon/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 80E23956F for ; Thu, 4 Feb 2021 15:51:21 +0000 (UTC) (envelope-from bdragon@FreeBSD.org) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailauth.nyi.internal (Postfix) with ESMTP id 4DE0527C0054 for ; Thu, 4 Feb 2021 10:51:21 -0500 (EST) Received: from imap38 ([10.202.2.88]) by compute3.internal (MEProxy); Thu, 04 Feb 2021 10:51:21 -0500 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrgeeggdejfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecufghrlhcuvffnffculddutddmnecujfgurhepofgfgg fkjghffffhvffutgfgsehtqhertderreejnecuhfhrohhmpedfuehrrghnughonhcuuegv rhhgrhgvnhdfuceosggurhgrghhonheshfhrvggvuefuffdrohhrgheqnecuggftrfgrth htvghrnhepieefgeeuveduffejteetjeejkeeftdetgffgieefgfetueegueekgeeutddu teejnecuffhomhgrihhnpehfrhgvvggsshgurdhorhhgnecuvehluhhsthgvrhfuihiivg eptdenucfrrghrrghmpehmrghilhhfrhhomhepsggurhgrghhonhdomhgvshhmthhprghu thhhphgvrhhsohhnrghlihhthidquddtgedvfeehkeeigedqudekuddtkeehuddqsggurh grghhonheppefhrhgvvgeuufffrdhorhhgsehimhgrphdrtggt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id F17C6CA005F; Thu, 4 Feb 2021 10:51:20 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-93-gef6c4048e6-fm-20210128.002-gef6c4048 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 04 Feb 2021 09:48:49 -0600 From: "Brandon Bergren" To: "FreeBSD PowerPC ML" Subject: Re: Looking for shell access for (minimal) LLDB testing Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2021 15:51:21 -0000 On Mon, Feb 1, 2021, at 6:16 AM, Micha=C5=82 G=C3=B3rny wrote: > Hello, >=20 > I'm working on modernizing LLDB's FreeBSD support. As a part of that,= > I have to port all architecture-specific code to a new process plugin > architecture, and I'd prefer to test that my code actually works ;-). >=20 > Sadly, FWICS FreeBSD doesn't work under qemu-system-ppc [1], and my > attempts seem to confirm that. For this reason I'd like to ask -- wou= ld > someone be able to grant me user-privilege shell access to a machine > (or VM) running 32-bit FreeBSD on PowerPC for a few days? >=20 > I probably won't need root access, though rsync(1) installed would be > helpful. I'm going to need around 1G of disk space but I can try to > squeeze in less than that if necessary. All builds are done on my hom= e > machine via a cross-compiler, so I won't be using much CPU or memory, > just some network bandwidth to transfer the data. >=20 > TIA for your help. >=20 > [1] https://wiki.freebsd.org/QemuRecipes#powerpc >=20 > --=20 > Best regards, > Micha=C5=82 G=C3=B3rny I can provide remote access to 32-bit PowerPC hardware if nobody's alrea= dy hooked you up. --=20 Brandon Bergren bdragon@FreeBSD.org From owner-freebsd-ppc@freebsd.org Fri Feb 5 12:06:06 2021 Return-Path: Delivered-To: freebsd-ppc@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0E349546940 for ; Fri, 5 Feb 2021 12:06:06 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-19.consmr.mail.gq1.yahoo.com (sonic314-19.consmr.mail.gq1.yahoo.com [98.137.69.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 4DXDf41XKdz3CC2 for ; Fri, 5 Feb 2021 12:06:03 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1612526761; bh=JDQIN2vIY91uu/xallDMPMXRZOtuCpC/3JWGlt9zmeP=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=jALCDjOE4EVPOTelVKTCQCZQLsyvNS3zf3Pt1wJY5mvWubO/ICn4fAYy6E/1agX73bOXMOfXAefl1rUnfqkKq75IS74eM+6XvHJzA9UxBd88zmZzYxC4t2U7SQANk0Ifv+zfQLDYvtvMKOgppZajq9RRDOrJhSNCsnXHcq6H1v0TRXku/gP2cKTPqQkkHAfdO/XqdjOkvBNNLRx/rjz3BEPIQlk9UOcSUXugacMbdalhc4ex1AnxtY0xd7YwUypqotXlWjFCdJB1V3G06AENMF0Kcln/+yohz+RS25Uqa/cxLtfnX42R4eybDxpxnmZPBWwsNM8uqf7F79nYnt9+GQ== X-YMail-OSG: K8CmzqgVM1mmy1aU8fa2uFv3L2zUKrR7q97TBrkVWyqT5HOa91CS_GcWjtE9Sjx JSGpLmJwXZASjEq3cAVXZQ8o4kVE_8i7nPkssHIhgdVQE04MVyPmbARrYJiFSMDwNr_QzxR7sXqh ZTJmcEU19lb008KxwRAqwmi9SiJ4oxtrzKHOLlElT6WYjAGxmCHt61ZNtc03OpJq.xsvXtO8WAts lUbpuuBrUnbdvL9XCDxTaHJtTNBGlxHjhTuVslDqaKC7zh2dF.b5__vxYN2XNCT5mBhJyQAvi.8d 70VwMb1C5XP0XcLqdz7jrKBTr2dJJhLIBAfqMxLKS_mOEU2VLRzyVvRUKOYzOueYxUCjsbZoJpHi .QDeJi9OoTFcRHMc438ek5IL_92zL5VdD0_I6.x2.xH.h9FE5q3EmviuJoOmbjFHlkTGxoanPpZK Sp61G5IMZv1oqq1A5PpAylvBv2K._NFO3h9rYXNB0m6DP.Bnqp3z2a65Y6AgQlnxqN.bUu.PSwJ1 43kmk_A8fAUNZnq5YE3sLF8zVMn7nJyY6bbam7X2puOGjZlDUXw01uEcEbpWcgoFFYwPTnL4sFDW ychdanM98jjqYEva.bBSTEhwTX9_iEzarN.pjSEj0FcczAOlfAAUH1lcdZ7yzEfed6c0GVt4C3E6 rOk76kDAVCOoclw1Dl8GL_sEEwfSy7F946pG7TIVoN31sKphilsSb1Qq9yPYPJhRa08ucQ2MY6jL 2QiCEyTxBFDCBiDQ4XvNvXVCw1EfzfFD7KvnnhWIhgHddCOn9bslfzlS88R_qMuGFbhJNS1sBOVv 3lG_fhJxtvcDiBAl_M8aEfWndQZr9yX_opyMQeXxzuu6GWOq1YsegKLOwPogtMygAXvwXdr7aByU o4ERTKjiiDi7tpmNX8NGQbiphyyjybSg.QqGiqnmBblW1uDrD1j6r.xcYFgacmEqiu25cao0x.Ja UDVw34ONHHSLhmeKtVLfKbN7sQJaN7Qh4ifK7RH.iclJZlIBz3YskJ.pNWiBceud2t9YmH1Wzs4K NIDKfmxjksUA4SrfQOSc1JhFFP7S5RPclhEocs_PwxEmtUp7bHOVTkyn3lEHi_RONH3h9kwMn6oa kt58Rz4lLok7SNw5kqg0PSH9ZNBEtGDzazhdUzN0acFwg_Uj1b4J0CmchYEoHCkTm6vgEPVOUVXt elniU.BXC6GEdQ6F_05YhgoQf2FGqE_V26zm7vCW2HTAlBX8q.54J.xOMKep0xdNSmxjwd1uGrEy RoUhLtj6f5z2Z3rUqerEoQzevqlOq_Qr42mNc0uLg8ulpUv22QmAFuqLiHqG3Dcs4aFAWZvyXj5_ gx6zjvEQuCsQA3Z3nWBW4oLpftDFIidF.Aty9oYHn04YPXYFJIxr8J8WnoNySfyaCQIUT.Fi09cd v0raG9MudP03TS6xvye3CKwSmnGptWMfrOKLusUK.80HVFnu8VdwM9DAiDYZq.5Sa6GY6ZbKjUqq AWw3jKb6Uo7xTmMKuaiGZD8v1WSbMcQeASkzOsT_TpNt3tpar0YjimzMRmoQSLjUiwy3XIasDnrN 2NtPB2dS_Z0R5ry6v__aCfv5oMOWnmc6qYaBtSpd3sOJlmC90p5BRa_4pYA8R9g.Xu4X91mc0KtX L9nmzTm0Fin1.zqOIHX0ZriczcZCIlKXTK59b5lUbxrm3._6SSQQ5RalGsVNPxxfca.nMHCWDh24 1yRK.qfvGz3HSbIN9MTzp3QSBdYxrItbnPE4QNcL.cDo_S7c_J4i2Cx8RNSOA2Y7eyG7e6W.Uj2Q rQ0zCxVKzyhgeAv2vePFXALY3bs6XinkAMKZPxuERXH3kH8dqJSnB79DWi5xxhn4DoKMmN1i1ydm K0OmJ6bPt5J0FHJIJ6Cus83fQIeMs..LhcpUyUBaMoicTwmRCkpahW27d0W7AOI1Ks75pgDEZTTn i74ultdkPlyWZQ542oWCN.0It5HEyw4erc60MMxIcRWWLWiBklS8HdSsUotdLuARcNQNwoc1UwZ4 okXcty6hfOagehm4MXD4QUcL9RoGl0R4cNTnw1Dp1H5S5Bo1xmdTt4OQj6EEirpFF43cTK7hzMVc mquXzB6FJJW9sLm6DYR5WDQKu02uHS8XJMbLY7vmB90.K8ih8Lc8ev8b79Jh9pK4rjtcK96f9GSC 6AlTzoWC6DqyW5mgnlyFqfETC4dJGM_N_xAj87dvqQCtIVcxAMirpxlEhkR0G4Ioe3xdm06ya1ea XlkSVm8D2uh.YoUBlNMB8jjgIGqy0BEbNabeHjR0WyhkK0FKFgRxuTBq9YvogSdXJXChwatW6bOd kI_eRR3KzQ3lFuEr_12X96FizKHnP6Pg.6XmmEfCwGnQ5cvQwy5tHq2DSOeL6shYYhYwtxK7ZtCY MvwPWqGjIIT79Z2ZaZwtoCl22q1XOqKsZfkAkYgRDH9ag6eCokDKicUaY4Q90ISYMgUQ1jtraW6i vRWCf5H1yXw-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Fri, 5 Feb 2021 12:06:01 +0000 Received: by smtp421.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 4fb7ec9caecad2cc263bfa8a54044ae0; Fri, 05 Feb 2021 12:05:58 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Subject: main (14-CURRENT) may be unstable on powerpc64 Message-Id: <28E64465-8A99-43CF-8B4F-044533EA03C4@yahoo.com> Date: Fri, 5 Feb 2021 04:05:55 -0800 To: freebsd-ppc X-Mailer: Apple Mail (2.3654.40.0.2.32) References: <28E64465-8A99-43CF-8B4F-044533EA03C4.ref@yahoo.com> X-Rspamd-Queue-Id: 4DXDf41XKdz3CC2 X-Spamd-Bar: - X-Spamd-Result: default: False [-1.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.69.82:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_SHORT(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[98.137.69.82:from:127.0.2.255]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.82:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.82:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-ppc] X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2021 12:06:06 -0000 I am running on a 2-socket/1-core-each PowerMac G5 (8 GiByte RAM) based on: # ~/fbsd-based-on-what-freebsd-main.sh=20 merge-base: 847dfd2803f6c8b077e3ebc68e35adff2c79a65f merge-base: CommitDate: 2021-02-03 21:24:22 +0000 325d7069b027 (HEAD -> mm-src) mm-src snapshot for mm's patched build in = git context. 847dfd2803f6 (freebsd/main, freebsd/HEAD, pure-src, main) readelf: do = not trucate section name with -W FreeBSD FBSDG5L2 14.0-CURRENT FreeBSD 14.0-CURRENT = mm-src-n244624-325d7069b027 GENERIC64vtsc-NODBG-dcons powerpc powerpc64 = 1400003 1400003 I attempted to rebuild the ports to get FreeBSD:14 based versions but got the below oddity in the process: # poudriere bulk -jFBSDpowerpc64 -c -w -f = ~/origins/powerpc64-origins.txt . . . =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D> Building package for gettext-tools-0.21 Child process pid=3D44950 terminated abnormally: Segmentation fault Child process pid=3D44956 terminated abnormally: Segmentation fault actual-package-depends: dependency on /usr/local/lib/libtextstyle.so not = registered (normal if it belongs to base) Child process pid=3D44958 terminated abnormally: Segmentation fault Child process pid=3D44962 terminated abnormally: Segmentation fault Child process pid=3D44971 terminated abnormally: Segmentation fault actual-package-depends: dependency on /usr/local/lib/libintl.so not = registered (normal if it belongs to base) Child process pid=3D44973 terminated abnormally: Segmentation fault Child process pid=3D44977 terminated abnormally: Segmentation fault Child process pid=3D44980 terminated abnormally: Segmentation fault actual-package-depends: dependency on /usr/local/bin/indexinfo not = registered (normal if it belongs to base) Child process pid=3D44982 terminated abnormally: Segmentation fault . . . Unfortunately, at the package phase, the above sort of thing does not lead to a saved copy of the work/ area for the port in poudriere and was classified as a Success. I do have the console report: Feb 4 03:14:17 FBSDG5L2 kernel: pid 44950 (pkg-static), jid 4, uid 0: = exited on signal 11 Feb 4 03:14:17 FBSDG5L2 kernel: pid 44956 (pkg-static), jid 4, uid 0: = exited on signal 11 Feb 4 03:14:17 FBSDG5L2 kernel: pid 44958 (pkg-static), jid 4, uid 0: = exited on signal 11 Feb 4 03:14:17 FBSDG5L2 kernel: pid 44962 (pkg-static), jid 4, uid 0: = exited on signal 11 Feb 4 03:14:17 FBSDG5L2 kernel: pid 44971 (pkg-static), jid 4, uid 0: = exited on signal 11 Feb 4 03:14:17 FBSDG5L2 kernel: pid 44973 (pkg-static), jid 4, uid 0: = exited on signal 11 Feb 4 03:14:17 FBSDG5L2 kernel: pid 44977 (pkg-static), jid 4, uid 0: = exited on signal 11 Feb 4 03:14:17 FBSDG5L2 kernel: pid 44980 (pkg-static), jid 4, uid 0: = exited on signal 11 Feb 4 03:14:17 FBSDG5L2 kernel: pid 44982 (pkg-static), jid 4, uid 0: = exited on signal 11 so which program got the failures is known but I did not end up with core files or other such. Also they all seem to have happened with the same reported time (second scale). (The messages above do not show "(core dumped)" either, so even with a copy of the work/ area there probably would not have been evidence.) One point is that the time frame means that the once-a-day checking activity (defaults) was likely running in parallel with the poudriere activity. The above left the "deps" information missing for gettex-tools-0.21 . When the poudriere run finished, the status was 7 failures and 153 skipped because of lack of "deps" information for gettext-tools-0.21 : [FBSDpowerpc64-default] [2021-02-04_02h19m21s] [committing:] Queued: 476 = Built: 316 Failed: 7 Skipped: 153 Ignored: 0 Tobuild: 0 Time: = 24:28:45 For reference, from early in the build: [00:24:17] [02] [00:00:00] Building devel/gettext-tools | = gettext-tools-0.21 . . . [00:55:34] [02] [00:31:17] Finished devel/gettext-tools | = gettext-tools-0.21: Success I then tried: # poudriere bulk -jFBSDpowerpc64 -i -C -w devel/gettext-tools and it built just fine this time: [FBSDpowerpc64-default] [2021-02-05_02h50m31s] [committing:] Queued: 1 = Built: 1 Failed: 0 Skipped: 0 Ignored: 0 Tobuild: 0 Time: 00:23:26 In all cases, each poudriere job was allow to have an active process per cpu (so 2 active processes per job). The retry, of course, was just one poudriere job. So far I've no evidence of problems with the other 315 of 316 built ports from the first run, including no more pkg-static failures. I have started up an attempted build of the failed and skipped ports. I have no known way to repeat the problem on demand and no evidence for specifically where pkg-static was executing when it failed. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-ppc@freebsd.org Fri Feb 5 18:34:42 2021 Return-Path: Delivered-To: freebsd-ppc@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 37D5154ECD4 for ; Fri, 5 Feb 2021 18:34:42 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-24.consmr.mail.gq1.yahoo.com (sonic311-24.consmr.mail.gq1.yahoo.com [98.137.65.205]) (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 4DXPGT2XHCz3tRv for ; Fri, 5 Feb 2021 18:34:41 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1612550079; bh=5HsxNLLBDegKyjzFVCWF2quglfEXaOLGABBcSb1EEy5=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=PPBLGfKsJIUkvjqQZR6JEWceP8DVU21tFBjn7BHEhYs6nIWP7dC1EKgN/cIhSSltH3gDJk20CFOyqzM2nkzo2xDc2K4zQEbTPgYmVoeFLhqf4l6469AsOFbWH6//8uXG9PuQb15pki9WSbNerHTfA4RgXzZth04cHMbFdTEbdV9TIz9ePNvtveuyOw4QmCyIXxfDCYHcuVohMWrUjdJTqsXPTeORZu0xErGgl9IaA1PRPSsmWMW/kriYUWeGxKqpyjf/1dIYB9aa7iB8A4G/nIOJyV7urZxiw3mytA4nLdAy5gBWm/YuxoJvoFWRaTO/90nPyCaIRh+VtrzONp51tA== X-YMail-OSG: TgstmyQVM1mVyeWqWgAe6twoEpR0BJBoOA8DWRgxxprNevAAQ31HPgQokiUqF80 yluDj0BqxvRhhCaITfPHhypec9dgDUlbIwmpPgtP8Ql.xNqxwT9ocp93yOjsP7y_o8lnUp2YgLpE 0ZnrVbKMxoxhJnjzPr08eZfEyrmcNGTYZgbjAWtT4SBukB4KnhgvQc5ss7tu87Rk7whd9S8.W9uB KHaY00EwdABqNUeV5PxwStyx4S8xVHus0TTREdCHF_iKN6Wx8YupmEtE62_OzijTShKzMyRBgSqQ A59zBvqwU.T8C1.qZXfywnaKmWpL8Lkp0vVLd6q57b1Rb_nXnkQdC0iSFIqu9iB5yfWamxO2hyj5 3CFPEFb8fAOyC8uYldSIDe1whd4ZoPRM74VByTJksK3nRaQlF.wIIUwew01psI0JzxrTIe_OLWKI 7hkuJuLjzfY.vgYAobfdJLUmChiqaq.iRY9CcE18sawtz0NS8BUWU5wsYfdQ2OjCF9oV83DVPISu cb3.DN3oo8n83lp.2rPSyAA6t4aAhLyuOqpu0mDCmQiQL9SpCUc_0U.kNqconPBmkFw.1X8B_HGI 9OL3QUctuvER56bvFVRrjux.nmuDTWUuZw8moYP1NUMbo2_RYB5183L7D.mQfVhuQgBH7aFayfWN 0oTYyNNFnYJMk257b7t_O8voYkS1eW27dqZHY3XNwMRkCRQdMwFDGRq25RzTJuOvyl22fhdKI1Ga RPG6w4S6crtfigqwr9QB6jWyxzF9PG5UXw9ks5yvmudx4O5ysFAGDiVWtdcIlShkUIF3nBbASP5_ W84ibmFNnL4tKW2dCxLDj.e0KRFkJc30s0wgLuwoRMM9cTRpUig4yr_IWzMS5K1jUmGnGkHO2HTq 7nOQxzZ9Jt7.GLWKc4EMlNfLVdGhf_pZQDPMP1BkVcs52e9MDh85n9bHeL763wnXFipLkjTqR3hJ sqk2.AbfDsb5FXWpjhOGS4KjRvcsGZ7YAO1pSfNM3tdeEMwpn0Ocs7EM4YgJghGoNAjzMsVRoNzi x8SFjEa.YMLYIH6SZ49sgdji7JjgYmXCe4w1UyWDWMRyvlI9.5PMj6j0.t7Dz6YhNVzl5oGzGp4q X25tjKPGBkAQxnmsgFlvTLYA6k.R0r9g0Du9gHscYKXEYGzGMAlXIwsmuznEFZVKki1nIZMRo9bh upyRAf5RZ1K9L4DdcNInMlQYpq2MFCW.7v81TF1tevt8U2X9YQUzXFO_9BeVIfAeeYgnvJtfhZJg hWYHe0STyaqEStgCIFo83J5z._uhmJ9KJnGuMfZEX8OpW1ACM_GJ.9oqoB1JlPNc1rZutcH.PPyU .A6vaEcVKxzUqJjNpabo5yP0vbanppBSiVacjyjdO.qDwNXIXu6xadRYJ1WYcU_5kA2xJMB0iGQ4 M9sDRKJ9xMVlhVx_r3e6WHdzUBclYtk_6upY4CZYJ6seD1OgKcl39WDzz6keIrB54m_p5_gmnqC4 5pYOcwXuOqd4F762LApn0jHPBTpE8lPhlf_RUwBQtGYAPKOQXSqc_p6bq63Aj9tznrpq_YsFnfzT lW_v8.cQ5Lp0FIOZXbsQ46SEZRBaz8fzoOBHnuWBdsvBaivzKhNMptfxyZvDml2w_TWNYa_JakM4 2CPJvJ358p439uQ.ysj3t0GK.57nnit3hwDwY3SjZWUY6d9a6Fu1utjjsX5u3TJeOkExUaTH6C7_ n.sPv951jKxxKnko2kkm2BL_cvk6RJfGHl.G1Jpn4jWabsDxnatuLb4o2QBbXwo5919TOxqAQ2zF ag0.mBmN5nGtkUIVP7OCTopqUvE9zvQz.Y5cDk7J77v6.h9GREkqJdzKkNfyA7JLw6MI.PW01KvR rcg1qfizRif557ObneEQVOVdpc89Vvmiq2fRfzudoj8euG.Ku2GbteERdartuys_5N11lPPwr5Uh g76tU5bDDJgS.rnhyRYSTATHLcG0_KiVO..507O.gu1BB7sUMemjVrZOzHJ.LHzBYTars2_LncZI sx5z1gFNoal2jVDAfeuLHT8wdavjL2v4z1.uOSq6.2.wA4AQH_vZm2HY5i4xgn7bvz4_mzwkSwE5 k4FztQt_uo9OA4yF9rZXjM59WY37966..UV9PsTfoPCV3GO82AOsyq9bT7kh5InxgZgspaZr5I86 TYJJghVAUIJkeQS10I3VBjQ_JxH7EAtDnYPTLd_fme5TpMpqKrOJs2UP5oxOcq4GGF8NDqtsV_bm Ydn52.0orrQZFN0ixLFAoPauoaVnUguSIDjvteCoT25Va65qMk9FT.waYB8vGEw9ty4f8ZzEwqvE ogfie2JlbrOBpouJhqO5GYP8JiYW_3AxQnCSeP8WkCoeT0FKvHc3dUX9sitjNh28zTtjDJm7hwUR lWL6GODQlV1uPUYdkhzJmtnr8B8X_wypGz6ZMKG0szTBuqfR9M4jn.l9KzuG79QgxIhQV34gvB84 HJwAF369paxRUQbzN7DcxYj3RpnEqrn5NR40oltm0TBqdiRgmhJIacCWaYIkmNJfOL1BsV3sQjUU mrxu9GXiAlEsEfp_jxXvNTNj.Ao6O8XsxnA-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Fri, 5 Feb 2021 18:34:39 +0000 Received: by smtp409.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID b9d9b267d82eca4404f60360eabc3ae4; Fri, 05 Feb 2021 18:34:28 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Subject: Re: main (14-CURRENT) may be unstable on powerpc64 From: Mark Millard In-Reply-To: <20210205113544.349ee77e@ralga.knownspace> Date: Fri, 5 Feb 2021 10:34:27 -0800 Cc: freebsd-ppc Content-Transfer-Encoding: quoted-printable Message-Id: <52899C49-E0DF-4E19-A89F-8B9376B8F1F5@yahoo.com> References: <28E64465-8A99-43CF-8B4F-044533EA03C4.ref@yahoo.com> <28E64465-8A99-43CF-8B4F-044533EA03C4@yahoo.com> <20210205113544.349ee77e@ralga.knownspace> To: Justin Hibbits X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4DXPGT2XHCz3tRv X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.65.205:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.65.205:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.205:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.205:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-ppc] X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2021 18:34:42 -0000 On 2021-Feb-5, at 09:35, Justin Hibbits wrote: > On Fri, 5 Feb 2021 04:05:55 -0800 > Mark Millard via freebsd-ppc wrote: >=20 >> I am running on a 2-socket/1-core-each PowerMac G5 >> (8 GiByte RAM) based on: >>=20 >> # ~/fbsd-based-on-what-freebsd-main.sh=20 >> merge-base: 847dfd2803f6c8b077e3ebc68e35adff2c79a65f >> merge-base: CommitDate: 2021-02-03 21:24:22 +0000 >> 325d7069b027 (HEAD -> mm-src) mm-src snapshot for mm's patched build >> in git context. 847dfd2803f6 (freebsd/main, freebsd/HEAD, pure-src, >> main) readelf: do not trucate section name with -W FreeBSD FBSDG5L2 >> 14.0-CURRENT FreeBSD 14.0-CURRENT mm-src-n244624-325d7069b027 >> GENERIC64vtsc-NODBG-dcons powerpc powerpc64 1400003 1400003 >>=20 >> I attempted to rebuild the ports to get FreeBSD:14 based >> versions but got the below oddity in the process: >>=20 >> # poudriere bulk -jFBSDpowerpc64 -c -w -f >> ~/origins/powerpc64-origins.txt . . . >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =3D=3D=3D> Building package for >>> gettext-tools-0.21 =20 >> Child process pid=3D44950 terminated abnormally: Segmentation fault >> Child process pid=3D44956 terminated abnormally: Segmentation fault >> actual-package-depends: dependency on /usr/local/lib/libtextstyle.so >> not registered (normal if it belongs to base) Child process pid=3D44958= >> terminated abnormally: Segmentation fault Child process pid=3D44962 >> terminated abnormally: Segmentation fault Child process pid=3D44971 >> terminated abnormally: Segmentation fault actual-package-depends: >> dependency on /usr/local/lib/libintl.so not registered (normal if it >> belongs to base) Child process pid=3D44973 terminated abnormally: >> Segmentation fault Child process pid=3D44977 terminated abnormally: >> Segmentation fault Child process pid=3D44980 terminated abnormally: >> Segmentation fault actual-package-depends: dependency on >> /usr/local/bin/indexinfo not registered (normal if it belongs to >> base) Child process pid=3D44982 terminated abnormally: Segmentation >> fault . . . >>=20 >> Unfortunately, at the package phase, the above sort of thing >> does not lead to a saved copy of the work/ area for the port >> in poudriere and was classified as a Success. I do have the >> console report: >>=20 >> Feb 4 03:14:17 FBSDG5L2 kernel: pid 44950 (pkg-static), jid 4, uid >> 0: exited on signal 11 Feb 4 03:14:17 FBSDG5L2 kernel: pid 44956 >> (pkg-static), jid 4, uid 0: exited on signal 11 Feb 4 03:14:17 >> FBSDG5L2 kernel: pid 44958 (pkg-static), jid 4, uid 0: exited on >> signal 11 Feb 4 03:14:17 FBSDG5L2 kernel: pid 44962 (pkg-static), >> jid 4, uid 0: exited on signal 11 Feb 4 03:14:17 FBSDG5L2 kernel: >> pid 44971 (pkg-static), jid 4, uid 0: exited on signal 11 Feb 4 >> 03:14:17 FBSDG5L2 kernel: pid 44973 (pkg-static), jid 4, uid 0: >> exited on signal 11 Feb 4 03:14:17 FBSDG5L2 kernel: pid 44977 >> (pkg-static), jid 4, uid 0: exited on signal 11 Feb 4 03:14:17 >> FBSDG5L2 kernel: pid 44980 (pkg-static), jid 4, uid 0: exited on >> signal 11 Feb 4 03:14:17 FBSDG5L2 kernel: pid 44982 (pkg-static), >> jid 4, uid 0: exited on signal 11 >>=20 >> so which program got the failures is known but I >> did not end up with core files or other such. Also >> they all seem to have happened with the same >> reported time (second scale). (The messages above >> do not show "(core dumped)" either, so even with >> a copy of the work/ area there probably would not >> have been evidence.) >>=20 >> One point is that the time frame means that the once-a-day >> checking activity (defaults) was likely running in parallel >> with the poudriere activity. >>=20 >> The above left the "deps" information missing for >> gettex-tools-0.21 . >>=20 >> When the poudriere run finished, the status was 7 failures >> and 153 skipped because of lack of "deps" information for >> gettext-tools-0.21 : >>=20 >> [FBSDpowerpc64-default] [2021-02-04_02h19m21s] [committing:] Queued: >> 476 Built: 316 Failed: 7 Skipped: 153 Ignored: 0 Tobuild: 0 >> Time: 24:28:45 >>=20 >> For reference, from early in the build: >>=20 >> [00:24:17] [02] [00:00:00] Building devel/gettext-tools | >> gettext-tools-0.21 . . . >> [00:55:34] [02] [00:31:17] Finished devel/gettext-tools | >> gettext-tools-0.21: Success >>=20 >>=20 >> I then tried: >>=20 >> # poudriere bulk -jFBSDpowerpc64 -i -C -w devel/gettext-tools >>=20 >> and it built just fine this time: >>=20 >> [FBSDpowerpc64-default] [2021-02-05_02h50m31s] [committing:] Queued: >> 1 Built: 1 Failed: 0 Skipped: 0 Ignored: 0 Tobuild: 0 Time: >> 00:23:26 >>=20 >>=20 >> In all cases, each poudriere job was allow to have an active >> process per cpu (so 2 active processes per job). The retry, >> of course, was just one poudriere job. >>=20 >> So far I've no evidence of problems with the other 315 of 316 >> built ports from the first run, including no more pkg-static >> failures. >>=20 >>=20 >> I have started up an attempted build of the failed and skipped >> ports. >>=20 >>=20 >> I have no known way to repeat the problem on demand and no >> evidence for specifically where pkg-static was executing when >> it failed. >>=20 >> =3D=3D=3D >> Mark Millard >> marklmi at yahoo.com >> ( dsl-only.net went >> away in early 2018-Mar) >=20 > This is probably fallout from 710e45c4b, which has since been = reverted. > 710e45c4b broke other things like swig as well, which caused a lot of > poudriere fallout for me (devel/llvm* failed because swig crashed). >=20 > Try updating past 33f0540b1 and testing again. >=20 The above is based on 847dfd2803f6, which is after 33f0540b1 . . . https://cgit.freebsd.org/src/log/?qt=3Drange&q=3D33f0540b1~1..847dfd2803f6= shows: Commit message (Expand) Author Age Files Lines * readelf: do not trucate section name with -W Ed Maste = 45 hours 1 -4/+9 * readelf: decode LA48 and ASG_DISABLE feature flags Ed Maste = 45 hours 1 -0/+2 * Add a VM flag to prevent reclaim on a failed contig allocation = Ryan Stone 45 hours 3 -2/+11 * dwmmc: Multiple busdma fixes. Michal Meloun 46 hours = 1 -15/+32 * linux: remove locks around callout_drain in timerfd_close() = shu 46 hours 1 -2/+0 * Revert "Reimplement strlen" Mateusz Guzik 47 hours = 2 -53/+108 (I Probably should have shown that in the original message, given the difficulty in determining the relative order of referenced commits.) Before updating to be 847dfd2803f6 based, I had also previously hit the swig issue with the llvm10 build. That problem failed reliably until after I'd updated past the revert. (Not trusting the other things built is why I did a -c poudriere bulk after updating to an environment based on after the revert.) The variability in the pkg-static behavior this time suggests race conditions are involved, though not frequent failures. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-ppc@freebsd.org Sat Feb 6 05:34:22 2021 Return-Path: Delivered-To: freebsd-ppc@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id F01B4534A3A for ; Sat, 6 Feb 2021 05:34:22 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-8.consmr.mail.gq1.yahoo.com (sonic316-8.consmr.mail.gq1.yahoo.com [98.137.69.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DXgvd3Gkrz3LWZ for ; Sat, 6 Feb 2021 05:34:21 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1612589658; bh=kGslYrDOJBl7G5E/lsjfRxhzZMwDIIO4CYgCvFeIKVQ=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=YETrOVcCJW1y0FhTUWYYeq4rzAt3B1dwaM84txR9jLo+jYh0TYZllO3rBKhXqmuv0PHy5n2YFqoKcbMDWkNDpJV8z7qi6wdzUTnIbsHvvncEyOBCrOOcYYNty0BN49Eie+0Uv9PwlR8WVcDW2FlGRn8W1iUuLw3HbVQP8Ittv4MHWA9t29Q/QbZGDFbWXhMjUfbFk+jvlFp9LqXGtZC0umaNJf4QRfUDP5oArQUaRTgz+pgxeWUV7FeAaW8RrBvvE/oJUu9Bw59d/Uq0YsnhCZ5NsPEhhhdUytfBCZTQ23E0+/3UrI296b9JDRGOgEKUipdD1N6IkmETt/M+gmO8mw== X-YMail-OSG: F1oIvtgVM1mg7HuOTEsaBWM6AZLWGE7b78z7FLH7vqtpcd84Csj1cz7HxwXVUqa 1YPP9bhWHBBT7JMdZUk5wbD2.mtFGRb0WPpLbLedJK.5K5DAJCsqTcXj99kI6zOYP_3HkiI0Ds77 Ws0cX_34uN.B9qAJ28iFaRf42hNoGi9Y9BgX_dH8DHEwWpp7Yg1bvAZylkLjKoB3XRf31Hvlr4az awu4DBdAvxXfbSJIzrCdyFd3xlDeiuvYfUwU9PDtbQK1laIgIothRL7e9Ej2i3udwbuaWFOQKpHs rCmZSUm5rV4zyO.8olUvFe.5d0rpw5nHVi3SNhUSLJUUNbqgQIgZYe1xAKkoHkMH91WBGVFNPJOU GP4_RoVPh7lKi_BEhU4kdi.vZlryXaVqsotlsOYTd7887KcIpnirUYg_gswHv_tK9WyuhTYGAmn5 a37JAMHdw_OoCgtAeO15wR9ZM4p9JhPCGjMpO49SrignGs3rIooBDtrzwym_J_XTh.MNHwXQ7_jY RMOOJpAasGiEIOSgVQZy3WiYY5VYNN435nORNW6beN5oONFIpZepYLRhiuFUIk7lg52L0p6OLZfm zVN1L_Ux0dShgnPfBxspnFse4f0ZjDKnP8keiTaRvplF6gglaqgRPBbDc1X99do5GIIc3SrGAbC9 aNC1wf52YjC0NmGn_GcW.jUYCeGzz23V7YwfY8Aa2I66LUxOrmhEW6UqX.epvXPB1QKXQoFcnO2D l6Epzlme0UjKUt7e1aYDBQmvGhJKw1ilaZPwEVythpBe7YvYob_AXCJlC.QQeF6Phh.ktIshjI_u h38zSppZ5ajmHT0NmwugzaP0TF9ills_tJFnWfu7bz4KqUbXRq49V1dW0dbtfWtpCO7BjOtw9QfZ yMPPNG7mtgdV4nZVVbO1RSNGwm6M5.3wh6OcudkNmSebakb1hAzcLPtv1iw9iGAP1vVZRs_Q1sNm 707UTEAnSmiCzapZ8IXvJxilFi44nXkvbDU67L9H0Q66z1817p1a.N6iho7pOh4xQvB497i7xCHo 7B.Du_16o4nW2pqDt_44V4gQzGvHLDjCFCEvWDIF1w.j2YxLixowxiPZTkNHLnKfUMz9GdziH8zm lzdao50q5_V.yLaxEopLhX5v8rqvoFJSgqJo_tJtUnJpOSxDizIWyPFawLqDG4fDvgJADLXmqtPh .WbwpVmU_yJXVVCTs0txnvRaTfxgy9rhtDTJjq.Y.Ug2hziHipRpM1hhobg6RqoH3GIRAHN8ufYG C43jUdWX7a.3n2pO7Ja2EGHYZh_o8v.TM.Hmue7.WW9cEkvKxwc6eJpSROAmYO_Jq7wc.BFvxoon TWSTq8tBPs.46Pszl_bUcy0qRuQJIlgZj53C5Shrd06AfjfJiJrxct.DUBHuKdKiNh3RXVeJhXeu 0Yr_gUUZ0z.RNO72FBV93uC3pNQkShngzFPQIVULqq6jDtSqbu94uhVX9Yc.B_1oUVeZ8SE6bSKg tTDBshgoY6Rl14kPJBxuMoY50vsxFA0_XJR6IOUPwtGoG1a968i196cBUQnR5afh32pJzd0XZL4Z yhIoBjKlEoro.p7siYtQ2b6LYzJwK_xMT.R8JGW8inAABolnp_qTxKmpNo1_i2itdMiR1wZwdmV5 pixc7qTKO9ZWLxREpyY6YUIXDMTs4yx02C.NLQo03S_0NxPgxtOlarKoJALpAtArdzDfOhF4lpIQ 69aGNnhkSbTRkd.sKjG.ZS7yWHj0QjXXPbMa5FyJmdEFExjsHa_GQpVbDM4DJV8eFjeMp99ENU5p W0CXciLHHYp.AxI0cVTJkryTVPpukekBml91jOmYPYF_DBoKmTz49hHZ8IpO73B1q7pJhdxv_3Ra HTuawk.9IsA_tzTaSRVKEfS_JCOvFlfCqdkXjUarW4zv.I3c92jcnzwenjCJecZyZ2aftnAJysvb 1ILBj_M1aHNwz5UWmGNambYkgBvnsN0x469Gn_mmsyy3ZdWG055GoUFTHooh_TmfK6vd9ERHEFyR IJIYWXnJTPN_zeO2ttdDGc6IbnNWiewT.fljIMZbBxsU_IW1te98nY4DyYyETahU_SXMY_ZOx5Nz CT86mWa5l6s06QRkrAptyzOklmBzpAqZI7LMLfRuqMEGNN0B0stttWABYZ5YQWajiVbDiLoWV.he druEwMVs64z9Sdk.LoM.bkpqdldZfoeaonSgSyE1bXgCGBAU_pS0tHOhpwAa73LzlmcnzCTa0URc iip_cfaj.1Vr6lDoHBz7jmjSMA7mL4w1dxaWyTO99VfasM9XTQYl11Lqs_Ziq4YV7v0t13TlnCTA MHdeGepILjvRg_RkAAMUvTT7cF6Ca.AmsOKpAR3TT7EahNINPDS4XhGMtr.TbDDBaAlYHCUjhqoB FHAWWI7zjipSuz10U4NXP3nbVIkoyNRVfL9L8kmsAUBPvcxtcjPSotMPFVV.HFBmHhMtdDKF3ZrU kEw4qlbzM6SaeqsPcblUT23PBbUCbcELA4gtsr8DT94KpS06n8IE3HSU94poaYufYpUyddmcOO1H _puh0R2QruipWgiL9c_590JvDq2ZVY2jav76J X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Sat, 6 Feb 2021 05:34:18 +0000 Received: by smtp420.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 0f259058251bc78a7b5a16c5a34e52e8; Sat, 06 Feb 2021 05:34:14 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Subject: Re: main (14-CURRENT) may be unstable on powerpc64 From: Mark Millard In-Reply-To: <52899C49-E0DF-4E19-A89F-8B9376B8F1F5@yahoo.com> Date: Fri, 5 Feb 2021 21:34:11 -0800 Cc: freebsd-ppc Content-Transfer-Encoding: quoted-printable Message-Id: <051FDA5B-C529-4805-89F1-3802D75FC7B7@yahoo.com> References: <28E64465-8A99-43CF-8B4F-044533EA03C4.ref@yahoo.com> <28E64465-8A99-43CF-8B4F-044533EA03C4@yahoo.com> <20210205113544.349ee77e@ralga.knownspace> <52899C49-E0DF-4E19-A89F-8B9376B8F1F5@yahoo.com> To: Justin Hibbits X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4DXgvd3Gkrz3LWZ X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.69.32:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.69.32:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.32:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.32:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-ppc] X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Feb 2021 05:34:23 -0000 On 2021-Feb-5, at 10:34, Mark Millard wrote: > On 2021-Feb-5, at 09:35, Justin Hibbits = wrote: >=20 >> On Fri, 5 Feb 2021 04:05:55 -0800 >> Mark Millard via freebsd-ppc wrote: >>=20 >>> . . . >>=20 >> This is probably fallout from 710e45c4b, which has since been = reverted. >> 710e45c4b broke other things like swig as well, which caused a lot of >> poudriere fallout for me (devel/llvm* failed because swig crashed). >>=20 >> Try updating past 33f0540b1 and testing again. >>=20 >=20 > The above is based on 847dfd2803f6, which is after 33f0540b1 . . . >=20 > https://cgit.freebsd.org/src/log/?qt=3Drange&q=3D33f0540b1~1..847dfd2803= f6 > shows: >=20 > Commit message (Expand) Author Age Files Lines > * readelf: do not trucate section name with -W Ed Maste = 45 hours 1 -4/+9 > * readelf: decode LA48 and ASG_DISABLE feature flags Ed Maste = 45 hours 1 -0/+2 > * Add a VM flag to prevent reclaim on a failed contig allocation = Ryan Stone 45 hours 3 -2/+11 > * dwmmc: Multiple busdma fixes. Michal Meloun 46 hours = 1 -15/+32 > * linux: remove locks around callout_drain in timerfd_close() = shu 46 hours 1 -2/+0 > * Revert "Reimplement strlen" Mateusz Guzik 47 hours = 2 -53/+108 >=20 > (I Probably should have shown that in the original > message, given the difficulty in determining the > relative order of referenced commits.) >=20 > Before updating to be 847dfd2803f6 based, I had also > previously hit the swig issue with the llvm10 build. > That problem failed reliably until after I'd updated > past the revert. (Not trusting the other things built > is why I did a -c poudriere bulk after updating to an > environment based on after the revert.) >=20 > The variability in the pkg-static behavior this time > suggests race conditions are involved, though not > frequent failures. >=20 >=20 It still failed to build llvm10 but the error reporoted is rather different. At least there is a .tbz for me to expand. I may end up with more to report after that. Here is the log file's report: [2996/4558] /usr/bin/c++ -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS = -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS = -Itools/clang/tools/extra/clang-tidy/plugin = -I/wrkdirs/usr/ports/devel/llvm10/work/llvm-10. 0.1.src/tools/clang/tools/extra/clang-tidy/plugin = -I/wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/tools/clang/include= -Itools/clang/include -Iinclude = -I/wrkdirs/usr/ports/devel/llvm10/work/llvm -10.0.1.src/include -O2 -pipe -DNDEBUG -fstack-protector-strong -isystem = /usr/local/include -fno-strict-aliasing -DNDEBUG -isystem = /usr/local/include -fPIC -fvisibility-inlines-hidden -Werror=3Ddate-ti me -Werror=3Dunguarded-availability-new -Wall -Wextra = -Wno-unused-parameter -Wwrite-strings -Wcast-qual = -Wmissing-field-initializers -pedantic -Wno-long-long = -Wimplicit-fallthrough -Wcovered-switch-defa ult -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor = -Wstring-conversion -fdiagnostics-color -ffunction-sections = -fdata-sections -fno-common -Woverloaded-virtual -Wno-nested-anon-types=20= -O2 -pipe -DNDEBUG -fstack-protector-strong -isystem /usr/local/include = -fno-strict-aliasing -DNDEBUG -isystem /usr/local/include = -fno-exceptions -std=3Dc++14 -MD -MT tools/clang/tools/extra/clang-tid y/plugin/CMakeFiles/obj.clangTidyPlugin.dir/ClangTidyPlugin.cpp.o -MF = tools/clang/tools/extra/clang-tidy/plugin/CMakeFiles/obj.clangTidyPlugin.d= ir/ClangTidyPlugin.cpp.o.d -o tools/clang/tools/extra/cl ang-tidy/plugin/CMakeFiles/obj.clangTidyPlugin.dir/ClangTidyPlugin.cpp.o = -c = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/tools/clang/tools/ext= ra/clang-tidy/plugin/ClangTidyPlugin.cpp FAILED: = tools/clang/tools/extra/clang-tidy/plugin/CMakeFiles/obj.clangTidyPlugin.d= ir/ClangTidyPlugin.cpp.o=20 /usr/bin/c++ -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS = -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS = -Itools/clang/tools/extra/clang-tidy/plugin = -I/wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/tool s/clang/tools/extra/clang-tidy/plugin = -I/wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/tools/clang/include= -Itools/clang/include -Iinclude = -I/wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/ include -O2 -pipe -DNDEBUG -fstack-protector-strong -isystem = /usr/local/include -fno-strict-aliasing -DNDEBUG -isystem = /usr/local/include -fPIC -fvisibility-inlines-hidden -Werror=3Ddate-time = -Werror=3Du nguarded-availability-new -Wall -Wextra -Wno-unused-parameter = -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic = -Wno-long-long -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noe xcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor = -Wstring-conversion -fdiagnostics-color -ffunction-sections = -fdata-sections -fno-common -Woverloaded-virtual -Wno-nested-anon-types = -O2 -pipe -D NDEBUG -fstack-protector-strong -isystem /usr/local/include = -fno-strict-aliasing -DNDEBUG -isystem /usr/local/include = -fno-exceptions -std=3Dc++14 -MD -MT = tools/clang/tools/extra/clang-tidy/plugin/CMa keFiles/obj.clangTidyPlugin.dir/ClangTidyPlugin.cpp.o -MF = tools/clang/tools/extra/clang-tidy/plugin/CMakeFiles/obj.clangTidyPlugin.d= ir/ClangTidyPlugin.cpp.o.d -o tools/clang/tools/extra/clang-tidy/plu gin/CMakeFiles/obj.clangTidyPlugin.dir/ClangTidyPlugin.cpp.o -c = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/tools/clang/tools/ext= ra/clang-tidy/plugin/ClangTidyPlugin.cpp PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and = include the crash backtrace, preprocessed source, and associated run = script. Stack dump: 0. Program arguments: /usr/bin/c++ -D_GNU_SOURCE = -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS = -Itools/clang/tools/extra/clang-tidy/plugin = -I/wrkdirs/usr/ports/devel/llvm1 0/work/llvm-10.0.1.src/tools/clang/tools/extra/clang-tidy/plugin = -I/wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/tools/clang/include= -Itools/clang/include -Iinclude = -I/wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/include -O2 -pipe = -DNDEBUG -fstack-protector-strong -isystem /usr/local/include = -fno-strict-aliasing -DNDEBUG -isystem /usr/local/include -fPIC = -fvisibility-inlines-hidden -Werror=3Ddate-time = -Werror=3Dunguarded-availability-new -Wall -Wextra -Wno-unused-parameter = -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic = -Wno-long-long -Wimplicit-fallthrough -Wcovered-switch-default = -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor = -Wstring-conversion -fdiagnostics-color -ffunction-sections = -fdata-sections -fno-common -Woverloaded-virtual -Wno-nested-anon-types = -O2 -pipe -DNDEBUG -fstack-protector-strong -isystem /usr/local/include = -fno-strict-aliasing -DNDEBUG -isystem /usr/local/include = -fno-exceptions -std=3Dc++14 -MD -MT = tools/clang/tools/extra/clang-tidy/plugin/CMakeFiles/obj.clangTidyPlugin.d= ir/ClangTidyPlugin.cpp.o -MF = tools/clang/tools/extra/clang-tidy/plugin/CMakeFiles/obj.clangTidyPlugin.d= ir/ClangTidyPlugin.cpp.o.d -o = tools/clang/tools/extra/clang-tidy/plugin/CMakeFiles/obj.clangTidyPlugin.d= ir/ClangTidyPlugin.cpp.o -c = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/tools/clang/tools/ext= ra/clang-tidy/plugin/ClangTidyPlugin.cpp=20 1. = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/tools/clang/include/c= lang/Frontend/Utils.h:165:76: current parser token ')' 2. = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/tools/clang/include/c= lang/Frontend/Utils.h:40:1: parsing namespace 'clang' 3. = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/tools/clang/include/c= lang/Frontend/Utils.h:149:1: parsing struct/union/class body = 'clang::ModuleDependencyCollector' 4. = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/tools/clang/include/c= lang/Frontend/Utils.h:165:47: parsing function body = 'clang::ModuleDependencyCollector::insertSeen' 5. = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/tools/clang/include/c= lang/Frontend/Utils.h:165:47: in compound statement ('{}') 6. /usr/include/c++/v1/utility:297:29: instantiating class = definition 'std::__1::pair, = bool>' 7. = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/include/llvm/ADT/Stri= ngMap.h:34:34: instantiating class definition = 'llvm::StringMapIterator' 8. = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/include/llvm/ADT/Stri= ngMap.h:488:7: instantiating class definition = 'llvm::StringMapIterBase, = llvm::StringMapEntry>' 9. = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/include/llvm/ADT/iter= ator.h:67:7: instantiating class definition = 'llvm::iterator_facade_base, = std::__1::forward_iterator_tag, llvm::StringMapEntry, = long, llvm::StringMapEntry *, = llvm::StringMapEntry &>' #0 0x0000000012f52ed0 llvm::sys::PrintStackTrace(llvm::raw_ostream&) = (/usr/bin/c+++0x12f52ed0) #1 0x0000000012f50770 llvm::sys::RunSignalHandlers() = (/usr/bin/c+++0x12f50770) #2 0x0000000012ee4778 CrashRecoverySignalHandler(int) = (/usr/bin/c+++0x12ee4778) #3 0x0000000813f2b2b4 (/lib/libthr.so.3+0x2f2b4) c++: error: clang frontend command failed due to signal (use -v to see = invocation) FreeBSD clang version 11.0.1 (git@github.com:llvm/llvm-project.git = llvmorg-11.0.1-0-g43ff75f2c3fe) Target: powerpc64-unknown-freebsd14.0 Thread model: posix InstalledDir: /usr/bin c++: note: diagnostic msg:=20 ******************** PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: c++: note: diagnostic msg: /tmp/ClangTidyPlugin-21aaa2.cpp c++: note: diagnostic msg: /tmp/ClangTidyPlugin-21aaa2.sh c++: note: diagnostic msg:=20 Note: Unfortunately, poudriere does not capture those files from /tmp/ in the .tbz for the build failure. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-ppc@freebsd.org Sat Feb 6 07:49:29 2021 Return-Path: Delivered-To: freebsd-ppc@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6539153FA09 for ; Sat, 6 Feb 2021 07:49:29 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-8.consmr.mail.gq1.yahoo.com (sonic315-8.consmr.mail.gq1.yahoo.com [98.137.65.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DXkvX2pWxz3mJT for ; Sat, 6 Feb 2021 07:49:27 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1612597766; bh=AFtLARXxdQTl+Ujb+rOLSt+JPWjWhp+xWpkzjeSNL3L=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=LBblpblygnz+hqpW/3vZCbOESOm5IFSMf9D3t6PdVI1XlTRLj9e88SnJ6WHzE+aCmirh0Zx5/6tMpkyC7idfD6kjsQwTFIOydxIzN6B3QgueZNUAaxT/iilNZ9vXKXGuOhEhiujdWUQbpYGFgVdjK5QOe0E5FJoBmTfgzu5ZthYNLH0k6thcczQKThc0tz1jiIumoTcGaUUbWfv2DRhOulUkXav0w/4Bo7p2VHeI1vJFU8ABhmMb/h5WJ1ajTxNLsFlt+OkB38z82mST3+eOPOPtJEtPltZpync7FyTUk9X1Xy92y/sgQZl96abXjuK3iE+poQP+yaMQ3LKOnhXpww== X-YMail-OSG: 3GObsJQVM1l7TQgnZRc4tRJz.dPWLoHQsMewbloQd0V2GH3Wgp41mZHTvXJhg3f QOxqT9XceXg30fgg2W8WJ1HaRaGC_pcYmrKR0X4vRgmLlum9tDCQ6vgdnQ1mj7IMJVhUNSsEaPAT GBleCLA_iHJpkUaU6Q0nurIzXXJRJXCJVSihrbYRvxgRi54XVY_1mcIcgfxnxUm2BWPDCWV3L2Dh v0EGHYKJs_L_7Gu4Yhm95AEhc5JauEwdgOOUeVlUPOzW_8jSrmKMaJdA6IVz2hW6MieMOLrgo0kH w5rOY.1QCcfcH9zh3jTEUcQPf3a2u743eqq8gB7W7YxKd1OE4KpBp21k3QN1AGFh2IJqTM7adrai b_WJKdGkgej.3OZJsMQGa1dIPo46Q_JNFRZbTVgrGPanBOSEgivaJGrAVCWhUs3J6QWEcUN6HIbq pE42jd4aYF__xKXx3WJBPfDZ6ICBFUuTp24lTuFd3O55Sv38A1iZ7tb19qolaQDk_OalZUF0dcTv WGLmYfaSSkMgT3NtttYOXkHuV79a8N9V3FLehLZyC0baZlG_u0PndL9KJg6th5Qj6T1kP2pSjytb DnrtIuKad3Ot_ZH0SIAgaiPxCHKMyfKGcS_aTghT179oMVvAMOMk8FpH7p_4stKEByL3Xqnf0ZEl vtFL.Urm6o2qq4MZ59ZSuE_Xe4dIxdCQlqRvRRC1uEsDmK3ESxKwxrnjcdPFEzy.WAIBUu.EShHM gMnVYkEho2WJjwqDGhFF74jWwA._1UibJigGQcLwabQkxLlobnIThRuabX3FV1vt6Qcwyg_DG4xs VcczBYxSwvGo9QPo_7KqejmTZwvBDHSdzdXQI3QTMECf3x9Wuect89xc9bwE8Hb3bH6DZnsFtdte RLcCTsru7ntkGiz2XqXfNS5WEJmx51OEgh44AO4dSlFug8T7.h4TlN9Oy_kMkcHr8A1CubbQFl8Y psO9TVMAMB6XMYimX6FwyQUHPkMbCka6O36oa3T_XiRRhILgJ3fZceQLm4_hjqcGaJ7GcSKRXkYN ucUQsL6k8rj6.Lml75loiazdVGFFxh0442B9w4z9D4dLhFpfqkw9MsHBkQhZWosKbhvUa99CkbUQ BQfpOMjOb1.M7K.3N1qV65j7PURx_4l8JhBDeIXJE_YIcd_IAJngkARybpdpQB69qwDg6IaLiJj1 0wkxmwdHyMLwqLgWH3G2t3OT9XcrskkPcTNJMtib46LyzzbGKWcua538B5HG.0Vjvxs_5h6BTuN0 zykqeouUu43Un.1PgAiVvapS9KUq4hzmTXbmMmgp.1KQ6fJ1hywncIBO3PfNZwZ_821kOSJEbFJ7 DM5x1L.0L2D5Azn6kI7sKNfuh0uGPUbsOR9zVv4xVy5HXzMIX0yhDpXo8vqvcgrulzYglPMtNAQu kI0HjhOsTs4UScEKi.14rESdXY1zKIDBKIxs5CyaD_uVxzHr4f_AGqXNFYz2yKvuHBPmQof1JztT Ki0RlTuMk9bbkIKt92YeQTH.vv4V6.CN7GkEFR5ilJ2qmLcw2_2HHUdEZmuOdD8ScIYXIjQFL3f1 6Rze3QHBwEmnBKFvK1ExwpW5obHyDyYMjEKrgj5uTqqJN9A4UpL8YJmQdQrRrlYdgb3lGQHzqMjF siX1PKXJaOPN7VMH7aKYHLcY9jV9rfMUWTcLxPnp1v9MqoJjizCTdL6BMk0qjhWsgAaBYdszRzTN x_wl2QKIILJwc2YCdCQIc3DgRasWWd3f3aEkIUi0xk6q1zyST7OWI8zUjP.sH_uQOvZVhZXQ802t OV_3IL5qY7gHB7lYrKJzUcwwkcTjFGLJ.opRYxuM3NtSOuiJF5RwEnfCUNrj40Yr1eWezGbAKp7p 6CIn5IPkgccO6dvBOrQYJ6w0XWreLmSrbZ9LN2VP9b_fXsp9rk_9.qVkDOv9O.HYHD9Bx3tOrIpZ 8M_Sn6HhGmva1cpsV79gWBFRequ4qPYO8aMSGsMo5hhmB6.4s.bD9EQsv2nTgOM5wsyzEdA6neid .tlohgsCaf_u9Bp8ig743v4_pozLqIuxcKO1yvcAJL6sXt9fHhS0oaZvTpISbFVBdtkX1BptlQcB 4Y3ZZ8Q6gKhpFbTlfFyDoZOb6rvxydz.p0Bb.31NDARdvBHsSfGMr5pRY52qlojPq4MqaQ80ClHW haQtEkLgtCS4B.PLJdZBJX92y8i2ThuFbtUeOAhIAYcpfZ6pwgW_sEYJVillwdwCV2P.XJjtkZUI RFsbPztHYRFWqT8LVbVCe6hauMLRqJezEKOZ4Dddtrqx2YhJ02qJBlAf7O3oxK3U3.p5hLTRtqBy BurxwN9ROxBGjQS79DaBZp6bw0q9oFVAP14YKiDxjbLs4kelzn0fB8jweJI49oVPa44kppNK46eJ UBOFmO5OIadq7_UI0s6upDIf2xSdYYSTpm16w3lLXCFDK3.qWzIkuBZP.g5CIq0BUBrrmwU7yYdG b6ExrqN7R98ccLKNvaTAjp3ygn_V6ZxNe4nUMNqcWBO6umdg91VOr X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Sat, 6 Feb 2021 07:49:26 +0000 Received: by smtp418.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 9ed3fe98179e3da0eaee9fffe207ba17; Sat, 06 Feb 2021 07:49:25 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Subject: Re: main (14-CURRENT) may be unstable on powerpc64 From: Mark Millard In-Reply-To: <051FDA5B-C529-4805-89F1-3802D75FC7B7@yahoo.com> Date: Fri, 5 Feb 2021 23:49:24 -0800 Cc: freebsd-ppc Content-Transfer-Encoding: quoted-printable Message-Id: References: <28E64465-8A99-43CF-8B4F-044533EA03C4.ref@yahoo.com> <28E64465-8A99-43CF-8B4F-044533EA03C4@yahoo.com> <20210205113544.349ee77e@ralga.knownspace> <52899C49-E0DF-4E19-A89F-8B9376B8F1F5@yahoo.com> <051FDA5B-C529-4805-89F1-3802D75FC7B7@yahoo.com> To: Justin Hibbits X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4DXkvX2pWxz3mJT X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-0.999]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.65.32:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.65.32:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.32:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.32:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-ppc] X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Feb 2021 07:49:29 -0000 On 2021-Feb-5, at 21:34, Mark Millard wrote: > On 2021-Feb-5, at 10:34, Mark Millard wrote: >=20 > On 2021-Feb-5, at 09:35, Justin Hibbits = wrote: >>=20 >>> On Fri, 5 Feb 2021 04:05:55 -0800 >>> Mark Millard via freebsd-ppc wrote: >>>=20 >>>> . . . >>>=20 >>> This is probably fallout from 710e45c4b, which has since been = reverted. >>> 710e45c4b broke other things like swig as well, which caused a lot = of >>> poudriere fallout for me (devel/llvm* failed because swig crashed). >>>=20 >>> Try updating past 33f0540b1 and testing again. >>>=20 >>=20 >> The above is based on 847dfd2803f6, which is after 33f0540b1 . . . >>=20 >> = https://cgit.freebsd.org/src/log/?qt=3Drange&q=3D33f0540b1~1..847dfd2803f6= >> shows: >>=20 >> Commit message (Expand) Author Age Files Lines >> * readelf: do not trucate section name with -W Ed Maste = 45 hours 1 -4/+9 >> * readelf: decode LA48 and ASG_DISABLE feature flags Ed Maste = 45 hours 1 -0/+2 >> * Add a VM flag to prevent reclaim on a failed contig allocation = Ryan Stone 45 hours 3 -2/+11 >> * dwmmc: Multiple busdma fixes. Michal Meloun 46 hours = 1 -15/+32 >> * linux: remove locks around callout_drain in timerfd_close() = shu 46 hours 1 -2/+0 >> * Revert "Reimplement strlen" Mateusz Guzik 47 hours = 2 -53/+108 >>=20 >> (I Probably should have shown that in the original >> message, given the difficulty in determining the >> relative order of referenced commits.) >>=20 >> Before updating to be 847dfd2803f6 based, I had also >> previously hit the swig issue with the llvm10 build. >> That problem failed reliably until after I'd updated >> past the revert. (Not trusting the other things built >> is why I did a -c poudriere bulk after updating to an >> environment based on after the revert.) >>=20 >> The variability in the pkg-static behavior this time >> suggests race conditions are involved, though not >> frequent failures. >>=20 >>=20 >=20 > It still failed to build llvm10 but the error reporoted > is rather different. At least there is a .tbz for me to > expand. I may end up with more to report after that. >=20 > Here is the log file's report: >=20 > [2996/4558] /usr/bin/c++ -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS = -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS = -Itools/clang/tools/extra/clang-tidy/plugin = -I/wrkdirs/usr/ports/devel/llvm10/work/llvm-10. > 0.1.src/tools/clang/tools/extra/clang-tidy/plugin = -I/wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/tools/clang/include= -Itools/clang/include -Iinclude = -I/wrkdirs/usr/ports/devel/llvm10/work/llvm > -10.0.1.src/include -O2 -pipe -DNDEBUG -fstack-protector-strong = -isystem /usr/local/include -fno-strict-aliasing -DNDEBUG -isystem = /usr/local/include -fPIC -fvisibility-inlines-hidden -Werror=3Ddate-ti > me -Werror=3Dunguarded-availability-new -Wall -Wextra = -Wno-unused-parameter -Wwrite-strings -Wcast-qual = -Wmissing-field-initializers -pedantic -Wno-long-long = -Wimplicit-fallthrough -Wcovered-switch-defa > ult -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor = -Wstring-conversion -fdiagnostics-color -ffunction-sections = -fdata-sections -fno-common -Woverloaded-virtual -Wno-nested-anon-types=20= > -O2 -pipe -DNDEBUG -fstack-protector-strong -isystem = /usr/local/include -fno-strict-aliasing -DNDEBUG -isystem = /usr/local/include -fno-exceptions -std=3Dc++14 -MD -MT = tools/clang/tools/extra/clang-tid > y/plugin/CMakeFiles/obj.clangTidyPlugin.dir/ClangTidyPlugin.cpp.o -MF = tools/clang/tools/extra/clang-tidy/plugin/CMakeFiles/obj.clangTidyPlugin.d= ir/ClangTidyPlugin.cpp.o.d -o tools/clang/tools/extra/cl > = ang-tidy/plugin/CMakeFiles/obj.clangTidyPlugin.dir/ClangTidyPlugin.cpp.o = -c = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/tools/clang/tools/ext= ra/clang-tidy/plugin/ClangTidyPlugin.cpp > FAILED: = tools/clang/tools/extra/clang-tidy/plugin/CMakeFiles/obj.clangTidyPlugin.d= ir/ClangTidyPlugin.cpp.o=20 > /usr/bin/c++ -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS = -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS = -Itools/clang/tools/extra/clang-tidy/plugin = -I/wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/tool > s/clang/tools/extra/clang-tidy/plugin = -I/wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/tools/clang/include= -Itools/clang/include -Iinclude = -I/wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/ > include -O2 -pipe -DNDEBUG -fstack-protector-strong -isystem = /usr/local/include -fno-strict-aliasing -DNDEBUG -isystem = /usr/local/include -fPIC -fvisibility-inlines-hidden -Werror=3Ddate-time = -Werror=3Du > nguarded-availability-new -Wall -Wextra -Wno-unused-parameter = -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic = -Wno-long-long -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noe > xcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor = -Wstring-conversion -fdiagnostics-color -ffunction-sections = -fdata-sections -fno-common -Woverloaded-virtual -Wno-nested-anon-types = -O2 -pipe -D > NDEBUG -fstack-protector-strong -isystem /usr/local/include = -fno-strict-aliasing -DNDEBUG -isystem /usr/local/include = -fno-exceptions -std=3Dc++14 -MD -MT = tools/clang/tools/extra/clang-tidy/plugin/CMa > keFiles/obj.clangTidyPlugin.dir/ClangTidyPlugin.cpp.o -MF = tools/clang/tools/extra/clang-tidy/plugin/CMakeFiles/obj.clangTidyPlugin.d= ir/ClangTidyPlugin.cpp.o.d -o tools/clang/tools/extra/clang-tidy/plu > gin/CMakeFiles/obj.clangTidyPlugin.dir/ClangTidyPlugin.cpp.o -c = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/tools/clang/tools/ext= ra/clang-tidy/plugin/ClangTidyPlugin.cpp > PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and = include the crash backtrace, preprocessed source, and associated run = script. > Stack dump: > 0. Program arguments: /usr/bin/c++ -D_GNU_SOURCE = -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS = -Itools/clang/tools/extra/clang-tidy/plugin = -I/wrkdirs/usr/ports/devel/llvm1 > 0/work/llvm-10.0.1.src/tools/clang/tools/extra/clang-tidy/plugin = -I/wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/tools/clang/include= -Itools/clang/include -Iinclude = -I/wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/include -O2 -pipe = -DNDEBUG -fstack-protector-strong -isystem /usr/local/include = -fno-strict-aliasing -DNDEBUG -isystem /usr/local/include -fPIC = -fvisibility-inlines-hidden -Werror=3Ddate-time = -Werror=3Dunguarded-availability-new -Wall -Wextra -Wno-unused-parameter = -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic = -Wno-long-long -Wimplicit-fallthrough -Wcovered-switch-default = -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor = -Wstring-conversion -fdiagnostics-color -ffunction-sections = -fdata-sections -fno-common -Woverloaded-virtual -Wno-nested-anon-types = -O2 -pipe -DNDEBUG -fstack-protector-strong -isystem /usr/local/include = -fno-strict-aliasing -DNDEBUG -isystem /usr/local/include = -fno-exceptions -std=3Dc++14 -MD -MT = tools/clang/tools/extra/clang-tidy/plugin/CMakeFiles/obj.clangTidyPlugin.d= ir/ClangTidyPlugin.cpp.o -MF = tools/clang/tools/extra/clang-tidy/plugin/CMakeFiles/obj.clangTidyPlugin.d= ir/ClangTidyPlugin.cpp.o.d -o = tools/clang/tools/extra/clang-tidy/plugin/CMakeFiles/obj.clangTidyPlugin.d= ir/ClangTidyPlugin.cpp.o -c = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/tools/clang/tools/ext= ra/clang-tidy/plugin/ClangTidyPlugin.cpp=20 > 1. = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/tools/clang/include/c= lang/Frontend/Utils.h:165:76: current parser token ')' > 2. = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/tools/clang/include/c= lang/Frontend/Utils.h:40:1: parsing namespace 'clang' > 3. = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/tools/clang/include/c= lang/Frontend/Utils.h:149:1: parsing struct/union/class body = 'clang::ModuleDependencyCollector' > 4. = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/tools/clang/include/c= lang/Frontend/Utils.h:165:47: parsing function body = 'clang::ModuleDependencyCollector::insertSeen' > 5. = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/tools/clang/include/c= lang/Frontend/Utils.h:165:47: in compound statement ('{}') > 6. /usr/include/c++/v1/utility:297:29: instantiating class = definition 'std::__1::pair, = bool>' > 7. = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/include/llvm/ADT/Stri= ngMap.h:34:34: instantiating class definition = 'llvm::StringMapIterator' > 8. = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/include/llvm/ADT/Stri= ngMap.h:488:7: instantiating class definition = 'llvm::StringMapIterBase, = llvm::StringMapEntry>' > 9. = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/include/llvm/ADT/iter= ator.h:67:7: instantiating class definition = 'llvm::iterator_facade_base, = std::__1::forward_iterator_tag, llvm::StringMapEntry, = long, llvm::StringMapEntry *, = llvm::StringMapEntry &>' > #0 0x0000000012f52ed0 llvm::sys::PrintStackTrace(llvm::raw_ostream&) = (/usr/bin/c+++0x12f52ed0) > #1 0x0000000012f50770 llvm::sys::RunSignalHandlers() = (/usr/bin/c+++0x12f50770) > #2 0x0000000012ee4778 CrashRecoverySignalHandler(int) = (/usr/bin/c+++0x12ee4778) > #3 0x0000000813f2b2b4 (/lib/libthr.so.3+0x2f2b4) > c++: error: clang frontend command failed due to signal (use -v to see = invocation) > FreeBSD clang version 11.0.1 (git@github.com:llvm/llvm-project.git = llvmorg-11.0.1-0-g43ff75f2c3fe) > Target: powerpc64-unknown-freebsd14.0 > Thread model: posix > InstalledDir: /usr/bin > c++: note: diagnostic msg:=20 > ******************** >=20 > PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: > Preprocessed source(s) and associated run script(s) are located at: > c++: note: diagnostic msg: /tmp/ClangTidyPlugin-21aaa2.cpp > c++: note: diagnostic msg: /tmp/ClangTidyPlugin-21aaa2.sh > c++: note: diagnostic msg:=20 >=20 >=20 > Note: Unfortunately, poudriere does not capture those files > from /tmp/ in the .tbz for the build failure. >=20 No *.core was left behind in the expanded .tbz . /var/log/messages did not have a line reporting any pid signal lines in the time frame. Repeating the failing command in the expansion of the .tbz did not repeat the problem. It looks to be another example of there being one or more not-readily-repeatable problems occurring. It will be many hours before the new poudriere bulk can get back to that same point, but with just the one builder and the one job for the builder. (Still allowing use of an active process per cpu.) The normal/prior bulk runs were allowing 2 jobs. Note: /lib/libthr.so.3+0x2f2b4 seems to be in code from the "static void handle_signal . . ." routine. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-ppc@freebsd.org Fri Feb 5 17:35:50 2021 Return-Path: Delivered-To: freebsd-ppc@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1C99254D76B for ; Fri, 5 Feb 2021 17:35:50 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DXMyY2g5Bz3qBh for ; Fri, 5 Feb 2021 17:35:49 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by mail-io1-xd30.google.com with SMTP id u8so7869761ior.13 for ; Fri, 05 Feb 2021 09:35:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=Q7pXmdaeWocqZNt30iiBBERwQlryoHPDxg5ESebXEl0=; b=o6LHQ3iw7P3K7rr+Qilu7FjbfpY/h7jjZ/VhOXQrE8pkhDvydI7JAJsmFDguIDVg/9 XCWcih+heQ59IiV7jFLuAQAGS2OBFfkiGDjYzzBinE0G3yKmvf8+NW4Mqv0qGHRkQA2R qtpQkgABQKyexgtlSewlt8vQUtpZyqKIft/YXsJnAC7ve+JPDH+s+a+EJrkAmVAip2uy PBqcp1xFHVPEq57rjMv2RC7xmxjzitO+vKQ4l6KJXl+P8APaXLf1GB309xvs7CmXh7Je j68lzSuEwKAOLRIpB8H6EgYTpVkSR8mBoeSGJ+qkaU6g+NAdArfNtNRdvptTrJ7uWgME zwkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=Q7pXmdaeWocqZNt30iiBBERwQlryoHPDxg5ESebXEl0=; b=fyujv12oPPohJS80AcbkyNlx5rqR99r6+6iO6OPttCTU0Dy//1xMH7SXITAn2FrU0S Mm2TZ3PYEG/lGewLvx51A37YpB62cwey9NOtDcqSDfEpLEcN9OJ3Ws714OO2AXEls1Mg GOyv9a3f5LiDPtaQrImWfJQpqR0t24r7vnS7TbY0B3LNG+zv7HQNI88+tUH7HLk383k3 vkA1vfv+Bh2+KxGVz69aDYRQ4rJ8VCvjS4RWZFYRGFAc3ea1Wyhgl8azJqx+hqak6HFE 32S9a5aTCC14t7zT8YjdhtnZync+K6Q7PvH/wyR8UAVTqpK2tfzVllXgsL4hRDIrF3AK gbiw== X-Gm-Message-State: AOAM532ibry5swoW2QQp69TTwnO/y2M/j4HKw9EUUiVGzIgvCMQYGxEx sbuWPmkSoQvYr1I+huiFIyoqT3NdAU7UHw== X-Google-Smtp-Source: ABdhPJwJdLVDiA7f8FOASKPVE+ecf2xKormWE0W1friMZkJBzpF8n2CZxTrdZqrwHyaNRCdarDPVCA== X-Received: by 2002:a05:6602:3154:: with SMTP id m20mr5097897ioy.188.1612546546826; Fri, 05 Feb 2021 09:35:46 -0800 (PST) Received: from ralga.knownspace (173-18-9-215.client.mchsi.com. [173.18.9.215]) by smtp.gmail.com with ESMTPSA id g16sm4464412iln.29.2021.02.05.09.35.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 05 Feb 2021 09:35:46 -0800 (PST) Date: Fri, 5 Feb 2021 11:35:44 -0600 From: Justin Hibbits To: Mark Millard via freebsd-ppc Subject: Re: main (14-CURRENT) may be unstable on powerpc64 Message-ID: <20210205113544.349ee77e@ralga.knownspace> In-Reply-To: <28E64465-8A99-43CF-8B4F-044533EA03C4@yahoo.com> References: <28E64465-8A99-43CF-8B4F-044533EA03C4.ref@yahoo.com> <28E64465-8A99-43CF-8B4F-044533EA03C4@yahoo.com> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; powerpc64-portbld-freebsd13.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4DXMyY2g5Bz3qBh X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=o6LHQ3iw; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of chmeeedalf@gmail.com designates 2607:f8b0:4864:20::d30 as permitted sender) smtp.mailfrom=chmeeedalf@gmail.com X-Spamd-Result: default: False [-2.26 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[2607:f8b0:4864:20::d30:from]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; RECEIVED_SPAMHAUS_PBL(0.00)[173.18.9.215:received]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.74)[0.740]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-ppc@freebsd.org]; SPAMHAUS_ZRD(0.00)[2607:f8b0:4864:20::d30:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::d30:from]; FREEMAIL_CC(0.00)[yahoo.com]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-ppc] X-Mailman-Approved-At: Sat, 06 Feb 2021 08:16:42 +0000 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2021 17:35:50 -0000 On Fri, 5 Feb 2021 04:05:55 -0800 Mark Millard via freebsd-ppc wrote: > I am running on a 2-socket/1-core-each PowerMac G5 > (8 GiByte RAM) based on: > > # ~/fbsd-based-on-what-freebsd-main.sh > merge-base: 847dfd2803f6c8b077e3ebc68e35adff2c79a65f > merge-base: CommitDate: 2021-02-03 21:24:22 +0000 > 325d7069b027 (HEAD -> mm-src) mm-src snapshot for mm's patched build > in git context. 847dfd2803f6 (freebsd/main, freebsd/HEAD, pure-src, > main) readelf: do not trucate section name with -W FreeBSD FBSDG5L2 > 14.0-CURRENT FreeBSD 14.0-CURRENT mm-src-n244624-325d7069b027 > GENERIC64vtsc-NODBG-dcons powerpc powerpc64 1400003 1400003 > > I attempted to rebuild the ports to get FreeBSD:14 based > versions but got the below oddity in the process: > > # poudriere bulk -jFBSDpowerpc64 -c -w -f > ~/origins/powerpc64-origins.txt . . . > ======================= >============================ ===> Building package for > >gettext-tools-0.21 > Child process pid=44950 terminated abnormally: Segmentation fault > Child process pid=44956 terminated abnormally: Segmentation fault > actual-package-depends: dependency on /usr/local/lib/libtextstyle.so > not registered (normal if it belongs to base) Child process pid=44958 > terminated abnormally: Segmentation fault Child process pid=44962 > terminated abnormally: Segmentation fault Child process pid=44971 > terminated abnormally: Segmentation fault actual-package-depends: > dependency on /usr/local/lib/libintl.so not registered (normal if it > belongs to base) Child process pid=44973 terminated abnormally: > Segmentation fault Child process pid=44977 terminated abnormally: > Segmentation fault Child process pid=44980 terminated abnormally: > Segmentation fault actual-package-depends: dependency on > /usr/local/bin/indexinfo not registered (normal if it belongs to > base) Child process pid=44982 terminated abnormally: Segmentation > fault . . . > > Unfortunately, at the package phase, the above sort of thing > does not lead to a saved copy of the work/ area for the port > in poudriere and was classified as a Success. I do have the > console report: > > Feb 4 03:14:17 FBSDG5L2 kernel: pid 44950 (pkg-static), jid 4, uid > 0: exited on signal 11 Feb 4 03:14:17 FBSDG5L2 kernel: pid 44956 > (pkg-static), jid 4, uid 0: exited on signal 11 Feb 4 03:14:17 > FBSDG5L2 kernel: pid 44958 (pkg-static), jid 4, uid 0: exited on > signal 11 Feb 4 03:14:17 FBSDG5L2 kernel: pid 44962 (pkg-static), > jid 4, uid 0: exited on signal 11 Feb 4 03:14:17 FBSDG5L2 kernel: > pid 44971 (pkg-static), jid 4, uid 0: exited on signal 11 Feb 4 > 03:14:17 FBSDG5L2 kernel: pid 44973 (pkg-static), jid 4, uid 0: > exited on signal 11 Feb 4 03:14:17 FBSDG5L2 kernel: pid 44977 > (pkg-static), jid 4, uid 0: exited on signal 11 Feb 4 03:14:17 > FBSDG5L2 kernel: pid 44980 (pkg-static), jid 4, uid 0: exited on > signal 11 Feb 4 03:14:17 FBSDG5L2 kernel: pid 44982 (pkg-static), > jid 4, uid 0: exited on signal 11 > > so which program got the failures is known but I > did not end up with core files or other such. Also > they all seem to have happened with the same > reported time (second scale). (The messages above > do not show "(core dumped)" either, so even with > a copy of the work/ area there probably would not > have been evidence.) > > One point is that the time frame means that the once-a-day > checking activity (defaults) was likely running in parallel > with the poudriere activity. > > The above left the "deps" information missing for > gettex-tools-0.21 . > > When the poudriere run finished, the status was 7 failures > and 153 skipped because of lack of "deps" information for > gettext-tools-0.21 : > > [FBSDpowerpc64-default] [2021-02-04_02h19m21s] [committing:] Queued: > 476 Built: 316 Failed: 7 Skipped: 153 Ignored: 0 Tobuild: 0 > Time: 24:28:45 > > For reference, from early in the build: > > [00:24:17] [02] [00:00:00] Building devel/gettext-tools | > gettext-tools-0.21 . . . > [00:55:34] [02] [00:31:17] Finished devel/gettext-tools | > gettext-tools-0.21: Success > > > I then tried: > > # poudriere bulk -jFBSDpowerpc64 -i -C -w devel/gettext-tools > > and it built just fine this time: > > [FBSDpowerpc64-default] [2021-02-05_02h50m31s] [committing:] Queued: > 1 Built: 1 Failed: 0 Skipped: 0 Ignored: 0 Tobuild: 0 Time: > 00:23:26 > > > In all cases, each poudriere job was allow to have an active > process per cpu (so 2 active processes per job). The retry, > of course, was just one poudriere job. > > So far I've no evidence of problems with the other 315 of 316 > built ports from the first run, including no more pkg-static > failures. > > > I have started up an attempted build of the failed and skipped > ports. > > > I have no known way to repeat the problem on demand and no > evidence for specifically where pkg-static was executing when > it failed. > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) This is probably fallout from 710e45c4b, which has since been reverted. 710e45c4b broke other things like swig as well, which caused a lot of poudriere fallout for me (devel/llvm* failed because swig crashed). Try updating past 33f0540b1 and testing again. - Justin From owner-freebsd-ppc@freebsd.org Sat Feb 6 20:55:21 2021 Return-Path: Delivered-To: freebsd-ppc@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C8D42536EA9 for ; Sat, 6 Feb 2021 20:55:20 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-55.consmr.mail.gq1.yahoo.com (sonic315-55.consmr.mail.gq1.yahoo.com [98.137.65.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DY4LF66g4z3n78 for ; Sat, 6 Feb 2021 20:55:17 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1612644912; bh=tVJpJeYnFvrvMmiVCuRQ7qF9B99bdwG1eElNTAIVakr=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=AJU6kqtdNCXrGU0lEVE50Cbva1KiIM1JomjTIn7b19vC6WR9/kfS3Ij45EACc+BPWT0fWBnNaCM/4gmG84aAbY7upi495LLnAPnM9V9hzGrjKko1PiwC4NTE21hAveQmNewQ2bFbaVlCRXbGgD2JyWORumNqu+T/fCFD5yatWXasJzfQ9aLUUMkHVS19DAdsvoXJERgtlm91hKS51aAY9bGpQKBIyiySAm8l/lMK0QP7N49golvG880CwuSWy1GZWlzgVFO4LF8nuUcAVbgZGlEFWU4ud7zhkxLSuAfBv7xJFegTqTcrscxB9FpcNN4Uf6dCaLBfn8dqEiFYpZmq6Q== X-YMail-OSG: FxMUZawVM1mmChaFEz0l8O5gu1FrmbaQrykYqvSOrKyHHRqhmJu28Lgg8FfJmIk bqU0orgnVAIwGwkI5K9XrXkPwKzcAIFimxs9aZnTr3mFvKMKZvqV2Phbjl_3UQR3SaZzHkup8RrF OCtBv.g7a9QRz8MC1p.FAYG3Ms6O6eAKgKqgc014ORvhY9Xovmoqh5uqDklLNLXcN3AC7rar8Sz0 0GTRTQhmiHcLjCz8NoDbxOxS6M__r2w.fO8D6myMntn7BHO7bYmSq.XtqYnXMpCzeZh43KYAE8kC kNI78zyh.wumhPJt2kpWsjZinTj5ZVIEISKVOHnrQbknnXupRblo4Yy5PIvF_e3OiJeKM4BkooYK qEmfJEN3BaDJy3E33g6jlRUeXQHAbN6LJVmBUbUNqhsfz84dMahdqtzXIxScorJqtB8OxKcDrdqg sFc5yRfft1YCiw8bLpRBIwsenP2ckXKOafql5ezvLhlhk8gHHxFF1RfqQNryP9gxop53gkSwyUie Zs89_2qr3BQLWGrrpfpCBXrZ4fv6AjShScwPDeRJm1NU36Pq_tL1MqiVdMZExAt1ECTtsyDRM1Kv sat5C0QP..YJWC.8jcQgIqsJmf8d0gbGy_kHhApnJ7pd6nbV7ZQBzy57Nc9NysehJk8gan6SG.2U 417C5x2jwprckTVyhdTYqVM52F1.GZQNK7eY8DNpjriDV_D.vnbogzawEZZw3jVPt6N4BuCa2l03 HRYD4wpvMcElBG.KGYDj._1.CtZvA8nqzVoxxUnYEugwcgUxBsO_SlAHb_ag8EAtoV6nUecQKqnZ rBCzDG8DQ_dUdiWSOdVVDNa1AGNGGjor8idlO__NJRZ1JPRm395JT9iXY.p4nZhpMUcLL0wy9eIo 3p9rfjw0KkpUC60AOd5OzgP8nd3L9w1AU3_xXpprA7iolB6i1TNZjaJsyvk6Nk3Gm9xu6WHjyEu5 zf.O8ZlYHZqmhqADeT6m3_mTclbAeonMVc8HsPTf3IDyuEcRf6EcMGX9ryIZbS_tRYPN_gsZlF5p t9RuKKl6HogIv3GvZT_ZeqH_IqVtfTxU.l_rFR9DilSaEcKzZdMDfaVQNSdDegGu.15wiIN8ooUR 2NwuRBapAnu8.oZtq3HLYVU71GlLetiAMH7sEmTBaFilIV9.uu3xdlyyu.dKRNsa0LKaz2LSgUVz E1ncWu6GldOAmpaHz_U07SBb98a6HNHGX7ba2ribAD8AhyG.X4xHxSYmTE_T.mduZiTeQoYpPnMZ 30ozIqSc7OzWGRrjEsq.Cn8Z6IGBpeHLxdH0JYZdh_CD0POHVyOobfhAYYzdgYoRZ1lewFnc1qap 4ELOOQ5YGYHGG6JiBFV_XVbaVb0X5PfOOKagEkomE2GPCBd2dfkAU8mmvtg5CNzKqnPQRXbYvJMH 9g8fLYYvnzwn7lLMavTNSAkshkuBxQyFMGQdLnyBvViYJ4Rg5b84OcDL9X3vKSKZznmKCaEO_4YE .CB1WaIcHOnGoUzkr6ZGueKA_yNxIlcnq9JhxE1FB8J4N1N6q89mII8dk2lhxWIfc1eKLKNTXa1r yYdDfI7JPLlXo2HzNVnPs0w.fkjFgp.YuM4I09VS4wuxKV37R66sGyYrJzz9C2JgYnagtJ4fEQlp SUmjJwoshN.pUsF5DI.kNh1lHAYqX4n8ClqW5QAPA2FtbGAsIzrj3Gp1oHXBoFkhRlCrGFgqpRNy GFObLoCDGrW7nKXXsJ05l7E2JN2lvMnwBLhOYYbWRccaqSemGGbDkcfyehzxypfKwyvcfBj9EbY1 CVBYFQDALYT9yXwugjNvEq118MHdJ.C9TY0UskRRP8WzXfbdEnTQrTZmZdqNEq73y86SgWtCDSK0 NW6Esh0tZ0IS.55qZ5cwIRUbBANyBA0ctzz0vFiS8Cx9DpoJUbSaNqHVsd8ZmX5uflNGrwTYeow2 x4FgQf65ZZscnwmkTU.z6_JCiMCIw2XxzCyxIvsEDYRLIDD6eTTWA61z3BInz4X5aWVXpNBnyHVR j3CajT2fP0YSCMzu8YMo6xMbs3Vp2y.6xq_EU3V9g1s7_xXyWKh_vxB1gFp3oePveqsL215iWFcB .z3IlkUZG2gos0kyL7JNpw2Xbxqin2o_IWjNe5NTm29MBM.5tXt6CxfCRWTEOuPO2Rc8.HrGgds2 u9cD4o3oTMtXKfqEEGU5boVQxXIxDBlK4KXqnhlsQgsYUBfeYukBKSGl.wpOnWqz1LTbBuG.5qeB .LEDjSOTzcDdgmryC5uH2Xpk3HfalLLWG.XRyWyZNKB8hm02yMmoWnG6gecK7lHZcxhaghcw6iQO AF54e2wC389dhs6Kn2QVqggMmJK8jPX2U4EVgEB27sD7VtNXFKG0JdVy.UIztAk8qC3yh8K3ybBD sBaPpOtQBNySCUjj_GT8smPmIp_mjCO5dBh9YpS1YuyVZpLGTcrSh5nX6kyHZjZD59cA.Gi0M.gl pku6R4DJariLt5cMyPg.DRxTAdJgg3QKAT6YqO.pxIEPq1Sa2ynG3XL4nqED_lChszABzeiYs.p1 FV275VUMnRXZfpnODwJ5FEshyuI4ULexK X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Sat, 6 Feb 2021 20:55:12 +0000 Received: by smtp410.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID e002a6313d18d5024715ac36c8125ec8; Sat, 06 Feb 2021 20:55:06 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Subject: Re: main (14-CURRENT) may be unstable on powerpc64 From: Mark Millard In-Reply-To: Date: Sat, 6 Feb 2021 12:55:03 -0800 Cc: freebsd-ppc Content-Transfer-Encoding: quoted-printable Message-Id: <2009AE57-9720-4FF2-9EC9-8F5EFDCB9E78@yahoo.com> References: <28E64465-8A99-43CF-8B4F-044533EA03C4.ref@yahoo.com> <28E64465-8A99-43CF-8B4F-044533EA03C4@yahoo.com> <20210205113544.349ee77e@ralga.knownspace> <52899C49-E0DF-4E19-A89F-8B9376B8F1F5@yahoo.com> <051FDA5B-C529-4805-89F1-3802D75FC7B7@yahoo.com> To: Justin Hibbits X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4DY4LF66g4z3n78 X-Spamd-Bar: - X-Spamd-Result: default: False [-1.50 / 15.00]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.65.31:from]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(1.00)[1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.65.31:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.31:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.31:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-ppc] X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Feb 2021 20:55:23 -0000 On 2021-Feb-5, at 23:49, Mark Millard wrote: > On 2021-Feb-5, at 21:34, Mark Millard wrote: >=20 >> On 2021-Feb-5, at 10:34, Mark Millard wrote: >>=20 >> On 2021-Feb-5, at 09:35, Justin Hibbits = wrote: >>>=20 >>>> On Fri, 5 Feb 2021 04:05:55 -0800 >>>> Mark Millard via freebsd-ppc wrote: >>>>=20 >>>>> . . . >>>>=20 >>>> This is probably fallout from 710e45c4b, which has since been = reverted. >>>> 710e45c4b broke other things like swig as well, which caused a lot = of >>>> poudriere fallout for me (devel/llvm* failed because swig crashed). >>>>=20 >>>> Try updating past 33f0540b1 and testing again. >>>>=20 >>>=20 >>> The above is based on 847dfd2803f6, which is after 33f0540b1 . . . >>>=20 >>> = https://cgit.freebsd.org/src/log/?qt=3Drange&q=3D33f0540b1~1..847dfd2803f6= >>> shows: >>>=20 >>> Commit message (Expand) Author Age Files Lines >>> * readelf: do not trucate section name with -W Ed Maste = 45 hours 1 -4/+9 >>> * readelf: decode LA48 and ASG_DISABLE feature flags Ed Maste = 45 hours 1 -0/+2 >>> * Add a VM flag to prevent reclaim on a failed contig allocation = Ryan Stone 45 hours 3 -2/+11 >>> * dwmmc: Multiple busdma fixes. Michal Meloun 46 hours = 1 -15/+32 >>> * linux: remove locks around callout_drain in timerfd_close() = shu 46 hours 1 -2/+0 >>> * Revert "Reimplement strlen" Mateusz Guzik 47 hours = 2 -53/+108 >>>=20 >>> (I Probably should have shown that in the original >>> message, given the difficulty in determining the >>> relative order of referenced commits.) >>>=20 >>> Before updating to be 847dfd2803f6 based, I had also >>> previously hit the swig issue with the llvm10 build. >>> That problem failed reliably until after I'd updated >>> past the revert. (Not trusting the other things built >>> is why I did a -c poudriere bulk after updating to an >>> environment based on after the revert.) >>>=20 >>> The variability in the pkg-static behavior this time >>> suggests race conditions are involved, though not >>> frequent failures. >>>=20 >>>=20 >>=20 >> It still failed to build llvm10 but the error reporoted >> is rather different. At least there is a .tbz for me to >> expand. I may end up with more to report after that. >>=20 >> Here is the log file's report: >>=20 >> [2996/4558] /usr/bin/c++ -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS = -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS = -Itools/clang/tools/extra/clang-tidy/plugin = -I/wrkdirs/usr/ports/devel/llvm10/work/llvm-10. >> 0.1.src/tools/clang/tools/extra/clang-tidy/plugin = -I/wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/tools/clang/include= -Itools/clang/include -Iinclude = -I/wrkdirs/usr/ports/devel/llvm10/work/llvm >> -10.0.1.src/include -O2 -pipe -DNDEBUG -fstack-protector-strong = -isystem /usr/local/include -fno-strict-aliasing -DNDEBUG -isystem = /usr/local/include -fPIC -fvisibility-inlines-hidden -Werror=3Ddate-ti >> me -Werror=3Dunguarded-availability-new -Wall -Wextra = -Wno-unused-parameter -Wwrite-strings -Wcast-qual = -Wmissing-field-initializers -pedantic -Wno-long-long = -Wimplicit-fallthrough -Wcovered-switch-defa >> ult -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor = -Wstring-conversion -fdiagnostics-color -ffunction-sections = -fdata-sections -fno-common -Woverloaded-virtual -Wno-nested-anon-types=20= >> -O2 -pipe -DNDEBUG -fstack-protector-strong -isystem = /usr/local/include -fno-strict-aliasing -DNDEBUG -isystem = /usr/local/include -fno-exceptions -std=3Dc++14 -MD -MT = tools/clang/tools/extra/clang-tid >> y/plugin/CMakeFiles/obj.clangTidyPlugin.dir/ClangTidyPlugin.cpp.o -MF = tools/clang/tools/extra/clang-tidy/plugin/CMakeFiles/obj.clangTidyPlugin.d= ir/ClangTidyPlugin.cpp.o.d -o tools/clang/tools/extra/cl >> = ang-tidy/plugin/CMakeFiles/obj.clangTidyPlugin.dir/ClangTidyPlugin.cpp.o = -c = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/tools/clang/tools/ext= ra/clang-tidy/plugin/ClangTidyPlugin.cpp >> FAILED: = tools/clang/tools/extra/clang-tidy/plugin/CMakeFiles/obj.clangTidyPlugin.d= ir/ClangTidyPlugin.cpp.o=20 >> /usr/bin/c++ -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS = -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS = -Itools/clang/tools/extra/clang-tidy/plugin = -I/wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/tool >> s/clang/tools/extra/clang-tidy/plugin = -I/wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/tools/clang/include= -Itools/clang/include -Iinclude = -I/wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/ >> include -O2 -pipe -DNDEBUG -fstack-protector-strong -isystem = /usr/local/include -fno-strict-aliasing -DNDEBUG -isystem = /usr/local/include -fPIC -fvisibility-inlines-hidden -Werror=3Ddate-time = -Werror=3Du >> nguarded-availability-new -Wall -Wextra -Wno-unused-parameter = -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic = -Wno-long-long -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noe >> xcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor = -Wstring-conversion -fdiagnostics-color -ffunction-sections = -fdata-sections -fno-common -Woverloaded-virtual -Wno-nested-anon-types = -O2 -pipe -D >> NDEBUG -fstack-protector-strong -isystem /usr/local/include = -fno-strict-aliasing -DNDEBUG -isystem /usr/local/include = -fno-exceptions -std=3Dc++14 -MD -MT = tools/clang/tools/extra/clang-tidy/plugin/CMa >> keFiles/obj.clangTidyPlugin.dir/ClangTidyPlugin.cpp.o -MF = tools/clang/tools/extra/clang-tidy/plugin/CMakeFiles/obj.clangTidyPlugin.d= ir/ClangTidyPlugin.cpp.o.d -o tools/clang/tools/extra/clang-tidy/plu >> gin/CMakeFiles/obj.clangTidyPlugin.dir/ClangTidyPlugin.cpp.o -c = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/tools/clang/tools/ext= ra/clang-tidy/plugin/ClangTidyPlugin.cpp >> PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and = include the crash backtrace, preprocessed source, and associated run = script. >> Stack dump: >> 0. Program arguments: /usr/bin/c++ -D_GNU_SOURCE = -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS = -Itools/clang/tools/extra/clang-tidy/plugin = -I/wrkdirs/usr/ports/devel/llvm1 >> 0/work/llvm-10.0.1.src/tools/clang/tools/extra/clang-tidy/plugin = -I/wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/tools/clang/include= -Itools/clang/include -Iinclude = -I/wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/include -O2 -pipe = -DNDEBUG -fstack-protector-strong -isystem /usr/local/include = -fno-strict-aliasing -DNDEBUG -isystem /usr/local/include -fPIC = -fvisibility-inlines-hidden -Werror=3Ddate-time = -Werror=3Dunguarded-availability-new -Wall -Wextra -Wno-unused-parameter = -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic = -Wno-long-long -Wimplicit-fallthrough -Wcovered-switch-default = -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor = -Wstring-conversion -fdiagnostics-color -ffunction-sections = -fdata-sections -fno-common -Woverloaded-virtual -Wno-nested-anon-types = -O2 -pipe -DNDEBUG -fstack-protector-strong -isystem /usr/local/include = -fno-strict-aliasing -DNDEBUG -isystem /usr/local/include = -fno-exceptions -std=3Dc++14 -MD -MT = tools/clang/tools/extra/clang-tidy/plugin/CMakeFiles/obj.clangTidyPlugin.d= ir/ClangTidyPlugin.cpp.o -MF = tools/clang/tools/extra/clang-tidy/plugin/CMakeFiles/obj.clangTidyPlugin.d= ir/ClangTidyPlugin.cpp.o.d -o = tools/clang/tools/extra/clang-tidy/plugin/CMakeFiles/obj.clangTidyPlugin.d= ir/ClangTidyPlugin.cpp.o -c = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/tools/clang/tools/ext= ra/clang-tidy/plugin/ClangTidyPlugin.cpp=20 >> 1. = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/tools/clang/include/c= lang/Frontend/Utils.h:165:76: current parser token ')' >> 2. = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/tools/clang/include/c= lang/Frontend/Utils.h:40:1: parsing namespace 'clang' >> 3. = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/tools/clang/include/c= lang/Frontend/Utils.h:149:1: parsing struct/union/class body = 'clang::ModuleDependencyCollector' >> 4. = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/tools/clang/include/c= lang/Frontend/Utils.h:165:47: parsing function body = 'clang::ModuleDependencyCollector::insertSeen' >> 5. = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/tools/clang/include/c= lang/Frontend/Utils.h:165:47: in compound statement ('{}') >> 6. /usr/include/c++/v1/utility:297:29: instantiating class = definition 'std::__1::pair, = bool>' >> 7. = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/include/llvm/ADT/Stri= ngMap.h:34:34: instantiating class definition = 'llvm::StringMapIterator' >> 8. = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/include/llvm/ADT/Stri= ngMap.h:488:7: instantiating class definition = 'llvm::StringMapIterBase, = llvm::StringMapEntry>' >> 9. = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/include/llvm/ADT/iter= ator.h:67:7: instantiating class definition = 'llvm::iterator_facade_base, = std::__1::forward_iterator_tag, llvm::StringMapEntry, = long, llvm::StringMapEntry *, = llvm::StringMapEntry &>' >> #0 0x0000000012f52ed0 llvm::sys::PrintStackTrace(llvm::raw_ostream&) = (/usr/bin/c+++0x12f52ed0) >> #1 0x0000000012f50770 llvm::sys::RunSignalHandlers() = (/usr/bin/c+++0x12f50770) >> #2 0x0000000012ee4778 CrashRecoverySignalHandler(int) = (/usr/bin/c+++0x12ee4778) >> #3 0x0000000813f2b2b4 (/lib/libthr.so.3+0x2f2b4) >> c++: error: clang frontend command failed due to signal (use -v to = see invocation) >> FreeBSD clang version 11.0.1 (git@github.com:llvm/llvm-project.git = llvmorg-11.0.1-0-g43ff75f2c3fe) >> Target: powerpc64-unknown-freebsd14.0 >> Thread model: posix >> InstalledDir: /usr/bin >> c++: note: diagnostic msg:=20 >> ******************** >>=20 >> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >> Preprocessed source(s) and associated run script(s) are located at: >> c++: note: diagnostic msg: /tmp/ClangTidyPlugin-21aaa2.cpp >> c++: note: diagnostic msg: /tmp/ClangTidyPlugin-21aaa2.sh >> c++: note: diagnostic msg:=20 >>=20 >>=20 >> Note: Unfortunately, poudriere does not capture those files >> from /tmp/ in the .tbz for the build failure. >>=20 >=20 > No *.core was left behind in the expanded .tbz . > /var/log/messages did not have a line reporting > any pid signal lines in the time frame. >=20 > Repeating the failing command in the expansion of > the .tbz did not repeat the problem. >=20 > It looks to be another example of there being one > or more not-readily-repeatable problems occurring. >=20 > It will be many hours before the new poudriere bulk > can get back to that same point, but with just the > one builder and the one job for the builder. (Still > allowing use of an active process per cpu.) The > normal/prior bulk runs were allowing 2 jobs. >=20 >=20 > Note: /lib/libthr.so.3+0x2f2b4 seems to be in code > from the "static void handle_signal . . ." routine. >=20 The devel/llvm10 rebuild attempt is well past the [2996/4558] point now: working on [3056/4558] . But it looks like it may have 6+ hrs to go to complete (if successful). So far: [FBSDpowerpc64-default] [2021-02-05_23h31m51s] [parallel_build:] Queued: = 1 Built: 0 Failed: 0 Skipped: 0 Ignored: 0 Tobuild: 1 Time: = 13:01:28 [01]: devel/llvm10 | llvm10-10.0.1_3 = build (12:50:05 / 12:59:42) [13:02:12] Logs: = /usr/local/poudriere/data/logs/bulk/FBSDpowerpc64-default/2021-02-05_23h31= m51s I've no reasonable way to figure out if the parallel activity from letting 2 jobs run (so: higher load average) would have made a difference or not. Getting a very detailed repetition for such is difficult so any variation in what context it failed in makes useful comparison/contrast problematical. But, if this run completes successfully, there will be 101 more ports to let poudriere bulk try to build, one of which would be devel/llvm11 . =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)