From owner-freebsd-ppc@freebsd.org Sun May 3 01:47:03 2020 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 529942CD2A9 for ; Sun, 3 May 2020 01:47:03 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-21.consmr.mail.gq1.yahoo.com (sonic306-21.consmr.mail.gq1.yahoo.com [98.137.68.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 49F8445ggCz41Q2 for ; Sun, 3 May 2020 01:47:00 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: Je91.JsVM1ltv_HQv7RPo8lTpTRycFoqzySPqqjE0TqqPJDSgl2wrD6oF6S1XVs d1qDmWaJAJehOqk8oe.7Ipt.G7QV8bj.otr9HeKeoxY2i5BWR4tTNwKYEVkkvLLomHdk27efm6Pn R00XHn8DwOcJpZsJ.K63G8ou5VoF5N840cQH2ECzAu18TZoFJFO3yZBfIdd23ZkPtQk9U98ePpvo Rdewpte3qUgIQoRa7ibTgDLHZtmiCjkRn45qZHjVRPFo65PUvXl1xZxuRpV7fohA9OIuaw6gqIa. RzT7hvdDspYdvyLSm2pG.0POTWCOJh7JtGSSX6scZrgppN1K1HWhjmMQGOrS8makSIKlyFFo7Gyx G8ACMe0g2kmOofKxrsYEPrBPqu6e_bXh8L7WsXYRwzxlYkQvxgejllkIkG8icHcLEkAhZ2fJ21jY IwEoZBmPhGealeVUAciF68JwoODAXlT5eMujt6urX.ptkVKQGYcaMsKzlhE4Aopu6oTMXAWsCKrn RNtox1Of1er_ZrrMhwJujCSbC48QrR6cal7pPri0tYqaEclSot_R.ndWW5.UlfIShYhdlb0hfqkJ zxM1DDhm4_3CA5bKElKA29U9353rr9ocAZE0hm2DEEWSTQllqJ3cCtcKjeoOr0E8UFwi6x4VIpV4 NS7Nb_563U_i9oEJE7ucID4iR2xxtKa_2UH_8a82ghVwjHJ9tdJnJRZ3xdCM6LekhPYq73d7wNbZ Fd__aMIl021gr6mVGd90tMjS5iu.yz.6B0EYbg065Bax3qFoKebJqDVixns.yM9APzXBcJv2.1bN Us2D6BahOo_CxHox.K7QbC.VU7jJUA0FVvVpYn3tIW3Bs4Ihtf7VHULYqni9KFTirOFbsRVM9Tz6 RjNvJO_8RIZXK2ucjENimeYuleDtYo6g0YcDWQBWvsFD6SUDhXX36dqA.J88kFY_etlq9t2AIJly FSwRZl02XU3ZscxsQLI1cH218SEN4S0rxYZp7hZV4alwjcU5YZ6uAPCSD4_e6MEXPQLZN6nBZC6y sqgfH1_H22IYxg7JDYi6AM0Tk1lcg8nKLE0g9AqOM9KYda17o4etBzK_AmwvWzcU2.lRXvtzrLjD vreHvtRlU3Estnhwm1EC96Jx1PGCOcDoBb5ahcHt7xB9h1uREAQKbA.D6iE1Rh.d5yHtHuGr20xw eKsnCfOmv_im7NjHv_7KT0PBl1EFj_bRLqhFmH.3Ypwei7v1tlZBTw7HxVrzU.eyR72_J.de5DLb EcTawSkW5s5UbhYSyhggiFdFE4U4jY8P1wG0sECxjDA3g7GwLf0acgyS36BDTRwv4SiNEd7QIl4j 7eASqnwbMs6RYDXdeY8_Hr10Cyw9EdS6gszJpJY.EVt3A4YlwotCB._0TC1UgLUKTjrPdKR153_L sgW7Fkw9v30nrOIIO0jUTZJTakaPjkvjpOS3ctPXxXB6ZhS.N5nt33jqzor0- Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Sun, 3 May 2020 01:46:58 +0000 Received: by smtp427.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID bd44885a1276e2c9781055283e56c150; Sun, 03 May 2020 01:46:55 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: svn commit: r360233 - in head: contrib/jemalloc . . . : This partially breaks a 2-socket 32-bit powerpc (old PowerMac G4) based on head -r360311 Message-Id: Date: Sat, 2 May 2020 18:46:54 -0700 To: "vangyzen@freebsd.org " , svn-src-head@freebsd.org, FreeBSD Current , FreeBSD Hackers , FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3608.80.23.2.2) References: X-Rspamd-Queue-Id: 49F8445ggCz41Q2 X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.28 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; RCPT_COUNT_FIVE(0.00)[5]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.87)[-0.873,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.91)[-0.909,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ip: (5.87), ipnet: 98.137.64.0/21(0.83), asn: 36647(0.66), country: US(-0.05)]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[84.68.137.98.list.dnswl.org : 127.0.5.0]; RWL_MAILSPIKE_POSSIBLE(0.00)[84.68.137.98.rep.mailspike.net : 127.0.0.17]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2020 01:47:03 -0000 [I'm only claiming the new jemalloc is involved and that reverting avoids the problem.] I've been reporting to some lists problems with: dhclient sendmail rpcbind mountd nfsd getting SIGSEGV (signal 11) crashes and some core dumps on the old 2-socket (1 core per socket) 32-bit PowerMac G4 running head -r360311. Mika=C3=ABl Urankar sent a note suggesting that I try testing reverting head -r360233 for my head -r360311 context. He got it right . . . Context: The problem was noticed by an inability to have other machines do a: mount -onoatime,soft OLDPOWERMAC-LOCAL-IP:/... /mnt sort of operation and to have succeed. By contrast, on the old PowerMac G4 I could initiate mounts against other machines just fine. I do not see any such problems on any of (all based on head -r360311): powerpc64 (old PowerMac G5 2-sockets with 2 cores each) armv7 (OrangePi+ 2ed) aarch64 (Rock64, RPi4, RPi3, OverDrive 1000, Macchiatobin Double Shot) amd64 (ThreadRipper 1950X) So I expect something 32-bit powerpc specific is somehow involved, even if jemalloc is only using whatever it is. (A kyua run with a debug kernel did not find other unexpected signal 11 sources on the 32-bit PowerMac compared to past kyua runs, at least that I noticed. There were a few lock order reversals that I do not know if they are expected or known-safe or not. I've reported those reversals to the lists as well.) Recent experiments based on the suggestion: Doing the buildworld, buildkernel and installing just the new kernel and rebooting made no difference. But then installing the new world and rebooting did make things work again: I no longer get core files for the likes of (old cores from before the update): # find / -name "*.core" -print /var/spool/clientmqueue/sendmail.core /rpcbind.core /mountd.core /nfsd.core Nor do I see the various notices for sendmail signal 11's that did not leave behind a core file --or for dhclient (no core file left behind). And I can mount the old PowerMac's drive from other machines just fine. Other notes: I do not actively use sendmail but it was left to do its default things, partially to test if such default things are working. Unfortunately, PowerMacs have a problematical status under FreeBSD and my context has my historical experiments with avoiding various problems. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-ppc@freebsd.org Sun May 3 08:26:19 2020 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 E56B22D7A77 for ; Sun, 3 May 2020 08:26:19 +0000 (UTC) (envelope-from nonameless@ukr.net) Received: from frv199.fwdcdn.com (frv199.fwdcdn.com [212.42.77.199]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "*.ukr.net", Issuer "Thawte RSA CA 2018" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49FJwp0Rdhz4Pqs for ; Sun, 3 May 2020 08:26:17 +0000 (UTC) (envelope-from nonameless@ukr.net) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=ffe; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-Id: References:In-Reply-To:Cc:To:Subject:From:Date:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=cTqMXKxtjm3PrzRBzX+3tC1Nj0fVsf476tQZl60eRbs=; b=eiiVOJyeHu7/9m/xGHdz42AJoT k8yIWEQZ6XyDhUbWwLYxE2tjppmkM8UqQMmXLVkJp2l0sxApeuiT+AMW0CJ5TGkWUBKyqhcLxIPyD 1+DRyDzOx/0gnxb8GbtzfJUAJiT0PyJXZI9Op7NYQIQ2hyvhITTxAR96zlhSaINlUPzg=; Received: from [10.10.80.28] (helo=frv55.fwdcdn.com) by frv199.fwdcdn.com with smtp ID 1jV9wv-000Hi7-Km for freebsd-ppc@freebsd.org; Sun, 03 May 2020 11:26:09 +0300 Date: Sun, 03 May 2020 11:26:09 +0300 From: nonameless@ukr.net Subject: Re[2]: svn commit: r360233 - in head: contrib/jemalloc . . . : This partially breaks a 2-socket 32-bit powerpc (old PowerMac G4) based on head -r360311 To: Mark Millard Cc: =?us-ascii?q?vangyzen=40freebsd=2Eorg?= , svn-src-head@freebsd.org, FreeBSD Current , FreeBSD Hackers , FreeBSD PowerPC ML Received: from nonameless@ukr.net by frv55.fwdcdn.com; Sun, 03 May 2020 11:26:09 +0300 In-Reply-To: References: X-Reply-Action: reply Message-Id: <1588493689.54538000.et1xl2l8@frv55.fwdcdn.com> X-Mailer: mail.ukr.net 5.0 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: binary X-Rspamd-Queue-Id: 49FJwp0Rdhz4Pqs X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ukr.net header.s=ffe header.b=eiiVOJye; dmarc=pass (policy=none) header.from=ukr.net; spf=pass (mx1.freebsd.org: domain of nonameless@ukr.net designates 212.42.77.199 as permitted sender) smtp.mailfrom=nonameless@ukr.net X-Spamd-Result: default: False [-2.80 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[ukr.net:s=ffe]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; IP_SCORE(0.00)[ip: (-9.91), ipnet: 212.42.77.0/24(-4.88), asn: 8856(-3.91), country: UA(0.07)]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[ukr.net]; R_SPF_ALLOW(-0.20)[+ip4:212.42.77.0/24]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE_FREEMAIL(0.00)[]; CC_EXCESS_QP(1.20)[]; RCPT_COUNT_FIVE(0.00)[6]; DWL_DNSWL_LOW(-1.00)[ukr.net.dwl.dnswl.org : 127.0.5.1]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[ukr.net:+]; DMARC_POLICY_ALLOW(-0.50)[ukr.net,none]; FROM_NO_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[ukr.net]; ASN(0.00)[asn:8856, ipnet:212.42.77.0/24, country:UA]; RCVD_TLS_LAST(0.00)[] X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2020 08:26:20 -0000 --- Original message --- From: "Mark Millard"  Date: 3 May 2020, 04:47:14 > [I'm only claiming the new jemalloc is involved and that > reverting avoids the problem.] > > I've been reporting to some lists problems with: > > dhclient > sendmail > rpcbind > mountd > nfsd > > getting SIGSEGV (signal 11) crashes and some core > dumps on the old 2-socket (1 core per socket) 32-bit > PowerMac G4 running head -r360311. > > Mikaël Urankar sent a note suggesting that I try > testing reverting head -r360233 for my head -r360311 > context. He got it right . . . > > > Context: > > The problem was noticed by an inability to have > other machines do a: > > mount -onoatime,soft OLDPOWERMAC-LOCAL-IP:/... /mnt > > sort of operation and to have succeed. By contrast, on > the old PowerMac G4 I could initiate mounts against > other machines just fine. > > I do not see any such problems on any of (all based > on head -r360311): > > powerpc64 (old PowerMac G5 2-sockets with 2 cores each) > armv7 (OrangePi+ 2ed) > aarch64 (Rock64, RPi4, RPi3, > OverDrive 1000, > Macchiatobin Double Shot) > amd64 (ThreadRipper 1950X) > > So I expect something 32-bit powerpc specific > is somehow involved, even if jemalloc is only > using whatever it is. > > (A kyua run with a debug kernel did not find other > unexpected signal 11 sources on the 32-bit PowerMac > compared to past kyua runs, at least that I noticed. > There were a few lock order reversals that I do not > know if they are expected or known-safe or not. > I've reported those reversals to the lists as well.) > > > Recent experiments based on the suggestion: > > Doing the buildworld, buildkernel and installing just > the new kernel and rebooting made no difference. > > But then installing the new world and rebooting did > make things work again: I no longer get core files > for the likes of (old cores from before the update): > > # find / -name "*.core" -print > /var/spool/clientmqueue/sendmail.core > /rpcbind.core > /mountd.core > /nfsd.core > > Nor do I see the various notices for sendmail > signal 11's that did not leave behind a core file > --or for dhclient (no core file left behind). > And I can mount the old PowerMac's drive from > other machines just fine. > > > Other notes: > > I do not actively use sendmail but it was left > to do its default things, partially to test if > such default things are working. Unfortunately, > PowerMacs have a problematical status under > FreeBSD and my context has my historical > experiments with avoiding various problems. > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > Hi Mark, It should be fixed, but not by reverting to old version. We can't stuck on old version because of ancient hardware. I think upstream is not interested in support such hardware. So, it have to patched locally. Thanks. From owner-freebsd-ppc@freebsd.org Sun May 3 09:00:59 2020 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 1457D2D890A for ; Sun, 3 May 2020 09:00:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49FKhp6sSqz4RTP for ; Sun, 3 May 2020 09:00:58 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by freefall.freebsd.org (Postfix) id CA75616AED; Sun, 3 May 2020 09:00:58 +0000 (UTC) Delivered-To: powerpc@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id C661516D94 for ; Sun, 3 May 2020 09:00:58 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49FKhp3sX2z4RTH for ; Sun, 3 May 2020 09:00:58 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 800C587A7 for ; Sun, 3 May 2020 09:00:58 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 04390wKM007473 for ; Sun, 3 May 2020 09:00:58 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 04390wHD007463 for powerpc@FreeBSD.org; Sun, 3 May 2020 09:00:58 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: powerpc@FreeBSD.org Subject: [Bug 245483] lang/gcc10-devel: fix build on powerpc64 elfv2 Date: Sun, 03 May 2020 09:00:57 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: gerald@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: DUPLICATE X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: gerald@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback+ X-Bugzilla-Changed-Fields: flagtypes.name Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2020 09:00:59 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D245483 Gerald Pfeifer changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|maintainer-feedback?(gerald |maintainer-feedback+ |@FreeBSD.org) | --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-ppc@freebsd.org Sun May 3 09:12:07 2020 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 F31A42D8B9A for ; Sun, 3 May 2020 09:12:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49FKxg6GT0z4Rvc for ; Sun, 3 May 2020 09:12:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by freefall.freebsd.org (Postfix) id B3D1416F23; Sun, 3 May 2020 09:12:07 +0000 (UTC) Delivered-To: powerpc@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [96.47.72.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id B110916CED for ; Sun, 3 May 2020 09:12:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49FKxg3Sqlz4RvW for ; Sun, 3 May 2020 09:12:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 725CD89ED for ; Sun, 3 May 2020 09:12:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 0439C76h063522 for ; Sun, 3 May 2020 09:12:07 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 0439C7sc063513 for powerpc@FreeBSD.org; Sun, 3 May 2020 09:12:07 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: powerpc@FreeBSD.org Subject: [Bug 239266] lang/gcc8 (and lang/gcc9) fail to build with clang8: tree-vect-loop.c:4979:12: error: expected unqualified-id Date: Sun, 03 May 2020 09:12:06 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2020 09:12:08 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D239266 --- Comment #35 from commit-hook@freebsd.org --- A commit references this bug: Author: gerald Date: Sun May 3 09:11:13 UTC 2020 New revision: 533759 URL: https://svnweb.freebsd.org/changeset/ports/533759 Log: Update to the 20200502 snapshot of GCC 10.0.1, which has branched for the release of GCC 10.1 (and the GCC 10 release series) now. Forward port r517843 | gerald | 2019-11-17 from lang/gcc9-devel since this issue has not been addressed upstream or in our system compiler yet. [1] clang on rs6000/powerpc* unfortunately poisons user namespace by default (without any special options or include files being required). Until that changes (or GCC changes) we need to avoid using vec_step as a variable name. PR: 239266, 245483 Changes: head/lang/gcc10-devel/Makefile head/lang/gcc10-devel/distinfo head/lang/gcc10-devel/patch-clang-vec_step --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-ppc@freebsd.org Sun May 3 09:12:09 2020 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 4E4942D8BB8 for ; Sun, 3 May 2020 09:12:09 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49FKxj16xtz4Rvv for ; Sun, 3 May 2020 09:12:09 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by freefall.freebsd.org (Postfix) id 19C9D16C72; Sun, 3 May 2020 09:12:09 +0000 (UTC) Delivered-To: powerpc@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [96.47.72.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id 1736316E44 for ; Sun, 3 May 2020 09:12:09 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49FKxh6BGSz4Rvk for ; Sun, 3 May 2020 09:12:08 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id CFB7589F4 for ; Sun, 3 May 2020 09:12:08 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 0439C87e064777 for ; Sun, 3 May 2020 09:12:08 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 0439C8hH064763 for powerpc@FreeBSD.org; Sun, 3 May 2020 09:12:08 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: powerpc@FreeBSD.org Subject: [Bug 245483] lang/gcc10-devel: fix build on powerpc64 elfv2 Date: Sun, 03 May 2020 09:12:08 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: DUPLICATE X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: gerald@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback+ X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2020 09:12:09 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D245483 --- Comment #2 from commit-hook@freebsd.org --- A commit references this bug: Author: gerald Date: Sun May 3 09:11:13 UTC 2020 New revision: 533759 URL: https://svnweb.freebsd.org/changeset/ports/533759 Log: Update to the 20200502 snapshot of GCC 10.0.1, which has branched for the release of GCC 10.1 (and the GCC 10 release series) now. Forward port r517843 | gerald | 2019-11-17 from lang/gcc9-devel since this issue has not been addressed upstream or in our system compiler yet. [1] clang on rs6000/powerpc* unfortunately poisons user namespace by default (without any special options or include files being required). Until that changes (or GCC changes) we need to avoid using vec_step as a variable name. PR: 239266, 245483 Changes: head/lang/gcc10-devel/Makefile head/lang/gcc10-devel/distinfo head/lang/gcc10-devel/patch-clang-vec_step --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-ppc@freebsd.org Sun May 3 14:38:14 2020 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 DE38C2DF055 for ; Sun, 3 May 2020 14:38:14 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-54.consmr.mail.gq1.yahoo.com (sonic316-54.consmr.mail.gq1.yahoo.com [98.137.69.30]) (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 49FT9x2dVtz3H01 for ; Sun, 3 May 2020 14:38:13 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: GK_At_sVM1nO4_VNufUJRQiRbBHFzGzYXYgVFH083iNk.b.MLZwLCxzQqnnsUNa x_8tvuR148QZ_3Kho53XjSXrKURYdHi6Mepaq0aR7AicR9ZXqrywG9b5VYoZ3p53tjxMKaaPOop0 pvyQ13wozBpoV6BHbme6jU2kelDLsAfqNTMNrWmCLTOFt2EGGIBHBW5hfOC_PN7MuUz0_k9THFAT y6nD1dJ2WZTwHhhXYmheWp7ZRs7pC4ujL0V2OF4_oDk.EvN3u_0qz8MLcU7DYY3tgGURYU7TR5Lg 4Dboz27fxBNRunL70Mv7hTI8MKCqk5oEWYh6PRlYLRDSlfJd.BEGjqPjVBtqHTPf5YZtGInMUolY ERAlV4mcsW.aY9RPf0kHlzjFuIabM2DDPVKlKinsgES2721ZQK9CNodqY8PoF_ZpPVKqjZPHHeVD EufxgxQ.uN.wJeLiOKddrQU_bJ2ALPk3Zn2Ctrd9hk0dPEWqfSlEH3GUcNZciLJ_v1JzOeaGs1b5 J1LNxKNc.vdqOAvNAOO3p9yfHTDhb1pax4SihajEkIys2VqoTL4E83jyVMLqxznBSCVKoLR0MCjP nKP1PhCNcjmj7P2EN7GMGUVq84IzaT2BjwIw_tCL9_4H1L.0k6uAblCxzNw8M2cA9tNK7nq8LtG8 fZTTJg0asx0TtwrpMKs1GzifRDtcRw41L5h2QarqElv4O.WCHXZBXu0Op9VTjJ5pmsHd4aUFEk6H HvUZZcqdKARb9Si2zlMfUyHEd0EH3qHjxCn.fVSYSvca4wpO2vInGnPl3dug7GaiCbhEvmOv4HLo iaNvd6QI2UiyFq0Ude4r4pYClsi2qiFh.usFs_8LDm9CvByvWx5.cPxMY.5VLn9U5kHKqpCtwwrE 3UacgmEl3rIqvX1THtMGWhZT2R1xplGqEvD2H8bS0wtPcyZaiAbuIy6LkGNM.58fn9HDPz4m8vQi xSNZ98UUCqjbrj5WiDIncS3de0AqzHNnQXgcqKYzq_CzJWTogxu0SiPnixGzfEQM.LMFfdcuePiH crHr1ZgP.cRnv9is1apmTGeHkuPs7l9xwhXErNydjgmq.7ebx7UbhQmDGC65uSyZeIKl9PqbQ5RU rhLSjTHbrBMJ3yMtfVAJTm1hN4Yh1LCTpazzGQa3Fhg8_bX281zBoMF9qqo.4eteSvXS5QE_hqci 0jRR3FVq.ammdhNbrjwZ55KrDaLmjcx729KoBqKZROcwXwlDD8qHcGtu8wkcpLuuXDJsGhrWm3dt v4.VXuUtkE.loMX9ZCBtIi0iI2TS8FoqXb3S8.IvI4o69lKXSZsMWG2tNtAgA2xoxfc6StW1dKSX hw0cRa6jpj8IJrdck2.YqCM9DyPZudBQg5oWBjX5Dtw02Mq0_nJspvLkRxCWyR2ffeIlDQm0SGZy I3Ka4EANwc7jutC3H4dTtDuVpAMuFJA30XpUzkCgoqE_c69mBuCy95GmkL7h6 Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Sun, 3 May 2020 14:38:11 +0000 Received: by smtp425.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 152cb9da62572901c7e41056e9bc8777; Sun, 03 May 2020 14:38:07 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: svn commit: r360233 - in head: contrib/jemalloc . . . : This partially breaks a 2-socket 32-bit powerpc (old PowerMac G4) based on head -r360311 From: Mark Millard In-Reply-To: <1588493689.54538000.et1xl2l8@frv55.fwdcdn.com> Date: Sun, 3 May 2020 07:38:06 -0700 Cc: svn-src-head@freebsd.org, FreeBSD Current , FreeBSD Hackers , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <922FBA7C-039D-4852-AC8F-E85A221C2559@yahoo.com> References: <1588493689.54538000.et1xl2l8@frv55.fwdcdn.com> To: nonameless@ukr.net X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49FT9x2dVtz3H01 X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.40 / 15.00]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; RCPT_COUNT_FIVE(0.00)[5]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FREEMAIL_TO(0.00)[ukr.net]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.93)[-0.935,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.97)[-0.967,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ip: (3.91), ipnet: 98.137.64.0/21(0.83), asn: 36647(0.66), country: US(-0.05)]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[30.69.137.98.list.dnswl.org : 127.0.5.0]; RWL_MAILSPIKE_POSSIBLE(0.00)[30.69.137.98.rep.mailspike.net : 127.0.0.17]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2020 14:38:15 -0000 On 2020-May-3, at 01:26, nonameless at ukr.net wrote: > --- Original message --- > From: "Mark Millard" > Date: 3 May 2020, 04:47:14 >=20 >=20 >=20 >> [I'm only claiming the new jemalloc is involved and that >> reverting avoids the problem.] >>=20 >> I've been reporting to some lists problems with: >>=20 >> dhclient >> sendmail >> rpcbind >> mountd >> nfsd >>=20 >> getting SIGSEGV (signal 11) crashes and some core >> dumps on the old 2-socket (1 core per socket) 32-bit >> PowerMac G4 running head -r360311. >>=20 >> Mika=C3=ABl Urankar sent a note suggesting that I try >> testing reverting head -r360233 for my head -r360311 >> context. He got it right . . . >>=20 >>=20 >> Context: >>=20 >> The problem was noticed by an inability to have >> other machines do a: >>=20 >> mount -onoatime,soft OLDPOWERMAC-LOCAL-IP:/... /mnt >>=20 >> sort of operation and to have succeed. By contrast, on >> the old PowerMac G4 I could initiate mounts against >> other machines just fine. >>=20 >> I do not see any such problems on any of (all based >> on head -r360311): >>=20 >> powerpc64 (old PowerMac G5 2-sockets with 2 cores each) >> armv7 (OrangePi+ 2ed) >> aarch64 (Rock64, RPi4, RPi3, >> OverDrive 1000, >> Macchiatobin Double Shot) >> amd64 (ThreadRipper 1950X) >>=20 >> So I expect something 32-bit powerpc specific >> is somehow involved, even if jemalloc is only >> using whatever it is. >>=20 >> (A kyua run with a debug kernel did not find other >> unexpected signal 11 sources on the 32-bit PowerMac >> compared to past kyua runs, at least that I noticed. >> There were a few lock order reversals that I do not >> know if they are expected or known-safe or not. >> I've reported those reversals to the lists as well.) >>=20 >>=20 >> Recent experiments based on the suggestion: >>=20 >> Doing the buildworld, buildkernel and installing just >> the new kernel and rebooting made no difference. >>=20 >> But then installing the new world and rebooting did >> make things work again: I no longer get core files >> for the likes of (old cores from before the update): >>=20 >> # find / -name "*.core" -print >> /var/spool/clientmqueue/sendmail.core >> /rpcbind.core >> /mountd.core >> /nfsd.core >>=20 >> Nor do I see the various notices for sendmail >> signal 11's that did not leave behind a core file >> --or for dhclient (no core file left behind). >> And I can mount the old PowerMac's drive from >> other machines just fine. >>=20 >>=20 >> Other notes: >>=20 >> I do not actively use sendmail but it was left >> to do its default things, partially to test if >> such default things are working. Unfortunately, >> PowerMacs have a problematical status under >> FreeBSD and my context has my historical >> experiments with avoiding various problems. >>=20 >> =3D=3D=3D >> Mark Millard >> marklmi at yahoo.com >> ( dsl-only.net went >> away in early 2018-Mar) >>=20 >=20 > Hi Mark, >=20 > It should be fixed, but not by reverting to old version. We can't = stuck on old version because of ancient hardware. I think upstream is = not interested in support such hardware. So, it have to patched locally. Observing and reporting the reverting result is an initial part of problem isolation. I made no request for FreeBSD to give up on using the updated jemalloc. (Unfortunately, I'm not sure what a good next step of problem isolation might be for the dual-socket PowerMac G4 context.) Other than reverting, no patch is known for the issue at this point. More problem isolation is needed first. While I do not have access, https://wiki.freebsd.org/powerpc lists more modern 32-bit powerpc hardware as supported: MPC85XX evaluation boards and AmigaOne A1222 (powerpcspe). (The AmigaOne A1222 seems to be dual-ore/single-socket.) So folks with access to one of those may want to see if they also see the problem(s) with head -r360233 or later. Another interesting context to test could be single-socket with just one core. (I might be able to do that on another old PowerMac, booting the same media after moving the media.) If I understand right, the most common 32-bit powerpc tier 2 hardware platforms may still be old PowerMac's. They are considered supported and "mature", instead of just "stable". See https://wiki.freebsd.org/powerpc . However, the reality is that there are various problems for old PowerMacs (32-bit and 64-bit, at least when there is more than one socket present). The wiki page does not hint at such. (I'm not sure about single socket/multi-core PowerMacs: no access to such.) It is certainly possible for some problem to happen that would lead to dropping the supported-status for some or all old 32-bit PowerMacs, even as tier 2. But that has not happened yet and I'd have no say in such a choice. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-ppc@freebsd.org Sun May 3 14:56:23 2020 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 311DA2DF92F for ; Sun, 3 May 2020 14:56:23 +0000 (UTC) (envelope-from bdragon@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49FTZv0S4Tz3J08 for ; Sun, 3 May 2020 14:56:23 +0000 (UTC) (envelope-from bdragon@FreeBSD.org) Received: from auth1-smtp.messagingengine.com (auth1-smtp.messagingengine.com [66.111.4.227]) (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 DF9691D7E1 for ; Sun, 3 May 2020 14:56:22 +0000 (UTC) (envelope-from bdragon@FreeBSD.org) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailauth.nyi.internal (Postfix) with ESMTP id 6995B27C0054 for ; Sun, 3 May 2020 10:56:22 -0400 (EDT) Received: from imap1 ([10.202.2.51]) by compute4.internal (MEProxy); Sun, 03 May 2020 10:56:22 -0400 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrjedvgdekfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecufghrlhcuvffnffculddutddmnecujfgurhepofgfgg fkjghffffhvffutgesthdtredtreerjeenucfhrhhomhepfdeurhgrnhguohhnuceuvghr ghhrvghnfdcuoegsughrrghgohhnsefhrhgvvgeuufffrdhorhhgqeenucggtffrrghtth gvrhhnpeehieeikeekffekleekleegtefgledttefghfduteeikeevfedvhfeggfffudej gfenucffohhmrghinhepfhhrvggvsghsugdrohhrghenucevlhhushhtvghrufhiiigvpe dtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsughrrghgohhnodhmvghsmhhtphgruhht hhhpvghrshhonhgrlhhithihqddutdegvdefheekieegqddukedutdekheduqdgsughrrg hgohhnpeephfhrvggvuefuffdrohhrghesihhmrghprdgttg X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 037A4C200A4; Sun, 3 May 2020 10:56:21 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-351-g9981f4f-fmstable-20200421v1 Mime-Version: 1.0 Message-Id: In-Reply-To: <922FBA7C-039D-4852-AC8F-E85A221C2559@yahoo.com> References: <1588493689.54538000.et1xl2l8@frv55.fwdcdn.com> <922FBA7C-039D-4852-AC8F-E85A221C2559@yahoo.com> Date: Sun, 03 May 2020 09:56:02 -0500 From: "Brandon Bergren" To: "FreeBSD PowerPC ML" Subject: =?UTF-8?Q?Re:_svn_commit:_r360233_-_in_head:_contrib/jemalloc_._._._:_Th?= =?UTF-8?Q?is_partially_breaks_a_2-socket_32-bit_powerpc_(old_PowerMac_G?= =?UTF-8?Q?4)_based_on_head_-r360311?= Content-Type: text/plain X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2020 14:56:23 -0000 On Sun, May 3, 2020, at 9:38 AM, Mark Millard via freebsd-ppc wrote: > > Observing and reporting the reverting result is an initial > part of problem isolation. I made no request for FreeBSD > to give up on using the updated jemalloc. (Unfortunately, > I'm not sure what a good next step of problem isolation > might be for the dual-socket PowerMac G4 context.) I appreciate this testing btw. The only dual-socket G4 I have (my xserve g4) does not have the second socket populated, so I am currently unable to test two-socket ppc32. > Other than reverting, no patch is known for the issue at > this point. More problem isolation is needed first. > > While I do not have access, https://wiki.freebsd.org/powerpc > lists more modern 32-bit powerpc hardware as supported: > MPC85XX evaluation boards and AmigaOne A1222 (powerpcspe). > (The AmigaOne A1222 seems to be dual-ore/single-socket.) jhibbits has an A1222 that is used as an actual primary desktop, and I will hopefully have one at the end of the year. And I have an RB800 that I use for testing. powerpcspe is really a different beast than aim32 though. I have been mainly working on aim32 on g4 laptops, although I do have an xserve. > > So folks with access to one of those may want to see > if they also see the problem(s) with head -r360233 or > later. Frankly, I wouldn't be surprised if this continues to be down to the timebase skew somehow. I know that jemalloc tends to be sensitive to time problems. > > Another interesting context to test could be single-socket > with just one core. (I might be able to do that on another > old PowerMac, booting the same media after moving the > media.) That's my primary aim32 testing platform. I have a stack of g4 laptops that I test on, and a magically working usb stick (ADATA C008 / 8GB model. For some reason it just works, I've never seen another stick actually work) > > If I understand right, the most common 32-bit powerpc > tier 2 hardware platforms may still be old PowerMac's. > They are considered supported and "mature", instead of > just "stable". See https://wiki.freebsd.org/powerpc . > However, the reality is that there are various problems > for old PowerMacs (32-bit and 64-bit, at least when > there is more than one socket present). The wiki page > does not hint at such. (I'm not sure about > single socket/multi-core PowerMacs: no access to > such.) Yes, neither I nor jhibbits have multiple socket g4 hardware at the moment, and I additionally don't have multiple socket g5 either. > > It is certainly possible for some problem to happen > that would lead to dropping the supported-status > for some or all old 32-bit PowerMacs, even as tier 2. > But that has not happened yet and I'd have no say in > such a choice. >From a kernel standpoint, I for one have no intention of dropping 32 bit support in the forseeable future. I've actually been putting more work into 32 bit than 64 bit recently in fact. -- Brandon Bergren bdragon@FreeBSD.org From owner-freebsd-ppc@freebsd.org Sun May 3 15:38:10 2020 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 74B8B2E05C6 for ; Sun, 3 May 2020 15:38:10 +0000 (UTC) (envelope-from nonameless@ukr.net) Received: from frv190.fwdcdn.com (frv190.fwdcdn.com [212.42.77.190]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "*.ukr.net", Issuer "Thawte RSA CA 2018" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49FVW53T4Hz3KvT for ; Sun, 3 May 2020 15:38:09 +0000 (UTC) (envelope-from nonameless@ukr.net) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=ffe; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-Id: References:In-Reply-To:Cc:To:Subject:From:Date:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=tt42P0Zvr9+bApZvWbmXDXeXrA2RJyFe70eK+5ctp9o=; b=TFeKlFmSnuzfx5sN4ShdwhRQlR FV6a8zSPK4MCmPgnS5lw9I2butpPo1GW8pQopLG6DLCvErOd9ZelUf6trmgY9xhBAvy+V9nBwe4xV 9cEUqNZc1Lg93JqeRRGaiB2iLebjCW9E3b8WQrHpfHkgf+fgcTtViVYVcxUATlkyfGX8=; Received: from [10.10.80.23] (helo=frv55.fwdcdn.com) by frv190.fwdcdn.com with smtp ID 1jVGgr-000DWF-8K for freebsd-ppc@freebsd.org; Sun, 03 May 2020 18:38:01 +0300 Date: Sun, 03 May 2020 18:38:01 +0300 From: nonameless@ukr.net Subject: Re[2]: svn commit: r360233 - in head: contrib/jemalloc . . . : This partially breaks a 2-socket 32-bit powerpc (old PowerMac G4) based on head -r360311 To: Mark Millard Cc: svn-src-head@freebsd.org, FreeBSD Current , FreeBSD Hackers , FreeBSD PowerPC ML Received: from nonameless@ukr.net by frv55.fwdcdn.com; Sun, 03 May 2020 18:38:01 +0300 In-Reply-To: <922FBA7C-039D-4852-AC8F-E85A221C2559@yahoo.com> References: <1588493689.54538000.et1xl2l8@frv55.fwdcdn.com> <922FBA7C-039D-4852-AC8F-E85A221C2559@yahoo.com> X-Reply-Action: reply Message-Id: <1588519871.700235000.j9rwguqu@frv55.fwdcdn.com> X-Mailer: mail.ukr.net 5.0 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: binary X-Rspamd-Queue-Id: 49FVW53T4Hz3KvT X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ukr.net header.s=ffe header.b=TFeKlFmS; dmarc=pass (policy=none) header.from=ukr.net; spf=pass (mx1.freebsd.org: domain of nonameless@ukr.net designates 212.42.77.190 as permitted sender) smtp.mailfrom=nonameless@ukr.net X-Spamd-Result: default: False [-4.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[ukr.net:s=ffe]; IP_SCORE(0.00)[ipnet: 212.42.77.0/24(-4.88), asn: 8856(-3.91), country: UA(0.07)]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[ukr.net]; R_SPF_ALLOW(-0.20)[+ip4:212.42.77.0/24:c]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE_FREEMAIL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCPT_COUNT_FIVE(0.00)[5]; DWL_DNSWL_LOW(-1.00)[ukr.net.dwl.dnswl.org : 127.0.5.1]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[ukr.net:+]; DMARC_POLICY_ALLOW(-0.50)[ukr.net,none]; FROM_NO_DN(0.00)[]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[ukr.net]; ASN(0.00)[asn:8856, ipnet:212.42.77.0/24, country:UA]; RCVD_TLS_LAST(0.00)[] X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2020 15:38:10 -0000 --- Original message --- From: "Mark Millard"  Date: 3 May 2020, 17:38:14 > > > On 2020-May-3, at 01:26, nonameless at ukr.net wrote: > > > > > > --- Original message --- > > From: "Mark Millard" > > Date: 3 May 2020, 04:47:14 > > > > > > > >> [I'm only claiming the new jemalloc is involved and that > >> reverting avoids the problem.] > >> > >> I've been reporting to some lists problems with: > >> > >> dhclient > >> sendmail > >> rpcbind > >> mountd > >> nfsd > >> > >> getting SIGSEGV (signal 11) crashes and some core > >> dumps on the old 2-socket (1 core per socket) 32-bit > >> PowerMac G4 running head -r360311">360311. > >> > >> Mikaël Urankar sent a note suggesting that I try > >> testing reverting head -r360233">360233 for my head -r360311">360311 > >> context. He got it right . . . > >> > >> > >> Context: > >> > >> The problem was noticed by an inability to have > >> other machines do a: > >> > >> mount -onoatime,soft OLDPOWERMAC-LOCAL-IP:/... /mnt > >> > >> sort of operation and to have succeed. By contrast, on > >> the old PowerMac G4 I could initiate mounts against > >> other machines just fine. > >> > >> I do not see any such problems on any of (all based > >> on head -r360311): > >> > >> powerpc64 (old PowerMac G5 2-sockets with 2 cores each) > >> armv7 (OrangePi+ 2ed) > >> aarch64 (Rock64, RPi4, RPi3, > >> OverDrive 1000">1000, > >> Macchiatobin Double Shot) > >> amd64 (ThreadRipper 1950X) > >> > >> So I expect something 32-bit powerpc specific > >> is somehow involved, even if jemalloc is only > >> using whatever it is. > >> > >> (A kyua run with a debug kernel did not find other > >> unexpected signal 11 sources on the 32-bit PowerMac > >> compared to past kyua runs, at least that I noticed. > >> There were a few lock order reversals that I do not > >> know if they are expected or known-safe or not. > >> I've reported those reversals to the lists as well.) > >> > >> > >> Recent experiments based on the suggestion: > >> > >> Doing the buildworld, buildkernel and installing just > >> the new kernel and rebooting made no difference. > >> > >> But then installing the new world and rebooting did > >> make things work again: I no longer get core files > >> for the likes of (old cores from before the update): > >> > >> # find / -name "*.core" -print > >> /var/spool/clientmqueue/sendmail.core > >> /rpcbind.core > >> /mountd.core > >> /nfsd.core > >> > >> Nor do I see the various notices for sendmail > >> signal 11's that did not leave behind a core file > >> --or for dhclient (no core file left behind). > >> And I can mount the old PowerMac's drive from > >> other machines just fine. > >> > >> > >> Other notes: > >> > >> I do not actively use sendmail but it was left > >> to do its default things, partially to test if > >> such default things are working. Unfortunately, > >> PowerMacs have a problematical status under > >> FreeBSD and my context has my historical > >> experiments with avoiding various problems. > >> > >> === > >> Mark Millard > >> marklmi at yahoo.com > >> ( dsl-only.net went > >> away in early 2018">2018-Mar) > >> > > > > Hi Mark, > > > > It should be fixed, but not by reverting to old version. We can't stuck on old version because of ancient hardware. I think upstream is not interested in support such hardware. So, it have to patched locally. > > Observing and reporting the reverting result is an initial > part of problem isolation. I made no request for FreeBSD > to give up on using the updated jemalloc. (Unfortunately, > I'm not sure what a good next step of problem isolation > might be for the dual-socket PowerMac G4 context.) > > Other than reverting, no patch is known for the issue at > this point. More problem isolation is needed first. > > While I do not have access, https://wiki.freebsd.org/powerpc > lists more modern 32-bit powerpc hardware as supported: > MPC85XX evaluation boards and AmigaOne A1222 (powerpcspe). > (The AmigaOne A1222 seems to be dual-ore/single-socket.) > > So folks with access to one of those may want to see > if they also see the problem(s) with head -r360233 or > later. > > Another interesting context to test could be single-socket > with just one core. (I might be able to do that on another > old PowerMac, booting the same media after moving the > media.) > > If I understand right, the most common 32-bit powerpc > tier 2 hardware platforms may still be old PowerMac's. > They are considered supported and "mature", instead of > just "stable". See https://wiki.freebsd.org/powerpc . > However, the reality is that there are various problems > for old PowerMacs (32-bit and 64-bit, at least when > there is more than one socket present). The wiki page > does not hint at such. (I'm not sure about > single socket/multi-core PowerMacs: no access to > such.) > > It is certainly possible for some problem to happen > that would lead to dropping the supported-status > for some or all old 32-bit PowerMacs, even as tier 2. > But that has not happened yet and I'd have no say in > such a choice. > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > Just don't want to see again previous situation when jemalloc was committed, then reverted and was forgotten for six months. From owner-freebsd-ppc@freebsd.org Sun May 3 18:08:36 2020 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 88B7B2E4474 for ; Sun, 3 May 2020 18:08:36 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-20.consmr.mail.gq1.yahoo.com (sonic313-20.consmr.mail.gq1.yahoo.com [98.137.65.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49FYrf4Gzwz41sc for ; Sun, 3 May 2020 18:08:34 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 1oX6N4AVM1kMEt_vPxuFXH9vEhh1wYomaWReYDYjULLXvDflLYHJiezPy_PUB3r JgJ0FHTSFm9MJZ9RL7pKFvscGotD95w45Lba1uwxAPX0Wz4YlbPdRn76Vrzg2lrQF51vIBEM7Iia NtbtlW_Brm6UT1HX7GAtvzWR80EFMGGGz2IxTYxbUKsbNO2ZRCU.f7yLKWTl_GZx2MjtpW4oU77B UiaQwBSwN7TgKBWI0FcwPinkrOZioD.XUQS24i_ACCIdPVccgJUNR8vCHdhGTVTHM.9.DUcXfGX8 U1EBvDfBOBt8hVIgi7KdHHjVU8qK53uLEnnQeqx0Wc7aZ7Bu3ZQZjJUKo253ddI0xW08i6kp0MVt rXUeUXRHukehLn.2svajv90uPVWzeBV4.FRx1_ym85CCzZGUJ3QOLJUH_NNylGBkZfa5eP2VV9EE APhM0cZ8o8GNrHPvulT6lqSZLjWRLoKAIEAVt6fhyiKTQhN6lDc57o6AOVSbvrQdNbXKdqfA8smm OzCws63s9R_LMSjL7q6Yn8WYHxI5pWPfxFSR6TKRNJkocJ6cEttlSIJn.haWkabQCA5pBCI3_Ss7 oeipxHzpQJnl6cSKFNyxWUSbw8TQXnp1B8oqfofzH3MaISfml7ksJqzW.zPuOOrtgYESFCO2kw2V giR6umdL5MEF4fVQWZvBBsZRxDDh5RPFWK.fOKr51txJw1oHcK8j.1.KmcsQ.bxdHtIPV6RQK5vV 0bv9z_3qG_CEdWLIIswO34W.T22RRVUEvT0NCKEX5nFvLXJtHBh7Ij9055ZqSnK71IUTgL5MdgBv 7LLCwL598HOfs27rntQDl5lRfmSFULqFuKYrOie4.iAehxD0l9Gb76eM4v2rkPUt6wQNxn_HvY0v vEoIFxL9sJK.bU5Cop21fIF48lhB0c9eeIe6T2rTGPAY_Rya22MA6FxI7zMURQe7iH73fWgog9Od dWh1E8H3HvlCjHqf_QmDXGaznD2j1n6H5zpMarpY_eIk97qicL.UfrSYXGksHBsHxEL4NOCJXPMZ 4i.qz.tdb0MG1zZf38.LFrGUmHJlDFnr_O2Mt6abokrw9_v.jIuqIyoFGUJK8wxmr_kAh9yqbja2 fH3uW9lcyP_JkGP3STEX0NSBUiQKuyGxVk_kt7Msz7307g2Pn2yA3fG0XROxErkhR2X8HIMrIPM0 u9x9LaIXJz6.EHoNO.QTcl4Zf52KxOklCmQO3cNV1zJTmH5E3ldU_1QdQ8wKM7PSY4kSoYOQGpWV M4NVExzZ6bpbUXH1bLcgyl2aRFzL._Bcp1A9nJ5R_H.HuZPrxw82zeVlbpm6jGsJjpjgu158aKYY hgVzf3kpsPO1ZCcnQDyt7PAX.R1Y6WzJA6ThHJYtKSA3r5ISa_p..VDrk6zTkQM.GWvpzHCbjlU1 eNJ3xXdJdnvZlnifZo2xn.vGythTSa3G1APVLxceufCV1EwU56ZaikDdf6WDJj9RHmsc- Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Sun, 3 May 2020 18:08:32 +0000 Received: by smtp422.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 233fcb4833509f60a9288f2901074f87; Sun, 03 May 2020 18:08:28 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: svn commit: r360233 - in head: contrib/jemalloc . . . : This partially breaks a 2-socket 32-bit powerpc (old PowerMac G4) based on head -r360311 From: Mark Millard In-Reply-To: Date: Sun, 3 May 2020 11:08:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8479DD58-44F6-446A-9CA5-D01F0F7C1B38@yahoo.com> References: To: "vangyzen@freebsd.org" , svn-src-head@freebsd.org, FreeBSD Current , FreeBSD Hackers , FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49FYrf4Gzwz41sc X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.49 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; RCPT_COUNT_FIVE(0.00)[6]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.989,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.997,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ip: (1.71), ipnet: 98.137.64.0/21(0.82), asn: 36647(0.66), country: US(-0.05)]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[83.65.137.98.list.dnswl.org : 127.0.5.0]; RWL_MAILSPIKE_POSSIBLE(0.00)[83.65.137.98.rep.mailspike.net : 127.0.0.17]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2020 18:08:36 -0000 [At around 4AM local time dhcient got a signal 11, despite the jemalloc revert. The other exmaples have not happened.] On 2020-May-2, at 18:46, Mark Millard wrote: > [I'm only claiming the new jemalloc is involved and that > reverting avoids the problem.] >=20 > I've been reporting to some lists problems with: >=20 > dhclient > sendmail > rpcbind > mountd > nfsd >=20 > getting SIGSEGV (signal 11) crashes and some core > dumps on the old 2-socket (1 core per socket) 32-bit > PowerMac G4 running head -r360311. >=20 > Mika=C3=ABl Urankar sent a note suggesting that I try > testing reverting head -r360233 for my head -r360311 > context. He got it right . . . >=20 >=20 > Context: >=20 > The problem was noticed by an inability to have > other machines do a: >=20 > mount -onoatime,soft OLDPOWERMAC-LOCAL-IP:/... /mnt >=20 > sort of operation and to have succeed. By contrast, on > the old PowerMac G4 I could initiate mounts against > other machines just fine. >=20 > I do not see any such problems on any of (all based > on head -r360311): >=20 > powerpc64 (old PowerMac G5 2-sockets with 2 cores each) > armv7 (OrangePi+ 2ed) > aarch64 (Rock64, RPi4, RPi3, > OverDrive 1000, > Macchiatobin Double Shot) > amd64 (ThreadRipper 1950X) >=20 > So I expect something 32-bit powerpc specific > is somehow involved, even if jemalloc is only > using whatever it is. >=20 > (A kyua run with a debug kernel did not find other > unexpected signal 11 sources on the 32-bit PowerMac > compared to past kyua runs, at least that I noticed. > There were a few lock order reversals that I do not > know if they are expected or known-safe or not. > I've reported those reversals to the lists as well.) >=20 >=20 > Recent experiments based on the suggestion: >=20 > Doing the buildworld, buildkernel and installing just > the new kernel and rebooting made no difference. >=20 > But then installing the new world and rebooting did > make things work again: I no longer get core files > for the likes of (old cores from before the update): >=20 > # find / -name "*.core" -print > /var/spool/clientmqueue/sendmail.core > /rpcbind.core > /mountd.core > /nfsd.core >=20 > Nor do I see the various notices for sendmail > signal 11's that did not leave behind a core file > --or for dhclient (no core file left behind). > And I can mount the old PowerMac's drive from > other machines just fine. >=20 >=20 > Other notes: >=20 > I do not actively use sendmail but it was left > to do its default things, partially to test if > such default things are working. Unfortunately, > PowerMacs have a problematical status under > FreeBSD and my context has my historical > experiments with avoiding various problems. Looking, I see that I got a: pid 572 (dhclient), jid 0, uid 0: exited on signal 11 (core dumped) notice under the reverted build. No instances of the other examples. This is the first that a dhclient example has produced a .core file. gdb indicates 0x5180936c for r7 in: lwz r8,36(r7) as leading to the failure. This was in arena_dalloc_bin_locked_impl (where arena_slab_reg_dalloc and bitmap_unset were apparently inlined). The chain for the example seems to be: fork_privchld -> dispatch_imsg -> jemalloc For reference . . . # gdb dhclient /dhclient.core=20 GNU gdb (GDB) 9.1 [GDB v9.1 for FreeBSD] Copyright (C) 2020 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later = . . . Reading symbols from dhclient... Reading symbols from /usr/lib/debug//sbin/dhclient.debug... [New LWP 100089] Core was generated by `dhclient: gem0 [priv]'. Program terminated with signal SIGSEGV, Segmentation fault. #0 bitmap_unset (bitmap=3D0x50407164, binfo=3D, = bit=3D167842154) at = /usr/powerpc32_src/contrib/jemalloc/include/jemalloc/internal/bitmap.h:341= 341 = /usr/powerpc32_src/contrib/jemalloc/include/jemalloc/internal/bitmap.h: = No such file or directory. (gdb) bt -full #0 bitmap_unset (bitmap=3D0x50407164, binfo=3D, = bit=3D167842154) at = /usr/powerpc32_src/contrib/jemalloc/include/jemalloc/internal/bitmap.h:341= goff =3D gp =3D 0x51809390 propagate =3D g =3D i =3D #1 arena_slab_reg_dalloc (slab=3D0x50407140, slab_data=3D0x50407164, = ptr=3D0x50088b50) at jemalloc_arena.c:273 bin_info =3D binind =3D 0 regind =3D 167842154 #2 arena_dalloc_bin_locked_impl (tsdn=3D0x5009f018, arena=3D, slab=3D, ptr=3D, junked=3D) at jemalloc_arena.c:1540 slab_data =3D binind =3D bin_info =3D bin =3D nfree =3D #3 0x502916a8 in __je_arena_dalloc_bin_junked_locked (tsdn=3D, arena=3D, extent=3D, ptr=3D) at jemalloc_arena.c:1559 No locals. #4 0x50250d2c in __je_tcache_bin_flush_small (tsd=3D0x5009f018, = tcache=3D, tbin=3D0x5009f1c0, binind=3D, = rem=3D24) at jemalloc_tcache.c:149 ptr =3D i =3D 0 extent =3D 0x50407140 bin_arena =3D 0x50400380 bin =3D ndeferred =3D 0 merged_stats =3D arena =3D 0x50400380 nflush =3D 75 __vla_expr0 =3D item_extent =3D 0xffffd1f0 #5 0x502508a0 in __je_tcache_event_hard (tsd=3D, = tcache=3D0x5009f108) at jemalloc_tcache.c:54 tbin_info =3D binind =3D 7 tbin =3D 0x5009f1c0 #6 0x5029a684 in __free (ptr=3D0x500530c0) at = /usr/powerpc32_src/contrib/jemalloc/include/jemalloc/internal/rtree.h:374 tcache =3D 0x5009f108 tsd =3D log_var =3D log_var =3D #7 0x10025994 in dispatch_imsg (ifix=3D, fd=3D10) at = /usr/powerpc32_src/sbin/dhclient/privsep.c:215 hdr =3D {code =3D IMSG_SCRIPT_WRITE_PARAMS, len =3D 3225} lease =3D {next =3D 0x0, expiry =3D 1588504529, renewal =3D = 1588504229, rebind =3D 1588504454, address =3D {len =3D 4, iabuf =3D = "\300\250\001i", '\000' }, nextserver =3D {len =3D 4,=20= iabuf =3D '\000' }, server_name =3D 0x0, = filename =3D 0x0, medium =3D 0x0, is_static =3D 0, is_bootp =3D 0, = options =3D {{len =3D 0, data =3D 0x0}, {len =3D 4,=20 data =3D 0x500530c8 "\377\377\377"}, {len =3D 0, data =3D = 0x0}, {len =3D 4, data =3D 0x500530d0 "\300\250\001\001"}, {len =3D 0, = data =3D 0x0}, {len =3D 0, data =3D 0x0}, {len =3D 4,=20 data =3D 0x500530d8 "\300\250\001\001"}, {len =3D 0, data = =3D 0x0}, {len =3D 0, data =3D 0x0}, {len =3D 0, data =3D 0x0}, {len =3D = 0, data =3D 0x0}, {len =3D 0, data =3D 0x0}, {len =3D 0, data =3D 0x0}, = { len =3D 0, data =3D 0x0}, {len =3D 0, data =3D 0x0}, {len = =3D 20, data =3D 0x50055200 "hsd1.or.comcast.net."}, {len =3D 0, data =3D = 0x0} , {len =3D 4, data =3D 0x500530e0 ""}, {len =3D = 0,=20 data =3D 0x0}, {len =3D 1, data =3D 0x500530e8 "\005"}, = {len =3D 4, data =3D 0x500530f0 "\300\250\001\001"}, {len =3D 0, data =3D = 0x0} }} medium_len =3D medium =3D totlen =3D 3225 filename_len =3D filename =3D 0x0 ret =3D buf =3D mtu =3D servername_len =3D servername =3D 0x0 reason_len =3D reason =3D --Type for more, q to quit, c to continue without paging-- prefix_len =3D prefix =3D 0x500530c0 "new_" i =3D 0 optlen =3D 0 #8 0x100189f4 in fork_privchld (fd=3D10, fd2=3D) at = /usr/powerpc32_src/sbin/dhclient/dhclient.c:2847 pfd =3D {{fd =3D 10, events =3D 1, revents =3D 1}} nfds =3D #9 0x10017a80 in main (argc=3D, argv=3D) = at /usr/powerpc32_src/sbin/dhclient/dhclient.c:505 pipe_fd =3D {10, 11} rights =3D {cr_rights =3D {1342801412, 18446706484155777024}} immediate_daemon =3D 0 i =3D 0 ch =3D otherpid =3D 8 pw =3D 0x5039b9d8 fd =3D capmode =3D (gdb) disass Dump of assembler code for function arena_dalloc_bin_locked_impl: 0x502916b8 <+0>: mflr r0 0x502916bc <+4>: stw r0,4(r1) 0x502916c0 <+8>: stwu r1,-48(r1) 0x502916c4 <+12>: stw r30,40(r1) 0x502916c8 <+16>: stw r24,16(r1) 0x502916cc <+20>: stw r25,20(r1) 0x502916d0 <+24>: stw r26,24(r1) 0x502916d4 <+28>: stw r27,28(r1) 0x502916d8 <+32>: stw r28,32(r1) 0x502916dc <+36>: stw r29,36(r1) 0x502916e0 <+40>: bl 0x502916e4 = 0x502916e4 <+44>: mr r27,r3 0x502916e8 <+48>: mflr r30 0x502916ec <+52>: addis r30,r30,14 0x502916f0 <+56>: addi r30,r30,7788 0x502916f4 <+60>: mr r28,r4 0x502916f8 <+64>: lwz r4,5856(r30) 0x502916fc <+68>: lwz r3,4(r5) 0x50291700 <+72>: mr r29,r5 0x50291704 <+76>: andi. r5,r7,1 0x50291708 <+80>: mr r26,r6 0x5029170c <+84>: lbz r4,0(r4) 0x50291710 <+88>: rlwinm r5,r3,14,25,31 0x50291714 <+92>: mulli r24,r5,224 0x50291718 <+96>: mulli r25,r5,44 0x5029171c <+100>: cmpwi cr1,r4,0 0x50291720 <+104>: cror 4*cr5+lt,4*cr1+eq,gt 0x50291724 <+108>: bge cr5,0x50291a2c = 0x50291728 <+112>: lwz r4,0(r29) 0x5029172c <+116>: lwz r6,6036(r30) 0x50291730 <+120>: lwz r7,8(r29) 0x50291734 <+124>: rlwinm r8,r5,2,0,29 0x50291738 <+128>: li r9,1 0x5029173c <+132>: add r24,r28,r24 0x50291740 <+136>: lwzx r6,r6,r8 0x50291744 <+140>: subf r7,r7,r26 0x50291748 <+144>: mulhwu r6,r6,r7 0x5029174c <+148>: rlwinm r7,r6,29,3,29 0x50291750 <+152>: add r7,r29,r7 =3D> 0x50291754 <+156>: lwz r8,36(r7) 0x50291758 <+160>: clrlwi r10,r6,27 0x5029175c <+164>: slw r9,r9,r10 0x50291760 <+168>: xor r9,r9,r8 0x50291764 <+172>: cmplwi r8,0 0x50291768 <+176>: stw r9,36(r7) 0x5029176c <+180>: bne 0x502917e4 = 0x50291770 <+184>: lwz r7,4408(r30) 0x50291774 <+188>: mulli r8,r5,44 0x50291778 <+192>: add r5,r7,r8 0x5029177c <+196>: lwz r5,16(r5) 0x50291780 <+200>: cmplwi r5,2 0x50291784 <+204>: blt 0x502917e4 = msr cr 0x42480c00 1112017920 lr 0x502916e4 0x502916e4 = ctr 0x5005d114 1342558484 xer 0x0 0 fpscr 0x0 0 vscr vrsave =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-ppc@freebsd.org Sun May 3 18:21:55 2020 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 4AA8A2E4DD0 for ; Sun, 3 May 2020 18:21:55 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49FZ831G9Jz436L for ; Sun, 3 May 2020 18:21:55 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by freefall.freebsd.org (Postfix) id 23F511D4EE; Sun, 3 May 2020 18:21:55 +0000 (UTC) Delivered-To: powerpc@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id 215801D6B0 for ; Sun, 3 May 2020 18:21:55 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49FZ826K0Yz436H for ; Sun, 3 May 2020 18:21:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id D440FF3CD for ; Sun, 3 May 2020 18:21:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 043ILsar098403 for ; Sun, 3 May 2020 18:21:54 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 043ILseR098340 for powerpc@FreeBSD.org; Sun, 3 May 2020 18:21:54 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: powerpc@FreeBSD.org Subject: [Bug 246146] www/qt5-webkit: fix build on powerpc Date: Sun, 03 May 2020 18:21:53 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: pkubaj@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: kde@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter cc flagtypes.name attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2020 18:21:55 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D246146 Bug ID: 246146 Summary: www/qt5-webkit: fix build on powerpc Product: Ports & Packages Version: Latest Hardware: powerpc OS: Any Status: New Severity: Affects Only Me Priority: --- Component: Individual Port(s) Assignee: kde@FreeBSD.org Reporter: pkubaj@FreeBSD.org CC: powerpc@FreeBSD.org CC: powerpc@FreeBSD.org Assignee: kde@FreeBSD.org Flags: maintainer-feedback?(kde@FreeBSD.org) Created attachment 214067 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D214067&action= =3Dedit patch Same changes as those done for powerpc64 are necessary. Additionally, uc_mcontext.uc_regs doesn't exist on FreeBSD. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-ppc@freebsd.org Sun May 3 18:22:07 2020 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 D9A562E4E23 for ; Sun, 3 May 2020 18:22:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49FZ8H5VwYz439G for ; Sun, 3 May 2020 18:22:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by freefall.freebsd.org (Postfix) id B30651D4F7; Sun, 3 May 2020 18:22:07 +0000 (UTC) Delivered-To: powerpc@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [96.47.72.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id A66B91D5D2 for ; Sun, 3 May 2020 18:22:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49FZ8H3F8wz439B for ; Sun, 3 May 2020 18:22:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 6AA8EF3E6 for ; Sun, 3 May 2020 18:22:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 043IM7B5014572 for ; Sun, 3 May 2020 18:22:07 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 043IM7QY014546 for powerpc@FreeBSD.org; Sun, 3 May 2020 18:22:07 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: powerpc@FreeBSD.org Subject: [Bug 246146] www/qt5-webkit: fix build on powerpc Date: Sun, 03 May 2020 18:22:07 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: pkubaj@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: kde@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: cc flagtypes.name Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2020 18:22:07 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D246146 Piotr Kubaj changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kde@FreeBSD.org Attachment #214067| |maintainer-approval?(kde@Fr Flags| |eeBSD.org) --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-ppc@freebsd.org Sun May 3 21:32:41 2020 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 DFEBE2BA1E1 for ; Sun, 3 May 2020 21:32:41 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-21.consmr.mail.gq1.yahoo.com (sonic306-21.consmr.mail.gq1.yahoo.com [98.137.68.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 49FfN849nNz4LRk for ; Sun, 3 May 2020 21:32:40 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: KnuII7sVM1nfAwvNbPtHtam40Uu8y6WCL4Z47wcV3hlZx0ZkXFkRJEK_ULFEmhU jrMOQc60Mr8XZKuajjcE0dqxRsQ.D0kEZy..Gmsxc5moHHHqV2s0C7L2AsTdRg7B0LQqK.511ONo IeMhZBvN1WbypwXPg4xQk8O2ZRbdMWqToHSWR9GRc3QPnLzih5xK7PR461Tf2yFrPMYC0QtwoN71 ZPP1HlMjSF7RUOSczLZhoEULqHuAxcYpF9RhwmWV4f4HDAPsCMH0NIJh370QSXAX6R6RieThPXLf ElFXInU86S3gyxVJVUyeNvv.PZQdpcJjQYO6FUwIg6DqdjEvxCNZpckGlmUOi9jbaOuCrIMknfk2 Z_sYORL8iSmhLPGpN_NHeTWknpmtPhWyqn40_9yGbrKrkSFMH5k53v0MGTrtcTIvN6S9EeMxvNPG e_MEPNfC1XAWDzG89UTh8l42xljp.wgoObTmMBespduGvoWGOVGDt8iu.epn74aCCLmq5Ld7zzm8 teytPIdS2V4cvhc0w2kUbrKYtbQdkW6GX0IzN.w3cI0LMunf9l8nZEdV6M8BJZn8mAtvm9QdoSmJ smV6YmEZxlVfPyKfiMx2pEERTXpKqOSeJCQjgDb1h_XnngBJ6G2ijO4AfxLUCJPJLhj52KTfDIxy HXGsFhZR57EaR0GC9DH6fUmfjs6Tdqw1iQKW6IbpOAV2pgq08EkxvxHOwOfkmmaajl8HNO31ldes Y2yPsWYPY08Hg5aFK3qeEsnF5MWWQhHqLr6WDxoziG_j7KR9T8_iVh2XgOYg2HteIT0XVtN.VpTW M6aTftNwBOGWsyDqhxOrYiEDanoO1D45fGEEUi5Ka9iGCtKAVDeYYA4phffIxmNBwpkFdBEJ9b4K QHp5Rb.C9HMnq7m7N1Ws__bPVDBHkPvHnVgxh67ZWYZr8a7HynVkZh6mm0kfl1HNH0WXFnlwERkx uZHDL2vVj3STIr36P5bEZ4cE.HKv9QSRS7i7RouW.UXehDJUBuoA9B7nVK1HU4.tWudtjKp49YNX bC_DyAqdbI1iZd9VZL8NmGP6V._Q2TSuzisY1CtTvnXby0VBhn1OEpHL_qIVKpBy.v3YM915ncA8 JhSKid05LjD.RZV_S_x.lJRqGT3hh7ULAhCJHZxa.mCDkEXjJK6RizZgoCyMUTuBhohnBa7mSZSD _PXv7_A6NiOprGs2pPx.Fet8XwH61i_vQqS3Iv0rXIhcTo3NFIdK4guEoNB6ZcSIeuzanv2XtIT8 48Gwhk5a9imkhIh4Q_EeHGSu6Ll1.kkAfZEjKYcxxAU4x.wZGgt2Wfq4IKNPE2ZzXQJY.R9V1_dM uTFKAWEsXj9zUjKD0Mjo5bwCl4MUJXZicVpR1AAKxqDwsTULRYCtyZAyx1A08Wxyja3YbOtPJCl. 2GKcTXrYvnvLcJSxBeCj15eEWNhZVRZQiCXW01CQIEOEsalzueEbqsgAhNKPY8W8meOUPJg-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Sun, 3 May 2020 21:32:37 +0000 Received: by smtp421.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 0baeaae5442914f50439d86f6563f26f; Sun, 03 May 2020 21:32:36 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: svn commit: r360233 - in head: contrib/jemalloc . . . : This partially breaks a 2-socket 32-bit powerpc (old PowerMac G4) based on head -r360311 From: Mark Millard In-Reply-To: <8479DD58-44F6-446A-9CA5-D01F0F7C1B38@yahoo.com> Date: Sun, 3 May 2020 14:32:34 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <17ACDA02-D7EF-4F26-874A-BB3E935CD072@yahoo.com> References: <8479DD58-44F6-446A-9CA5-D01F0F7C1B38@yahoo.com> To: "vangyzen@freebsd.org" , svn-src-head@freebsd.org, FreeBSD Current , FreeBSD Hackers , FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49FfN849nNz4LRk X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.31 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; RCPT_COUNT_FIVE(0.00)[6]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.89)[-0.887,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.92)[-0.922,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ip: (5.59), ipnet: 98.137.64.0/21(0.82), asn: 36647(0.66), country: US(-0.05)]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[84.68.137.98.list.dnswl.org : 127.0.5.0]; RWL_MAILSPIKE_POSSIBLE(0.00)[84.68.137.98.rep.mailspike.net : 127.0.0.17]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2020 21:32:42 -0000 [The bit argument ot bitmap_unset seems to be way too large.] On 2020-May-3, at 11:08, Mark Millard wrote: > [At around 4AM local time dhcient got a signal 11, > despite the jemalloc revert. The other exmaples > have not happened.] >=20 > On 2020-May-2, at 18:46, Mark Millard wrote: >=20 >> [I'm only claiming the new jemalloc is involved and that >> reverting avoids the problem.] >>=20 >> I've been reporting to some lists problems with: >>=20 >> dhclient >> sendmail >> rpcbind >> mountd >> nfsd >>=20 >> getting SIGSEGV (signal 11) crashes and some core >> dumps on the old 2-socket (1 core per socket) 32-bit >> PowerMac G4 running head -r360311. >>=20 >> Mika=C3=ABl Urankar sent a note suggesting that I try >> testing reverting head -r360233 for my head -r360311 >> context. He got it right . . . >>=20 >>=20 >> Context: >>=20 >> The problem was noticed by an inability to have >> other machines do a: >>=20 >> mount -onoatime,soft OLDPOWERMAC-LOCAL-IP:/... /mnt >>=20 >> sort of operation and to have succeed. By contrast, on >> the old PowerMac G4 I could initiate mounts against >> other machines just fine. >>=20 >> I do not see any such problems on any of (all based >> on head -r360311): >>=20 >> powerpc64 (old PowerMac G5 2-sockets with 2 cores each) >> armv7 (OrangePi+ 2ed) >> aarch64 (Rock64, RPi4, RPi3, >> OverDrive 1000, >> Macchiatobin Double Shot) >> amd64 (ThreadRipper 1950X) >>=20 >> So I expect something 32-bit powerpc specific >> is somehow involved, even if jemalloc is only >> using whatever it is. >>=20 >> (A kyua run with a debug kernel did not find other >> unexpected signal 11 sources on the 32-bit PowerMac >> compared to past kyua runs, at least that I noticed. >> There were a few lock order reversals that I do not >> know if they are expected or known-safe or not. >> I've reported those reversals to the lists as well.) >>=20 >>=20 >> Recent experiments based on the suggestion: >>=20 >> Doing the buildworld, buildkernel and installing just >> the new kernel and rebooting made no difference. >>=20 >> But then installing the new world and rebooting did >> make things work again: I no longer get core files >> for the likes of (old cores from before the update): >>=20 >> # find / -name "*.core" -print >> /var/spool/clientmqueue/sendmail.core >> /rpcbind.core >> /mountd.core >> /nfsd.core >>=20 >> Nor do I see the various notices for sendmail >> signal 11's that did not leave behind a core file >> --or for dhclient (no core file left behind). >> And I can mount the old PowerMac's drive from >> other machines just fine. >>=20 >>=20 >> Other notes: >>=20 >> I do not actively use sendmail but it was left >> to do its default things, partially to test if >> such default things are working. Unfortunately, >> PowerMacs have a problematical status under >> FreeBSD and my context has my historical >> experiments with avoiding various problems. >=20 > Looking, I see that I got a: >=20 > pid 572 (dhclient), jid 0, uid 0: exited on signal 11 (core dumped) >=20 > notice under the reverted build. No instances > of the other examples. This is the first that a > dhclient example has produced a .core file. >=20 > gdb indicates 0x5180936c for r7 in: >=20 > lwz r8,36(r7) >=20 > as leading to the failure. This was in > arena_dalloc_bin_locked_impl (where > arena_slab_reg_dalloc and bitmap_unset > were apparently inlined). >=20 > The chain for the example seems to be: > fork_privchld -> dispatch_imsg -> jemalloc >=20 > For reference . . . >=20 > # gdb dhclient /dhclient.core=20 > GNU gdb (GDB) 9.1 [GDB v9.1 for FreeBSD] > Copyright (C) 2020 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later = > . . . > Reading symbols from dhclient... > Reading symbols from /usr/lib/debug//sbin/dhclient.debug... > [New LWP 100089] > Core was generated by `dhclient: gem0 [priv]'. > Program terminated with signal SIGSEGV, Segmentation fault. > #0 bitmap_unset (bitmap=3D0x50407164, binfo=3D, = bit=3D167842154) at = /usr/powerpc32_src/contrib/jemalloc/include/jemalloc/internal/bitmap.h:341= > 341 = /usr/powerpc32_src/contrib/jemalloc/include/jemalloc/internal/bitmap.h: = No such file or directory. > (gdb) bt -full > #0 bitmap_unset (bitmap=3D0x50407164, binfo=3D, = bit=3D167842154) at = /usr/powerpc32_src/contrib/jemalloc/include/jemalloc/internal/bitmap.h:341= > goff =3D > gp =3D 0x51809390 > propagate =3D > g =3D > i =3D > #1 arena_slab_reg_dalloc (slab=3D0x50407140, slab_data=3D0x50407164, = ptr=3D0x50088b50) at jemalloc_arena.c:273 > bin_info =3D > binind =3D 0 > regind =3D 167842154 > #2 arena_dalloc_bin_locked_impl (tsdn=3D0x5009f018, arena=3D, slab=3D, ptr=3D, junked=3D) at jemalloc_arena.c:1540 > slab_data =3D > binind =3D > bin_info =3D > bin =3D > nfree =3D > #3 0x502916a8 in __je_arena_dalloc_bin_junked_locked (tsdn=3D, arena=3D, extent=3D, ptr=3D) at jemalloc_arena.c:1559 > No locals. > #4 0x50250d2c in __je_tcache_bin_flush_small (tsd=3D0x5009f018, = tcache=3D, tbin=3D0x5009f1c0, binind=3D, = rem=3D24) at jemalloc_tcache.c:149 > ptr =3D > i =3D 0 > extent =3D 0x50407140 > bin_arena =3D 0x50400380 > bin =3D > ndeferred =3D 0 > merged_stats =3D > arena =3D 0x50400380 > nflush =3D 75 > __vla_expr0 =3D > item_extent =3D 0xffffd1f0 > #5 0x502508a0 in __je_tcache_event_hard (tsd=3D, = tcache=3D0x5009f108) at jemalloc_tcache.c:54 > tbin_info =3D > binind =3D 7 > tbin =3D 0x5009f1c0 > #6 0x5029a684 in __free (ptr=3D0x500530c0) at = /usr/powerpc32_src/contrib/jemalloc/include/jemalloc/internal/rtree.h:374 > tcache =3D 0x5009f108 > tsd =3D > log_var =3D > log_var =3D > #7 0x10025994 in dispatch_imsg (ifix=3D, fd=3D10) at = /usr/powerpc32_src/sbin/dhclient/privsep.c:215 > hdr =3D {code =3D IMSG_SCRIPT_WRITE_PARAMS, len =3D 3225} > lease =3D {next =3D 0x0, expiry =3D 1588504529, renewal =3D = 1588504229, rebind =3D 1588504454, address =3D {len =3D 4, iabuf =3D = "\300\250\001i", '\000' }, nextserver =3D {len =3D 4,=20= > iabuf =3D '\000' }, server_name =3D 0x0, = filename =3D 0x0, medium =3D 0x0, is_static =3D 0, is_bootp =3D 0, = options =3D {{len =3D 0, data =3D 0x0}, {len =3D 4,=20 > data =3D 0x500530c8 "\377\377\377"}, {len =3D 0, data =3D = 0x0}, {len =3D 4, data =3D 0x500530d0 "\300\250\001\001"}, {len =3D 0, = data =3D 0x0}, {len =3D 0, data =3D 0x0}, {len =3D 4,=20 > data =3D 0x500530d8 "\300\250\001\001"}, {len =3D 0, data = =3D 0x0}, {len =3D 0, data =3D 0x0}, {len =3D 0, data =3D 0x0}, {len =3D = 0, data =3D 0x0}, {len =3D 0, data =3D 0x0}, {len =3D 0, data =3D 0x0}, = { > len =3D 0, data =3D 0x0}, {len =3D 0, data =3D 0x0}, {len = =3D 20, data =3D 0x50055200 "hsd1.or.comcast.net."}, {len =3D 0, data =3D = 0x0} , {len =3D 4, data =3D 0x500530e0 ""}, {len =3D = 0,=20 > data =3D 0x0}, {len =3D 1, data =3D 0x500530e8 "\005"}, = {len =3D 4, data =3D 0x500530f0 "\300\250\001\001"}, {len =3D 0, data =3D = 0x0} }} > medium_len =3D > medium =3D > totlen =3D 3225 > filename_len =3D > filename =3D 0x0 > ret =3D > buf =3D > mtu =3D > servername_len =3D > servername =3D 0x0 > reason_len =3D > reason =3D > --Type for more, q to quit, c to continue without paging-- > prefix_len =3D > prefix =3D 0x500530c0 "new_" > i =3D 0 > optlen =3D 0 > #8 0x100189f4 in fork_privchld (fd=3D10, fd2=3D) at = /usr/powerpc32_src/sbin/dhclient/dhclient.c:2847 > pfd =3D {{fd =3D 10, events =3D 1, revents =3D 1}} > nfds =3D > #9 0x10017a80 in main (argc=3D, argv=3D) at /usr/powerpc32_src/sbin/dhclient/dhclient.c:505 > pipe_fd =3D {10, 11} > rights =3D {cr_rights =3D {1342801412, 18446706484155777024}} > immediate_daemon =3D 0 > i =3D 0 > ch =3D > otherpid =3D 8 > pw =3D 0x5039b9d8 > fd =3D > capmode =3D >=20 > (gdb) disass > Dump of assembler code for function arena_dalloc_bin_locked_impl: > 0x502916b8 <+0>: mflr r0 > 0x502916bc <+4>: stw r0,4(r1) > 0x502916c0 <+8>: stwu r1,-48(r1) > 0x502916c4 <+12>: stw r30,40(r1) > 0x502916c8 <+16>: stw r24,16(r1) > 0x502916cc <+20>: stw r25,20(r1) > 0x502916d0 <+24>: stw r26,24(r1) > 0x502916d4 <+28>: stw r27,28(r1) > 0x502916d8 <+32>: stw r28,32(r1) > 0x502916dc <+36>: stw r29,36(r1) > 0x502916e0 <+40>: bl 0x502916e4 = > 0x502916e4 <+44>: mr r27,r3 > 0x502916e8 <+48>: mflr r30 > 0x502916ec <+52>: addis r30,r30,14 > 0x502916f0 <+56>: addi r30,r30,7788 > 0x502916f4 <+60>: mr r28,r4 > 0x502916f8 <+64>: lwz r4,5856(r30) > 0x502916fc <+68>: lwz r3,4(r5) > 0x50291700 <+72>: mr r29,r5 > 0x50291704 <+76>: andi. r5,r7,1 > 0x50291708 <+80>: mr r26,r6 > 0x5029170c <+84>: lbz r4,0(r4) > 0x50291710 <+88>: rlwinm r5,r3,14,25,31 > 0x50291714 <+92>: mulli r24,r5,224 > 0x50291718 <+96>: mulli r25,r5,44 > 0x5029171c <+100>: cmpwi cr1,r4,0 > 0x50291720 <+104>: cror 4*cr5+lt,4*cr1+eq,gt > 0x50291724 <+108>: bge cr5,0x50291a2c = > 0x50291728 <+112>: lwz r4,0(r29) > 0x5029172c <+116>: lwz r6,6036(r30) > 0x50291730 <+120>: lwz r7,8(r29) > 0x50291734 <+124>: rlwinm r8,r5,2,0,29 > 0x50291738 <+128>: li r9,1 > 0x5029173c <+132>: add r24,r28,r24 > 0x50291740 <+136>: lwzx r6,r6,r8 > 0x50291744 <+140>: subf r7,r7,r26 > 0x50291748 <+144>: mulhwu r6,r6,r7 > 0x5029174c <+148>: rlwinm r7,r6,29,3,29 > 0x50291750 <+152>: add r7,r29,r7 > =3D> 0x50291754 <+156>: lwz r8,36(r7) > 0x50291758 <+160>: clrlwi r10,r6,27 > 0x5029175c <+164>: slw r9,r9,r10 > 0x50291760 <+168>: xor r9,r9,r8 > 0x50291764 <+172>: cmplwi r8,0 > 0x50291768 <+176>: stw r9,36(r7) > 0x5029176c <+180>: bne 0x502917e4 = > 0x50291770 <+184>: lwz r7,4408(r30) > 0x50291774 <+188>: mulli r8,r5,44 > 0x50291778 <+192>: add r5,r7,r8 > 0x5029177c <+196>: lwz r5,16(r5) > 0x50291780 <+200>: cmplwi r5,2 > 0x50291784 <+204>: blt 0x502917e4 = . . . >=20 > (gdb) info reg > r0 0x502916a8 1344870056 > r1 0xffffd1a0 4294955424 > r2 0x500a6018 1342857240 > r3 0x0 0 > r4 0x0 0 > r5 0x0 0 > r6 0xa01116a 167842154 > r7 0x5180936c 1367380844 > r8 0x0 0 > r9 0x1 1 > r10 0x1e 30 > r11 0x5005d114 1342558484 > r12 0x84000c00 2214595584 > r13 0x0 0 > r14 0xffffd1f0 4294955504 > r15 0xfffffffc 4294967292 > r16 0x4a 74 > r17 0x4b 75 > r18 0x0 0 > r19 0x504009a0 1346374048 > r20 0x0 0 > r21 0xffffd1f0 4294955504 > r22 0x620 1568 > r23 0x50400380 1346372480 > r24 0x50400380 1346372480 > r25 0x0 0 > r26 0x50088b50 1342737232 > r27 0x5009f018 1342828568 > r28 0x50400380 1346372480 > r29 0x50407140 1346400576 > r30 0x50373550 1345795408 > r31 0xffffd310 4294955792 > pc 0x50291754 0x50291754 = > msr > cr 0x42480c00 1112017920 > lr 0x502916e4 0x502916e4 = > ctr 0x5005d114 1342558484 > xer 0x0 0 > fpscr 0x0 0 > vscr > vrsave bitmap_unset (bitmap=3D0x50407164, binfo=3D, = bit=3D167842154) explains calculating: gp =3D 0x51809390 via bitmap+(bit/4/8): (gdb) print/x 0x50407164 +167842154/4/8=20 $16 =3D 0x51809390 The last potential bit/4/8 value to be able to access memory (without spanning a hole) is: (gdb) print *(bitmap+582566) $13 =3D 0 (gdb) print/x (bitmap+582566) $14 =3D 0x5063fffc So it looks like arena_slab_reg_dalloc produced an invalid bit value. Looking at that code shows that regind hold the parameter value that matches: static void arena_slab_reg_dalloc(extent_t *slab, arena_slab_data_t *slab_data, void = *ptr) { szind_t binind =3D extent_szind_get(slab); const bin_info_t *bin_info =3D &bin_infos[binind]; size_t regind =3D arena_slab_regind(slab, binind, ptr); =20 assert(extent_nfree_get(slab) < bin_info->nregs); /* Freeing an unallocated pointer can cause assertion failure. = */ assert(bitmap_get(slab_data->bitmap, &bin_info->bitmap_info, = regind)); bitmap_unset(slab_data->bitmap, &bin_info->bitmap_info, regind); extent_nfree_inc(slab); } The backtrace showed binind=3D=3D0 for arena_slab_reg_dalloc. That leaves: arena_slab_regind(slab, binind, ptr) as producing the odd value. size_t arena_slab_regind(extent_t *slab, szind_t binind, const void *ptr) { size_t diff, regind; /* Freeing a pointer outside the slab can cause assertion = failure. */ assert((uintptr_t)ptr >=3D (uintptr_t)extent_addr_get(slab)); assert((uintptr_t)ptr < (uintptr_t)extent_past_get(slab)); /* Freeing an interior pointer can cause assertion failure. */ assert(((uintptr_t)ptr - (uintptr_t)extent_addr_get(slab)) % (uintptr_t)bin_infos[binind].reg_size =3D=3D 0); diff =3D (size_t)((uintptr_t)ptr - = (uintptr_t)extent_addr_get(slab)); /* Avoid doing division with a variable divisor. */ regind =3D div_compute(&arena_binind_div_info[binind], diff); assert(regind < bin_infos[binind].nregs); return regind; } ptr =3D=3D 0x50088b50 slab =3D=3D 0x50407140 static inline void * extent_addr_get(const extent_t *extent) { assert(extent->e_addr =3D=3D PAGE_ADDR2BASE(extent->e_addr) || !extent_slab_get(extent)); return extent->e_addr; } (gdb) print *slab $17 =3D {e_bits =3D 0, e_addr =3D 0x0, {e_size_esn =3D 0, e_bsize =3D = 0}, ql_link =3D {qre_next =3D 0x0, qre_prev =3D 0x0}, ph_link =3D = {phn_prev =3D 0x0, phn_next =3D 0x0, phn_lchild =3D 0x0}, {e_slab_data =3D= {bitmap =3D { 0 }}, e_prof_tctx =3D {repr =3D 0x0}}} That looks wrong: all fields are zero, which is not likely to be the description of a slab. But I'll continue to be sure I get the reported value of bit. So extent_addr_get(slab)=3D=3Dslab->e_addr and slab->e_addr=3D=3D0x0 and diff=3D=3Dptr . (gdb) print/x arena_binind_div_info[binind] $19 =3D {magic =3D 0x20000000} static inline size_t div_compute(div_info_t *div_info, size_t n) { assert(n <=3D (uint32_t)-1); /* * This generates, e.g. mov; imul; shr on x86-64. On a 32-bit = machine, * the compilers I tried were all smart enough to turn this into = the * appropriate "get the high 32 bits of the result of a = multiply" (e.g. * mul; mov edx eax; on x86, umull on arm, etc.). */ size_t i =3D ((uint64_t)n * (uint64_t)div_info->magic) >> 32; #ifdef JEMALLOC_DEBUG assert(i * div_info->d =3D=3D n); #endif return i; } (gdb) print/x ((unsigned long long)0x50088b50 * (unsigned long = long)0x20000000) >> 32 $21 =3D 0xa01116a (gdb) print ((unsigned long long)0x50088b50 * (unsigned long = long)0x20000000) >> 32 $22 =3D 167842154 (As reported.) So returning to *slab being all zero . . . The slab value in the call chain seems to trace back to=3D __je_tcache_bin_flush_small code: bin_t *bin =3D &bin_arena->bins[binind]; . . . malloc_mutex_lock(tsd_tsdn(tsd), &bin->lock); . . . for (unsigned i =3D 0; i < nflush; i++) { void *ptr =3D *(tbin->avail - 1 - i); extent =3D item_extent[i]; assert(ptr !=3D NULL && extent !=3D NULL); if (extent_arena_get(extent) =3D=3D bin_arena) { = arena_dalloc_bin_junked_locked(tsd_tsdn(tsd), bin_arena, extent, ptr); . . . malloc_mutex_unlock(tsd_tsdn(tsd), &bin->lock); (So ptr's value here is later slab's value in the call chain.) The backtrace shows binind =3D 7 via __je_tcache_event_hard . (Not the same as the earlier binind.) #4 0x50250d2c in __je_tcache_bin_flush_small (tsd=3D0x5009f018, = tcache=3D, tbin=3D0x5009f1c0, binind=3D, = rem=3D24) at jemalloc_tcache.c:149 ptr =3D i =3D 0 extent =3D 0x50407140 bin_arena =3D 0x50400380 bin =3D ndeferred =3D 0 merged_stats =3D arena =3D 0x50400380 nflush =3D 75 __vla_expr0 =3D item_extent =3D 0xffffd1f0 (gdb) print/x bin_arena->bins[7] $44 =3D {lock =3D {{{prof_data =3D {tot_wait_time =3D {ns =3D 0x0}, = max_wait_time =3D {ns =3D 0x0}, n_wait_times =3D 0x0, n_spin_acquired =3D = 0x0, max_n_thds =3D 0x0, n_waiting_thds =3D {repr =3D 0x0},=20 n_owner_switches =3D 0x0, prev_owner =3D 0x0, n_lock_ops =3D = 0x0}, lock =3D 0x0, postponed_next =3D 0x504021d0}, witness =3D {name =3D = 0x0, rank =3D 0x0, comp =3D 0x0, opaque =3D 0x0, link =3D {qre_next =3D = 0x0,=20 qre_prev =3D 0x0}}, lock_order =3D 0x0}}, slabcur =3D = 0x50407140, slabs_nonfull =3D {ph_root =3D 0x0}, slabs_full =3D = {qlh_first =3D 0x0}, stats =3D {nmalloc =3D 0x64, ndalloc =3D 0x0, = nrequests =3D 0x1,=20 curregs =3D 0x64, nfills =3D 0x1, nflushes =3D 0x1, nslabs =3D 0x1, = reslabs =3D 0x0, curslabs =3D 0x1, mutex_data =3D {tot_wait_time =3D {ns = =3D 0x0}, max_wait_time =3D {ns =3D 0x0}, n_wait_times =3D 0x0,=20 n_spin_acquired =3D 0x0, max_n_thds =3D 0x0, n_waiting_thds =3D = {repr =3D 0x0}, n_owner_switches =3D 0x0, prev_owner =3D 0x0, n_lock_ops = =3D 0x0}}} That indicates: bin_arena->bins[7]->lock =3D 0x0 . Expected? Single threaded context? (gdb) print *item_extent[0] $27 =3D {e_bits =3D 0, e_addr =3D 0x0, {e_size_esn =3D 0, e_bsize =3D = 0}, ql_link =3D {qre_next =3D 0x0, qre_prev =3D 0x0}, ph_link =3D = {phn_prev =3D 0x0, phn_next =3D 0x0, phn_lchild =3D 0x0}, {e_slab_data =3D= {bitmap =3D { 0 }}, e_prof_tctx =3D {repr =3D 0x0}}} Other *item_extent[INDEX] that I tried got the same: all zeros. This is what contributed to the huge bit value. item_extent[] is based on the declaration: VARIABLE_ARRAY(extent_t *, item_extent, nflush); and: /* Declare a variable-length array. */ #if __STDC_VERSION__ < 199901L # ifdef _MSC_VER # include # define alloca _alloca # else # ifdef JEMALLOC_HAS_ALLOCA_H # include # else # include # endif # endif # define VARIABLE_ARRAY(type, name, count) \ type *name =3D alloca(sizeof(type) * (count)) #else # define VARIABLE_ARRAY(type, name, count) type name[(count)] #endif WARNING: C11 turned VLAs into a conditional feature (__STDC_NO_VLA__). Only C99 has it as required. Thus the above definition of VARIABLE_ARRAY is incomplete or limited to C99 and before relative the the language vintages. Looking around, the stack frames seem to span the space okay: (gdb) print/x &item_extent[75] $32 =3D 0xffffd31c (gdb) print/x &item_extent[0] $33 =3D 0xffffd1f0 r1 0xffffd1a0 4294955424 r14 0xffffd1f0 4294955504 r15 0xfffffffc 4294967292 r21 0xffffd1f0 4294955504 (gdb) print/x *(void**)0xffffd1a0 $36 =3D 0xffffd1d0 (gdb) print/x *(void**)0xffffd1d0 $37 =3D 0xffffd1e0 (gdb) print/x *(void**)0xffffd1e0 $38 =3D 0xffffd440 (gdb) print/x *(void**)0xffffd440 $39 =3D 0xffffd460 And I've run out of ideas for what else to look at (for now). (It is not like I understand jemalloc.) (Last I knew, 32-bit powerpc did not have red-zone stack-space criteria to leave room for signals to use.) =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 May 4 03:35:43 2020 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 2F4212C1D2A for ; Mon, 4 May 2020 03:35:43 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-25.consmr.mail.gq1.yahoo.com (sonic312-25.consmr.mail.gq1.yahoo.com [98.137.69.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 49FpR163Xpz4cPf for ; Mon, 4 May 2020 03:35:41 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: k6zKPnsVM1lfrCrcQF5bRJOn.HgrqX3l23eRyTPe6AXTqAVsXKJfcIN2SvJg6B1 .gd0V6_dWoAb2J8tqbCnwFDSEA4ImyXhxngCs1rXaSKMZ2WzXGD_Dqs4XkBx_2FdRFgeapuLD2po _CHP_7yMQtdP2LcldiJi38IMpt3sizYgGYxHy_N80uNHkFZGPy0BtBPquQdrahF7MpFKSbkCIuTR zGGM_aVcAzN9rJPDhVrNahUo2t5t_b4yW.MtwOQs2g7n02PYy_5_8Ce2fsPXfxNwUzLOR1.SNlL_ v6nSyHHpOVrmYrEfINqvIbGvQkuE79j2Wjx8A6dj5BjMwfH2n3Cy7s17fiT8uL.LjFJJQDQrTadm 1f4MMCeTy4sNMk0d3gMRk40QiKuLZqxZJelae8EQKaCp2bkV9dj1DIkVCwuIW45IkKHI0eJ86DHR tOfJdnAYRLOo8HFEyVFVCbWkclyuUhkdCRw2jaqATVSAWGpPqkZ4PCSth0MPp3dz2WcOZx8HpnBL .mnbB3XOmsxT4Uzxonxeyjo3SVWIbGIZCJlWFOCn1IC2L3bKlwF3oR.Kgd1vLA8bgNoNXzIU3Dv. D8QoJSUBtqB04dKkh_CB0JxF.9bxR3Xlms_rfK4H0BncktRy1tsXFUl0ho5tAhBFD5xbjPbTqSWV RlweHPHL4iBAhLzUn7K7v7sUC581yJpSuFb34jXAD0dZDN88DARLrNKSzgtxVBSzTOq1ntfsapz5 _lBFo_ATpkeSl_drJUbxlolZV_hTcA24UgesCS1E_HtKtAPe_agj1Rdl_lWPAR_xcVuARdVVAT3s JCvMJVveQGxPicWOizbuWEfB9vPtLFemI2IBGJcsByOQEAI6kw8vkqXwKPUVAj9yBC8iGTN.xv.n wrdlx3pmlBCrvWLk4xjjob652Oxo_Itsgw0W1kBSYW9g4jg0z1IGEgkVzpUYD0.OaiLOWX4T1OLc DACqxfd_U4mzMztoJ2SuJdGI.0Of3sTE4nAAFwsm7HwJ4PCQqJatkl_QbUtGUpaRzMtc_X8FTGlz og50slZw8QHRSn3AA0B.xo0haFGCgGnLne.OSv8c9EOrLZsAbPiDSc0DyHgAhBAYLMrZ8av_w518 QMm27jfMrceXW_Jfwbk0rsp2dqo5MqCb5BFc3iahwzTfN.KX8X_oz9e3a.ljxCBGxpYnaMtWE6dc H4NS.X0jMO8bMuAsfeVEAjcBLzuADQkEpUUEQHIWz_8np2fzNP7hFUse3Sp9QvMcfeCETBmyZ2Lr VpJZ_9DqiM4qz5UpBrKP0lIUUQo68haPsVQcKZJ6nxkTXYzpd1NShMjgIRDjgWFsSwpCWcyeuoe_ W5ecdYjRuV9TEUIGVTx56COQMnpOFPOU9Qm_zs5Uz1iqoXOnWf6cDJIT.ymcBd308Oz7Vbm73cRh OwAy.cHJQ64lLPNBWgnTh3Bpfgf9izg-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Mon, 4 May 2020 03:35:39 +0000 Received: by smtp415.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 0f1626b2cc68caa9d0a40fce7235f8f4; Mon, 04 May 2020 03:35:37 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: svn commit: r360233 - in head: contrib/jemalloc . . . : This partially breaks a 2-socket 32-bit powerpc (old PowerMac G4) based on head -r360311 From: Mark Millard In-Reply-To: <17ACDA02-D7EF-4F26-874A-BB3E935CD072@yahoo.com> Date: Sun, 3 May 2020 20:35:35 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <695E6836-F860-4557-B7DE-CC1EDB347F18@yahoo.com> References: <8479DD58-44F6-446A-9CA5-D01F0F7C1B38@yahoo.com> <17ACDA02-D7EF-4F26-874A-BB3E935CD072@yahoo.com> To: "vangyzen@freebsd.org" , svn-src-head@freebsd.org, FreeBSD Current , FreeBSD Hackers , FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49FpR163Xpz4cPf X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.50 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; RCPT_COUNT_FIVE(0.00)[6]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ip: (-3.25), ipnet: 98.137.64.0/21(0.82), asn: 36647(0.66), country: US(-0.05)]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[206.69.137.98.list.dnswl.org : 127.0.5.0]; RWL_MAILSPIKE_POSSIBLE(0.00)[206.69.137.98.rep.mailspike.net : 127.0.0.17]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2020 03:35:43 -0000 This note just reports things from looking at 2 .core files (mountd and rpcbind) from the new jemalloc context's failures. May be someone that knows more can get something out of it. I've not included any of the prior message history. For mountd: Core was generated by `/usr/sbin/mountd -r'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x50235df0 in cache_bin_dalloc_easy (bin=3D, = bin_info=3D, ptr=3D0x50049160) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/cache_bin.h:121 warning: Source file is more recent than executable. 121 if (unlikely(bin->ncached =3D=3D bin_info->ncached_max)) = { It turns out that bin_info traces back to: cache_bin_t *bin =3D tcache_small_bin_get(tcache, = alloc_ctx.szind); cache_bin_info_t *bin_info =3D = &tcache_bin_info[alloc_ctx.szind]; if (!cache_bin_dalloc_easy(bin, bin_info, ptr)) { return false; } based on: #define tcache_bin_info JEMALLOC_N(tcache_bin_info) and: # define JEMALLOC_N(n) __je_##n But gdb reports: (gdb) print __je_tcache_bin_info $3 =3D (cache_bin_info_t *) 0x0 (gdb) print alloc_ctx $1 =3D {szind =3D 0, slab =3D } so bin_info =3D NULL and bin_info->ncached_max would fail (and does). By contrast, bin->ncached seems to be from: (gdb) print *(cache_bin_t*)0x50094018 $6 =3D {low_water =3D 65536, ncached =3D 1, tstats =3D {nrequests =3D = 4796680610075595179}, avail =3D 0x0} For rpcbind: Core was generated by `/usr/sbin/rpcbind'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x50243fec in rendezvous_request (xprt=3D, = msg=3D) at /usr/src/lib/libc/rpc/svc_vc.c:323 323 newxprt->xp_raddr =3D *(struct sockaddr_in = *)newxprt->xp_rtaddr.buf; (gdb) print *newxprt $5 =3D {xp_fd =3D 14, xp_port =3D 0, xp_ops =3D 0x50329e1c, xp_addrlen =3D= 0, xp_raddr =3D {sin_len =3D 0 '\000', sin_family =3D 0 '\000', = sin_port =3D 0, sin_addr =3D {s_addr =3D 0},=20 sin_zero =3D "\000\000\000\000P1O\374"}, xp_ops2 =3D 0x50329e34, = xp_tp =3D 0x0, xp_netid =3D 0x50047310 "unix", xp_ltaddr =3D {maxlen =3D = 1345322064, len =3D 1970170232, buf =3D 0x2020}, xp_rtaddr =3D { maxlen =3D 268500992, len =3D 16, buf =3D 0x0}, xp_verf =3D = {oa_flavor =3D 0, oa_base =3D 0x202d2020 , oa_length =3D 538976364}, xp_p1 =3D 0x6f6f7000,=20 xp_p2 =3D 0x0, xp_p3 =3D 0x202d2020, xp_type =3D 538976288} so newxprt->xp_rtaddr.buf =3D=3D 0x0 . But taht is very odd . . . /* * make a new transporter (re-uses xprt) */ newxprt =3D makefd_xprt(sock, r->sendsize, r->recvsize); newxprt->xp_rtaddr.buf =3D mem_alloc(len); if (newxprt->xp_rtaddr.buf =3D=3D NULL) return (FALSE); memcpy(newxprt->xp_rtaddr.buf, &addr, len); newxprt->xp_rtaddr.len =3D len; #ifdef PORTMAP if (addr.ss_family =3D=3D AF_INET || addr.ss_family =3D=3D = AF_LOCAL) { newxprt->xp_raddr =3D *(struct sockaddr_in = *)newxprt->xp_rtaddr.buf; newxprt->xp_addrlen =3D sizeof (struct sockaddr_in); } #endif /* PORTMAP */ Or, in machine code terms: 0x50243f90 <+260>: mr r28,r3 0x50243f94 <+264>: lwz r4,0(r24) 0x50243f98 <+268>: lwz r5,4(r24) 0x50243f9c <+272>: mr r3,r28 0x50243fa0 <+276>: bl 0x5024308c 0x50243fa4 <+280>: lwz r27,36(r1) 0x50243fa8 <+284>: mr r29,r3 0x50243fac <+288>: li r3,1 0x50243fb0 <+292>: mr r4,r27 0x50243fb4 <+296>: bl 0x502e3214 <00000000.plt_pic32.calloc> 0x50243fb8 <+300>: cmplwi r3,0 0x50243fbc <+304>: stw r3,64(r29) 0x50243fc0 <+308>: beq 0x50244160 Note: getting here means that newxprt->xp_rtaddr.buf ws not NULL . Also the value was stored to 64(r29). 0x50243fc4 <+312>: addi r4,r1,296 0x50243fc8 <+316>: mr r5,r27 0x50243fcc <+320>: bl 0x502e3264 <00000000.plt_pic32.memcpy> Note: getting here means that memcpy was able to store where ewxprt->xp_rtaddr.buf indicated (as the r3 value). 0x50243fd0 <+324>: lbz r3,297(r1) 0x50243fd4 <+328>: stw r27,60(r29) 0x50243fd8 <+332>: addi r3,r3,-1 0x50243fdc <+336>: clrlwi r3,r3,24 0x50243fe0 <+340>: cmplwi r3,1 0x50243fe4 <+344>: bgt 0x50244014 0x50243fe8 <+348>: lwz r3,64(r29) =3D> 0x50243fec <+352>: lwz r4,0(r3) Note: the failure was above with r3=3D=3D0x0: (gdb) info reg r0 0x50243fb8 1344552888 r1 0xffffb400 4294947840 r2 0x500a1018 1342836760 r3 0x0 0 r4 0xffffb538 4294948152 r5 0x10 16 r6 0x50047328 1342468904 r7 0x0 0 r8 0x50047324 1342468900 r9 0x0 0 r10 0x20 32 r11 0x502d691c 1345153308 r12 0x24200880 606079104 r13 0x0 0 r14 0x0 0 r15 0xffffbc28 4294949928 r16 0x10002848 268445768 r17 0x10040000 268697600 r18 0x2 2 r19 0x0 0 r20 0x1 1 r21 0x5004c044 1342488644 r22 0xffffb63c 4294948412 r23 0x80 128 r24 0x50048010 1342472208 r25 0x14 20 r26 0xffffb630 4294948400 r27 0x10 16 r28 0xe 14 r29 0x500472e0 1342468832 r30 0x5030112c 1345327404 r31 0x10040000 268697600 pc 0x50243fec 0x50243fec msr cr 0x84200080 2216689792 lr 0x50243fd0 0x50243fd0 ctr 0x0 0 xer 0x0 0 fpscr 0x0 0 vscr vrsave Note: The rest of the 2 assignments would have been done by: 0x50243ff0 <+356>: stw r4,16(r29) 0x50243ff4 <+360>: lwz r4,4(r3) 0x50243ff8 <+364>: stw r4,20(r29) 0x50243ffc <+368>: lwz r4,8(r3) 0x50244000 <+372>: stw r4,24(r29) 0x50244004 <+376>: li r4,16 0x50244008 <+380>: lwz r3,12(r3) 0x5024400c <+384>: stw r4,12(r29) 0x50244010 <+388>: stw r3,28(r29) My only guesses for alternatives are: A) A processor context switch where the other processor did not (yet) see the value stored via 64(r29) and so it used an older value. B) Something trashed the memory at 64(r29) after it was updated by the code above. C) r29's value was trashed by something, changing where 64(r29) referenced. D) r3 was trashed between the two back-to-back instructions: 0x50243fe8 <+348>: lwz r3,64(r29) =3D> 0x50243fec <+352>: lwz r4,0(r3) E) ??? I've no clue which. Both .core files seem to have zero's showing up in unexpected places previously non-zero. =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 May 4 18:16:24 2020 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 4E4AD2D6483 for ; Mon, 4 May 2020 18:16:24 +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 49G9zC3kRYz4XP0 for ; Mon, 4 May 2020 18:16:23 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: LIeyrEgVM1li9ooYhqzhtSDUrWGsBQaCd98bLHYPxzr1tWDaTQiFgQsVdy3sLYQ DuY7YJWnuvRsz8wt20s_q1gEXLVVWUJh4J7L8XXZfRdqA2QEDbPuojhsTo2VCZbDj3ZF.7eI0lfz o9c7ALvAJ6spb7M13DWi.WLosHHwcCt04GW6O8TjA2mlM_1bsBxCcfNWdqTo..lAnYHjPEDBx7HV _2Tx1qIzQ0cOI6GRFvSIsXRo5_nYDcyP4awQVt17mJBdAdz6Yk0vj82E5_JvCI0leB62JA3tm78h 1XD5wQwUZlerLBCGKHqLs7qcDxNr9pv3ZV8LLDFFT.tFMFBhVGs6Rs3O4IpXpFEr1cMiOnFHAhte Da.EZXxSbmsUFkHC0su6tanKGYhKy42h7GJ5OqkojE.nD7H78Vn0GLA93fU7dMt4_RlHcKBG0lxX vz3tNV4s0kGeIQEz53hRxg5yqWEeTuzc6mbNmjjN0.UVqbg3TjZzyLIuXvHvH2xBQgfdsz3VfrqZ vfA26Zu6oKgZ8Ez66yktajslvTCiZNlCGBnDitZ_ZitHlKk5_zk4KzX2BOe1dRzuyLyrkyw6FAeY LGllG7Pcf5JChIynJj6g6ghPqlCEY0JsByIIzUhzRP15Bh51CAgFN41VfGV2XAitDX5YVpBCdIZy Td8B.fb2u0R6Fmwh9b_5JFLJJMZs.gsTKEAx8HwjLQjNHpQodaUV4eEoFq6fqBdsNJaLg8KZ1acV 7yHmFiZiHKItADe.WNn3cFhzQn7gRXafkxT0J75Br5IEJWHBOEqjYCh1HHhqmGg4YAplI9nRFnzc WGIwg69XgJ86bPT6I_kpA4mTgUUa5lcHOGsVwEtKBGkoJXUXVTl9agBtFFtV6uHGuYJsGvCV8bWQ imQUDp3YhDa0AZ2OO3XCkOSGtGJFwOnEnqZnsowIrQRC7PTldWSC9Mh6cKxsLAQktEBdaqf84vX3 DpS6UUYwVDWQWgNJtDyFUiFx1KxQ.7_ZAoSEkO2zk7WahJ6aq_R5QA55BRyhAYOnTMezWiEQINqe X7BU8mdf2zwRz4wP0wew6kBTKybCFZP95mAQQXhlqMUbZkuA9PVCnTQe7z4h8RQ2Pn3KJNgopgR1 IUmbIHXyAgT4r.t3wNabY8D.Bdh7aT99AMohI_UcQplI8D0fDqyDIf8ZAdMKlAQ3sey.uUzqokMw wRQsSJ4FyGIPWpc.7WYefhujclI_4uqWnDhGhlowYfWeMVYP6PaePQZ0q_rOvAAvpvToWbVPcvO_ pL3eiTH.l.HOZk3MvqnPmtNOjJ7lSvxkLpNpI0mhpR3s4xKJ58eeMgODzqBAk2KLkOyWyKpozc6d Uu68LoHo4fJZEtTpZPLGb57.PJZ_nNAKDfvgLeFoXGEQCfGqQ9pEV066Ro2m.tdyKUvItA_N7.pH fbUbXHzl7f9mOfQYNyX1hQt7mvs8Xwcw- Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.gq1.yahoo.com with HTTP; Mon, 4 May 2020 18:16:22 +0000 Received: by smtp412.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID a91220a105656127b80ed8ef3721be0e; Mon, 04 May 2020 18:16:17 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: svn commit: r360233 - in head: contrib/jemalloc . . . : This partially breaks a 2-socket 32-bit powerpc (old PowerMac G4) based on head -r360311 From: Mark Millard In-Reply-To: <695E6836-F860-4557-B7DE-CC1EDB347F18@yahoo.com> Date: Mon, 4 May 2020 11:16:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8479DD58-44F6-446A-9CA5-D01F0F7C1B38@yahoo.com> <17ACDA02-D7EF-4F26-874A-BB3E935CD072@yahoo.com> <695E6836-F860-4557-B7DE-CC1EDB347F18@yahoo.com> To: "vangyzen@freebsd.org" , svn-src-head@freebsd.org, FreeBSD Current , FreeBSD Hackers , FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49G9zC3kRYz4XP0 X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.43 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; RCPT_COUNT_FIVE(0.00)[6]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.94)[-0.940,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.99)[-0.994,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ip: (3.26), ipnet: 98.137.64.0/21(0.83), asn: 36647(0.66), country: US(-0.05)]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[148.68.137.98.list.dnswl.org : 127.0.5.0]; RWL_MAILSPIKE_POSSIBLE(0.00)[148.68.137.98.rep.mailspike.net : 127.0.0.17]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2020 18:16:24 -0000 [This report just shows some material for the sendmail SIGSEGV's, based on truss output.] I've returned to using the modern jemalloc because it seems to show problems more, after having caught the earlier reported dhclient example under the older jemalloc context. (Again: jemalloc may be exposing a problem elsewhere.) I had truss monitor sendmail, including following child processes. A child process start and end normally looks like: 963: 3092.707439595 0.000033895 sigprocmask(SIG_SETMASK,{ SIGCHLD = },0x0) =3D 0 (0x0) 2432: 3092.708024959 0.000000000 963: 3092.708136462 0.000470115 fork() =3D 2432 (0x980) 2432: 3092.708441039 0.000033319 thr_self(0x50120000) =3D 0 (0x0) . . . 2432: 3092.717283761 0.000036008 sigaction(SIGQUIT,{ SIG_IGN SA_RESTART = ss_t },{ SIG_IGN SA_RESTART ss_t }) =3D 0 (0x0) 2432: 3092.717544288 0.000034352 sigprocmask(SIG_SETMASK,{ },0x0) =3D 0 = (0x0) 2432: 3092.717799894 0.000035768 close(0) =3D 0 (0x0) 2432: 3092.718174733 0.000103726 = openat(AT_FDCWD,"/dev/null",O_RDONLY,00) =3D 0 (0x0) 2432: 3092.718480437 0.000052091 = openat(AT_FDCWD,"/dev/null",O_WRONLY,00) =3D 4 (0x4) 2432: 3092.718778028 0.000037856 dup2(4,1) =3D 1 (0x1) 2432: 3092.719003051 0.000034255 dup2(4,2) =3D 2 (0x2) 2432: 3092.719225122 0.000033655 close(4) =3D 0 (0x0) 2432: 3092.719437735 0.000047626 fstat(0,{ mode=3Dcrw-rw-rw- = ,inode=3D22,size=3D0,blksize=3D4096 }) =3D 0 (0x0) 2432: 3092.719679274 0.000037400 fstat(1,{ mode=3Dcrw-rw-rw- = ,inode=3D22,size=3D0,blksize=3D4096 }) =3D 0 (0x0) 2432: 3092.719908859 0.000035816 fstat(2,{ mode=3Dcrw-rw-rw- = ,inode=3D22,size=3D0,blksize=3D4096 }) =3D 0 (0x0) 2432: 3092.720138299 0.000033727 clock_gettime(13,{ = 1588570204.000000000 }) =3D 0 (0x0) 2432: 3092.720658945 0.000035360 getpid() =3D 2432 (0x980) 2432: 3092.720931594 0.000048730 = __sysctl("kern.proc.args.2432",4,0x0,0x0,0x508ae000,49) =3D 0 (0x0) 2432: 3092.721572338 0.000062318 = open(".",O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC,00) =3D 4 (0x4) 2432: 3092.721962132 0.000037808 fcntl(4,F_ISUNIONSTACK,0x0) =3D 0 = (0x0) 2432: 3092.722323792 0.000098613 = getdirentries(4,"\0\0\0\0\0\t\M-I\M^Q\0\0\0\0\0\0"...,4096,{ 0x0 }) =3D = 144 (0x90) 2432: 3092.722944875 0.000036944 getdirentries(4,0x50859000,4096,{ = 0x200 }) =3D 0 (0x0) 2432: 3092.723294461 0.000045250 close(4) =3D 0 (0x0) 2432: 3092.723576400 0.000041144 clock_gettime(13,{ = 1588570204.000000000 }) =3D 0 (0x0) 2432: 3092.723828718 0.000037928 setitimer(0,{ 0.000000, 0.000000 = },0x0) =3D 0 (0x0) 2432: 3092.724092245 0.000035815 sigprocmask(SIG_UNBLOCK,{ SIGALRM },{ = }) =3D 0 (0x0) 2432: 3092.724591527 0.000038024 getpid() =3D 2432 (0x980) 2432: 3092.724952323 0.000052955 setuid(0x0) ERR#1 'Operation not = permitted' 2432: 3092.727852159 0.000042969 clock_gettime(4,{ 21633.960374942 }) =3D= 0 (0x0) 2432: 3092.728508193 0.000034327 clock_gettime(4,{ 21633.961033929 }) =3D= 0 (0x0) 2432: 3092.729146608 0.000036872 clock_gettime(4,{ 21633.961670903 }) =3D= 0 (0x0) 2432: 3092.729824967 0.000038360 clock_gettime(4,{ 21633.962349071 }) =3D= 0 (0x0) 2432: 3092.732435446 0.001634793 exit(0x0) =20 2432: 3092.732555855 0.001755202 process exit, rval =3D 0 963: 3092.732638865 0.018571063 SIGNAL 20 (SIGCHLD) code=3DCLD_EXITED = pid=3D2432 uid=3D25 status=3D0 963: 3092.732822864 0.018755062 sigsuspend({ }) ERR#4 'Interrupted = system call' 963: 3092.733076525 0.000039968 sigprocmask(SIG_SETMASK,{ SIGCHLD = },0x0) =3D 0 (0x0) 963: 3092.733447788 0.000076601 wait4(-1,{ EXITED,val=3D0 = },WNOHANG,0x0) =3D 2432 (0x980) 963: 3092.733781410 0.000034783 wait4(-1,0xffffbe60,WNOHANG,0x0) = ERR#10 'No child processes' 963: 3092.734065366 0.000037328 sigreturn(0xffffbe90) EJUSTRETURN 963: 3092.734263408 0.000033295 sigprocmask(SIG_BLOCK,0x0,{ }) =3D 0 = (0x0) (No activity in 963 for about 1800 seconds.) But once it starts failing, the SIGSEGV happens just after the: setuid(0x0) ERR#1 'Operation not permitted' For example: . . . 4745: 37293.335510778 0.000035023 clock_gettime(13,{ = 1588604405.000000000 }) =3D 0 (0x0) 4745: 37293.335754863 0.000037593 setitimer(0,{ 0.000000, 0.000000 = },0x0) =3D 0 (0x0) 4745: 37293.336010253 0.000036200 sigprocmask(SIG_UNBLOCK,{ SIGALRM },{ = }) =3D 0 (0x0) 4745: 37293.336488027 0.000033823 getpid() =3D 4745 (0x1289) 4745: 37293.336836797 0.000051995 setuid(0x0) ERR#1 'Operation not = permitted' 4745: 37293.338022675 0.001237873 SIGNAL 11 (SIGSEGV) code=3DSEGV_MAPERR = trapno=3D768 addr=3D0x506a11f0 4745: 37293.339546520 0.002761718 process killed, signal =3D 11 963: 37293.339627249 0.050797919 SIGNAL 20 (SIGCHLD) code=3DCLD_KILLED = pid=3D4745 uid=3D25 status=3D11 963: 37293.339794781 0.050965451 sigsuspend({ }) ERR#4 'Interrupted = system call' 963: 37293.340038313 0.000037544 sigprocmask(SIG_SETMASK,{ SIGCHLD = },0x0) =3D 0 (0x0) 963: 37293.340329951 0.000070215 wait4(-1,{ SIGNALED,sig=3DSIGSEGV = },WNOHANG,0x0) =3D 4745 (0x1289) 963: 37293.340634048 0.000034903 wait4(-1,0xffffbe60,WNOHANG,0x0) = ERR#10 'No child processes' 963: 37293.340901417 0.000037615 sigreturn(0xffffbe90) EJUSTRETURN 963: 37293.341090122 0.000033319 sigprocmask(SIG_BLOCK,0x0,{ }) =3D 0 = (0x0) (Another about 1800 seconds.) So it seems that sendmail's SIGSEGV always happens during the winding down of the child process: getting ready to exit. So far, it seems that once it starts happening, it happens for each child process created after that. =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 May 4 21:11:05 2020 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 B02EB2C3537 for ; Mon, 4 May 2020 21:11:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49GFrn4CMBz3KD7 for ; Mon, 4 May 2020 21:11:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by freefall.freebsd.org (Postfix) id 89A511596A; Mon, 4 May 2020 21:11:05 +0000 (UTC) Delivered-To: powerpc@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [96.47.72.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id 8745315969 for ; Mon, 4 May 2020 21:11:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49GFrn2Hwsz3KD2 for ; Mon, 4 May 2020 21:11:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4A1822855 for ; Mon, 4 May 2020 21:11:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 044LB54U024347 for ; Mon, 4 May 2020 21:11:05 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 044LB549024337 for powerpc@FreeBSD.org; Mon, 4 May 2020 21:11:05 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: powerpc@FreeBSD.org Subject: [Bug 246194] math/blis: pacify portlint, add test target, optimize for power9 Date: Mon, 04 May 2020 21:11:04 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: pkubaj@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: jmd@freebsd.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter cc flagtypes.name attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2020 21:11:05 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D246194 Bug ID: 246194 Summary: math/blis: pacify portlint, add test target, optimize for power9 Product: Ports & Packages Version: Latest Hardware: powerpc OS: Any Status: New Severity: Affects Only Me Priority: --- Component: Individual Port(s) Assignee: jmd@freebsd.org Reporter: pkubaj@FreeBSD.org CC: powerpc@FreeBSD.org Assignee: jmd@freebsd.org CC: powerpc@FreeBSD.org Flags: maintainer-feedback?(jmd@freebsd.org) Created attachment 214125 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D214125&action= =3Dedit patch 1. Move USES block to pacify portlint. 2. Add test target. 3. Add perl as a build dependency, I'm not sure how it worked before. 4. Optimize for power9 on powerpc64. This will break blis on all earlier PO= WER generations, but nothing depends on this port so I guess it's ok. make test passes fine on both elfv1 and elfv2. 5. Remove LIBNAME, it's not necessary. Question: would it be possible to add flavors with all kernels? That way, u= sers could install the version optimized for their CPU or just generic. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-ppc@freebsd.org Mon May 4 21:11:23 2020 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 64EE12C35AE for ; Mon, 4 May 2020 21:11:23 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49GFs70Y95z3KP6 for ; Mon, 4 May 2020 21:11:23 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by freefall.freebsd.org (Postfix) id 0992F15C1A; Mon, 4 May 2020 21:11:23 +0000 (UTC) Delivered-To: powerpc@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id 06A3F15A46 for ; Mon, 4 May 2020 21:11:23 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49GFs65f4Tz3KNs for ; Mon, 4 May 2020 21:11:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id BD3102876 for ; Mon, 4 May 2020 21:11:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 044LBMxn039733 for ; Mon, 4 May 2020 21:11:22 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 044LBMHs039725 for powerpc@FreeBSD.org; Mon, 4 May 2020 21:11:22 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: powerpc@FreeBSD.org Subject: [Bug 246194] math/blis: pacify portlint, add test target, optimize for power9 Date: Mon, 04 May 2020 21:11:22 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: pkubaj@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: jmd@freebsd.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: cc flagtypes.name Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2020 21:11:23 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D246194 Piotr Kubaj changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jmd@freebsd.org Attachment #214125| |maintainer-approval?(jmd@fr Flags| |eebsd.org) --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-ppc@freebsd.org Tue May 5 08:52:35 2020 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 7AFDB2DCE88 for ; Tue, 5 May 2020 08:52:35 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-21.consmr.mail.gq1.yahoo.com (sonic313-21.consmr.mail.gq1.yahoo.com [98.137.65.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 49GYQB3R4rz4YR6 for ; Tue, 5 May 2020 08:52:34 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 45cOfUYVM1nnpRZ33.aMxVMjSiZ4AG_vYL0FwrHrpO7VaAFhdklIEfC9zGIRjyz GXZjb2NYXPub2F3iVpivu3EyANzT9in3EHE0EHurFD3bDJtif3FKJKKlbmwqDLN6v.YL9SMYk2oM CCCqlLImoAINRo79X1TyeVQ3WJsG313XI_QbmSC_WsPNLnlffP.hc1JFPJzdAkhDf9nQ9zqW3UTV zX_dNJyHukdSh54bOiv5oBk7pJUWUy7l9QXs4a1TO1hlah_gcaBcm3F7fSLoNfG6pV9L9d7k3H0J Pc30MGC5yTV5mvmf9lAQVXE1EZFxNXO_fZZEfOhdjDvCbNJouD1PiIra_5Lsr.eKk7O.5biMCueA jPB3KKLa3yrkQmbgQLvC8Z8.gKgLcMpk3B0UUjWQyzRpWSmm7inACIBlZ2d0tfz4u.4JFVY7R01m AyXrbIq0zmw6Yl7koe3FUTYclzbQsaEjnuPXfNyAqqohr3mGsgkgt1Va72ahPtUBe5UicT32yS8Q uabeMpmz2o73du._KFb0cTyPV9bifh_ZMizkiT13MPusvAidZyPC6kO3SnMiUjhXm.ok7m9Q2h3E oEMUd0cGUflqJao1fBguO1tGoh2PNGjurwlU_7tStIqwtdE0v398.NFSDe4jfBM5m3ajfQeTuujO WaXSI.Qx_oA_VhoTWn6CkeQnb4sB8JyzMloIUqLjT8NSdN8l6C6VEw5hBfECUC8188SBZVX27hXF IXwHfEg_AOeJ_Qo0hJm6ZgRuSNVDd3_cwdq.LeTQoHYJpue9uaAS6PCisVjRSBmDZpdKPaTEghUk Z1AN4EfdyyMBiomrcYxLdRWtJWUDXYWp1kdRUYlyX5g6bUZbch70F_ifnIvLkFnK2I4YkLZP384N FGFKCIzlt75XwafGGiQjYqoirgiPBo4ITrYUplwc_WYn3Zwvzmnhk0wXrO8pJJ4N2I4wI.w1TRBd m70VAweMW.t48tj_xYJgUaEfEFIc7urswFyJ5XvZK6fOD9EuhydE0_hk_Z_jKLA8XRZSE4x.QuH9 k1HgRKCapVZHMC5iNdYMfBYN3QShQ4pDA1kezt0TkJK46tdxCTeE037ZjGBTw_HZqMtIqI.4kEfv JatltgZybgNc4mpkd4hA3BA1LdEqZyYh_MiUUy_Cbymj_HvV228fx5Vfa0JCc_fYXmd0saRizQ5Z Rm4aP.ubUk6hpnEltHOqQnIAkcB4wxxR4v66kWo3sBW93k79n.FYD0oWQL6eJDi7oo2uHzsdAFn. Z_o.tSJPhZRhnq.TbpT2p5pjDCATsjKCzDJE0C0.ew2Dcd4YywaelGVJdsvEWCS3oGISsTdm4rH3 2Lv4ZRYlU1MgsRk3sw5nvy7.nc5lXy0PKI4AS6B8tKHaQQ4FUxWq1iYvyA1mF3B764Mw96Qox.5u H2JqwKyJqY_DUvZqQXoBRYYpAk2UWfNLdSibGbgvuOwR1Gw8lz1wwgRsHD20CF_8- Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Tue, 5 May 2020 08:52:33 +0000 Received: by smtp434.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID da1665613de72442d31e291f1d443e23; Tue, 05 May 2020 08:52:29 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: svn commit: r360233 - in head: contrib/jemalloc . . . : This partially breaks a 2-socket 32-bit powerpc (old PowerMac G4) based on head -r360311 From: Mark Millard In-Reply-To: Date: Tue, 5 May 2020 01:52:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <121B9B09-141B-4DC3-918B-1E7CFB99E779@yahoo.com> References: <8479DD58-44F6-446A-9CA5-D01F0F7C1B38@yahoo.com> <17ACDA02-D7EF-4F26-874A-BB3E935CD072@yahoo.com> <695E6836-F860-4557-B7DE-CC1EDB347F18@yahoo.com> To: "vangyzen@freebsd.org" , svn-src-head@freebsd.org, FreeBSD Current , FreeBSD Hackers , FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49GYQB3R4rz4YR6 X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.49 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; RCPT_COUNT_FIVE(0.00)[6]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.989,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ip: (1.00), ipnet: 98.137.64.0/21(0.83), asn: 36647(0.66), country: US(-0.05)]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[84.65.137.98.list.dnswl.org : 127.0.5.0]; RWL_MAILSPIKE_POSSIBLE(0.00)[84.65.137.98.rep.mailspike.net : 127.0.0.17]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2020 08:52:35 -0000 [This report just shows an interesting rpcbind crash: a pointer was filled with part of a string instead, leading to a failed memory access attempt from the junk address produced.] Core was generated by `/usr/sbin/rpcbind'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x5024405c in rendezvous_request (xprt=3D, = msg=3D) at /usr/src/lib/libc/rpc/svc_vc.c:335 335 cd->recvsize =3D r->recvsize; (gdb) list 330 _setsockopt(sock, IPPROTO_TCP, TCP_NODELAY, = &len, sizeof (len)); 331 } 332=09 333 cd =3D (struct cf_conn *)newxprt->xp_p1; 334=09 335 cd->recvsize =3D r->recvsize; 336 cd->sendsize =3D r->sendsize; 337 cd->maxrec =3D r->maxrec; 338=09 339 if (cd->maxrec !=3D 0) { (gdb) print/c *cd Cannot access memory at address 0x2d202020 FYI: . . . 0x50244050 <+452>: bl 0x502e3404 = <00000000.plt_pic32._setsockopt> 0x50244054 <+456>: lwz r27,80(r29) 0x50244058 <+460>: lwz r3,4(r24) =3D> 0x5024405c <+464>: stw r3,436(r27) Note the 80(r29) use. (gdb) info reg r0 0x50244020 1344552992 r1 0xffffb400 4294947840 r2 0x500a1018 1342836760 r3 0x2328 9000 r4 0x32ef559c 854545820 r5 0x0 0 r6 0xffffb360 4294947680 r7 0xffffb364 4294947684 r8 0x5004733c 1342468924 r9 0x0 0 r10 0x20 32 r11 0x50252ea0 1344614048 r12 0x24200ca0 606080160 r13 0x0 0 r14 0x0 0 r15 0xffffbc28 4294949928 r16 0x10002848 268445768 r17 0x10040000 268697600 r18 0x2 2 r19 0x0 0 r20 0x1 1 r21 0x5004c044 1342488644 r22 0xffffb63c 4294948412 r23 0x80 128 r24 0x50048010 1342472208 r25 0x14 20 r26 0xffffb630 4294948400 r27 0x2d202020 757080096 r28 0xf 15 r29 0x50047308 1342468872 r30 0x5030112c 1345327404 r31 0x10040000 268697600 pc 0x5024405c 0x5024405c msr cr 0x842000a0 2216689824 lr 0x50244020 0x50244020 ctr 0x50252ea0 1344614048 xer 0x0 0 fpscr 0x0 0 vscr vrsave (gdb) x/s 0x50047308+72 0x50047350: " - - -\n" So it tried to use "- " as a pointer value. It appears that the r29 value was from: 0x50243f90 <+260>: mr r28,r3 0x50243f94 <+264>: lwz r4,0(r24) 0x50243f98 <+268>: lwz r5,4(r24) 0x50243f9c <+272>: mr r3,r28 0x50243fa0 <+276>: bl 0x5024308c 0x50243fa4 <+280>: lwz r27,36(r1) 0x50243fa8 <+284>: mr r29,r3 The makefd_xprt being used as part of: /* * make a new transporter (re-uses xprt) */ newxprt =3D makefd_xprt(sock, r->sendsize, r->recvsize); newxprt->xp_rtaddr.buf =3D mem_alloc(len); if (newxprt->xp_rtaddr.buf =3D=3D NULL) return (FALSE); memcpy(newxprt->xp_rtaddr.buf, &addr, len); newxprt->xp_rtaddr.len =3D len; #ifdef PORTMAP if (addr.ss_family =3D=3D AF_INET || addr.ss_family =3D=3D = AF_LOCAL) { newxprt->xp_raddr =3D *(struct sockaddr_in = *)newxprt->xp_rtaddr.buf; newxprt->xp_addrlen =3D sizeof (struct sockaddr_in); } #endif /* PORTMAP */ if (__rpc_fd2sockinfo(sock, &si) && si.si_proto =3D=3D = IPPROTO_TCP) { len =3D 1; /* XXX fvdl - is this useful? */ _setsockopt(sock, IPPROTO_TCP, TCP_NODELAY, &len, sizeof = (len)); } =20 cd =3D (struct cf_conn *)newxprt->xp_p1; =20 cd->recvsize =3D r->recvsize; cd->sendsize =3D r->sendsize; cd->maxrec =3D r->maxrec; FYI: (gdb) print *r $5 =3D {sendsize =3D 9000, recvsize =3D 9000, maxrec =3D 9000} There is more evidence of strings in pointers in *newxprt (xp_tp, oa_base, xp_p1, xp_p2, xp_p3): (gdb) print *newxprt $7 =3D {xp_fd =3D 15, xp_port =3D 0, xp_ops =3D 0x50329e1c, xp_addrlen =3D= 16, xp_raddr =3D {sin_len =3D 16 '\020', sin_family =3D 1 '\001', = sin_port =3D 0, sin_addr =3D {s_addr =3D 0},=20 sin_zero =3D "\000\000\000\000\000\000\000"}, xp_ops2 =3D = 0x756e6978, xp_tp =3D 0x2020 ,=20 xp_netid =3D 0x10010000 , xp_ltaddr =3D {maxlen =3D 0, len =3D 0, buf =3D 0x0}, = xp_rtaddr =3D {maxlen =3D 539828256, len =3D 16, buf =3D 0x50047330}, = xp_verf =3D { oa_flavor =3D 0, oa_base =3D 0x202d2020 , oa_length =3D 538976288}, xp_p1 =3D 0x2d202020, = xp_p2 =3D 0x20202020, xp_p3 =3D 0x2d0a0079, xp_type =3D 543780384} (gdb) print (char*)(&newxprt->xp_verf.oa_base) $24 =3D 0x50047350 " - - -\n" (gdb) print (char*)(&newxprt->xp_p3)+3 $13 =3D 0x50047363 "y in FreeBSD.\n" (gdb) print (char*)(&newxprt->xp_type) $25 =3D 0x50047364 " in FreeBSD.\n" =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 May 5 14:18:24 2020 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 B068413813C for ; Tue, 5 May 2020 14:18:24 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49Ghf84Jp7z43fY for ; Tue, 5 May 2020 14:18:24 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by freefall.freebsd.org (Postfix) id 886686104; Tue, 5 May 2020 14:18:24 +0000 (UTC) Delivered-To: powerpc@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id 6B3175EDA for ; Tue, 5 May 2020 14:18:24 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49Ghf80xStz43fS for ; Tue, 5 May 2020 14:18:24 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 1AB6CF3A9 for ; Tue, 5 May 2020 14:18:24 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 045EIN6w090815 for ; Tue, 5 May 2020 14:18:23 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 045EINiJ090814 for powerpc@FreeBSD.org; Tue, 5 May 2020 14:18:23 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: powerpc@FreeBSD.org Subject: [Bug 246224] lang/ghc: bad distinfo for powerpc64 elfv2 bootstrap Date: Tue, 05 May 2020 14:18:23 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: pkubaj@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: haskell@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter cc flagtypes.name Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2020 14:18:24 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D246224 Bug ID: 246224 Summary: lang/ghc: bad distinfo for powerpc64 elfv2 bootstrap Product: Ports & Packages Version: Latest Hardware: powerpc OS: Any Status: New Severity: Affects Only Me Priority: --- Component: Individual Port(s) Assignee: haskell@FreeBSD.org Reporter: pkubaj@FreeBSD.org CC: powerpc@FreeBSD.org CC: powerpc@FreeBSD.org Assignee: haskell@FreeBSD.org Flags: maintainer-feedback?(haskell@FreeBSD.org) =3D>> Status lang/ghc | ghc-8.8.3: fetch =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D> License BSD3CLAUSE accepted by the user =3D=3D=3D> ghc-8.8.3 depends on file: /usr/local/sbin/pkg - found =3D> ghc-8.6.5-boot-powerpc64-freebsd-elfv2.tar.xz doesn't seem to exist in /portdistfiles/. =3D> Attempting to fetch http://distcache.FreeBSD.org/local-distfiles/arrowd/ghc-8.6.5-boot-powerpc6= 4-freebsd-elfv2.tar.xz fetch: http://distcache.FreeBSD.org/local-distfiles/arrowd/ghc-8.6.5-boot-powerpc6= 4-freebsd-elfv2.tar.xz: size mismatch: expected 112469852, actual 113782560 =3D> Attempting to fetch http://distcache.us-east.FreeBSD.org/local-distfiles/arrowd/ghc-8.6.5-boot-= powerpc64-freebsd-elfv2.tar.xz fetch: http://distcache.us-east.FreeBSD.org/local-distfiles/arrowd/ghc-8.6.5-boot-= powerpc64-freebsd-elfv2.tar.xz: size mismatch: expected 112469852, actual 113782560 =3D> Attempting to fetch http://distcache.eu.FreeBSD.org/local-distfiles/arrowd/ghc-8.6.5-boot-power= pc64-freebsd-elfv2.tar.xz fetch: http://distcache.eu.FreeBSD.org/local-distfiles/arrowd/ghc-8.6.5-boot-power= pc64-freebsd-elfv2.tar.xz: size mismatch: expected 112469852, actual 113782560 =3D> Attempting to fetch http://distcache.us-west.FreeBSD.org/local-distfiles/arrowd/ghc-8.6.5-boot-= powerpc64-freebsd-elfv2.tar.xz fetch: http://distcache.us-west.FreeBSD.org/local-distfiles/arrowd/ghc-8.6.5-boot-= powerpc64-freebsd-elfv2.tar.xz: size mismatch: expected 112469852, actual 113782560 =3D> Attempting to fetch http://distcache.FreeBSD.org/ports-distfiles/ghc-8.6.5-boot-powerpc64-freeb= sd-elfv2.tar.xz fetch: http://distcache.FreeBSD.org/ports-distfiles/ghc-8.6.5-boot-powerpc64-freeb= sd-elfv2.tar.xz: Not Found --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-ppc@freebsd.org Tue May 5 16:15:05 2020 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 2D09D13B5BC for ; Tue, 5 May 2020 16:15:05 +0000 (UTC) (envelope-from luciano@vespaperitivo.it) Received: from baobab.bilink.net (baobab.bilink.net [212.45.144.44]) by mx1.freebsd.org (Postfix) with ESMTP id 49GlDl5Rz9z4BYl for ; Tue, 5 May 2020 16:15:03 +0000 (UTC) (envelope-from luciano@vespaperitivo.it) Received: from baobab.bilink.net (localhost [127.0.0.1]) by baobab.bilink.it (Postfix) with ESMTP id 49GlDb5ZFlz1ftWm for ; Tue, 5 May 2020 18:14:55 +0200 (CEST) Received: from hermes.mcs.it (hermes.mcs.it [192.168.132.21]) by baobab.bilink.it (Postfix) with ESMTP id 49GlDb4pB5z1ftWf for ; Tue, 5 May 2020 18:14:55 +0200 (CEST) Received: from mordeus (unknown [192.168.45.6]) by hermes.mcs.it (Postfix) with ESMTP id 806094D277F for ; Tue, 5 May 2020 18:14:55 +0200 (CEST) Date: Tue, 5 May 2020 18:14:27 +0200 From: Luciano Mannucci To: FreeBSD PowerPC ML Subject: nss on PPC64 again X-Mailer: Claws Mail 3.17.4 (GTK+ 2.24.32; amd64-portbld-freebsd12.0) X-Face: 4qPv4GNcD; h<7Q/sK>+GqF4=CR@KmnPkSmwd+#%\F`4yjKO3"C]p'z=(oWRnsYBQGM\5g:4skqQY0NnV'dM:Mm:^/_+I@a"; [-s=ogufdF"9ggQ'=y MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <49GlDb4pB5z1ftWf@baobab.bilink.it> X-Virus-Scanned: PippoLillo, ClamAV using ClamSMTP X-Rspamd-Queue-Id: 49GlDl5Rz9z4BYl X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of luciano@vespaperitivo.it designates 212.45.144.44 as permitted sender) smtp.mailfrom=luciano@vespaperitivo.it X-Spamd-Result: default: False [-5.01 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:212.45.144.0/24]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-ppc@freebsd.org]; DMARC_NA(0.00)[vespaperitivo.it]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_ALL(0.00)[]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:8816, ipnet:212.45.128.0/19, country:IT]; IP_SCORE(-2.81)[ip: (-8.07), ipnet: 212.45.128.0/19(-4.03), asn: 8816(-1.96), country: IT(0.03)] X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2020 16:15:05 -0000 Again, I'm unable to build nss on PPC64. I'm getting: /usr/local/bin/ld: FreeBSD11.3_OPT.OBJ/FreeBSD_SINGLE_SHLIB/sha512-p8.o: ABI version 2 is not compatible with ABI version 1 output /usr/local/bin/ld: failed to merge target specific data of file FreeBSD11.3_OPT.OBJ/FreeBSD_SINGLE_SHLIB/sha512-p8.o collect2: error: ld returned 1 exit status gmake[5]: *** [../../coreconf/rules.mk:291: FreeBSD11.3_OPT.OBJ/FreeBSD_SINGLE_SHLIB/libfreeblpriv3.so] Error 1 gmake[5]: Leaving directory '/usr/ports/security/nss/work/nss-3.52/nss/lib/freebl' gmake[4]: *** [Makefile:650: libs] Error 2 gmake[4]: Leaving directory '/usr/ports/security/nss/work/nss-3.52/nss/lib/freebl' gmake[3]: *** [../coreconf/rules.mk:101: libs] Error 2 gmake[3]: Leaving directory '/usr/ports/security/nss/work/nss-3.52/nss/lib' gmake[2]: *** [coreconf/rules.mk:101: libs] Error 2 gmake[2]: Leaving directory '/usr/ports/security/nss/work/nss-3.52/nss' *** Error code 1 Is that just me? Cheers, Luciano. -- /"\ /Via A. Salaino, 7 - 20144 Milano (Italy) \ / ASCII RIBBON CAMPAIGN / PHONE : +39 2 485781 FAX: +39 2 48578250 X AGAINST HTML MAIL / E-MAIL: posthamster@sublink.sublink.ORG / \ AND POSTINGS / WWW: http://www.lesassaie.IT/ From owner-freebsd-ppc@freebsd.org Tue May 5 19:59:01 2020 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 8A1292C42CA for ; Tue, 5 May 2020 19:59:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49GrC93BZxz4Tdk for ; Tue, 5 May 2020 19:59:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by freefall.freebsd.org (Postfix) id 650C9B9D3; Tue, 5 May 2020 19:59:01 +0000 (UTC) Delivered-To: powerpc@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id 624E8B873 for ; Tue, 5 May 2020 19:59:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49GrC91Dxnz4Tdg for ; Tue, 5 May 2020 19:59:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 219911B677 for ; Tue, 5 May 2020 19:59:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 045Jx0jw021583 for ; Tue, 5 May 2020 19:59:00 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 045Jx0HT021582 for powerpc@FreeBSD.org; Tue, 5 May 2020 19:59:00 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: powerpc@FreeBSD.org Subject: [Bug 246224] lang/ghc: bad distinfo for powerpc64 elfv2 bootstrap Date: Tue, 05 May 2020 19:59:01 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: arrowd@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: haskell@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: cc bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2020 19:59:01 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D246224 Gleb Popov changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |arrowd@FreeBSD.org Status|New |Open --- Comment #1 from Gleb Popov --- I didn't touch this bootstrap. Do you want me to adjust distinfo for a curr= ent bootstrap, or you have a bootstrap that matches current distinfo? --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-ppc@freebsd.org Tue May 5 20:52:16 2020 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 3CDD62C5A18 for ; Tue, 5 May 2020 20:52:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49GsNc0x6Cz4XV5 for ; Tue, 5 May 2020 20:52:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by freefall.freebsd.org (Postfix) id ED729C5B7; Tue, 5 May 2020 20:52:15 +0000 (UTC) Delivered-To: powerpc@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [96.47.72.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id E8E51C53B for ; Tue, 5 May 2020 20:52:15 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49GsNb50pPz4XV1 for ; Tue, 5 May 2020 20:52:15 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id A6E881C1E8 for ; Tue, 5 May 2020 20:52:15 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 045KqF8W089439 for ; Tue, 5 May 2020 20:52:15 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 045KqFnj089438 for powerpc@FreeBSD.org; Tue, 5 May 2020 20:52:15 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: powerpc@FreeBSD.org Subject: [Bug 246224] lang/ghc: bad distinfo for powerpc64 elfv2 bootstrap Date: Tue, 05 May 2020 20:52:15 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: pkubaj@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: haskell@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2020 20:52:16 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D246224 --- Comment #2 from Piotr Kubaj --- This is strange. It looks like it was changed in https://svnweb.freebsd.org/ports/head/lang/ghc/distinfo?r1=3D529204&r2=3D52= 9205&, which was when you commited my patch from https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D245057 I can confirm th= at the bootstrap I uploaded to freefall (I didn't remove it) is the same you used = and it looks like the file wasn't changed, it's still the same I uploaded: pkubaj@freefall:/home/arrowd/public_distfiles % ls -l ghc-8.6.5-boot-powerpc64-freebsd-elfv2.tar.xz -rw-r--r-- 1 arrowd devel 113782560 Mar 13 16:03 ghc-8.6.5-boot-powerpc64-freebsd-elfv2.tar.xz pkubaj@freefall:/home/arrowd/public_distfiles % ls -l ~/public_html/ghc-8.6.5-boot-powerpc64-freebsd-elfv2.tar.xz -rw-r--r-- 1 pkubaj devel 113782560 Mar 13 15:17 /home/pkubaj/public_html/ghc-8.6.5-boot-powerpc64-freebsd-elfv2.tar.xz I guess that would suggest a problem in my patch, although I don't really g= et how it happened. I'm doing poudriere testport now with proper updated distinfo. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-ppc@freebsd.org Tue May 5 21:01:19 2020 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 35B0F2C5F2A for ; Tue, 5 May 2020 21:01:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49Gsb30jVnz4YBp for ; Tue, 5 May 2020 21:01:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by freefall.freebsd.org (Postfix) id EAE66CA40; Tue, 5 May 2020 21:01:18 +0000 (UTC) Delivered-To: powerpc@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [96.47.72.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id DF06AC9DB for ; Tue, 5 May 2020 21:01:18 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49Gsb24rYgz4YBj for ; Tue, 5 May 2020 21:01:18 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id A1A701C399 for ; Tue, 5 May 2020 21:01:18 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 045L1IAE010214 for ; Tue, 5 May 2020 21:01:18 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 045L1IZO010196 for powerpc@FreeBSD.org; Tue, 5 May 2020 21:01:18 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: powerpc@FreeBSD.org Subject: [Bug 246224] lang/ghc: bad distinfo for powerpc64 elfv2 bootstrap Date: Tue, 05 May 2020 21:01:18 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: pkubaj@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: haskell@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2020 21:01:19 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D246224 --- Comment #3 from Piotr Kubaj --- I guess the patch was ok, but I probably uploaded the wrong bootstrap. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-ppc@freebsd.org Tue May 5 21:38:51 2020 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 36AC42C6A9F for ; Tue, 5 May 2020 21:38:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49GtQM0krFz4Zjc for ; Tue, 5 May 2020 21:38:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by freefall.freebsd.org (Postfix) id E5D11CDFD; Tue, 5 May 2020 21:38:50 +0000 (UTC) Delivered-To: powerpc@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [96.47.72.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id DF7A7CF2C for ; Tue, 5 May 2020 21:38:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49GtQL4jyKz4ZjW for ; Tue, 5 May 2020 21:38:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 9D7A01C9AF for ; Tue, 5 May 2020 21:38:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 045LcoOd078715 for ; Tue, 5 May 2020 21:38:50 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 045Lco0B078714 for powerpc@FreeBSD.org; Tue, 5 May 2020 21:38:50 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: powerpc@FreeBSD.org Subject: [Bug 246224] lang/ghc: bad distinfo for powerpc64 elfv2 bootstrap Date: Tue, 05 May 2020 21:38:50 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: pkubaj@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: haskell@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2020 21:38:51 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D246224 --- Comment #4 from Piotr Kubaj --- I tried compiling lang/ghc with the currently posted bootstrap, it fails at: Linking utils/ghc-cabal/dist/build/tmp/ghc-cabal ... ld: error: /wrkdirs/usr/ports/lang/ghc/work/ghc-8.6.5-boot/lib/ghc-8.6.5/template-hask= ell-2.14.0.0/libHStemplate-haskell-2.14.0.0.a(Syntax.o): SHT_SYMTAB_SHNDX has 65534 entries, but the symbol table associated has 489= 56 cc: error: linker command failed with exit code 1 (use -v to see invocation) `cc' failed in phase `Linker'. (Exit code: 1) But that could be related to some 8.8.3 bug. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-ppc@freebsd.org Wed May 6 00:58:52 2020 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 CF8D92DB247 for ; Wed, 6 May 2020 00:58:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49Gys850xQz3HwM for ; Wed, 6 May 2020 00:58:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by freefall.freebsd.org (Postfix) id 8457BEE79; Wed, 6 May 2020 00:58:52 +0000 (UTC) Delivered-To: powerpc@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [96.47.72.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id 7E674EEDA for ; Wed, 6 May 2020 00:58:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49Gys81s36z3HwJ for ; Wed, 6 May 2020 00:58:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 3B2741EF8C for ; Wed, 6 May 2020 00:58:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 0460wq5E053886 for ; Wed, 6 May 2020 00:58:52 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 0460wq5B053885 for powerpc@FreeBSD.org; Wed, 6 May 2020 00:58:52 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: powerpc@FreeBSD.org Subject: [Bug 246224] lang/ghc: bad distinfo for powerpc64 elfv2 bootstrap Date: Wed, 06 May 2020 00:58:52 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: pkubaj@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: haskell@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 00:58:52 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D246224 --- Comment #5 from Piotr Kubaj --- I successfully built GHC 8.6.5 with the following patch: Index: distinfo =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- distinfo (revision 533932) +++ distinfo (working copy) @@ -25,8 +25,8 @@ SIZE (ghc-8.6.5-boot-armv6-freebsd.tar.xz) =3D 136889664 SHA256 (ghc-8.6.5-boot-armv7-freebsd.tar.xz) =3D ce4bc7fd20bb420963081171e483beb7387f9704323f7c03e36bbf3bf68a00ea SIZE (ghc-8.6.5-boot-armv7-freebsd.tar.xz) =3D 135237856 -SHA256 (ghc-8.6.5-boot-powerpc64-freebsd-elfv2.tar.xz) =3D 58eb128409a69b1b19f92b3c4090b6a023fd22f539b8b8013a7b6bf4b264d916 -SIZE (ghc-8.6.5-boot-powerpc64-freebsd-elfv2.tar.xz) =3D 112469852 +SHA256 (ghc-8.6.5-boot-powerpc64-freebsd-elfv2.tar.xz) =3D 89dfbfab84aef489ca9d0ff6fdf97152cff2412f6a8b9b1e57025b2019908318 +SIZE (ghc-8.6.5-boot-powerpc64-freebsd-elfv2.tar.xz) =3D 113782560 SHA256 (ghc-8.6.3-boot-powerpc64-freebsd-elfv1.tar.xz) =3D fb9bd4bad3a54722b7012c0a531cbdfe71b3b20a0b92cbd52195a526dc5ccde4 SIZE (ghc-8.6.3-boot-powerpc64-freebsd-elfv1.tar.xz) =3D 112652192 SHA256 (hscolour-1.24.4.tar.gz) =3D 243332b082294117f37b2c2c68079fa61af68b36223b3fc07594f245e0e5321d That means the bootstrap is ok, can you commit it? --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-ppc@freebsd.org Wed May 6 07:08:18 2020 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 38B402E7BFA for ; Wed, 6 May 2020 07:08:18 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49H73Q0pRCz4CLF for ; Wed, 6 May 2020 07:08:18 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by freefall.freebsd.org (Postfix) id EF95114A0F; Wed, 6 May 2020 07:08:17 +0000 (UTC) Delivered-To: powerpc@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id E88B714A8A for ; Wed, 6 May 2020 07:08:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49H73P52z8z4CL8 for ; Wed, 6 May 2020 07:08:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id A88F223706 for ; Wed, 6 May 2020 07:08:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 04678HeE029517 for ; Wed, 6 May 2020 07:08:17 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 04678HZf029516 for powerpc@FreeBSD.org; Wed, 6 May 2020 07:08:17 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: powerpc@FreeBSD.org Subject: [Bug 246224] lang/ghc: bad distinfo for powerpc64 elfv2 bootstrap Date: Wed, 06 May 2020 07:08:17 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: haskell@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 07:08:18 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D246224 --- Comment #6 from commit-hook@freebsd.org --- A commit references this bug: Author: arrowd Date: Wed May 6 07:08:03 UTC 2020 New revision: 534150 URL: https://svnweb.freebsd.org/changeset/ports/534150 Log: lang/ghc: Correct distinfo entry for ghc-8.6.5-boot-powerpc64-freebsd-elfv2.tar.xz file PR: 246224 Submitted by: pkubaj Changes: head/lang/ghc/distinfo --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-ppc@freebsd.org Wed May 6 07:10:00 2020 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 114682E7C79 for ; Wed, 6 May 2020 07:10:00 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49H75M6cPdz4CN8 for ; Wed, 6 May 2020 07:09:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by freefall.freebsd.org (Postfix) id D639214851; Wed, 6 May 2020 07:09:59 +0000 (UTC) Delivered-To: powerpc@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id D2F9B14A16 for ; Wed, 6 May 2020 07:09:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49H75M4NStz4CN4 for ; Wed, 6 May 2020 07:09:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 8DB642370C for ; Wed, 6 May 2020 07:09:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 04679xVe031446 for ; Wed, 6 May 2020 07:09:59 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 04679xOW031444 for powerpc@FreeBSD.org; Wed, 6 May 2020 07:09:59 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: powerpc@FreeBSD.org Subject: [Bug 246224] lang/ghc: bad distinfo for powerpc64 elfv2 bootstrap Date: Wed, 06 May 2020 07:09:59 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: arrowd@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: haskell@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: bug_status resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 07:10:00 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D246224 Gleb Popov changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Open |Closed Resolution|--- |FIXED --- Comment #7 from Gleb Popov --- Thanks. In future, you can commit such changes yourself (that is, simple and non-x86 related). --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-ppc@freebsd.org Wed May 6 09:06:32 2020 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 0DCF813C670 for ; Wed, 6 May 2020 09:06:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49H9gq6gcdz4MMp for ; Wed, 6 May 2020 09:06:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by freefall.freebsd.org (Postfix) id BEEFD16D10; Wed, 6 May 2020 09:06:31 +0000 (UTC) Delivered-To: powerpc@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id B9BA916CAF for ; Wed, 6 May 2020 09:06:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49H9gq3b59z4MMl for ; Wed, 6 May 2020 09:06:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 7678E24EF4 for ; Wed, 6 May 2020 09:06:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 04696V51094750 for ; Wed, 6 May 2020 09:06:31 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 04696Vuu094743 for powerpc@FreeBSD.org; Wed, 6 May 2020 09:06:31 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: powerpc@FreeBSD.org Subject: [Bug 243659] multimedia/wlrobs: fix build on powerpc64 Date: Wed, 06 May 2020 09:06:31 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: buildisok X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: jbeich@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? merge-quarterly? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 09:06:32 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D243659 --- Comment #5 from commit-hook@freebsd.org --- A commit references this bug: Author: jbeich Date: Wed May 6 09:05:57 UTC 2020 New revision: 534155 URL: https://svnweb.freebsd.org/changeset/ports/534155 Log: multimedia/wlrobs: unbreak on powerpc64 PR: 243659 Submitted by: pkubaj Changes: head/multimedia/wlrobs/Makefile --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-ppc@freebsd.org Wed May 6 09:07:33 2020 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 650C513C735 for ; Wed, 6 May 2020 09:07:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49H9j122WBz4MW2 for ; Wed, 6 May 2020 09:07:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by freefall.freebsd.org (Postfix) id 263F216DB4; Wed, 6 May 2020 09:07:33 +0000 (UTC) Delivered-To: powerpc@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id 212CD16E95 for ; Wed, 6 May 2020 09:07:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49H9j06SK0z4MW0 for ; Wed, 6 May 2020 09:07:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id D916C24F1E for ; Wed, 6 May 2020 09:07:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 04697W3f038109 for ; Wed, 6 May 2020 09:07:32 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 04697WoR038100 for powerpc@FreeBSD.org; Wed, 6 May 2020 09:07:32 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: powerpc@FreeBSD.org Subject: [Bug 243659] multimedia/wlrobs: fix build on powerpc64 Date: Wed, 06 May 2020 09:07:33 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: buildisok X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: jbeich@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? merge-quarterly? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 09:07:33 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D243659 --- Comment #6 from commit-hook@freebsd.org --- A commit references this bug: Author: jbeich Date: Wed May 6 09:06:49 UTC 2020 New revision: 534156 URL: https://svnweb.freebsd.org/changeset/ports/534156 Log: MFH: r534155 multimedia/wlrobs: unbreak on powerpc64 PR: 243659 Submitted by: pkubaj Approved by: ports-secteam blanket Changes: _U branches/2020Q2/ branches/2020Q2/multimedia/wlrobs/Makefile --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-ppc@freebsd.org Wed May 6 09:10:54 2020 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 ED17413C80F for ; Wed, 6 May 2020 09:10:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49H9mt63fyz4Mb8 for ; Wed, 6 May 2020 09:10:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by freefall.freebsd.org (Postfix) id AAA0B16C4F; Wed, 6 May 2020 09:10:54 +0000 (UTC) Delivered-To: powerpc@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [96.47.72.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id 8497A16DC5 for ; Wed, 6 May 2020 09:10:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49H9mt2Gz6z4Mb5 for ; Wed, 6 May 2020 09:10:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4934D24F45 for ; Wed, 6 May 2020 09:10:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 0469AsDb070721 for ; Wed, 6 May 2020 09:10:54 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 0469AsCo070717 for powerpc@FreeBSD.org; Wed, 6 May 2020 09:10:54 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: powerpc@FreeBSD.org Subject: [Bug 243659] multimedia/wlrobs: fix build on powerpc64 Date: Wed, 06 May 2020 09:10:54 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: buildisok X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jbeich@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: jbeich@FreeBSD.org X-Bugzilla-Flags: merge-quarterly+ X-Bugzilla-Changed-Fields: bug_status resolution flagtypes.name Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 09:10:55 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D243659 Jan Beich changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Closed Resolution|--- |FIXED Flags|maintainer-feedback?(jbeich |merge-quarterly+ |@FreeBSD.org), | |merge-quarterly? | --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-ppc@freebsd.org Wed May 6 17:02:23 2020 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 7C1782DA2C5 for ; Wed, 6 May 2020 17:02:23 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-qt1-x844.google.com (mail-qt1-x844.google.com [IPv6:2607:f8b0:4864:20::844]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49HNDt5wVcz3QK8; Wed, 6 May 2020 17:02:22 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by mail-qt1-x844.google.com with SMTP id i68so2012000qtb.5; Wed, 06 May 2020 10:02:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=jQ5FWFcLzr5DqqP/gTSPBVyZUBwMEb1qNBBaEV/PybU=; b=KqpalwEjF08sy7pmNs9XkDB8TRuXQkVvVSW9/XjzaXMwxF/1DlulNRtpumKDfprxih q3ay2XTLVzFoIveKPg7U1rCiPkEttoHycTnU6erUnOXW15QUu+0O1Q2hd5CNDReiPXlk 7g+iVOg9lQ0HPNtCQE5zlTeLwjVK8i3zfot8Il4T0atsearp8e7e5o8lD1DEOEvwo0N2 KzwCWSoDT5nbZUqVIr83oM1uLlrx3+yypLoYbSISoFpPKaHkO/VFV1J7O8bT53BdOY7t LjGy6xkdnCRVEGyeaeweYty7uyHLJE6+ZUsrXgD1yotzlpqZJthh9ilejk1SjpJNkFYi 3YjA== 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=jQ5FWFcLzr5DqqP/gTSPBVyZUBwMEb1qNBBaEV/PybU=; b=D6UzitB6bKZYZ3HLSl75UbuE0b5KZxMikUaWy0wNKVx7dRqHuHeNtCH1rJLsY67nlj f9qiJhHvHzLGjE+Ai8obHnRkVdYH2OJzOedtjw3THkDqkCkrobab9YpD7SGCM7LQqjfb h97sn1U8MNdLaRIu4zLpvQM8IwfGAAdJ8tC3xaERswMcKT1nTtU/drLGJBQ6/hyLE/Zz r/c54Cgy5vm/jRJmAIBGEsEuiL/DVsbXkRTvRL1n6lykeFxzmgTpK5utOaBOPMd4btAR tEhmZ4bRf3yXNwe3uymitXUrqcuAB144D0ARvMD7OFIst4Dl+DiqxhgxS8oVpR7Y9TIz exQg== X-Gm-Message-State: AGi0PuZHqVJ7TLpy0esUCRdqsiezpCcnAKSlHxxWKc8BJI6DhhBtsUM5 fJWbtfrcCQGap29XaOm7y4cDzsqKUV0= X-Google-Smtp-Source: APiQypIySVC4zPnI1QWW9Zp9oc4y64GFoW0t8U2B4sK5dK9wTOsYRS4Neapz32Zym9ky6SJ9hFba5A== X-Received: by 2002:aed:2ac4:: with SMTP id t62mr9777681qtd.381.1588784541612; Wed, 06 May 2020 10:02:21 -0700 (PDT) Received: from titan.knownspace (173-19-125-130.client.mchsi.com. [173.19.125.130]) by smtp.gmail.com with ESMTPSA id j83sm2135462qke.7.2020.05.06.10.02.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 May 2020 10:02:21 -0700 (PDT) Date: Wed, 6 May 2020 12:02:15 -0500 From: Justin Hibbits To: "Brandon Bergren" Cc: "FreeBSD PowerPC ML" Subject: Re: svn commit: r360233 - in head: contrib/jemalloc . . . : This partially breaks a 2-socket 32-bit powerpc (old PowerMac G4) based on head -r360311 Message-ID: <20200506120215.2615b439@titan.knownspace> In-Reply-To: References: <1588493689.54538000.et1xl2l8@frv55.fwdcdn.com> <922FBA7C-039D-4852-AC8F-E85A221C2559@yahoo.com> X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; powerpc64-portbld-freebsd13.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 49HNDt5wVcz3QK8 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=KqpalwEj; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of chmeeedalf@gmail.com designates 2607:f8b0:4864:20::844 as permitted sender) smtp.mailfrom=chmeeedalf@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; RECEIVED_SPAMHAUS_PBL(0.00)[130.125.19.173.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE_FREEMAIL(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[3]; IP_SCORE(0.00)[ip: (0.02), ipnet: 2607:f8b0::/32(-0.33), asn: 15169(-0.43), country: US(-0.05)]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[4.4.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; 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]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 17:02:23 -0000 On Sun, 03 May 2020 09:56:02 -0500 "Brandon Bergren" wrote: > On Sun, May 3, 2020, at 9:38 AM, Mark Millard via freebsd-ppc wrote: > > > > Observing and reporting the reverting result is an initial > > part of problem isolation. I made no request for FreeBSD > > to give up on using the updated jemalloc. (Unfortunately, > > I'm not sure what a good next step of problem isolation > > might be for the dual-socket PowerMac G4 context.) > > I appreciate this testing btw. The only dual-socket G4 I have (my > xserve g4) does not have the second socket populated, so I am > currently unable to test two-socket ppc32. > > > Other than reverting, no patch is known for the issue at > > this point. More problem isolation is needed first. > > > > While I do not have access, https://wiki.freebsd.org/powerpc > > lists more modern 32-bit powerpc hardware as supported: > > MPC85XX evaluation boards and AmigaOne A1222 (powerpcspe). > > (The AmigaOne A1222 seems to be dual-ore/single-socket.) > > jhibbits has an A1222 that is used as an actual primary desktop, and > I will hopefully have one at the end of the year. And I have an RB800 > that I use for testing. > > powerpcspe is really a different beast than aim32 though. I have been > mainly working on aim32 on g4 laptops, although I do have an xserve. > > > > > So folks with access to one of those may want to see > > if they also see the problem(s) with head -r360233 or > > later. > > Frankly, I wouldn't be surprised if this continues to be down to the > timebase skew somehow. I know that jemalloc tends to be sensitive to > time problems. > > > > > Another interesting context to test could be single-socket > > with just one core. (I might be able to do that on another > > old PowerMac, booting the same media after moving the > > media.) > > That's my primary aim32 testing platform. I have a stack of g4 > laptops that I test on, and a magically working usb stick (ADATA C008 > / 8GB model. For some reason it just works, I've never seen another > stick actually work) > > > > > If I understand right, the most common 32-bit powerpc > > tier 2 hardware platforms may still be old PowerMac's. > > They are considered supported and "mature", instead of > > just "stable". See https://wiki.freebsd.org/powerpc . > > However, the reality is that there are various problems > > for old PowerMacs (32-bit and 64-bit, at least when > > there is more than one socket present). The wiki page > > does not hint at such. (I'm not sure about > > single socket/multi-core PowerMacs: no access to > > such.) > > Yes, neither I nor jhibbits have multiple socket g4 hardware at the > moment, and I additionally don't have multiple socket g5 either. > > > > > It is certainly possible for some problem to happen > > that would lead to dropping the supported-status > > for some or all old 32-bit PowerMacs, even as tier 2. > > But that has not happened yet and I'd have no say in > > such a choice. > > From a kernel standpoint, I for one have no intention of dropping 32 > bit support in the forseeable future. I've actually been putting more > work into 32 bit than 64 bit recently in fact. > I currently have FreeBSD HEAD from late last week running on a dual G4 MDD (WITNESS kernel), and no segmentation faults from dhclient. I'm using the following patch against jemalloc. Brandon has reported other results with that patch to me, so I'm not sure it's a correct patch. - Justin diff --git a/contrib/jemalloc/include/jemalloc/internal/cache_bin.h b/contrib/jemalloc/include/jemalloc/internal/cache_bin.h index d14556a3da8..728959a448e 100644 --- a/contrib/jemalloc/include/jemalloc/internal/cache_bin.h +++ b/contrib/jemalloc/include/jemalloc/internal/cache_bin.h @@ -88,7 +88,7 @@ JEMALLOC_ALWAYS_INLINE void * cache_bin_alloc_easy(cache_bin_t *bin, bool *success) { void *ret; - bin->ncached--; + cache_bin_sz_t cached = --bin->ncached; /* * Check for both bin->ncached == 0 and ncached < low_water @@ -111,7 +111,7 @@ cache_bin_alloc_easy(cache_bin_t *bin, bool *success) { * cacheline). */ *success = true; - ret = *(bin->avail - (bin->ncached + 1)); + ret = *(bin->avail - (cached + 1)); return ret; } From owner-freebsd-ppc@freebsd.org Wed May 6 22:46:14 2020 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 EF69A2E1B0F for ; Wed, 6 May 2020 22:46:14 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-20.consmr.mail.gq1.yahoo.com (sonic313-20.consmr.mail.gq1.yahoo.com [98.137.65.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49HWsd54K7z4JqH for ; Wed, 6 May 2020 22:46:13 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 1DTOFBUVM1l3vkgFLHk9Orgw1l6iSVl6V736.O6AYzeKYG9409JF.XE3pj4Nhb8 wxM2socAmMDgRgT1STjmAnWIMvhrHXpd7Xe1QGptkfr_A5aE_DHdoCe_U6pgHJDgueZOAHSoF16c 9s8FWCUrg.RCSh9pwOWVMXuUX43e_ghISRk2Wg6.6xhQ2T.LWSE2jSb.nCEJwcICvLb0LoH0rPvQ vndyx74T7k8habzGqMXaaorUrJyMnNh6P8bSYpJt7DLQuvVbRNJDkp2T6Usxb6JNO4juPYnH8VwQ YiXFCLB7tcfiHKLbL8wvzOaTxBjRiQGBGZgYQ_nOjtZQoEoBw_fpTJLehecnIbJ3NC80ou2quMCt tAgDse.nEyOt3lO1M0ScM3KEAWrAl8ojZhru7IL22j.myAtpIYWnpBA5WxK4RWWDvKEi.D66tvOn T.gFL.GPd8a1bo.veitEh9BtnCiAN8tfkbb5IKvjFGveVxmokR6SD7m6vn7lDcrtNkusudrUcXBk dkcTMFBnB0s7RPfDariunBkdsPPvInSzLyVKi9Wo2JQ8Bsx1Ws1qTa5Z4at6mmAlEPvVPptjnopD MEgqBxRpdRlOdNmdcj5nSQjUqjAYNCxhyP8xDIlAXPFQl9T0xe7uFDpkxhiInzFPLOQQpkot9lRo LxGXGg3mjbW4JbCYr528PcSfl_2jp20T2QBQfzCrJrjShysycv.wMLZBuMaSwXzG5MmvCUfYx1f8 MB5H12nWAo1L1DMzJHq1_EnkALd_yYa.tKrtyp7MgXil2RLnahwUAxt5Ye8MIwC245lKh.E_7TNX D6ICqQCEt56rxzvHl6xrsD18fF195Xi0CXBOfBXXiDMWCwA8JXU4WwPaEUL19Ahw39xZwDhVC0LZ 8jo16mJcXhFw32jwzAfOQZBvSkUSTywRL_8S8CWGfOY2445i_DohrPqYQUmcEN3VPIc3Db4mkNWX Jd.yIbz0um9JFfA8LbNfwrT8iIR23jUqXUUdFu2T6f6qons4yoR8nm6HxD084oj4tkqorvnhB3AA VEnntdhlly5WWwbdc3W7YT.9W9VS_MEuwKUEnejIjkh2YBRvts1_szYGtgq0tul1T7uzPzvcm96e 33ugj8lZKMDpdmj0aYtXIRY3wVoyBUktsIl7e.9yhTDoS_xQuGd7_57dYSGiYTnGto1HWGj52mpR XsvimPGcFSWPZp3sF0azYOK8AndD8tDw8C.VfowCiIhjsVDqW13syPLGZJD7C_FarbVpB7.ngp4_ dPDd_Jj38oAhhFvfV1FOfNiGUzjf91gyRG436GZHov9pmm12C2C3QJeKB262E8ePSVWdQPjWSbJC .N4hja_jYvYFduomkEO1F2R0NRbctHhjBvm8sN3_3ZSnMw3MdC0FYs3lBaRB9kVMblC2HkwOetVn P4g4R5hOCJig7i7Ifpg-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Wed, 6 May 2020 22:46:12 +0000 Received: by smtp401.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID e84a67d5a75c05956583e617f413d1f5; Wed, 06 May 2020 22:46:06 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: svn commit: r360233 - in head: contrib/jemalloc . . . : This partially breaks a 2-socket 32-bit powerpc (old PowerMac G4) based on head -r360311 From: Mark Millard In-Reply-To: <20200506120215.2615b439@titan.knownspace> Date: Wed, 6 May 2020 15:46:04 -0700 Cc: Brandon Bergren , FreeBSD PowerPC ML Content-Transfer-Encoding: 7bit Message-Id: <012EC6DD-AF2F-40EE-A9E2-A74ACE28E7A3@yahoo.com> References: <1588493689.54538000.et1xl2l8@frv55.fwdcdn.com> <922FBA7C-039D-4852-AC8F-E85A221C2559@yahoo.com> <20200506120215.2615b439@titan.knownspace> To: Justin Hibbits X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49HWsd54K7z4JqH X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.45 / 15.00]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.95)[-0.953,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-0.99)[-0.993,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ip: (1.47), ipnet: 98.137.64.0/21(0.83), asn: 36647(0.66), country: US(-0.05)]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[83.65.137.98.list.dnswl.org : 127.0.5.0]; RWL_MAILSPIKE_POSSIBLE(0.00)[83.65.137.98.rep.mailspike.net : 127.0.0.17]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 22:46:15 -0000 On 2020-May-6, at 10:02, Justin Hibbits wrote: > On Sun, 03 May 2020 09:56:02 -0500 > "Brandon Bergren" wrote: > >> On Sun, May 3, 2020, at 9:38 AM, Mark Millard via freebsd-ppc wrote: >>> >>> Observing and reporting the reverting result is an initial >>> part of problem isolation. I made no request for FreeBSD >>> to give up on using the updated jemalloc. (Unfortunately, >>> I'm not sure what a good next step of problem isolation >>> might be for the dual-socket PowerMac G4 context.) >> >> I appreciate this testing btw. The only dual-socket G4 I have (my >> xserve g4) does not have the second socket populated, so I am >> currently unable to test two-socket ppc32. >> >>> Other than reverting, no patch is known for the issue at >>> this point. More problem isolation is needed first. >>> >>> While I do not have access, https://wiki.freebsd.org/powerpc >>> lists more modern 32-bit powerpc hardware as supported: >>> MPC85XX evaluation boards and AmigaOne A1222 (powerpcspe). >>> (The AmigaOne A1222 seems to be dual-ore/single-socket.) >> >> jhibbits has an A1222 that is used as an actual primary desktop, and >> I will hopefully have one at the end of the year. And I have an RB800 >> that I use for testing. >> >> powerpcspe is really a different beast than aim32 though. I have been >> mainly working on aim32 on g4 laptops, although I do have an xserve. >> >>> >>> So folks with access to one of those may want to see >>> if they also see the problem(s) with head -r360233 or >>> later. >> >> Frankly, I wouldn't be surprised if this continues to be down to the >> timebase skew somehow. I know that jemalloc tends to be sensitive to >> time problems. >> >>> >>> Another interesting context to test could be single-socket >>> with just one core. (I might be able to do that on another >>> old PowerMac, booting the same media after moving the >>> media.) >> >> That's my primary aim32 testing platform. I have a stack of g4 >> laptops that I test on, and a magically working usb stick (ADATA C008 >> / 8GB model. For some reason it just works, I've never seen another >> stick actually work) >> >>> >>> If I understand right, the most common 32-bit powerpc >>> tier 2 hardware platforms may still be old PowerMac's. >>> They are considered supported and "mature", instead of >>> just "stable". See https://wiki.freebsd.org/powerpc . >>> However, the reality is that there are various problems >>> for old PowerMacs (32-bit and 64-bit, at least when >>> there is more than one socket present). The wiki page >>> does not hint at such. (I'm not sure about >>> single socket/multi-core PowerMacs: no access to >>> such.) >> >> Yes, neither I nor jhibbits have multiple socket g4 hardware at the >> moment, and I additionally don't have multiple socket g5 either. >> >>> >>> It is certainly possible for some problem to happen >>> that would lead to dropping the supported-status >>> for some or all old 32-bit PowerMacs, even as tier 2. >>> But that has not happened yet and I'd have no say in >>> such a choice. >> >> From a kernel standpoint, I for one have no intention of dropping 32 >> bit support in the forseeable future. I've actually been putting more >> work into 32 bit than 64 bit recently in fact. >> > > I currently have FreeBSD HEAD from late last week running on a dual G4 > MDD (WITNESS kernel), and no segmentation faults from dhclient. I'm > using the following patch against jemalloc. Brandon has reported other > results with that patch to me, so I'm not sure it's a correct patch. > > - Justin Thanks. The status of trying to track this down . . . I normally use MALLOC_PRODUCTION= in my normally non-debug builds. So: no jemalloc assert's. So I tried a "debug" build without MALLOC_PRODUCTION= --and so far I've not had any failures after booting with that world-build. Nor have any assert's failed. It has been longer than usual but it would probably be a few days before I concluded much. (At some point I'll reboot just to change the conditions some and then give it more time as well.) I had hoped this type of build would detect there being a problem earlier after things start going bad internally. I've still no means of directly causing the problem. I've still only seen the odd SIGSEGV's in dhclient, rpcbind, mountd, nfsd, and sendmail. I've really only learned: A) Either messed up memory contents is involved or addresses in registers were pointing to the wrong place. (I know not which for sure.) B) It seems to be probabilistic for when it starts in each of the 5 types of context. (Possibly some data race involved?) C) The programs do not all fail together but over time more than one type can get failures. D) Once sendmail's quickly executing subprocess starts having the problem during its exit, later instances seem to have it as well. (Inheriting bad memory content via a fork-ish operation that creates the subprocess?) E) I do have the example failure of one of the contexts with the prior jemalloc code. (It was a MALLOC_PRODUCTION= style build.) (I reverted to the modern jemalloc that seemed to expose the problem more.) So far I've made no progress for isolating the context for where the problem starts. I've no clue how much is messed up or for how long it has been messed up by the time a notice is reported. I still do not blame jemalloc: as far as I know it could be just contributing to exposing problem(s) from other code instead of having problems of its own. Some of the SIGEGV's are not in jemalloc code at the time of the SIGSEGV. > diff --git a/contrib/jemalloc/include/jemalloc/internal/cache_bin.h > b/contrib/jemalloc/include/jemalloc/internal/cache_bin.h index > d14556a3da8..728959a448e 100644 --- > a/contrib/jemalloc/include/jemalloc/internal/cache_bin.h +++ > b/contrib/jemalloc/include/jemalloc/internal/cache_bin.h @@ -88,7 +88,7 > @@ JEMALLOC_ALWAYS_INLINE void * cache_bin_alloc_easy(cache_bin_t *bin, > bool *success) { void *ret; > > - bin->ncached--; > + cache_bin_sz_t cached = --bin->ncached; > > /* > * Check for both bin->ncached == 0 and ncached < low_water > @@ -111,7 +111,7 @@ cache_bin_alloc_easy(cache_bin_t *bin, bool > *success) { > * cacheline). > */ > *success = true; > - ret = *(bin->avail - (bin->ncached + 1)); > + ret = *(bin->avail - (cached + 1)); > > return ret; > } As stands, it is messy trying to conclude if something helps vs. hurts vs. makes-little-difference. So I'm not sure how or when I'll try the above. So far I've focused on reproducing the problem, possibly in a away that gives better (earlier) information. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-ppc@freebsd.org Wed May 6 23:58:06 2020 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 02CE32E3C22 for ; Wed, 6 May 2020 23:58:06 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-21.consmr.mail.gq1.yahoo.com (sonic306-21.consmr.mail.gq1.yahoo.com [98.137.68.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 49HYSX44BWz4PGx for ; Wed, 6 May 2020 23:58:04 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: .tMrsL8VM1lHXQP1QD1XvZPA.c2.3hOgHOxwWwSCQi09XDVpsXAd5ewGprIy6L1 bNqzZCaCCdY2_oNp9HMnBiRgfiyaGnEKtxgGWZdWmz1RJk4QhDnh23eirM4m3r.Cp94YkOaV0Uj8 O9awIIh7GssVjPFBgOzK3AQ6OyV5Wg009wwsVB8HZ.P7GFFvF4n1LnY7bJKCHIONZhrfVI7iGHZu F.iq.YkK.5wFY7EpOFv81jf30uZoxZqIsAV5jX.cE0iZvNDn8yh3zdcvPYlgOPz.IwEbFJq47R_7 PUY0Pk6QnDPKq9dROHiEr6hcaBs1cYNFzdE2tYQCGa29cOL_HtpRVCntJltJ9jrsQM7MP1I4a55c T0JLEdVJS9qVFJCyE35Kh9e0.9lqI7eaJyZ2f2L9OhRH.ec7k6aIgeuGbwiCl7guWS8wnRpRj1Bg RhurB93CwUj0tnHEpWh2GUP584a_4ds_HCr1fcWc.VHZFRXN2PtSB8s92qMIzthS9Yk4TSKrb_1s e8OQEyHk2zOlSJ_psMp0Gutl6_U2Z.jtnC.izImKdMyBTvCfEdX4xiIJ7U083wCIpxTEqRQ_jXN6 TiLh0Mxers3xJtQkAkAb32eII10xTvJEg_vcNQn5K6hfi_5Lp6URAFx1t6_SU62sXZZ4_uLjyjF2 xZd8KuAxpPmhFtFEBQ0rfy13B4P4e9NHfLz1SRsJpYpf.YPMU8kvglnsVD7UdUjfthU.fL88pXGD LXXFOoWUOAl06Vyr8cMGqWoH9aTSpr7BmGtvWTU7w4Z_U_Ai0CAObR51iPwT4slwjmbRHst.vwac yKC3IZoKuLFui2oYI1fdiBjAk9z.rtaBaLVjT7OR38SE7HJOCxCG_CMcB8Td.AARjZxj7l1S79Ot ciTVOg6xySj5cNq3fQvUXRggsU5AG8U5OmKz6KfS3qUQIzMuzwonRwUSB_dHtsKAyMWcSt5f1nBp 7sZ0T19os.GFqLkSmQbbDXKeKFLO13UtWQHEreoPW_ZDnDL9UnJ0Mba9uTu26E4wVGDqtagV52tQ s8VsNV0VLej2ISum1AMkBZSMdCYz_vBw6IltGJk0puzOyiblXVhn5I8WyWllgE1RileXEhUjbMuK dvP45LHE1ChrPbSXWyRpIBNkqmpKUZco83BwXUaTJmtksHC4DchQ7h4JFZqeWK9WoF5a7MiVYW0s LlJ_Ov54Q9nLSzZFgXTP5iAD4W4KtYIyolYDjkSBhqxotIY2i03RxPNDqJBHnI86Jepp9lyk0a5k b3xxYVEJ0fPg.o0ILqXANdpq2hMVUKAojQZxthATbCyUNEw_0jQY3S6DNBtrTR08nbynZ.gDhXc. XXZdgQwtOlr4EeOT1TxyJROSIIRELaKQSIuL4p4SMSpazgeSKBXhOkprKZi.UJJQD9BprLa7bqOP zxGyZxjAONZf6EQH51EvguF0u2wPsDIJeeRuyCFsz1.EPpmUO6BFN9p2Xw5OLIemj4iwU Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Wed, 6 May 2020 23:58:03 +0000 Received: by smtp408.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 275644a7f42f203160b12da5531da6aa; Wed, 06 May 2020 23:57:58 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: svn commit: r360233 - in head: contrib/jemalloc . . . : This partially breaks a 2-socket 32-bit powerpc (old PowerMac G4) based on head -r360311 From: Mark Millard In-Reply-To: <121B9B09-141B-4DC3-918B-1E7CFB99E779@yahoo.com> Date: Wed, 6 May 2020 16:57:55 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8AAB0462-3FA8-490C-8D8D-7C15B1C9E2DE@yahoo.com> References: <8479DD58-44F6-446A-9CA5-D01F0F7C1B38@yahoo.com> <17ACDA02-D7EF-4F26-874A-BB3E935CD072@yahoo.com> <695E6836-F860-4557-B7DE-CC1EDB347F18@yahoo.com> <121B9B09-141B-4DC3-918B-1E7CFB99E779@yahoo.com> To: "vangyzen@freebsd.org" , svn-src-head@freebsd.org, FreeBSD Current , FreeBSD Hackers , FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49HYSX44BWz4PGx X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.05 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; RCPT_COUNT_FIVE(0.00)[6]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.65)[-0.648,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.90)[-0.905,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ip: (5.24), ipnet: 98.137.64.0/21(0.83), asn: 36647(0.66), country: US(-0.05)]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[84.68.137.98.list.dnswl.org : 127.0.5.0]; RWL_MAILSPIKE_POSSIBLE(0.00)[84.68.137.98.rep.mailspike.net : 127.0.0.17]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 23:58:06 -0000 [This explores process crashes that happen during system shutdown, in a context not having MALLOC_PRODUCTION=3D . So assert failures are reported as the stopping points.] It looks like shutdown -p now, shutdown -r now, and the like can lead some processes to assert during their exit attempt, including a sshd failure (that I've not seen before), rpcbind, and nfsd. I show information about the observed asserts for those below. sshd hit an assert, failing slab =3D=3D extent_slab_get(extent) : (gdb) bt=20 #0 thr_kill () at thr_kill.S:4 #1 0x50927170 in __raise (s=3D6) at /usr/src/lib/libc/gen/raise.c:52 #2 0x50886cc0 in abort () at /usr/src/lib/libc/stdlib/abort.c:67 #3 0x508834b0 in arena_dalloc (tsdn=3D, ptr=3D, tcache=3D, alloc_ctx=3D, = slow_path=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/arena_inlines_b.h:315 #4 idalloctm (tsdn=3D0x500dd040, ptr=3D0x5008a180, tcache=3D0x500dd160, = alloc_ctx=3D, is_internal=3D, = slow_path=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/jemalloc_internal_inli= nes_c.h:118 #5 0x5087b0a4 in ifree (tsd=3D0x500dd040, ptr=3D0x5008a180, = tcache=3D0x500dd160, slow_path=3D) at = jemalloc_jemalloc.c:2590 #6 0x5087acac in __je_free_default (ptr=3D0x5008a180) at = jemalloc_jemalloc.c:2784 #7 0x5087b294 in __free (ptr=3D0x5008a180) at jemalloc_jemalloc.c:2852 #8 0x10029464 in server_accept_loop (config_s=3D, = sock_in=3D, sock_out=3D, = newsock=3D) at /usr/src/crypto/openssh/sshd.c:1185 #9 main (ac=3D, av=3D0xffffde3c) at = /usr/src/crypto/openssh/sshd.c:2009 . . . (gdb) up #2 0x50886cc0 in abort () at /usr/src/lib/libc/stdlib/abort.c:67 67 (void)raise(SIGABRT); (gdb) up #3 0x508834b0 in arena_dalloc (tsdn=3D, ptr=3D, tcache=3D, alloc_ctx=3D, = slow_path=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/arena_inlines_b.h:315 315 assert(slab =3D=3D extent_slab_get(extent)); (gdb) list 310 rtree_ctx =3D tsd_rtree_ctx(tsdn_tsd(tsdn)); 311 extent_t *extent =3D rtree_extent_read(tsdn, = &extents_rtree, 312 rtree_ctx, (uintptr_t)ptr, true); 313 assert(szind =3D=3D extent_szind_get(extent)); 314 assert(szind < SC_NSIZES); 315 assert(slab =3D=3D extent_slab_get(extent)); 316 } 317=09 318 if (likely(slab)) { 319 /* Small allocation. */ More fully: 285 JEMALLOC_ALWAYS_INLINE void 286 arena_dalloc(tsdn_t *tsdn, void *ptr, tcache_t *tcache, 287 alloc_ctx_t *alloc_ctx, bool slow_path) { 288 assert(!tsdn_null(tsdn) || tcache =3D=3D NULL); 289 assert(ptr !=3D NULL); 290=09 291 if (unlikely(tcache =3D=3D NULL)) { 292 arena_dalloc_no_tcache(tsdn, ptr); 293 return; 294 } 295=09 296 szind_t szind; 297 bool slab; 298 rtree_ctx_t *rtree_ctx; 299 if (alloc_ctx !=3D NULL) { 300 szind =3D alloc_ctx->szind; 301 slab =3D alloc_ctx->slab; 302 assert(szind !=3D SC_NSIZES); 303 } else { 304 rtree_ctx =3D tsd_rtree_ctx(tsdn_tsd(tsdn)); 305 rtree_szind_slab_read(tsdn, &extents_rtree, = rtree_ctx, 306 (uintptr_t)ptr, true, &szind, &slab); 307 } 308=09 309 if (config_debug) { 310 rtree_ctx =3D tsd_rtree_ctx(tsdn_tsd(tsdn)); 311 extent_t *extent =3D rtree_extent_read(tsdn, = &extents_rtree, 312 rtree_ctx, (uintptr_t)ptr, true); 313 assert(szind =3D=3D extent_szind_get(extent)); 314 assert(szind < SC_NSIZES); 315 assert(slab =3D=3D extent_slab_get(extent)); 316 } 317=09 318 if (likely(slab)) { 319 /* Small allocation. */ 320 tcache_dalloc_small(tsdn_tsd(tsdn), tcache, ptr, = szind, 321 slow_path); 322 } else { 323 arena_dalloc_large(tsdn, ptr, tcache, szind, = slow_path); 324 } 325 } rpcbind hit an assert, failing ret =3D=3D sz_size2index_compute(size) : (gdb) bt #0 thr_kill () at thr_kill.S:4 #1 0x502f2170 in __raise (s=3D6) at /usr/src/lib/libc/gen/raise.c:52 #2 0x50251d04 in abort () at /usr/src/lib/libc/stdlib/abort.c:79 #3 0x5024f260 in sz_size2index_lookup (size=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/sz.h:159 #4 sz_size2index (size=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/sz.h:166 #5 imalloc_body (sopts=3D0xffffb360, dopts=3D0xffffb340, = tsd=3D0x5009a018) at jemalloc_jemalloc.c:2066 #6 0x50244874 in imalloc (sopts=3D0xffffb360, dopts=3D0xffffb340) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/tsd.h:331 #7 0x50244fe8 in __calloc (num=3D1, size=3D96) at = jemalloc_jemalloc.c:2498 #8 0x50265690 in svc_xprt_alloc () at /usr/src/lib/libc/rpc/svc.c:541 #9 0x502635f4 in makefd_xprt (fd=3D14, sendsize=3D9000, recvsize=3D9000) = at /usr/src/lib/libc/rpc/svc_vc.c:250 #10 0x502644b4 in rendezvous_request (xprt=3D0x5004c000, msg=3D) at /usr/src/lib/libc/rpc/svc_vc.c:315 #11 0x50265a98 in svc_getreq_common (fd=3D) at = /usr/src/lib/libc/rpc/svc.c:640 #12 0x50265d1c in svc_getreq_poll (pfdp=3D, pollretval=3D1)= at /usr/src/lib/libc/rpc/svc.c:739 #13 0x10018568 in my_svc_run () at = /usr/src/usr.sbin/rpcbind/rpcb_svc_com.c:1167 #14 0x10014ad8 in main (argc=3D, argv=3D) = at /usr/src/usr.sbin/rpcbind/rpcbind.c:250 (gdb) up 3 #3 0x5024f260 in sz_size2index_lookup (size=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/sz.h:159 159 assert(ret =3D=3D sz_size2index_compute(size)); (gdb) print ret $1 =3D 0 154 JEMALLOC_ALWAYS_INLINE szind_t 155 sz_size2index_lookup(size_t size) { 156 assert(size <=3D SC_LOOKUP_MAXCLASS); 157 szind_t ret =3D (sz_size2index_tab[(size + (ZU(1) << = SC_LG_TINY_MIN) - 1) 158 >> SC_LG_TINY_MIN]); 159 assert(ret =3D=3D sz_size2index_compute(size)); 160 return ret; 161 } nfsd hit an assert, failing ret =3D=3D sz_size2index_compute(size) (also, but a different caller of sz_size2index): (gdb) bt #0 thr_kill () at thr_kill.S:4 #1 0x502b2170 in __raise (s=3D6) at /usr/src/lib/libc/gen/raise.c:52 #2 0x50211cc0 in abort () at /usr/src/lib/libc/stdlib/abort.c:67 #3 0x50206104 in sz_index2size_lookup (index=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/sz.h:200 #4 sz_index2size (index=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/sz.h:207 #5 ifree (tsd=3D0x50094018, ptr=3D0x50041028, tcache=3D0x50094138, = slow_path=3D) at jemalloc_jemalloc.c:2583 #6 0x50205cac in __je_free_default (ptr=3D0x50041028) at = jemalloc_jemalloc.c:2784 #7 0x50206294 in __free (ptr=3D0x50041028) at jemalloc_jemalloc.c:2852 #8 0x50287ec8 in ns_src_free (src=3D0x50329004, srclistsize=3D) at /usr/src/lib/libc/net/nsdispatch.c:452 #9 ns_dbt_free (dbt=3D0x50329000) at = /usr/src/lib/libc/net/nsdispatch.c:436 #10 vector_free (vec=3D0x50329000, count=3D, esize=3D12, = free_elem=3D) at /usr/src/lib/libc/net/nsdispatch.c:253 #11 nss_atexit () at /usr/src/lib/libc/net/nsdispatch.c:578 #12 0x5028d958 in __cxa_finalize (dso=3D0x0) at = /usr/src/lib/libc/stdlib/atexit.c:240 #13 0x502117f8 in exit (status=3D0) at = /usr/src/lib/libc/stdlib/exit.c:74 #14 0x10013f9c in child_cleanup (signo=3D) at = /usr/src/usr.sbin/nfsd/nfsd.c:969 #15 #16 0x00000000 in ?? () (gdb) up 3 #3 0x50206104 in sz_index2size_lookup (index=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/sz.h:200 200 assert(ret =3D=3D sz_index2size_compute(index)); (ret is optimized out.) 197 JEMALLOC_ALWAYS_INLINE size_t 198 sz_index2size_lookup(szind_t index) { 199 size_t ret =3D (size_t)sz_index2size_tab[index]; 200 assert(ret =3D=3D sz_index2size_compute(index)); 201 return ret; 202 } Booting and immediately trying something like: service nfsd stop did not lead to a failure. But may be after a while it would and be less drastic than a reboot or power down. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-ppc@freebsd.org Thu May 7 07:46:40 2020 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 BCE6813ACA2 for ; Thu, 7 May 2020 07:46:40 +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 49HlsC2BYYz3FJT for ; Thu, 7 May 2020 07:46:39 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: OPNsNFcVM1lg_qAnMTDQTK3p6D7_v8d4a1hkBTBFATb9D8EdW0fAtSiyXqJ_CmM cC.GFKzJu6vWWOjImpl4nGd10z5jcwXRE4L_Zr3b.DPcoxvN6IhM_G._7lnBVJjz9648dLc9jexF 88y8_cXMAv5Hzl3H3sk14v8aqNLLWqPcjXLWmL_sWASxHG4ypnCqrDY8f9ErNDPy8rMrXjYFm.oV zXp1g3oynvSj3CPH5lvDZSbW_FHh_u5SSBuZAwBwEJPOZKXJ5n6d7fWQnWds0zoPMhLx37njt4RB 2tylxDS5OVSvqRO.LFRvLdQFynLF7QyAfwfpcidUu0Eu9WQkqdsrcFB7VjEeB_.xFFVkjwe.USmE flW3X0xWiZtx9qIUdwx7br59WvcMQzmeg_cWGFm_Y68hz6scsIONmz5l5LuvvYoCi65qNuB3PkQ4 ZxJP0quX2TFsJ7EYkvOSBrVISRtgGRj4yyV_7CIVm7doZz14jL1K04qtx22O26ym4aHszXrgNXVI C9Khdn6yqiWdJFIIjV6Ftz5PpuM_D8KaMqQSHKtDeD1Fd6fbQJXb.YMLHyjFvHEYVvNKMXfhamFM rEUizUep4d4jwJemX6RVG1C1SCbdO3VQlkq3Ege.fTMTHhrbmlEBCWXLJQQ6vQ1_AkheZFBKl5Ja QTVSXsuCnRIgrf4Sfj.pb5UDAjIlHLx2hpVQo.H.xFz3CpHrQU.46Oog8HYvLCZW.qlacrf3V.3P 9fWbk5tD5wYtkkIhtTcMt05EZGZOUyafwcOZnqsT7KsYbvk_lTTJsA5.AOpU7LykWndBZ2iw_YBZ 7Zx7b8c8Hlmdh0Xk0iTih77k2jSBxhDtFptkEGRzzAnx9FbN1TjURg24VkSnHmjFuYaK6kugFAr7 aln_UFbHTq3Z1JzdzISv3qZDhAzS8WCQmau2ctWHqezQvvKcXeOMDsRaYanFPtCYClbeUNd7MBgx 7jurHTue0kNeQl5nCWrUkNFemFYCXwL8jGGg06parSo9RXv2cYNafsr7FXBr1L3L9Dv6rECpnhU7 nWdtoPD6ayz6WNkjXadg0Pa9.dkTj7WPeguLP_X04u3ne1Epb.aH3bM6nmu8XhyVi0uBNMdocGW2 Qc_Ew2E6OQacImCkp8xkF4HtOmqhEwRWoyI7IGBz6vaRQBwtH5MnK3a1u3Sl0kQFew9qCBeQQTC9 QURNKJRimayT2l55hHSo32SmQ1PKeNDunnJ2s_dGsgPM.3WGHWw8P5fTftVy4aUP61vaVjKZkxnV wOPcZwnnyaqFpUt52YMNRy_r3WCIXGXmdywPo5HqjeESQSKOrZJl4wtI8SCgTC7C31F58Si.Y4Hi KV8U06tHi8ewwIHnLchtdcpMxYLBdZ3_EcO5IKJYqubtNJuvwUQfLxEA2n3cQM33BgnZ_dVYCGvA MFCn73Vdfk6ZK9f5X.lo- Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Thu, 7 May 2020 07:46:37 +0000 Received: by smtp403.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 2d65ee9bbf6f83b7a0d0434cbd6c20e4; Thu, 07 May 2020 07:46:32 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: svn commit: r360233 - in head: contrib/jemalloc . . . : This partially breaks a 2-socket 32-bit powerpc (old PowerMac G4) based on head -r360311 From: Mark Millard In-Reply-To: <8AAB0462-3FA8-490C-8D8D-7C15B1C9E2DE@yahoo.com> Date: Thu, 7 May 2020 00:46:30 -0700 Cc: Brandon Bergren , Justin Hibbits Content-Transfer-Encoding: quoted-printable Message-Id: <18E62746-80DB-4195-977D-4FF32D0129EE@yahoo.com> References: <8479DD58-44F6-446A-9CA5-D01F0F7C1B38@yahoo.com> <17ACDA02-D7EF-4F26-874A-BB3E935CD072@yahoo.com> <695E6836-F860-4557-B7DE-CC1EDB347F18@yahoo.com> <121B9B09-141B-4DC3-918B-1E7CFB99E779@yahoo.com> <8AAB0462-3FA8-490C-8D8D-7C15B1C9E2DE@yahoo.com> To: "vangyzen@freebsd.org" , svn-src-head@freebsd.org, FreeBSD Current , FreeBSD Hackers , FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49HlsC2BYYz3FJT X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.15 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCPT_COUNT_SEVEN(0.00)[7]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.72)[-0.716,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.93)[-0.929,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ip: (4.75), ipnet: 98.137.64.0/21(0.83), asn: 36647(0.66), country: US(-0.05)]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[32.65.137.98.list.dnswl.org : 127.0.5.0]; RWL_MAILSPIKE_POSSIBLE(0.00)[32.65.137.98.rep.mailspike.net : 127.0.0.17]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2020 07:46:40 -0000 [__je_sz_size2index_tab seems messed up in 2 of the asserting contexts: first 384 are zero in both. More before that is also messed up (all zero). I show the details later below.] On 2020-May-6, at 16:57, Mark Millard wrote: > [This explores process crashes that happen during system > shutdown, in a context not having MALLOC_PRODUCTION=3D . > So assert failures are reported as the stopping points.] >=20 > It looks like shutdown -p now, shutdown -r now, and the > like can lead some processes to assert during their exit > attempt, including a sshd failure (that I've not seen > before), rpcbind, and nfsd. I show information about the > observed asserts for those below. >=20 >=20 > sshd hit an assert, failing slab =3D=3D extent_slab_get(extent) : >=20 > (gdb) bt=20 > #0 thr_kill () at thr_kill.S:4 > #1 0x50927170 in __raise (s=3D6) at /usr/src/lib/libc/gen/raise.c:52 > #2 0x50886cc0 in abort () at /usr/src/lib/libc/stdlib/abort.c:67 > #3 0x508834b0 in arena_dalloc (tsdn=3D, ptr=3D, tcache=3D, alloc_ctx=3D, = slow_path=3D) > at = /usr/src/contrib/jemalloc/include/jemalloc/internal/arena_inlines_b.h:315 > #4 idalloctm (tsdn=3D0x500dd040, ptr=3D0x5008a180, tcache=3D0x500dd160,= alloc_ctx=3D, is_internal=3D, = slow_path=3D) > at = /usr/src/contrib/jemalloc/include/jemalloc/internal/jemalloc_internal_inli= nes_c.h:118 > #5 0x5087b0a4 in ifree (tsd=3D0x500dd040, ptr=3D0x5008a180, = tcache=3D0x500dd160, slow_path=3D) at = jemalloc_jemalloc.c:2590 > #6 0x5087acac in __je_free_default (ptr=3D0x5008a180) at = jemalloc_jemalloc.c:2784 > #7 0x5087b294 in __free (ptr=3D0x5008a180) at = jemalloc_jemalloc.c:2852 > #8 0x10029464 in server_accept_loop (config_s=3D, = sock_in=3D, sock_out=3D, = newsock=3D) at /usr/src/crypto/openssh/sshd.c:1185 > #9 main (ac=3D, av=3D0xffffde3c) at = /usr/src/crypto/openssh/sshd.c:2009 >=20 > . . . > (gdb) up > #2 0x50886cc0 in abort () at /usr/src/lib/libc/stdlib/abort.c:67 > 67 (void)raise(SIGABRT); > (gdb) up > #3 0x508834b0 in arena_dalloc (tsdn=3D, ptr=3D, tcache=3D, alloc_ctx=3D, = slow_path=3D) > at = /usr/src/contrib/jemalloc/include/jemalloc/internal/arena_inlines_b.h:315 > 315 assert(slab =3D=3D extent_slab_get(extent)); >=20 > (gdb) list > 310 rtree_ctx =3D tsd_rtree_ctx(tsdn_tsd(tsdn)); > 311 extent_t *extent =3D rtree_extent_read(tsdn, = &extents_rtree, > 312 rtree_ctx, (uintptr_t)ptr, true); > 313 assert(szind =3D=3D extent_szind_get(extent)); > 314 assert(szind < SC_NSIZES); > 315 assert(slab =3D=3D extent_slab_get(extent)); > 316 } > 317=09 > 318 if (likely(slab)) { > 319 /* Small allocation. */ >=20 > More fully: >=20 > 285 JEMALLOC_ALWAYS_INLINE void > 286 arena_dalloc(tsdn_t *tsdn, void *ptr, tcache_t *tcache, > 287 alloc_ctx_t *alloc_ctx, bool slow_path) { > 288 assert(!tsdn_null(tsdn) || tcache =3D=3D NULL); > 289 assert(ptr !=3D NULL); > 290=09 > 291 if (unlikely(tcache =3D=3D NULL)) { > 292 arena_dalloc_no_tcache(tsdn, ptr); > 293 return; > 294 } > 295=09 > 296 szind_t szind; > 297 bool slab; > 298 rtree_ctx_t *rtree_ctx; > 299 if (alloc_ctx !=3D NULL) { > 300 szind =3D alloc_ctx->szind; > 301 slab =3D alloc_ctx->slab; > 302 assert(szind !=3D SC_NSIZES); > 303 } else { > 304 rtree_ctx =3D tsd_rtree_ctx(tsdn_tsd(tsdn)); > 305 rtree_szind_slab_read(tsdn, &extents_rtree, = rtree_ctx, > 306 (uintptr_t)ptr, true, &szind, &slab); > 307 } > 308=09 > 309 if (config_debug) { > 310 rtree_ctx =3D tsd_rtree_ctx(tsdn_tsd(tsdn)); > 311 extent_t *extent =3D rtree_extent_read(tsdn, = &extents_rtree, > 312 rtree_ctx, (uintptr_t)ptr, true); > 313 assert(szind =3D=3D extent_szind_get(extent)); > 314 assert(szind < SC_NSIZES); > 315 assert(slab =3D=3D extent_slab_get(extent)); > 316 } > 317=09 > 318 if (likely(slab)) { > 319 /* Small allocation. */ > 320 tcache_dalloc_small(tsdn_tsd(tsdn), tcache, ptr, = szind, > 321 slow_path); > 322 } else { > 323 arena_dalloc_large(tsdn, ptr, tcache, szind, = slow_path); > 324 } > 325 } The following are only shown for contrast with the later cases of lots of zeros showing up where below shows non-zero values (taken from sshd.core, which failed differently): (gdb) x/4x __je_arenas+16368/4 0x50981ab0 <__je_arenas+16368>: 0x00000000 0x00000000 = 0x00000000 0x00000009 (gdb) print/x __je_arenas_lock=20 $1 =3D {{{prof_data =3D {tot_wait_time =3D {ns =3D 0x0}, max_wait_time =3D= {ns =3D 0x0}, n_wait_times =3D 0x0, n_spin_acquired =3D 0x0, max_n_thds = =3D 0x0, n_waiting_thds =3D {repr =3D 0x0}, n_owner_switches =3D 0x0,=20 prev_owner =3D 0x0, n_lock_ops =3D 0x0}, lock =3D 0x5008bf00, = postponed_next =3D 0x50974070, locked =3D {repr =3D 0x0}}}, witness =3D = {name =3D 0x50760b04, rank =3D 0x3, comp =3D 0x0, opaque =3D 0x0, link =3D= { qre_next =3D 0x50981b10, qre_prev =3D 0x50981b10}}, lock_order =3D = 0x0} (gdb) print/x __je_narenas_auto $2 =3D 0x8 (gdb) print/x malloc_conf $3 =3D 0x0 (gdb) print/x __je_ncpus $4 =3D 0x2 (gdb) print/x __je_manual_arena_base $5 =3D 0x9 (gdb) print/x __je_sz_pind2sz_tab=20 $6 =3D {0x1000, 0x2000, 0x3000, 0x4000, 0x5000, 0x6000, 0x7000, 0x8000, = 0xa000, 0xc000, 0xe000, 0x10000, 0x14000, 0x18000, 0x1c000, 0x20000, = 0x28000, 0x30000, 0x38000, 0x40000, 0x50000, 0x60000,=20 0x70000, 0x80000, 0xa0000, 0xc0000, 0xe0000, 0x100000, 0x140000, = 0x180000, 0x1c0000, 0x200000, 0x280000, 0x300000, 0x380000, 0x400000, = 0x500000, 0x600000, 0x700000, 0x800000, 0xa00000, 0xc00000,=20 0xe00000, 0x1000000, 0x1400000, 0x1800000, 0x1c00000, 0x2000000, = 0x2800000, 0x3000000, 0x3800000, 0x4000000, 0x5000000, 0x6000000, = 0x7000000, 0x8000000, 0xa000000, 0xc000000, 0xe000000,=20 0x10000000, 0x14000000, 0x18000000, 0x1c000000, 0x20000000, = 0x28000000, 0x30000000, 0x38000000, 0x40000000, 0x50000000, 0x60000000, = 0x70000000, 0x70001000} (gdb) print/x __je_sz_index2size_tab $7 =3D {0x8, 0x10, 0x20, 0x30, 0x40, 0x50, 0x60, 0x70, 0x80, 0xa0, 0xc0, = 0xe0, 0x100, 0x140, 0x180, 0x1c0, 0x200, 0x280, 0x300, 0x380, 0x400, = 0x500, 0x600, 0x700, 0x800, 0xa00, 0xc00, 0xe00, 0x1000,=20 0x1400, 0x1800, 0x1c00, 0x2000, 0x2800, 0x3000, 0x3800, 0x4000, = 0x5000, 0x6000, 0x7000, 0x8000, 0xa000, 0xc000, 0xe000, 0x10000, = 0x14000, 0x18000, 0x1c000, 0x20000, 0x28000, 0x30000, 0x38000,=20 0x40000, 0x50000, 0x60000, 0x70000, 0x80000, 0xa0000, 0xc0000, = 0xe0000, 0x100000, 0x140000, 0x180000, 0x1c0000, 0x200000, 0x280000, = 0x300000, 0x380000, 0x400000, 0x500000, 0x600000, 0x700000,=20 0x800000, 0xa00000, 0xc00000, 0xe00000, 0x1000000, 0x1400000, = 0x1800000, 0x1c00000, 0x2000000, 0x2800000, 0x3000000, 0x3800000, = 0x4000000, 0x5000000, 0x6000000, 0x7000000, 0x8000000, 0xa000000,=20 0xc000000, 0xe000000, 0x10000000, 0x14000000, 0x18000000, 0x1c000000, = 0x20000000, 0x28000000, 0x30000000, 0x38000000, 0x40000000, 0x50000000, = 0x60000000, 0x70000000} (gdb) print/x __je_sz_size2index_tab $2 =3D {0x0, 0x0, 0x1, 0x2, 0x2, 0x3, 0x3, 0x4, 0x4, 0x5, 0x5, 0x6, 0x6, = 0x7, 0x7, 0x8, 0x8, 0x9, 0x9, 0x9, 0x9, 0xa, 0xa, 0xa, 0xa, 0xb, 0xb, = 0xb, 0xb, 0xc, 0xc, 0xc, 0xc, 0xd, 0xd, 0xd, 0xd, 0xd,=20 0xd, 0xd, 0xd, 0xe, 0xe, 0xe, 0xe, 0xe, 0xe, 0xe, 0xe, 0xf, 0xf, 0xf, = 0xf, 0xf, 0xf, 0xf, 0xf, 0x10, 0x10, 0x10, 0x10, 0x10, 0x10, 0x10, 0x10, = 0x11 , 0x12 ,=20 0x13 , 0x14 , 0x15 , 0x16 , 0x17 , 0x18 , 0x19 ,=20 0x1a , 0x1b , 0x1c } > rpcbind hit an assert, failing ret =3D=3D sz_size2index_compute(size) = : >=20 > (gdb) bt > #0 thr_kill () at thr_kill.S:4 > #1 0x502f2170 in __raise (s=3D6) at /usr/src/lib/libc/gen/raise.c:52 > #2 0x50251d04 in abort () at /usr/src/lib/libc/stdlib/abort.c:79 > #3 0x5024f260 in sz_size2index_lookup (size=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/sz.h:159 > #4 sz_size2index (size=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/sz.h:166 > #5 imalloc_body (sopts=3D0xffffb360, dopts=3D0xffffb340, = tsd=3D0x5009a018) at jemalloc_jemalloc.c:2066 > #6 0x50244874 in imalloc (sopts=3D0xffffb360, dopts=3D0xffffb340) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/tsd.h:331 > #7 0x50244fe8 in __calloc (num=3D1, size=3D96) at = jemalloc_jemalloc.c:2498 > #8 0x50265690 in svc_xprt_alloc () at /usr/src/lib/libc/rpc/svc.c:541 > #9 0x502635f4 in makefd_xprt (fd=3D14, sendsize=3D9000, = recvsize=3D9000) at /usr/src/lib/libc/rpc/svc_vc.c:250 > #10 0x502644b4 in rendezvous_request (xprt=3D0x5004c000, = msg=3D) at /usr/src/lib/libc/rpc/svc_vc.c:315 > #11 0x50265a98 in svc_getreq_common (fd=3D) at = /usr/src/lib/libc/rpc/svc.c:640 > #12 0x50265d1c in svc_getreq_poll (pfdp=3D, = pollretval=3D1) at /usr/src/lib/libc/rpc/svc.c:739 > #13 0x10018568 in my_svc_run () at = /usr/src/usr.sbin/rpcbind/rpcb_svc_com.c:1167 > #14 0x10014ad8 in main (argc=3D, argv=3D) at /usr/src/usr.sbin/rpcbind/rpcbind.c:250 > (gdb) up 3 > #3 0x5024f260 in sz_size2index_lookup (size=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/sz.h:159 > 159 assert(ret =3D=3D sz_size2index_compute(size)); > (gdb) print ret > $1 =3D 0 >=20 > 154 JEMALLOC_ALWAYS_INLINE szind_t > 155 sz_size2index_lookup(size_t size) { > 156 assert(size <=3D SC_LOOKUP_MAXCLASS); > 157 szind_t ret =3D (sz_size2index_tab[(size + (ZU(1) << = SC_LG_TINY_MIN) - 1) > 158 >> SC_LG_TINY_MIN]); > 159 assert(ret =3D=3D sz_size2index_compute(size)); > 160 return ret; > 161 } gdb reports for sz_size2index_tab (really JEMALLOC_N(sz_size2index_tab), i.e., __je_sz_size2index_tab): (gdb) print/x __je_sz_size2index_tab $1 =3D {0x0 , 0x1a, 0x1b , 0x1c = } Also: (gdb) x/4x __je_arenas+16368/4 0x5034cab0 <__je_arenas+16368>: 0x00000000 0x00000000 = 0x00000000 0x00000000 (gdb) print/x __je_arenas_lock = =20 $8 =3D {{{prof_data =3D {tot_wait_time =3D {ns =3D 0x0}, max_wait_time =3D= {ns =3D 0x0}, n_wait_times =3D 0x0, n_spin_acquired =3D 0x0, max_n_thds = =3D 0x0, n_waiting_thds =3D {repr =3D 0x0}, n_owner_switches =3D 0x0,=20 prev_owner =3D 0x0, n_lock_ops =3D 0x0}, lock =3D 0x0, = postponed_next =3D 0x0, locked =3D {repr =3D 0x0}}}, witness =3D {name =3D= 0x0, rank =3D 0x0, comp =3D 0x0, opaque =3D 0x0, link =3D {qre_next =3D = 0x0,=20 qre_prev =3D 0x0}}, lock_order =3D 0x0} (gdb) print/x __je_narenas_auto $9 =3D 0x0 (gdb) print/x malloc_conf =20 $10 =3D 0x0 (gdb) print/x __je_ncpus=20 $11 =3D 0x0 (gdb) print/x __je_manual_arena_base $12 =3D 0x0 (gdb) print/x __je_sz_pind2sz_tab =20 $13 =3D {0x0 } (gdb) print/x __je_sz_index2size_tab $14 =3D {0x0 } > nfsd hit an assert, failing ret =3D=3D sz_size2index_compute(size) [Correction: That should have referenced sz_index2size_lookup(index).] > (also, but a different caller of sz_size2index): [Correction: The "also" comment should be ignored: sz_index2size_lookup(index) is referenced below.] >=20 > (gdb) bt > #0 thr_kill () at thr_kill.S:4 > #1 0x502b2170 in __raise (s=3D6) at /usr/src/lib/libc/gen/raise.c:52 > #2 0x50211cc0 in abort () at /usr/src/lib/libc/stdlib/abort.c:67 > #3 0x50206104 in sz_index2size_lookup (index=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/sz.h:200 > #4 sz_index2size (index=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/sz.h:207 > #5 ifree (tsd=3D0x50094018, ptr=3D0x50041028, tcache=3D0x50094138, = slow_path=3D) at jemalloc_jemalloc.c:2583 > #6 0x50205cac in __je_free_default (ptr=3D0x50041028) at = jemalloc_jemalloc.c:2784 > #7 0x50206294 in __free (ptr=3D0x50041028) at = jemalloc_jemalloc.c:2852 > #8 0x50287ec8 in ns_src_free (src=3D0x50329004, = srclistsize=3D) at /usr/src/lib/libc/net/nsdispatch.c:452 > #9 ns_dbt_free (dbt=3D0x50329000) at = /usr/src/lib/libc/net/nsdispatch.c:436 > #10 vector_free (vec=3D0x50329000, count=3D, esize=3D12, = free_elem=3D) at /usr/src/lib/libc/net/nsdispatch.c:253 > #11 nss_atexit () at /usr/src/lib/libc/net/nsdispatch.c:578 > #12 0x5028d958 in __cxa_finalize (dso=3D0x0) at = /usr/src/lib/libc/stdlib/atexit.c:240 > #13 0x502117f8 in exit (status=3D0) at = /usr/src/lib/libc/stdlib/exit.c:74 > #14 0x10013f9c in child_cleanup (signo=3D) at = /usr/src/usr.sbin/nfsd/nfsd.c:969 > #15 > #16 0x00000000 in ?? () >=20 > (gdb) up 3 > #3 0x50206104 in sz_index2size_lookup (index=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/sz.h:200 > 200 assert(ret =3D=3D sz_index2size_compute(index)); >=20 > (ret is optimized out.) >=20 > 197 JEMALLOC_ALWAYS_INLINE size_t > 198 sz_index2size_lookup(szind_t index) { > 199 size_t ret =3D (size_t)sz_index2size_tab[index]; > 200 assert(ret =3D=3D sz_index2size_compute(index)); > 201 return ret; > 202 } (gdb) print/x __je_sz_index2size_tab $3 =3D {0x0 } Also: (gdb) x/4x __je_arenas+16368/4 0x5030cab0 <__je_arenas+16368>: 0x00000000 0x00000000 = 0x00000000 0x00000000 (gdb) print/x __je_arenas_lock = =20 $8 =3D {{{prof_data =3D {tot_wait_time =3D {ns =3D 0x0}, max_wait_time =3D= {ns =3D 0x0}, n_wait_times =3D 0x0, n_spin_acquired =3D 0x0, max_n_thds = =3D 0x0, n_waiting_thds =3D {repr =3D 0x0}, n_owner_switches =3D 0x0,=20 prev_owner =3D 0x0, n_lock_ops =3D 0x0}, lock =3D 0x0, = postponed_next =3D 0x0, locked =3D {repr =3D 0x0}}}, witness =3D {name =3D= 0x0, rank =3D 0x0, comp =3D 0x0, opaque =3D 0x0, link =3D {qre_next =3D = 0x0,=20 qre_prev =3D 0x0}}, lock_order =3D 0x0} (gdb) print/x __je_narenas_auto $9 =3D 0x0 (gdb) print/x malloc_conf =20 $10 =3D 0x0 (gdb) print/x __je_ncpus=20 $11 =3D 0x0 (gdb) print/x __je_manual_arena_base $12 =3D 0x0 (gdb) print/x __je_sz_pind2sz_tab =20 $13 =3D {0x0 } (gdb) print/x __je_sz_size2index_tab $1 =3D {0x0 , 0x1a, 0x1b , 0x1c = } > Booting and immediately trying something like: >=20 > service nfsd stop >=20 > did not lead to a failure. But may be after > a while it would and be less drastic than a > reboot or power down. More detail: So, for rpcbind and nfds at some point a large part of __je_sz_size2index_tab is being stomped on, as is all of __je_sz_index2size_tab and more. For rpcbind, the following area is zero but in a live process is not all-zero (I show the partially non-zero live-process context instead of the all-zero .core file content): 0x5034cab0 <__je_arenas+16368>: 0x00000000 0x00000000 = 0x00000000 0x00000009 0x5034cac0 <__je_arenas_lock>: 0x00000000 0x00000000 = 0x00000000 0x00000000 0x5034cad0 <__je_arenas_lock+16>: 0x00000000 0x00000000 = 0x00000000 0x00000000 0x5034cae0 <__je_arenas_lock+32>: 0x00000000 0x00000000 = 0x00000000 0x00000000 0x5034caf0 <__je_arenas_lock+48>: 0x00000000 0x00000000 = 0x00000000 0x00000000 0x5034cb00 <__je_arenas_lock+64>: 0x00000000 0x5033f070 = 0x00000000 0x00000000 0x5034cb10 <__je_arenas_lock+80>: 0x5012bb04 0x00000003 = 0x00000000 0x00000000 0x5034cb20 <__je_arenas_lock+96>: 0x5034cb10 0x5034cb10 = 0x00000000 0x00000000 Then the memory in the crash continues to be zero until: 0x5034d000 <__je_sz_size2index_tab+384>: 0x1a1b1b1b = 0x1b1b1b1b 0x1b1b1b1b 0x1b1b1b1b Notice the interesting page boundary for where non-zero is first available again! Between __je_arenas_lock and __je_sz_size2index_tab are: 0x5034cb30 __je_narenas_auto 0x5034cb38 malloc_conf 0x5034cb3c __je_ncpus 0x5034cb40 __je_manual_arena_base 0x5034cb80 __je_sz_pind2sz_tab 0x5034ccc0 __je_sz_index2size_tab 0x5034ce80 __je_sz_size2index_tab For nfsd, it is similar (again showing the partially non-zero live process context instead of the all-zeros from the .core file): 0x5030cab0 <__je_arenas+16368>: 0x00000000 0x00000000 = 0x00000000 0x00000009 0x5030cac0 <__je_arenas_lock>: 0x00000000 0x00000000 = 0x00000000 0x00000000 0x5030cad0 <__je_arenas_lock+16>: 0x00000000 0x00000000 = 0x00000000 0x00000000 0x5030cae0 <__je_arenas_lock+32>: 0x00000000 0x00000000 = 0x00000000 0x00000000 0x5030caf0 <__je_arenas_lock+48>: 0x00000000 0x00000000 = 0x00000000 0x00000000 0x5030cb00 <__je_arenas_lock+64>: 0x00000000 0x502ff070 = 0x00000000 0x00000000 0x5030cb10 <__je_arenas_lock+80>: 0x500ebb04 0x00000003 = 0x00000000 0x00000000 0x5030cb20 <__je_arenas_lock+96>: 0x5030cb10 0x5030cb10 = 0x00000000 0x00000000 Then the memory in the crash continues to be zero until: 0x5030d000 <__je_sz_size2index_tab+384>: 0x1a1b1b1b = 0x1b1b1b1b 0x1b1b1b1b 0x1b1b1b1b Notice the interesting page boundary for where non-zero is first available again! Between __je_arenas_lock and __je_sz_size2index_tab are: 0x5030cb30 __je_narenas_auto 0x5030cb38 malloc_conf 0x5030cb3c __je_ncpus 0x5030cb40 __je_manual_arena_base 0x5030cb80 __je_sz_pind2sz_tab 0x5030ccc0 __je_sz_index2size_tab 0x5030ce80 __je_sz_size2index_tab Note: because __je_arenas is normally mostly zero for these contexts, I can not tell where the memory trashing started, only where it replaced non-zero values with zeros. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-ppc@freebsd.org Thu May 7 19:06:38 2020 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 C19152E1E9D for ; Thu, 7 May 2020 19:06:38 +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 49J2xn1xzKz4Zqh for ; Thu, 7 May 2020 19:06:37 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: ymUHbHAVM1nxMvrnBetflgticeA9_e1fEHsRRHVMHn0m2qCUC.tTFaDDeMuvFXO JMGVC3bkuHxMQ3Gh2xCgvxW4jAGW6JsVsVXrx8HToAGqGgMVCwx1cYVzQ9BNdiu1NFjhrJMUFNX3 KOPexm9XqKb_62elZnxldMtv6kG67pexLkfYuhEK9GdrVmZoPQPmNmfeTxtTlAdcoHeStPre1w2O Ce0doYJbKpkR39sSZm7clKruyOcUtyvXTNQKFn7L63qLYm.IDcrwekGcccVJct0Ihcw2hnVctlXD VSEssj9Dyqr2B8XK9PhIyZSiXkN.kIiXSKma5esYqfAREwas0lVoLKmkQ1LJLvMFnI2a630GjD9L bUJeisuATRy2OHPRzFKAlAyymPTwMzg23QeWoBQKvLBwzp_JsDmBQOzRWZOdGWkXkJAQAJghNNjL aWdUNOc5seAEdCA7qBs7Em9miC5WHxmYlNanPibU9x0x2Y5Ih_9c1MdOB8edHM3MfA0BmDcw2e3A A4.xhSVnMHvFB2kl9IwAlP1jFpNEoDUbsMwYPJaoSvuzv2BSwPcGvGqHkX870PPgfrDj32d7O7hn ul_vXE4u42qUxd.KMVyI27S7uGVNDXmzyuT2d6ZGROYtvob__cL6xBmNhT7C_81b5aCwSyJOUbTs cx9f__cSs8bOGlC6sbtxRs8VqrLaxHyJKvoZvsbIfFkLs0M9ANzOXEzG5fllGBnUNFCI6bIS9WCx ZcllYQuVYqpLDvuhS3h00YppZc4LDLZN40bnsZj8VOafpMtgoC1fWEllCewltGw11jV.Had9Mfud f5LxYdj3CXef8em.11Zv.Pdt6qDYCD0har50cPmDgT13cSYL.O9GsbK5DeSxdNqciTJuv5LdcKob xgHlWPjb8dxR1fHYXgieiHprpzMBHpz_kL_K_kLqp0i6xs9QiMQ17mZ5mo5pVrRbyXro1TUn2Bvc pF2WP6I6vjM6G55BVesaEl.VAgS3mxTJVMps52zZfq2mw0BStsODtQZ3SAQKf7KEZlXoNx91xXLz WTkybn.q9c5UzDLu_pX1aJDr1fGQPp9asliXeImYT1l4DsySQU8fuGnx.k5RleIMVwH7cRVr1BOj .cPbQvbcsNyHLvizcNWwqzHzYpopO3_gkwVXcRYlerQgiUztzU.1zWxpYOa7HQXowhAs5bFoHsbl 7fMk0lceaJTOCuM1_z3Ab_FRuiMuIV6cheVf_Ai.QzEGOw3.XCr7gyDL1t61cLC8LPareeeH_x9E zl1CVhlvBMkpWhiJiXIpICBhd1uWUqLpd8oakTxub26b3x4Zzgk0gT5OlK6YeMs_vL58OepvSMNH nf9yMHViwKnvByXTPJAQsxNKB8TrDLI7Z5PwSOpjXusG59yUk6.nEwKCAlr3DT5uOpYO1ufMP5XF PZSUUB1BRwmXrx2to51w4MVcqCV.DLSwqh7fFh9IaiCi8sY5qZObGhxPpPGX_.w-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Thu, 7 May 2020 19:06:35 +0000 Received: by smtp434.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID f7716cd2133ed3096a69b5432fcac9e7; Thu, 07 May 2020 19:06:34 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: svn commit: r360233 - in head: contrib/jemalloc . . . : This partially breaks a 2-socket 32-bit powerpc (old PowerMac G4) based on head -r360311 From: Mark Millard In-Reply-To: <18E62746-80DB-4195-977D-4FF32D0129EE@yahoo.com> Date: Thu, 7 May 2020 12:06:15 -0700 Cc: Brandon Bergren , Justin Hibbits Content-Transfer-Encoding: quoted-printable Message-Id: References: <8479DD58-44F6-446A-9CA5-D01F0F7C1B38@yahoo.com> <17ACDA02-D7EF-4F26-874A-BB3E935CD072@yahoo.com> <695E6836-F860-4557-B7DE-CC1EDB347F18@yahoo.com> <121B9B09-141B-4DC3-918B-1E7CFB99E779@yahoo.com> <8AAB0462-3FA8-490C-8D8D-7C15B1C9E2DE@yahoo.com> <18E62746-80DB-4195-977D-4FF32D0129EE@yahoo.com> To: "vangyzen@freebsd.org" , svn-src-head@freebsd.org, FreeBSD Current , FreeBSD Hackers , FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49J2xn1xzKz4Zqh X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.49 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCPT_COUNT_SEVEN(0.00)[7]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.993,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ip: (-0.08), ipnet: 98.137.64.0/21(0.83), asn: 36647(0.66), country: US(-0.05)]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[206.68.137.98.list.dnswl.org : 127.0.5.0]; RWL_MAILSPIKE_POSSIBLE(0.00)[206.68.137.98.rep.mailspike.net : 127.0.0.17]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2020 19:06:38 -0000 [mountd failure example: also at sz_size2index_lookup assert for the same zero'd memory problem.] > On 2020-May-7, at 00:46, Mark Millard wrote: >=20 > [__je_sz_size2index_tab seems messed up in 2 of the > asserting contexts: first 384 are zero in both. More > before that is also messed up (all zero). I show the > details later below.] >=20 > On 2020-May-6, at 16:57, Mark Millard wrote: >=20 >> [This explores process crashes that happen during system >> shutdown, in a context not having MALLOC_PRODUCTION=3D . >> So assert failures are reported as the stopping points.] >>=20 >> It looks like shutdown -p now, shutdown -r now, and the >> like can lead some processes to assert during their exit >> attempt, including a sshd failure (that I've not seen >> before), rpcbind, and nfsd. I show information about the >> observed asserts for those below. >>=20 >>=20 >> sshd hit an assert, failing slab =3D=3D extent_slab_get(extent) : >>=20 >> (gdb) bt=20 >> #0 thr_kill () at thr_kill.S:4 >> #1 0x50927170 in __raise (s=3D6) at /usr/src/lib/libc/gen/raise.c:52 >> #2 0x50886cc0 in abort () at /usr/src/lib/libc/stdlib/abort.c:67 >> #3 0x508834b0 in arena_dalloc (tsdn=3D, = ptr=3D, tcache=3D, alloc_ctx=3D, slow_path=3D) >> at = /usr/src/contrib/jemalloc/include/jemalloc/internal/arena_inlines_b.h:315 >> #4 idalloctm (tsdn=3D0x500dd040, ptr=3D0x5008a180, = tcache=3D0x500dd160, alloc_ctx=3D, is_internal=3D, slow_path=3D) >> at = /usr/src/contrib/jemalloc/include/jemalloc/internal/jemalloc_internal_inli= nes_c.h:118 >> #5 0x5087b0a4 in ifree (tsd=3D0x500dd040, ptr=3D0x5008a180, = tcache=3D0x500dd160, slow_path=3D) at = jemalloc_jemalloc.c:2590 >> #6 0x5087acac in __je_free_default (ptr=3D0x5008a180) at = jemalloc_jemalloc.c:2784 >> #7 0x5087b294 in __free (ptr=3D0x5008a180) at = jemalloc_jemalloc.c:2852 >> #8 0x10029464 in server_accept_loop (config_s=3D, = sock_in=3D, sock_out=3D, = newsock=3D) at /usr/src/crypto/openssh/sshd.c:1185 >> #9 main (ac=3D, av=3D0xffffde3c) at = /usr/src/crypto/openssh/sshd.c:2009 >>=20 >> . . . >> (gdb) up >> #2 0x50886cc0 in abort () at /usr/src/lib/libc/stdlib/abort.c:67 >> 67 (void)raise(SIGABRT); >> (gdb) up >> #3 0x508834b0 in arena_dalloc (tsdn=3D, = ptr=3D, tcache=3D, alloc_ctx=3D, slow_path=3D) >> at = /usr/src/contrib/jemalloc/include/jemalloc/internal/arena_inlines_b.h:315 >> 315 assert(slab =3D=3D extent_slab_get(extent)); >>=20 >> (gdb) list >> 310 rtree_ctx =3D tsd_rtree_ctx(tsdn_tsd(tsdn)); >> 311 extent_t *extent =3D rtree_extent_read(tsdn, = &extents_rtree, >> 312 rtree_ctx, (uintptr_t)ptr, true); >> 313 assert(szind =3D=3D extent_szind_get(extent)); >> 314 assert(szind < SC_NSIZES); >> 315 assert(slab =3D=3D extent_slab_get(extent)); >> 316 } >> 317=09 >> 318 if (likely(slab)) { >> 319 /* Small allocation. */ >>=20 >> More fully: >>=20 >> 285 JEMALLOC_ALWAYS_INLINE void >> 286 arena_dalloc(tsdn_t *tsdn, void *ptr, tcache_t *tcache, >> 287 alloc_ctx_t *alloc_ctx, bool slow_path) { >> 288 assert(!tsdn_null(tsdn) || tcache =3D=3D NULL); >> 289 assert(ptr !=3D NULL); >> 290=09 >> 291 if (unlikely(tcache =3D=3D NULL)) { >> 292 arena_dalloc_no_tcache(tsdn, ptr); >> 293 return; >> 294 } >> 295=09 >> 296 szind_t szind; >> 297 bool slab; >> 298 rtree_ctx_t *rtree_ctx; >> 299 if (alloc_ctx !=3D NULL) { >> 300 szind =3D alloc_ctx->szind; >> 301 slab =3D alloc_ctx->slab; >> 302 assert(szind !=3D SC_NSIZES); >> 303 } else { >> 304 rtree_ctx =3D tsd_rtree_ctx(tsdn_tsd(tsdn)); >> 305 rtree_szind_slab_read(tsdn, &extents_rtree, = rtree_ctx, >> 306 (uintptr_t)ptr, true, &szind, &slab); >> 307 } >> 308=09 >> 309 if (config_debug) { >> 310 rtree_ctx =3D tsd_rtree_ctx(tsdn_tsd(tsdn)); >> 311 extent_t *extent =3D rtree_extent_read(tsdn, = &extents_rtree, >> 312 rtree_ctx, (uintptr_t)ptr, true); >> 313 assert(szind =3D=3D extent_szind_get(extent)); >> 314 assert(szind < SC_NSIZES); >> 315 assert(slab =3D=3D extent_slab_get(extent)); >> 316 } >> 317=09 >> 318 if (likely(slab)) { >> 319 /* Small allocation. */ >> 320 tcache_dalloc_small(tsdn_tsd(tsdn), tcache, ptr, = szind, >> 321 slow_path); >> 322 } else { >> 323 arena_dalloc_large(tsdn, ptr, tcache, szind, = slow_path); >> 324 } >> 325 } >=20 > The following are only shown for contrast with the later > cases of lots of zeros showing up where below shows > non-zero values (taken from sshd.core, which failed > differently): >=20 > (gdb) x/4x __je_arenas+16368/4 > 0x50981ab0 <__je_arenas+16368>: 0x00000000 0x00000000 = 0x00000000 0x00000009 > (gdb) print/x __je_arenas_lock=20 > $1 =3D {{{prof_data =3D {tot_wait_time =3D {ns =3D 0x0}, max_wait_time = =3D {ns =3D 0x0}, n_wait_times =3D 0x0, n_spin_acquired =3D 0x0, = max_n_thds =3D 0x0, n_waiting_thds =3D {repr =3D 0x0}, n_owner_switches = =3D 0x0,=20 > prev_owner =3D 0x0, n_lock_ops =3D 0x0}, lock =3D 0x5008bf00, = postponed_next =3D 0x50974070, locked =3D {repr =3D 0x0}}}, witness =3D = {name =3D 0x50760b04, rank =3D 0x3, comp =3D 0x0, opaque =3D 0x0, link =3D= { > qre_next =3D 0x50981b10, qre_prev =3D 0x50981b10}}, lock_order =3D = 0x0} > (gdb) print/x __je_narenas_auto > $2 =3D 0x8 > (gdb) print/x malloc_conf > $3 =3D 0x0 > (gdb) print/x __je_ncpus > $4 =3D 0x2 > (gdb) print/x __je_manual_arena_base > $5 =3D 0x9 > (gdb) print/x __je_sz_pind2sz_tab=20 > $6 =3D {0x1000, 0x2000, 0x3000, 0x4000, 0x5000, 0x6000, 0x7000, = 0x8000, 0xa000, 0xc000, 0xe000, 0x10000, 0x14000, 0x18000, 0x1c000, = 0x20000, 0x28000, 0x30000, 0x38000, 0x40000, 0x50000, 0x60000,=20 > 0x70000, 0x80000, 0xa0000, 0xc0000, 0xe0000, 0x100000, 0x140000, = 0x180000, 0x1c0000, 0x200000, 0x280000, 0x300000, 0x380000, 0x400000, = 0x500000, 0x600000, 0x700000, 0x800000, 0xa00000, 0xc00000,=20 > 0xe00000, 0x1000000, 0x1400000, 0x1800000, 0x1c00000, 0x2000000, = 0x2800000, 0x3000000, 0x3800000, 0x4000000, 0x5000000, 0x6000000, = 0x7000000, 0x8000000, 0xa000000, 0xc000000, 0xe000000,=20 > 0x10000000, 0x14000000, 0x18000000, 0x1c000000, 0x20000000, = 0x28000000, 0x30000000, 0x38000000, 0x40000000, 0x50000000, 0x60000000, = 0x70000000, 0x70001000} > (gdb) print/x __je_sz_index2size_tab > $7 =3D {0x8, 0x10, 0x20, 0x30, 0x40, 0x50, 0x60, 0x70, 0x80, 0xa0, = 0xc0, 0xe0, 0x100, 0x140, 0x180, 0x1c0, 0x200, 0x280, 0x300, 0x380, = 0x400, 0x500, 0x600, 0x700, 0x800, 0xa00, 0xc00, 0xe00, 0x1000,=20 > 0x1400, 0x1800, 0x1c00, 0x2000, 0x2800, 0x3000, 0x3800, 0x4000, = 0x5000, 0x6000, 0x7000, 0x8000, 0xa000, 0xc000, 0xe000, 0x10000, = 0x14000, 0x18000, 0x1c000, 0x20000, 0x28000, 0x30000, 0x38000,=20 > 0x40000, 0x50000, 0x60000, 0x70000, 0x80000, 0xa0000, 0xc0000, = 0xe0000, 0x100000, 0x140000, 0x180000, 0x1c0000, 0x200000, 0x280000, = 0x300000, 0x380000, 0x400000, 0x500000, 0x600000, 0x700000,=20 > 0x800000, 0xa00000, 0xc00000, 0xe00000, 0x1000000, 0x1400000, = 0x1800000, 0x1c00000, 0x2000000, 0x2800000, 0x3000000, 0x3800000, = 0x4000000, 0x5000000, 0x6000000, 0x7000000, 0x8000000, 0xa000000,=20 > 0xc000000, 0xe000000, 0x10000000, 0x14000000, 0x18000000, 0x1c000000, = 0x20000000, 0x28000000, 0x30000000, 0x38000000, 0x40000000, 0x50000000, = 0x60000000, 0x70000000} > (gdb) print/x __je_sz_size2index_tab > $2 =3D {0x0, 0x0, 0x1, 0x2, 0x2, 0x3, 0x3, 0x4, 0x4, 0x5, 0x5, 0x6, = 0x6, 0x7, 0x7, 0x8, 0x8, 0x9, 0x9, 0x9, 0x9, 0xa, 0xa, 0xa, 0xa, 0xb, = 0xb, 0xb, 0xb, 0xc, 0xc, 0xc, 0xc, 0xd, 0xd, 0xd, 0xd, 0xd,=20 > 0xd, 0xd, 0xd, 0xe, 0xe, 0xe, 0xe, 0xe, 0xe, 0xe, 0xe, 0xf, 0xf, 0xf, = 0xf, 0xf, 0xf, 0xf, 0xf, 0x10, 0x10, 0x10, 0x10, 0x10, 0x10, 0x10, 0x10, = 0x11 , 0x12 ,=20 > 0x13 , 0x14 , 0x15 , 0x16 , 0x17 , 0x18 , 0x19 ,=20 > 0x1a , 0x1b , 0x1c } >=20 >=20 >> rpcbind hit an assert, failing ret =3D=3D sz_size2index_compute(size) = : >>=20 >> (gdb) bt >> #0 thr_kill () at thr_kill.S:4 >> #1 0x502f2170 in __raise (s=3D6) at /usr/src/lib/libc/gen/raise.c:52 >> #2 0x50251d04 in abort () at /usr/src/lib/libc/stdlib/abort.c:79 >> #3 0x5024f260 in sz_size2index_lookup (size=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/sz.h:159 >> #4 sz_size2index (size=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/sz.h:166 >> #5 imalloc_body (sopts=3D0xffffb360, dopts=3D0xffffb340, = tsd=3D0x5009a018) at jemalloc_jemalloc.c:2066 >> #6 0x50244874 in imalloc (sopts=3D0xffffb360, dopts=3D0xffffb340) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/tsd.h:331 >> #7 0x50244fe8 in __calloc (num=3D1, size=3D96) at = jemalloc_jemalloc.c:2498 >> #8 0x50265690 in svc_xprt_alloc () at = /usr/src/lib/libc/rpc/svc.c:541 >> #9 0x502635f4 in makefd_xprt (fd=3D14, sendsize=3D9000, = recvsize=3D9000) at /usr/src/lib/libc/rpc/svc_vc.c:250 >> #10 0x502644b4 in rendezvous_request (xprt=3D0x5004c000, = msg=3D) at /usr/src/lib/libc/rpc/svc_vc.c:315 >> #11 0x50265a98 in svc_getreq_common (fd=3D) at = /usr/src/lib/libc/rpc/svc.c:640 >> #12 0x50265d1c in svc_getreq_poll (pfdp=3D, = pollretval=3D1) at /usr/src/lib/libc/rpc/svc.c:739 >> #13 0x10018568 in my_svc_run () at = /usr/src/usr.sbin/rpcbind/rpcb_svc_com.c:1167 >> #14 0x10014ad8 in main (argc=3D, argv=3D) at /usr/src/usr.sbin/rpcbind/rpcbind.c:250 >> (gdb) up 3 >> #3 0x5024f260 in sz_size2index_lookup (size=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/sz.h:159 >> 159 assert(ret =3D=3D sz_size2index_compute(size)); >> (gdb) print ret >> $1 =3D 0 >>=20 >> 154 JEMALLOC_ALWAYS_INLINE szind_t >> 155 sz_size2index_lookup(size_t size) { >> 156 assert(size <=3D SC_LOOKUP_MAXCLASS); >> 157 szind_t ret =3D (sz_size2index_tab[(size + (ZU(1) << = SC_LG_TINY_MIN) - 1) >> 158 >> SC_LG_TINY_MIN]); >> 159 assert(ret =3D=3D sz_size2index_compute(size)); >> 160 return ret; >> 161 } >=20 > gdb reports for sz_size2index_tab (really = JEMALLOC_N(sz_size2index_tab), > i.e., __je_sz_size2index_tab): >=20 > (gdb) print/x __je_sz_size2index_tab > $1 =3D {0x0 , 0x1a, 0x1b , 0x1c = } >=20 > Also: >=20 > (gdb) x/4x __je_arenas+16368/4 > 0x5034cab0 <__je_arenas+16368>: 0x00000000 0x00000000 = 0x00000000 0x00000000 > (gdb) print/x __je_arenas_lock = =20= > $8 =3D {{{prof_data =3D {tot_wait_time =3D {ns =3D 0x0}, max_wait_time = =3D {ns =3D 0x0}, n_wait_times =3D 0x0, n_spin_acquired =3D 0x0, = max_n_thds =3D 0x0, n_waiting_thds =3D {repr =3D 0x0}, n_owner_switches = =3D 0x0,=20 > prev_owner =3D 0x0, n_lock_ops =3D 0x0}, lock =3D 0x0, = postponed_next =3D 0x0, locked =3D {repr =3D 0x0}}}, witness =3D {name =3D= 0x0, rank =3D 0x0, comp =3D 0x0, opaque =3D 0x0, link =3D {qre_next =3D = 0x0,=20 > qre_prev =3D 0x0}}, lock_order =3D 0x0} > (gdb) print/x __je_narenas_auto > $9 =3D 0x0 > (gdb) print/x malloc_conf =20 > $10 =3D 0x0 > (gdb) print/x __je_ncpus=20 > $11 =3D 0x0 > (gdb) print/x __je_manual_arena_base > $12 =3D 0x0 > (gdb) print/x __je_sz_pind2sz_tab =20 > $13 =3D {0x0 } > (gdb) print/x __je_sz_index2size_tab > $14 =3D {0x0 } >=20 >=20 >> nfsd hit an assert, failing ret =3D=3D sz_size2index_compute(size) >=20 > [Correction: That should have referenced sz_index2size_lookup(index).] >=20 >> (also, but a different caller of sz_size2index): >=20 > [Correction: The "also" comment should be ignored: > sz_index2size_lookup(index) is referenced below.] >=20 >>=20 >> (gdb) bt >> #0 thr_kill () at thr_kill.S:4 >> #1 0x502b2170 in __raise (s=3D6) at /usr/src/lib/libc/gen/raise.c:52 >> #2 0x50211cc0 in abort () at /usr/src/lib/libc/stdlib/abort.c:67 >> #3 0x50206104 in sz_index2size_lookup (index=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/sz.h:200 >> #4 sz_index2size (index=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/sz.h:207 >> #5 ifree (tsd=3D0x50094018, ptr=3D0x50041028, tcache=3D0x50094138, = slow_path=3D) at jemalloc_jemalloc.c:2583 >> #6 0x50205cac in __je_free_default (ptr=3D0x50041028) at = jemalloc_jemalloc.c:2784 >> #7 0x50206294 in __free (ptr=3D0x50041028) at = jemalloc_jemalloc.c:2852 >> #8 0x50287ec8 in ns_src_free (src=3D0x50329004, = srclistsize=3D) at /usr/src/lib/libc/net/nsdispatch.c:452 >> #9 ns_dbt_free (dbt=3D0x50329000) at = /usr/src/lib/libc/net/nsdispatch.c:436 >> #10 vector_free (vec=3D0x50329000, count=3D, esize=3D12,= free_elem=3D) at /usr/src/lib/libc/net/nsdispatch.c:253 >> #11 nss_atexit () at /usr/src/lib/libc/net/nsdispatch.c:578 >> #12 0x5028d958 in __cxa_finalize (dso=3D0x0) at = /usr/src/lib/libc/stdlib/atexit.c:240 >> #13 0x502117f8 in exit (status=3D0) at = /usr/src/lib/libc/stdlib/exit.c:74 >> #14 0x10013f9c in child_cleanup (signo=3D) at = /usr/src/usr.sbin/nfsd/nfsd.c:969 >> #15 >> #16 0x00000000 in ?? () >>=20 >> (gdb) up 3 >> #3 0x50206104 in sz_index2size_lookup (index=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/sz.h:200 >> 200 assert(ret =3D=3D sz_index2size_compute(index)); >>=20 >> (ret is optimized out.) >>=20 >> 197 JEMALLOC_ALWAYS_INLINE size_t >> 198 sz_index2size_lookup(szind_t index) { >> 199 size_t ret =3D (size_t)sz_index2size_tab[index]; >> 200 assert(ret =3D=3D sz_index2size_compute(index)); >> 201 return ret; >> 202 } >=20 > (gdb) print/x __je_sz_index2size_tab > $3 =3D {0x0 } >=20 > Also: >=20 > (gdb) x/4x __je_arenas+16368/4 > 0x5030cab0 <__je_arenas+16368>: 0x00000000 0x00000000 = 0x00000000 0x00000000 > (gdb) print/x __je_arenas_lock = =20= > $8 =3D {{{prof_data =3D {tot_wait_time =3D {ns =3D 0x0}, max_wait_time = =3D {ns =3D 0x0}, n_wait_times =3D 0x0, n_spin_acquired =3D 0x0, = max_n_thds =3D 0x0, n_waiting_thds =3D {repr =3D 0x0}, n_owner_switches = =3D 0x0,=20 > prev_owner =3D 0x0, n_lock_ops =3D 0x0}, lock =3D 0x0, = postponed_next =3D 0x0, locked =3D {repr =3D 0x0}}}, witness =3D {name =3D= 0x0, rank =3D 0x0, comp =3D 0x0, opaque =3D 0x0, link =3D {qre_next =3D = 0x0,=20 > qre_prev =3D 0x0}}, lock_order =3D 0x0} > (gdb) print/x __je_narenas_auto > $9 =3D 0x0 > (gdb) print/x malloc_conf =20 > $10 =3D 0x0 > (gdb) print/x __je_ncpus=20 > $11 =3D 0x0 > (gdb) print/x __je_manual_arena_base > $12 =3D 0x0 > (gdb) print/x __je_sz_pind2sz_tab =20 > $13 =3D {0x0 } > (gdb) print/x __je_sz_size2index_tab > $1 =3D {0x0 , 0x1a, 0x1b , 0x1c = } >=20 >> Booting and immediately trying something like: >>=20 >> service nfsd stop >>=20 >> did not lead to a failure. But may be after >> a while it would and be less drastic than a >> reboot or power down. >=20 > More detail: >=20 > So, for rpcbind and nfds at some point a large part of > __je_sz_size2index_tab is being stomped on, as is all of > __je_sz_index2size_tab and more. >=20 > For rpcbind, the following area is zero but in a > live process is not all-zero (I show the partially > non-zero live-process context instead of the all-zero > .core file content): >=20 > 0x5034cab0 <__je_arenas+16368>: 0x00000000 0x00000000 = 0x00000000 0x00000009 > 0x5034cac0 <__je_arenas_lock>: 0x00000000 0x00000000 = 0x00000000 0x00000000 > 0x5034cad0 <__je_arenas_lock+16>: 0x00000000 0x00000000 = 0x00000000 0x00000000 > 0x5034cae0 <__je_arenas_lock+32>: 0x00000000 0x00000000 = 0x00000000 0x00000000 > 0x5034caf0 <__je_arenas_lock+48>: 0x00000000 0x00000000 = 0x00000000 0x00000000 > 0x5034cb00 <__je_arenas_lock+64>: 0x00000000 0x5033f070 = 0x00000000 0x00000000 > 0x5034cb10 <__je_arenas_lock+80>: 0x5012bb04 0x00000003 = 0x00000000 0x00000000 > 0x5034cb20 <__je_arenas_lock+96>: 0x5034cb10 0x5034cb10 = 0x00000000 0x00000000 >=20 > Then the memory in the crash continues to be zero until: >=20 > 0x5034d000 <__je_sz_size2index_tab+384>: 0x1a1b1b1b = 0x1b1b1b1b 0x1b1b1b1b 0x1b1b1b1b >=20 > Notice the interesting page boundary for where non-zero > is first available again! >=20 > Between __je_arenas_lock and __je_sz_size2index_tab are: >=20 > 0x5034cb30 __je_narenas_auto > 0x5034cb38 malloc_conf > 0x5034cb3c __je_ncpus > 0x5034cb40 __je_manual_arena_base > 0x5034cb80 __je_sz_pind2sz_tab > 0x5034ccc0 __je_sz_index2size_tab > 0x5034ce80 __je_sz_size2index_tab >=20 > For nfsd, it is similar (again showing the partially > non-zero live process context instead of the all-zeros > from the .core file): >=20 > 0x5030cab0 <__je_arenas+16368>: 0x00000000 0x00000000 = 0x00000000 0x00000009 > 0x5030cac0 <__je_arenas_lock>: 0x00000000 0x00000000 = 0x00000000 0x00000000 > 0x5030cad0 <__je_arenas_lock+16>: 0x00000000 0x00000000 = 0x00000000 0x00000000 > 0x5030cae0 <__je_arenas_lock+32>: 0x00000000 0x00000000 = 0x00000000 0x00000000 > 0x5030caf0 <__je_arenas_lock+48>: 0x00000000 0x00000000 = 0x00000000 0x00000000 > 0x5030cb00 <__je_arenas_lock+64>: 0x00000000 0x502ff070 = 0x00000000 0x00000000 > 0x5030cb10 <__je_arenas_lock+80>: 0x500ebb04 0x00000003 = 0x00000000 0x00000000 > 0x5030cb20 <__je_arenas_lock+96>: 0x5030cb10 0x5030cb10 = 0x00000000 0x00000000 >=20 > Then the memory in the crash continues to be zero until: >=20 > 0x5030d000 <__je_sz_size2index_tab+384>: 0x1a1b1b1b = 0x1b1b1b1b 0x1b1b1b1b 0x1b1b1b1b >=20 > Notice the interesting page boundary for where non-zero > is first available again! >=20 > Between __je_arenas_lock and __je_sz_size2index_tab are: >=20 > 0x5030cb30 __je_narenas_auto > 0x5030cb38 malloc_conf > 0x5030cb3c __je_ncpus > 0x5030cb40 __je_manual_arena_base > 0x5030cb80 __je_sz_pind2sz_tab > 0x5030ccc0 __je_sz_index2size_tab > 0x5030ce80 __je_sz_size2index_tab >=20 >=20 > Note: because __je_arenas is normally > mostly zero for these contexts, I can > not tell where the memory trashing > started, only where it replaced non-zero > values with zeros. >=20 I got a mountd assert failure in sz_size2index_lookup while attempting __calloc during makefd_xprt. (gdb) bt #0 thr_kill () at thr_kill.S:4 #1 0x50301170 in __raise (s=3D6) at /usr/src/lib/libc/gen/raise.c:52 #2 0x50260cc0 in abort () at /usr/src/lib/libc/stdlib/abort.c:67 #3 0x5025e260 in sz_size2index_lookup (size=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/sz.h:159 #4 sz_size2index (size=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/sz.h:166 #5 imalloc_body (sopts=3D0xffffd000, dopts=3D0xffffcfe0, = tsd=3D0x50094018) at jemalloc_jemalloc.c:2066 #6 0x50253874 in imalloc (sopts=3D0xffffd000, dopts=3D0xffffcfe0) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/tsd.h:331 #7 0x50253fe8 in __calloc (num=3D1, size=3D96) at = jemalloc_jemalloc.c:2498 #8 0x50274690 in svc_xprt_alloc () at /usr/src/lib/libc/rpc/svc.c:541 #9 0x502725f4 in makefd_xprt (fd=3D10, sendsize=3D9000, recvsize=3D9000) = at /usr/src/lib/libc/rpc/svc_vc.c:250 #10 0x502734b4 in rendezvous_request (xprt=3D0x5007b120, msg=3D) at /usr/src/lib/libc/rpc/svc_vc.c:315 #11 0x50274a98 in svc_getreq_common (fd=3D) at = /usr/src/lib/libc/rpc/svc.c:640 #12 0x502748e0 in svc_getreqset (readfds=3D) at = /usr/src/lib/libc/rpc/svc.c:611 #13 0x1001434c in main (argc=3D, argv=3D0xffffde3c) at = /usr/src/usr.sbin/mountd/mountd.c:683 (gdb) up 3 #3 0x5025e260 in sz_size2index_lookup (size=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/sz.h:159 159 assert(ret =3D=3D sz_size2index_compute(size)); Again there is that area of memory that has been zeroed, with the same stopping point in __je_sz_size2index_tab: (gdb) print/x __je_narenas_auto $2 =3D 0x0 (gdb) print/x malloc_conf=20 $3 =3D 0x0 (gdb) print/x __je_ncpus $4 =3D 0x0 (gdb) print/x __je_manual_arena_base $5 =3D 0x0 (gdb) print/x __je_sz_pind2sz_tab $6 =3D {0x0 } (gdb) print/x __je_sz_size2index_tab $7 =3D {0x0 , 0x1a, 0x1b , 0x1c = } Showing where the zeroing stopped: . . . (gdb) x/156x __je_sz_size2index_tab 0x5035be80 <__je_sz_size2index_tab>: 0x00000000 0x00000000 = 0x00000000 0x00000000 0x5035be90 <__je_sz_size2index_tab+16>: 0x00000000 0x00000000 = 0x00000000 0x00000000 0x5035bea0 <__je_sz_size2index_tab+32>: 0x00000000 0x00000000 = 0x00000000 0x00000000 0x5035beb0 <__je_sz_size2index_tab+48>: 0x00000000 0x00000000 = 0x00000000 0x00000000 0x5035bec0 <__je_sz_size2index_tab+64>: 0x00000000 0x00000000 = 0x00000000 0x00000000 0x5035bed0 <__je_sz_size2index_tab+80>: 0x00000000 0x00000000 = 0x00000000 0x00000000 0x5035bee0 <__je_sz_size2index_tab+96>: 0x00000000 0x00000000 = 0x00000000 0x00000000 0x5035bef0 <__je_sz_size2index_tab+112>: 0x00000000 = 0x00000000 0x00000000 0x00000000 0x5035bf00 <__je_sz_size2index_tab+128>: 0x00000000 = 0x00000000 0x00000000 0x00000000 0x5035bf10 <__je_sz_size2index_tab+144>: 0x00000000 = 0x00000000 0x00000000 0x00000000 0x5035bf20 <__je_sz_size2index_tab+160>: 0x00000000 = 0x00000000 0x00000000 0x00000000 0x5035bf30 <__je_sz_size2index_tab+176>: 0x00000000 = 0x00000000 0x00000000 0x00000000 0x5035bf40 <__je_sz_size2index_tab+192>: 0x00000000 = 0x00000000 0x00000000 0x00000000 0x5035bf50 <__je_sz_size2index_tab+208>: 0x00000000 = 0x00000000 0x00000000 0x00000000 0x5035bf60 <__je_sz_size2index_tab+224>: 0x00000000 = 0x00000000 0x00000000 0x00000000 0x5035bf70 <__je_sz_size2index_tab+240>: 0x00000000 = 0x00000000 0x00000000 0x00000000 0x5035bf80 <__je_sz_size2index_tab+256>: 0x00000000 = 0x00000000 0x00000000 0x00000000 0x5035bf90 <__je_sz_size2index_tab+272>: 0x00000000 = 0x00000000 0x00000000 0x00000000 0x5035bfa0 <__je_sz_size2index_tab+288>: 0x00000000 = 0x00000000 0x00000000 0x00000000 0x5035bfb0 <__je_sz_size2index_tab+304>: 0x00000000 = 0x00000000 0x00000000 0x00000000 0x5035bfc0 <__je_sz_size2index_tab+320>: 0x00000000 = 0x00000000 0x00000000 0x00000000 0x5035bfd0 <__je_sz_size2index_tab+336>: 0x00000000 = 0x00000000 0x00000000 0x00000000 0x5035bfe0 <__je_sz_size2index_tab+352>: 0x00000000 = 0x00000000 0x00000000 0x00000000 0x5035bff0 <__je_sz_size2index_tab+368>: 0x00000000 = 0x00000000 0x00000000 0x00000000 0x5035c000 <__je_sz_size2index_tab+384>: 0x1a1b1b1b = 0x1b1b1b1b 0x1b1b1b1b 0x1b1b1b1b 0x5035c010 <__je_sz_size2index_tab+400>: 0x1b1b1b1b = 0x1b1b1b1b 0x1b1b1b1b 0x1b1b1b1b 0x5035c020 <__je_sz_size2index_tab+416>: 0x1b1b1b1b = 0x1b1b1b1b 0x1b1b1b1b 0x1b1b1b1b 0x5035c030 <__je_sz_size2index_tab+432>: 0x1b1b1b1b = 0x1b1b1b1b 0x1b1b1b1b 0x1b1b1b1b 0x5035c040 <__je_sz_size2index_tab+448>: 0x1b1c1c1c = 0x1c1c1c1c 0x1c1c1c1c 0x1c1c1c1c 0x5035c050 <__je_sz_size2index_tab+464>: 0x1c1c1c1c = 0x1c1c1c1c 0x1c1c1c1c 0x1c1c1c1c 0x5035c060 <__je_sz_size2index_tab+480>: 0x1c1c1c1c = 0x1c1c1c1c 0x1c1c1c1c 0x1c1c1c1c 0x5035c070 <__je_sz_size2index_tab+496>: 0x1c1c1c1c = 0x1c1c1c1c 0x1c1c1c1c 0x1c1c1c1c 0x5035c080 <__je_sz_size2index_tab+512>: 0x1c000000 = 0x00000000 0x50303474 0x00000000 0x5035c090: 0x00000000 0x00000000 0x00000000 = 0x00000000 0x5035c0a0: 0x00000000 0x00000000 0x00000000 = 0x00000000 0x5035c0b0: 0x00000000 0x00000000 0x00000000 = 0x00000000 0x5035c0c0: 0x00000000 0x00000000 0x00000000 = 0x00000000 0x5035c0d0: 0x00000000 0x00000000 0x00000000 = 0x00000000 0x5035c0e0: 0x00000000 0x00000000 0x00000000 = 0x00000000 Again: a nice page boundary: 0x5035c000 for where the zeros stop. Note that, despite the address ranges shifting around between programs, the same global variables are being stomped on, stopping at the same index into __je_sz_size2index_tab in each of the 3 programs. It always is page aligned there in my context. (The sshd example is different. I've yet to explore it much.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-ppc@freebsd.org Thu May 7 23:19:46 2020 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 A899D2E86EF for ; Thu, 7 May 2020 23:19:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49J8Yt41K5z3PPZ for ; Thu, 7 May 2020 23:19:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by freefall.freebsd.org (Postfix) id 720CF1B7D8; Thu, 7 May 2020 23:19:46 +0000 (UTC) Delivered-To: powerpc@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id 557321BA2E for ; Thu, 7 May 2020 23:19:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49J8Yt0fnvz3PPV for ; Thu, 7 May 2020 23:19:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 11DB520D3F for ; Thu, 7 May 2020 23:19:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 047NJj7O055301 for ; Thu, 7 May 2020 23:19:45 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 047NJjgO055300 for powerpc@FreeBSD.org; Thu, 7 May 2020 23:19:45 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: powerpc@FreeBSD.org Subject: [Bug 245511] lang/gcc9: build with base GCC on powerpc64 elfv1 Date: Thu, 07 May 2020 23:19:46 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: buildisok X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: gerald@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: gerald@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2020 23:19:46 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D245511 --- Comment #17 from Gerald Pfeifer --- (In reply to Piotr Kubaj from comment #16) > If you suggest there might be new build errors for some ports getting=20 > built with gcc9, there are none now. Interesting, given how broken that bootstrap compiler appears to be. > And I don't think the quality of gcc9-generated binaries will regress. It definitely will in terms of target libraries. That is what CFLAGS_FOR_TARGET=3D"-O0" CXXFLAGS_FOR_TARGET=3D"-O0" does. Thank you for sharing those snippets from the various build attempts. It appears they all fail in stage 1, trying to build target libraries. So ideally we'd need to only tone down everything related to stage 1 - unlike the current patch which tones down the target libraries in stage 3 even and all the other stage1-3 compilers as well - I just am not sure how to go about that.=20 Looking at the first attempt, where you noted STAGE1_TFLAGS=3D"-O0", it appears the compiler invocation was effectively done with -O2. I am wondering whether setting STAGE1_CFLAGS and STAGE1_CXXFLAGS might help. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-ppc@freebsd.org Thu May 7 23:37:49 2020 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 70DDB2E8E5E for ; Thu, 7 May 2020 23:37:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49J8yj2Lt9z3QTx for ; Thu, 7 May 2020 23:37:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by freefall.freebsd.org (Postfix) id 2B0321BC57; Thu, 7 May 2020 23:37:49 +0000 (UTC) Delivered-To: powerpc@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [96.47.72.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id 278AA1BBC7 for ; Thu, 7 May 2020 23:37:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49J8yh6XvCz3QTt for ; Thu, 7 May 2020 23:37:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id D7BC22110F for ; Thu, 7 May 2020 23:37:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 047NbmS6035501 for ; Thu, 7 May 2020 23:37:48 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 047Nbm7N035500 for powerpc@FreeBSD.org; Thu, 7 May 2020 23:37:48 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: powerpc@FreeBSD.org Subject: [Bug 245511] lang/gcc9: build with base GCC on powerpc64 elfv1 Date: Thu, 07 May 2020 23:37:49 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: buildisok X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: pkubaj@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: gerald@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2020 23:37:49 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D245511 --- Comment #18 from Piotr Kubaj --- I will test that later today since my Talos is currently busy. BTW, since you are much more knowledgeable than me about this - you could t= ry compiling this on ref12-ppc64. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-ppc@freebsd.org Thu May 7 23:52:07 2020 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 415802E92CC for ; Thu, 7 May 2020 23:52:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49J9HC14xsz3R88 for ; Thu, 7 May 2020 23:52:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by freefall.freebsd.org (Postfix) id 196C71BDE3; Thu, 7 May 2020 23:52:07 +0000 (UTC) Delivered-To: powerpc@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [96.47.72.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id 16FD91BDE2 for ; Thu, 7 May 2020 23:52:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49J9HB62q3z3R84 for ; Thu, 7 May 2020 23:52:06 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id CAF002137A for ; Thu, 7 May 2020 23:52:06 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 047Nq6iY073439 for ; Thu, 7 May 2020 23:52:06 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 047Nq67e073438 for powerpc@FreeBSD.org; Thu, 7 May 2020 23:52:06 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: powerpc@FreeBSD.org Subject: [Bug 245511] lang/gcc9: build with base GCC on powerpc64 elfv1 Date: Thu, 07 May 2020 23:52:06 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: buildisok X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: pkubaj@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: gerald@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2020 23:52:07 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D245511 --- Comment #19 from Piotr Kubaj --- OK, since one of Poudriere jobs finished, I'm setting it to run for the nig= ht. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-ppc@freebsd.org Fri May 8 08:50:07 2020 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 230632D0F6C for ; Fri, 8 May 2020 08:50:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49JPCx1Zpfz4SXl for ; Fri, 8 May 2020 08:50:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by freefall.freebsd.org (Postfix) id 4C93C2F45; Fri, 8 May 2020 08:50:03 +0000 (UTC) Delivered-To: powerpc@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id DF7ED2FB4 for ; Fri, 8 May 2020 08:50:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49JPCr0Cyfz4ST0 for ; Fri, 8 May 2020 08:49:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 7007027918 for ; Fri, 8 May 2020 08:49:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 0488nvYG038013 for ; Fri, 8 May 2020 08:49:57 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 0488nvav038012 for powerpc@FreeBSD.org; Fri, 8 May 2020 08:49:57 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: powerpc@FreeBSD.org Subject: [Bug 245511] lang/gcc9: build with base GCC on powerpc64 elfv1 Date: Fri, 08 May 2020 08:49:57 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: buildisok X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: pkubaj@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: gerald@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.32 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2020 08:50:07 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D245511 --- Comment #20 from Piotr Kubaj --- I set STAGE1_CFLAGS=3D"-O0" STAGE1_CXXFLAGS=3D"-O0" in MAKE_ARGS and removed CFLAGS_FOR_TARGET=3D"-O0" CXXFLAGS_FOR_TARGET=3D"-O0". Build still fails an= d I can see -O0 is not passed: gmake[6]: Entering directory '/wrkdirs/usr/ports/lang/gcc9/work/.build/powerpc64-portbld-freebsd12.1/32/= libgcc' # If this is the top-level multilib, build all the other # multilibs. /wrkdirs/usr/ports/lang/gcc9/work/.build/./gcc/xgcc -B/wrkdirs/usr/ports/lang/gcc9/work/.build/./gcc/ -B/usr/local/powerpc64-portbld-freebsd12.1/bin/ -B/usr/local/powerpc64-portbld-freebsd12.1/lib/ -isystem /usr/local/powerpc64-portbld-freebsd12.1/include -isystem /usr/local/powerpc64-portbld-freebsd12.1/sys-include -fno-checking -g -O2 -pipe -DLIBICONV_PLUG -fno-strict-aliasing -m32 -fPIC -mstrict-align -O2 -g -O2 -pipe -DLIBICONV_PLUG -fno-strict-aliasing -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wno-format -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -pthread -mno-minimal-toc -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fPIC -pthread -mno-minimal-toc -I. -I. -I../../../.= /gcc -I/wrkdirs/usr/ports/lang/gcc9/work/gcc-9.3.0/libgcc -I/wrkdirs/usr/ports/lang/gcc9/work/gcc-9.3.0/libgcc/. -I/wrkdirs/usr/ports/lang/gcc9/work/gcc-9.3.0/libgcc/../gcc -I/wrkdirs/usr/ports/lang/gcc9/work/gcc-9.3.0/libgcc/../include -DHAVE_CC_= TLS=20 -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c /wrkdirs/usr/ports/lang/gcc9/work/gcc-9.3.0/libgcc/libgcc2.c -fvisibility=3Dhidden -DHIDE_EXPORTS during GIMPLE pass: store-merging In file included from /wrkdirs/usr/ports/lang/gcc9/work/gcc-9.3.0/libgcc/libgcc2.c:56: /wrkdirs/usr/ports/lang/gcc9/work/gcc-9.3.0/libgcc/libgcc2.c: In function '__muldi3': /wrkdirs/usr/ports/lang/gcc9/work/gcc-9.3.0/libgcc/libgcc2.h:219:20: intern= al compiler error: Segmentation fault 219 | #define __NDW(a,b) __ ## a ## di ## b | ^~ /wrkdirs/usr/ports/lang/gcc9/work/gcc-9.3.0/libgcc/libgcc2.h:273:18: note: = in expansion of macro '__NDW' 273 | #define __muldi3 __NDW(mul,3) | ^~~~~ /wrkdirs/usr/ports/lang/gcc9/work/gcc-9.3.0/libgcc/libgcc2.c:548:1: note: in expansion of macro '__muldi3' 548 | __muldi3 (DWtype u, DWtype v) | ^~~~~~~~ no stack trace because unwind library not available Please submit a full bug report, with preprocessed source if appropriate. See for instructions. gmake[6]: *** [Makefile:498: _muldi3.o] Error 1 gmake[6]: Leaving directory '/wrkdirs/usr/ports/lang/gcc9/work/.build/powerpc64-portbld-freebsd12.1/32/= libgcc' gmake[5]: *** [Makefile:1210: multi-do] Error 1 gmake[5]: Leaving directory '/wrkdirs/usr/ports/lang/gcc9/work/.build/powerpc64-portbld-freebsd12.1/lib= gcc' gmake[4]: *** [Makefile:127: all-multi] Error 2 gmake[4]: Leaving directory '/wrkdirs/usr/ports/lang/gcc9/work/.build/powerpc64-portbld-freebsd12.1/lib= gcc' gmake[3]: *** [Makefile:17170: all-stage1-target-libgcc] Error 2 gmake[3]: Leaving directory '/wrkdirs/usr/ports/lang/gcc9/work/.build' gmake[2]: *** [Makefile:22474: stage1-bubble] Error 2 gmake[2]: Leaving directory '/wrkdirs/usr/ports/lang/gcc9/work/.build' gmake[1]: *** [Makefile:22806: bootstrap-lean] Error 2 gmake[1]: Leaving directory '/wrkdirs/usr/ports/lang/gcc9/work/.build' *** Error code 1 root@powerpc64-121-default:/usr/ports/lang/gcc9 # grep MAKE_ARGS Makefile MAKE_ARGS+=3D STAGE1_CFLAGS=3D"-O0" STAGE1_CXXFLAGS=3D"-O0" BOOT_CFLAGS=3D"-O0" --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-ppc@freebsd.org Fri May 8 09:29:07 2020 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 D01172D2BA7 for ; Fri, 8 May 2020 09:29:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49JQ4z5C3Fz4Xjj for ; Fri, 8 May 2020 09:29:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by freefall.freebsd.org (Postfix) id 8F8AB48DB; Fri, 8 May 2020 09:29:07 +0000 (UTC) Delivered-To: powerpc@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id 8940148DA for ; Fri, 8 May 2020 09:29:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49JQ4z28s9z4Xjf for ; Fri, 8 May 2020 09:29:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 41351F8 for ; Fri, 8 May 2020 09:29:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 0489T712018731 for ; Fri, 8 May 2020 09:29:07 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 0489T6p8018730 for powerpc@FreeBSD.org; Fri, 8 May 2020 09:29:06 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: powerpc@FreeBSD.org Subject: [Bug 245511] lang/gcc9: build with base GCC on powerpc64 elfv1 Date: Fri, 08 May 2020 09:29:07 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: buildisok X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: pkubaj@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: gerald@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.32 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2020 09:29:07 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D245511 --- Comment #21 from Piotr Kubaj --- I also tried adding CONFIGURE_ARGS+=3D--with-stage1-cflags=3D"-O0", but that doesn't help. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-ppc@freebsd.org Fri May 8 16:14:34 2020 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 64B192DB642 for ; Fri, 8 May 2020 16:14:34 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-20.consmr.mail.gq1.yahoo.com (sonic306-20.consmr.mail.gq1.yahoo.com [98.137.68.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49Jb4m2wcTz40mW for ; Fri, 8 May 2020 16:14:32 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: TVENuvoVM1n_zA_0fs6Z719DKccdLvBZKI4IF2arNLX_N4maUdk63_v7VCedtYw kKmDxIpX7OF5E6wicfhOXIHMkD7lDSBRJFGS_kqn447wUaref25ZfPYh4YEESAzPpA2rIsETZB3z FYvkZLf5Po8MZyT3KX6Cain4buVLJUUhDIkLbXksSeWUo51VxQJMV3C6fCuJu6nWndqmA4Qh1mTt XMLaHVA8E9GNT_PfDLNvZKcnGbANy5qhCfkmZ4LOEF_GyAwAuZ1aHHwY4GOgyyoND1NHNxa04rat NulF6Fool9duKR9UmGva60q4Gl0HmRxyNNKQN253LMyOVhNlZ0B1iRkkEqig4JqhdM_aHxu0iktm AnoAodoa.Ws3BKJogkqMMnXCv91vkDRVyuxh7FDK3uf1SqN_2x9C_UpWLfrkwAET.ydd4aJEVT0N Jbz1FrB9uo8yq5KeD_uNskh1N2rHXtc30BDQOzrqsRDKcyZvcK3XcLvW6NMtMlM0UF5gHMNAA5uH 23SQcUX_sHjsarQTcf8.orhY4Xane0WX0kMO_QrZTnT00PQrlrGn0.GdH6_o8zwEAG.xcsFSLgTT _.yybkiZ.p3hwwxvTQEJWfzdQQDpj0FQcRE9gtcU8ONPqCXCZM14u73ArBF1F7dFJ8lEEru25dR5 0vErXFnRDQs.kxzebK4TWqJe24GHRSXhvLpALkZgqUp.BNqakGjSg97Y3OvQPdmLQAoPG_1S.Cje Hk9FfmYnXohSWqwBtfBgRzhd13NCi_uztl8yy2zdHs9e19MEuf8AvhwIX2AgBgSnRgde45zygkYH y.gPaQ8GewxsVdScud1nCUICCM1ACyu1IxRqZvu3QDrsoqhx5C3mTnYcvxZbAoC5QEoJ.1i3aIWy 4ooOqAK0xXFAp1VVpr3zp99dzwDc0PdtY3l6ar7sMa_uBpDCLaBry2ZCzQQmErOYj5_jeg0HH_sK 5mVHAUngzgcF_GJv29m7NC3viQH16l.e0mLx70pJv4goQuGhC_JoT9re8DZq3o9sbJIYTiTve8G9 xAqAgkZJUXQoPqkQD9bcr3cgUNMH3XCF55R0wJoH7TFpx5vYUZ3Qu4.DatFyku_ISXHer15cnlXN ThYqGhAVjHZ_cPf1N7EjWDuJxl6vtPrxbLgNPYG5eVrBVb0Y8meyYv9e9nPlCEYkPWDdGcVd8gvB Z77cDzOsF3Q8d0OJsBRBPyLjgMydpRbaffFyT0fAD22FU8rjdidlFmPmf9orIe6fRLZK4RKZh.gr rMRj5aMwaDpfT4G4KLlY9X.vCUNZ4eZasZkWtUnhoaq0ReXMJXFtCiWwEr3q_b9coYIqliudGjWR 7aUsa6GVnP53AU6aTKEurLaKhBF8tyndHLlpg8KVBobgq3YhFzOOsLv.rikJwACuuuc0eZlQh5rN TrcgPmggrtVjMJg_b2OXVrlBnJDEfhbGt0Tm_3IEz6t3qTdCQCG7XB7_ObBwezDw- Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Fri, 8 May 2020 16:14:30 +0000 Received: by smtp421.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID f4875cfc9e4acaebf3d65b4cfeaaba16; Fri, 08 May 2020 16:14:26 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: svn commit: r360233 - in head: contrib/jemalloc . . . : This partially breaks a 2-socket 32-bit powerpc (old PowerMac G4) based on head -r360311 From: Mark Millard In-Reply-To: Date: Fri, 8 May 2020 09:14:24 -0700 Cc: Brandon Bergren , Justin Hibbits Content-Transfer-Encoding: quoted-printable Message-Id: <624CE71B-2C50-4E77-85A2-42D9FA140AD0@yahoo.com> References: <8479DD58-44F6-446A-9CA5-D01F0F7C1B38@yahoo.com> <17ACDA02-D7EF-4F26-874A-BB3E935CD072@yahoo.com> <695E6836-F860-4557-B7DE-CC1EDB347F18@yahoo.com> <121B9B09-141B-4DC3-918B-1E7CFB99E779@yahoo.com> <8AAB0462-3FA8-490C-8D8D-7C15B1C9E2DE@yahoo.com> <18E62746-80DB-4195-977D-4FF32D0129EE@yahoo.com> To: "vangyzen@freebsd.org" , svn-src-head@freebsd.org, FreeBSD Current , FreeBSD Hackers , FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49Jb4m2wcTz40mW X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.40 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCPT_COUNT_SEVEN(0.00)[7]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.93)[-0.926,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.97)[-0.970,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ip: (2.91), ipnet: 98.137.64.0/21(0.83), asn: 36647(0.66), country: US(-0.05)]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[83.68.137.98.list.dnswl.org : 127.0.5.0]; RWL_MAILSPIKE_POSSIBLE(0.00)[83.68.137.98.rep.mailspike.net : 127.0.0.17]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.32 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2020 16:14:34 -0000 [More details for a sshd failure. The other examples are omitted. The sshd failure also shows a all-zeros-up-to-a-page-boundary issue, just for a different address range.] On 2020-May-7, at 12:06, Mark Millard wrote: >=20 > [mountd failure example: also at sz_size2index_lookup assert > for the same zero'd memory problem.] >=20 >> On 2020-May-7, at 00:46, Mark Millard wrote: >>=20 >> [__je_sz_size2index_tab seems messed up in 2 of the >> asserting contexts: first 384 are zero in both. More >> before that is also messed up (all zero). I show the >> details later below.] >>=20 >> On 2020-May-6, at 16:57, Mark Millard wrote: >>=20 >>> [This explores process crashes that happen during system >>> shutdown, in a context not having MALLOC_PRODUCTION=3D . >>> So assert failures are reported as the stopping points.] >>>=20 >>> It looks like shutdown -p now, shutdown -r now, and the >>> like can lead some processes to assert during their exit >>> attempt, including a sshd failure (that I've not seen >>> before), rpcbind, and nfsd. I show information about the >>> observed asserts for those below. >>>=20 >>>=20 >>> sshd hit an assert, failing slab =3D=3D extent_slab_get(extent) : >>>=20 >>> (gdb) bt=20 >>> #0 thr_kill () at thr_kill.S:4 >>> #1 0x50927170 in __raise (s=3D6) at = /usr/src/lib/libc/gen/raise.c:52 >>> #2 0x50886cc0 in abort () at /usr/src/lib/libc/stdlib/abort.c:67 >>> #3 0x508834b0 in arena_dalloc (tsdn=3D, = ptr=3D, tcache=3D, alloc_ctx=3D, slow_path=3D) >>> at = /usr/src/contrib/jemalloc/include/jemalloc/internal/arena_inlines_b.h:315 >>> #4 idalloctm (tsdn=3D0x500dd040, ptr=3D0x5008a180, = tcache=3D0x500dd160, alloc_ctx=3D, is_internal=3D, slow_path=3D) >>> at = /usr/src/contrib/jemalloc/include/jemalloc/internal/jemalloc_internal_inli= nes_c.h:118 >>> #5 0x5087b0a4 in ifree (tsd=3D0x500dd040, ptr=3D0x5008a180, = tcache=3D0x500dd160, slow_path=3D) at = jemalloc_jemalloc.c:2590 >>> #6 0x5087acac in __je_free_default (ptr=3D0x5008a180) at = jemalloc_jemalloc.c:2784 >>> #7 0x5087b294 in __free (ptr=3D0x5008a180) at = jemalloc_jemalloc.c:2852 >>> #8 0x10029464 in server_accept_loop (config_s=3D, = sock_in=3D, sock_out=3D, = newsock=3D) at /usr/src/crypto/openssh/sshd.c:1185 >>> #9 main (ac=3D, av=3D0xffffde3c) at = /usr/src/crypto/openssh/sshd.c:2009 >>>=20 >>> . . . >>> (gdb) up >>> #2 0x50886cc0 in abort () at /usr/src/lib/libc/stdlib/abort.c:67 >>> 67 (void)raise(SIGABRT); >>> (gdb) up >>> #3 0x508834b0 in arena_dalloc (tsdn=3D, = ptr=3D, tcache=3D, alloc_ctx=3D, slow_path=3D) >>> at = /usr/src/contrib/jemalloc/include/jemalloc/internal/arena_inlines_b.h:315 >>> 315 assert(slab =3D=3D extent_slab_get(extent)); >>>=20 >>> (gdb) list >>> 310 rtree_ctx =3D tsd_rtree_ctx(tsdn_tsd(tsdn)); >>> 311 extent_t *extent =3D rtree_extent_read(tsdn, = &extents_rtree, >>> 312 rtree_ctx, (uintptr_t)ptr, true); >>> 313 assert(szind =3D=3D extent_szind_get(extent)); >>> 314 assert(szind < SC_NSIZES); >>> 315 assert(slab =3D=3D extent_slab_get(extent)); >>> 316 } >>> 317=09 >>> 318 if (likely(slab)) { >>> 319 /* Small allocation. */ >>>=20 >>> More fully: >>>=20 >>> 285 JEMALLOC_ALWAYS_INLINE void >>> 286 arena_dalloc(tsdn_t *tsdn, void *ptr, tcache_t *tcache, >>> 287 alloc_ctx_t *alloc_ctx, bool slow_path) { >>> 288 assert(!tsdn_null(tsdn) || tcache =3D=3D NULL); >>> 289 assert(ptr !=3D NULL); >>> 290=09 >>> 291 if (unlikely(tcache =3D=3D NULL)) { >>> 292 arena_dalloc_no_tcache(tsdn, ptr); >>> 293 return; >>> 294 } >>> 295=09 >>> 296 szind_t szind; >>> 297 bool slab; >>> 298 rtree_ctx_t *rtree_ctx; >>> 299 if (alloc_ctx !=3D NULL) { >>> 300 szind =3D alloc_ctx->szind; >>> 301 slab =3D alloc_ctx->slab; >>> 302 assert(szind !=3D SC_NSIZES); >>> 303 } else { >>> 304 rtree_ctx =3D tsd_rtree_ctx(tsdn_tsd(tsdn)); >>> 305 rtree_szind_slab_read(tsdn, &extents_rtree, = rtree_ctx, >>> 306 (uintptr_t)ptr, true, &szind, &slab); >>> 307 } >>> 308=09 >>> 309 if (config_debug) { >>> 310 rtree_ctx =3D tsd_rtree_ctx(tsdn_tsd(tsdn)); >>> 311 extent_t *extent =3D rtree_extent_read(tsdn, = &extents_rtree, >>> 312 rtree_ctx, (uintptr_t)ptr, true); >>> 313 assert(szind =3D=3D extent_szind_get(extent)); >>> 314 assert(szind < SC_NSIZES); >>> 315 assert(slab =3D=3D extent_slab_get(extent)); >>> 316 } >>> 317=09 >>> 318 if (likely(slab)) { >>> 319 /* Small allocation. */ >>> 320 tcache_dalloc_small(tsdn_tsd(tsdn), tcache, ptr, = szind, >>> 321 slow_path); >>> 322 } else { >>> 323 arena_dalloc_large(tsdn, ptr, tcache, szind, = slow_path); >>> 324 } >>> 325 } >>=20 >> . . . The machine code for: 309 if (config_debug) { 310 rtree_ctx =3D tsd_rtree_ctx(tsdn_tsd(tsdn)); 311 extent_t *extent =3D rtree_extent_read(tsdn, = &extents_rtree, 312 rtree_ctx, (uintptr_t)ptr, true); 313 assert(szind =3D=3D extent_szind_get(extent)); 314 assert(szind < SC_NSIZES); 315 assert(slab =3D=3D extent_slab_get(extent)); 316 } was dropping the address in "extent" the next instruction after finding it: replacing with with a field's value. So by the time the status of the assert could be known, examining extent was a difficulty. So I touched the source code to force the address to be kept and to give a place to breakpoint on failure before calling another routine: # svnlite diff = /usr/src/contrib/jemalloc/include/jemalloc/internal/arena_inlines_b.h Index: = /usr/src/contrib/jemalloc/include/jemalloc/internal/arena_inlines_b.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- = /usr/src/contrib/jemalloc/include/jemalloc/internal/arena_inlines_b.h = (revision 360322) +++ = /usr/src/contrib/jemalloc/include/jemalloc/internal/arena_inlines_b.h = (working copy) @@ -308,11 +308,11 @@ =20 if (config_debug) { rtree_ctx =3D tsd_rtree_ctx(tsdn_tsd(tsdn)); - extent_t *extent =3D rtree_extent_read(tsdn, = &extents_rtree, + extent_t * volatile extent =3D rtree_extent_read(tsdn, = &extents_rtree, rtree_ctx, (uintptr_t)ptr, true); assert(szind =3D=3D extent_szind_get(extent)); assert(szind < SC_NSIZES); - assert(slab =3D=3D extent_slab_get(extent)); + assert((slab =3D=3D extent_slab_get(extent)) ?true = :extent=3D=3DNULL); } =20 if (likely(slab)) { The ":extent=3D=3DNULL" should be guaranteed to produce :false as a = result but with more code involved to get there. It gave me a place to = breakpoint on failure. (gdb) bt -full #0 0x50883258 in arena_dalloc (tsdn=3D, ptr=3D, tcache=3D, alloc_ctx=3D, = slow_path=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/arena_inlines_b.h:315 extent =3D 0x51007fc0 slab =3D szind =3D rtree_ctx =3D 0x500dd06c extent =3D #1 idalloctm (tsdn=3D0x500dd040, ptr=3D0x5008a180, tcache=3D0x500dd160, = alloc_ctx=3D, is_internal=3D, = slow_path=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/jemalloc_internal_inli= nes_c.h:118 No locals. #2 0x5087b0e4 in ifree (tsd=3D0x500dd040, ptr=3D0x5008a180, = tcache=3D0x500dd160, slow_path=3D) at = jemalloc_jemalloc.c:2590 alloc_ctx =3D {szind =3D 0, slab =3D true} rtree_ctx =3D usize =3D #3 0x5087acec in __je_free_default (ptr=3D0x5008a180) at = jemalloc_jemalloc.c:2784 tcache =3D 0x500dd160 tsd =3D #4 0x5087b2d4 in __free (ptr=3D0x5008a180) at jemalloc_jemalloc.c:2852 log_var =3D log_var =3D #5 0x10029464 in server_accept_loop (config_s=3D, = sock_in=3D, sock_out=3D, = newsock=3D) at /usr/src/crypto/openssh/sshd.c:1185 from =3D {ss_len =3D 16 '\020', ss_family =3D 2 '\002', = __ss_pad1 =3D "\317\200\300\250\001\031", __ss_align =3D 0,=20 __ss_pad2 =3D "\000\000\000\000\000\000\000\002Am", '\000' = , "\065\341I\000\000\000\000^\264\234\331", '\000' = , = "^\262\027\034-a\241H\000\000\000\000\000\000\000\000^\264\235Y,\024\247\0= 30\000\000\000\000\000\000\000\000V\312\331f6-N\370\000\000\000\000\000\00= 0\000\000\000\000\002\000\000\000\000\000\000\000\000\b"} rnd =3D '\000' startup_p =3D {6, 7} startups =3D 1 i =3D maxfd =3D 6 fdset =3D fromlen =3D ret =3D j =3D pid =3D laddr =3D raddr =3D #6 main (ac=3D, av=3D0xffffde3c) at = /usr/src/crypto/openssh/sshd.c:2009 config_s =3D {8, 9} on =3D 1 ssh =3D 0x0 logfile =3D newsock =3D -1 sock_out =3D -1 sock_in =3D -1 connection_info =3D i =3D opt =3D line =3D r =3D key =3D pubkey =3D keytype =3D fp =3D j =3D new_umask =3D already_daemon =3D remote_port =3D remote_ip =3D rdomain =3D --Type for more, q to quit, c to continue without paging-- laddr =3D authctxt =3D obytes =3D ibytes =3D (gdb) list 310 rtree_ctx =3D tsd_rtree_ctx(tsdn_tsd(tsdn)); 311 extent_t * volatile extent =3D = rtree_extent_read(tsdn, &extents_rtree, 312 rtree_ctx, (uintptr_t)ptr, true); 313 assert(szind =3D=3D extent_szind_get(extent)); 314 assert(szind < SC_NSIZES); 315 assert((slab =3D=3D extent_slab_get(extent)) = ?true :extent=3D=3DNULL); 316 } 317=09 318 if (likely(slab)) { 319 /* Small allocation. */ (gdb) print/x extent $6 =3D 0x51007fc0 (gdb) print/x *extent $2 =3D {e_bits =3D 0x0, e_addr =3D 0x0, {e_size_esn =3D 0x0, e_bsize =3D = 0x0}, ql_link =3D {qre_next =3D 0x0, qre_prev =3D 0x0}, ph_link =3D = {phn_prev =3D 0x0, phn_next =3D 0x0, phn_lchild =3D 0x0}, {e_slab_data =3D= { bitmap =3D {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0xffffffff, 0xffffffff, = 0xffffffff, 0xffffffff, 0xffffffff, 0xffffffff, 0xffffffff, 0xffffffff, = 0xffffffff, 0xffffffff, 0xfff8}}, {e_alloc_time =3D { ns =3D 0x0}, e_prof_tctx =3D {repr =3D 0x0}}}} It looks like the prefix of the above has been stomped on to be zeros. Checking addresses as well: (gdb) x/64x extent 0x51007fc0: 0x00000000 0x00000000 0x00000000 = 0x00000000 0x51007fd0: 0x00000000 0x00000000 0x00000000 = 0x00000000 0x51007fe0: 0x00000000 0x00000000 0x00000000 = 0x00000000 0x51007ff0: 0x00000000 0x00000000 0x00000000 = 0x00000000 0x51008000: 0xffffffff 0xffffffff 0xffffffff = 0xffffffff 0x51008010: 0xffffffff 0xffffffff 0xffffffff = 0xffffffff 0x51008020: 0xffffffff 0xffffffff 0x0000fff8 = 0x00000000 0x51008030: 0x00000000 0x00000000 0x00000000 = 0x00000000 0x51008040: 0x00000800 0x0014f000 0x5008b000 = 0x00005000 0x51008050: 0x51008040 0x51008040 0x00000000 = 0x00000000 0x51008060: 0x00000000 0x00000000 0x00000000 = 0x00000000 0x51008070: 0x00000000 0x00000000 0x00000000 = 0x00000000 0x51008080: 0x00000000 0x00000000 0x00000000 = 0x00000000 0x51008090: 0x00000000 0x00000000 0x00000000 = 0x00000000 0x510080a0: 0x00000000 0x00000000 0x00000000 = 0x00000000 0x510080b0: 0x00000000 0x00000000 0x00000000 = 0x00000000 Note that the non-zero values start at: 0x51008000, again a page boundary, like the other examples in prior notes for other cases. This appears to be another example of memory having been stomped on/replaced that likely previously had the intended values. The first prior non-zero values are at: 0x51005a30: 0x00000000 0x51008740 0x0000000f = 0x01000000 0x51005a40: 0x51008740 0x0000000f 0x01000000 = 0x51008740 0x51005a50: 0x0000000f 0x01000000 0x51008740 = 0x0000000f 0x51005a60: 0x01000000 0x51008740 0x0000000f = 0x01000000 0x51005a70: 0x51008740 0x0000000f 0x01000000 = 0x51008740 0x51005a80: 0x0000000f 0x01000000 0x51008940 = 0x00000014 0x51005a90: 0x01000000 0x510089c0 0x00000014 = 0x01000000 0x51005aa0: 0x51008a40 0x00000018 0x01000000 = 0x51008ac0 0x51005ab0: 0x00000018 0x01000000 0x51008b40 = 0x00000018 0x51005ac0: 0x01000000 0x51008bc0 0x00000018 = 0x01000000 0x51005ad0: 0x51008c40 0x00000018 0x01000000 = 0x51008cc0 0x51005ae0: 0x00000001 0x01000000 0x00000000 = 0x00000000 So the pages for address ranges 0x51006yyy and 0x51007yyy seem to be all-zero, along with the tail of the page for the range 0x51005yyy. #2 (ifree) in the backtrace shows the alloc_ctx content: alloc_ctx =3D {szind =3D 0, slab =3D true} So slab=3D=3Dtrue but the bit in extent->e_bits=3D=3Dfalse, leading to the failed assert. Before going to sleep for the night, I could ssh into the old PowerMac without this detection. After getting up, trying the same got the failure detection. I did not have the machine doing anything else special between. The other examples in the other programs are similar: just waiting long enough with normal background processing going on eventually leads to the context for the next explicit use (or exit) to detect the problem. I'm still no where near identifying when the stomped-on memory range is trashed with zeros in code terms in any example program. But sshd, dhclient, rpcbind, nfsd, and sendmail all seem to have some common subject area(s) involved in their implementation. So I suspect something common across those is essentially involved. For reference: In #0: (gdb) print/x rtree_ctx $5 =3D 0x500dd06c (gdb) print/x *rtree_ctx $4 =3D {cache =3D {{leafkey =3D 0x50000000, leaf =3D 0x51004fc0}, = {leafkey =3D 0x1, leaf =3D 0x0}, {leafkey =3D 0x1, leaf =3D 0x0}, = {leafkey =3D 0x50c00000, leaf =3D 0x51008dc0}, {leafkey =3D 0x1,=20 leaf =3D 0x0} }, l2_cache =3D {{leafkey =3D 0x1, = leaf =3D 0x0}, {leafkey =3D 0x1, leaf =3D 0x0}, {leafkey =3D 0x1, leaf =3D= 0x0}, {leafkey =3D 0x1, leaf =3D 0x0}, {leafkey =3D 0x1, leaf =3D 0x0}, = { leafkey =3D 0x1, leaf =3D 0x0}, {leafkey =3D 0x1, leaf =3D 0x0}, = {leafkey =3D 0x1, leaf =3D 0x0}}} =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 May 9 03:58:10 2020 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 133032DB532 for ; Sat, 9 May 2020 03:58:10 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-23.consmr.mail.gq1.yahoo.com (sonic304-23.consmr.mail.gq1.yahoo.com [98.137.68.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49Jthb6Sfpz4Bwk for ; Sat, 9 May 2020 03:58:07 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: s0_eZEgVM1kntVEPp5zUb2Pq16aoJ1O8ool0YjqYxqXmvYgL8PHMFtmIwpbNfpG pxKFMBhV3sd28Fx3ufO1P5mYcQLHKDE1m5CZzhFzyJBBMzzHtBfxBLVnqAWkMyyAuZmqZ2ScnjMj cxVGWsQGfYur.9Ku7XZW._hrh8RLnFRQCF01D.moEPnPC0WTgKFm_GXn7SYkq6.Pg6C90yZDMjqw Vtib5SySCCLgrjLLrOua8o8Uh7FLsJFZygoKZytO0hCCStPuAaW._U0kSIRb92mwxPouIJHkvBr_ nhGADpZV5WmJ0Leor8z1Ku2dfqMpuFWQDd4zljLTUQpkYSKM7TBGNXLF8WE7Q8k41QyVZecMRvN9 Ufxzs78oOVrOELk6f0Ia71uSXshU6WRWmq2jMlAZhNeZVQpGnOHOPPqL9W1ZHhiUc27yY.lE1etw QWnCahLz9ApGIXMgeyzuhnosN517oR728w6YmL2gckxVaz4XSt.gfnz0ZqwBCWsazBp.7IfcI0bR b6FzhWhZCJiveX4tnkrTfGRyKRLiyT4k.S1uNWeI8.NQpRaCsA.NYPNTYqMt_Kht2TllSaWodXbH qSCyfW3o3azjKBGB5UkknnupwGfAWQLuy.qIqu56S7sLr27rX7truy_X1uvGowvx5ZXNZaNePqxT I1ZJG29M_Z80wl6BTuJL6jXByXHuAnPe1mT_XOxkvu7ZQdUJ6AbMiiuvfTglinoJhdDYfsxB5pVP HBviAwEBQXU0H6xcu02h2hkHWis.ktNJHlSRuAuTCr85WiDzqTyfsA1iRg611eV6.GKIexXNiUG7 whjFVar0Me_25vxiy3AgllxABzMXSTA5.FTuvVrzstGE0.eicLA318w7ty2jhII4lQTQpLP1abby .dKS7I4hgQosHxEicdvmZaLdTU3cbZ4eWLh7l9VzphGNSxT15mPVyqAiz78Igiak.HBJFoqmxuMD 09jARYa2OwCSVXPG8QAa72U47SlhwJVlyhfLUnA0cNuLcM_4Lw.g3eL5SNWKlTVMGuCGBvl4JKB3 LBNhojpv9exZQmEqy7QnNOGZfMOV76T1VdOARbW5WuCvDR2RsbnqxIHeGwDvIF4m7YTIV90XhbVK qderv9zcQCJZQTJYHj7WHEiCVg2dmFQ4Fv4K6nCNAMrkzufYII4jHJo7CjwccD1TrUJDp0doHSZt 82JCGkLWphzUXwMFeYfgRQLRt3AkU5mM_4YltVflTxRDVhDGyqsUaVnN98V101ghOlN0DcOSI6Ht CKIeM6UphwsEE2HG1HovfZMnv9RN1EhaA2ia.NNY_kAxOrRS232wMCuyYz3kZ7nQ86DDl6f8SR0R 1ZA.iRPhbPWJR0rozq7W0hb3l1Vm1QHhvgUd2cYhL2cWgYnndUzL2RwfkmGjlvMIFm5AaPKoCADw sVVUYgN0GqHUK64o2bSpDQa_OWbQXF08- Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Sat, 9 May 2020 03:58:04 +0000 Received: by smtp415.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 143842a2404404a60b46c84d00c5d4fd; Sat, 09 May 2020 03:58:02 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: svn commit: r360233 - in head: contrib/jemalloc . . . : This partially breaks a 2-socket 32-bit powerpc (old PowerMac G4) based on head -r360311 From: Mark Millard In-Reply-To: Date: Fri, 8 May 2020 20:58:02 -0700 Cc: Brandon Bergren , Justin Hibbits Content-Transfer-Encoding: quoted-printable Message-Id: References: <8479DD58-44F6-446A-9CA5-D01F0F7C1B38@yahoo.com> <17ACDA02-D7EF-4F26-874A-BB3E935CD072@yahoo.com> <695E6836-F860-4557-B7DE-CC1EDB347F18@yahoo.com> <121B9B09-141B-4DC3-918B-1E7CFB99E779@yahoo.com> <8AAB0462-3FA8-490C-8D8D-7C15B1C9E2DE@yahoo.com> <18E62746-80DB-4195-977D-4FF32D0129EE@yahoo.com> To: "vangyzen@freebsd.org" , svn-src-head@freebsd.org, FreeBSD Current , FreeBSD Hackers , FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49Jthb6Sfpz4Bwk X-Spamd-Bar: - X-Spamd-Result: default: False [-1.89 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCPT_COUNT_SEVEN(0.00)[7]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.62)[-0.617,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.77)[-0.771,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ip: (7.01), ipnet: 98.137.64.0/21(0.83), asn: 36647(0.66), country: US(-0.05)]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[204.68.137.98.list.dnswl.org : 127.0.5.0]; RWL_MAILSPIKE_POSSIBLE(0.00)[204.68.137.98.rep.mailspike.net : 127.0.0.17]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.32 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2020 03:58:10 -0000 [I caused nfsd to having things shifted in mmeory some to see it it tracked content vs. page boundary for where the zeros stop. Non-nfsd examples omitted.] > . . . >> nfsd hit an assert, failing ret =3D=3D sz_size2index_compute(size) >=20 > [Correction: That should have referenced sz_index2size_lookup(index).] >=20 >> (also, but a different caller of sz_size2index): >=20 > [Correction: The "also" comment should be ignored: > sz_index2size_lookup(index) is referenced below.] >=20 >>=20 >> (gdb) bt >> #0 thr_kill () at thr_kill.S:4 >> #1 0x502b2170 in __raise (s=3D6) at /usr/src/lib/libc/gen/raise.c:52 >> #2 0x50211cc0 in abort () at /usr/src/lib/libc/stdlib/abort.c:67 >> #3 0x50206104 in sz_index2size_lookup (index=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/sz.h:200 >> #4 sz_index2size (index=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/sz.h:207 >> #5 ifree (tsd=3D0x50094018, ptr=3D0x50041028, tcache=3D0x50094138, = slow_path=3D) at jemalloc_jemalloc.c:2583 >> #6 0x50205cac in __je_free_default (ptr=3D0x50041028) at = jemalloc_jemalloc.c:2784 >> #7 0x50206294 in __free (ptr=3D0x50041028) at = jemalloc_jemalloc.c:2852 >> #8 0x50287ec8 in ns_src_free (src=3D0x50329004, = srclistsize=3D) at /usr/src/lib/libc/net/nsdispatch.c:452 >> #9 ns_dbt_free (dbt=3D0x50329000) at = /usr/src/lib/libc/net/nsdispatch.c:436 >> #10 vector_free (vec=3D0x50329000, count=3D, esize=3D12,= free_elem=3D) at /usr/src/lib/libc/net/nsdispatch.c:253 >> #11 nss_atexit () at /usr/src/lib/libc/net/nsdispatch.c:578 >> #12 0x5028d958 in __cxa_finalize (dso=3D0x0) at = /usr/src/lib/libc/stdlib/atexit.c:240 >> #13 0x502117f8 in exit (status=3D0) at = /usr/src/lib/libc/stdlib/exit.c:74 >> #14 0x10013f9c in child_cleanup (signo=3D) at = /usr/src/usr.sbin/nfsd/nfsd.c:969 >> #15 >> #16 0x00000000 in ?? () >>=20 >> (gdb) up 3 >> #3 0x50206104 in sz_index2size_lookup (index=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/sz.h:200 >> 200 assert(ret =3D=3D sz_index2size_compute(index)); >>=20 >> (ret is optimized out.) >>=20 >> 197 JEMALLOC_ALWAYS_INLINE size_t >> 198 sz_index2size_lookup(szind_t index) { >> 199 size_t ret =3D (size_t)sz_index2size_tab[index]; >> 200 assert(ret =3D=3D sz_index2size_compute(index)); >> 201 return ret; >> 202 } >=20 > (gdb) print/x __je_sz_index2size_tab > $3 =3D {0x0 } >=20 > Also: >=20 > (gdb) x/4x __je_arenas+16368/4 > 0x5030cab0 <__je_arenas+16368>: 0x00000000 0x00000000 = 0x00000000 0x00000000 > (gdb) print/x __je_arenas_lock = =20= > $8 =3D {{{prof_data =3D {tot_wait_time =3D {ns =3D 0x0}, max_wait_time = =3D {ns =3D 0x0}, n_wait_times =3D 0x0, n_spin_acquired =3D 0x0, = max_n_thds =3D 0x0, n_waiting_thds =3D {repr =3D 0x0}, n_owner_switches = =3D 0x0,=20 > prev_owner =3D 0x0, n_lock_ops =3D 0x0}, lock =3D 0x0, = postponed_next =3D 0x0, locked =3D {repr =3D 0x0}}}, witness =3D {name =3D= 0x0, rank =3D 0x0, comp =3D 0x0, opaque =3D 0x0, link =3D {qre_next =3D = 0x0,=20 > qre_prev =3D 0x0}}, lock_order =3D 0x0} > (gdb) print/x __je_narenas_auto > $9 =3D 0x0 > (gdb) print/x malloc_conf =20 > $10 =3D 0x0 > (gdb) print/x __je_ncpus=20 > $11 =3D 0x0 > (gdb) print/x __je_manual_arena_base > $12 =3D 0x0 > (gdb) print/x __je_sz_pind2sz_tab =20 > $13 =3D {0x0 } > (gdb) print/x __je_sz_size2index_tab > $1 =3D {0x0 , 0x1a, 0x1b , 0x1c = } >=20 >> Booting and immediately trying something like: >>=20 >> service nfsd stop >>=20 >> did not lead to a failure. But may be after >> a while it would and be less drastic than a >> reboot or power down. >=20 > More detail: >=20 > So, for rpcbind and nfds at some point a large part of > __je_sz_size2index_tab is being stomped on, as is all of > __je_sz_index2size_tab and more. >=20 > . . . >=20 > For nfsd, it is similar (again showing the partially > non-zero live process context instead of the all-zeros > from the .core file): >=20 > 0x5030cab0 <__je_arenas+16368>: 0x00000000 0x00000000 = 0x00000000 0x00000009 > 0x5030cac0 <__je_arenas_lock>: 0x00000000 0x00000000 = 0x00000000 0x00000000 > 0x5030cad0 <__je_arenas_lock+16>: 0x00000000 0x00000000 = 0x00000000 0x00000000 > 0x5030cae0 <__je_arenas_lock+32>: 0x00000000 0x00000000 = 0x00000000 0x00000000 > 0x5030caf0 <__je_arenas_lock+48>: 0x00000000 0x00000000 = 0x00000000 0x00000000 > 0x5030cb00 <__je_arenas_lock+64>: 0x00000000 0x502ff070 = 0x00000000 0x00000000 > 0x5030cb10 <__je_arenas_lock+80>: 0x500ebb04 0x00000003 = 0x00000000 0x00000000 > 0x5030cb20 <__je_arenas_lock+96>: 0x5030cb10 0x5030cb10 = 0x00000000 0x00000000 >=20 > Then the memory in the crash continues to be zero until: >=20 > 0x5030d000 <__je_sz_size2index_tab+384>: 0x1a1b1b1b = 0x1b1b1b1b 0x1b1b1b1b 0x1b1b1b1b >=20 > Notice the interesting page boundary for where non-zero > is first available again! >=20 > Between __je_arenas_lock and __je_sz_size2index_tab are: >=20 > 0x5030cb30 __je_narenas_auto > 0x5030cb38 malloc_conf > 0x5030cb3c __je_ncpus > 0x5030cb40 __je_manual_arena_base > 0x5030cb80 __je_sz_pind2sz_tab > 0x5030ccc0 __je_sz_index2size_tab > 0x5030ce80 __je_sz_size2index_tab >=20 >=20 > Note: because __je_arenas is normally > mostly zero for these contexts, I can > not tell where the memory trashing > started, only where it replaced non-zero > values with zeros. > . . . I caused the memory content to have shifted some in nfsd. The resultant zeros-stop-at from the failure look like: (gdb) x/128x __je_sz_size2index_tab 0x5030cf00 <__je_sz_size2index_tab>: 0x00000000 0x00000000 = 0x00000000 0x00000000 0x5030cf10 <__je_sz_size2index_tab+16>: 0x00000000 0x00000000 = 0x00000000 0x00000000 0x5030cf20 <__je_sz_size2index_tab+32>: 0x00000000 0x00000000 = 0x00000000 0x00000000 0x5030cf30 <__je_sz_size2index_tab+48>: 0x00000000 0x00000000 = 0x00000000 0x00000000 0x5030cf40 <__je_sz_size2index_tab+64>: 0x00000000 0x00000000 = 0x00000000 0x00000000 0x5030cf50 <__je_sz_size2index_tab+80>: 0x00000000 0x00000000 = 0x00000000 0x00000000 0x5030cf60 <__je_sz_size2index_tab+96>: 0x00000000 0x00000000 = 0x00000000 0x00000000 0x5030cf70 <__je_sz_size2index_tab+112>: 0x00000000 = 0x00000000 0x00000000 0x00000000 0x5030cf80 <__je_sz_size2index_tab+128>: 0x00000000 = 0x00000000 0x00000000 0x00000000 0x5030cf90 <__je_sz_size2index_tab+144>: 0x00000000 = 0x00000000 0x00000000 0x00000000 0x5030cfa0 <__je_sz_size2index_tab+160>: 0x00000000 = 0x00000000 0x00000000 0x00000000 0x5030cfb0 <__je_sz_size2index_tab+176>: 0x00000000 = 0x00000000 0x00000000 0x00000000 0x5030cfc0 <__je_sz_size2index_tab+192>: 0x00000000 = 0x00000000 0x00000000 0x00000000 0x5030cfd0 <__je_sz_size2index_tab+208>: 0x00000000 = 0x00000000 0x00000000 0x00000000 0x5030cfe0 <__je_sz_size2index_tab+224>: 0x00000000 = 0x00000000 0x00000000 0x00000000 0x5030cff0 <__je_sz_size2index_tab+240>: 0x00000000 = 0x00000000 0x00000000 0x00000000 0x5030d000 <__je_sz_size2index_tab+256>: 0x18191919 = 0x19191919 0x19191919 0x19191919 0x5030d010 <__je_sz_size2index_tab+272>: 0x19191919 = 0x19191919 0x19191919 0x19191919 0x5030d020 <__je_sz_size2index_tab+288>: 0x19191919 = 0x19191919 0x19191919 0x19191919 0x5030d030 <__je_sz_size2index_tab+304>: 0x19191919 = 0x19191919 0x19191919 0x19191919 0x5030d040 <__je_sz_size2index_tab+320>: 0x191a1a1a = 0x1a1a1a1a 0x1a1a1a1a 0x1a1a1a1a 0x5030d050 <__je_sz_size2index_tab+336>: 0x1a1a1a1a = 0x1a1a1a1a 0x1a1a1a1a 0x1a1a1a1a 0x5030d060 <__je_sz_size2index_tab+352>: 0x1a1a1a1a = 0x1a1a1a1a 0x1a1a1a1a 0x1a1a1a1a 0x5030d070 <__je_sz_size2index_tab+368>: 0x1a1a1a1a = 0x1a1a1a1a 0x1a1a1a1a 0x1a1a1a1a 0x5030d080 <__je_sz_size2index_tab+384>: 0x1a1b1b1b = 0x1b1b1b1b 0x1b1b1b1b 0x1b1b1b1b 0x5030d090 <__je_sz_size2index_tab+400>: 0x1b1b1b1b = 0x1b1b1b1b 0x1b1b1b1b 0x1b1b1b1b 0x5030d0a0 <__je_sz_size2index_tab+416>: 0x1b1b1b1b = 0x1b1b1b1b 0x1b1b1b1b 0x1b1b1b1b 0x5030d0b0 <__je_sz_size2index_tab+432>: 0x1b1b1b1b = 0x1b1b1b1b 0x1b1b1b1b 0x1b1b1b1b 0x5030d0c0 <__je_sz_size2index_tab+448>: 0x1b1c1c1c = 0x1c1c1c1c 0x1c1c1c1c 0x1c1c1c1c 0x5030d0d0 <__je_sz_size2index_tab+464>: 0x1c1c1c1c = 0x1c1c1c1c 0x1c1c1c1c 0x1c1c1c1c 0x5030d0e0 <__je_sz_size2index_tab+480>: 0x1c1c1c1c = 0x1c1c1c1c 0x1c1c1c1c 0x1c1c1c1c 0x5030d0f0 <__je_sz_size2index_tab+496>: 0x1c1c1c1c = 0x1c1c1c1c 0x1c1c1c1c 0x1c1c1c1c So, it is the page boundary that it tracks, not the detailed placement of the memory contents. =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 May 9 20:50:49 2020 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 525BB2F573D for ; Sat, 9 May 2020 20:50:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49KK951YDZz4KJ0 for ; Sat, 9 May 2020 20:50:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by freefall.freebsd.org (Postfix) id 13388EA01; Sat, 9 May 2020 20:50:49 +0000 (UTC) Delivered-To: powerpc@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [96.47.72.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id 10E5CE67E for ; Sat, 9 May 2020 20:50:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49KK945zn0z4KHw for ; Sat, 9 May 2020 20:50:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id C887F21D25 for ; Sat, 9 May 2020 20:50:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 049KomgW043054 for ; Sat, 9 May 2020 20:50:48 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 049Komf3043053 for powerpc@FreeBSD.org; Sat, 9 May 2020 20:50:48 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: powerpc@FreeBSD.org Subject: [Bug 246194] math/blis: pacify portlint, add test target, optimize for power9 Date: Sat, 09 May 2020 20:50:47 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jmd@freebsd.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: jmd@freebsd.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.32 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2020 20:50:49 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D246194 Johannes M Dieterich changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |In Progress --- Comment #1 from Johannes M Dieterich --- No objections to 1-3, 5. 4: are these generations supported by powerpc64? If so, can we add fallback= to generic? That should work by introducing a "powerpc64" family containing bo= th the family 9 optimized one as well as the generic fallback I'm not a friend of complicating the port too much - I'd rather us use prop= er families for all targets to not run into surprises and be able to distribute the packages. The overhead of having non-applicable kernels compiled and packaged seems tolerable? --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-ppc@freebsd.org Sat May 9 22:03:29 2020 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 915222F7070 for ; Sat, 9 May 2020 22:03:29 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49KLmx3Nlhz4Ntv for ; Sat, 9 May 2020 22:03:29 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by freefall.freebsd.org (Postfix) id 659F0F325; Sat, 9 May 2020 22:03:29 +0000 (UTC) Delivered-To: powerpc@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id 45629F324 for ; Sat, 9 May 2020 22:03:29 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49KLmx0F34z4Nts for ; Sat, 9 May 2020 22:03:29 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 03A4222C08 for ; Sat, 9 May 2020 22:03:29 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 049M3SA7008602 for ; Sat, 9 May 2020 22:03:28 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 049M3Skx008601 for powerpc@FreeBSD.org; Sat, 9 May 2020 22:03:28 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: powerpc@FreeBSD.org Subject: [Bug 246194] math/blis: pacify portlint, add test target, optimize for power9 Date: Sat, 09 May 2020 22:03:29 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: pkubaj@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: jmd@freebsd.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.32 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2020 22:03:29 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D246194 --- Comment #2 from Piotr Kubaj --- FreeBSD supports all IBM POWER chips from the first PPC970 (in Macs G5) up = to the latest POWER9 and also Freescale's ppc64 chips found in embedded device= s. So yes, optimizing for POWER9 will make it more useful to POWER9 users. It = will also make this port useless on all earlier generations, but: 1) since nothing depends on this port, optimizing to POWER9 will only be relevant to people directly using this port on powerpc64 older than POWER9,= not to someone using some reverse dependency (because there are none), 2) I think people using software strictly for scientific computations tend = to use the latest available hardware because of power usage improvements. I do= n't think anyone will use their old PowerMac G5 with this port. Regarding complicating this port, on e.g. ARM we build generic binaries, but per https://github.com/flame/blis/blob/master/config_registry, there are two armv7-optimized variants and three aarch64-optimized variants, depending on= the actual CPU. For amd64, there are overall 11 possible variants (optimized for specific CPUs). This is why I proposed this port getting flavours, that would make it possi= ble for users to install their preferred version. If you ask about POWER and BGQ in the above link, AFAIK this is IBM Blue Ge= ne which uses custom PowerPC chips and support for it is not available in Free= BSD anyway. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-ppc@freebsd.org Sat May 9 22:46:17 2020 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 E585E2F7D57 for ; Sat, 9 May 2020 22:46:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49KMkK5kT1z4QNQ for ; Sat, 9 May 2020 22:46:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by freefall.freebsd.org (Postfix) id 9CE13F1F1; Sat, 9 May 2020 22:46:17 +0000 (UTC) Delivered-To: powerpc@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id 973FEF4B8 for ; Sat, 9 May 2020 22:46:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49KMkK2cN8z4QNM for ; Sat, 9 May 2020 22:46:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 5503E23369 for ; Sat, 9 May 2020 22:46:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 049MkH1O040013 for ; Sat, 9 May 2020 22:46:17 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 049MkH9O040012 for powerpc@FreeBSD.org; Sat, 9 May 2020 22:46:17 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: powerpc@FreeBSD.org Subject: [Bug 246194] math/blis: pacify portlint, add test target, optimize for power9 Date: Sat, 09 May 2020 22:46:16 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jmd@freebsd.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: jmd@freebsd.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.32 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2020 22:46:18 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D246194 --- Comment #3 from Johannes M Dieterich --- My goal for this port is to have it be an option as a BLAS solution in the ports framework, so I'm hesitant to break it for anything. We should be abl= e to work with upstream to ensure a family config is available that works ideall= y on 9 and falls back correctly. That's the point of the x86_64 family is to support all 11 amd64/intel64 x86_64. They added this on my request. I'd rather work with upstream to properly bundle the ARM and Power configs = as well (with fallback, so that's unlike the x86_64 family which does not poss= ess a fallback - but maybe should) and switch them at runtime. That way everybo= dy gets ideal performance without older generations breaking. That's equivalent to what e.g. math/openblas does. --=20 You are receiving this mail because: You are on the CC list for the bug.=