From nobody Mon Nov 15 16:47:44 2021 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id A7FDF188E0F4; Mon, 15 Nov 2021 16:47:46 +0000 (UTC) (envelope-from debdrup@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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HtFVV3y4vz4Zhw; Mon, 15 Nov 2021 16:47:46 +0000 (UTC) (envelope-from debdrup@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1636994866; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type; bh=m+iAUVB0VdGYXfnHCgBmER8qhWHmOpGg6tJMTEIf3jc=; b=arRU/kkFqnRjt9tH2y+Lch2OMfwK/Yv7qtiSIe8E7EUXWS8rUrJdT0Oi7BKhiKRq57LRuC BAviWpcpw6geH/i88Qq2AsJcVA209EvAAYrWlNH2cO0Bty1yw4K6OnJPXVtIWisKO/qV0J wMNrEhkebmtJIQPg+/li6FXVqDkhvEGJ0tUHinP3B0EnK1lX/x8Hq69k8oXrn9ejUoGxOU LdWYvQ4XAB03HcYir4A6ciJJUxLIfPEuXVOEcxF0MJsspANdDpdMNjCwXyokMJnb7iF2Ug NLW2+Qq5/tcNmHHRbpppFxjq9M3Pukr7XcXRjIdxwjcx++fCx0vAmiGihqGWXA== Received: by freefall.freebsd.org (Postfix, from userid 1471) id 702981BB1D; Mon, 15 Nov 2021 16:47:46 +0000 (UTC) Date: Mon, 15 Nov 2021 17:47:44 +0100 From: Daniel Ebdrup Jensen To: hackers@FreeBSD.org Cc: current@FreeBSD.org, stable@FreeBSD.org Subject: FreeBSD Quarterly Status Report - Third Quarter 2021 Message-ID: <20211115164744.chsesrxkz3bb4wct@nerd-thinkpad.local> Mail-Followup-To: Daniel Ebdrup Jensen , hackers@FreeBSD.org, current@FreeBSD.org, stable@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="66dsezfsnajsewcm" Content-Disposition: inline ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1636994866; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type; bh=m+iAUVB0VdGYXfnHCgBmER8qhWHmOpGg6tJMTEIf3jc=; b=qsbgdTuE4/drg/gfERD1lYv7/TTrdYPRAbv36xHF4Ptp1dxWEeSlAnzFSE4jlta+BK2pXj SXmn+JErgXWhOsM+dBtG8Zjza0XasueA0briFqa9/zh8MOyvOf/6gGCa+9WJQ8WlT3A+k4 Evo0MIHzCi7cnpeOJgbFQI7iFz1nGKkwf6fesSexjgRVvUuINz1WtO86bXkfIALNOChIb/ PFTUSRBUN3qYBifA/BaJcfOEAXx6G06yUBpmQw/Oh/v4gPIfBFMaJInt/+PBcGNmDC2ugD 8iqph3Xp+lnvIZRHOVPmRn8s86bIkEaQRwz4Z8CfPPQmEFGAahwrmDLlrOpWyA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1636994866; a=rsa-sha256; cv=none; b=jWTTTGm7W3kWvtsH+6WaC+NDd4uYReFSQyVxxVLhqWXvO2n3GFcwI8E7Yx7yyOKyl1M2Lc GCsMVKasxl2WruS2tcjeSUjU2VI2XsLjMIDG6iRslFZoyrSJtuE4K1P46gmDpWj3G1k7nJ 8CRtTOmLakqQrJByRcBfd05yGNWET3YJEOo/Rqw9moaaTl1C3rpzIzKBayg29TbdSr9VOY eK5A2Uycwtanztk8B056g7OtmmpeZcgyrDHaami0wkVk5+pByQHVaRI+hq10EE8MIMvMjV 2kURTJ4Bp0wL3Nd6eanRPTpZpYswHC3TsCmrKgJ2r7fhG+uzcixnuEKacYg0/A== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --66dsezfsnajsewcm Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable FreeBSD Quarterly Status Report 3rd Quarter 2021 This report covers FreeBSD related projects for the period between July and September, and is the third of four planned reports for 2021, and contains = 42 entries. The third quarter of 2021 was quite active in lots of different areas, so t= he report covers a bunch of interesting work including but not limited to boot performance, compile-time analysis, hole-punching support, various drivers,= ZFS raidz expansion, an update to the sound mixer, and many more. Regrettably, the status report got a bit delayed, but we hope that the apho= rism better late than never can apply here. Yours, Daniel Ebdrup Jensen, with status hat on. =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 Table of Contents =E2=80=A2 FreeBSD Team Reports =E2=96=A1 FreeBSD Foundation =E2=96=A1 FreeBSD Release Engineering Team =E2=96=A1 Cluster Administration Team =E2=96=A1 Continuous Integration =E2=96=A1 Ports Collection =E2=96=A1 Documentation Engineering Team =E2=96=A1 FreeBSD Website Revamp - WebApps working group =E2=80=A2 Projects =E2=96=A1 Boot Performance Improvements =E2=96=A1 Git Migration Working Group =E2=96=A1 LLDB Debugger Improvements =E2=96=A1 Linux compatibility layer update =E2=96=A1 Sound mixer improvements =E2=96=A1 Base System OpenSSH Update =E2=80=A2 Kernel =E2=96=A1 Arm64 improvements =E2=96=A1 FreeBSD on Microsoft HyperV and Azure =E2=96=A1 Improved amd64 UEFI boot =E2=96=A1 ENA FreeBSD Driver Update =E2=96=A1 Hole-punching support on FreeBSD =E2=96=A1 Intel Networking on FreeBSD =E2=96=A1 Intel Wireless driver support =E2=96=A1 Microchip LAN743x mgb(4) Device Driver =E2=96=A1 Fixes for msdosfs_rename VOP =E2=96=A1 OpenZFS RAIDZ Expansion update =E2=96=A1 RFC1191 support in IPSEC tunnels =E2=96=A1 Realtek rtw88 support =E2=96=A1 Marvell SDHCI improvements and ACPI support =E2=96=A1 Stack gap handling improvements =E2=96=A1 syzkaller on FreeBSD =E2=96=A1 Using OCF in WireGuard =E2=96=A1 Intel Volume Management Device driver update =E2=80=A2 Ports =E2=96=A1 Improve CPE Data in the Ports Collection =E2=96=A1 Why do we need it? =E2=96=A1 How can I help? =E2=96=A1 Open Tasks =E2=96=A1 FreeBSD Erlang Ecosystem Ports update =E2=96=A1 KDE on FreeBSD =E2=96=A1 OpenSearch on FreeBSD =E2=96=A1 Valgrind - Official Support for FreeBSD has Landed =E2=96=A1 Wine on FreeBSD =E2=96=A1 Ztop =E2=80=A2 Miscellaneous =E2=96=A1 -CURRENT compilation time analysis =E2=80=A2 Third-Party Projects =E2=96=A1 Gitlab 14.3 available =E2=96=A1 helloSystem =E2=96=A1 Containers & FreeBSD: Pot, Potluck & Potman =E2=96=A1 WireGuard on FreeBSD Stabilizes, Eyes Upstreaming =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 FreeBSD Team Reports Entries from the various official and semi-official teams, as found in the Administration Page. FreeBSD Foundation Links: FreeBSD Foundation URL: https://www.FreeBSDfoundation.org Technology Roadmap URL: https://freebsdfoundation.org/blog/technology-roadm= ap/ Donate URL: https://www.FreeBSDfoundation.org/donate/ Foundation Partnership Program URL: https://www.FreeBSDfoundation.org/ FreeBSD-foundation-partnership-program FreeBSD Journal URL: https://www.FreeBSDfoundation.org/journal/ Foundation News and Events URL: https://www.FreeBSDfoundation.org/ news-and-events/ Contact: Deb Goodkin The FreeBSD Foundation is a 501(c)(3) non-profit organization dedicated to supporting and promoting the FreeBSD Project and community worldwide. Donat= ions =66rom individuals and corporations are used to fund and manage software development projects, conferences, and developer summits. We also provide travel grants to FreeBSD contributors, purchase and support hardware to imp= rove and maintain FreeBSD infrastructure, and provide resources to improve secur= ity, quality assurance, and release engineering efforts. We publish marketing material to promote, educate, and advocate for the FreeBSD Project, facilit= ate collaboration between commercial vendors and FreeBSD developers, and finall= y, represent the FreeBSD Project in executing contracts, license agreements, a= nd other legal arrangements that require a recognized legal entity. Here are some highlights of what we did to help FreeBSD last quarter: Fundraising Efforts Fundraising last quarter wasn=E2=80=99t as spectacular as we were hoping. B= ut, then again, people tend to take vacations during the summer months, which makes = it that more difficult for our funding requests to go through the management c= hain for approvals. So far this year we=E2=80=99ve raised $180,000 towards our $2,000,000 spend= ing budget. Why do we need so much money? Well, last year we decided to make more significant software contributions to FreeBSD. In order to do that, we had = to grow our team. We developed a technology roadmap based on input we were receiving from commercial users as well as market trends. Based on the road= map, we identified positions we needed to fill. This year we=E2=80=99ve hired three full-time software developers, one full= -time ARM kernel developer, and one project manager. We also are funding wifi work full-time and some other projects to help with FreeBSD on the desktop. You = can read about this effort to attract new users and contributors to the Project= in individual entries elsewhere in this status report. Our growth wasn=E2=80=99t just in our technology team, but in our advocacy = team too. Here we hired a marketing coordinator and technical writer to provide more educational and informational content. You=E2=80=99ll see in the Advocacy a= nd Education section below all the work we did to promote FreeBSD, provide community engagement, education opportunities, and informative content to help pave t= he path to getting started with FreeBSD. You=E2=80=99ll find out how we used your donations here and in individual e= ntries throughout this status report. We=E2=80=99re passionate about supporting you, the FreeBSD community, but w= e can=E2=80=99t do it without your financial support. Please consider making a donation to help us continue and increase our supp= ort for FreeBSD in 2021: https://www.FreeBSDfoundation.org/donate/. We also have the Partnership Program, to provide more benefits for our larg= er commercial donors. Find out more information at https:// www.FreeBSDfoundation.org/FreeBSD-foundation-partnership-program/ and share with your companies! OS Improvements During the third quarter, Foundation staff and grant recipients committed 4= 20 src tree changes, 24 ports tree changes, and 11 doc tree changes. This represents 38%, 48%, and 16% of src, port, and doc commits which identify a sponsor. You can read about Foundation-sponsored projects in individual quarterly re= port entries: =E2=80=A2 Base System OpenSSH Update =E2=80=A2 Fixes for msdosfs_rename VOP =E2=80=A2 Hole Punching =E2=80=A2 Improved amd64 UEFI boot =E2=80=A2 Intel Wireless driver support =E2=80=A2 LLDB Debugger Improvements =E2=80=A2 Microchip LAN743x mgb(4) Device Driver =E2=80=A2 OpenZFS RAIDZ Expansion update =E2=80=A2 Using OCF in WireGuard =E2=80=A2 syzkaller on FreeBSD Foundation-sponsored arm64 work: =E2=80=A2 Support for booting FreeBSD on the Arm Armv8-A AEM simulator =E2=80=A2 sha256 instruction support to libmd(4) on arm64 =E2=80=A2 Initial work to support RAS, PAC and BTI on arm64 Continuous Integration and Quality Assurance The Foundation provides a full-time staff member and funds projects to impr= ove continuous integration, automated testing, and overall quality assurance efforts for the FreeBSD project. See the separate Continuous Integration entry for details. Supporting FreeBSD Infrastructure The Foundation provides hardware and support for the Project. Last quarter,= we continued supporting the test cluster at Sentex, purchased a few needed dri= ves and spam filtering software for project email. We also set up a new and more efficient hardware request/purchase process for clusteradm to use. Partnerships and Commercial User Support We met virtually with corporate users and started travelling again in late = Q3 for some in-person meetings. The goals of the meetings are to facilitate collaboration between commercial users and FreeBSD developers. We also met = with companies to discuss their needs and share that information with the Projec= t. FreeBSD Advocacy and Education Much of our effort is dedicated to Project advocacy. This may involve highlighting interesting FreeBSD work, producing literature, attending even= ts, or giving presentations. The goal of the literature we produce is to teach people FreeBSD basics and help make their path to adoption or contribution easier. Other than attending and presenting at events, we encourage and help community members run their own FreeBSD events, give presentations, or staff FreeBSD tables. The FreeBSD Foundation sponsors many conferences, events, and summits around the globe. These events can be BSD-related, open source, or technology even= ts geared towards underrepresented groups. We support the FreeBSD-focused even= ts to help provide a venue for sharing knowledge, working together on projects, and facilitating collaboration between developers and commercial users. This all helps provide a healthy ecosystem. We support the non-FreeBSD events to promote and raise awareness of FreeBSD, to increase the use of FreeBSD in different applications, and to recruit more contributors to the Project. We finally made it back to our first in-person meeting with the Open Source Su= mmit in late September. We are also continuing to attend virtual events. In addi= tion to attending and planning virtual events, we are continually working on new training initiatives and updating our selection of how-to guides to facilit= ate getting more folks to try out FreeBSD. Check out some of the advocacy and education work we did last quarter: =E2=80=A2 Participated as an Industry Partner for USENIX ATC and OSD, Jul= y 14-16, 2021 =E2=80=A2 Participated as an Industry Partner for USENIX Security, August= 11-13, 2021 =E2=80=A2 Held a FreeBSD Friday: How to Track FreeBSD Using Git =E2=80=A2 Sponsored and gave a talk at OpenFest 2020 in Sofia, Bulgaria, = August 14-15, 2021 =E2=80=A2 Began planning for the November 2021 FreeBSD Vendor Summit to b= e held online, November 18-19 =E2=80=A2 Presented at APNIC on August 13-16, 2021 =E2=80=A2 Served as a Nonprofit In-Kind Sponsor of OSI=E2=80=99s POSI 202= 1, September 16, 2021 =E2=80=A2 Sponsored EuroBSDcon at the Silver Level. The event took place,= September 17-19, 2021 =E2=80=A2 Presented at Open Source Summit, in Seattle, WA, September 27-3= 0, 2021 =E2=80=A2 Committed to be a Bronze Sponsor for the OpenZFS Summit =E2=80=A2 New blog and video posts: =E2=96=A1 Status of Online Conference Software on FreeBSD =E2=96=A1 Meet the Summer 2021 Foundation Interns =E2=96=A1 A Look at Profiling: FreeBSD Sort =E2=96=A1 Meet the 2021 FreeBSD Google Summer of Code Students =E2=96=A1 A Co-op Term at the FreeBSD Foundation =E2=96=A1 Technology Roadmap =E2=80=A2 Devstyler Interview with Deb Goodkin =E2=80=A2 New Video How-to Guides on installing HelloSystem and installin= g GhostBSD =E2=80=A2 New Quick Start Guide on Printing on FreeBSD =E2=80=A2 Committed to be a Media Sponsor for All Things Open We help educate the world about FreeBSD by publishing the professionally produced FreeBSD Journal. As we mentioned previously, the FreeBSD Journal is now a free publication. Find out more and access the latest issues at https= :// www.FreeBSDfoundation.org/journal/. You can find out more about events we attended and upcoming events at https= :// www.FreeBSDfoundation.org/news-and-events/. Legal/FreeBSD IP The Foundation owns the FreeBSD trademarks, and it is our responsibility to protect them. We also provide legal support for the core team to investigate questions that arise. Go to https://www.FreeBSDfoundation.org to find more about how we support FreeBSD and how we can help you! =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 FreeBSD Release Engineering Team Links: FreeBSD 12.3-RELEASE schedule URL: https://www.freebsd.org/releases/12.3R/ schedule/ FreeBSD releases URL: https://download.freebsd.org/ftp/releases/ISO-IMAGES/ FreeBSD development snapshots URL: https://download.freebsd.org/ftp/snapsho= ts/ ISO-IMAGES/ Contact: FreeBSD Release Engineering Team, The FreeBSD Release Engineering Team is responsible for setting and publish= ing release schedules for official project releases of FreeBSD, announcing code freezes and maintaining the respective branches, among other things. Throughout the third quarter, several development snapshots builds were released for the main, stable/13, and stable/12 branches. More work had been done on various release-related tooling following the conversion from Subversion to Git. Additionally, the team had drafted the proposed schedule= for the upcoming 12.3-RELEASE. Sponsor: Rubicon Communications, LLC ("Netgate") Sponsor: The FreeBSD Foundation =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 Cluster Administration Team Links: Cluster Administration Team members URL: https://www.freebsd.org/administra= tion /#t-clusteradm Contact: Cluster Administration Team FreeBSD Cluster Administration Team members are responsible for managing the machines the Project relies on to synchronise its distributed work and communications. In this quarter, the team has worked on the following: =E2=80=A2 Fixed www.FreeBSD.org mirror sync source =E2=80=A2 Improvements to GeoDNS for {download,ftp,pkg}.FreeBSD.org =E2=80=A2 Added IPv6 support =E2=80=A2 More optimal mirror selection in Asia =E2=80=A2 Finished installing a new mirror site in Japan, sponsored by Br= oadband Tower, Inc. =E2=80=A2 Full mirror site (ftp, pkg, git, doc, dns,=E2=80=A6=E2=80=8B) =E2=80=A2 The network and machine resources for this mirror are generousl= y sponsored by the Cloud and SDN Laboratory at BroadBand Tower, Inc., one of the Internet data center service providers in Tokyo, Japan, with 300+ Gbps international IP transit bandwidth =E2=80=A2 Improved the retention script used for the artifact server of C= I cluster to offer a mix of the latest artifacts but also a selection of older artif= acts for comparison, space permitting =E2=80=A2 Ongoing day to day cluster administration =E2=80=A2 Replacing failed disks =E2=80=A2 Babysitting pkgsync Work in progress: =E2=80=A2 Move pkg-master.nyi to new hardware =E2=80=A2 Improve the package building infrastructure =E2=80=A2 Review the service jails and service administrators operation =E2=80=A2 Setup powerpc pkgbuilder/ref/universal machines =E2=80=A2 Search for more providers that can fit the requirements for a g= eneric mirrored layout or a tiny mirror =E2=80=A2 Upgrading public-facing cluster services from 12.2-STABLE to 13= =2E0-STABLE =E2=80=A2 Working with doceng@ to improve https://www.freebsd.org and htt= ps:// docs.freebsd.org =E2=80=A2 Improve the web service architecture =E2=80=A2 Improve the cluster backup plan =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 Continuous Integration Links: FreeBSD Jenkins Instance URL: https://ci.FreeBSD.org FreeBSD CI artifact archive URL: https://artifact.ci.FreeBSD.org FreeBSD Jenkins wiki URL: https://wiki.freebsd.org/Jenkins Hosted CI wiki URL: https://wiki.freebsd.org/HostedCI 3rd Party Software CI URL: https://wiki.freebsd.org/3rdPartySoftwareCI Tickets related to freebsd-testing@ URL: https://preview.tinyurl.com/y9maau= wg FreeBSD CI Repository URL: https://github.com/freebsd/freebsd-ci+ dev-ci Mailing List URL: https://lists.freebsd.org/subscription/dev-ci Contact: Jenkins Admin Contact: Li-Wen Hsu Contact: freebsd-testing Mailing List Contact: IRC #freebsd-ci channel on EFNet The FreeBSD CI team maintains the continuous integration system of the Free= BSD project. The CI system checks the committed changes can be successfully bui= lt, then performs various tests and analysis over the newly built results. The artifacts from those builds are archived in the artifact server for further testing and debugging needs. The CI team members examine the failing builds= and unstable tests and work with the experts in that area to fix the code or ad= just test infrastructure. During the third quarter of 2021, we continued working with the contributors and developers in the project to fulfil their testing needs and also keep collaborating with external projects and companies to improve their products and FreeBSD. Important changes: =E2=80=A2 The results of FreeBSD-main-amd64-build and FreeBSD-main-amd64-= test jobs are sent to the dev-ci mailing list New jobs: =E2=80=A2 Run tests with KASAN enabled for main on amd64 =E2=80=A2 Run tests with KMSAN enabled for main on amd64 Retired jobs: =E2=80=A2 The jobs for stable/11 branch were removed after September 30th= per FreeBSD 11.4 end-of-life Work in progress and open tasks: =E2=80=A2 Designing and implementing pre-commit CI building and testing (= to support the workflow working group) =E2=80=A2 Designing and implementing use of CI cluster to build release a= rtifacts as release engineering does =E2=80=A2 Collecting and sorting CI tasks and ideas here =E2=80=A2 Testing and merging pull requests in the FreeBSD-ci repo =E2=80=A2 Reducing the procedures of CI/test environment setting up for c= ontributors and developers =E2=80=A2 Setting up the CI stage environment and putting the experimenta= l jobs on it =E2=80=A2 Setting up public network access for the VM guest running tests =E2=80=A2 Implementing using bare metal hardware to run test suites =E2=80=A2 Adding drm ports building tests against -CURRENT =E2=80=A2 Planning to run ztest tests =E2=80=A2 Adding more external toolchain related jobs =E2=80=A2 Improving maturity of the hardware lab and adding more hardware= under test =E2=80=A2 Helping more software get FreeBSD support in its CI pipeline (W= iki pages: 3rdPartySoftwareCI, HostedCI) =E2=80=A2 Working with hosted CI providers to have better FreeBSD support Please see freebsd-testing@ related tickets for more WIP information, and d= on=E2=80=99t hesitate to join the effort! Sponsor: The FreeBSD Foundation =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 Ports Collection Links: About FreeBSD Ports URL: https://www.FreeBSD.org/ports/ Contributing to Ports URL: https://docs.freebsd.org/en/articles/contributin= g/ ports-contributing/ FreeBSD Ports Monitoring URL: http://portsmon.freebsd.org/ Ports Management Team URL: https://www.freebsd.org/portmgr/ Ports Tarball URL: http://ftp.freebsd.org/pub/FreeBSD/ports/ports/ Contact: Ren=C3=A9 Ladan Contact: FreeBSD Ports Management Team The Ports Management Team is responsible for overseeing the overall directi= on of the Ports Tree, building packages, and personnel matters. Below is what happened in the last quarter. There are currently 46,500 ports in the Ports Tree according to FreshPorts.= The open PR count for ports is currently 2,588, of which 608 are unassigned. The last quarter saw 9,833 commits on the "main" branch by 148 committers and 7= 43 commits on the quarterly branch by 54 committers. Compared to 2021q2, activ= ity mostly remained the same, the PR counts increased a bit but there were also more commits to the quarterly branch. During 2021q3, we welcomed Daniel Engberg (diizzy@) and Yasuhiro Kimura (yasu@), and we said goodbye to culot@ and grog@ after their commit bits we= re taken in for safekeeping. Two new uses were introduced: angr to help with testing Python-related ports and mlt to help depending on mlt, a multimedia framework for TV broadcastin= g. Ruby saw minor updates for the 2.6, 2.7, and 3.0 series. The "big" packages were also updated: pkg to 1.17.2, Firefox to 93.0, and Chromium to 92.0.4515.159. As usual, exp-runs were performed by antoine@ but only those of July were recorded. There were 5 exp-runs to test adding CLOCK_\*_COARSE compatibility definitions for Linux and to test ports updates. Furthermore, rene@ gave a presentation "portmgr: behind the scenes" at EuroBSDCon 2021 about how portmgr came to be and its daily activities. =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 Documentation Engineering Team Links: FreeBSD Documentation Project URL: https://www.freebsd.org/docproj/ FreeBSD Documentation Project Primer for New Contributors URL: link:https:// docs.freebsd.org/en/books/fdp-primer/ Documentation Engineering Team URL: https://www.freebsd.org/administration/# t-doceng Contact: FreeBSD Doceng Team The doceng@ team is a body to handle some of the meta-project issues associ= ated with the FreeBSD Documentation Project; for more information, see FreeBSD Doceng Team Charter. During the last quarter, Philip Paeps (philip@) and Li-Wen Hsu (lwhsu@), already src and ports committers, were granted documentation commit bits, b= oth now have all commit bit types. Ed Maste (emaste@) who is already a src committer was granted a documentation commit bit. We also said goodbye to Murray Stokely (murray@), G=C3=A1bor K=C3=B6vesd=C3=A1n (gabor@), Warren Bl= ock (wblock@), and Sevan Janiyan (sevan@). G=C3=A1bor K=C3=B6vesd=C3=A1n (gabor@) and Warren B= lock (wblock@) are now former members of the doceng@ team; we thank them for their years of service. Implicit (blanket) approvals were documented in the Committers Guide. That = does not cover all cases, but doceng@ encourages any FreeBSD committer from ports and src to contribute to the doc tree. All ports/packages misc/freebsd-doc-* were updated. They have the entire documentation set from the FreeBSD Documentation Project, like Handbook, FA= Q, articles, and more. =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 FreeBSD Website Revamp - WebApps working group Contact: Sergio Carlavilla Working group in charge of creating the new FreeBSD Documentation Portal and redesigning the FreeBSD main website and its components. FreeBSD developers= can follow and join the working group on the FreeBSD Slack channel #wg-www21. T= he work will be divided into four phases: 1. Redesign of the Documentation Portal Create a new design, responsive and with global search. (Work in progre= ss, almost complete) 2. Redesign of the Manual Pages on web Scripts to generate the HTML pages using mandoc. (Work in progress) 3. Redesign of the Ports page on web Ports scripts to create an applications portal. (Not started) 4. Redesign of the FreeBSD main website New design, responsive and dark theme. (Not started) =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 Projects Projects that span multiple categories, from the kernel and userspace to the Ports Collection or external projects. Boot Performance Improvements Links: Wiki page URL: https://wiki.freebsd.org/BootTime OS boot time comparison URL: https://www.daemonology.net/blog/ 2021-08-12-EC2-boot-time-benchmarking.html Contact: Colin Percival Colin Percival is coordinating an effort to speed up the FreeBSD boot proce= ss. For benchmarking purposes, he is using an EC2 c5.xlarge instance as a refer= ence platform and is measuring the time between when the virtual machine enters = the EC2 "running" state and when it is possible to SSH into the instance. This work started in 2017, leading to a conference presentation, "Profiling= the FreeBSD kernel boot", and quickly yielded roughly 4850 ms of improvements (starting from a baseline of about 30 seconds). Since June, another roughly 9790 ms of time has been shaved off the boot process, taking it down to approximately 15 seconds. There is still more wo= rk to be done; in particular, while the loader and kernel have been profiled, = the TSLOG system Colin is using does not currently support userland profiling. Issues are listed on the wiki page as they are identified; the wiki page al= so has instructions for performing profiling. Users are encouraged to profile = the boot process on their own systems, in case they experience delays which don= =E2=80=99t show up on the system Colin is using for testing. This work is supported by Colin=E2=80=99s FreeBSD/EC2 Patreon. Sponsor: https://www.patreon.com/cperciva =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 Git Migration Working Group Links: Git for FreeBSD development wiki URL: https://wiki.freebsd.org/Git Git transition wiki URL: https://wiki.freebsd.org/GitTransition doc git repo web URL: https://cgit.FreeBSD.org/doc ports git repo web URL: https://cgit.FreeBSD.org/ports src (base system) git repo web URL: https://cgit.FreeBSD.org/src Committers guide Git primer URL: https://docs.freebsd.org/en/articles/ committers-guide/#git-primer Handbook Using Git appendix URL: https://docs.freebsd.org/en/books/handbook/ mirrors/#git Game of Trees URL: http://gameoftrees.org/ gitup URL: https://github.com/johnmehr/gitup Contact: Li-Wen Hsu Contact: Warner Losh Contact: Ed Maste Contact: FreeBSD-git mailing list Contact: #gitcvt channel on EFnet With the end of the third quarter of 2021, we are approaching the one-year anniversary of the transition of the doc and src repositories from Subversi= on to Git. The 2021Q4 branch of the ports tree has been created, the third quarterly branch created using Git. During 2021Q3, repository hooks have been refined as problems were discover= ed and a few lingering references to Subversion were updated in the Committer= =E2=80=99s Guide. The Working Group continues to track progress on two permissively-licensed Git-compatible tools: Gitup and Game of Trees. Gitup = is a small, dependency-free tool to clone and update git repositories. It is used only to keep a local tree up-to-date, and has no support for local commits. Game of Trees is a version control client that is compatible with Git repositories. It provides a user interface and workflow that is distinct fr= om that of Git. It is in no way intended to be a drop-in replacement for Git, = but can be used to develop software maintained in a Git repository. Gitup and Game of Trees are currently available as ports and packages. Futu= re work will evaluate them as candidates for the base system. Remaining work includes continuing with refinements to Git documentation in= the Handbook, committing new and updated repository hooks for managing branch content and commit mail, and surveying pre-commit hooks to use the CI clust= er to build release artifacts. Priorities have been set for the next working g= roup tasked with refining our Git workflow. The first meeting will be in mid-October. Sponsor: The FreeBSD Foundation (in part) =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 LLDB Debugger Improvements Links: Moritz Systems Project Description URL: link:https://www.moritz.systems/blo= g/ freebsd-kgdb-support-in-lldb/ Progress Report 1 URL: https://www.moritz.systems/blog/ improving-gdb-protocol-compatibility-in-lldb/ Progress Report 2 URL: https://www.moritz.systems/blog/ improving-gdb-register-model-compatibility-in-lldb/ Git Repository URL: https://github.com/moritz-systems/llvm-project Contact: Kamil Rytarowski Contact: Micha=C5=82 G=C3=B3rny According to the upstream description, "LLDB is a next generation, high-performance debugger. It is built as a set of reusable components which highly leverage existing libraries in the larger LLVM Project, such as the Clang expression parser and LLVM disassembler." FreeBSD includes LLDB in the base system. At present, it has some limitatio= ns compared to the GNU GDB debugger, and does not yet provide a complete replacement. This project spans from July 2021 to January 2022 and aims to = make LLDB suitable for debugging FreeBSD kernels. The work so far was focused on improving the compatibility between LLDB and other servers implementing the GDB Remote Protocol. Multiple bugs were fixed that limited LLDB=E2=80=99s functionality when interfacing with GNU GDB=E2= =80=99s gdbserver and QEMU=E2=80=99s gdbserver implementations. Support for debugging executables= running on gdbserver architectures other than amd64 was fixed, and was explicitly test= ed on arm64 and i386. This effort also resulted in adjusting lldb-server=E2=80=99s implementation= to conform better to the standard set by GDB. Thanks to these improvements, the LLDB client needs to provide less divergent code paths depending on the server u= sed, and the single code path used is tested more thoroughly. The work also involved improvements to the LLDB API and code deduplication, that result in reducing the maintenance effort and lowering the bar for fut= ure contributions. The test coverage was improved, increasing the likelihood th= at any future problems will be detected before they affect users. The introduced changes are expected to be shipped with LLDB 14.0. Sponsor: The FreeBSD Foundation =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 Linux compatibility layer update Contact: Dmitry Chagin, Contact: Edward Tomasz Napierala, The goal of this project is to improve FreeBSD=E2=80=99s ability to execute= unmodified Linux binaries. The current support status of specific Linux applications is being tracked on the Linux app status Wiki page. The vdso(7) implementation was reworked. The futex(2) support was overhaule= d to make use of FreeBSD=E2=80=99s native umtx mechanism. It now supports priority-inheritance futexes, in addition to fixing several bugs. The rt_sigsuspend(2) and sigaltstack(2) syscalls are now supported on ARM64. The faccessat2(2), clone3(2) system calls are now implemented. The CLONE_CLEAR_RESETHAND option is now supported. The prctl(2) syscall now supports PR_SET_NO_NEW_PRIVS. The ptrace(2) syscall now supports PTRACE_GET_SYSCALL_INFO, which is a prerequisite to support newer strace(1) versions. There is ongoing work to make Linuxulator on arm64 on par with the amd64 on= e; right now it=E2=80=99s good enough for development work. Sponsor: EPSRC (Edward=E2=80=99s work) =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 Sound mixer improvements Links: GSoC 2021 project article URL: https://wiki.freebsd.org/ SummerOfCode2021Projects/SoundMixerImprovements Contact: Christos Margiolis Contact: Hans Petter Selasky This project is an attempt to improve the capabilities of the OSS sound mix= er on FreeBSD. This means a new mixer(3) library, a complete rewrite of mixer(= 8), and updates to sound(4). Development started during Google Summer of Code 2021, but will likely cont= inue independently. Applied changes: =E2=80=A2 Implement OSS mixer (un)muting ioctls in sound(4) (commit 0f8da= fb45859). =E2=80=A2 Implement playback/recording mode sysctl (commit ed2196e5df0c). =E2=80=A2 Implement mixer(3) and new version of mixer(8) (commit 903873ce= 1560). Patches, comments and discussion are all welcome. =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 Base System OpenSSH Update Links: OpenSSH URL: https://www.openssh.com/ Announcement to freebsd-security@ URL: https://lists.freebsd.org/pipermail/ freebsd-security/2021-September/010473.html Contact: Ed Maste OpenSSH, a suite of remote login and file transfer tools, was updated from version 7.9p1 to 8.7p1 in the FreeBSD base system. FreeBSD base OpenSSH includes a number of local bug fixes, configuration changes, and small features. As part of the work for this update, I submitt= ed some of these upstream and am preparing to do the same with the remaining changes. OpenSSH now supports FIDO/U2F devices, although additional work is required= to enable this in the FreeBSD base system. This includes importing a pair of dependencies: libcbor, and libfido2. Within the next couple of months I exp= ect to import these, enable FIDO/U2F support, and update to OpenSSH version 8.8= p1. NOTE: OpenSSH 8.8p1 will disable the ssh-rsa signature scheme by default, so some additional work is required for this next update. For more information please see the Important note for future FreeBSD base system OpenSSH update mailing list post. Sponsor: The FreeBSD Foundation =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 Kernel Updates to kernel subsystems/features, driver support, filesystems, and mor= e. Arm64 improvements Links: Pointer Authentication Review URL: https://reviews.freebsd.org/D31261 Contact: Andrew Turner FreeBSD has been ported to the Arm Armv8-A Architecture Envelope Model (AEM= ), an Armv8 architecture simulator. AEM is useful for Armv8 development and testing, because it supports different configurations, including the abilit= y to enable or disable different extensions. As part of this work, the virtio le= gacy pci driver was fixed and ACPI resource parsing code was updated to work with the ACPI tables that the model provides. Libmd(4) has been updated to use the sha256 instructions when available. Th= is can lead to a large performance improvement when these instructions are available. For example, on the Apple M1 under a hypervisor, the time to calculate the sha256 of a 1GB file has decreased from a median of 3.46s to 0.5s. Using an ifunc (indirect function) in a static binary is now supported. This will allow different implementations of a function to be used depending on which hardware it is being run on. Using an ifunc in dynamic binaries was already supported. The arm64 ID register definitions have been updated to match the Armv8.5 specification and other special registers have been updated to the Armv8.7 spec. There have been numerous cleanups in decoding the arm64 ID registers in the kernel to ensure we provide a consistent view of the hardware to userspace = if it reads the emulated ID register directly, or uses an ELF HWCAP value. There has been early work on supporting the Arm Reliability, Availability, = and Serviceability (RAS) extension. The external aborts it may use are now hand= led in the kernel. Support for the Arm Pointer Authentication extension is under review. This extension allows programs to use new instructions that add a hash to unused bits in a code or data pointer. They can then later check the hash in a way that will either, depending on the CPU, create an invalid pointer or raise = an exception. This can be used to protect the function return address from bei= ng overwritten, making Return Oriented Programming (ROP) attacks difficult. The change supports both userspace and kernel pointer authentication. It is wai= ting on debugger changes to be sent upstream so lldb can clear the hash when nee= ded, e.g., in a stack trace. Work has started on supporting the Branch Target Identification extension. = This adds a flag to the page tables to disallow unintended targets from some bra= nch instructions. When a CPU branches to a new location from a register, the CPU will check if the instruction is correct. This will protect, e.g., against a function pointer being called when it points to the middle of a function. T= he kernel has been built with this feature enabled and tested in the Arm AEM. Sponsor: The FreeBSD Foundation =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 FreeBSD on Microsoft HyperV and Azure Links: Microsoft Azure article on FreeBSD wiki URL: https://wiki.freebsd.org/ MicrosoftAzure Microsoft HyperV article on FreeBSD wiki URL: https://wiki.freebsd.org/Hype= rV Contact: Microsoft FreeBSD Integration Services Team Contact: freebsd-cloud Mailing List Contact: The FreeBSD Azure Release Engineering Team Contact: Wei Hu Contact: Li-Wen Hsu The 13.0-RELEASE image on Azure Marketplace has been published. The changes for building official images on Azure Marketplace, which fulfill the requirements of Azure and FreeBSD cloud images like disk layout and UEFI for Gen2 VM, along with some minor improvements like configurations to spee= d up booting, have been imported. Above tasks are sponsored by The FreeBSD Foundation, with resources provide= d by Microsoft. Microsoft Azure Network Adapter (MANA) is the new network adapter from Microsoft which will be available in the Azure public cloud. It provides SR= -IOV NIC as a Virtual Function (VF) to guest OS running on Hyper-V. Wei has been working on its driver for a while and committed in this quarter. This task is sponsored by Microsoft. Work in progress tasks: =E2=80=A2 Build and publish gen2 vm image to Azure Marketplace =E2=80=A2 Build and publish ZFS-based image to Azure Marketplace =E2=80=A2 Upstream local modifications of Azure agent =E2=80=A2 Update Azure agent port to the latest version Open tasks: =E2=80=A2 Update FreeBSD related doc at https://docs.microsoft.com =E2=80=A2 Support FreeBSD in Azure Pipelines =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 Improved amd64 UEFI boot Contact: Konstantin Belousov UEFI BIOS on PC provides a much richer and more streamlined environment for pre-OS programs, but also imposes some requirements on the programs that are executed there, OS loaders in particular. One such requirement is that the loader must coordinate its memory use with the BIOS, only using memory that= was allocated for it. Even after the loader handoff to the operating system ker= nel, there are still some memory regions that are reserved by the BIOS for diffe= rent reasons. Examples are runtime services code and data. On the other hand, legacy/CSM BIOS boot works with memory completely differently; there are known memory regions that hold BIOS data and must be avoided. Otherwise, the memory is considered free for loader and OS to use.= (Of course it is not that straightforward, the definition of known regions is u= p to the vendor and there are a lot of workarounds there.) The BIOS boot puts the kernel and preloaded data (like modules, memory disk, CPU microcode update etc) at the contigous physical memory block starting at 2M. This algorithm goes back to how the i386 kernel boots. Also, when preparing to pass control to the kernel, the loader creates very special temporary mappings, where the low 1G of physical address space is mapped 1:1 into virtual address space, and then repeated for each 1G until = the virtual memory end. The kernel knows about its physical location and the temporary mapping, and constructs kernel page tables assuming that the phys= ical address of the text is at 2M. This mechanism of loader to kernel handoff was left unchanged when the load= er gained support for the UEFI environment. The loader prepares kernel and auxiliary preload data in a so-called staging area while UEFI boot services= are active, and after EFI_BOOT_SERVICES.ExitBootServices(), the temporary mappi= ng is activated and the staging area is copied at 2M. An advantage at that time was that no changes to the kernel were needed. But there are issues; the biggest is that memory at 2M might be not free for re= use. For instance, BIOS runtime code or data might be located there. Or there mi= ght be no memory at 2M at all. Or trampoline page table or code, or even some p= arts of the staging area overlapping with the 2M region where staging area is copied. The outcome was a hard to diagnose boot time failure, typically a h= ard hang when the loader started the kernel. Another limitation is the 1G transient mapping, which due to copying means = that the total size of preloaded data cannot exceed around 400M for everything, including kernel, memory disks, and anything else. Also the code to grow the staging area on demand was quite unflexible, only able to grow the staging = area in place. The work described in this report allows the UEFI loader on amd64 to start = the kernel from the staging area without copying. Kernel assumptions about the hand-off were explicitly identified and documented. The kernel only requires the staging area to be located below 4G together with the trampoline page t= able (this is a consequence of CPU architecture requiring 32bit protected mode to enter long mode), be 2M aligned and the whole low 4G mapped 1:1 at hand-off. The kernel computes its physical address and builds kernel page tables accordingly. Making the kernel boot with staging area in-place required identifying all places where the amd64 kernel had a dependency on its physical location. The most complicated part was application processors startup, which required rewriting initialization code, which we were able to streamline as result. = In particular, when an AP enters paging mode, it does so straight into the cor= rect kernel page table, without loading intermediate trampoline page table. The updated loader automatically detects if the loaded kernel can handle in-place staging area ('non-copying mode'). If needed, this can be overridd= en with the loader=E2=80=99s copy_staging command. For instance, 'copy_staging= enable' tells the loader to unconditionally copy the staging area to 2M regardless = of kernel capabilities (default is 'copy_staging auto'). Also, the code to grow the staging area was made much more robust, allowing it to grow without hand-tuning and recompiling the loader. Sponsor: The FreeBSD Foundation =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 ENA FreeBSD Driver Update Links: ENA README URL: https://github.com/amzn/amzn-drivers/blob/master/kernel/fbs= d/ ena/README Contact: Michal Krawczyk Contact: Artur Rojek Contact: Marcin Wojtas ENA (Elastic Network Adapter) is the smart NIC available in the virtualized environment of Amazon Web Services (AWS). The ENA driver supports multiple transmit and receive queues and can handle up to 100 Gb/s of network traffi= c, depending on the instance type on which it is used. Completed since the last update: =E2=80=A2 Update ENA driver to v2.4.1 =E2=80=A2 Introduce full kernel RSS API support =E2=80=A2 Allow reconfiguration of the RSS indirection table and hash key =E2=80=A2 Support netmap on the c6gn/m6i AWS instance types =E2=80=A2 Fix race between detach function and some of the procedural sys= ctl nodes =E2=80=A2 Add new statistics counters =E2=80=A2 Improve safety of the reset handling routine =E2=80=A2 Avoid mbuf collapse on Tx path for the LLQ condition Work in progress: =E2=80=A2 Prototype the driver port to the iflib framework =E2=80=A2 MFC the ENA v2.4.1 driver to the FreeBSD 11/12/13-STABLE branch= es =E2=80=A2 Add IPv6 L4 checksum offload support to the driver Sponsor: Amazon.com Inc =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 Hole-punching support on FreeBSD Links: Commit 0dc332bff200 URL: https://cgit.freebsd.org/src/commit/?id=3D 0dc332bff200c940edc36c4715b629a2e1e9f9ae Commit 9e202d036dd6 URL: https://cgit.freebsd.org/src/commit/?id=3D 9e202d036dd6f38ce0f578aa2086ebc358315bab Commit 5ee2c35751ef URL: https://cgit.freebsd.org/src/commit/?id=3D 5ee2c35751ef5d131222423bf3e25073f997c337 OpenZFS Pull Request #12458 URL: https://github.com/openzfs/zfs/pull/12458 Contact: Ka Ho Ng Hole-punching functionality allows turning a contiguous range of bytes into= a hole for a given file. File systems supporting hole-punching may deallocate= the file system space from the given file. One use case for the functionality i= s to convert TRIM/UNMAP/DEALLOCATE requests from a virtual machine guest to hole-punching calls on the host=E2=80=99s side, thus allows reclamation of = file system space when unneeded by the guest. A set of APIs and KPIs are added that developers can call to invoke hole-punching on a given file, if the underlying file system exposes that functionality. For file systems not supporting hole-punching there is a fallback implementation in the kernel which does zero-filling instead. Besi= des the APIs and KPIs addition, the truncate(1) utility is expanded by adding a= -d flag to support invoking hole-punching as well. At the time of writing this report, OpenZFS and tmpfs are the file systems = that support hole-punching. Sponsor: The FreeBSD Foundation =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 Intel Networking on FreeBSD Links: DPDK URL: https://github.com/DPDK/dpdk/tree/main/drivers/net Contact: Intel Contact: Kevin Bowling lem(4)/em(4)/igb(4) and ix(4) were updated with various common code improvements obtained from DPDK. There have also been several bug fixes from the community: =E2=80=A2 lem(4)/em(4)/igb(4) changes =E2=80=A2 ix(4) changes Intel has updated ixl(4) with various improvements: =E2=80=A2 ixl(4): Fix 2.5 and 5G speeds reporting and update shared code =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 Intel Wireless driver support Links: iwlwifi status FreeBSD wiki page URL: https://wiki.freebsd.org/WiFi/Iwlwifi Contact: Bjoern A. Zeeb The Intel Wireless driver update project aims to bring support for newer chipsets along with mac80211 LinuxKPI compat code. The dual-licensed Intel driver code was ported in the past for the iwm(4) native driver; using the LinuxKPI compat framework allows us to use the driver directly, with only v= ery minor modificationsi that we hope will be incorporated into the original driver. After the initial snapshot at the end of June, another snapshot was release= d in early September. Thank you to everyone testing on CURRENT and reporting bac= k. While we keep updating the driver and all the compat code needed for that, = the focus now is on stability and adding support for newer 802.11 standards. The driver is currently set to 11a/b/g and 11n will be next before we look at 1= 1ac. We are currently trying to get as much into FreeBSD as is possible and makes sense. Full integration into FreeBSD main is waiting for a policy update. For the latest state of the development or code, please follow the referenc= ed wiki page or the freebsd-wireless mailing list. We expect to release another snapshot soon and hope to also support stable/13 again with that one. Sponsor: The FreeBSD Foundation =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 Microchip LAN743x mgb(4) Device Driver Links: Commit adding mgb(4) driver URL: https://cgit.freebsd.org/src/commit/?id=3D 8890ab7758b8a03a68f3fe596f6a5446921631a5 Commit connecting mgb(4) module to the build URL: https://cgit.freebsd.org/= src/ commit/?id=3D543df609072fe49079c36d6bee510e1645edde3a Contact: Ed Maste Microchip=E2=80=99s LAN7430 and LAN7431 are PCIe Gigabit Ethernet interface= ICs, with an integrated PHY (LAN7430) or RGMII interface (LAN7431). In 2019 Gerald ND Aryeetey, a FreeBSD Foundation intern, developed the mgb(= 4) driver for these devices. It was added to the tree but not yet connected to= the build. Since it was committed a number of sweeping iflib changes were made, which included updates to mgb(4). I have addressed some outstanding issues in the driver, and have now added = the module to the build. It is available in -CURRENT snapshot images. The drive= r is functional, although some additional work is still needed. In particular, configuration of the Receive Filtering Engine, and VLAN and RX/TX checksum offload are required. Caveats and notes are described in the man page. I am very interested in feedback and test results. Sponsor: The FreeBSD Foundation =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 Fixes for msdosfs_rename VOP Contact: Konstantin Belousov Contact: Peter Holm Our msdosfs(5) implementation is old code and has a relatively large legacy cost. In particular, even though it got fine-grained locking and miscellane= ous bugfixes over time, sometimes a serious issue is found in it. Recently trasz@ found that msdosfs rename can be easily deadlocked. Further examination of rename code revealed a lot of issues with locking, potential= use after free, and filesystem structure corruption. As part of the update, locking in the msdosfs rename code was reworked. We = need to lock up to four vnodes, and check one path to ensure that rename does not create circular parent relations between directories. For that, the locking procedure was copied from UFS rename, where all vnodes except the first are locked in try-mode. Lockless relockup was added to msdosfs and the directory path checker was changed to non-blocking mode. During this work, all known issues were fixed and msdosfs passes the enhanc= ed stress2 suite of tests. Sponsor: The FreeBSD Foundation (kib=E2=80=99s contributions) =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 OpenZFS RAIDZ Expansion update Links: OpenZFS Pull Request URL: https://github.com/openzfs/zfs/pull/12225 video from 2021 FreeBSD Developer Summit URL: https://www.youtube.com/watch= ?v=3D yF2KgQGmUic slides from 2021 FreeBSD Developer Summit URL: https://docs.google.com/ presentation/d/1FeQgEwChrtNQBHfWSNsPK3Y53O5BnPh3Cz5nRa5GAQY/view news article from Ars Technica URL: https://arstechnica.com/gadgets/2021/06/ raidz-expansion-code-lands-in-openzfs-master/ Contact: Matthew Ahrens Project This feature allows disks to be added one at a time to a RAID-Z group, expanding its capacity incrementally. This feature is especially useful for small pools (typically with only one RAID-Z group), where there isn=E2=80= =99t sufficient hardware to add capacity by adding a whole new RAID-Z group (typically doubling the number of disks). FreeBSD=E2=80=99s ZFS implementation comes from the OpenZFS project. This w= ork will be integrated into the OpenZFS repo, with support for FreeBSD and Linux. Status The work is functionally complete, and a pull request has been opened. Remaining Work Remaining work includes some code cleanup, design documentation, addressing test failures. We also need to solicit code reviewers and respond to code review feedback. Sponsor: The FreeBSD Foundation =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 RFC1191 support in IPSEC tunnels Contact: Wojciech Macek The Semihalf team has been working on providing support for RFC1191 in IPSEC tunnels. This allows the PMTUD algorithm to dynamically discover the maximum path MTU the tunnel can handle and update tunnel parameters accordingly. As= a result, a better performance can be observed as there is no need for packet fragmentation. The newly introduced rework includes: =E2=80=A2 NEEDFRAG support for IPSEC commit d9d59bb1af1 =E2=80=A2 PMTUD for IPv4 IPSEC over IPv6 link commit 4f3376951d70 =E2=80=A2 Security fix as per RFC1191 specs commit b4220bf387e6 =E2=80=A2 PMTUD support for IPv6 tunnel commit 9dfc8606eb80 Sponsor: Stormshield =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 Realtek rtw88 support Links: Rtw88 status FreeBSD wiki page URL: https://wiki.freebsd.org/WiFi/Rtw88 Contact: Bjoern A. Zeeb This project aims to bring in support for Realtek=E2=80=99s rtw88 chips. With the growing LinuxKPI compatibility code an initial port of the Realtek rtw88 driver was done. This gives us support for a second driver after Intel and helps to validate and grow the LinuxKPI code base. Changes and overall = time needed to get the driver compiling were very little. At the moment we are seeing DMA issues which prevent most people from loading firmware or using = the driver later on. Thanks to everyone who was brave enough to give this initial code drop a tr= y. While this is a leasure time project we would love to better support Realtek wireless devices and will keep working on this. For the latest state of the development or code, please follow the referenc= ed wiki page or the freebsd-wireless mailing list. =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 Marvell SDHCI improvements and ACPI support Contact: Bartlomiej Grzesik Contact: Marcin Wojtas The Semihalf team was working on the ACPI support for the Marvell Octeon TX2 CN913x and Armada 7k/8k SoCs' SD/MMC controller, as well as extending and improving the related generic parts of the FreeBSD OS. Applied changes: =E2=80=A2 Add ACPI_GET_PROPERTY to access Device Specific Data (DSD) comm= it b91fc6c43a81 =E2=80=A2 Introduce generic device_get_property/device_has_property, whic= h allow to obtain DT/ACPI properties with the same generic code commit 3f9a00e3b577 =E2=80=A2 Switch mmc_helper to device_* API, to access the controller des= cription from DT/ACPI in a unified way commit 8a8166e5bcfb =E2=80=A2 Add ACPI support for the sdhci_xenon driver commit d78e464d2330= and commit adbce5ff747b =E2=80=A2 Apply other minor improvements and fixes related to properties = parsing in core mmc code and sdhci_xenon driver. Sponsor: Semihalf =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 Stack gap handling improvements Contact: Dawid Gorecki Contact: Marcin Wojtas Stack gap is a feature that randomizes the stack address by creating a rand= om sized gap between the top of stack and strings area. The current implementa= tion of this mitigation can cause issues for some applications e.g. Firefox ( PR239873). Until now the only workaround for this problem was disabling the stack gap for those programs, as is done for ntpd. Semihalf team has been working on fixing the root causes of stack gap relat= ed problems. One of the issues could be observed when setting the stack limit to a low v= alue with setrlimit(2). Since the stack gap size can be significant, and the pro= cess had no knowledge of how large the stack gap is, this caused programs to abo= rt immediately after returning from a syscall due to the stack extending past = the limit. The fix involves increasing the soft resource limit (rlim_cur) by the size of stack gap during the setrlimit(2) call. This fixes the issue with n= tpd without disabling the stack gap entirely. The patch is currently under revi= ew. The second identified problem is related to the way the thread stacks are handled. Thread stacks are calculated using the kern.usrstack sysctl, which should point to the beginning of the stack. This sysctl returned a constant value depending on the ABI and the presence of the stack gap was ignored. A= new sysctl was introduced, and the thread library was updated to use it accordingly. Patches D31897 and D31898 are currently under discussion. These fix the issues with Firefox and Thunderbird not starting with the stack gap feature enabled. Sponsor: Stormshield =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 syzkaller on FreeBSD Contact: Mark Johnston Contact: Michael Tuexen < tuexen@FreeBSD.org> syzkaller is a coverage-guided operating system kernel fuzzer. See the syzkaller entry in the 2019q1 quarterly report for an introduction to syzkaller. In the past quarter we made a concerted effort to shrink the backlog of rep= orts =66rom the public syzbot instance. A number of long-standing locking bugs i= n the socket subsystem have been fixed, and the SCTP protocol implementation has = seen many bug fixes as well. Beyond that, many bugs in various other kernel subsystems have been fixed and the backlog has become substantially smaller over the past quarter. As a direct result of this effort, we have been able= to identify regressions more easily and fix bugs closer to the time of introduction. Work is still ongoing to further shrink the backlog. KASAN (Kernel Address SANitizer) was enabled in the default kernel configuration used by syzbot, which has greatly enhanced our ability to root-cause and fix kernel bugs. See the kernel-sanitizers entry in the 2021= q2 quarterly report for an introduction to KASAN and KMSAN. KASAN helps ensure that memory safety bugs manifest more deterministically, improving syzkalle= r=E2=80=99s ability to find reproducers and simplifying debugging. A KMSAN (Kernel Memory SANitizer) port was committed to FreeBSD=E2=80=99s m= ain branch in August. Some initial work has been done to make it usable by syzkaller (mainly, kcov(4) required several small modifications to work in a KMSAN-enabled kernel), and a number of bugs were found and fixed using priv= ate syzkaller instances. Goals for the next several months include: =E2=80=A2 Addition of a KMSAN target in syzbot. =E2=80=A2 Further reduction in the syzbot backlog. =E2=80=A2 Upstreaming syzkaller patches to support fuzzing of the Linuxul= ator. =E2=80=A2 Fuzzing using ZFS-based VM images. Sponsor: The FreeBSD Foundation =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 Using OCF in WireGuard Contact: John Baldwin I have looked at updating the data path crypto in the upstream WireGuard dr= iver to use the in-kernel OpenCrypto Framework for the data path. Data packets s= ent over a WireGuard tunnel are encrypted with the Chacha20-Poly1305 AEAD ciphe= r. Unlike TLS and IPsec, Wireguard uses an 8 byte nonce rather than a 12 byte nonce with this cipher. To date, most of the work has focused on updating OCF to better support multiple nonce (and tag/MAC) lengths for a given cipher. I resurrected an o= ld branch I had previously started on for this aimed at supporting all of the AES-CCM NIST KAT vectors many of which use non-default nonce and tag length= s. I have refined the approach to better fit the existing OCF model where nonce = and MAC lengths are properties of a session (similar to key lengths). (My earli= er branch had made the nonce length a property of individual operations instea= d.) Mostly this entailed extending the /dev/crypto interface to permit setting these parameters for a session. Existing tests for OCF run in userland and = use the /dev/crypto interface including both the cryptocheck utility and the NI= ST KAT vector tests. Building on these framework changes, I have extended the existing Chacha20-Poly1305 cipher in OCF to support both 8 and 12 byte nonces includ= ing in the accelerated ossl(4) driver. I also have a patch against the upstream WireGuard FreeBSD driver to make use of this for the dataplane and have verified that it interoperates with the stock WireGuard driver. Future work will focus on upstreaming the OCF changes as well as additional review of the upstream WireGuard driver. Sponsor: The FreeBSD Foundation =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 Intel Volume Management Device driver update Links: main branch commit URL: https://cgit.freebsd.org/src/commit/?id=3D 7af4475a6e31202a865b1dd3727018659b44470f Contact: Alexander Motin Intel VMD is used by Intel=E2=80=99s VROC (Virtual RAID on chip) to isolate= parts of PCI tree, including NVMe devices, behind one or several VMD devices. Each V= MD device has 3 memory windows to access config space and memory of its child devices, plus some number (I saw 19 and 33) of MSI-X interrupt vectors to forward their MSI and MSI-X interrupts through. The vmd(4) driver was first introduced in FreeBSD 13.0, but was found to ha= ve a number of problems addressed in this update: - The VMD device was made to l= ook more like a regular PCI-to-PCI bridge, implementing the regular pcib(4) interface and using the standard pci(4) bus driver on top. - Memory and bus numbers resource management was rewritten to properly handle resource reque= sts using memory windows of the VMD device. - Interrupt handling was completely rewritten to distribute child interrupts among available VMD MSI-X vectors, setting them up to be handled via standard OS mechanisms with minimal overh= ead instead of custom dispatching via taskqueue. Due to the limited number of vectors and routing abilities of VMD, children are limited to only one MSI = or three MSI-X vectors per device to avoid sharing. The limits can be tuned, depending on the number of VMD vectors and children. To improve the flexibi= lity the nvme(4) driver was made to work with a limited number of vectors, start= ing =66rom just one MSI/MSI-X if needed. Sponsor: iXsystems, Inc. =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 Ports Changes affecting the Ports Collection, whether sweeping changes that touch most of the tree, or individual ports themselves. Improve CPE Data in the Ports Collection Links: chkcpe URL: https://github.com/decke/chkcpe CPE on wiki.freebsd.org URL: https://wiki.freebsd.org/Ports/CPE CPE Dictionary URL: https://nvd.nist.gov/products/cpe Contact: Bernhard Froehlich Common Platform Enumeration (CPE) is an open standard for naming hardware a= nd software components. Originally developed by MITRE, it is now maintained by NIST under the aegis of the National Vulnerability Database. A CPE URI uniq= uely identifies a device or program by its vendor, product name, version, revisi= on, etc. NIST maintains the official CPE dictionary which lists CPE names for a= ll software versions that have ever been mentioned in an advisory. In the FreeBSD Ports Collection it has been possible to annotate CPE data w= ith USES=3Dcpe since 2014 but only around 1000 ports out of 30.000 did use it. = This is why a script called chkcpe was created to validate existing CPE data and find new possible matches automatically. Why do we need it? It allows comparing CPE URIs for installed packages against published vulnerability data and will give us a much better and more complete pkg aud= it. As a side effect we will also have a better overview of vulnerable ports in= the FreeBSD Ports Collection that need to be patched or updated. How can I help? In this phase there is no easy possibility for port maintainers to help. Creating separate PRs only to add CPE data does not make sense because the overhead is very high. This is why I did spend some time on chkcpe to impro= ve the review and commit workflow. Right now review and commit consumes around= 3 minutes per port. If you are a Ports Committer and want to help please get in touch! Open Tasks =E2=80=A2 Review remaining reports (~1800) and update ports when appropri= ate =E2=80=A2 Improve matching quality to find more possible matches =E2=80=A2 Support using CPE data in pkg audit =E2=80=A2 Scan for vulnerable ports in the Ports Collection =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 FreeBSD Erlang Ecosystem Ports update Links: FreeBSD Erlang wiki URL: https://wiki.freebsd.org/Erlang Erlang/OTP language URL: https://erlang.org/ Elixir language URL: https://elixir-lang.org/ Gleam language URL: https://gleam.run/ Contact: FreeBSD Erlang mailing list The Erlang runtime system, commonly known as the BEAM, provides a runtime t= hat is used by a number of programming languages and applications in the FreeBSD ports collection. Earlier this year, both Elixir and Erlang runtimes were brought up to date,= but as separate ports, to enable porters and users to test applications side by side. In Q3, the current runtimes have been brought across as defaults - this mea= ns that lang/elixir and lang/erlang are running as the latest releases of these superb programming languages and runtimes. Older releases of lang/erlang-runtime{21,22,23} are still available as port= s. The very old releases prior to OTP20 have been removed from the ports tree,= as they are no longer supported upstream either. Only newer OTP releases include the updated SSL application that will corre= ctly validate cross-signed certificates, as used in Let=E2=80=99s Encrypt=E2=80= =99s upcoming root certificate deprecations. Further details on these changes are well documented at Erlang/OTP impact of DST Root CA X3 expiration and DST Root CA X3 expiration update All of the NIF driver related ports that pull in other FreeBSD ports tree dependencies have been updated to match the newer lang/erlang release, and a number of ports that are not being updated in their upstream community, have therefore been marked as broken. The Erlang team is planning to: =E2=80=A2 remove the deprecated OTP20 and OTP21 runtimes in 2021Q4 =E2=80=A2 remove ports directly dependent on erlang- and elixir- language= s, where they are more commonly installed via mix and rebar3 tools, the standard community build tool chain. Additional testing and community contributions are welcome; please reach ou= t on the mailing list, especially if you are able to help testing of specific po= rt updates. =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 KDE on FreeBSD Links: KDE FreeBSD URL: https://freebsd.kde.org/ KDE Community FreeBSD URL: https://community.kde.org/FreeBSD Contact: Adriaan de Groot The KDE on FreeBSD project aims to package almost all of the software from = the KDE Community for the FreeBSD ports tree. The software includes a full desk= top environment called KDE Plasma (for both X11 and Wayland) and hundreds of applications that can be used on any FreeBSD machine. The KDE team (kde@) is part of desktop@ and x11@ as well, building the soft= ware stack to make FreeBSD beautiful and usable as a daily-driver graphics-based desktop machine. Q3 is summer in the northern hemisphere: bicycles were biked and mountains = were hiked and the team was psyched to chase the software we like. And there were plenty of things to chase: =E2=80=A2 Three CMake releases landed, ending up with CMake 3.21.3 and li= bpkg support that once again works with CPack to produce FreeBSD packages. =E2=80=A2 Monthly releases of KDE Frameworks, KDE Plasma, and KDE Gear ke= pt the exp-runs going. kde@ would like to thank Antoine for overseeing our many exp-run requests. =E2=80=A2 The KDE Plasma applications for monitoring the state of the system=E2=80=89=E2=80=94=E2=80=89ksysguard, Plasma system monitor, and = supporting libraries=E2=80=89=E2=80=94=E2=80=89received a number of updates. FreeB= SD support code has been merged upstream. =E2=80=A2 Across all of the Qt and KDE packages, an attempt was made to r= educe how "heavy" the dependencies are. In general this means removing developer-= only dependencies, avoiding the installation of test-code, etc. The underlyi= ng idea is to cut down the size of the installation when specific ports are installed, while preserving the "developer batteries included" characte= r of the meta-ports. =E2=80=A2 A runtime-incompatibility was introduced by MySQL 5.7.34, which= affected KDE=E2=80=99s personal-information-management applications and email. T= his was patched in the Qt ports. =E2=80=A2 The mixer application in KDE Plasma now defaults to using pulse= audio. =E2=80=A2 accountsservice was updated, and then patched with code from Op= enBSD. =E2=80=A2 kdiff3 was updated to 1.9.3, now with upstream patches for some= corner cases originally reported on FreeBSD. =E2=80=A2 kimageannotator and ksnip were updated, for nicer screenshots. =E2=80=A2 kraft, the small-business support application, was updated to v= ersion 0.97. =E2=80=A2 krita had an upstream release to address a performance issue, w= hich then landed in FreeBSD. =E2=80=A2 kstars, the interactive planetarium and sky-watching applicatio= n, was updated to 3.5.5. =E2=80=A2 latte-dock, used as an alternative launcher, updated to 0.10.2. =E2=80=A2 libphonenumber, Google=E2=80=99s library for dealing with all t= he ways phone numbers are represented around the world, received multiple updates. =E2=80=A2 maliit-framework, for on-screen keyboards, as added to the port= s tree. =E2=80=A2 pipewire was kept up-to-date. This is a next-generation video-h= andling framework, and is being increasingly used in Wayland environments for efficient passing of video data between applications. =E2=80=A2 poppler was updated to version 21.09, with significant speed im= provements. =E2=80=A2 sddm was made a little more robust when installed on its own, w= ith xinitrc support. =E2=80=A2 math/eigen2 was removed. =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 OpenSearch on FreeBSD Links: OpenSearch website URL: https://opensearch.org/ OpenSearch Community (unofficial) on Discord URL: link:https://discord.gg/ NmtQGAWY Contact: OpenSearch Team OpenSearch is a community-driven, open-source search and analytics suite derived from Apache 2.0 licensed Elasticsearch 7.10.2 & Kibana 7.10.2. It consists of a search engine daemon, OpenSearch, and a visualization and user interface, OpenSearch Dashboards. OpenSearch enables people to easily inges= t, secure, search, aggregate, view, and analyze data. These capabilities are popular for use cases such as application search, log analytics, and more. = With OpenSearch people benefit from having an open-source product they can use, modify, extend, monetize, and resell how they want. After the release of OpenSearch 1.0.0, a FreeBSD OpenSearch team was create= d to coordinate the efforts for porting it to FreeBSD. Because ElasticSearch 7 a= nd Kibana 7 were already in the ports tree, we could rely on these ports to get started quickly (kudos to the elastic@ team) and could focus on the parts t= hat already changed between the previous codebase and the fork. The ports have = been committed to the FreeBSD ports tree as textproc/opensearch and textproc/ opensearch-dashboards, and currently provide the latest 1.0.1 version of OpenSearch. Contributing The ports have been thoroughly tested in our testing environments and on so= me production workloads, but we are actively looking for feedback from users. = Feel free to send us an email to report successes or failures. =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 Valgrind - Official Support for FreeBSD has Landed Links Valgrind Home Page URL: https://www.valgrind.org/ Valgrind News URL: https://www.valgrind.org/docs/manual/dist.news.html Contact: Paul Floyd Valgrind is an instrumentation framework for building dynamic analysis tool= s. There are Valgrind tools that can automatically detect many memory manageme= nt and threading bugs, and profile your programs in detail. You can also use Valgrind to build new tools. With the release of version 3.18.0 of Valgrind, official FreeBSD support has landed upstream. The two supported architectures are amd64 and i386 (x86). The next step will be to update the FreeBSD port. This will involve switchi= ng =66rom code that was maintained out-of-tree for over 15 years to using the official upstream tarball. As Valgrind is closely tied to operating system details, obtaining official FreeBSD support was the result of significant effort from dozens of develop= ers. =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 Wine on FreeBSD Links Wine home page Contact: Gerald Pfeifer Contact: Damjan Jovanovic < damjan.jov@gmail.com> Wine allows running Windows programs on FreeBSD. This quarter we focused on the wine-devel port that tracks mainline development, followed half a dozen of version updates, simplified the port, removed three options (SDL, VKD3D, VULKAN) which are unconditionally active now, and fixed a number of portability issues. These changes will make their way into the primary Wine port over the coming weeks. After working on our Wine ports for more than 21 years, maintaining for more than 19 years, time has come to hand over the baton. Luckily Damjan has stepped up and is going to look after wine-devel and associated ports - thanks! Help with the following is still very welcome: =E2=80=A2 WineHQ bug 50257 =E2=80=A2 FreeBSD Bugzilla 257533 =E2=80=A2 Maintain daily (or at least regular) test builds of upstream Wi= ne. This quarter this triggered two dozen fixes in support of FreeBSD upstream, though usually it=E2=80=99s quite less effort. =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 Ztop Links: Repository Port Contact: Alan Somers ztop is a new utility that displays ZFS datasets' I/O in real time, like to= p, but for ZFS. Unlike the existing zpool iostat, which only displays traffic = at the level of a pool, ztop displays it at the level of individual datasets. Previously, there was no tool that could display this information. The Prometheus Node Exporter can export it into Prometheus, from which it can be viewed after the fact with various other tools, but that requires a large s= tack of software, and isn=E2=80=99t real-time. I started ztop this quarter, and it is now fully functional. However, it has revealed a performance problem within the kernel. In the presence of more t= han a few thousand datasets, the sysctl interface is too slow and ztop becomes sluggish. Future work, if I have the time, will address that problem. Sponsor: Axcient =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 Miscellaneous Objects that defy categorization. -CURRENT compilation time analysis Links: Bug 257141 URL: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D257141 Discussion on freebsd-current URL: https://lists.freebsd.org/archives/ freebsd-current/2021-September/index.html#msg511 Visual chart of buildworld by stages URL: https://people.freebsd.org/wosch/ build-time/buildworld/ Contact: Wolfram Schneider Re-building FreeBSD from source takes a lot of CPU resources. Depending on = your machine it takes between 20min and several hours. At the end of `make buildworld' we log the real time and which parameters are used for parallel build. E.g. time make -j $(sysctl -n hw.ncpu) buildworld > buildworld.log 2>&1 tail buildworld.log >>> World build completed on Sat Sep 4 20:58:00 UTC 2021 >>> World built in 7235 seconds, ncpu: 3, make -j3 7235.61 real 20527.30 user 915.88 sys The build process runs in several steps. It would be great to know which st= ep takes most of the time, and what are the effects of special build parameter= s. With a small patch in Aug 2021 we get this information now: egrep '>>> stage| real ' buildworld.log >>> stage 1.1: legacy release compatibility shims 0.28 real 0.18 user 0.10 sys >>> stage 1.2: bootstrap tools 165.99 real 472.58 user 11.56 sys >>> stage 2.1: cleaning up the object tree 21.47 real 36.96 user 14.14 sys 15.87 real 29.14 user 11.87 sys >>> stage 2.3: build tools 2.42 real 3.79 user 0.62 sys >>> stage 3: cross tools 9.92 real 18.49 user 1.75 sys >>> stage 3.1: recording build metadata 0.07 real 0.01 user 0.06 sys >>> stage 4.1: building includes 16.62 real 36.46 user 9.48 sys >>> stage 4.2: building libraries 5440.89 real 15724.60 user 482.58 sys >>> stage 4.3: building lib32 shim libraries 615.91 real 1654.77 user 164.58 sys >>> stage 4.4: building everything 937.23 real 2540.06 user 205.47 sys In this example, we spent most of the time in "stage 4.2: building librarie= s", 77% of the CPU time and 75% of the real time. Now running the buildworld wi= th the parameter WITHOUT_TOOLCHAIN=3Dyes we get a 3.3x faster build. Instead o= f 2h it will be done in 36 minutes! time make -j $(sysctl -n hw.ncpu) WITHOUT_TOOLCHAIN=3Dyes buildworld > buil= dworld.log 2>&1 >>> World build completed on Fri Sep 17 12:31:41 UTC 2021 >>> World built in 2207 seconds, ncpu: 3, make -j3 2207.44 real 5710.83 user 676.16 sys egrep '>>> stage| real ' buildworld.log >>> stage 1.1: legacy release compatibility shims 0.35 real 0.20 user 0.16 sys >>> stage 1.2: bootstrap tools 20.47 real 51.98 user 5.12 sys >>> stage 2.1: cleaning up the object tree 20.92 real 34.45 user 13.57 sys 16.33 real 28.59 user 12.33 sys >>> stage 2.3: build tools 2.59 real 3.90 user 0.86 sys >>> stage 3: cross tools 10.46 real 18.62 user 2.35 sys >>> stage 3.1: recording build metadata 0.07 real 0.03 user 0.05 sys 0.08 real 0.03 user 0.05 sys >>> stage 4.1: building includes 15.50 real 33.03 user 9.29 sys >>> stage 4.2: building libraries 750.31 real 1962.43 user 218.60 sys >>> stage 4.3: building lib32 shim libraries 684.05 real 1780.35 user 213.22 sys >>> stage 4.4: building everything 677.87 real 1787.13 user 186.82 sys Using WITHOUT_TOOLCHAIN=3Dyes is fine as long as there are no major LLVM co= mpiler changes. If you dislike this feature or suspect it is causing trouble you can disabl= e it with the variable TIME_ENV=3D"" Next task: get more detailed timing information for the long-running stages (4.2, 4.3, 4.4) =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 Third-Party Projects Many projects build upon FreeBSD or incorporate components of FreeBSD into their project. As these projects may be of interest to the broader FreeBSD community, we sometimes include brief updates submitted by these projects in our quarterly report. The FreeBSD project makes no representation as to the accuracy or veracity of any claims in these submissions. Gitlab 14.3 available Links: Gitlab 14.3 New Features URL: https://about.gitlab.com/releases/2021/09/22/ gitlab-14-3-released/ Contact: Matthias Fechner GitLab is the DevOps Platform. Bring velocity with confidence, security wit= hout sacrifice, and visibility into DevOps success. Version 14.3 now available on FreeBSD. =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 helloSystem Links: Documentation URL: https://hellosystem.github.io/ Contact: Simon Peter Contact: #helloSystem on irc.libera.chat, mirrored to #helloSystem:matrix.o= rg on Matrix What is helloSystem? helloSystem is FreeBSD preconfigured as a desktop operating system with a f= ocus on simplicity, elegance, and usability. Its design follows the =E2=80=9CLes= s, but better=E2=80=9D philosophy. Q3 2021 Status =E2=80=A2 Version 0.6.0 of helloSystem has been published including many = contributed features and bugfixes =E2=96=A1 Improved window management with KWin as the window manager =E2=96=A1 Simplified Filer file manager =E2=80=A2 Contributors have started to port the helloSystem desktop envir= onment, helloDesktop, to the FreeBSD Ports and Packages Collection (see changel= og at https://github.com/helloSystem/ISO/releases/tag/r0.6.0 for details) Installable Live ISO images and a full changelog are available at https:// github.com/helloSystem/ISO/releases/tag/r0.6.0 Contributing Help is wanted in a number of areas, especially in the areas of the FreeBSD core OS and kernel, and Qt/C++. =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 Containers & FreeBSD: Pot, Potluck & Potman Links: Pot on github URL: https://github.com/pizzamig/pot Potluck Repository & Project URL: https://potluck.honeyguide.net/ Potluck on github URL: https://github.com/hny-gd/potluck Potman on github URL: https://github.com/grembo/potman Contact: Luca Pizzamiglio (Pot) Contact: Stephan Lichtenauer (Potluck) Contact: Michael Gmelin (Potman) Pot is a jail management tool that also supports orchestration through Noma= d. In the last quarter, a new release 0.13.0 with a number of major new featur= es was made available. Layered images allow a split into a foundation image component that only changes seldom and that e.g. contains the basic jail and packages and a "le= af" image component on top with potentially small additions that might change m= ore frequently, like software built in a CI pipeline. Since it is not the compl= ete image that has to be rebuilt each time, image creation and distribution can= be sped up immensely. Also a copy-out command has been included where the container state that was initialised from within the container can be made persistent and reinjected into additional containers afterwards. Potluck aims to be to FreeBSD and Pot what Dockerhub is to Linux and Docker= : a repository of Pot flavours and complete container images for usage with Pot= and in many cases Nomad. Here we had a busy quarter. Not only did we commit a number of new images l= ike Nextcloud which can be deployed via Nomad, but the images used to build the foundation of a virtual data center (Nomad, Consul and Vault) themselves ha= ve received major updates. For these images, further improvements for even better security and reliabi= lity will likely be finished in the coming quarter. Also, we are aware that right now the advantages of the container approach = as it is described in Virtual DC Part I/Part II/Part III are not yet obvious a= nd transparent enough and also no longer completely up to date, so we plan to provide additional documentation as soon as we find the time to do so. Potman aims to simplify building Pot images with Vagrant and VirtualBox bas= ed on the Potluck approach, e.g. as part of a DevOps workflow for software development including testing and publishing them to a repository. Here, not too much has happened over the last quarter but the current idea = is to incorporate additional features in the medium to longer term to modulari= se and simplify the image build definitions and then utilise Potman in the Pot= luck library build process. As always, feedback and patches are welcome. =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 WireGuard on FreeBSD Stabilizes, Eyes Upstreaming Links WireGuard URL:https://www.wireguard.com/ wireguard-freebsd codebase URL:https://git.zx2c4.com/wireguard-freebsd/ Contact: Jason A. Donenfeld WireGuard is a secure tunneling protocol that lives in the kernel. For the last quarter, the wireguard-freebsd codebase has been quite stable = and complete. For a while, there were rapid-fire releases fixing issues, and a = lot of effort was made to track down every bug report on bugs.freebsd.org, IRC,= the mailing list, or elsewhere. But by now, the reports have dried up, and most= ly users come to IRC with questions on usage and integration, the usual types = of things associated with a stabler project. We also have automated CI now for each commit, compiling and running a small smoke test on wireguard-freebsd= =E2=80=99s supported releases=E2=80=89=E2=80=94=E2=80=8912.1, 12.2, and 13.0. At some = point, hopefully that small smoke test will expand to include the larger battery of tests from Linux. The wireguard-freebsd repository has been geared around being an out-of-tree kmod, which is distributed in ports. But it is also organized to be eventua= lly upstreamed. To that end, the repository maintains two files: compat.h and support.h. compat.h contains polyfills of code that exists in FreeBSD=E2=80= =99s main branch but does not exist in various older releases, with ifdefs for each of the various releases we support. On the other hand, support.h contains code that is not yet in FreeBSD=E2=80=99s main branch. The goal is to eventually= move all the code from support.h into compat.h, at which point, the repository will = be ready for upstreaming. As of writing, there=E2=80=99s basically only one re= al function left=E2=80=89=E2=80=94=E2=80=89sogetsockaddr=E2=80=89=E2=80=94=E2=80=89and = then two convenience macros that need to be sent upstream for consideration by ConcurrencyKit. A significant aspect that isn=E2=80=99t in support.h, though, is the crypto= graphic primitives that the code uses. The files crypto.c and crypto.h contain bori= ng C "reference implementations" of ChaCha20Poly1305, XChaCha20Poly1305, Blake2s, and X25519 (which is formally verified via MIT=E2=80=99s fiat-crypto projec= t). These four algorithms are used by the handshake path on very small inputs for WireGuard=E2=80=99s key exchange, and will hopefully be making their way to= sys/crypto/ in the FreeBSD tree as just ordinary functions. On the flip side, the datap= ath uses an entry point of ChaCha20Poly1305 that works on mbufs (which might be rather large) and is performance critical. To that end, jhb@ has been impro= ving OCF for WireGuard=E2=80=99s particulars. The next step will then be moving = our current calls from chacha20poly1305_{en,de}crypt_mbuf in wg_noise.c to instead call= out to OCF, submitting crypto_buffer`s of type `CRYPTO_BUF_MBUF. This will automatically benefit from Andy Polyakov=E2=80=99s optimized ChaPoly implem= entations that OCF has long since imported from OpenSSL. When we make the move to OCF, it=E2=80=99s likely that the wireguard-freebs= d repo as-is will become "wireguard-freebsd-compat", which will be explicitly aimed at backports to earlier FreeBSD releases for ports, while a new wireguard-free= bsd repository will be a whole FreeBSD tree, where we can work directly on integration patches for upstream. That repository will also have an imported version of the wg(8) utility from wireguard-tools, which I=E2=80=99ll be re= licensing as MIT. I=E2=80=99m quite excited for the upcoming quarter and seeing how much of wireguard-freebsd we=E2=80=99re able to land upstream. =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2= =94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94= =81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81=E2=94=81= =E2=94=81=E2=94=81=E2=94=81=E2=94=81 --66dsezfsnajsewcm Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAABCgB9FiEEDonNJPbg/JLIMoS6Ps5hSHzN87oFAmGSjzBfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDBF ODlDRDI0RjZFMEZDOTJDODMyODRCQTNFQ0U2MTQ4N0NDREYzQkEACgkQPs5hSHzN 87rCJQf+L85vcCZetfg8jx9wmIkBX8z1Sy4P0k0JYAlDU64bdSorQfv9iehSapMd jGKLOhD5oQjFht/2u4uM9bBYMDBe53JSSo9NUSdcjPDsHcwLbZPKbxNlSZ6GOX6U UmAGftRiXLTIX2DNTeNQmtUzd/Os66/13RTaUlkAg2L9zHxX6ImXWk27EWpsR6Nn oY4gXT4/px750uBdYPv1HxGxLpHIMy4E46T7UOcrc3UmbhN+lAf6fj+yNIx04ur5 IYgPv8vAFffaTjvF/YzPbPj9L5UJhCzTQed8IE8Xbsl4r+NKKmFRCk0Tb+IIUiWA vCnZ8iOJWV9vWTOZgxMHWD/43oxwyQ== =n3Dy -----END PGP SIGNATURE----- --66dsezfsnajsewcm-- From nobody Mon Nov 15 18:14:39 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id D9EF21892B3F for ; Mon, 15 Nov 2021 18:14:55 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-22.consmr.mail.gq1.yahoo.com (sonic301-22.consmr.mail.gq1.yahoo.com [98.137.64.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HtHR21xzNz3hbV for ; Mon, 15 Nov 2021 18:14:54 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637000085; bh=C2icfc7aKDYXON8YieUnvcy1faVtAkd3BnU16MgSNdc=; h=From:Subject:Date:Cc:To:References:From:Subject:Reply-To; b=hmxW6lXTw5hb97MiTGhTXc1UdA+NE1ykFIPjmZei+qDKVl8b9w/CB7dVnedG9ZRpz4kvURi8SRbKRTmUQAwSYz/0ZuH/cVko2HgQaTKh+RselMbC2woiYq7lAvKVppCgK6Hyg0bjJ45EF2dki5ho0dDCed+Et3WCswCIMUOvyrAt4bE7RDWoAnS0XAjEFLMrNEoyR34sBqqR6pL+Uh37DtVucqzCY9dwobVWnQohjerxHPy7Dx86OiEpdt9DKS7PWk7+VkFIxA5UBEQ1edNYY2nrHMg8tidjGDU/LVnj0lVGk8CRhA9OKEtBQBv/qGkJkqw9xyjJbI0mt8klL7OyGg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637000085; bh=X/Mik6OZMLbwG2czLS2/itDJjd0cFP6JanHnZ42Da0e=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=QdUed6W5gGfVPoI51C14DB8v2MStpvevd2wYW0gz6iUV/61F2/VRbpNAVaBvC9qeJwJU/5LTyoOe+QnIuj2woC/XNgG+T56GtneSp03hT47XE9l0o0X2rJx3j2LoF2SpXt2IM4VGe3sl5wh1WWa7IHxsKV26N9O2kJ8L6mgMmGy0ohwzT/xyK+v+ndj0viSChHV21zJ5WW/JGiykSKqrD5bPvHfD9y4VrEjtuLlfX/5/D3UlVYg1mNSZLCOl+qKkJUQ9uY+MzrEtPOfKDPFs/dnqgKqlK6ykO1Nw3SH+PFWxQDw8tKyHfQ2r9oylM+tYQ6adkmHxY7xB9MG8rZ2t7A== X-YMail-OSG: UytF20kVM1nhbx4zyo8Xyll7v8xTjffuhLe._1z2rEHfWWebjGHzkaehMrrDpvf MDfgD1N4w7_iadJyCvIYZ37ZnDlWcS7ofC0eZxRZ2eUGz6D9D00sDE1300M0ly4_KTjmRWfODWhr 8wTcO0BLOqB7cXFm7WHossMq9DLJ6XTvun3rgCj85DjOJJpwhC0OU8iUB6PglS2v5GbZAJlxd6Ki T9ghuBJ6MHHqCITq9L3xkho1uuAMV0pgUzTe8zPrf0mjrUFiZcIvH6xdRZ6lKxMHF6Btui.kH27C DIJdhNKTaerb6YvWJqQKY0Osjkrd4opCVFrro_rTet.Eag4W_eNNGPguVA1j6xktd30WLWB1bovG gAY_nD8iF_IZgfFDIkuVrkqxBHA5kbAGR517HkO3PxXUopAa0PNYeuP.CYeNa5QC5Bj12spDSXeN O3ldDqWXiE.hIriKW6U5f5RHAHc6D8JuZBqrnqF4CXsSKWmeBiNYjz.AzxOMAoGTFD.Chc_vE7cq HUmO__nQFya41XiiZkarKegCrjISkQ755TDzeiwOIx0Fph6kH6W9EtX4W8IGIDRYZhpLhCiKa1EK pmzEMiTMnQUdj1eFlA_7QMyxMYZBZ5Kle3zr4ss_mfEIoVIDYUNmydBQZjNsKS1q_2Cg4LgqKPtn X5BvQFXY7tnkXOjnuWloAbBfRhPEA1WVEU9b0EnMcbT93wLy684EnWENxUDrdcrHYe42rrVBzbaZ zblBvLOyvrw_lJP5wzKM9xdni4_3pI5cr8787JXyddlY7VikfYz07mu85hh4ViF9_gR5Hc.i3NlL 1sc6jDp5oJ6yTPS06WzwH_zqacBYEgQxivfWokvscNTMKHMVNCQ487exM7VcLtKqtW5Xr30SEh9i wMWdupMpo20brLqgcfgYkIdvP7bJsjMLf7N5OkYE6.f3FuvhioGH5MHHWosXrWSxJmTanU5tshlH zj.1LIEQ377qwP1LuVKNu2xZsW3qFxYH6FkOrh8Dtia07ftCd6f9r6FxnNaXwX22ThRceFebF21p P9xLMTk7mLtkJHB_tiy.Ghmcgl8UGZdg9GBVPOnNBdvr72PZpRvhG_iyIcD8UD96RyYgs87dE8L9 QlAR6MdMx7fCd.4jIOzbXqJmHgpwbvZCDyoFiv1J0DfskdEFhZzuFT3YMs9br0D1kZLgLxDYkzx0 A.X6p1ZVlZTa9dJxzIKhhQueWot.JZ.OzG6UFdAxJm.ijMjx5_xTJb26oQyya4DFGslK5eZ1MDOr sl_zZq3iDHYpccZlsddTU_XGJEOUI1Jk9BoA5U0f17RWksgtvyjo.mmMmzZiGGk.ux.kdNhbBtXk z_rP40IGWqoYybzLOytdMyZPLGpoD0n8F4fKLbGWvSuExg.GbRboKmw4xIT1xVbrbTQWKIXu_n6W T5xSHOZaet8vYpMePAJ8D6esFs_xMGx83syeXktEHWYu0gu7HZ8K2HGG7cHorwRuZFVAjnAQTm5g UgE9sjAJ2EmbvHd6btCFtl6fQVCXXPxYZaLFWqNhRsNwkMXmeJ3KvqP7BGHxNZ1cGpNYMndNsu.k 09YNuotkmkUtPiBw2VFQ6_BKL9VybWS88OXkOfR.kU7gIS4FFh7hiacusmT.gRf7Jz584u4WqNL8 .H5iqDIYoq0bco4rUnDvM2MoMaARYbyxglfIyFBq0.YhgCJd9gL5Nb8VOvqIV7sVTtqNP92btkBV JwwUYFNA.gVr_uOMfT3mVxDFzKZs35rDwjArDRBjleeHgJT1NIaZK581xYuwcFN5pw_fx3cGW5pJ sFJg0zWkG2dqvbCZ8T2d6mpmNpc0t3EbElqJeRGfPtjD63kSn4wc4IACneq8tGRhYfR4Ko4bMc3O XfW_TystsFSYPyuvK3OMgSMBmw6SDgrX0LIYn93JVXNtldAbiB8XwFBWQ1IelX7A4TtM2Il23RtN cR6Ml2rLqznFB0.lMyJYCOSgs0vzgBN44uge1MNX5qj8OAe7DsF1WRmaxfYacL2SD1RoBltAkDf6 urjPw5OAzfWE9nn5ka2_TszIX6ubFrFDIfeleLr3fer3WZTP04RSIDRjbIqRCtYqajhHJQcqdUWm 5_9x7dWA.A_De_nKMnHlFCzkaURw0Yi7domYHyzPKvdTYzTqhJ_kPVnhVLMFU1la20r9Gm2AG7mL nUCmJfeTyCQTai4UEPIdtQ11RdE3BeBm8gOIDEtNQMqKYp4JDHlC9rFiUNk1AkZmyHjApi6fhvU7 DRD7WkylsHFx_qMbYvZYcGZtEIIcMogN7nGrgwRivM0H.vt.v X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Mon, 15 Nov 2021 18:14:45 +0000 Received: by kubenode520.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 0202f115a5e78cbabb0b738dbf0e9075; Mon, 15 Nov 2021 18:14:42 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: armv7 targeting (on aarch64, via poudriere-devel): system's clang 13 rejected building devel/lllvm13 Message-Id: <15A74B79-47CF-4743-A831-D7C0E9B1DD0E@yahoo.com> Date: Mon, 15 Nov 2021 10:14:39 -0800 Cc: "freebsd-arm@freebsd.org" To: "brooks@freebsd.org" , FreeBSD Toolchain , freebsd-current , freebsd-ports@freebsd.org X-Mailer: Apple Mail (2.3654.120.0.1.13) References: <15A74B79-47CF-4743-A831-D7C0E9B1DD0E.ref@yahoo.com> X-Rspamd-Queue-Id: 4HtHR21xzNz3hbV X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=hmxW6lXT; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.46 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; RCPT_COUNT_FIVE(0.00)[5]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.96)[-0.965]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.148:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.148:from]; RCVD_COUNT_TWO(0.00)[2] Reply-To: marklmi@yahoo.com From: Mark Millard via arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N There error was: error: non-constant-expression cannot be narrowed from type 'long long' = to 'std::size_t' (aka 'unsi gned int') in initializer list [-Wc++11-narrowing] std::size_t resultBytes{size * elementBytes}; ^~~~~~~~~~~~~~~~~~~ = /wrkdirs/usr/ports/devel/llvm13/work/llvm-project-13.0.0.src/flang/runtime= /misc-intrinsic.cpp:50:27: note: insert an explicit cast to silence this = issue std::size_t resultBytes{size * elementBytes}; ^~~~~~~~~~~~~~~~~~~ static_cast( ) More context: =3D=3D=3D> Compilation failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=3Dyes and rebuild before reporting the = failure to the maintainer. /usr/bin/c++ -D_FILE_OFFSET_BITS=3D64 -D_LARGEFILE_SOURCE = -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS = -I/wrkdirs/usr/ports/devel/llvm13/work/.build/tools/flang/runtime = -I/wrkdi rs/usr/ports/devel/llvm13/work/llvm-project-13.0.0.src/flang/runtime = -I/wrkdirs/usr/ports/devel/llvm13/work/llvm-project-13.0.0.src/flang/inclu= de -I/wrkdirs/usr/ports/devel/llvm13/work/.build/tools/fl ang/include -I/wrkdirs/usr/ports/devel/llvm13/work/.build/include = -I/wrkdirs/usr/ports/devel/llvm13/work/llvm-project-13.0.0.src/llvm/includ= e -isystem /wrkdirs/usr/ports/devel/llvm13/work/llvm-project -13.0.0.src/llvm/../mlir/include -isystem = /wrkdirs/usr/ports/devel/llvm13/work/.build/tools/mlir/include -isystem = /wrkdirs/usr/ports/devel/llvm13/work/.build/tools/clang/include -isystem = /wrkdirs/usr/ ports/devel/llvm13/work/llvm-project-13.0.0.src/llvm/../clang/include = -O2 -pipe -mcpu=3Dcortex-a7 -DNDEBUG -fstack-protector-strong -isystem = /usr/local/include -fno-strict-aliasing -mcpu=3Dcortex-a7 -DND EBUG -isystem /usr/local/include -fPIC -fvisibility-inlines-hidden = -Werror=3Ddate-time -Werror=3Dunguarded-availability-new -Wall -Wextra = -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field- initializers -pedantic -Wno-long-long -Wc++98-compat-extra-semi = -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type = -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wstr ing-conversion -Wmisleading-indentation -fdiagnostics-color = -ffunction-sections -fdata-sections -Wno-deprecated-copy = -Wno-string-conversion -Wno-unused-command-line-argument = -Wstring-conversion =20 -Wcovered-switch-default -Wno-nested-anon-types -O2 -pipe = -mcpu=3Dcortex-a7 -DNDEBUG -fstack-protector-strong -isystem = /usr/local/include -fno-strict-aliasing -mcpu=3Dcortex-a7 -DNDEBUG = -isystem /usr /local/include -std=3Dc++17 -fno-exceptions -MD -MT = tools/flang/runtime/CMakeFiles/obj.FortranRuntime.dir/misc-intrinsic.cpp.o= -MF = tools/flang/runtime/CMakeFiles/obj.FortranRuntime.dir/misc-intrinsic.c pp.o.d -o = tools/flang/runtime/CMakeFiles/obj.FortranRuntime.dir/misc-intrinsic.cpp.o= -c = /wrkdirs/usr/ports/devel/llvm13/work/llvm-project-13.0.0.src/flang/runtime= /misc-intrinsic.cpp = /wrkdirs/usr/ports/devel/llvm13/work/llvm-project-13.0.0.src/flang/runtime= /misc-intrinsic.cpp:50:27: error: non-constant-expression cannot be = narrowed from type 'long long' to 'std::size_t' (aka 'unsi gned int') in initializer list [-Wc++11-narrowing] std::size_t resultBytes{size * elementBytes}; ^~~~~~~~~~~~~~~~~~~ = /wrkdirs/usr/ports/devel/llvm13/work/llvm-project-13.0.0.src/flang/runtime= /misc-intrinsic.cpp:50:27: note: insert an explicit cast to silence this = issue std::size_t resultBytes{size * elementBytes}; ^~~~~~~~~~~~~~~~~~~ static_cast( ) 1 error generated. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Mon Nov 15 18:40:58 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 065551850EF3; Mon, 15 Nov 2021 18:41:06 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HtJ1F6dG8z3vPC; Mon, 15 Nov 2021 18:41:05 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "R3" (verified OK)) (Authenticated sender: dim) by smtp.freebsd.org (Postfix) with ESMTPSA id A724C270E2; Mon, 15 Nov 2021 18:41:05 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtpclient.apple (longrow.home.andric.com [192.168.0.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id BECB05A022; Mon, 15 Nov 2021 19:41:03 +0100 (CET) From: Dimitry Andric Message-Id: <91AD337B-6D40-4639-A43C-688699981167@FreeBSD.org> Content-Type: multipart/signed; boundary="Apple-Mail=_73807854-0A8A-41CA-A301-8309F9FC216B"; protocol="application/pgp-signature"; micalg=pgp-sha1 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: armv7 targeting (on aarch64, via poudriere-devel): system's clang 13 rejected building devel/lllvm13 Date: Mon, 15 Nov 2021 19:40:58 +0100 In-Reply-To: <15A74B79-47CF-4743-A831-D7C0E9B1DD0E@yahoo.com> Cc: "brooks@freebsd.org" , FreeBSD Toolchain , freebsd-current , freebsd-ports@freebsd.org, "freebsd-arm@freebsd.org" To: Mark Millard References: <15A74B79-47CF-4743-A831-D7C0E9B1DD0E.ref@yahoo.com> <15A74B79-47CF-4743-A831-D7C0E9B1DD0E@yahoo.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_73807854-0A8A-41CA-A301-8309F9FC216B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 15 Nov 2021, at 19:14, Mark Millard via arm wrote: >=20 > There error was: >=20 > error: non-constant-expression cannot be narrowed from type 'long = long' to 'std::size_t' (aka 'unsi > gned int') in initializer list [-Wc++11-narrowing] > std::size_t resultBytes{size * elementBytes}; > ^~~~~~~~~~~~~~~~~~~ > = /wrkdirs/usr/ports/devel/llvm13/work/llvm-project-13.0.0.src/flang/runtime= /misc-intrinsic.cpp:50:27: note: insert an explicit cast to silence this = issue > std::size_t resultBytes{size * elementBytes}; > ^~~~~~~~~~~~~~~~~~~ > static_cast( ) The flang subproject does quite a lot of mixing of size_t and uint64_t, = assuming in various places that they are the same. You will also = encounter similar errors when attempting to build it for e.g. i386, or = other 32 bit architectures. I think it is quite a lot of work to get all = of these right, and it should really be discussed upstream. So for now, I would advise to only turn on the flang option for amd64 by = default. -Dimitry --Apple-Mail=_73807854-0A8A-41CA-A301-8309F9FC216B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCYZKpugAKCRCwXqMKLiCW o68qAKDP8WfByS2UovTvl8L2lHFYdYuBFwCgqi2aK0EdPp2/jZ8CuDTUGX2s+Bg= =xxGf -----END PGP SIGNATURE----- --Apple-Mail=_73807854-0A8A-41CA-A301-8309F9FC216B-- From nobody Mon Nov 15 19:31:59 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id DD7E31899C2B for ; Mon, 15 Nov 2021 19:32:11 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-24.consmr.mail.gq1.yahoo.com (sonic312-24.consmr.mail.gq1.yahoo.com [98.137.69.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HtK8B3shgz4jCZ for ; Mon, 15 Nov 2021 19:32:10 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637004722; bh=9UbXsEFxD9z1AHRM3nZZBANcQQjBlM3t7In0FvDOtHI=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=Y5EFdRi3kBBWp37vjV7z1ElMSLzeQiyidhJw4yBBmvejSGOCrEf5OFfFQK1INPqLa4M5NUMbWq/VxC9n+NsThVIZu4n1LU3pJ+aBG81Tyn4W0dvNRgkfZDl8t59kPAFGCWKys9TA4hAIJqquCVQF75Ir5sCyo2TwWE+6pkxp0SxheN/3KzbB+ORJOmIXtX+A1I4rIBZa6aSw8aIYBoQdydDTUwn/S3XMxGNqqjUE3pqRQbpu6SIOk9Aj85IgV+tABfF4eG5xRm3jmj9Wgk1XM33afE7p2HrPCId5+4KQSJ65lacN/H0evdnp++PJD/C6h+0MV0pZkqnAJbVGy99cVQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637004722; bh=cV+u/ZrE+q+Te3gC5lkluzg3zNO4yTzIvj5Tssh2uGX=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=T7w1OhSmNuYDafuG/OhY0wdI1marKLuZxdq++gHsqtra/xSmwGE5+UcMbzda1oOB1/Rbujixvvg3/TWHits7dHWAbXp5A6c3Ulm3RESyG0ANs+CVOMH8KDhP/k/J9FMfcyqeTthyyYX/NyYsFb1UOPgmzy3xIsfLOX2tlpwDWt5igeETYCxlhtkU93OJMVjhgDWQMDAPhOztQHznl89ckhbTLaJ7NFu6KG7knSmtjED5Oi0FaRPQlR52uwLhmnvwYlIGHJz7zZOHZHsJGfIWY9wRqXstkfa6acssAnOVy9CajW7WqJwAdopqR9Q4S6JsVqZq39zCGtGFyuBoBUgGeA== X-YMail-OSG: eVX1xQUVM1mhbp88hegfI3FLxDJYLulSQoKMt2bhAfWA47_ByjMIwEb5NU8_0ZJ 72KC.7F3DxdgDZY9Gs9X9y0xe6gwxADDYSbg3KrHsCRNAHx1nYQDMGC6P9sp_nSkooAZpM665XCG pgZzeH0DhFDXgb6uZkg_jy9uSHJR6_kf_7NNYeoJZTnXwwhdesB7IA5zPLxUMB0fktid.qi3JRK4 cm7ZMke7VBbSwEN4rqTiiIJE.6e._yaAzh1DHjNkP9LCKkFuV2o_FPsT4or6SJOmdFpEsCXIudIU VWGTaA5RbPWr3VT6LZqghnmoSWZkIlytGxMCD2k5VV36X0vRKbRM4A3hB2kgI8ITWv6jwqVkZZhA ERiilSDyxYnHG1rTv8kPNCD2x6gGumd3BZiGlY56jYJie94SVaf8aM_sNZrtkUk.WF1VCo6SfJlF O2pRyHyJgFYErfRTWo1eep8x4Vgq.r_OesxVUHHWKD0qpdIHHt6C9H060WNiuv1zuPnPabGZokbQ RrRExibnprXCcZJBkQfIl9N9Qy0bUnP2io6t.C410zccsqNZgtVrZbp9Xof6mWGk0Cm9v1BZgvud AfgpPwHn9w.hnId.wu9RfT57Hsqzyi.WKtztxST09wGgPnlTv7rFmguJ9smlnTlBYTY8XbVbm2.7 0Wx_HiB4X5QlZdkxpI3QVWKs.06A1IbdblZRABQXBgddNA_SMqAZ76_0Dsbrh1coA2dXApwOXsC_ eNXyCew8eghtbMedT5iUo5Fv9A928DSN4nEqybKbfwoygnTT9znqsBG0K9wDtd0CMTkq.wvjdmXr hEWWCLVh91Hu1XBqE3vUZWrOv6wFiPBeSThLWRBDznBTyMcUa89wpaMIg_PW45AgJzxBB5w_yULM ndgnufNprwJoKJl5eAjWmDrVaoWwB0egen18lJ_tWPFpjlnO_Xm0wjPj6MFADZp4lufHTZ0tngxi cE_jPfKDWk1USJcbIWrUEDR7Yfp7NoeVeoEIpTngV1dD8MTOjgmWi9i0TZ4631cshvehvL6v1.XT tdreJLlc_EwsIxThOEJsYPojkzxtiEVyEbeneVWny6GYJkxfvfe7VuxnLRkNtl0g3QiUhx_W0XkO vG6ZmHhiPEjnXdjA1I7mcJQ4O7qBb7FRKkZG_POsGCw3.FPuMETUlwytyluOZ1RW.qO232c3BUhk 4tC5QHh8Juu5.kHPk7gpv4Vfs_cO1.YdTSK9_S_Za2yUfQOHrAJ4zJIZ0yXcqUJQCrOHi1Svdpf6 nFrXBoAxc0ql43CSB.FdL9OyfUf38z3Jpj7DB1rVtMmBhh6zYBtEBAXNo9UCuWMITMCx1TPDlH8T 4SLXAYTw7lkhctPjQNM68xZSfHxdIXkmDI3wl_zDT7nNLcGh7MarnPDczdK_yLjaA68J.G.tA00s uC9Oo9kcwDI1mwWBLksRnZ0x2ECb8xiafP8fobdjFGpGhX.BBF_CfFei.E4kdz7H5iTBJue8tIWF mXpFrpfsi5Cd81mwlSoHKKJUffunPDD0VNjkkn3OQTL42ei0nCpVxWU4CW7r_dh.DNvTlfy5itaR _uD7LNmKZC7MElsT1Y9VKluOYTzV7HJCYrne_Hj1vpkePO_JvGYGrYbLjPlkmujzompH2pnZd70L 5cQEC3L3jYE2Wyt.CfJPCtYpxKI58tnLuWbL3CAA9rMCZzU99Ik9XCdQPhHbtWpiocHQOd_BnUVU jwpUIOMtawGhRTuecqoFciVO0uoyVOR4OMGsGK4Ede877kUDxseN.lwLyOzWtOcwg_AKaKMsC4Bj ZXP9oKYeuMP6HLvWB3Oe_Yl6Vr7NCoTALOfyQgDCixjLnn08LgzKgyD4aKsrHThAm3xiX0Dcowe2 n7QAiCEangpL6LhBuCGC5cAOvkN7S37l6PrwZaATpkOdE4exG5WZtpRNWwCdLg.dqvKuKs2Jp3aB Nc6ZDejbljxqj0sKIFOz8k98GrLTw65a6xvG381yQg2umhFJHiiCjaX2mzqLd6VJdYtNz0dOQZ9k huIY3F_MAfpT48snrE5SwNL_NY0PsuT54NbsSynrqfAtSXLjLUmtzBnlEVMCef8vzf1IUwA0Oo60 bSMJzpvzh2lv.73GfQEY5ZvO7ymBD6ie3RaVekwKoA1U3i39pbJn9y5LSiLqMtrV2m8UQ85u.Y1E y460uZ_aUj7m8fbCm1H8MOS_rdP6uy4UC4sChL0FNmIhMFJ4rFtRU8_TJbZb52kZnqZfE0nks7H1 SJXre2A4Ttli.eiXqVZS7nZnhVf6VSV148wnD4Fo9rNQ- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Mon, 15 Nov 2021 19:32:02 +0000 Received: by kubenode534.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID bce6b983586d0e5f783906e330aabfd2; Mon, 15 Nov 2021 19:32:00 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: aarch64(?) poudiere-devel based builds seem to get fairly-rare corrupted files after recent system update(s?) Message-Id: <2CA61249-321C-45AA-9755-597146AB8E9F@yahoo.com> Date: Mon, 15 Nov 2021 11:31:59 -0800 To: freebsd-current , "freebsd-arm@freebsd.org" X-Mailer: Apple Mail (2.3654.120.0.1.13) References: <2CA61249-321C-45AA-9755-597146AB8E9F.ref@yahoo.com> X-Rspamd-Queue-Id: 4HtK8B3shgz4jCZ X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=Y5EFdRi3; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.205 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.205:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.205:from]; RCVD_COUNT_TWO(0.00)[2] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-current X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N I updated from (shown a system that I've not updated yet): # uname -apKU FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #18 = main-n250455-890cae197737-dirty: Thu Nov 4 13:43:17 PDT 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64=20 1400040 1400040 to: # uname -apKU FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #19 = main-n250667-20aa359773be-dirty: Sun Nov 14 02:57:32 PST 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400042 1400042 and then updated /usr/ports/ and started poudriere-devel based builds of the ports I's set up to use. However my last round of port builds from a general update of /usr/ports/ were on 2021-10-23 before either of the above. I've had at least two files that seem to be corrupted, where a later = part of the build hits problematical file(s) from earlier build activity. For example: /usr/local/include/X11/extensions/XvMC.h:1:1: warning: null character = ignored [-Wnull-character] =20 ^ /usr/local/include/X11/extensions/XvMC.h:1:2: warning: null character = ignored [-Wnull-character] ^ /usr/local/include/X11/extensions/XvMC.h:1:3: warning: null character = ignored [-Wnull-character] =20 ^ =20 /usr/local/include/X11/extensions/XvMC.h:1:4: warning: null character = ignored [-Wnull-character] ^ . . . Removing the xorgproto-2021.4 package and rebuilding via poudiere-devel did not get a failure of any ports dependent on it. This was from a use of: # poudriere jail -j13_0R-CA7 -i Jail name: 13_0R-CA7 Jail version: 13.0-RELEASE-p5 Jail arch: arm.armv7 Jail method: null Jail mount: /usr/obj/DESTDIRs/13_0R-CA7-poud Jail fs: =20 Jail updated: 2021-11-04 01:48:49 Jail pkgbase: disabled but another not-investigated example was from: # poudriere jail -j13_0R-CA72 -i Jail name: 13_0R-CA72 Jail version: 13.0-RELEASE-p5 Jail arch: arm64.aarch64 Jail method: null Jail mount: /usr/obj/DESTDIRs/13_0R-CA72-poud Jail fs: =20 Jail updated: 2021-11-04 01:48:01 Jail pkgbase: disabled (so no 32-bit COMPAT involved). The apparent corruption was in a different port (autoconfig, noticed by the build of automake failing via config reporting /usr/local/share/autoconf-2.69/autoconf/autoconf.m4f being rejected). /usr/obj/DESTDIRs/13_0R-CA7-poud/ and /usr/obj/DESTDIRs/13_0R-CA72-poud/ and the like track the system versions. The media is an Optane 960 in the PCIe slot of a HoneyComb (16 Cortex-A72's). The context is a root on ZFS one, ZFS used in order to have bectl, not redundancy. The ThreadRipper 1950X (so amd64) port builds did not give evidence of such problems based on the updated system. (Also Optane media in a PCIe slot, also root on ZFS.) But the errors seem rare enough to not be able to conclude much. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Mon Nov 15 19:35:30 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 13E1E189BC67 for ; Mon, 15 Nov 2021 19:35:41 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-55.consmr.mail.gq1.yahoo.com (sonic307-55.consmr.mail.gq1.yahoo.com [98.137.64.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HtKDD1dWBz4lb6 for ; Mon, 15 Nov 2021 19:35:40 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637004938; bh=W4gFthozDO6PSjo0AW+gqAsC8sdi8ZAH8sKjCYiWZ0o=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=ldYoifUOkXtIIoGJjxeDRam0QbiKltfjLh7y/qou3yUsB03uUhYBVnJzmkQqQTQsfZI+KInjNbb30yWrSBftr4HV9UMjjjU0XI6j5yXzlC2mQeDTHJrMAU1cYeJyjWTexNGh8DV+3U7kfI/WkUzC3b+cvztY2XxrQPnWxUFGqAaRqJFv+/aCfrwVgw8B5UfKuvGdkq2NfGYcgj+yx4HZ5maGeOmkyIMu4BatEetAuombrCNIBP2Qp8XTKmce4VW6Hyy/+jADfGi8dGgYFnn8zAV6R8MYsR4xxXy4oLhTa7h7yTRN1pBB3J7VsEfyDCTGy0z9qg1h0sXjwKOEsa9chg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637004938; bh=hTmbZwqv+gtE1wmSoGoXntG0nPzFlW8153rtnMZqPXJ=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Koo5SNEcPr9L+2g0CeLxGBMY1L7EpsDBnZPd3qB8nEBKtP64ThZnMvruGjhrzkfcbd/QqpthAUIvZyCCauKpt/5NTvZSfkemQXJXlswQLbrWqcyw4ipYZ+QOf7o4fePqNalfM36nCLOsKbIVcu0BP/gvx8qNyAEBRGpkvrQxzJ+X+4Q6WB5pxRdP2kcmRd9gmrwopWaafRRsIYGPVuYNM8BY2A0UPPSwHgk+6A6ijSHl4ixEXjqxL3cTZz67RLvhoFyuxBznHphh6HuQowyTsFNRnIyE9Za18trWkVvuJViJgWyt5hgpe/DA7NKpaLE5/DW32f4TlVJIBOWk7tVSfA== X-YMail-OSG: zPr6DUAVM1lzdnPqwf3EXCraVyv6OL.zHIqX5DKeDfElYKTbXXGYe13fleUeK0B fJdVSksQqIFubCn1oJaSDBl1vJkBDchgmV6fr3ZBEi5nWQxpn.QCLd87U_OiSDuNNFqvL.6O02Lk uvZkcQTsTNKBhRfpQiTxnXmKRUYMhZYQ1NmLbKMMDd2SjQqqzkI99nsAQ7S.kcwu06koTsYx4rxA eB33lynjgcWVjGBNLXttzssc3NPWuXjd3GW.vgKb3SIfRI9Kg5DwXEwBfF4nuxft93wVAVDtmslz PI1gaCOBNMKZpc4bGUtsy6Upl9emIEOG6llob0uqrsC.mukfUmge.WODWbjtIagCXtQnscaFR06b QrCkfUdgcyVfXHtygKYNCRZfoKT_hXlVpKZ1xjackwS5579eiDmWKOd7lCfRDOeykVHCnbQFdg7Q HN1Z7.wLSxu8dfhbBVdLcygCfT3xy81sWDf5Cy3Qwc59w_3jQJFyLatTmbXu78hCpHfB_y5uLrir .oOD_vcINmHze6xmJF6140tn5UcaauYbfLNAo7VK28uVF4bb1VwO5ec41yJrnHzRZw9jLHxpcog7 CshSWQu2VnGs7PVjWz5BZpDDoiN5rJeAXDwus5FcCsfp8sS1adkNCA26IV2Awd6Q8RblkAgdsaqK ZF2zwTndOaKV4GJLAq71SFl317OYUXRseSiltydkm43_K4FUUCtEX5MTNRkwsrKYpI_5uIwdqaJW zyXEJcRP1kaRE8OVCyXCyrHY_JKeHN0EbrTxp_2F7m53klJXDx.UGVvbT9lLJr3FRy3iKXF2mSQG HGrcp2NH4i65Hu2tk11PNq7TpitupKLBBtE3qCsJJFX9cJwVIXnQ991gFP9FzX56GTfxu5taxLfQ r_CWZwsS7IIFVq8oNBflUHnnJR_NQkqrCnaGZq1nkOvrF4J0jd6uJT8qxMwz2m6RKBLy60xKPizE bCVRom8hNvuVNWdd6N8AVG8VfiZGFEKyqnRAhgf5b.NtFauZTpGjlRmBsNNVNNHo3SR9s4mZdW_s 5TFzeR7htDO3zf9GeRVuekqE0Egba1.DELwdMW4NSq0sDd36ftUPGtvDp5MD5lIWBLR6btICgtwh kHvz2CFBEWGSTI7JoagctOXnwokTrtdqPz.2RsiVm8nJCinDr.ugWe4HyFkn.HXr8jy_tg.OpGap aDzPZumj.NGMQUL74.m64py70DVdVlih1kAb7hzYFxUuOdCT2AgSlX5VNnlTe.h4USlBDg8YPUIt gQCMjoba39QCZCFtSHnGItb2NyVWzJNc_1vjX.cBIwDjHV0MdE_Mgv8HUaYE6eBm6NN37sOalKnz bJe468bRHbaFVi3mIUbIwM5R7F06hBMjb4Is8A9oOpKRA8fhMfWc1g.OEoWpeAbK3XqYb8GgaN7B BUOoxTfWtJ.D6idhp9CkhIYRkGsKPdZi.LvBiIAe5mlVK_nvvBcEEK8A8B30ZNjNog9NBBDNHfa8 sxBVDpBpogKPGq7ERIi32KhqtnKw9OHEPvteY9OuNlcgYczfkzsxLE2OF9bMM4VlIMo8.IfjCR26 3vOXH49.r8fwkFIY8MkJXIVAVw8XQ08NZx4KJcpJ2rsTqBcmaW2SArylwYMjzkBF1z_EprbAu7Zp aloMx20fb_VSu5s2y6Hl2sbAhzyOVptLGjWVOY.UtmFVoK.C3BMYhuxxmP2aw6ltaUInolZszGYt .EWwsPcvtjp4ePRE15_csqtb05y9CxQG2SCgPAV.sN06aopWuM4FtA7eqrx9T4606C2G64AzcuPh YEL1AyMUW.8WvdgQBPBP.2.i_DmzL0kKIH_64in74AIch35ToDuRTa9bubcT3jSg0AzQWgveL53a fRiBwuI.fsal0NCGZmSGeJa_ESEDkZK8kdJvuz3OkSp6HFWOKzLOI2cwMj0N9OgonSMu4iLrkscV qtvX.DpkJ5g5NHk1tjJpBYd12lGMKf7LK0_pFER0On71D1I9w6tmMLrw6QcrQPRMm3Kf_x459Gvd 23thTk0.oDZXCegN3iHIxh95QrakqlAKhmLEurNJhhxo4TTHlYAA5j3.6Co8P9A57PuP_N8TRsLd 3tbgfXPh01jeHZR5WBhtlQe1quF2bRpuwrO37AQ2NMLVqk7jww2vUwsrDFkXu1m495wEsZZrog9Q yJ5RB5Bf_aBc5t_aAJFtG5sEnMEPjUO_nZvn.lD0MhB9oBhnS7.AqKzsUbMijKN2KOb56FM8LU6K MjMXlgc3conqOUAejMPcDjEHl6ungw_AuugmgsPbyMJrOxthN X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Mon, 15 Nov 2021 19:35:38 +0000 Received: by kubenode549.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 83fe48e92d87a725de8beeca5848aea2; Mon, 15 Nov 2021 19:35:31 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: armv7 targeting (on aarch64, via poudriere-devel): system's clang 13 rejected building devel/lllvm13 In-Reply-To: <91AD337B-6D40-4639-A43C-688699981167@FreeBSD.org> Date: Mon, 15 Nov 2021 11:35:30 -0800 Cc: "brooks@freebsd.org" , FreeBSD Toolchain , freebsd-current , freebsd-ports@freebsd.org, "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <3F3F1A2B-87E2-47CA-A9C6-BC65B71F1DE7@yahoo.com> References: <15A74B79-47CF-4743-A831-D7C0E9B1DD0E.ref@yahoo.com> <15A74B79-47CF-4743-A831-D7C0E9B1DD0E@yahoo.com> <91AD337B-6D40-4639-A43C-688699981167@FreeBSD.org> To: Dimitry Andric X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4HtKDD1dWBz4lb6 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-toolchain X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Nov-15, at 10:40, Dimitry Andric wrote: > On 15 Nov 2021, at 19:14, Mark Millard via arm = wrote: >>=20 >> There error was: >>=20 >> error: non-constant-expression cannot be narrowed from type 'long = long' to 'std::size_t' (aka 'unsi >> gned int') in initializer list [-Wc++11-narrowing] >> std::size_t resultBytes{size * elementBytes}; >> ^~~~~~~~~~~~~~~~~~~ >> = /wrkdirs/usr/ports/devel/llvm13/work/llvm-project-13.0.0.src/flang/runtime= /misc-intrinsic.cpp:50:27: note: insert an explicit cast to silence this = issue >> std::size_t resultBytes{size * elementBytes}; >> ^~~~~~~~~~~~~~~~~~~ >> static_cast( ) >=20 > The flang subproject does quite a lot of mixing of size_t and = uint64_t, assuming in various places that they are the same. You will = also encounter similar errors when attempting to build it for e.g. i386, = or other 32 bit architectures. I think it is quite a lot of work to get = all of these right, and it should really be discussed upstream. >=20 > So for now, I would advise to only turn on the flang option for amd64 = by default. flang was not being built: # more /usr/local/etc/poudriere.d/options/devel_llvm13/options=20 # This file is auto-generated by 'make config'. # Options for llvm13-13.0.0 _OPTIONS_READ=3Dllvm13-13.0.0 _FILE_COMPLETE_OPTIONS_LIST=3DBE_AMDGPU CLANG DOCS EXTRAS FLANG LIT LLD = LLDB MLIR OPENMP PYCLANG BE_FREEBSD BE_NATIVE BE_STANDARD OPTIONS_FILE_SET+=3DBE_AMDGPU OPTIONS_FILE_SET+=3DCLANG OPTIONS_FILE_SET+=3DDOCS OPTIONS_FILE_SET+=3DEXTRAS OPTIONS_FILE_UNSET+=3DFLANG OPTIONS_FILE_SET+=3DLIT OPTIONS_FILE_SET+=3DLLD OPTIONS_FILE_SET+=3DLLDB OPTIONS_FILE_SET+=3DMLIR OPTIONS_FILE_UNSET+=3DOPENMP OPTIONS_FILE_UNSET+=3DPYCLANG OPTIONS_FILE_UNSET+=3DBE_FREEBSD OPTIONS_FILE_SET+=3DBE_NATIVE OPTIONS_FILE_UNSET+=3DBE_STANDARD =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Mon Nov 15 19:40:49 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id BD8E6189EB29 for ; Mon, 15 Nov 2021 19:40:52 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-22.consmr.mail.gq1.yahoo.com (sonic301-22.consmr.mail.gq1.yahoo.com [98.137.64.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HtKLC5ZZpz4pNp for ; Mon, 15 Nov 2021 19:40:51 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637005250; bh=+p2DghXewEsz34Ggp03Hl7+aPLMgnqmo5G2xRC2m2vc=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=ijCk5eDfDZwZbSII8rPf3AJdQ1GkAy3YZ9MX+2Ix12fjpMPUWtgz6o6e6dYiRQA2QrigLkrKjmRZpXLnRFUH7nwSeNpNUG2X0bPmtNMBFTWimE/ifQyyZe7yaUl7b+aArxuLBN3n7rjo4qdo0z+n7Etrk8Bt97rZ5Qdlh2f6uK2n0o/d7BKtbKhWbnbDvLvU6ptXQLGD9pHJo+idBi/Wrs0T5QsXnn6MvXY8GQDBKhpcjz4BpHN0qNdGhmiKG+58zGQoRHvrTEpLm9RK5UhYXy0PcgoSc4Cmk7fiqxfcVQNvDYhBGNdApBBMPrbvYyehpzselNVHbU+rclrrXtfWsw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637005250; bh=4mf6UxGYgvbdjmhW6+3l+S1mIpkobCA3ZcdB0ZqPvWB=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=W50hYnXup8BVWIcifbt/iWNUfrD232X1EGQWyB1N0yN9+vRLwVj/kUWieAa6gSvRR6goRor5JOknUkKtVDtI9NO9zlnr6vJXctj0kRjYVPWj3C3srMoZyhmzJlYHfvQ9MsKO0g52xThqZGmREC2kFGurYo2+LcE2gGeDFmlRNMDVTlYaGRBLJK7RJvJ5JhhLW3KnLLhqFQ7FyZf0rBu2gSL8Q0sUleq8gkIrNuOBSxlwLphZA0qhxXLS0sdMPVmTnYif8usvOucx7+C8A8YJhodQb0hI8QUi+tnsit7k2HUH616bNbYqKezeHBku8cXkj0qgPX+TmbuTqK9qxfXg5A== X-YMail-OSG: lTkiFAoVM1mnQ7WUNVhGGXnYpwgTMd6LoZmILn3gd.kClCCnIPSwoJNnLuNSiOw mSFjezMW5v_ZUnwkTvIHeOPRX_.1iX0BEHRVGK18h6tN7TawmkSFQl7lhEELxX8Fv4mjy0Dptxqr xtwz3K1.KQshmSiVrLvUggsKDGa_jsdrinRaAv5fHLkUy.9w3i5w7EomYByiJ.DwNiJNPTaGLyxP dmwbWl7IjLmEVwIdjQZCjCMEM0W5GTkWlgubL0LFninWYAue_AF7AFZGSIDJ8oKaZzRy_7AnBbZS aICYjtANx_tfMO2nR5e_RlvbItFhSBn8R8OjUxrPqJLmUsqq42zu00VCM_ALi8iuyvksmoE04zb_ 6oXQsfOCgKXDriU_TpxBw9mp5ZNd111r2NhWskgFV1v23CSvVn9zQGB4_b8BzqVUu37gdaHEKzTj K4v6yIxfU.OMNc0JUYN2B3vrtzZEdz.NdB8VIEFEsvb0yegS0M3e1hAn2nj32oCFXBQqBL10s3EX 4g8oIWE_n3jjtaPxbLD2EvJbeX4TKWVzPFPy7fcoT.UNihNhSkO14q7jcT8SOL1zL1o7xWmmRlhc hgE2gLhUBUNglatmKYZJc_ovz5ydJx4MqhL4cUsJDYHZKtONg2N2PJfuDsRpJekmq.6vB2ODrSE7 JZXTxooFnOYxGr4_tYp58PpR8Xh1Vc4oYUbx0i93OSg775u8axARJy_Wgi4zmdAybMuYzGFX8SXB 0prXHkI.UWlrvluGYQqiQ97w3MOis8kluulcafQGbsIi6BqqFnYclzz0dL7_BvJKle9g9CRqYBke 0benIYGU5RvTN8iShUWS5WN6qt16iXdM7Mb2Fh_AJzl1oajnsHmNz7v5w65uAOTUW.9gXkbQijv_ fumLcZya6B.pWHfFubkcVjxm5165NQxeZZsPbelWAh.ItWVq58BjQYsyZXtSR.bycB9lnTSseXu0 x3JW3I16PuxxgTbLhoiONdr2hilE6plPh0APY2smjsNODguA6EjXZ_2j8Yoge5_IjO.euDe_cCt0 MFAjILS9c19_66ZiCDkJX6w6JnPGYZDJVy2PVR_dWiMzdHjJdn1rkstY.My4aNRei.Zth0FoJlQk Rhz8kvhMfsas_A_VVp3.DXVuWS1xaXd8t_Sa6t_yoKgk3MYCYB9z6BBz0vthAmJ8dAs5RfQ5fW2N N29sRBPKOpqaccfXDg.IGHZUQ813VoA6p25bZdH57COrG7.zoG4plFVRQpMwd0Nn_oYCT3zr6SJ7 wwkFddvCH5408w9Kq0SNgCMAjl0FdUFpwGxPFadL7XSAAlgihkPp6U6_7C6NsObQBO6lL0ISy9DW zj4pv.fqJjDwe_AKW5ZLzA0cRvCJJ8AwaBOm.CO90UHSSp5WA6Kfgvo5x7K97cLUrQxiUSkMqS3x UA5OSRsOeu1kv2ILT1rSMPtlvZYxpeHwzNWbz38IeQO8EHHHEpf2TS8m.sMk394XBCdmFTabwBZj rIBnJt0jiUtx.4KtMR1ukyiKXo3VqpeC84vnmjcWimeOnfZSDg0OCAmu8p5WJh0.6gtTJRIsZLiK 9UuAULanTNFwlWMxoy.bJ0hEqOclkOm9XtlMYoCHBrOQhl2mxBu_48bF8nftsSEXdUsiNm6j74_R L.pYBA5reaKOW60.ccn.CY1ChY.pcGMawIX.WEepkWc0XurC6R7pANsmKUv3Poa8R74U81jahR7r otGAV42ohGIkdcQoYrUtbGIXK_iaIHlJXZsnWWsNkrmmoxsFkYuyoHVt4N7HU8H7hHGTOz_O9kIz S7MY7_6uTqiA4EIcAcZNIy01Z7BCjghlzPWHBwNHNiO7kreWmndUJ0DKEJ1gbfRJaG9W3sWMdDkU ZdZZRI74uJyrUWrSCm7TjeAk4UwOu2blRX2jGJbl7jQtEgJtuCTQoDh.LxmCSd3U38LasEBVUErM DCLp6pLjCYVFiNnfzMa1l3a0YDecpBpBZJyXn1tJP5FHeTE08PMzfZaS99HBXLt3jbe0ODg6rft_ WIIo6EJ50imok4T7ZILA39en7FuWBwl9UZs71ILaJCtrqdLjW0ysXzTvlf48MI.s1RNK.YWjCsUw nWX7N_mWyu7gNhNK78a.dKKafJdjmcN8o1MQ02pXCiGYjL_ffug_.UZgrdRdT3s15W1bzEVtZ0tD eudeuw9AsZwcWty08PjIyDLDtvBtDoe5W.kPYnUXZm4TaD1TKedqTC5kz6hRZR771ZQ1tF8iEu_5 CA0G_RippaQrqkltFa90OsjXI76zbV3Fob5UGt2L463nho2scPgT2gmMHNgBt2Inznc2HBjjLhNr bi1.qqirmVwAnAKQJWH56BHhDzC0- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Mon, 15 Nov 2021 19:40:50 +0000 Received: by kubenode548.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID d01971386b38a54d52fdea58f2d7e88f; Mon, 15 Nov 2021 19:40:50 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: armv7 targeting (on aarch64, via poudriere-devel): system's clang 13 rejected building devel/lllvm13 In-Reply-To: <3F3F1A2B-87E2-47CA-A9C6-BC65B71F1DE7@yahoo.com> Date: Mon, 15 Nov 2021 11:40:49 -0800 Cc: "brooks@freebsd.org" , FreeBSD Toolchain , freebsd-current , freebsd-ports@freebsd.org, "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <15A74B79-47CF-4743-A831-D7C0E9B1DD0E.ref@yahoo.com> <15A74B79-47CF-4743-A831-D7C0E9B1DD0E@yahoo.com> <91AD337B-6D40-4639-A43C-688699981167@FreeBSD.org> <3F3F1A2B-87E2-47CA-A9C6-BC65B71F1DE7@yahoo.com> To: Dimitry Andric X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4HtKLC5ZZpz4pNp X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=ijCk5eDf; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.50 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; RCPT_COUNT_FIVE(0.00)[6]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.148:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.148:from]; RCVD_COUNT_TWO(0.00)[2] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-toolchain X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Nov-15, at 11:35, Mark Millard wrote: > On 2021-Nov-15, at 10:40, Dimitry Andric wrote: >=20 >> On 15 Nov 2021, at 19:14, Mark Millard via arm = wrote: >>>=20 >>> There error was: >>>=20 >>> error: non-constant-expression cannot be narrowed from type 'long = long' to 'std::size_t' (aka 'unsi >>> gned int') in initializer list [-Wc++11-narrowing] >>> std::size_t resultBytes{size * elementBytes}; >>> ^~~~~~~~~~~~~~~~~~~ >>> = /wrkdirs/usr/ports/devel/llvm13/work/llvm-project-13.0.0.src/flang/runtime= /misc-intrinsic.cpp:50:27: note: insert an explicit cast to silence this = issue >>> std::size_t resultBytes{size * elementBytes}; >>> ^~~~~~~~~~~~~~~~~~~ >>> static_cast( ) >>=20 >> The flang subproject does quite a lot of mixing of size_t and = uint64_t, assuming in various places that they are the same. You will = also encounter similar errors when attempting to build it for e.g. i386, = or other 32 bit architectures. I think it is quite a lot of work to get = all of these right, and it should really be discussed upstream. >>=20 >> So for now, I would advise to only turn on the flang option for amd64 = by default. >=20 > flang was not being built: >=20 > # more /usr/local/etc/poudriere.d/options/devel_llvm13/options=20 > # This file is auto-generated by 'make config'. > # Options for llvm13-13.0.0 > _OPTIONS_READ=3Dllvm13-13.0.0 > _FILE_COMPLETE_OPTIONS_LIST=3DBE_AMDGPU CLANG DOCS EXTRAS FLANG LIT = LLD LLDB MLIR OPENMP PYCLANG BE_FREEBSD BE_NATIVE BE_STANDARD > OPTIONS_FILE_SET+=3DBE_AMDGPU > OPTIONS_FILE_SET+=3DCLANG > OPTIONS_FILE_SET+=3DDOCS > OPTIONS_FILE_SET+=3DEXTRAS > OPTIONS_FILE_UNSET+=3DFLANG > OPTIONS_FILE_SET+=3DLIT > OPTIONS_FILE_SET+=3DLLD > OPTIONS_FILE_SET+=3DLLDB > OPTIONS_FILE_SET+=3DMLIR > OPTIONS_FILE_UNSET+=3DOPENMP > OPTIONS_FILE_UNSET+=3DPYCLANG > OPTIONS_FILE_UNSET+=3DBE_FREEBSD > OPTIONS_FILE_SET+=3DBE_NATIVE > OPTIONS_FILE_UNSET+=3DBE_STANDARD >=20 Hmm. I got that wrong, somehow the above was not used. =46rom the log file: ---Begin OPTIONS List--- =3D=3D=3D> The following configuration options are available for = llvm13-13.0.0_2: BE_AMDGPU=3Don: AMD GPU backend (required by mesa) CLANG=3Don: Build clang DOCS=3Don: Build and/or install documentation EXTRAS=3Don: Extra clang tools FLANG=3Don: Flang FORTRAN compiler LIT=3Don: Install lit and FileCheck test tools LLD=3Don: Install lld, the LLVM linker LLDB=3Don: Install lldb, the LLVM debugger MLIR=3Don: Multi-Level Intermediate Representation PYCLANG=3Don: Install python bindings to libclang =3D=3D=3D=3D> Options available for the single BACKENDS: you have to = select exactly one of them BE_FREEBSD=3Doff: Backends for FreeBSD architectures BE_NATIVE=3Doff: Backend(s) for this architecture (ARM) BE_STANDARD=3Don: All non-experimental backends =3D=3D=3D> Use 'make config' to modify these settings =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Mon Nov 15 20:51:17 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1E0001850E7C for ; Mon, 15 Nov 2021 20:51:27 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-55.consmr.mail.gq1.yahoo.com (sonic315-55.consmr.mail.gq1.yahoo.com [98.137.65.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HtLvd64zFz3mX5 for ; Mon, 15 Nov 2021 20:51:25 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637009484; bh=Spm5zBqzDdI49OOdqyyFzFNbB7IVhuxmSRlEcKj+wvQ=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=bnXnXa1kpKI+G88XFk8U2r7+nOgeA526Jv3US3He6UfzmOhA56NqCtd8hiPGmnB3U16zQ4tDjqITEzb2+k3C8g5dPI2l3aZ1FQmn/kAlx3W7CSrECS5xQolGDMbnhcitX+eKc2L4egbugdRteBg+2U6r9pYr8tacayHXKmdDX6LmrSyq00XEJNArCGL7sY2YmIEb+XzpyyuVUdPcLiK8FZw8CwsIwZ7mYHrAwlkfNJjRkQKs3l0Oz7eWXNURiNwi1VQe9DEugkI0+e9+s40BVyktaGTYEwvgkmJpsICpkQC+6TTIixCeG5pUiaVU4u6y98XO+GZdJVu6wLH9BCODhw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637009484; bh=xmDrfuewT2wSebTM3BuXZNf+1nsEfROa/QdpprXCq1a=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=G4wJ3F5wAEJcVXzFvmOsLvZBiY4TBYOvv0G/tMh7aew8TuZAtCNaM4uki4N9iAQD01jVJm9yr3QAsNhWySUPdCrgeh8Bjta1KJ2Qu2ltjnQ/Pqp8T894Xoa0cvDdWY0yQjTY5bbX73MVJcmA+zm4BRf99nb61WFMe7Hr22AYUk875Hhx254CnRxN3RF6a2ho4HoCdc6Hg+OhQhDTREvPYIm+b7PHHbqqyOgDNbASAauDO+k5zV10H+nzie/zS1jNG6/JYpEX4HEV7hYOaVL+DI/1705cL1x1MvQ1V09GukMzdwMb9UzK84d1604M52iPCnsNalVmGzAMrN8Yz3EK0g== X-YMail-OSG: sFkpQJUVM1kZUNOAMY2Y2y6WZr8EvO1._TPV3zo3RR.jic88cnTgHiVrYlF5JAn DI1FDwJu0muuB0aIj54c7d7MUocIOEBqIoUDbt7ksK6OhKmLNfHB2SYqcFSQ.eQcZEN5g95oTIlU HOl2Wleu_YG1hCa7LgodVPz4B_VkmDA5f9Ml6tvz0nfynCUzj9W5eMeftBYPXV1Py_z3.llISHyb M9QT5aAUPq25edHrLccaS1caflJPo5M5xsm6MKLZHZkZb5FuBoXp6zuTq6ONsp4mN8KzXX_t.YL5 3_7fJ7LhvI2dRpm8SDEJJnMMOrTRLMRqNWsI8QvpoP74Kszq3EiXn93tntdL4DP45QMh39R2waLN HMIC3etJ51sjBNpTKyfgI9Nekgi5J_PfPotsL1H4a7pnzouoF6bimMRBql1nkf8.qdehaQ7qZmYt FFZ6C5WYm0b5Jw_Z7ygXdnUFqg69YaUWd9VoY1NA1ZPQNXOtIVlr4ln1NqCzvuSGWkyuSlkBjgiC RpDNc_O1w_NuO4tgcG2QVYot20L2.zjrJKvYN4Qqzns27a9JVxVIgfhqtiV00YqzO6DcH3sp.tZC fyDAGDSyOX9WdaKrPg0c3v_L2dTV948VuGS5RaA3W4I7kZqaVaZ5CvqzaVTgU1D_AVLEjC14SoAk c2WcVnpexsZedUAJOwjlbkjkj60oIjSbDQ007u7XRXXvpAqq8j5gxEiNEGAjA0uLDf50KuQ9dzaU 9efAu7yPEQiEvlDbIKslxVGBSz6rhtWxtQ9i7why2qqTTwpdYsB5mWDNzTHaFAWZ88aYLNZU5vrX R39Ym3KPVMvDf0pSfRmreMNusi6rCxtqZyNNkZjn_tqgZ_3zlQUM9Wg2R0VWJa6bO5l0G1ZFiePx D1HzTRc4bj8eN1617hI_XMWk7b3PUEwhrleBBz334bIhmCUeEZSyJEIy9_1M30ffckYQBJBHRoLr Z1SsRQ.JfGxCA1zO44hZCPykoZGomlBSlBtRe3.eyA1q70apQyNqUE5_LXNHEGu.Fpeiva9Xs4Eh jowol15C1mvQiF8ZJcC5XRY3QZhhJ0duAsR2ALHITB.RYsxtSV6f0xjB7RUqVK4O8d.j4e3zLxb1 M1mutDu.SD_Tss9RLEO.bhBhq_aPX9IL3tYo7TVDntnYgxiGUtk0xCVb1hI8mRUWSiAKAw.q2LND xYvT4enPq8hYvpTR3zI6Xmg9kd1PgSLJvdtr8SgtGZSU1WxSyniYH_dAYHKrYLXgl_WfZvg9S3Xb zJ51pRpTpzgPsH_V0BSueFALnqFiipQ4v91318LB1fRi1Kgiy2f14M_cNt3jBXqKqvQWzzptRKdC ubbIoSOdJzdWZp9vHUMHtHkONt4UUfmOSYbjKKqEBRTZ9c_mNQ2ygasZxOzQwAbl6xcAbB9S6s75 5HUb6b04JVFNjTolTxOx0b29QgyFhE1WkmN8qSpMpHDe2jdK6VU.0opEL3VQQYaHgZMWGPbR1MS5 dFOtpDTd2thG8ysQVtUzKNvpebSCGHgBBxD4Y3HNtfc03H5fbYSYPuI9S.XBgTQ_feCmDoVa3RHX 7M0T2cOY6fEvHETiBZ6Nw3c3qn69GBHIsRPal67.MlDbJAH0oGL8ubxKWjHBqxunPMRBiuaq8a.k b3s5nOsd88NfQUQfoqVNvOeMTUsQ.xf6jtPg69DqEkozZLeNvxCHaFAMdgzaPbHYep3Mq8N1pHc3 EXvWB_aRXUJUVhlgmjqYoMHkOqZ1LnUk4bgJiJR_db99jlxBv8FxnV15lzSDEW4Wxo_N6zyMnsXU eH1R2awyuDaNtj6jTYicDCSn6Qx.b9d4koEYJ8_w95_sN80OXg5PzAy4EqWyFi4ebNcwPnOvLSZw l5fVaa.rSNGOgTJZNm43.lht4vMh0DMKo33Qa3UTOrctO_DNbXn6dgTUDXd5eYS_HCK82.FOKr8z 1zUSAFzOa5Mv89UBtsX7SS0wiQ6h37Ql.k5FTkoyphDbVyJT8KcQTpQgMI5IXRcvqHZ1O2XyCt9J y0VN.S5OpNeOmcUz0mhjpia5jn3NPgxlF9Dhxp5NFpEeW4mkvcXNk36jdLu7y6apXIFtT4oeukLG CGwHnjQTJxxt6J71RsRB6gIWkWK588Y9qO74dZiSaqJFpXtqLK9MMo82y4KaaP7i3p79vTerEIZz OnSOHDhGCMZtf7Pz_Ocq5Kh4Nax5aMsN1YV9wwsm9wRXL.xaBJIsCGBzduqAF.a7InLtsUvwBY9z DmV1qh02kX7J1FeT22JhlypeyTSsFM.9mgqxGmQPDtYPcJFsn X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Mon, 15 Nov 2021 20:51:24 +0000 Received: by kubenode502.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID b76ae83e72eaf007efbf393290b269c9; Mon, 15 Nov 2021 20:51:18 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: aarch64(?) poudiere-devel based builds seem to get fairly-rare corrupted files after recent system update(s?) Date: Mon, 15 Nov 2021 12:51:17 -0800 References: <2CA61249-321C-45AA-9755-597146AB8E9F@yahoo.com> To: freebsd-current , "freebsd-arm@freebsd.org" In-Reply-To: <2CA61249-321C-45AA-9755-597146AB8E9F@yahoo.com> Message-Id: <65AA4BCD-EC4B-4A19-B750-C7FC6E5ADDF5@yahoo.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4HtLvd64zFz3mX5 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=bnXnXa1k; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.31:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.31:from]; RCVD_COUNT_TWO(0.00)[2] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-current X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Nov-15, at 11:31, Mark Millard wrote: > I updated from (shown a system that I've not updated yet): >=20 > # uname -apKU > FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #18 = main-n250455-890cae197737-dirty: Thu Nov 4 13:43:17 PDT 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64=20 > 1400040 1400040 >=20 > to: >=20 > # uname -apKU > FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #19 = main-n250667-20aa359773be-dirty: Sun Nov 14 02:57:32 PST 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400042 1400042 >=20 > and then updated /usr/ports/ and started poudriere-devel based builds = of > the ports I's set up to use. However my last round of port builds from > a general update of /usr/ports/ were on 2021-10-23 before either of = the > above. >=20 > I've had at least two files that seem to be corrupted, where a later = part > of the build hits problematical file(s) from earlier build activity. = For > example: >=20 > /usr/local/include/X11/extensions/XvMC.h:1:1: warning: null character = ignored [-Wnull-character] > =20 > ^ > /usr/local/include/X11/extensions/XvMC.h:1:2: warning: null character = ignored [-Wnull-character] > > ^ > /usr/local/include/X11/extensions/XvMC.h:1:3: warning: null character = ignored [-Wnull-character] > =20 > ^ =20 > /usr/local/include/X11/extensions/XvMC.h:1:4: warning: null character = ignored [-Wnull-character] > > ^ > . . . >=20 > Removing the xorgproto-2021.4 package and rebuilding via > poudiere-devel did not get a failure of any ports dependent > on it. >=20 > This was from a use of: >=20 > # poudriere jail -j13_0R-CA7 -i > Jail name: 13_0R-CA7 > Jail version: 13.0-RELEASE-p5 > Jail arch: arm.armv7 > Jail method: null > Jail mount: /usr/obj/DESTDIRs/13_0R-CA7-poud > Jail fs: =20 > Jail updated: 2021-11-04 01:48:49 > Jail pkgbase: disabled >=20 > but another not-investigated example was from: >=20 > # poudriere jail -j13_0R-CA72 -i > Jail name: 13_0R-CA72 > Jail version: 13.0-RELEASE-p5 > Jail arch: arm64.aarch64 > Jail method: null > Jail mount: /usr/obj/DESTDIRs/13_0R-CA72-poud > Jail fs: =20 > Jail updated: 2021-11-04 01:48:01 > Jail pkgbase: disabled >=20 > (so no 32-bit COMPAT involved). The apparent corruption > was in a different port (autoconfig, noticed by the > build of automake failing via config reporting > /usr/local/share/autoconf-2.69/autoconf/autoconf.m4f > being rejected). >=20 > /usr/obj/DESTDIRs/13_0R-CA7-poud/ and > /usr/obj/DESTDIRs/13_0R-CA72-poud/ and the like track the > system versions. >=20 > The media is an Optane 960 in the PCIe slot of a HoneyComb > (16 Cortex-A72's). The context is a root on ZFS one, ZFS > used in order to have bectl, not redundancy. >=20 > The ThreadRipper 1950X (so amd64) port builds did not give > evidence of such problems based on the updated system. (Also > Optane media in a PCIe slot, also root on ZFS.) But the > errors seem rare enough to not be able to conclude much. For aarch64 targeting aarch64 there was also this explicit corruption notice during the poudriere(-devel) bulk build: . . . [CA72_ZFS] Extracting arm-none-eabi-gcc-8.4.0_3: ......... pkg-static: Fail to extract = /usr/local/libexec/gcc/arm-none-eabi/8.4.0/lto1 from package: Lzma = library error: Corrupted input data [CA72_ZFS] Extracting arm-none-eabi-gcc-8.4.0_3... done Failed to install the following 1 package(s): = /packages/All/arm-none-eabi-gcc-8.4.0_3.pkg *** Error code 1 Stop. make: stopped in /usr/ports/sysutils/u-boot-orangepi-plus-2e I'm not yet to the point of retrying after removing arm-none-eabi-gcc-8.4.0_3 : other things are being built. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Mon Nov 15 21:13:44 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1E0A9188C0B8 for ; Mon, 15 Nov 2021 21:13:51 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-21.consmr.mail.gq1.yahoo.com (sonic317-21.consmr.mail.gq1.yahoo.com [98.137.66.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HtMPV02bcz3vmj for ; Mon, 15 Nov 2021 21:13:49 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637010828; bh=CmwgQHz7NnMM/ThG+x6GRmKKqofAwcKTvAeWZKZR8DQ=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=JINM9iSG2CoBT0G496LS2a1pPhEqn8UHD47zv3EBlGSU+kIEy7iK6TMKkMr7WITacb5VvHDykLqoYy8BHJZYTahVJF8VZg+JKn5UuMdkh/PaPOgR/TaJY33cGAdHsq1Uwk4vbrb2kmM2EVDOX0P2ze5sXBpTLfnvaZOriS8YtHRK69m8Tmxd7w2X/FV9EsyQ6x3JAwh6p+++9zQAHr6jgOOsdiVskbY1lIc81zR/D+hzSUnMS9SCWl1bQMduZ8nT7+8GTDF1t0RXqmZL0/Yf7RQy/2XtkTNQaqzRVAryt0xxrl3sblZe7/jUOLQ0zcLy0tvgWG6is9RHKPUAiAvsoA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637010828; bh=J2ASv8VyIBM6J0VIor99/TyaSTI30nldzGFP2WZvAoD=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=d/lG6ZOCFerqR3oetjR4PO099VA2EwFEWG3D0cI2AZoWo3lc0vccCv4nH9ANhnqDp8FgK1K2DAGXyEX8aVR9HmqWukrTE8HsSCiUAzEuN5lf8sC8b5AGFXs3AJsNomDWBBY7i1p5tjnvNWs62bS9tRh5b7NwLjr/maz/9C+LvElnDA1hRUJPVGlQmsNtPQxFSQxz+yp99AJJr3WiKQ2TFWh0Q6pzx1kSw/de45NTzaT5Me6IAKX3gllJ2vBfOtJ+06OV+OPq7V6295ebQHcALA+pFtLWrfYpqA3iLWmjhAASv/alevaN4ZNaQq5iA8QJJ6gTdhrcHqPFNKtg/7RGNA== X-YMail-OSG: CYWpBIsVM1nmdSqM2HzRLdrTIIiTZe10cM6Z9lRhhuwlYtomDDUr2UCHJs3cuX7 6VhkHYlgsAWViZaFYtkRwRCvufEPR1pCpuJKQB9Z4qMi7YJU35AR7pn9yeH1u_2f951OInMVh3XH b.zueBdr71TPkjQKGQu4Gt4xXNiy4nZbsiJCb0BBLeSrRxBRWzKSxv1HcEVeAaaTze0Jw6bR7dQi 2lm61h3LaZ74jr3upFKqc3zSdOtloAylDMFSquIakn8wFbsDxfT9q4pehu0cYCBnKgu4.qkPEWhQ AQe2ygibXLTowW0IqgweYyBskUWCzgvaDUpYyCQl3crU1mvzDRMvQgVTiNcBTen.goC8meuirAal BNdnH6HIplua.9kcdCQzVLUGsGhHEl_kodNn6pE.hymlnnx24JfNdVzWmBALGWlssv5quKBEP6FB mELbREBB3sntlw5L.iHuVjWBBQJhNjiohuOsVQgF.DQtUzHstDDrnOq0.zOUuLKOggipR62FROMC YrnmOkrnGUW1GyoXkk5Wbuvr0HErXYc5ICzYE2aKSbah6GAFiFNIH01slKBri2DY6kq5HN5KgZ5N KGOgT3PWMBc9I3FDWhyOKhLf.4EUvZMv8KMSB4k_jj8jGZdFy7_etF.jea16d2DJHQUEkHk38jqJ hMlHu60rBXSEoAAA2DUQnuEDpGUF1YnAQKJYrSrFkL1ZejRVSnNmiXDssSdLu_tWil2LxZucZ._x ALEfOLTyNdWvBeeExSGkKwihhnM_2y9yU6UMJyUWIoax_WXXD5Leih9V4jCLSTBBymdxi6kbGhlj 8iW502ZXx27z05v949uNC6vnJWEyEuQQfN.zBOA0bgi_SQ5fP7jSOuXbCeNJ8jm6GFv9cfaEcA66 z6N__QulyiWMBnIva8dV2R7hgcc9FFPheofj3.H2YZgH3IPkDbIL7oRp_4aS09RKUn.Y3rSduZnK WKn5HvMnhkqS.C5_RQOSlxvKWpmwU6SUhBUw40RuvcsuvSe8muFupoBibRM6vjlxKXt5b1v.2tuo 6fkDNF6k0wuGWkB0R6wJB6Ag8BSlsGhEcIGGleDPz4rLLLwuxfJnxwbBD36dSVjI_6VNSP08EkfJ 81ZnYO3lU5PXW0B.81Btp8mDhuowaLSBP46pmsSTRYCz3aqUJvIt5cBk0AU1.4245OOulzDZjH7j mPmo3h4Qs5d_Zf9rGwqRmlV3baZ2rjmJw_9zfRxBD1lUFHzLdKMlFCh9JIm1Ir_A7g3khXNDrznT V5jS6sGlonlNeq.fxckFMHVMBavxeLdKk60dArkT8cYvMHVK60LgEeNqPpIP8sieg41fnUyo_6MZ 0f3z6uoQUu7SJY5dCcdKqnruzg2PyDgaqCB7UalVfe2AQa.O0h0DVV_LoeXpPE00IJpoxBjvsajm Wz6L2dJvGGp.xz_xIM6diDnQ0Tg9ZuIXCb.o2KI1C7TZG9cwF0pvLztfc9rJ__lwkmMrVJbtD6KO FqKDwAx2O6DFZi3NeuuSZtjMjBDsrp2kYhdXHsOHVX7bA_oM_vmAeOysjKesP1Y_pSOQrfCRkWIA AkblgpLdQFjb2O6Fm0jAXCVsxwo3hEhEvWwFn7nWofgxH7eKdwkRESzyYayWU_qoMvDtOykCEFme ieesBBniB9U9mhWFcozBHEhYlc9V59WbdUkTZVt2V8w.hcKP3I3.pRzs..cveXEJ3gCa9YQLATRk ahJDppj85W1HILRsk_WrH5.pB2Ps.EBc.7pRGsVQsIqEOwfEjfUyZDzLa4IOpiRi4O3IeRWeyFq2 oyvuP11plHAgnlszvvLfI9AFvYQ8YGqoGUIcM.wRfSvGVW6P.pLccpXn_YUIGRELACwRB3fyhqoK 40lWr47LSOVmZCcnRRHDMUwX0ZYCuu8F8_KNog_5ttbrkDRfPMsWleDRcPnlBLP71GQloF2Dyagp jF7Qzo7f6Ffen5JZp_7xKwwgWjmtQdafvCDGEgWo1Wsj8lPnZCtgfjszMC9EVq3mRxNyJufqLAq1 JP2vYNjc4M5XIkm241fNLKB5v5tRgKdBglbw3Ehzsf.iN2w.LwTbZyRAIwHXu.Uh5rk8RdBXit9O xjldbphEQuGIcbjEYWRGzcOa5THZgio2ZWgt8E_3cf91XTBMH.QvP9MagSizgrArreYMwu8hjkey WBqs0P.HRL2J.rvNSB.h_hD1F0zu8_Uj__0Ya1cvuLWffuuV17g7R2DoTdtCFmMR6DpetZuf2K1o a_Sl.u8e.ZaXNeSRN_OroiPD2eTUst4N6RwcYlt_SPzNB X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Mon, 15 Nov 2021 21:13:48 +0000 Received: by kubenode507.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 5b652c571f08a0174d9c1f6407fbef9d; Mon, 15 Nov 2021 21:13:45 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: aarch64(?) poudiere-devel based builds seem to get fairly-rare corrupted files after recent system update(s?) Date: Mon, 15 Nov 2021 13:13:44 -0800 References: <2CA61249-321C-45AA-9755-597146AB8E9F@yahoo.com> <65AA4BCD-EC4B-4A19-B750-C7FC6E5ADDF5@yahoo.com> To: freebsd-current , "freebsd-arm@freebsd.org" In-Reply-To: <65AA4BCD-EC4B-4A19-B750-C7FC6E5ADDF5@yahoo.com> Message-Id: X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4HtMPV02bcz3vmj X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=JINM9iSG; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.66.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.66.147:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.66.147:from]; RCVD_COUNT_TWO(0.00)[2] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-current X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Nov-15, at 12:51, Mark Millard wrote: > On 2021-Nov-15, at 11:31, Mark Millard wrote: >=20 >> I updated from (shown a system that I've not updated yet): >>=20 >> # uname -apKU >> FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #18 = main-n250455-890cae197737-dirty: Thu Nov 4 13:43:17 PDT 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64=20 >> 1400040 1400040 >>=20 >> to: >>=20 >> # uname -apKU >> FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #19 = main-n250667-20aa359773be-dirty: Sun Nov 14 02:57:32 PST 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400042 1400042 >>=20 >> and then updated /usr/ports/ and started poudriere-devel based builds = of >> the ports I's set up to use. However my last round of port builds = from >> a general update of /usr/ports/ were on 2021-10-23 before either of = the >> above. >>=20 >> I've had at least two files that seem to be corrupted, where a later = part >> of the build hits problematical file(s) from earlier build activity. = For >> example: >>=20 >> /usr/local/include/X11/extensions/XvMC.h:1:1: warning: null character = ignored [-Wnull-character] >> =20 >> ^ >> /usr/local/include/X11/extensions/XvMC.h:1:2: warning: null character = ignored [-Wnull-character] >> >> ^ >> /usr/local/include/X11/extensions/XvMC.h:1:3: warning: null character = ignored [-Wnull-character] >> =20 >> ^ =20 >> /usr/local/include/X11/extensions/XvMC.h:1:4: warning: null character = ignored [-Wnull-character] >> >> ^ >> . . . >>=20 >> Removing the xorgproto-2021.4 package and rebuilding via >> poudiere-devel did not get a failure of any ports dependent >> on it. >>=20 >> This was from a use of: >>=20 >> # poudriere jail -j13_0R-CA7 -i >> Jail name: 13_0R-CA7 >> Jail version: 13.0-RELEASE-p5 >> Jail arch: arm.armv7 >> Jail method: null >> Jail mount: /usr/obj/DESTDIRs/13_0R-CA7-poud >> Jail fs: =20 >> Jail updated: 2021-11-04 01:48:49 >> Jail pkgbase: disabled >>=20 >> but another not-investigated example was from: >>=20 >> # poudriere jail -j13_0R-CA72 -i >> Jail name: 13_0R-CA72 >> Jail version: 13.0-RELEASE-p5 >> Jail arch: arm64.aarch64 >> Jail method: null >> Jail mount: /usr/obj/DESTDIRs/13_0R-CA72-poud >> Jail fs: =20 >> Jail updated: 2021-11-04 01:48:01 >> Jail pkgbase: disabled >>=20 >> (so no 32-bit COMPAT involved). The apparent corruption >> was in a different port (autoconfig, noticed by the >> build of automake failing via config reporting >> /usr/local/share/autoconf-2.69/autoconf/autoconf.m4f >> being rejected). >>=20 >> /usr/obj/DESTDIRs/13_0R-CA7-poud/ and >> /usr/obj/DESTDIRs/13_0R-CA72-poud/ and the like track the >> system versions. >>=20 >> The media is an Optane 960 in the PCIe slot of a HoneyComb >> (16 Cortex-A72's). The context is a root on ZFS one, ZFS >> used in order to have bectl, not redundancy. >>=20 >> The ThreadRipper 1950X (so amd64) port builds did not give >> evidence of such problems based on the updated system. (Also >> Optane media in a PCIe slot, also root on ZFS.) But the >> errors seem rare enough to not be able to conclude much. >=20 > For aarch64 targeting aarch64 there was also this > explicit corruption notice during the poudriere(-devel) > bulk build: >=20 > . . . > [CA72_ZFS] Extracting arm-none-eabi-gcc-8.4.0_3: ......... > pkg-static: Fail to extract = /usr/local/libexec/gcc/arm-none-eabi/8.4.0/lto1 from package: Lzma = library error: Corrupted input data > [CA72_ZFS] Extracting arm-none-eabi-gcc-8.4.0_3... done >=20 > Failed to install the following 1 package(s): = /packages/All/arm-none-eabi-gcc-8.4.0_3.pkg > *** Error code 1 > Stop. > make: stopped in /usr/ports/sysutils/u-boot-orangepi-plus-2e >=20 > I'm not yet to the point of retrying after removing > arm-none-eabi-gcc-8.4.0_3 : other things are being built. Another context with my prior general update of /usr/ports/ and the matching port builds: Back then I used USE_TMPFS=3Dall but the failure is based on USE_TMPFS-"data" instead. So: lots more I/O. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Mon Nov 15 23:43:49 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 29C00188A63D for ; Mon, 15 Nov 2021 23:44:06 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-21.consmr.mail.gq1.yahoo.com (sonic317-21.consmr.mail.gq1.yahoo.com [98.137.66.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HtQkr3tN9z3jZ4 for ; Mon, 15 Nov 2021 23:44:04 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637019836; bh=mUekWikUU+iYpvEwo2oz/STVl6wxnakZiVqY5M8itsI=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=jhhQp9UBKnJiHtdSbCuagjmtt2PbTZegHAuxN4SRrz54w6NiX8uYyynqJqwYHUWhirqOlW6hm3bCJNiVIMEELJyNv2bxZ3x4G1GbGVRkYNk/MeVVT0+2e7uZs5uswuxNfv8MA1Z6b9I81+gi3r+cXJzC6SIQEreyzo/k3LEB9Lgvzg0EVL8wdUIMWsWlU2fvlkeF7apGCOOwQ7C4AO+EoDirMtF3KTCXIdwF8h24k55/PJhDOJvShGnzFte3edDF0ST8F6TvoweKs1KbXTHZ2dVnhbDB7Smk5L/jLrO0DIGM+FRqUQgE/rSTOsw+2GrYyaeBVoZUFU7Ys5LEQEeM9Q== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637019836; bh=l4BMh9v281S3hHZhq/V4EYcqBA85ot9pqRJkc78XVfH=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=ja5mZYtLsNhn2luy091FxJ8ugMTx5uv++tZvH2M9cKXAxNSV+GaFWwtLSwW4700nO3zB/N28AuvINvjb5pkslo+CyeyCVtNjJEYKWljvK1QV26AObQ2J1I0bnc7ieKWusYfR//lHeXVaQ3GDK4vet/l8Vuux8WBXxQMuUkdj68B+cC6rxS4Sle7/A3oShMEh1iMVprreaFwVaDBKccDxUbwmd3ctVxKDf/40icNS9cW069g/cVY2UF8aY33plKvS7ODKUODNQWjXs+1+tpV5/Mm1Wct/OuOBG9A3kVFE/eF35XXSFwMXdyKf+8T853oJxIwNN9z/9VWYGrNQd4n0JA== X-YMail-OSG: hjiTR8wVM1mkXN1f6bza0r3_CTVT86vcM0xSb3SNVnast2BnX4r6k8Rz8GoM5Ps qLKI2NPCjpRNg4AIbs3xycKO_1OkdO5ObHaPvH.C1waQxzfXFE0u_FRjzuaPTgh3TXoth5oksRNo _UvQVZ7GAMWP0weEx2_7wp8a5xvmFj.hS_tDh_j23fdKK.ZELSV.FXSHuynYJgakL4N2q2.COfXH AL5VCKFETJ4Y8AgxvQcmi2EjankWs_eifDUWY8pElfFWJgVdKxYfjjOWH.ELSEszxuPNqdbfmDAC Ol.3ls1T9HO0KCRcjexJJvuHLiYfd3IhTwl6u5s5Bw524nD4sHVv5EOVcUqeLO0apuS1.b.lBB6Y zEegDCZOp25lQiymIaMpSTQPWrMAm7HhVNMq17nvpo2AHis4eyJ23ZJtwtJJo25gkLYuuuw7mnfE l4YmAFpaGHjC42JTKijHDOIdxm2.Q7i0_9h7RbEro0f05e1UYl6LjbO_S38fECYSy7zHdWTnrJ6W AJJwsGocpfAl.DLgcu1gH77fLTyEf7ZbwKcMJrdCLswVq0.6x_pCUqDL8TVKmSqzeBCLxUDGHOe0 1xgpG6xkooxiNKrEQjf8kIpBEqGIFBIkQctXjDkCzZlfv54QJsZ1_hhP0AL.T4FbLPcrVc_pbWdf C.ig8TGbLqntAyMbwbZV_rWFdiNwB6JYjZNU9HZrqufZ.2uL2COzFDdsqRvP5k8pWbmLy7xoP7hm DLoqmW2Bppr57.fEFEVnD2Mn4mbXQkG9VA1rYDI2kqopXlWT0vfP4ydDvbDuW3_3ZYYIwnunNuP5 7DFbN5OtXSBPz4b8Zbsf0guJCM8NuHqghJvq.uWmhf12bA0moHKJrlnSp4pAHBnQJ3v_A7iiWUWp pC70JvWuSzIJRGCJuzh0uPEV168D20fhgcqINij8B2zhLSSFeOHe_SIxAbQpOuUuAaYjnce_QBAC VZQQSZEQpWWLhHsEeVkFeZyAmB0KnoIeg4RfHiJ8Q4oGDYbX2vmagoMc14c2uT8GTB8T5epPTZoB hcDLxLdGfQCLr0gEopZtJTFA8Zi89YD1D1Vqh1ZGZBUuxg1sCesyQBiu3klzgE34sFda8IcbmsG2 .k9Njx5Pshko2y74AAt3yBdnpkB3Hbv8TjH77Dob2mMb.4ajHrmJfv2k34OstnPoJCajbzyAjga1 ZxEH8fzBEX.TPsKXFDI0moWoKqguT6knrABF0UkHJqmXrcuEfNcWAwMJ5368x4xNr.YRE1tV04JZ BZcNXTzYXwVWq1pw1bSSsdX6PnHf1CL7XdxI2m6puk4yBLRws5PGCkxlXWCoxLZWGV14QVUENebm DDIQBP5jHEyyf7ZCAWzOFNhQNjRqVqWmh7wGN9Q6H2FhTPES6LFxGUUngPw19sGp_27uaHtEjs.v vEmrV7BEeLvNOvhljUvL9Mm0rGXLbdwpBIQAc4U8eAPCPxCe6GXpaY2dFpwhrORCaJ0rLrewY0lF oirbcY0llXkSwhm7Oo5U5TekDf4Uy.QxMwH1bcJF_rAXmr3eWjqR8eS1JbJ1OQT7toDdc65d.fX8 ZxDt.VTqxBpKbHyN7flqDHLuFilWz8ATqjGLolIL_qSPMvVXVOeq1DVsQ_wrzDoINAoozAIbz1Xh IGdWJhG8F1eCmMTQmfZLQR1jlVehEW3pZc045T1I_v843AF0f2em.2u1vwFFYtA0tFt3f0K5QpGM 1SCoFyKHK27ABZ03m5rFia4CoO6mBP4L36ROnEZkxtmLU3IEtJc9hUFThXQuzO0rX4CBnVOaL3l3 AGdFsEvxKelHgMmiTgtaqkLMMl0t7IDp2AkxiQ2wxzv8rZBJYUOsseKFXiH30BAYCgYYY1BC1BmL Q7p2QEgC7zzAVFscOSNc8MjVEmWZpTn.XFHaUfCKEJrcZTv4XW8OKa6TDxKp27aLKwPhNZqOY.e. 0RBJ9lHyi7f1QRgWpZp48lIg5W.SfvnTqi3o5aM8Erl7v1Kbgr4qiZ7ZXb8UlX6p4osayuEPxYC_ 00ZjFG4DWZktrOz65O3dPbOzf7rNVErUwDWNa9n.EogO3SYwW3zfIxi7E7Cr4yd9mJnQps3dH33P J2yTTteeCdOBjwShEPwYPFEFL.hxm_i.mtN_O4Wja7fok_gSghrP9PVaDnji9JOAQA_vWZueq.eY BtgH8O8gNdgRpMNNrfYpygBWWzKt8rDdbxZ6RaEG96_zd1OFXWGHKnV2ZAxKqpFJKxAsxAekD2Wu 3_HvqJQKEAsfzuYXYHphmvg8sYCkT72AxZUM7ev0bhSsL5Q-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Mon, 15 Nov 2021 23:43:56 +0000 Received: by kubenode522.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID ed2e5dd9852d9e679eca91269152e810; Mon, 15 Nov 2021 23:43:51 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: aarch64(?) poudiere-devel based builds seem to get fairly-rare corrupted files after recent system update(s?) Date: Mon, 15 Nov 2021 15:43:49 -0800 References: <2CA61249-321C-45AA-9755-597146AB8E9F@yahoo.com> <65AA4BCD-EC4B-4A19-B750-C7FC6E5ADDF5@yahoo.com> To: freebsd-current , "freebsd-arm@freebsd.org" In-Reply-To: Message-Id: <9BF4F65B-6437-4D88-AF34-9BCFBF90D6F3@yahoo.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4HtQkr3tN9z3jZ4 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=jhhQp9UB; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.66.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.66.147:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.66.147:from]; RCVD_COUNT_TWO(0.00)[2] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-current X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Nov-15, at 13:13, Mark Millard wrote: > On 2021-Nov-15, at 12:51, Mark Millard wrote: >=20 >> On 2021-Nov-15, at 11:31, Mark Millard wrote: >>=20 >>> I updated from (shown a system that I've not updated yet): >>>=20 >>> # uname -apKU >>> FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #18 = main-n250455-890cae197737-dirty: Thu Nov 4 13:43:17 PDT 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64=20 >>> 1400040 1400040 >>>=20 >>> to: >>>=20 >>> # uname -apKU >>> FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #19 = main-n250667-20aa359773be-dirty: Sun Nov 14 02:57:32 PST 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400042 1400042 >>>=20 >>> and then updated /usr/ports/ and started poudriere-devel based = builds of >>> the ports I's set up to use. However my last round of port builds = from >>> a general update of /usr/ports/ were on 2021-10-23 before either of = the >>> above. >>>=20 >>> I've had at least two files that seem to be corrupted, where a later = part >>> of the build hits problematical file(s) from earlier build activity. = For >>> example: >>>=20 >>> /usr/local/include/X11/extensions/XvMC.h:1:1: warning: null = character ignored [-Wnull-character] >>> =20 >>> ^ >>> /usr/local/include/X11/extensions/XvMC.h:1:2: warning: null = character ignored [-Wnull-character] >>> >>> ^ >>> /usr/local/include/X11/extensions/XvMC.h:1:3: warning: null = character ignored [-Wnull-character] >>> =20 >>> ^ =20 >>> /usr/local/include/X11/extensions/XvMC.h:1:4: warning: null = character ignored [-Wnull-character] >>> >>> ^ >>> . . . >>>=20 >>> Removing the xorgproto-2021.4 package and rebuilding via >>> poudiere-devel did not get a failure of any ports dependent >>> on it. >>>=20 >>> This was from a use of: >>>=20 >>> # poudriere jail -j13_0R-CA7 -i >>> Jail name: 13_0R-CA7 >>> Jail version: 13.0-RELEASE-p5 >>> Jail arch: arm.armv7 >>> Jail method: null >>> Jail mount: /usr/obj/DESTDIRs/13_0R-CA7-poud >>> Jail fs: =20 >>> Jail updated: 2021-11-04 01:48:49 >>> Jail pkgbase: disabled >>>=20 >>> but another not-investigated example was from: >>>=20 >>> # poudriere jail -j13_0R-CA72 -i >>> Jail name: 13_0R-CA72 >>> Jail version: 13.0-RELEASE-p5 >>> Jail arch: arm64.aarch64 >>> Jail method: null >>> Jail mount: /usr/obj/DESTDIRs/13_0R-CA72-poud >>> Jail fs: =20 >>> Jail updated: 2021-11-04 01:48:01 >>> Jail pkgbase: disabled >>>=20 >>> (so no 32-bit COMPAT involved). The apparent corruption >>> was in a different port (autoconfig, noticed by the >>> build of automake failing via config reporting >>> /usr/local/share/autoconf-2.69/autoconf/autoconf.m4f >>> being rejected). >>>=20 >>> /usr/obj/DESTDIRs/13_0R-CA7-poud/ and >>> /usr/obj/DESTDIRs/13_0R-CA72-poud/ and the like track the >>> system versions. >>>=20 >>> The media is an Optane 960 in the PCIe slot of a HoneyComb >>> (16 Cortex-A72's). The context is a root on ZFS one, ZFS >>> used in order to have bectl, not redundancy. >>>=20 >>> The ThreadRipper 1950X (so amd64) port builds did not give >>> evidence of such problems based on the updated system. (Also >>> Optane media in a PCIe slot, also root on ZFS.) But the >>> errors seem rare enough to not be able to conclude much. >>=20 >> For aarch64 targeting aarch64 there was also this >> explicit corruption notice during the poudriere(-devel) >> bulk build: >>=20 >> . . . >> [CA72_ZFS] Extracting arm-none-eabi-gcc-8.4.0_3: ......... >> pkg-static: Fail to extract = /usr/local/libexec/gcc/arm-none-eabi/8.4.0/lto1 from package: Lzma = library error: Corrupted input data >> [CA72_ZFS] Extracting arm-none-eabi-gcc-8.4.0_3... done >>=20 >> Failed to install the following 1 package(s): = /packages/All/arm-none-eabi-gcc-8.4.0_3.pkg >> *** Error code 1 >> Stop. >> make: stopped in /usr/ports/sysutils/u-boot-orangepi-plus-2e >>=20 >> I'm not yet to the point of retrying after removing >> arm-none-eabi-gcc-8.4.0_3 : other things are being built. >=20 >=20 > Another context with my prior general update of /usr/ports/ > and the matching port builds: Back then I used USE_TMPFS=3Dall > but the failure is based on USE_TMPFS-"data" instead. So: > lots more I/O. >=20 None of the 3 corruptions repeated during bulk builds that retried the builds that generated the files. All of the ports that failed by hitting the corruptions in what they depended on, built fine in teh retries. For reference: I'll note that, back when I was using USE_TMPFS=3Dall , I also did some separate bulk -a test runs, both aarch64 (Cortex-A72) native and Cortext-A72 targeting Cortex-A7 (armv7). None of those showed evidence of file corruptions. In general I've not had previous file corruptions with this system. (There was a little more than 245 GiBytes swap, which covered the tmpfs needs when they were large.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Tue Nov 16 04:34:25 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 32451185758E for ; Tue, 16 Nov 2021 04:34:35 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.protected-networks.net (mail.protected-networks.net [202.12.127.228]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.protected-networks.net", Issuer "R3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HtYB235SFz4cgP for ; Tue, 16 Nov 2021 04:34:34 +0000 (UTC) (envelope-from imb@protected-networks.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= protected-networks.net; h=content-transfer-encoding:content-type :content-type:subject:subject:from:from:content-language :user-agent:mime-version:date:date:message-id; s=201508; t= 1637037265; bh=JDgXF5dilsdzwAshIAisth6KzV+KmJeHY1GnJprN3h8=; b=F OhMyFaDDdlVmIzrG0Q143MbMKQZPhWXjnm9nyfAAeLmgre9H2FbGm6TGoubMdygt dJrMcaoXCL3dsm8PXz+araV27lJ3GCfMBUQDQ8AfrhmhtxDt3C2DIceUnOAtPzwB robq6VtINmZnxR4rlQkst3/7t7vFxyMYBSi0LfzCm0= Received: from [192.168.1.10] (toshi.auburn.protected-networks.net [192.168.1.10]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: imb@mail.protected-networks.net) by mail.protected-networks.net (Postfix) with ESMTPSA id DB8724720D for ; Mon, 15 Nov 2021 23:34:25 -0500 (EST) Message-ID: <674741a8-513f-ded4-c463-3b65c26560c5@protected-networks.net> Date: Mon, 15 Nov 2021 23:34:25 -0500 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.3.1 Content-Language: en-NZ To: freebsd-current Subject: cross-compiling for i386 on amd64 fails Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4HtYB235SFz4cgP X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=protected-networks.net header.s=201508 header.b="F OhMyFa"; dmarc=pass (policy=reject) header.from=protected-networks.net; spf=pass (mx1.freebsd.org: domain of imb@protected-networks.net designates 202.12.127.228 as permitted sender) smtp.mailfrom=imb@protected-networks.net X-Spamd-Result: default: False [-0.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[protected-networks.net:s=201508]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[protected-networks.net:+]; DMARC_POLICY_ALLOW(-0.50)[protected-networks.net,reject]; NEURAL_SPAM_SHORT(1.00)[1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:5716, ipnet:202.12.127.0/24, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] Reply-To: imb@protected-networks.net From: Michael Butler via freebsd-current X-Original-From: Michael Butler X-ThisMailContainsUnwantedMimeParts: N Haven't had time to identify which change caused this yet but I now get .. ===> lib/libsbuf (obj,all,install) ===> cddl/lib/libumem (obj,all,install) ===> cddl/lib/libnvpair (obj,all,install) ===> cddl/lib/libavl (obj,all,install) ld: error: /usr/obj/usr/src/i386.i386/tmp/usr/lib/libspl.a(assert.o) is incompatible with elf_i386_fbsd ===> cddl/lib/libspl (obj,all,install) cc: error: linker command failed with exit code 1 (use -v to see invocation) --- libavl.so.2 --- *** [libavl.so.2] Error code 1 make[4]: stopped in /usr/src/cddl/lib/libavl imb From nobody Tue Nov 16 07:33:49 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1E0521852E14 for ; Tue, 16 Nov 2021 07:34:22 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Htd9V09GZz4bdJ for ; Tue, 16 Nov 2021 07:34:22 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ua1-x934.google.com with SMTP id w23so17539774uao.5 for ; Mon, 15 Nov 2021 23:34:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=egtRLWKdOuOyHVvq3ID+tX2kG7oXq7Qf8RStJcdxbc4=; b=Enn9pdorCxfaXi2PRj7TSQsomW7OEDvbGeKjI6yG7EiDAHBRP5Q3SCTrmTFBxzQpnK EN8/kRkxLMNBpB/AlLPgADogrGg5XJSLZqw/+P0/04I0XSNIkIBjC2pNqKhthPM1+scE cnlNvCDoWRnhvfLZXOz6xbHCDj+X2Hcdt3rF3a/gEnVcOKC5iXSHdohIscIwFpF1/uPW f+mPtzjV58O5E/GzMJplBvC1LKrAx+EPN/8LGRCXrki3aA4oP4YX3k+MMpdCn84sEY/z CzPk172375lutBu/eYyXpXcThW2XDMm3bas0QBYvaw9cre1e+IyBYBSAwQlPKhcLmy1i DUrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=egtRLWKdOuOyHVvq3ID+tX2kG7oXq7Qf8RStJcdxbc4=; b=dfs7Wl7VkMyBZaZi/wZeOjoesPLBk/8QBAeDW7gkShIoTI+d1q/X1q0bNR3yD2b1Dt zTxtr8sCj4TWsQSihGiAy2LbiIYuojPyCMebDo965jKj1pOx4HTn6gcevt4MP49UnN6W Is5JkvaqrBqN2TVzX6TWR14r1a5JkiKwyYoqGQJVomb+UPO1HXFHSq92owIgSCgQVrwX 8cVoRJdr86ZdR2C0bRonQXY8RZuW+VYTEX95FoA7q0lMmD24MuqiKzoVJVeaQsJnhK9F chfcM6ZCOd8uhlpG2GnCzCtxi4Oje4mdUV0V/IRwjzzM0jXgF8pLoyyqQjPXcDOVGRlt JO7g== X-Gm-Message-State: AOAM530uIYbfvN0SQYIFE9xXJ6Fhb5uM3QsxtJI2+nVOG80xXFMNDx9x D31srAZWgpEpJjGF2mqt08+3C494M+Vf4lOkBPswhxgqzOg= X-Google-Smtp-Source: ABdhPJzRb4PCrzL1wGhsEkXjRuCpKXAy5fIi+uBcWxMkyZ7CXJ8mMMxRX2cJu3NxrcyZd+Wr8B8i/LFVbTOmx9BGbY0= X-Received: by 2002:a05:6102:5f2:: with SMTP id w18mr54632797vsf.6.1637048061515; Mon, 15 Nov 2021 23:34:21 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <674741a8-513f-ded4-c463-3b65c26560c5@protected-networks.net> In-Reply-To: <674741a8-513f-ded4-c463-3b65c26560c5@protected-networks.net> From: Warner Losh Date: Tue, 16 Nov 2021 00:33:49 -0700 Message-ID: Subject: Re: cross-compiling for i386 on amd64 fails To: Michael Butler Cc: freebsd-current Content-Type: multipart/alternative; boundary="0000000000002fe9ad05d0e2f43e" X-Rspamd-Queue-Id: 4Htd9V09GZz4bdJ X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --0000000000002fe9ad05d0e2f43e Content-Type: text/plain; charset="UTF-8" A meta-build worked for me just now... Warner On Mon, Nov 15, 2021 at 9:35 PM Michael Butler via freebsd-current < freebsd-current@freebsd.org> wrote: > Haven't had time to identify which change caused this yet but I now get .. > > ===> lib/libsbuf (obj,all,install) > ===> cddl/lib/libumem (obj,all,install) > ===> cddl/lib/libnvpair (obj,all,install) > ===> cddl/lib/libavl (obj,all,install) > ld: error: /usr/obj/usr/src/i386.i386/tmp/usr/lib/libspl.a(assert.o) is > incompatible with elf_i386_fbsd > ===> cddl/lib/libspl (obj,all,install) > cc: error: linker command failed with exit code 1 (use -v to see > invocation) > --- libavl.so.2 --- > *** [libavl.so.2] Error code 1 > > make[4]: stopped in /usr/src/cddl/lib/libavl > > imb > > --0000000000002fe9ad05d0e2f43e-- From nobody Tue Nov 16 09:40:37 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0E44F189E7C4 for ; Tue, 16 Nov 2021 09:40:41 +0000 (UTC) (envelope-from ludovit.koren@gmail.com) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HtgzC73gfz3ljy for ; Tue, 16 Nov 2021 09:40:39 +0000 (UTC) (envelope-from ludovit.koren@gmail.com) Received: by mail-ed1-x52b.google.com with SMTP id y12so28482953eda.12 for ; Tue, 16 Nov 2021 01:40:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:subject:user-mail-address:date:message-id:user-agent :mime-version; bh=SElkSPsfICGYMmRq6FQBFu3vcJV4+v9sUip6rpe9bno=; b=lIM3QnpI8WPOqU03xQ5PuB1wzESGaK8iKCYYUzwHFvighTHK9bZgPSVRKgHN8dYi/+ vzIaGRuk5s3vbj35WPxVI96C924aoQBa4NRkOLhxA5y20ClorqxOlyYQDwmColxUmQoI tFuQBJHAtkSmrQ6rUbTItLM8GBo3qmeCFSFgttA/a/cBevMa1jFdCDhKSnHxsBKjNq47 obrrFdRNTjjRWQe2TZ0WRkncfFqQQWWLhKYzhY50F1DKqCTwlRtEAAx6Em4BPrfqruAV hk+quLoTd6gMNYSs7yG199xYcWJAuQde6aggWBy9j+rWb4XmthR0jV9MvR49gEeJlbDR QUZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:subject:user-mail-address:date :message-id:user-agent:mime-version; bh=SElkSPsfICGYMmRq6FQBFu3vcJV4+v9sUip6rpe9bno=; b=HY5bFR0HMXeIQogMF1ZdqUSquOYH37y1f+NmBL0pKIPCRxkYcxkOVPyeVyf8FnRG3k lPUHaYppbAxyiPH0Ksiw+CSftHhUz2Hkzh4nR1qFc+E5gQbd7CV6GX59/FiC+nNfPU5M MrR02um1c2x2OZIV28V0+dzVn8mQ56DofHphKVmyJBIGjoRqRcy98DnIgotwG0zXHzFN 5HwF+l1DZd0op/bvAw/GmjM2GIi5lpVKlLxUTjnAHl5wHdqLKF9qelR+atatbiwWEuYa 9EHM9Cl49za5TH8aOuYwzJNTUd0ogFpMcEijVy1ex+FOlZzHkawG3ws4isxI/A7dzhII Gogg== X-Gm-Message-State: AOAM532WXX61OzEGqG9xdgmiL71zXEU94XqoqlbEjwZbf/6JQLzvzB7d pu3ckWKy1vXp+cbyKbOT0VzbbCgMUd4= X-Google-Smtp-Source: ABdhPJx+kGmcXF/qGGP7aHsq7Vb5vWCGyUWZ4vrKByneFOg9csVGHzLLBt0h3bx/Y9DoD0zubY4PpA== X-Received: by 2002:aa7:cf0a:: with SMTP id a10mr8372358edy.194.1637055638990; Tue, 16 Nov 2021 01:40:38 -0800 (PST) Received: from jedi.localdomain (adsl-dyn-28.95-102-251.t-com.sk. [95.102.251.28]) by smtp.gmail.com with ESMTPSA id ho17sm7898650ejc.111.2021.11.16.01.40.38 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Nov 2021 01:40:38 -0800 (PST) Received: by jedi.localdomain (Postfix, from userid 1001) id B2E5A1A8A19; Tue, 16 Nov 2021 10:40:37 +0100 (CET) From: Ludovit Koren To: freebsd-current@freebsd.org Subject: sound on FreeBSD 14.0-CURRENT User-Mail-Address: ludovit.koren@gmail.com Date: Tue, 16 Nov 2021 10:40:37 +0100 Message-ID: <86h7cc5tgq.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (berkeley-unix) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Rspamd-Queue-Id: 4HtgzC73gfz3ljy X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=lIM3QnpI; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of ludovitkoren@gmail.com designates 2a00:1450:4864:20::52b as permitted sender) smtp.mailfrom=ludovitkoren@gmail.com X-Spamd-Result: default: False [-1.90 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; HAS_ATTACHMENT(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.90)[-0.900]; RECEIVED_SPAMHAUS_PBL(0.00)[95.102.251.28:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~,3:~,4:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52b:from]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: Y --=-=-= Content-Type: text/plain Hi, I am running FreeBSD 14.0-CURRENT #0 main-n250646-c0525ab1d1c-dirty: Sat Nov 13 16:42:44 CET 2021 Here is the output from: cat /dev/sndstat Installed devices: pcm0: (play/rec) default pcm1: (play) pcm2: (play) Installed devices from userspace: dsp: (play/rec) vdsp: (play/rec) I am running: /usr/local/sbin/virtual_oss -B -D /var/run/virtual_oss/dsp.pid -T /dev/sndstat -S -i 8 -C 18 -c 18 -r 48000 -b 32 -s 512 -f /dev/dsp0 -c 2 -d dsp -c 18 -d vdsp -t vdsp.ctl I am not able to redirect to different output even if I try for example: sysctl hw.snd.default_unit=1 Please see the attached output from: sysctl dev.pcm, sysctl hw.snd and dmesg. I did not find any hint how to redirect the sound output to the different device except hw.snd.default_unit. The output remains in the default output. Am I missing something or doing something wrong? Regards, lk --=-=-=-- From nobody Tue Nov 16 09:48:57 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id D1C0518A28C8 for ; Tue, 16 Nov 2021 09:49:02 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Hth8t56knz3pZS for ; Tue, 16 Nov 2021 09:49:02 +0000 (UTC) (envelope-from hps@selasky.org) Received: from [10.36.2.165] (unknown [178.17.145.105]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 2901226017B; Tue, 16 Nov 2021 10:49:00 +0100 (CET) Message-ID: <8e946cd7-6380-87cc-9f9d-f624717a0954@selasky.org> Date: Tue, 16 Nov 2021 10:48:57 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: sound on FreeBSD 14.0-CURRENT Content-Language: en-US To: Ludovit Koren , freebsd-current@freebsd.org References: <86h7cc5tgq.fsf@gmail.com> From: Hans Petter Selasky In-Reply-To: <86h7cc5tgq.fsf@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4Hth8t56knz3pZS X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On 11/16/21 10:40, Ludovit Koren wrote: > > Hi, > > I am running FreeBSD 14.0-CURRENT #0 main-n250646-c0525ab1d1c-dirty: Sat Nov 13 16:42:44 CET 2021 > Here is the output from: > cat /dev/sndstat > Installed devices: > pcm0: (play/rec) default > pcm1: (play) > pcm2: (play) > Installed devices from userspace: > dsp: (play/rec) > vdsp: (play/rec) > > I am running: > /usr/local/sbin/virtual_oss -B -D /var/run/virtual_oss/dsp.pid -T /dev/sndstat -S -i 8 -C 18 -c 18 -r 48000 -b 32 -s 512 -f /dev/dsp0 -c 2 -d dsp -c 18 -d vdsp -t vdsp.ctl > > I am not able to redirect to different output even if I try for example: > > sysctl hw.snd.default_unit=1 > > > Please see the attached output from: sysctl dev.pcm, sysctl hw.snd and > dmesg. > > I did not find any hint how to redirect the sound output to the different > device except hw.snd.default_unit. The output remains in the default > output. Am I missing something or doing something wrong? > Hi, When you are using virtual_oss , hw.snd.default_unit is not used. man virtual_oss_cmd Try this instead: virtual_oss_cmd /dev/vdsp.ctl -f /dev/dsp1 --HPS From nobody Tue Nov 16 10:26:28 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 63149188E8BC for ; Tue, 16 Nov 2021 10:26:31 +0000 (UTC) (envelope-from ludovit.koren@gmail.com) Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Htj062zJmz4XWs for ; Tue, 16 Nov 2021 10:26:30 +0000 (UTC) (envelope-from ludovit.koren@gmail.com) Received: by mail-ed1-x531.google.com with SMTP id g14so21833338edb.8 for ; Tue, 16 Nov 2021 02:26:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:references:user-mail-address:date:in-reply-to :message-id:user-agent:mime-version; bh=uaE1CTP6ZWdY0y3u4eIjswwieYoBXIAghjd5ghWd6qM=; b=BGQGORf1CBTOS89T4uHEJassj4gkfVCxF/pRqqEhxYlSGs5UIIEwhn4HQI77ViqL0Q WrIbZYn/vBjC+HlKbBV1fdIWgIENWjGuAqvMhVvZRBpREGkeHFUuq3nAUPtSn1kQJ4+U LbxfHacLpWZIMYdCVpcYTXeKYjSQub4gVqb4lAEMn/N+ZQq8Mo7SSz4juBDb0vKPztbf +oKo8TC8SxtI69HUuS9JEmsY0XdihZ+VS7CqArzkUuR5c8VVyT/AO7RxTjI3P4VQv7ZD Q5vaKh5O44iN15JPlrao4vI40b8V/8Eu5bu9Hhri/OyF15DaQE4t/0H6ym/RkdHlYAuD PN0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:references:user-mail-address :date:in-reply-to:message-id:user-agent:mime-version; bh=uaE1CTP6ZWdY0y3u4eIjswwieYoBXIAghjd5ghWd6qM=; b=OIYSpxzlSVj/EnAGQvWcy7NnBRTeAwps++ypMAQj0uzajZ8fgnDamRnEeA/V9U3Sxe 7d3XgW2DXHsOeMVEMZg39h17t2KyFCXDDrY6DdGO6pE3mu2BT4gcLe37plVIIa+l8iuj aM1xHRs5+N/Itwv7RNTqsO9mW47dH9p2GdtJHf0dsoiL/yySHXjQE/ynRe0vXHqMx9dU 2ArkbrPsE/tbyv1TknjFFRoC5wDb2LtUvzxATiOxp5VdiE5ZBV8t3/OLeB7DUaDceYXY GUIOQYmUoEWx4Iw6R5Weh88M/l4fedjLENoanLEMH+eYylwg1mo8iB5UdDLyncog+AkX eDLA== X-Gm-Message-State: AOAM531c+4Nu5T/poMy8OGoBgqhPBnXXx9nXPXKS/UEj1sWt4wQoQfwf I6Zm8wBP/WV6cTpua+IcnLesr5LgtYg= X-Google-Smtp-Source: ABdhPJxX+HXLldogBkXFxFCQF7hktGxU0L/9kB/b/FXDQUkiUSo1/h6CIhhori/d2tuhlqRmoAYiJg== X-Received: by 2002:a17:906:2f10:: with SMTP id v16mr8207862eji.434.1637058389318; Tue, 16 Nov 2021 02:26:29 -0800 (PST) Received: from jedi.localdomain (adsl-dyn-28.95-102-251.t-com.sk. [95.102.251.28]) by smtp.gmail.com with ESMTPSA id hs20sm7873525ejc.26.2021.11.16.02.26.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Nov 2021 02:26:28 -0800 (PST) Received: by jedi.localdomain (Postfix, from userid 1001) id 3226B1A8A1C; Tue, 16 Nov 2021 11:26:28 +0100 (CET) From: Ludovit Koren To: Hans Petter Selasky Cc: freebsd-current@freebsd.org Subject: Re: sound on FreeBSD 14.0-CURRENT References: <86h7cc5tgq.fsf@gmail.com> <8e946cd7-6380-87cc-9f9d-f624717a0954@selasky.org> User-Mail-Address: ludovit.koren@gmail.com Date: Tue, 16 Nov 2021 11:26:28 +0100 In-Reply-To: <8e946cd7-6380-87cc-9f9d-f624717a0954@selasky.org> (Hans Petter Selasky's message of "Tue, 16 Nov 2021 10:48:57 +0100") Message-ID: <86czn05rcb.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (berkeley-unix) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain X-Rspamd-Queue-Id: 4Htj062zJmz4XWs X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=BGQGORf1; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of ludovitkoren@gmail.com designates 2a00:1450:4864:20::531 as permitted sender) smtp.mailfrom=ludovitkoren@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RECEIVED_SPAMHAUS_PBL(0.00)[95.102.251.28:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::531:from]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N >>>>> Hans Petter Selasky writes: > On 11/16/21 10:40, Ludovit Koren wrote: >> Hi, >> I am running FreeBSD 14.0-CURRENT #0 main-n250646-c0525ab1d1c-dirty: >> Sat Nov 13 16:42:44 CET 2021 >> Here is the output from: >> cat /dev/sndstat >> Installed devices: >> pcm0: (play/rec) default >> pcm1: (play) >> pcm2: (play) >> Installed devices from userspace: >> dsp: (play/rec) >> vdsp: (play/rec) >> I am running: >> /usr/local/sbin/virtual_oss -B -D /var/run/virtual_oss/dsp.pid -T >> /dev/sndstat -S -i 8 -C 18 -c 18 -r 48000 -b 32 -s 512 -f /dev/dsp0 >> -c 2 -d dsp -c 18 -d vdsp -t vdsp.ctl >> I am not able to redirect to different output even if I try for >> example: >> sysctl hw.snd.default_unit=1 >> Please see the attached output from: sysctl dev.pcm, sysctl hw.snd >> and >> dmesg. >> I did not find any hint how to redirect the sound output to the >> different >> device except hw.snd.default_unit. The output remains in the default >> output. Am I missing something or doing something wrong? >> > Hi, > When you are using virtual_oss , hw.snd.default_unit is not used. > man virtual_oss_cmd > Try this instead: > virtual_oss_cmd /dev/vdsp.ctl -f /dev/dsp1 Unfortunately, even the command is not working. lk From nobody Tue Nov 16 12:42:56 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1917818924FD for ; Tue, 16 Nov 2021 12:43:01 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Htm1c6dXQz3rX2 for ; Tue, 16 Nov 2021 12:43:00 +0000 (UTC) (envelope-from hps@selasky.org) Received: from [10.36.2.165] (unknown [178.17.145.105]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id F23FC26017B; Tue, 16 Nov 2021 13:42:58 +0100 (CET) Message-ID: <6c443abb-2d0f-ab04-2d8f-16e74323f4af@selasky.org> Date: Tue, 16 Nov 2021 13:42:56 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: sound on FreeBSD 14.0-CURRENT Content-Language: en-US To: Ludovit Koren Cc: freebsd-current@freebsd.org References: <86h7cc5tgq.fsf@gmail.com> <8e946cd7-6380-87cc-9f9d-f624717a0954@selasky.org> <86czn05rcb.fsf@gmail.com> From: Hans Petter Selasky In-Reply-To: <86czn05rcb.fsf@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4Htm1c6dXQz3rX2 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On 11/16/21 11:26, Ludovit Koren wrote: >>>>>> Hans Petter Selasky writes: > > > On 11/16/21 10:40, Ludovit Koren wrote: > >> Hi, > >> I am running FreeBSD 14.0-CURRENT #0 main-n250646-c0525ab1d1c-dirty: > >> Sat Nov 13 16:42:44 CET 2021 > >> Here is the output from: > >> cat /dev/sndstat > >> Installed devices: > >> pcm0: (play/rec) default > >> pcm1: (play) > >> pcm2: (play) > >> Installed devices from userspace: > >> dsp: (play/rec) > >> vdsp: (play/rec) > >> I am running: > >> /usr/local/sbin/virtual_oss -B -D /var/run/virtual_oss/dsp.pid -T > >> /dev/sndstat -S -i 8 -C 18 -c 18 -r 48000 -b 32 -s 512 -f /dev/dsp0 > >> -c 2 -d dsp -c 18 -d vdsp -t vdsp.ctl > >> I am not able to redirect to different output even if I try for > >> example: > >> sysctl hw.snd.default_unit=1 > >> Please see the attached output from: sysctl dev.pcm, sysctl hw.snd > >> and > >> dmesg. > >> I did not find any hint how to redirect the sound output to the > >> different > >> device except hw.snd.default_unit. The output remains in the default > >> output. Am I missing something or doing something wrong? > >> > > > Hi, > > > When you are using virtual_oss , hw.snd.default_unit is not used. > > > man virtual_oss_cmd > > > Try this instead: > > virtual_oss_cmd /dev/vdsp.ctl -f /dev/dsp1 > > Unfortunately, even the command is not working. > Maybe your virtual_oss installation needs to be upgraded then? It should be supported. --HPS From nobody Tue Nov 16 13:52:56 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 74B8C188CEB7 for ; Tue, 16 Nov 2021 13:53:13 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.protected-networks.net (mail.protected-networks.net [IPv6:2001:470:8d59:1::8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.protected-networks.net", Issuer "R3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HtnZd2HxYz4lY2 for ; Tue, 16 Nov 2021 13:53:13 +0000 (UTC) (envelope-from imb@protected-networks.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= protected-networks.net; h=content-transfer-encoding:content-type :content-type:in-reply-to:from:from:references:content-language :subject:subject:user-agent:mime-version:date:date:message-id; s=201508; t=1637070776; bh=6HIIQLs/k1pgui2Ov6zmubvJpHnEfE7PU3YG AEu5/ms=; b=ZFa/dgDucFx1/Ex/LhDiaVVhfgHAh0+Ircm0tR+Q23zWwMamQzOC LRPCfOJXq+m1lEoI5jTX2zCx7m7nAJK7+yoywB6kHUaqQVBew/P1y7Omno3gl9rJ xwGd8yrbmv5zWoECm2bwrqsxWbZxq0/8oEJPUrm0TQoPfvUJWXvUAjc= Received: from [192.168.1.10] (toshi.auburn.protected-networks.net [192.168.1.10]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: imb@mail.protected-networks.net) by mail.protected-networks.net (Postfix) with ESMTPSA id DA160DC94; Tue, 16 Nov 2021 08:52:56 -0500 (EST) Message-ID: <87b59860-0fb6-3404-878b-ad11f719e424@protected-networks.net> Date: Tue, 16 Nov 2021 08:52:56 -0500 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.3.1 Subject: Re: cross-compiling for i386 on amd64 fails Content-Language: en-NZ To: Warner Losh Cc: freebsd-current References: <674741a8-513f-ded4-c463-3b65c26560c5@protected-networks.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4HtnZd2HxYz4lY2 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: imb@protected-networks.net From: Michael Butler via freebsd-current X-Original-From: Michael Butler X-ThisMailContainsUnwantedMimeParts: N I should have been more specific .. I'm observing that "/usr/src/release/release.sh -c release-i386.conf" fails when targeting a i386 build on an amd64 host :-( On 11/16/21 02:33, Warner Losh wrote: > A meta-build worked for me just now... > > Warner > > On Mon, Nov 15, 2021 at 9:35 PM Michael Butler via freebsd-current < > freebsd-current@freebsd.org> wrote: > >> Haven't had time to identify which change caused this yet but I now get .. >> >> ===> lib/libsbuf (obj,all,install) >> ===> cddl/lib/libumem (obj,all,install) >> ===> cddl/lib/libnvpair (obj,all,install) >> ===> cddl/lib/libavl (obj,all,install) >> ld: error: /usr/obj/usr/src/i386.i386/tmp/usr/lib/libspl.a(assert.o) is >> incompatible with elf_i386_fbsd >> ===> cddl/lib/libspl (obj,all,install) >> cc: error: linker command failed with exit code 1 (use -v to see >> invocation) >> --- libavl.so.2 --- >> *** [libavl.so.2] Error code 1 >> >> make[4]: stopped in /usr/src/cddl/lib/libavl >> >> imb >> >> > From nobody Tue Nov 16 16:53:41 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id D9B3D189E74C for ; Tue, 16 Nov 2021 16:53:45 +0000 (UTC) (envelope-from ludovit.koren@gmail.com) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HtsZw3Pvyz4ljl for ; Tue, 16 Nov 2021 16:53:44 +0000 (UTC) (envelope-from ludovit.koren@gmail.com) Received: by mail-ed1-x533.google.com with SMTP id y12so34309729eda.12 for ; Tue, 16 Nov 2021 08:53:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:references:user-mail-address:date:in-reply-to :message-id:user-agent:mime-version; bh=9xSaiqnkBXtceV2MsxiiQyl/7Gr+c06yNbdRzZXA5xQ=; b=Jl/DljkuptlXO4kz90awjbk8E6K5cSHME6m6be4go8UuqZPiH0meU41mu559eCLFVw lCsXQ5kBBz2X9EQN9rO8I3iy0plfAGiEnq/pJ1AQZEcuGos/lEvl07ugZWFIE8FcjS5j i6DcuL6IzUli0DfaHIPr44vdDeOfDh+rEtQ0CAnBLrcqIQC40jpc5/KKTIRoJnqKwPYP q3r50yaPLLMGGpIupjlkRCsOS14PuXRco5XvpYMfYdoAih8PMEu85f+qPBlsbXvMr+60 EIRVWyY3XAh9/7DaQf5geujq8HsAl9q8nswpllQq7MF9TMNBL8ovn4MUTZRzwHZMllqN 4lLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:references:user-mail-address :date:in-reply-to:message-id:user-agent:mime-version; bh=9xSaiqnkBXtceV2MsxiiQyl/7Gr+c06yNbdRzZXA5xQ=; b=G7RaN+IE6uronLtYgwrjwrh7l2xOPB9SgIgr8ULhysEPIE/QngLL5ozRqEA3rUKxLd 1RxH9pgCeg5NbcNbzmB/noVNstGqTBnpmrvYPThcLFigaOeNemd5nDDl7Ypu1KhAhlGZ wgtSs5DHesKTvMTAnc6rsCmWv/zg+4tuj1ip+aw0ct3pwXDkKAKEHNUGARx3euLu6pDx 6Mynu6gvlEwyqZdlBlgkZ51wr4FKgi1M6ahMIgtaBriwnJf9Ntajq1/ykVhmQ5qdXn0S Fljjyl3yCeLYE0miY/g7XC6ZgygiBwu2KzGCsDoqzOhvKMAQCaZu/nAll3gtlD68dbby fvog== X-Gm-Message-State: AOAM5335O3eMbkuCQ1AMw3bvWlwihhWe2AUs0sIdJnKPidBByxRk+5Ht 4+a2TUY+kEReikTi0gGOpAbpCOghvFI= X-Google-Smtp-Source: ABdhPJzOuhWipZERYqAB4q1zprECjnMY/N1bW+k+02sdGzz9reoK1+XgbjAv6CRKI0ubaV+QcAJAnA== X-Received: by 2002:a05:6402:35cc:: with SMTP id z12mr11896131edc.393.1637081622748; Tue, 16 Nov 2021 08:53:42 -0800 (PST) Received: from jedi.localdomain (adsl-dyn-28.95-102-251.t-com.sk. [95.102.251.28]) by smtp.gmail.com with ESMTPSA id cs12sm8672564ejc.15.2021.11.16.08.53.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Nov 2021 08:53:42 -0800 (PST) Received: by jedi.localdomain (Postfix, from userid 1001) id 9D5D81A89ED; Tue, 16 Nov 2021 17:53:41 +0100 (CET) From: Ludovit Koren To: Hans Petter Selasky Cc: freebsd-current@freebsd.org Subject: Re: sound on FreeBSD 14.0-CURRENT References: <86h7cc5tgq.fsf@gmail.com> <8e946cd7-6380-87cc-9f9d-f624717a0954@selasky.org> <86czn05rcb.fsf@gmail.com> <6c443abb-2d0f-ab04-2d8f-16e74323f4af@selasky.org> User-Mail-Address: ludovit.koren@gmail.com Date: Tue, 16 Nov 2021 17:53:41 +0100 In-Reply-To: <6c443abb-2d0f-ab04-2d8f-16e74323f4af@selasky.org> (Hans Petter Selasky's message of "Tue, 16 Nov 2021 13:42:56 +0100") Message-ID: <868rxo59ey.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (berkeley-unix) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain X-Rspamd-Queue-Id: 4HtsZw3Pvyz4ljl X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b="Jl/Dljku"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of ludovitkoren@gmail.com designates 2a00:1450:4864:20::533 as permitted sender) smtp.mailfrom=ludovitkoren@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RECEIVED_SPAMHAUS_PBL(0.00)[95.102.251.28:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; NEURAL_SPAM_SHORT(1.00)[1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::533:from]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N >>>>> Hans Petter Selasky writes: > On 11/16/21 11:26, Ludovit Koren wrote: >>>>>>> Hans Petter Selasky writes: >> > On 11/16/21 10:40, Ludovit Koren wrote: >> >> Hi, >> >> I am running FreeBSD 14.0-CURRENT #0 main-n250646-c0525ab1d1c-dirty: >> >> Sat Nov 13 16:42:44 CET 2021 >> >> Here is the output from: >> >> cat /dev/sndstat >> >> Installed devices: >> >> pcm0: (play/rec) default >> >> pcm1: (play) >> >> pcm2: (play) >> >> Installed devices from userspace: >> >> dsp: (play/rec) >> >> vdsp: (play/rec) >> >> I am running: >> >> /usr/local/sbin/virtual_oss -B -D /var/run/virtual_oss/dsp.pid -T >> >> /dev/sndstat -S -i 8 -C 18 -c 18 -r 48000 -b 32 -s 512 -f /dev/dsp0 >> >> -c 2 -d dsp -c 18 -d vdsp -t vdsp.ctl >> >> I am not able to redirect to different output even if I try for >> >> example: >> >> sysctl hw.snd.default_unit=1 >> >> Please see the attached output from: sysctl dev.pcm, sysctl hw.snd >> >> and >> >> dmesg. >> >> I did not find any hint how to redirect the sound output to the >> >> different >> >> device except hw.snd.default_unit. The output remains in the default >> >> output. Am I missing something or doing something wrong? >> >> >> > Hi, >> > When you are using virtual_oss , hw.snd.default_unit is not >> used. >> > man virtual_oss_cmd >> > Try this instead: >> > virtual_oss_cmd /dev/vdsp.ctl -f /dev/dsp1 >> Unfortunately, even the command is not working. >> > Maybe your virtual_oss installation needs to be upgraded then? It > should be supported. >pkg info virtual_oss virtual_oss-1.2.15 Name : virtual_oss Version : 1.2.15 Installed on : Tue Nov 16 12:39:14 2021 CET Origin : audio/virtual_oss Architecture : FreeBSD:14:amd64 Prefix : /usr/local Categories : audio Licenses : BSD2CLAUSE Maintainer : hselasky@FreeBSD.org WWW : https://github.com/hselasky/virtual_oss Comment : Virtual OSS multi device mixer application Options : BLUETOOTH : on BT_SPEAKER : on COMMAND : on DEBUG : off EQUALIZER : on HTTPD : on Shared Libs required: libfftw3.so.3 libsamplerate.so.0 Annotations : FreeBSD_version: 1400041 Flat size : 140KiB Description : Virtual OSS is an audio mixing application that multiplexes and demultiplexes a single OSS device into multiple customizable OSS compatible devices using character devices in userspace. These devices can be used to record played back audio and mix the individual channels in multiple ways. Virtual OSS also supports playback and recording through bluetooth audio devices. WWW: https://github.com/hselasky/virtual_oss It is not working... Just a thought... Could not be the problem how are the apps built (chromium, firefox), i.e. which options are set on? regards, lk From nobody Tue Nov 16 17:00:36 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 14582185216D for ; Tue, 16 Nov 2021 17:00:38 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Htsks6tj3z4pV5; Tue, 16 Nov 2021 17:00:37 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro.local (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 530B41CC3; Tue, 16 Nov 2021 17:00:37 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Subject: Re: cross-compiling for i386 on amd64 fails To: imb@protected-networks.net, freebsd-current References: <674741a8-513f-ded4-c463-3b65c26560c5@protected-networks.net> From: John Baldwin Message-ID: Date: Tue, 16 Nov 2021 09:00:36 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 In-Reply-To: <674741a8-513f-ded4-c463-3b65c26560c5@protected-networks.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-ThisMailContainsUnwantedMimeParts: N On 11/15/21 8:34 PM, Michael Butler via freebsd-current wrote: > Haven't had time to identify which change caused this yet but I now get .. > > ===> lib/libsbuf (obj,all,install) > ===> cddl/lib/libumem (obj,all,install) > ===> cddl/lib/libnvpair (obj,all,install) > ===> cddl/lib/libavl (obj,all,install) > ld: error: /usr/obj/usr/src/i386.i386/tmp/usr/lib/libspl.a(assert.o) is > incompatible with elf_i386_fbsd > ===> cddl/lib/libspl (obj,all,install) > cc: error: linker command failed with exit code 1 (use -v to see invocation) > --- libavl.so.2 --- > *** [libavl.so.2] Error code 1 > > make[4]: stopped in /usr/src/cddl/lib/libavl My guess is that this was fixed by git: 9e9c651caceb - main - cddl: fix missing ZFS library dependencies -- John Baldwin From nobody Tue Nov 16 17:07:36 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B506E18563B6 for ; Tue, 16 Nov 2021 17:07:42 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Htsv21khxz4sl8 for ; Tue, 16 Nov 2021 17:07:42 +0000 (UTC) (envelope-from hps@selasky.org) Received: from [10.36.2.165] (unknown [178.17.145.105]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 6504B260393; Tue, 16 Nov 2021 18:07:40 +0100 (CET) Message-ID: <0bc2da89-337b-c6ed-fd41-0e31f6fde1ae@selasky.org> Date: Tue, 16 Nov 2021 18:07:36 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: sound on FreeBSD 14.0-CURRENT Content-Language: en-US To: Ludovit Koren Cc: freebsd-current@freebsd.org References: <86h7cc5tgq.fsf@gmail.com> <8e946cd7-6380-87cc-9f9d-f624717a0954@selasky.org> <86czn05rcb.fsf@gmail.com> <6c443abb-2d0f-ab04-2d8f-16e74323f4af@selasky.org> <868rxo59ey.fsf@gmail.com> From: Hans Petter Selasky In-Reply-To: <868rxo59ey.fsf@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4Htsv21khxz4sl8 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi, > > It is not working... > > Just a thought... Could not be the problem how are the apps built > (chromium, firefox), i.e. which options are set on? No, the default should work out of the box. What does "which virtual_oss_cmd" output? Maybe /usr/local/bin is not in your PATH? > > regards, > Can you show the commands you are running and the result printed in the terminal. --HPS From nobody Tue Nov 16 17:15:59 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 151CB1889DA4 for ; Tue, 16 Nov 2021 17:16:08 +0000 (UTC) (envelope-from meka@tilda.center) Received: from c3po.tilda.center (c3po.tilda.center [108.61.164.129]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Htt4l6Zy8z3CKV for ; Tue, 16 Nov 2021 17:16:07 +0000 (UTC) (envelope-from meka@tilda.center) Received: from tilda.center (178-220-5-137.static.isp.telekom.rs [178.220.5.137]) by c3po.tilda.center (Postfix) with ESMTPSA id E6A4311919; Tue, 16 Nov 2021 18:15:59 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tilda.center; s=c3po; t=1637082960; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=QtHXawgSuTwGOBt4NFAsgWYJtjcP0rIAOFp4kNspzGA=; b=ZR5HrtZazSJem43bN/qAuAaJRcdEG/IgPUf6T2bGxawJSNdBLwaxGH9ti5DnNHfCKmpdQX MA6sI1HkSdqSLuL3tNZq+4yUDWdjtVnikfuSwUNWUWbwfAxNyQtYOI+HlK2y/hzSSFSVSQ ojsFiiT7Aq/4OgLO1YmbpG2c/BdTXxg= Date: Tue, 16 Nov 2021 18:15:59 +0100 From: Goran =?utf-8?B?TWVracSH?= To: Ludovit Koren Cc: freebsd-current@freebsd.org Subject: Re: sound on FreeBSD 14.0-CURRENT Message-ID: <20211116171559.vi4hfd3upzcex2y2@tilda.center> References: <86h7cc5tgq.fsf@gmail.com> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ythn3nfya6nonlzk" Content-Disposition: inline In-Reply-To: <86h7cc5tgq.fsf@gmail.com> X-Rspamd-Queue-Id: 4Htt4l6Zy8z3CKV X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N --ythn3nfya6nonlzk Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 16, 2021 at 10:40:37AM +0100, Ludovit Koren wrote: >=20 > Hi, >=20 > I am running FreeBSD 14.0-CURRENT #0 main-n250646-c0525ab1d1c-dirty: Sat = Nov 13 16:42:44 CET 2021 > Here is the output from: > cat /dev/sndstat=20 > Installed devices: > pcm0: (play/rec) default > pcm1: (play) > pcm2: (play) > Installed devices from userspace: > dsp: (play/rec) > vdsp: (play/rec) >=20 > I am running: > /usr/local/sbin/virtual_oss -B -D /var/run/virtual_oss/dsp.pid -T /dev/sn= dstat -S -i 8 -C 18 -c 18 -r 48000 -b 32 -s 512 -f /dev/dsp0 -c 2 -d dsp -c= 18 -d vdsp -t vdsp.ctl This suspiciously looks like my config. For example, you're creating 18ch /dev/vdsp which I'm sure is not the channel count on your device. For start remove "-c 18 -d vdsp", that part is what you don't need. Anyway, why not using rc.conf and virtual_oss service? For start, it will create /var/run/virtual_oss which does not exist by default. >=20 > I am not able to redirect to different output even if I try for example: Be aware that something being pcm0 doesn't mean it will be parrent of dsp0. I'm not sure how to check which dsp device you need to use, though. Do ls -l /dev/dsp* and try them all. Regards, meka --ythn3nfya6nonlzk Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE1WIFkXy2ZeMKjjKEWj1TknovrLYFAmGT50cACgkQWj1Tknov rLZsVw//R1M1zA52Tm7MSJ8DhwHvgXedTz+eY9i3jr3ZYlaZRT4GanRyzbUvYzBr PRx2sgogG7N/u582oaey28HaIqPy1nD0FDFo4qvHn3Idie98bGLuhKnIA+A8Xyos UwI+Tnn5fCSOwVQEzsBxC+Ibxz7lYniz3+Uywjpyvvc0rajhvEKZNeDs4L6hyQVc SZiTbCeHdLborRk3FqX+5RUGMwoDCDA2B5XXUPVVKUWuGLyIiYxDL05YNy25fA1p 5+XscHG9qNFnZDQ/Rte3ENqedEYUt/VTYU2jfcPw83jorQ1mqFdplmh9Psc5tB3O +J55eRYRoxnVwY20WdnbygzILYQSCODvExfgTbY2VflZoc79/w/3n6YglzO/TK9c 3n4rnfJ3r2HDZYtnN/K4WPPhOjKueQsXOIOrwb2+TrlbULX7N7FcO8xrqHkLlrS6 NZZWIxzT1WZ0i1c0I8orknMgyUi6G0nnPiZFu9qZP5EivFN4/ZAB9rZb88nK9sXs RzWu+pQZCxxlKgYOx77yfQJ6NfI2cUYl/DrKHP9HgyBadQGivinm/5Lqj0oG2W0Z FscKPnq4XtIpKDkt0CXygtC23S6zY8lBbchaMkGCBU66L2m+gPcCHCwNqoNJ64y3 N3P/wYU1Oj9o3Mo7B5uk7n+IBL1OGuttCd+sNQwvL7wI9lY/yv4= =Rsio -----END PGP SIGNATURE----- --ythn3nfya6nonlzk-- From nobody Tue Nov 16 17:39:24 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 7B33B1898F75 for ; Tue, 16 Nov 2021 17:39:37 +0000 (UTC) (envelope-from ludovit.koren@gmail.com) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Httbr45XZz3Nf4 for ; Tue, 16 Nov 2021 17:39:36 +0000 (UTC) (envelope-from ludovit.koren@gmail.com) Received: by mail-ed1-x532.google.com with SMTP id g14so91416375edz.2 for ; Tue, 16 Nov 2021 09:39:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:references:user-mail-address:date:in-reply-to :message-id:user-agent:mime-version; bh=SWiz5OTzi0AJo3cvHsURzIfbnWxB1iCOUHI2pgTwtd4=; b=ZUSyFqUFniXLtSyCargadn8mouh1dPZ4pFwRO4mSvAchAXPnR0piZ8HngBJiN0AFiN AsXc+cGkcTEDIsrSu3xfPPRWbv5n1vWFbJRZZaIT0Eu08N5IcUam97K+hB6RgMsW0dVX t/FAdX/HVM36RL+GpuGyof1Eo1RpY1JaIGpJv++lvS4BXd8k9RW4IDQnXyU3wq9UF4EC tD/h2d4ZrwziBrG3e7NUx/x4lXavcyBqPrItnQ3mPTkh85jwE0/kgKjYY75iX7dL0iU6 o1JjQHgQRVY9jYYftGLXzZjST6eVWrQIIBM4uadg2A5hz8VKczNHhy6I8l5OePnN4t6T 9yrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:references:user-mail-address :date:in-reply-to:message-id:user-agent:mime-version; bh=SWiz5OTzi0AJo3cvHsURzIfbnWxB1iCOUHI2pgTwtd4=; b=Zpwx4Ddon6NYRyXnSaQLHYuaxwV4Xf9/THrhI5OQL1KbrBknwoog93p/Ny6Ogj6MhD +KfsCc4/I510E7z7+ncu2LKCAaLK5r9hnEYgf6w6aP3QIPXM+SKSTcjWsNht63uv6I0O BK1S4ulznaZGbapHbUlN5H8EkEmcFnBukYmQOYxK2UQVHJ9D7CyLZ5gTcaDM8ooZ+ALN XL4cKVzGBT7zJ+H6n3rWZCv7WzjPOCSz6+2xFnUwyhvqHwn58/6IXLPp3tQr8lFQhgRI yhgpEpQMDWxyeiaKI6tGsUCW10OavPRDYbmRhhG6AnP5E01ZYO5K/H+IvNpobKxJmeZm 67Bg== X-Gm-Message-State: AOAM533O89w7j4eZ9Cf9GGm/PgX75kITXaKYasIACr72QgDpkOJ9zdxG j6O3ifrjX9nVaLggGuRbFMYC76TzF9w= X-Google-Smtp-Source: ABdhPJxqvqrXL4df1IXYNbPRqW0SPAoHLB+7rIYKfxLLQBoWm1PQXJzTEEkOIPeq0qAnPoZBye+c6A== X-Received: by 2002:a17:906:1993:: with SMTP id g19mr12350158ejd.50.1637084375564; Tue, 16 Nov 2021 09:39:35 -0800 (PST) Received: from jedi.localdomain (adsl-dyn-28.95-102-251.t-com.sk. [95.102.251.28]) by smtp.gmail.com with ESMTPSA id d1sm9062239edn.56.2021.11.16.09.39.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Nov 2021 09:39:35 -0800 (PST) Received: by jedi.localdomain (Postfix, from userid 1001) id 527DE1A8A36; Tue, 16 Nov 2021 18:39:34 +0100 (CET) From: Ludovit Koren To: Goran =?utf-8?Q?Meki=C4=87?= Cc: freebsd-current@freebsd.org Subject: Re: sound on FreeBSD 14.0-CURRENT References: <86h7cc5tgq.fsf@gmail.com> <20211116171559.vi4hfd3upzcex2y2@tilda.center> User-Mail-Address: ludovit.koren@gmail.com Date: Tue, 16 Nov 2021 18:39:24 +0100 In-Reply-To: <20211116171559.vi4hfd3upzcex2y2@tilda.center> ("Goran =?utf-8?Q?Meki=C4=87=22's?= message of "Tue, 16 Nov 2021 18:15:59 +0100") Message-ID: <864k8c57ar.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (berkeley-unix) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Rspamd-Queue-Id: 4Httbr45XZz3Nf4 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=ZUSyFqUF; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of ludovitkoren@gmail.com designates 2a00:1450:4864:20::532 as permitted sender) smtp.mailfrom=ludovitkoren@gmail.com X-Spamd-Result: default: False [-6.10 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; SIGNED_PGP(-2.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[95.102.251.28:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::532:from]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable >>>>> Goran Meki=C4=87 writes: > On Tue, Nov 16, 2021 at 10:40:37AM +0100, Ludovit Koren wrote: >>=20 >> Hi, >>=20 >> I am running FreeBSD 14.0-CURRENT #0 main-n250646-c0525ab1d1c-dirty:= Sat Nov 13 16:42:44 CET 2021 >> Here is the output from: >> cat /dev/sndstat=20 >> Installed devices: >> pcm0: (play/rec) default >> pcm1: (play) >> pcm2: (play) >> Installed devices from userspace: >> dsp: (play/rec) >> vdsp: (play/rec) >>=20 >> I am running: >> /usr/local/sbin/virtual_oss -B -D /var/run/virtual_oss/dsp.pid -T >> /dev/sndstat -S -i 8 -C 18 -c 18 -r 48000 -b 32 -s 512 -f /dev/dsp0 >> -c 2 -d dsp -c 18 -d vdsp -t vdsp.ctl > This suspiciously looks like my config. For example, you're creating > 18ch /dev/vdsp which I'm sure is not the channel count on your device. > For start remove "-c 18 -d vdsp", that part is what you don't need. > Anyway, why not using rc.conf and virtual_oss service? For start, it > will create /var/run/virtual_oss which does not exist by default. >>=20 >> I am not able to redirect to different output even if I try for exam= ple: > Be aware that something being pcm0 doesn't mean it will be parrent of > dsp0. I'm not sure how to check which dsp device you need to use, > though. Do ls -l /dev/dsp* and try them all. That is exactly what I did before I tried mailing list... lk --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJMBAEBCAA2FiEEI5IvKkW9bSjxdViiIWbnEQGrrxcFAmGT7MwYHGx1ZG92aXQu a29yZW5AZ21haWwuY29tAAoJECFm5xEBq68XOpEP/R41xW/13cYuKouGgtGSayh/ w227yc84VbSPfFwqiy/qgYktyoaio1oww0AIyQe6rtXSz2mAC8BWC1P24Qwqx22X tFAWU2KS7Gz/cQa17+gzWIjHWHObmyZoIcSQ4DCy50jIimHytkNlqDU5z3VH1dVH tFwc87BsmJdiOFbthgmsBeFMkPDOtkzWJEhGh6z8o1OtCpmmXJOy1lDXvJBiyntB q1bM1OD6Q5Khm3kzfYjn1Q1quGrEakje54cQw2kgoFWz0/d8FycwehhI+3/BekcA oz3GG+8Vxr1ETeLYfmyKTeMF4lrZxlSp9rZqIAynkoFB8Ih3wl2irECg+3/NYN2C PB66Ncu83LIu6lHv1+mLjT4J7QiQEE3LuR8PXqIu+q2RQnNtAVYl9mN63XthrSDS BeHVs4Kx8RdDsgxIM2ed+bniIpxTxXkMnWTC7tb0UucPEflaCOPFsaKSbcjPDd/r rXtkxfpO7I3MvV4yzXwoG0IxW6c1WtpDDxLhJLERtDDroMnxFIHFoYoBop9mR07B juFSW+MWzBHYDo5QBkrTovFr/jjgr0TnalCH1KwAeaTpLucL6MRXJ1+jITHIqGoN BWzeJiEuy0h6kfyG56soh+KWN7HXP0WUM0IqQIO4FzqcJ7tx81Q9zcuMjMQNa/cb Q/NXHTpEeFA/rvV1ATN1 =cGfq -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Nov 16 19:59:05 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3878E18986C3 for ; Tue, 16 Nov 2021 19:59:08 +0000 (UTC) (envelope-from ludovit.koren@gmail.com) Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Htxhq31bGz3FL2 for ; Tue, 16 Nov 2021 19:59:07 +0000 (UTC) (envelope-from ludovit.koren@gmail.com) Received: by mail-ed1-x536.google.com with SMTP id y13so17968133edd.13 for ; Tue, 16 Nov 2021 11:59:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:references:user-mail-address:date:in-reply-to :message-id:user-agent:mime-version; bh=qtaX/F8HemWY1ftLeuh4hl8u+a7YIUgJz3aRZoZoykg=; b=KJuDtsN5Kf19fv1srMiV9xNxSEzktj18oa+/damv1b+GPZrNbdhRHv8i76prb+YZHO HDpGUdmv5QNOKDmrOvfRuwBwOsxRZ/RKIyq72KOdXYtWcSmK1DNQQpxlSaWl59RwEtTR /kiPij/G8bIZ5QyEuSQH16KXgsVhZ5sMHA6jV9rsrFyBusgFqbOSY4wmloV8TeqYVcJb AclhYX+Z4kX/xkIf72UigsP7E/TuYzExRM3P/kr+lAKPsIT7E2fq21BIHN+12kRq4rEm 6YehQvCORwO2leLedFuvGvusjk/Ezq6gHcXAUCZk/Li1WgjRbVvehBmCZLzmKYgYto/J wV+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:references:user-mail-address :date:in-reply-to:message-id:user-agent:mime-version; bh=qtaX/F8HemWY1ftLeuh4hl8u+a7YIUgJz3aRZoZoykg=; b=y8tO1J8Oz5xIsZvWm7XdQz7mSpFfK58YkzIj9TJWXoKDNeVM5SsFIlVhMxzjwconap 3CuXY4I64RipfFt8u/mtZ/fa9I4Sb+Eo+u70J7hiTQvmxQriOkMU01jIfgIWxn3dRPKt Lp+ju6mb1ghg1MTwc9qQKmt0v306OLEed54avWr8xz2MEnKyTLbRqYuaGJVdkz+ynjZp vVfpu/oKhdKwMZwCqsqBe8H99jl0N8abIYYUmxrTljgcAk1SdCN8RYCPcsxveI2pBvr3 Yvo64JXXBJKTmM/oB74SgCyAoeq8dHiwoVqYE4cbf6fwmt9LnwW6wzswLM3J/pzgH3Qv T4jA== X-Gm-Message-State: AOAM530uSxVO+TQE9Q2hKbMXH+h50K2FtO1CI4MJ8XF8HkklYe5ePaqV jHGaVBcB1R+gujRHcXCjwilAK3IRvHk= X-Google-Smtp-Source: ABdhPJwcXcxjIGIt2FjcGhGdQo4rknKTo7z2aLKh21Dh0ETaTApqoRUFcSUCoioyUpKwRtnHcxBIdA== X-Received: by 2002:a05:6402:1cb2:: with SMTP id cz18mr13319614edb.99.1637092746394; Tue, 16 Nov 2021 11:59:06 -0800 (PST) Received: from jedi.localdomain (adsl-dyn-28.95-102-251.t-com.sk. [95.102.251.28]) by smtp.gmail.com with ESMTPSA id p10sm9600186edj.91.2021.11.16.11.59.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Nov 2021 11:59:05 -0800 (PST) Received: by jedi.localdomain (Postfix, from userid 1001) id 125F71A8A3E; Tue, 16 Nov 2021 20:59:05 +0100 (CET) From: Ludovit Koren To: Hans Petter Selasky Cc: freebsd-current@freebsd.org Subject: Re: sound on FreeBSD 14.0-CURRENT References: <86h7cc5tgq.fsf@gmail.com> <8e946cd7-6380-87cc-9f9d-f624717a0954@selasky.org> <86czn05rcb.fsf@gmail.com> <6c443abb-2d0f-ab04-2d8f-16e74323f4af@selasky.org> <868rxo59ey.fsf@gmail.com> <0bc2da89-337b-c6ed-fd41-0e31f6fde1ae@selasky.org> User-Mail-Address: ludovit.koren@gmail.com Date: Tue, 16 Nov 2021 20:59:05 +0100 In-Reply-To: <0bc2da89-337b-c6ed-fd41-0e31f6fde1ae@selasky.org> (Hans Petter Selasky's message of "Tue, 16 Nov 2021 18:07:36 +0100") Message-ID: <86zgq350ty.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (berkeley-unix) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain X-Rspamd-Queue-Id: 4Htxhq31bGz3FL2 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=KJuDtsN5; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of ludovitkoren@gmail.com designates 2a00:1450:4864:20::536 as permitted sender) smtp.mailfrom=ludovitkoren@gmail.com X-Spamd-Result: default: False [-2.04 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RECEIVED_SPAMHAUS_PBL(0.00)[95.102.251.28:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; NEURAL_SPAM_SHORT(0.96)[0.960]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::536:from]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N >>>>> Hans Petter Selasky writes: > Hi, >> It is not working... >> Just a thought... Could not be the problem how are the apps built >> (chromium, firefox), i.e. which options are set on? > No, the default should work out of the box. > What does "which virtual_oss_cmd" output? which virtual_oss_cmd /usr/local/sbin/virtual_oss_cmd > Maybe /usr/local/bin is not in your PATH? env SHELL=/usr/local/bin/bash WORDLIST=/usr/home/koren/ispell.words crt=24 EDITOR=vi ENV=/usr/home/koren/.shrc PWD=/usr/home/koren LOGNAME=koren TEXINPUTS=.:/usr/local/lib/texmf/tex//:/usr/local/share/texmf/tex//:/usr/local/share/texmf-dist/tex//:/usr/home/koren/others:/usr/home/koren/mytex:/usr/home/koren/projects/interpre/manual/english MANPATH=/usr/share/man:/usr/X11R6/man:/usr/local/man:/usr/local/pgsql/man HOME=/usr/home/koren LANG=C.UTF-8 EXINIT=set redraw wm=8 TEXEDIT=/usr/local/bin/emacs +%d %s SSH_CONNECTION=192.168.2.16 15340 192.168.2.19 22 PGLIB=/usr/local/pgsql/lib TERM=xterm USER=koren MORE=-cei mail=/usr/spool/mail/koren DISPLAY=localhost:11.0 SHLVL=1 PAGER=more MM_CHARSET=UTF-8 PS1=\! \h|\w> SSH_CLIENT=192.168.2.16 15340 22 PGDATA=/usr/local/pgsql/data host=jedi PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin:/usr/X11R6/bin:/usr/home/koren/bin BLOCKSIZE=K MAIL=/usr/spool/mail/koren SSH_TTY=/dev/pts/11 _=/usr/bin/env >> regards, >> > Can you show the commands you are running and the result printed in > the terminal. virtual_oss_cmd /dev/dsp.ctl -f /dev/dsp1.0 virtual_oss_cmd /dev/dsp.ctl -f /dev/dsp2.0 virtual_oss_cmd /dev/dsp.ctl -f /dev/dsp1 virtual_oss_cmd /dev/dsp.ctl -f /dev/dsp2 no output and trying to switch to the jack headphones and listening output from firefox of chrome. the sound is coming only from speakers... lk From nobody Tue Nov 16 20:25:46 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id F29081856406 for ; Tue, 16 Nov 2021 20:25:59 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HtyHq5q9yz3PCg for ; Tue, 16 Nov 2021 20:25:59 +0000 (UTC) (envelope-from hps@selasky.org) Received: from [10.36.2.165] (unknown [178.17.145.105]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id C73822600D4; Tue, 16 Nov 2021 21:25:51 +0100 (CET) Message-ID: <17bb4c38-18d1-ac26-2bfe-d55ba3a23641@selasky.org> Date: Tue, 16 Nov 2021 21:25:46 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: sound on FreeBSD 14.0-CURRENT Content-Language: en-US To: Ludovit Koren Cc: freebsd-current@freebsd.org References: <86h7cc5tgq.fsf@gmail.com> <8e946cd7-6380-87cc-9f9d-f624717a0954@selasky.org> <86czn05rcb.fsf@gmail.com> <6c443abb-2d0f-ab04-2d8f-16e74323f4af@selasky.org> <868rxo59ey.fsf@gmail.com> <0bc2da89-337b-c6ed-fd41-0e31f6fde1ae@selasky.org> <86zgq350ty.fsf@gmail.com> From: Hans Petter Selasky In-Reply-To: <86zgq350ty.fsf@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4HtyHq5q9yz3PCg X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On 11/16/21 20:59, Ludovit Koren wrote: >>>>>> Hans Petter Selasky writes: > > > Hi, > >> It is not working... > >> Just a thought... Could not be the problem how are the apps built > >> (chromium, firefox), i.e. which options are set on? > > > No, the default should work out of the box. > > > What does "which virtual_oss_cmd" output? > > which virtual_oss_cmd > /usr/local/sbin/virtual_oss_cmd > > > Maybe /usr/local/bin is not in your PATH? > > env > SHELL=/usr/local/bin/bash > WORDLIST=/usr/home/koren/ispell.words > crt=24 > EDITOR=vi > ENV=/usr/home/koren/.shrc > PWD=/usr/home/koren > LOGNAME=koren > TEXINPUTS=.:/usr/local/lib/texmf/tex//:/usr/local/share/texmf/tex//:/usr/local/share/texmf-dist/tex//:/usr/home/koren/others:/usr/home/koren/mytex:/usr/home/koren/projects/interpre/manual/english > MANPATH=/usr/share/man:/usr/X11R6/man:/usr/local/man:/usr/local/pgsql/man > HOME=/usr/home/koren > LANG=C.UTF-8 > EXINIT=set redraw wm=8 > TEXEDIT=/usr/local/bin/emacs +%d %s > SSH_CONNECTION=192.168.2.16 15340 192.168.2.19 22 > PGLIB=/usr/local/pgsql/lib > TERM=xterm > USER=koren > MORE=-cei > mail=/usr/spool/mail/koren > DISPLAY=localhost:11.0 > SHLVL=1 > PAGER=more > MM_CHARSET=UTF-8 > PS1=\! \h|\w> > SSH_CLIENT=192.168.2.16 15340 22 > PGDATA=/usr/local/pgsql/data > host=jedi > PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin:/usr/X11R6/bin:/usr/home/koren/bin > BLOCKSIZE=K > MAIL=/usr/spool/mail/koren > SSH_TTY=/dev/pts/11 > _=/usr/bin/env > > >> regards, > >> > > > Can you show the commands you are running and the result printed in > > the terminal. > > virtual_oss_cmd /dev/dsp.ctl -f /dev/dsp1.0 > virtual_oss_cmd /dev/dsp.ctl -f /dev/dsp2.0 > virtual_oss_cmd /dev/dsp.ctl -f /dev/dsp1 > virtual_oss_cmd /dev/dsp.ctl -f /dev/dsp2 > > no output > Hi, Maybe the output and input are two different DSP devices. Try using the -P /dev/dsp1 and -R /dev/dsp0 options instead to sepecify each device separately. --HPS From nobody Tue Nov 16 20:55:49 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 2B6C918950DE for ; Tue, 16 Nov 2021 20:55:53 +0000 (UTC) (envelope-from ludovit.koren@gmail.com) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HtyyJ2BSCz3pVM for ; Tue, 16 Nov 2021 20:55:52 +0000 (UTC) (envelope-from ludovit.koren@gmail.com) Received: by mail-ed1-x532.google.com with SMTP id t5so932988edd.0 for ; Tue, 16 Nov 2021 12:55:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:references:user-mail-address:date:in-reply-to :message-id:user-agent:mime-version; bh=QT1dmW6T7gmoWSxmF80MTcmKOsodQi8O9f+COY5nIyc=; b=kQJ6NTNnZQUDJFCaNGaDqbU61glD30oWurxUlfVOCO+Z+wAv5EydRPlqG89oqfIYki 5g9+3sZhWAYs/xJ410+ZQ1qmqGvgOa8odJ1NedOhQwRzJMWJ8VbSX3isSTFF0Qgdi7nW eNLRjKdndmarzcAXPru2m1RbiWwF4k+U0b/UbX3BXRGEeU9mfmSKqZG+39GFRlaLultc SFL1jVuqvODIo2lH+l72ehJR6B/HAwmFF5DbccsVFppyEO3djG29C7/DP6VX0XKc+/JS K/avwAfx3nmB+fKoeG62t56ZLMovFXa06/jHpIxkFzzlJCaE+jA9Frq8UZYD3WBc7EvG AKMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:references:user-mail-address :date:in-reply-to:message-id:user-agent:mime-version; bh=QT1dmW6T7gmoWSxmF80MTcmKOsodQi8O9f+COY5nIyc=; b=a+a+BTFqhmcvq1cX8LyfuF+AH7UPkTaRrM9WQmMIWujWcL+DAV39BlZOvHBWPdmgMd 60+km+cG1RY2HzCPNisziZLECepxriUf9hWIuDgsdYdyHIW7OEvXJE8ccKf/zAnwkb70 9C4cimguOa/7FSO/1mLdyyK0CUqmPuirT7/5YCQd2ly6uVXdU90Cy856kIqDRWTjFLTy frnPuwRSMQd4bmAxtKIvHZE4LQvp7yi4je7sstR5x85LdeIRZFo9xnLCWJKG4pea79yj WNu3fkg5HZCca8xnUAl4uUmpi71BCgsAvKVtcfVA/u+o/l6C5A38LHDDuOk3xgGuVnPh rgfw== X-Gm-Message-State: AOAM5319BkSFNPE+ciD+skgVBZNqH0XrWA1TeSidSqfcZA59W5iwbbAm LG0AySJwFQVfOenMyLnOu3J0gOmSQY4= X-Google-Smtp-Source: ABdhPJzSRU/DySaQ05ic8kGZt+lvadnwKhLXgmGEc7hLHyI6IonB+u0YB7z79YM6//46mwhNldUnIw== X-Received: by 2002:a17:906:9b96:: with SMTP id dd22mr14236439ejc.422.1637096151249; Tue, 16 Nov 2021 12:55:51 -0800 (PST) Received: from jedi.localdomain (adsl-dyn-28.95-102-251.t-com.sk. [95.102.251.28]) by smtp.gmail.com with ESMTPSA id sb19sm9207164ejc.120.2021.11.16.12.55.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Nov 2021 12:55:50 -0800 (PST) Received: by jedi.localdomain (Postfix, from userid 1001) id 01C941A8A43; Tue, 16 Nov 2021 21:55:49 +0100 (CET) From: Ludovit Koren To: Hans Petter Selasky Cc: freebsd-current@freebsd.org Subject: Re: sound on FreeBSD 14.0-CURRENT References: <86h7cc5tgq.fsf@gmail.com> <8e946cd7-6380-87cc-9f9d-f624717a0954@selasky.org> <86czn05rcb.fsf@gmail.com> <6c443abb-2d0f-ab04-2d8f-16e74323f4af@selasky.org> <868rxo59ey.fsf@gmail.com> <0bc2da89-337b-c6ed-fd41-0e31f6fde1ae@selasky.org> <86zgq350ty.fsf@gmail.com> <17bb4c38-18d1-ac26-2bfe-d55ba3a23641@selasky.org> User-Mail-Address: ludovit.koren@gmail.com Date: Tue, 16 Nov 2021 21:55:49 +0100 In-Reply-To: <17bb4c38-18d1-ac26-2bfe-d55ba3a23641@selasky.org> (Hans Petter Selasky's message of "Tue, 16 Nov 2021 21:25:46 +0100") Message-ID: <86v90r4y7e.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (berkeley-unix) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain X-Rspamd-Queue-Id: 4HtyyJ2BSCz3pVM X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=kQJ6NTNn; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of ludovitkoren@gmail.com designates 2a00:1450:4864:20::532 as permitted sender) smtp.mailfrom=ludovitkoren@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RECEIVED_SPAMHAUS_PBL(0.00)[95.102.251.28:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::532:from]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N >>>>> Hans Petter Selasky writes: > On 11/16/21 20:59, Ludovit Koren wrote: >>>>>>> Hans Petter Selasky writes: >> > Hi, >> >> It is not working... >> >> Just a thought... Could not be the problem how are the apps built >> >> (chromium, firefox), i.e. which options are set on? >> > No, the default should work out of the box. >> > What does "which virtual_oss_cmd" output? >> which virtual_oss_cmd >> /usr/local/sbin/virtual_oss_cmd >> > Maybe /usr/local/bin is not in your PATH? >> env >> SHELL=/usr/local/bin/bash >> WORDLIST=/usr/home/koren/ispell.words >> crt=24 >> EDITOR=vi >> ENV=/usr/home/koren/.shrc >> PWD=/usr/home/koren >> LOGNAME=koren >> TEXINPUTS=.:/usr/local/lib/texmf/tex//:/usr/local/share/texmf/tex//:/usr/local/share/texmf-dist/tex//:/usr/home/koren/others:/usr/home/koren/mytex:/usr/home/koren/projects/interpre/manual/english >> MANPATH=/usr/share/man:/usr/X11R6/man:/usr/local/man:/usr/local/pgsql/man >> HOME=/usr/home/koren >> LANG=C.UTF-8 >> EXINIT=set redraw wm=8 >> TEXEDIT=/usr/local/bin/emacs +%d %s >> SSH_CONNECTION=192.168.2.16 15340 192.168.2.19 22 >> PGLIB=/usr/local/pgsql/lib >> TERM=xterm >> USER=koren >> MORE=-cei >> mail=/usr/spool/mail/koren >> DISPLAY=localhost:11.0 >> SHLVL=1 >> PAGER=more >> MM_CHARSET=UTF-8 >> PS1=\! \h|\w> >> SSH_CLIENT=192.168.2.16 15340 22 >> PGDATA=/usr/local/pgsql/data >> host=jedi >> PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin:/usr/X11R6/bin:/usr/home/koren/bin >> BLOCKSIZE=K >> MAIL=/usr/spool/mail/koren >> SSH_TTY=/dev/pts/11 >> _=/usr/bin/env >> >> regards, >> >> >> > Can you show the commands you are running and the result >> printed in >> > the terminal. >> virtual_oss_cmd /dev/dsp.ctl -f /dev/dsp1.0 >> virtual_oss_cmd /dev/dsp.ctl -f /dev/dsp2.0 >> virtual_oss_cmd /dev/dsp.ctl -f /dev/dsp1 >> virtual_oss_cmd /dev/dsp.ctl -f /dev/dsp2 >> no output >> > Hi, > Maybe the output and input are two different DSP devices. > Try using the -P /dev/dsp1 and -R /dev/dsp0 options instead to > sepecify each device separately. Still the same result... lk From nobody Tue Nov 16 22:30:19 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 22705189B968 for ; Tue, 16 Nov 2021 22:30:32 +0000 (UTC) (envelope-from mw@semihalf.com) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Hv13W3cq4z4rJn for ; Tue, 16 Nov 2021 22:30:31 +0000 (UTC) (envelope-from mw@semihalf.com) Received: by mail-lf1-x12a.google.com with SMTP id b40so1448888lfv.10 for ; Tue, 16 Nov 2021 14:30:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf-com.20210112.gappssmtp.com; s=20210112; h=mime-version:from:date:message-id:subject:to:cc; bh=OUwuJBUWw8yZGbd3k5PPVXOxDFl9VXn8n6umoHdL5PM=; b=cLPNOJYzT/Mi2tzszrwj1eVL18IUyrUkohFsnlhz6a3TSZygBIIEG1xI091/ddSpig couhE/n6x+bKI4H6deHWnROhP7ubp13ANsBry9RMl/+4HH59shXZ6C1iqNS7M5r4GZbx 7ZIoEgB9GWxy7b5NaDoXtMvsmi08WlbSWlDl9C+HmOnxO4c88FZDUJboNd/Aoz6o17Nl VygScl4h4lOnGSvLQoQ5alpj0wHxIUXWBW+lfxB6o14ETByN2o0CMLYbhZpdZXo/zzWv IbZuB1Pkd0VK4Kcvnu8LYmk62xN20p73B/b+oVZcNs1w2cydExLxqvqzuvVLaR/sE6Op lMPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=OUwuJBUWw8yZGbd3k5PPVXOxDFl9VXn8n6umoHdL5PM=; b=V0q1uy4M95f+Lm+aWWwInxlx1DavkL8IA97jZW9ycTyDdxzuvKM6/cKFGBhcsQAqK+ /IhvuSmK4X1xHkWnx6S+0l24n4gFldHeELzWyMZv1CQFjU3h1vMAokkTnAdY3bzhbiyl JHQA2/qqPUYzxHRULYmShRBQkWpK2WCXc2i+0C395G3nlbztUdr2xjKhc4Z33Y0Zg1tE OIR/z9mu4IKi8vk+8Q7V0w6DDZyk1XiE8jY8Lkok8uy2/Xz0VySvX11Gx8w35wXT1BBr Xvq12bSwtV7gbd/y8HgSSon3MFIGQ/y8TFwQAFnCm9XrvZNv80nUQhDHaSstvVhTBJ6M eqdQ== X-Gm-Message-State: AOAM531N6Dd61e8eg4fI8J7L7dsUSzK3v5MkK3E4v8C0UfJcKzm7nOpb Mkhoowaj984qgLDQfGh56OK2Z7rB9jC4kfqEo31lE8V1yAx5ag== X-Google-Smtp-Source: ABdhPJxNxxVRaxX1f8GrbQtF26xaOutii4RBVYsD2a3pB1WSw7bLm/g4jEGHV3FOMYUbGK5zQ55o8uW0P033uYGzRkQ= X-Received: by 2002:ac2:4c34:: with SMTP id u20mr10479979lfq.671.1637101830197; Tue, 16 Nov 2021 14:30:30 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 From: Marcin Wojtas Date: Tue, 16 Nov 2021 23:30:19 +0100 Message-ID: Subject: HEADS-UP: ASLR for 64-bit executables enabled by default on main To: freebsd-current@freebsd.org Cc: Fabien Thomas , MARECHAL Boris , Rafal Jaworowski , Damien DEVILLE Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4Hv13W3cq4z4rJn X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=semihalf-com.20210112.gappssmtp.com header.s=20210112 header.b=cLPNOJYz; dmarc=none; spf=none (mx1.freebsd.org: domain of mw@semihalf.com has no SPF policy when checking 2a00:1450:4864:20::12a) smtp.mailfrom=mw@semihalf.com X-Spamd-Result: default: False [0.70 / 15.00]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[semihalf-com.20210112.gappssmtp.com:s=20210112]; FREEFALL_USER(0.00)[mw]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(1.00)[1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[semihalf.com]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[semihalf-com.20210112.gappssmtp.com:+]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::12a:from]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N As of b014e0f15bc7 the ASLR (Address Space Layout Randomization) feature becomes enabled for the all 64-bit binaries by default. Address Space Layout Randomization (ASLR) is an exploit mitigation technique implemented in the majority of modern operating systems. It involves randomly positioning the base address of an executable and the position of libraries, heap, and stack, in a process's address space. Although over the years ASLR proved to not guarantee full OS security on its own, this mechanism can make exploitation more difficult (especially when combined with other methods, such as W^X). Tests on the tier 1 64-bit architectures demonstrated that the ASLR is stable and does not result in noticeable performance degradation, therefore it is considered safe to enable this mechanism by default. Moreover its effectiveness is increased for PIE (Position Independent Executable) binaries. Thanks to commit 9a227a2fd642 ("Enable PIE by default on 64-bit architectures"), building from src is not necessary to have PIE binaries and it is enough to control usage of ASLR in the OS solely by setting the appropriate sysctls. The defaults were toggled for the 64-bit PIE and non-PIE executables. As for the drawbacks, a consequence of using the ASLR is more significant VM fragmentation, hence the issues may be encountered in the systems with a limited address space in high memory consumption cases, such as buildworld. As a result, although the tests on 32-bit architectures with ASLR enabled were mostly on par with what was observed on 64-bit ones, the defaults for the former are not changed at this time. Also, for the sake of safety the feature remains disabled for 32-bit executables on 64-bit machines, too. The committed change affects the overall OS operation, so the following should be taken into consideration: * Address space fragmentation. * A changed ABI due to modified layout of address space. * More complicated debugging due to: * Non-reproducible address space layout between runs. * Some debuggers automatically disable ASLR for spawned processes, making target's environment different between debug and non-debug runs. The known issues (such as PR239873 or PR253208) have been fixed in HEAD up front, however please pay attention to the system behavior after upgrading the kernel to the newest revisions. In order to confirm/rule-out the dependency of any encountered issue on ASLR it is strongly advised to re-run the test with the feature disabled - it can be done by setting the following sysctls in the /etc/sysctl.conf file: kern.elf64.aslr.enable=0 kern.elf64.aslr.pie_enable=0 The change is a result of combined efforts under the auspices of the FreeBSD Foundation and the Semihalf team sponsored by Stormshield. Best regards, Marcin From nobody Wed Nov 17 03:56:05 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 33CFA1889EB3 for ; Wed, 17 Nov 2021 03:56:25 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-oo1-f53.google.com (mail-oo1-f53.google.com [209.85.161.53]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Hv8HX3CwFz3nsp for ; Wed, 17 Nov 2021 03:56:24 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-oo1-f53.google.com with SMTP id p2-20020a4adfc2000000b002c2676904fdso534253ood.13 for ; Tue, 16 Nov 2021 19:56:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=rbDkCRXQFKBtUGPlh/brbcbt4GBn60Ozu2X9lI79W3M=; b=UxQLuUOVWL5ohP7E3mWzGT/Qns0gRCcZ9yENCMWLrKC7XqjWVCe7S/kFDBSX9h1+Mw khPlMySqMKCHM5PIelt45twOiiAxJi60dBvz9uP426hki0/kzxbPPG3ogjTAILDSyEV4 HCzSzvMFsKRXBDN8PRL0WXZnAhMgw/NxV6IBS8k5mbnkvIwwVgxgQjp1f8Nqpb6IbCy5 MMczCkn8I69gp96VVGR8LbYJlX8GoVMNBfeMt3HQzNhz6bxzmDefgpGw6O2C1FOTGjq+ E/2URrPk/1sRDFg/cUBaUAkiDOWOGOWspW5z+c3LRI8BDz6FK3G+ASAJ9aSZEolF+nNk k9QQ== X-Gm-Message-State: AOAM530+nmtDmydsXfaIO4OBR0Cq7LEqxjY76zl0bkn+kidyiikymSQr X6/alYUywisqUk6N9zPqWlcLQv3MX6OH2XW65qRu1a/u X-Google-Smtp-Source: ABdhPJxUPgoUgCXC05Xq3IfMjIGKOChtR92rUdnbGMLu+kcgvMhgIoBjrR0Z/RN4iOmfPAldj4l8JgPJCZ/GyguDLO8= X-Received: by 2002:a4a:6215:: with SMTP id x21mr6800157ooc.16.1637121376707; Tue, 16 Nov 2021 19:56:16 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 From: Alan Somers Date: Tue, 16 Nov 2021 20:56:05 -0700 Message-ID: Subject: FreeBSD 14.0-CURRENT snapshots in Google Compute Engine To: FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4Hv8HX3CwFz3nsp X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.161.53 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [1.00 / 15.00]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FREEFALL_USER(0.00)[asomers]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[209.85.161.53:from]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_DN_ALL(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[209.85.161.53:from]; NEURAL_SPAM_SHORT(1.00)[1.000]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TO_DOM_EQ_FROM_DOM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Google Compute Engine has images for 11.4-RELEASE, 12.2-RELEASE, and 13.0-RELEASE. Are there any images for current snapshots, and if so what are their names? -Alan From nobody Wed Nov 17 04:20:45 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 60F4C18975DD for ; Wed, 17 Nov 2021 04:20:58 +0000 (UTC) (envelope-from lwhsu@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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Hv8qt2MHFz4RL3; Wed, 17 Nov 2021 04:20:58 +0000 (UTC) (envelope-from lwhsu@freebsd.org) Received: from mail-ed1-f41.google.com (mail-ed1-f41.google.com [209.85.208.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) (Authenticated sender: lwhsu/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 2B16D7E1C; Wed, 17 Nov 2021 04:20:58 +0000 (UTC) (envelope-from lwhsu@freebsd.org) Received: by mail-ed1-f41.google.com with SMTP id w1so4784876edc.6; Tue, 16 Nov 2021 20:20:58 -0800 (PST) X-Gm-Message-State: AOAM532mFY3g8uPl4ovxi4q43XTdr3VCFpMJNmf6Y89YboLZ6Pr8WKuA rEWNe3HxnjKUK+AhZn6h7PD7/KEc/k0iP/VHzuI= X-Google-Smtp-Source: ABdhPJwRKJpWW8p6ivxLOWPjHttY/4iU2oM/Wypx/I8bOlnc3C4SQNgRmaJtol6r4ivdxtX1VKAVnPWCkQIrqUrGtYM= X-Received: by 2002:a05:6402:2079:: with SMTP id bd25mr17990505edb.116.1637122856817; Tue, 16 Nov 2021 20:20:56 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Li-Wen Hsu Date: Wed, 17 Nov 2021 12:20:45 +0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: FreeBSD 14.0-CURRENT snapshots in Google Compute Engine To: Alan Somers Cc: FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" X-ThisMailContainsUnwantedMimeParts: N On Wed, Nov 17, 2021 at 11:56 AM Alan Somers wrote: > > Google Compute Engine has images for 11.4-RELEASE, 12.2-RELEASE, and > 13.0-RELEASE. Are there any images for current snapshots, and if so > what are their names? > -Alan You can use this command to list all the images built by re: gcloud compute images list --no-standard-images --project=freebsd-org-cloud-dev gcloud is from net/google-cloud-sdk Li-Wen From nobody Wed Nov 17 05:41:22 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 887421897C8B for ; Wed, 17 Nov 2021 05:41:40 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-oo1-f45.google.com (mail-oo1-f45.google.com [209.85.161.45]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HvBd03StVz4rNR; Wed, 17 Nov 2021 05:41:40 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-oo1-f45.google.com with SMTP id v30-20020a4a315e000000b002c52d555875so631691oog.12; Tue, 16 Nov 2021 21:41:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MC7bDZ0nmbi6cSJpxkSsolL772CZRxXbGWHzZ14uSeo=; b=X0AQCOtEZjBtg+910CbLvixL35czNk4yOnucbI7ST6rbA/IbM2gas7udsXYV+OAL+g f4p8EgFJhP1dfrWRYYVcxr9yCUdkdsIigomdOoJIyFXEIp/DNLFUdzmkBWzbku197NAg +XthTxoz0sf3Kzyk3Llm73X2q2wyJ8Q1uAYT1fqxlddd4gJxPtoqaC8VdvPqqdDOQ2XD nrcQBp3yymJwNT+NrcGkFOOZNCcY4r1A7G3YCodJHhtRb4A2p2jbKfk1i6pkf+5S/NIB f/JAXivZfBcHMlYmm0J+1npgX84scQDJndSJQzF35hiqLsmcNFY30yBtKTT6nkrBoTu3 rfWg== X-Gm-Message-State: AOAM530PY/sOXNR5Sk8T4FNGybvjUa+UpwK5I1YgeSc/FYDJt0qaLJ1f 5HgAaP5GPv37+lFClu4v+ay1dSeQJrh/TgfE/94OuB4k X-Google-Smtp-Source: ABdhPJwnasmVJVYmBpDUFA4rKuubQ/TlIoB4RgYxYHMo/vaj8tchivTp8Jpb3vA/0rCbFQGdoWRdgHxzvWkuG/3KJw0= X-Received: by 2002:a4a:d0af:: with SMTP id t15mr7124301oor.12.1637127693389; Tue, 16 Nov 2021 21:41:33 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Alan Somers Date: Tue, 16 Nov 2021 22:41:22 -0700 Message-ID: Subject: Re: FreeBSD 14.0-CURRENT snapshots in Google Compute Engine To: Li-Wen Hsu Cc: FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4HvBd03StVz4rNR X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Thanks! That's just what I was looking for. On Tue, Nov 16, 2021 at 9:20 PM Li-Wen Hsu wrote: > > On Wed, Nov 17, 2021 at 11:56 AM Alan Somers wrote: > > > > Google Compute Engine has images for 11.4-RELEASE, 12.2-RELEASE, and > > 13.0-RELEASE. Are there any images for current snapshots, and if so > > what are their names? > > -Alan > > You can use this command to list all the images built by re: > > gcloud compute images list --no-standard-images > --project=freebsd-org-cloud-dev > > gcloud is from net/google-cloud-sdk > > Li-Wen From nobody Wed Nov 17 09:20:39 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 2EAD318A05E8 for ; Wed, 17 Nov 2021 09:20:45 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HvHTn0KfVz3HR3 for ; Wed, 17 Nov 2021 09:20:45 +0000 (UTC) (envelope-from hps@selasky.org) Received: from [10.36.2.165] (unknown [178.17.145.105]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id E0FE726020D; Wed, 17 Nov 2021 10:20:42 +0100 (CET) Message-ID: <093f0d18-c538-9b08-313f-70f9184ad072@selasky.org> Date: Wed, 17 Nov 2021 10:20:39 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: sound on FreeBSD 14.0-CURRENT Content-Language: en-US To: Ludovit Koren Cc: freebsd-current@freebsd.org References: <86h7cc5tgq.fsf@gmail.com> <8e946cd7-6380-87cc-9f9d-f624717a0954@selasky.org> <86czn05rcb.fsf@gmail.com> <6c443abb-2d0f-ab04-2d8f-16e74323f4af@selasky.org> <868rxo59ey.fsf@gmail.com> <0bc2da89-337b-c6ed-fd41-0e31f6fde1ae@selasky.org> <86zgq350ty.fsf@gmail.com> <17bb4c38-18d1-ac26-2bfe-d55ba3a23641@selasky.org> <86v90r4y7e.fsf@gmail.com> From: Hans Petter Selasky In-Reply-To: <86v90r4y7e.fsf@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4HvHTn0KfVz3HR3 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi, > > > Still the same result... > Please show all commands you try! Can you explain, which if these devices you want to receive audio from, and which you want to transmit audio to: pcm0: (play/rec) default pcm1: (play) pcm2: (play) It might also be the mixer has the volume or recording level set to zero. --HPS From nobody Wed Nov 17 10:03:15 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 6DFD21888395 for ; Wed, 17 Nov 2021 10:03:24 +0000 (UTC) (envelope-from ludovit.koren@gmail.com) Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HvJQz1kbtz3mdL for ; Wed, 17 Nov 2021 10:03:23 +0000 (UTC) (envelope-from ludovit.koren@gmail.com) Received: by mail-ed1-x52a.google.com with SMTP id r11so8456015edd.9 for ; Wed, 17 Nov 2021 02:03:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:references:user-mail-address:date:in-reply-to :message-id:user-agent:mime-version; bh=Sa8jvdCDLi3pG457+72LQ4kE/40Rq6ox+qrAjdLezCc=; b=E9ORbzCdPAesU5n6M4x5lsl3Y2MjYmIYeCxiOHPwYvIGLlXeeClygCRgtfL5YJalNz pzaYUQmpmyEFtL6mfeJPm6k+VExQmkB445W82b6AAINuJ/W8nCN3M12ESAioSc8qIoza DDul5BgTlnJuxdwPw4RxXPjcGbbQV63z8svxDKrq38sN3Nmo/QEqYR5fne0KdYYcuuWW 30/O1cP7l6/assNX1M8/cXG4k8c4A5bXfGR8SD3CfXa6BEtBXCKDk4EydP/i0yib4mwI RJwUQxzgJKabsi9t75oBgnL1JuQmlyzHKb/SeNse3hwu8pxWEa/eCFuhIiRYHmxiFY3r LvLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:references:user-mail-address :date:in-reply-to:message-id:user-agent:mime-version; bh=Sa8jvdCDLi3pG457+72LQ4kE/40Rq6ox+qrAjdLezCc=; b=l+SWE1Xk8H0ZHejRZWPcwomUzgHXDdJXyn2soUt6oiwQ0HHqKBIS9p2gObE2yOSBPp nxjOPVs9Qf/KaNLJfPyll+kcHtjiQ3wzFBTcHpYjtB/zI+VW4MMN0aM7z/VyAEs3MxSA pY6cIBM5rK0VZIOPzyYS5+C/s4OCJaRRXKfoipgpi6MUjSW+KUfBpIwZvWH4/cp56PUB 3QWIx75KqGhjniTKHRF91pJa2mF3M7sK6cLQlLetl6PnFNP+37uk8NQmZChidCCLM652 upJywVgkLuXtolgy0fKHDLEdhqnhbdMfi4lm2xIQaEwJB7LjmnU4EeZwPUhqQQT4r3lQ QevA== X-Gm-Message-State: AOAM532oZbQpub5pV72R7nLtafVFplEYOBhnCwFyOWhdafsrmJmpOoG0 MGqrbaW5ylLluDbCMjkkqTzzroRVVbQ= X-Google-Smtp-Source: ABdhPJydIOqQXcvQ9YtIUT1iUUK8lC4Fx1W2fwyG/9l27oX8zrFt89erp5rLVM3P8vMlb6tudgTCcA== X-Received: by 2002:a17:906:382:: with SMTP id b2mr20437175eja.13.1637143396040; Wed, 17 Nov 2021 02:03:16 -0800 (PST) Received: from jedi.localdomain (adsl-dyn-28.95-102-251.t-com.sk. [95.102.251.28]) by smtp.gmail.com with ESMTPSA id hw8sm9833819ejc.58.2021.11.17.02.03.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 17 Nov 2021 02:03:15 -0800 (PST) Received: by jedi.localdomain (Postfix, from userid 1001) id 1C9511A8C6F; Wed, 17 Nov 2021 11:03:15 +0100 (CET) From: Ludovit Koren To: Hans Petter Selasky Cc: freebsd-current@freebsd.org Subject: Re: sound on FreeBSD 14.0-CURRENT References: <86h7cc5tgq.fsf@gmail.com> <8e946cd7-6380-87cc-9f9d-f624717a0954@selasky.org> <86czn05rcb.fsf@gmail.com> <6c443abb-2d0f-ab04-2d8f-16e74323f4af@selasky.org> <868rxo59ey.fsf@gmail.com> <0bc2da89-337b-c6ed-fd41-0e31f6fde1ae@selasky.org> <86zgq350ty.fsf@gmail.com> <17bb4c38-18d1-ac26-2bfe-d55ba3a23641@selasky.org> <86v90r4y7e.fsf@gmail.com> <093f0d18-c538-9b08-313f-70f9184ad072@selasky.org> User-Mail-Address: ludovit.koren@gmail.com Date: Wed, 17 Nov 2021 11:03:15 +0100 In-Reply-To: <093f0d18-c538-9b08-313f-70f9184ad072@selasky.org> (Hans Petter Selasky's message of "Wed, 17 Nov 2021 10:20:39 +0100") Message-ID: <86r1bf3xr0.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (berkeley-unix) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain X-Rspamd-Queue-Id: 4HvJQz1kbtz3mdL X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=E9ORbzCd; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of ludovitkoren@gmail.com designates 2a00:1450:4864:20::52a as permitted sender) smtp.mailfrom=ludovitkoren@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-0.999]; RECEIVED_SPAMHAUS_PBL(0.00)[95.102.251.28:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52a:from]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N >>>>> Hans Petter Selasky writes: > Hi, >> Still the same result... >> > Please show all commands you try! > Can you explain, which if these devices you want to receive audio > from, and which you want to transmit audio to: > pcm0: (play/rec) default > pcm1: (play) > pcm2: (play) > It might also be the mixer has the volume or recording level set to zero. It is my new notebook... I want to use applications like mplayer, firefox, chrome. On my old notebook, I can listen from speakers, after plugging in the headphones, from them. I would like to have the same functionality. It does not work automatically on the new notebook. I suppose pcm1, is the output for the jack headphones. I just tried without virtual_oss, with virtual_oss, starting with -f /dev/dsp0; /dev/dsp1; /dev/dsp2; /dev/dsp1.0; /dev/dsp2.0; then using virtual_oss_cmd using different devices and using virtual_oss_cmd as you mentioned in the email. Still no success... (and next I would like to run bluetooth headphones....) lk From nobody Wed Nov 17 10:50:20 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 182DF1856245 for ; Wed, 17 Nov 2021 10:50:26 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HvKTF6J8Zz4WtL for ; Wed, 17 Nov 2021 10:50:25 +0000 (UTC) (envelope-from hps@selasky.org) Received: from [10.36.2.165] (unknown [178.17.145.105]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 38D97260245; Wed, 17 Nov 2021 11:50:24 +0100 (CET) Message-ID: Date: Wed, 17 Nov 2021 11:50:20 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: sound on FreeBSD 14.0-CURRENT Content-Language: en-US To: Ludovit Koren Cc: freebsd-current@freebsd.org References: <86h7cc5tgq.fsf@gmail.com> <8e946cd7-6380-87cc-9f9d-f624717a0954@selasky.org> <86czn05rcb.fsf@gmail.com> <6c443abb-2d0f-ab04-2d8f-16e74323f4af@selasky.org> <868rxo59ey.fsf@gmail.com> <0bc2da89-337b-c6ed-fd41-0e31f6fde1ae@selasky.org> <86zgq350ty.fsf@gmail.com> <17bb4c38-18d1-ac26-2bfe-d55ba3a23641@selasky.org> <86v90r4y7e.fsf@gmail.com> <093f0d18-c538-9b08-313f-70f9184ad072@selasky.org> <86r1bf3xr0.fsf@gmail.com> From: Hans Petter Selasky In-Reply-To: <86r1bf3xr0.fsf@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4HvKTF6J8Zz4WtL X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi Ludovit, > > It does not work automatically on the new notebook. I suppose pcm1, is > the output for the jack headphones. > > I just tried without virtual_oss, with virtual_oss, starting with -f > /dev/dsp0; /dev/dsp1; /dev/dsp2; /dev/dsp1.0; /dev/dsp2.0; then using > virtual_oss_cmd using different devices and using virtual_oss_cmd as you > mentioned in the email. > > Still no success... (and next I would like to run bluetooth headphones....) Again, please show all the commands you try and the output from them. Else I cannot help you figure this out! Your setup should be like this: mixer -f /dev/mixer0 -s vol 100 mixer -f /dev/mixer0 -s pcm 100 mixer -f /dev/mixer1 -s vol 100 mixer -f /dev/mixer1 -s pcm 100 killall virtual_oss virtual_oss \ -B -S -Q 1 -C 2 -c 2 \ -T /dev/sndstat \ -r 48000 \ -b 24 \ -s 8.0ms \ -R /dev/dsp0 \ -P /dev/dsp0 \ -c 2 \ -d dsp \ -t vdsp.ctl # if you play something now, do you have sound in your regular speakers? virtual_oss_cmd /dev/vdsp.ctl -P /dev/dsp1 # if you play something now, do you have sound in your headphone jack? If the answer is "no" to the last question and "yes" to the first question, there may be some quirks needed for the sound card: Please read through: man snd_hda First and then try to search the FreeBSD forums for similar issues. --HPS From nobody Wed Nov 17 12:20:37 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C1F09188BDB3 for ; Wed, 17 Nov 2021 12:21:02 +0000 (UTC) (envelope-from wulf@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HvMTp531Fz3JxR for ; Wed, 17 Nov 2021 12:21:02 +0000 (UTC) (envelope-from wulf@FreeBSD.org) Received: from [192.168.0.30] (unknown [94.45.211.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: wulf) by smtp.freebsd.org (Postfix) with ESMTPSA id 4AC73B890 for ; Wed, 17 Nov 2021 12:21:02 +0000 (UTC) (envelope-from wulf@FreeBSD.org) Message-ID: <7c36027d-0196-9ea8-b79e-4e3ef1440b9f@FreeBSD.org> Date: Wed, 17 Nov 2021 15:20:37 +0300 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: sound on FreeBSD 14.0-CURRENT Content-Language: en-US To: freebsd-current@freebsd.org References: <86h7cc5tgq.fsf@gmail.com> <8e946cd7-6380-87cc-9f9d-f624717a0954@selasky.org> <86czn05rcb.fsf@gmail.com> <6c443abb-2d0f-ab04-2d8f-16e74323f4af@selasky.org> <868rxo59ey.fsf@gmail.com> <0bc2da89-337b-c6ed-fd41-0e31f6fde1ae@selasky.org> <86zgq350ty.fsf@gmail.com> <17bb4c38-18d1-ac26-2bfe-d55ba3a23641@selasky.org> <86v90r4y7e.fsf@gmail.com> <093f0d18-c538-9b08-313f-70f9184ad072@selasky.org> <86r1bf3xr0.fsf@gmail.com> From: Vladimir Kondratyev In-Reply-To: <86r1bf3xr0.fsf@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ThisMailContainsUnwantedMimeParts: N On 17.11.2021 13:03, Ludovit Koren wrote: >>>>>> Hans Petter Selasky writes: > > > Hi, > >> Still the same result... > >> > > > Please show all commands you try! > > > Can you explain, which if these devices you want to receive audio > > from, and which you want to transmit audio to: > > > pcm0: (play/rec) default > > pcm1: (play) > > pcm2: (play) > > > > It might also be the mixer has the volume or recording level set to zero. > > It is my new notebook... I want to use applications like mplayer, > firefox, chrome. On my old notebook, I can listen from speakers, after > plugging in the headphones, from them. I would like to have the same > functionality. > > It does not work automatically on the new notebook. I suppose pcm1, is > the output for the jack headphones. You don't need virtual_oss to do that. Just configure pins on your soundchip properly. See EXAMPLES section of man snd_hda. -- WBR Vladimir Kondratyev From nobody Wed Nov 17 12:36:12 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B4859189317B for ; Wed, 17 Nov 2021 12:36:21 +0000 (UTC) (envelope-from ludovit.koren@gmail.com) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HvMqS6PL7z3QJj for ; Wed, 17 Nov 2021 12:36:20 +0000 (UTC) (envelope-from ludovit.koren@gmail.com) Received: by mail-wm1-x334.google.com with SMTP id y196so2051076wmc.3 for ; Wed, 17 Nov 2021 04:36:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:references:user-mail-address:date:in-reply-to :message-id:user-agent:mime-version; bh=n9AeQ4Dj/SVtszeqC+zwRrn7yDFpookzXsJyJ0KnJuM=; b=BsugVo7/72vzfkDR/R65z2P5UtvDeg3anlTcapqAwOj/MI6fnq9UG1M7U6XjNkWIuT pUQy5T6hRidIPfO3JmoorDc7XZCsoNzym/Y4tIt8Eg8dT8eR3+Agqmj9CLIbczuCk94L 4Q/M9N1oiexDbvHYJktUbYj067rqrP5yKU5Kzqgg4nXfJDyTa1DuVGSwAZ4Ej8UPonlR AHjeSd86hxtLMsBL1e72ivuZGcMLKqEY/ueg6A3NhBAig09fjiKwS7SPECoU3FFxeyVU cJRmGrlNySnNBLthHjTxk+Jr/JKFwTtIOTtJDgjDEQU6SwYi0S/EHKDx9JolhdPZIHxa JCLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:references:user-mail-address :date:in-reply-to:message-id:user-agent:mime-version; bh=n9AeQ4Dj/SVtszeqC+zwRrn7yDFpookzXsJyJ0KnJuM=; b=b5/6rgTh60jqtrKMjj0bQvddcgzSCpnfgzuD+bHnmEHglz4gvF9gMkoqSNDY06o47p pAumyXdS4XHC8nQ7AfOdUpD2qOc3lkeM9owR+RGavQqbobZEOdsvhaeuH3gIXwfrKv7k f6XLJUlwi1VMQdFK1S3bEs7WuQCv1Bpj9heV1gCLtTX9/wnfC0SJFPkoj1qq2XcwEaR5 0VUGInwyCZz61MRLaJZMe9GuGEh5FoXnl90/vHM2Hv2yYrbdwAmrQkOv13Jl9HoPvd8A FSIoe9zYlNQVS6mkhvFcE0TWC5MrQAOootPT6ys972CZHr9t/S0aM3eZybAqc/PrtTZe yboA== X-Gm-Message-State: AOAM532i/lTwmjSn1tVqnf0dUqfAchIEBHD0IPgq+fEkp1oidn1uKJxC 34QGoJi5zlK3lvyfHOYANXQ7GMNZsGg= X-Google-Smtp-Source: ABdhPJxfBa0vaEyAG5MuXZIV4Ar/r7BDsH3ujQBST4Vira4I2h6bbhglKhXrVYa9a9av72H+j5efuQ== X-Received: by 2002:a7b:c04b:: with SMTP id u11mr78677991wmc.127.1637152574027; Wed, 17 Nov 2021 04:36:14 -0800 (PST) Received: from jedi.localdomain (adsl-dyn-28.95-102-251.t-com.sk. [95.102.251.28]) by smtp.gmail.com with ESMTPSA id h15sm6422520wmq.32.2021.11.17.04.36.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 17 Nov 2021 04:36:13 -0800 (PST) Received: by jedi.localdomain (Postfix, from userid 1001) id E583C1A8C75; Wed, 17 Nov 2021 13:36:12 +0100 (CET) From: Ludovit Koren To: Hans Petter Selasky Cc: freebsd-current@freebsd.org Subject: Re: sound on FreeBSD 14.0-CURRENT References: <86h7cc5tgq.fsf@gmail.com> <8e946cd7-6380-87cc-9f9d-f624717a0954@selasky.org> <86czn05rcb.fsf@gmail.com> <6c443abb-2d0f-ab04-2d8f-16e74323f4af@selasky.org> <868rxo59ey.fsf@gmail.com> <0bc2da89-337b-c6ed-fd41-0e31f6fde1ae@selasky.org> <86zgq350ty.fsf@gmail.com> <17bb4c38-18d1-ac26-2bfe-d55ba3a23641@selasky.org> <86v90r4y7e.fsf@gmail.com> <093f0d18-c538-9b08-313f-70f9184ad072@selasky.org> <86r1bf3xr0.fsf@gmail.com> User-Mail-Address: ludovit.koren@gmail.com Date: Wed, 17 Nov 2021 13:36:12 +0100 In-Reply-To: (Hans Petter Selasky's message of "Wed, 17 Nov 2021 11:50:20 +0100") Message-ID: <86mtm33qo3.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (berkeley-unix) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain X-Rspamd-Queue-Id: 4HvMqS6PL7z3QJj X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b="BsugVo7/"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of ludovitkoren@gmail.com designates 2a00:1450:4864:20::334 as permitted sender) smtp.mailfrom=ludovitkoren@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RECEIVED_SPAMHAUS_PBL(0.00)[95.102.251.28:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::334:from]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N >>>>> Hans Petter Selasky writes: > Hi Ludovit, >> It does not work automatically on the new notebook. I suppose pcm1, >> is >> the output for the jack headphones. >> I just tried without virtual_oss, with virtual_oss, starting with -f >> /dev/dsp0; /dev/dsp1; /dev/dsp2; /dev/dsp1.0; /dev/dsp2.0; then using >> virtual_oss_cmd using different devices and using virtual_oss_cmd as you >> mentioned in the email. >> Still no success... (and next I would like to run bluetooth >> headphones....) > Again, please show all the commands you try and the output from > them. Else I cannot help you figure this out! > Your setup should be like this: > mixer -f /dev/mixer0 -s vol 100 > mixer -f /dev/mixer0 -s pcm 100 >mixer -f /dev/mixer0 -s vol 100 pcm0:mixer: mic >mixer -f /dev/mixer0 -s pcm 100 pcm0:mixer: mic > mixer -f /dev/mixer1 -s vol 100 > mixer -f /dev/mixer1 -s pcm 100 >mixer -f /dev/mixer1 -s vol 100 >mixer -f /dev/mixer1 -s pcm 100 (no output) > killall virtual_oss > virtual_oss \ > -B -S -Q 1 -C 2 -c 2 \ > -T /dev/sndstat \ > -r 48000 \ > -b 24 \ > -s 8.0ms \ > -R /dev/dsp0 \ > -P /dev/dsp0 \ > -c 2 \ > -d dsp \ > -t vdsp.ctl > # if you play something now, do you have sound in your regular speakers? firefox, chrome both play via speakers > virtual_oss_cmd /dev/vdsp.ctl -P /dev/dsp1 > # if you play something now, do you have sound in your headphone jack? firefox plays via speakers chrome plays via headphones (heureka) Difference is pulseaudio in default settings...?! (and jack) > If the answer is "no" to the last question and "yes" to the first > question, there may be some quirks needed for the sound card: > Please read through: > man snd_hda I wil read and try some setup... > First and then try to search the FreeBSD forums for similar issues. Thank you. lk From nobody Wed Nov 17 12:35:58 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0466B1893624 for ; Wed, 17 Nov 2021 12:36:33 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: from out.alvermark.net (out.alvermark.net [185.34.136.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HvMqh6R9wz3QMn for ; Wed, 17 Nov 2021 12:36:32 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: from c-d24b235c.06-431-73746f70.bbcust.telenor.se ([92.35.75.210] helo=mail.alvermark.net) by out.alvermark.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91 (FreeBSD)) (envelope-from ) id 1mnKAq-000BG0-HX; Wed, 17 Nov 2021 13:36:24 +0100 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alvermark.net; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: From:References:Cc:To:Subject:MIME-Version:Date:Message-ID: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=iAI8VP/KFh5xtD7MJrO724MNwxXyMY0NLsF6xEP6l90=; b=xh8251H15AehQ8q3sCHXO3HAkN upT1sJdX4BCud+m9nOqH6ERw/iRynb1C99apbXC20vcs3fAAPuZ2k4ZnQDehNpqcRkd4iZSWfuNB7 PwKT75L+6tH7lg5sfjoygIX6Qg3JQXe0KXeOq8yWzLNSdFKZrhQN0jVSKmwy/ah7e32FNk0kEnEJ2 q3uLFB5fvAZSNu7vBgHhfryRFqkd7ZsgNdfg7j03eWkVXIjNNvmCWgUPN5nlwe5KVY3WKiloLRq1R 6Z1GOw1RxyzHAqeuHctNrASBT9+rLeigoTmQXq27VdZiYS5K1J8ru9Qe/btB350F+FoneuN/5kBnn +gMku3qA==; Received: from office.as33885.net ([84.55.65.101] helo=[192.168.1.125]) by mail.alvermark.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91 (FreeBSD)) (envelope-from ) id 1mnKAR-000JU2-24; Wed, 17 Nov 2021 13:35:59 +0100 Message-ID: <903aff29-7e94-471c-d38c-79e2b1f28619@alvermark.net> Date: Wed, 17 Nov 2021 13:35:58 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: sound on FreeBSD 14.0-CURRENT Content-Language: en-US To: Ludovit Koren , Hans Petter Selasky Cc: freebsd-current@freebsd.org References: <86h7cc5tgq.fsf@gmail.com> <8e946cd7-6380-87cc-9f9d-f624717a0954@selasky.org> <86czn05rcb.fsf@gmail.com> <6c443abb-2d0f-ab04-2d8f-16e74323f4af@selasky.org> <868rxo59ey.fsf@gmail.com> <0bc2da89-337b-c6ed-fd41-0e31f6fde1ae@selasky.org> <86zgq350ty.fsf@gmail.com> <17bb4c38-18d1-ac26-2bfe-d55ba3a23641@selasky.org> <86v90r4y7e.fsf@gmail.com> <093f0d18-c538-9b08-313f-70f9184ad072@selasky.org> <86r1bf3xr0.fsf@gmail.com> From: Jakob Alvermark In-Reply-To: <86r1bf3xr0.fsf@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4HvMqh6R9wz3QMn X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On 11/17/21 11:03, Ludovit Koren wrote: >>>>>> Hans Petter Selasky writes: > > Hi, > >> Still the same result... > >> > > > Please show all commands you try! > > > Can you explain, which if these devices you want to receive audio > > from, and which you want to transmit audio to: > > > pcm0: (play/rec) default > > pcm1: (play) > > pcm2: (play) > > > > It might also be the mixer has the volume or recording level set to zero. > > It is my new notebook... I want to use applications like mplayer, > firefox, chrome. On my old notebook, I can listen from speakers, after > plugging in the headphones, from them. I would like to have the same > functionality. > > It does not work automatically on the new notebook. I suppose pcm1, is > the output for the jack headphones. > > I just tried without virtual_oss, with virtual_oss, starting with -f > /dev/dsp0; /dev/dsp1; /dev/dsp2; /dev/dsp1.0; /dev/dsp2.0; then using > virtual_oss_cmd using different devices and using virtual_oss_cmd as you > mentioned in the email. > > Still no success... (and next I would like to run bluetooth headphones....) > > lk > Hi, can you send the output of 'sysctl dev.hdaa'? Jakob From nobody Wed Nov 17 12:39:41 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id CDD661894E9E for ; Wed, 17 Nov 2021 12:39:47 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HvMvR3nGGz3hm8 for ; Wed, 17 Nov 2021 12:39:47 +0000 (UTC) (envelope-from hps@selasky.org) Received: from [10.36.2.165] (unknown [178.17.145.105]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 50B3D26034E; Wed, 17 Nov 2021 13:39:45 +0100 (CET) Message-ID: Date: Wed, 17 Nov 2021 13:39:41 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: sound on FreeBSD 14.0-CURRENT Content-Language: en-US To: Ludovit Koren Cc: freebsd-current@freebsd.org References: <86h7cc5tgq.fsf@gmail.com> <8e946cd7-6380-87cc-9f9d-f624717a0954@selasky.org> <86czn05rcb.fsf@gmail.com> <6c443abb-2d0f-ab04-2d8f-16e74323f4af@selasky.org> <868rxo59ey.fsf@gmail.com> <0bc2da89-337b-c6ed-fd41-0e31f6fde1ae@selasky.org> <86zgq350ty.fsf@gmail.com> <17bb4c38-18d1-ac26-2bfe-d55ba3a23641@selasky.org> <86v90r4y7e.fsf@gmail.com> <093f0d18-c538-9b08-313f-70f9184ad072@selasky.org> <86r1bf3xr0.fsf@gmail.com> <86mtm33qo3.fsf@gmail.com> From: Hans Petter Selasky In-Reply-To: <86mtm33qo3.fsf@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4HvMvR3nGGz3hm8 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On 11/17/21 13:36, Ludovit Koren wrote: > firefox plays via speakers In firefox go to "about:config", then add this string: media.cubeb.backend oss Then restart firefox. --HPS From nobody Wed Nov 17 16:06:37 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 354051892591 for ; Wed, 17 Nov 2021 16:06:41 +0000 (UTC) (envelope-from ludovit.koren@gmail.com) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HvSV81YQ1z3ql6 for ; Wed, 17 Nov 2021 16:06:40 +0000 (UTC) (envelope-from ludovit.koren@gmail.com) Received: by mail-wr1-x42d.google.com with SMTP id d5so5723684wrc.1 for ; Wed, 17 Nov 2021 08:06:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:references:user-mail-address:date:in-reply-to :message-id:user-agent:mime-version; bh=UXWLuaGhdVEmjXiuaKOoyvVHaqSj16ne3k2/B7qEzKI=; b=W8xuw45SzqgGOvR3mz3382A2Dj1BLFjhig+kMA78y7xASeCmuvCIirgimc5owOoLD4 7aJnymZW6RWzttRMfO9Xp1s919eS74iXBhrgjkXp2t7lxSqUHIGEMRBp1IsZpClDmqcg iR5uD5mBp5ZU+QpcWSdeOfAKDhtJ4uiMih4Gv1AxlAMg+xXgPdediM39OtOW5gNOUkPt sugUve3365pttze2FvZ9g7ZvVeIrH1p+d74KZh7eIGPydOoBtrRfZNUI/SpnT4jucspx YTvuS4S7xuzRge0Q8aiv2D6Znt9RZsouO/ZqkSa2LqelXZ8CMIVqZtxmqegMY6joFj6C Q2Fg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:references:user-mail-address :date:in-reply-to:message-id:user-agent:mime-version; bh=UXWLuaGhdVEmjXiuaKOoyvVHaqSj16ne3k2/B7qEzKI=; b=4f4i5Z4EmADH3osw1l6KDduJ1fJfJd6bxbBLJKM5f8JtTc88kQe+uHc19UqcDvwa/j cMdhH+kq+Ba8lMTA9RTUQMKsyhUeTnO9QkAf01xQdOnqZrHW47sJ0eqrJLsMu/XBggqj KsmJCvu0Rpos3e4+G+QuGe9K/lrbQ1kZwWwzkK4XCo0ZpposedpHjt+psYXQj9c2CDfN AK7PwItPb2FCeizl2KKBtSaLfOqvjmFbsOLJxjltfa9mON57A0W0LNt0nU853jFea2Hu XI6WgBDsH/G9mx2c0JP9trjYFfEuSGPnVL+XDm96M7RtMGQBm6n7Uct3whyTVPjzIBLH QDKw== X-Gm-Message-State: AOAM533Vx+OOaNJylQqzdfMBaoiSw5Ems7fJ6U5vvI176HbTbBNosz8v OBXaNenJZvFR9hFqJlvZEqs= X-Google-Smtp-Source: ABdhPJxzTNr8P7oDLzDyFhvwuTOVTq2PnqxeAgZOwJGwFsOZ/99Q3f5o6Rpfs2JTI5vR19UwhsGHNw== X-Received: by 2002:adf:edce:: with SMTP id v14mr21287368wro.291.1637165199257; Wed, 17 Nov 2021 08:06:39 -0800 (PST) Received: from jedi.localdomain (adsl-dyn-28.95-102-251.t-com.sk. [95.102.251.28]) by smtp.gmail.com with ESMTPSA id p12sm289478wro.33.2021.11.17.08.06.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 17 Nov 2021 08:06:38 -0800 (PST) Received: by jedi.localdomain (Postfix, from userid 1001) id 55E851A8E60; Wed, 17 Nov 2021 17:06:37 +0100 (CET) From: Ludovit Koren To: Jakob Alvermark Cc: Hans Petter Selasky , freebsd-current@freebsd.org Subject: Re: sound on FreeBSD 14.0-CURRENT References: <86h7cc5tgq.fsf@gmail.com> <8e946cd7-6380-87cc-9f9d-f624717a0954@selasky.org> <86czn05rcb.fsf@gmail.com> <6c443abb-2d0f-ab04-2d8f-16e74323f4af@selasky.org> <868rxo59ey.fsf@gmail.com> <0bc2da89-337b-c6ed-fd41-0e31f6fde1ae@selasky.org> <86zgq350ty.fsf@gmail.com> <17bb4c38-18d1-ac26-2bfe-d55ba3a23641@selasky.org> <86v90r4y7e.fsf@gmail.com> <093f0d18-c538-9b08-313f-70f9184ad072@selasky.org> <86r1bf3xr0.fsf@gmail.com> <903aff29-7e94-471c-d38c-79e2b1f28619@alvermark.net> User-Mail-Address: ludovit.koren@gmail.com Date: Wed, 17 Nov 2021 17:06:37 +0100 In-Reply-To: <903aff29-7e94-471c-d38c-79e2b1f28619@alvermark.net> (Jakob Alvermark's message of "Wed, 17 Nov 2021 13:35:58 +0100") Message-ID: <86ilwq4vhu.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (berkeley-unix) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Rspamd-Queue-Id: 4HvSV81YQ1z3ql6 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=W8xuw45S; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of ludovitkoren@gmail.com designates 2a00:1450:4864:20::42d as permitted sender) smtp.mailfrom=ludovitkoren@gmail.com X-Spamd-Result: default: False [-3.95 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; HAS_ATTACHMENT(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.95)[-0.951]; RECEIVED_SPAMHAUS_PBL(0.00)[95.102.251.28:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::42d:from]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: Y --=-=-= Content-Type: text/plain >>>>> Jakob Alvermark writes: > On 11/17/21 11:03, Ludovit Koren wrote: >>>>>>> Hans Petter Selasky writes: >> > Hi, >> >> Still the same result... >> >> >> >> > Please show all commands you try! >> >> > Can you explain, which if these devices you want to receive audio >> > from, and which you want to transmit audio to: >> >> > pcm0: (play/rec) default >> > pcm1: (play) >> > pcm2: (play) >> >> >> > It might also be the mixer has the volume or recording level set to zero. >> >> It is my new notebook... I want to use applications like mplayer, >> firefox, chrome. On my old notebook, I can listen from speakers, after >> plugging in the headphones, from them. I would like to have the same >> functionality. >> >> It does not work automatically on the new notebook. I suppose pcm1, is >> the output for the jack headphones. >> >> I just tried without virtual_oss, with virtual_oss, starting with -f >> /dev/dsp0; /dev/dsp1; /dev/dsp2; /dev/dsp1.0; /dev/dsp2.0; then using >> virtual_oss_cmd using different devices and using virtual_oss_cmd as you >> mentioned in the email. >> >> Still no success... (and next I would like to run bluetooth headphones....) >> >> lk >> > Hi, can you send the output of 'sysctl dev.hdaa'? please, see the attached file. lk --=-=-=-- From nobody Wed Nov 17 16:22:09 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id BE3F91899C22 for ; Wed, 17 Nov 2021 16:22:18 +0000 (UTC) (envelope-from ludovit.koren@gmail.com) Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HvSr95ywYz4Qsr for ; Wed, 17 Nov 2021 16:22:17 +0000 (UTC) (envelope-from ludovit.koren@gmail.com) Received: by mail-wm1-x32d.google.com with SMTP id g191-20020a1c9dc8000000b0032fbf912885so2553298wme.4 for ; Wed, 17 Nov 2021 08:22:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:references:user-mail-address:date:in-reply-to :message-id:user-agent:mime-version; bh=/OzbR/9/9bzi47+Lh8aDiA0ns9mhrm4tzuLW1YOcVek=; b=qRwM+Tmxy6rt4DWNO0j6zwm1tW6uuON4S0yIRsl0BcTwBL843IYjgrSpXjJLlRIyzA wdFXFKgESTDvW7MpojEH5MBDesY/F21QQQx5UX5ABkfSlgZ1BAirYkqVS9zw3SHWT+cS dkh0dFXc5ucxRO9w9LnRIxU4B3ozYKVkR16qlXveST3u67bxVOKtQ/EhVEJhr1syIxz3 xdn96tipafxAufTnGC4967AIBJmXNrHrWuCTtOfIh6SMU9Qx1GOvSHQkKrh9pHca/u05 L7nru0IH0obyHFs8a257DIQlpaQQCn/PCNDrl9ru3s9iSo0t6bhy974iC3hKtTlDna7G DWZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:references:user-mail-address :date:in-reply-to:message-id:user-agent:mime-version; bh=/OzbR/9/9bzi47+Lh8aDiA0ns9mhrm4tzuLW1YOcVek=; b=69zqYMMG/fj0m1agDC4TaKjmeEbZGdwjEAuYe2XW6bwtIm9kUTSU14QaDNdR9595eO mc06ydTZ4QGhKzirha6+ahk0qDLwNDDBruYnj8bBf6vJ/f7JosBILCQ9aviLZD+XZcfL ZvDri0X9BNoQeEsBrkKpDwDE/Fs3kd/9h814ecCgpTGUAUD7fwstdM+E/0bw6HW7eN5q z0KlX6CAwV7VTV1s5llO/4AqUI8Yg0qtyaT5zJjmHta39+/Q2svKf9rTEQUah6K20wHS Z+MPfEnCzL5qPH/6BwI0Ld+5iIZq+6VMW00n3PpZzOtJJAoNYM5agHFardyVxN9JkmMK roJA== X-Gm-Message-State: AOAM5309Ligl2HetXTx97IDkaMEQY4I2mA/cN1a74Q5+UHeyo56MnTym dlIBnXgmciOu6eQXdPr3xZmXtEAIkHM= X-Google-Smtp-Source: ABdhPJxbzQU1Kp2PHUyMLYAtWENkXsHn9v8F3B9S7CUhb12auqXnxKbo3Sg5+b9gb73Lgot4dupnNg== X-Received: by 2002:a05:600c:2947:: with SMTP id n7mr1041894wmd.15.1637166130873; Wed, 17 Nov 2021 08:22:10 -0800 (PST) Received: from jedi.localdomain (adsl-dyn-28.95-102-251.t-com.sk. [95.102.251.28]) by smtp.gmail.com with ESMTPSA id d7sm287523wrw.87.2021.11.17.08.22.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 17 Nov 2021 08:22:10 -0800 (PST) Received: by jedi.localdomain (Postfix, from userid 1001) id 5E9861A8E4E; Wed, 17 Nov 2021 17:22:09 +0100 (CET) From: Ludovit Koren To: Hans Petter Selasky Cc: freebsd-current@freebsd.org Subject: Re: sound on FreeBSD 14.0-CURRENT References: <86h7cc5tgq.fsf@gmail.com> <8e946cd7-6380-87cc-9f9d-f624717a0954@selasky.org> <86czn05rcb.fsf@gmail.com> <6c443abb-2d0f-ab04-2d8f-16e74323f4af@selasky.org> <868rxo59ey.fsf@gmail.com> <0bc2da89-337b-c6ed-fd41-0e31f6fde1ae@selasky.org> <86zgq350ty.fsf@gmail.com> <17bb4c38-18d1-ac26-2bfe-d55ba3a23641@selasky.org> <86v90r4y7e.fsf@gmail.com> <093f0d18-c538-9b08-313f-70f9184ad072@selasky.org> <86r1bf3xr0.fsf@gmail.com> <86mtm33qo3.fsf@gmail.com> User-Mail-Address: ludovit.koren@gmail.com Date: Wed, 17 Nov 2021 17:22:09 +0100 In-Reply-To: (Hans Petter Selasky's message of "Wed, 17 Nov 2021 13:39:41 +0100") Message-ID: <86ee7e4ury.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (berkeley-unix) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain X-Rspamd-Queue-Id: 4HvSr95ywYz4Qsr X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=qRwM+Tmx; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of ludovitkoren@gmail.com designates 2a00:1450:4864:20::32d as permitted sender) smtp.mailfrom=ludovitkoren@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RECEIVED_SPAMHAUS_PBL(0.00)[95.102.251.28:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::32d:from]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N >>>>> Hans Petter Selasky writes: > On 11/17/21 13:36, Ludovit Koren wrote: >> firefox plays via speakers > In firefox go to "about:config", then add this string: > media.cubeb.backend oss > Then restart firefox. yes, it plays via headphones thanks, lk From nobody Wed Nov 17 16:33:35 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 8B16F18509F9 for ; Wed, 17 Nov 2021 16:33:58 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f49.google.com (mail-io1-f49.google.com [209.85.166.49]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HvT5f3XV2z4VwM; Wed, 17 Nov 2021 16:33:58 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io1-f49.google.com with SMTP id w22so4015507ioa.1; Wed, 17 Nov 2021 08:33:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PKB3mFHr/lUYA6XXHBewa260sprXCqx6VNLdPhfsk2E=; b=5qoEZIPHZroWsmQjs5+zdWbxy1H8WF8UWaHh8kSjTWRYP7C2/dTWI3fngetcV0cX3t 15Zkfxfl9Y+gMprjQEG7xpOllZWXWmUF4RxqJzPHFG4Y+GA3/jHm6ZkAVTAhKO1a+88c YNpKDtVuDYMUdTqM+48JYR4mImxRykNY9lEI5E+vc8TCpUwfyuS8Fpz44GXqgpthauTM JqUM+k+myl0g2koWSFZMSdajpx70RLN1TQKRvMQdbk/BljMJ8ZXRxqWHixMbDWZ+ER6F qMWYAj/m9HK+dBvMHJDVNr0cTeMx9X2f4nqOxDuotMrCo1A6o10PCmCOhKnyeW/DAJv6 VK6A== X-Gm-Message-State: AOAM533Az7JT/+PgWkFol//8CuMv1nkTIURyInuifCVIGq7t4arlEOur EQajHGXfobmyoUlPubKCHeD5TI5l2TMr89UIWPHb1rie X-Google-Smtp-Source: ABdhPJyObaSudVWQEpj2IHf0z2KRyfQ2FA8ebbAg/6BBKryC83T4526Y/GF4ntbq2wPT7NbRRn3opmqm2ZCyapfvy4Q= X-Received: by 2002:a05:6602:2d81:: with SMTP id k1mr12538398iow.112.1637166831525; Wed, 17 Nov 2021 08:33:51 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Ed Maste Date: Wed, 17 Nov 2021 11:33:35 -0500 Message-ID: Subject: Re: FreeBSD 14.0-CURRENT snapshots in Google Compute Engine To: Li-Wen Hsu Cc: Alan Somers , FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4HvT5f3XV2z4VwM X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Tue, 16 Nov 2021 at 23:22, Li-Wen Hsu wrote: > > You can use this command to list all the images built by re: > > gcloud compute images list --no-standard-images > --project=freebsd-org-cloud-dev Aside, it looks like we have many EOL images that are not marked as deprecated in the gcloud list (11.x and old 12.x images). From nobody Wed Nov 17 19:17:27 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 62564188B595 for ; Wed, 17 Nov 2021 19:17:39 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-24.consmr.mail.gq1.yahoo.com (sonic311-24.consmr.mail.gq1.yahoo.com [98.137.65.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HvXkV2C6Rz4RM2 for ; Wed, 17 Nov 2021 19:17:38 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637176651; bh=dDfbYH4xavsLHtllidO2NoN+PYuhji5v958VppA2i5Y=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=cxt1dJrcTe6LitCgMM1KvENW0FgE8H7SLJjUHkz63pXwK9NafxiVC0adypj23wh7EyCJGBI/guEeRApV+Ril98nAZ35pipTW1mkaKoQeZL8lkSyMPPh/JN9vgwHPrtEMZ7DLxwESHEJa2N0kT7Ib2iDoPieSWm1EFlRv4MUOojIfx+NxsLC5R6rDyX8zCl251GCbjousgTlelaYYEPZXSkA4frWGr5/eEc69Mh7DvenaQZTDNdtj5rJBH7YOWLh6oKqxHCeRhWIjVWBrSPHLEyeB8nY3hQ+iRUod3L8PdCsa14aB1GeQQAn484FSpWAADRcWpJYt2Fp3mvu08CUM2g== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637176651; bh=X9/4FTtrNoOph1HdFKGO+XMeT4PD3urrSr4exYPkRtf=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=SReXMGkG+hmF7/iJo337KTsay3D2p91cWRNNN3nra/LXd4r8DDWUjqPDU0NK6p2JzmTZkChPcPkA6QNZ4SC1npF9E18n+PhOr4foN80+cznqyuMYQZ6IkXAq6jcoluKNQUFFKiwEeI6KarkpM/NqOdrBTfUD7V2eheLPcbY/vHlNlhzNA64doldjFGq4P+vru4XFfA/O71TUUkaSBBgGlAF9QqWEp3gwXw6zSRr7veHfHGDg9pzjpm8SuMJsZ7TCNznK8A6JGKLCrNCukZLIl1QSxJRnpZvt79cVeYspVM2PYB8k0wOnK01vQg46PEL8oVQrKDBpl/zcIOXL5oUaWg== X-YMail-OSG: oJPqCE8VM1k3U8YNDXMkc0tyUNjp0HqxiPP05x_2sU41sFzQgJrcQLenP_Tps3k coksqHFXCdd46sR36y3CVTU9kzBRoFA2ud4KR.PEXvpM0RIMXs_2d_5g6f9CPvoDF2HwIfwr3fol blNW4hHYW6iRZQC56YsNyexIJ1fe.I6RN.TNcU8pIp530rzV8CRMWlz5WDCxJPjKOMaxuc0o92iu lb.d8CMj1auG1icxM72UugWTtG9zzyHE3cS__EaVkDNX627HkWpEMec4RVAj1I4tj4IQZCrgM.t1 gNJEQq6.Ntes0w_d5hx8n53MugnPQQ.QoXHHwF_PEcOPSCcOkk8eChQvqMbRBPouXhl_xufqzmbG X.s5CPO8v53KF09i6BmdqvcQUXW1mOdUf7lAkfxsonlKCzLNv8IZTFh59VJyGisLCMzkyeY96qZR pRMw_qKE_WkjV10Bhb8gRZhodLmDejxS4gqbxr0fzcAgivjaw_5X04rwjGaqh8948pGV732Avj9p tSpdY7mX4MmxTugO2EFY1t6uUr56Cff2.mA.xkmQx1ceDE83Z_ob6ZMf5IC26XhlCVJEAbtDU0AF P7rtRmQ9jshVBeSNZT_jPE6Efd5UcjdiRceKeXfDB4z6HZO1BFnv_x2ADDFjtM4dyASCK20NjYej 6Co9MYk1DwbhdIfXLClyMuZ0AzwkoSwL9zWDBN1LaCreicLm8MzGRmxme1vCLEP.JtEqdd4ALIcG BoYh4528OWWPvhANW4hElKor5NzG9vjesR4jFx5fg9_BgpIjdLdGRPp7xv6Rgedw4nSOIJrpCDIK IO5lMp6uESVMYqS4yuytEdaK16C4M.SlLIi2p2KMixqhxlAAdeteNeyncPhalIGOW9KHJMS97DuH 34Spz42HwXcOojjkiRwuIssn8rgNl4LAlHy1vAwPf8i99_JBZFcYRZDmIR4YCCu4wXNXp7d.gWWU 3WEru.fCWjAMoMzBWTpgT6GTjal0KSc4bTDYz9uQ3fSnMzjKDU5hP5QrxSA61ZD3hCVR1dhWuXzP UUWtaZvk5rSYjn_CtSmVpLpsdsKD8hvuiBhtjfWrXBH_mEX2wDXnrJKy0qEiU7XGZFjboTL8TzpN GLL5tuNjKYh2gLi.L9_pizGbXS.8d0wMBLtuxqYFG_CEZ8fdx3WKYPWRRWRQZg6e40Iv96NPnOEI ZCHwS8exTK1zPI6LolDNcpomIVeaWUE3tkuefOC8FECvYWgKYOyqONaNjCQATkART4VmWCW06mmo QI5IZbLDorecaM1Tz8ullLwgubHK8Ek9cG8tIoxE7JK7Uvk4M1ZL8svHuMvPdmJmGoLyXsgh.kLj csgaHwgEQxs6N6PR2ImIEW87eLd40aph5xDqvWMJcbWk2wgynUeyUhYuNmrKvh76VotqZv2NYqpk JGDqWto7iBtQugCjdonG1gwjqoWzJev2VSc1WTplZ91G5brIBki6KR8KJnTjRAS_kmAHLXdfqgIh 8lx498rIyUjsB4XxuZywzIHXXg7mtJBN0du9VOunEZMQM6R.IcomKg2mahhAJmnZfC4guUqABC6q Z7wTMiR0TfPOUeGlJxryUYpyAmaAsdTQE4VcEbGOc2SO.OT.8vdH.RgahdX63Pe1m1oE4I3_F7BJ LqHpRCudxxOwTc3yvi_WzCvcY05XKB7.qQt4FtH1ZeO2JxyAALCkq5bhnaLGvTxOkWmSEChiBVNH RvwNKqfhpGrHTpVvGKSVj2al2qnA9RfTz.eCu7SaIYu9NTRJfaoHrWdAokq1RRKqjYBI.XUaTk.V gdqO9oA00kDoghwDmSDg0onGTpVsQdyXEb_yrkNVDa4jEgTgkIwRJEkRBDOutJYkRgzASSfCEZGe pwF3ibCELHeq6r9BebLuNLvQ0fGtXKFSCsffmVYt1xROZ6Xerrxw_X7QqTmq8nXA7wrzIyweI0kY 9G4dXSEbVaqN0c2pMb9VqWqgigCOS.TECW.ThFc0QC0X8b1PxE9rgMX2GwEfDndwOewM_SwAExK7 HO_4LrW8VJgKt6S8aYPtMSiy5wsM8Boks447uwI5Rvb2MVd6J93QWPdo8PziY5t49MId6_k_57ui LsC38mlGT9SBmeo.8Buwd38orNyYRjhcfMNzbaAAewpnBoVhyMJLw2kpSQ_OHFN.E1GLyb6hFxzw 3wnB.9DC.rHx8rtZ.JRw1fc7uRA0GXr1P17WSswTgHHEu97rP1WoBA0tKkaQS5oSY..1Jt9sGjAC GxUwVTHIgQycZVP7TFgW6i2ufAZRv9NWpPijP_1VxeMUp8Fm0.s2_o0rs.1SAoqnfizZQ8tBStP2 5cHgFLUrXFf3YIYgWAgN7rA-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Wed, 17 Nov 2021 19:17:31 +0000 Received: by kubenode517.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 64521ccdb33749a612aab2229e750149; Wed, 17 Nov 2021 19:17:28 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: aarch64(?) poudiere-devel based builds seem to get fairly-rare corrupted files after recent system update(s?) Date: Wed, 17 Nov 2021 11:17:27 -0800 References: <2CA61249-321C-45AA-9755-597146AB8E9F@yahoo.com> <65AA4BCD-EC4B-4A19-B750-C7FC6E5ADDF5@yahoo.com> <9BF4F65B-6437-4D88-AF34-9BCFBF90D6F3@yahoo.com> To: freebsd-current , "freebsd-arm@freebsd.org" In-Reply-To: <9BF4F65B-6437-4D88-AF34-9BCFBF90D6F3@yahoo.com> Message-Id: X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4HvXkV2C6Rz4RM2 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=cxt1dJrc; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.205 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; NEURAL_SPAM_SHORT(1.00)[1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.205:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.205:from]; RCVD_COUNT_TWO(0.00)[2] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-current X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Nov-15, at 15:43, Mark Millard wrote: > On 2021-Nov-15, at 13:13, Mark Millard wrote: >=20 >> On 2021-Nov-15, at 12:51, Mark Millard wrote: >>=20 >>> On 2021-Nov-15, at 11:31, Mark Millard wrote: >>>=20 >>>> I updated from (shown a system that I've not updated yet): >>>>=20 >>>> # uname -apKU >>>> FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #18 = main-n250455-890cae197737-dirty: Thu Nov 4 13:43:17 PDT 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64=20 >>>> 1400040 1400040 >>>>=20 >>>> to: >>>>=20 >>>> # uname -apKU >>>> FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #19 = main-n250667-20aa359773be-dirty: Sun Nov 14 02:57:32 PST 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400042 1400042 >>>>=20 >>>> and then updated /usr/ports/ and started poudriere-devel based = builds of >>>> the ports I's set up to use. However my last round of port builds = from >>>> a general update of /usr/ports/ were on 2021-10-23 before either of = the >>>> above. >>>>=20 >>>> I've had at least two files that seem to be corrupted, where a = later part >>>> of the build hits problematical file(s) from earlier build = activity. For >>>> example: >>>>=20 >>>> /usr/local/include/X11/extensions/XvMC.h:1:1: warning: null = character ignored [-Wnull-character] >>>> =20 >>>> ^ >>>> /usr/local/include/X11/extensions/XvMC.h:1:2: warning: null = character ignored [-Wnull-character] >>>> >>>> ^ >>>> /usr/local/include/X11/extensions/XvMC.h:1:3: warning: null = character ignored [-Wnull-character] >>>> =20 >>>> ^ =20 >>>> /usr/local/include/X11/extensions/XvMC.h:1:4: warning: null = character ignored [-Wnull-character] >>>> >>>> ^ >>>> . . . >>>>=20 >>>> Removing the xorgproto-2021.4 package and rebuilding via >>>> poudiere-devel did not get a failure of any ports dependent >>>> on it. >>>>=20 >>>> This was from a use of: >>>>=20 >>>> # poudriere jail -j13_0R-CA7 -i >>>> Jail name: 13_0R-CA7 >>>> Jail version: 13.0-RELEASE-p5 >>>> Jail arch: arm.armv7 >>>> Jail method: null >>>> Jail mount: /usr/obj/DESTDIRs/13_0R-CA7-poud >>>> Jail fs: =20 >>>> Jail updated: 2021-11-04 01:48:49 >>>> Jail pkgbase: disabled >>>>=20 >>>> but another not-investigated example was from: >>>>=20 >>>> # poudriere jail -j13_0R-CA72 -i >>>> Jail name: 13_0R-CA72 >>>> Jail version: 13.0-RELEASE-p5 >>>> Jail arch: arm64.aarch64 >>>> Jail method: null >>>> Jail mount: /usr/obj/DESTDIRs/13_0R-CA72-poud >>>> Jail fs: =20 >>>> Jail updated: 2021-11-04 01:48:01 >>>> Jail pkgbase: disabled >>>>=20 >>>> (so no 32-bit COMPAT involved). The apparent corruption >>>> was in a different port (autoconfig, noticed by the >>>> build of automake failing via config reporting >>>> /usr/local/share/autoconf-2.69/autoconf/autoconf.m4f >>>> being rejected). >>>>=20 >>>> /usr/obj/DESTDIRs/13_0R-CA7-poud/ and >>>> /usr/obj/DESTDIRs/13_0R-CA72-poud/ and the like track the >>>> system versions. >>>>=20 >>>> The media is an Optane 960 in the PCIe slot of a HoneyComb >>>> (16 Cortex-A72's). The context is a root on ZFS one, ZFS >>>> used in order to have bectl, not redundancy. >>>>=20 >>>> The ThreadRipper 1950X (so amd64) port builds did not give >>>> evidence of such problems based on the updated system. (Also >>>> Optane media in a PCIe slot, also root on ZFS.) But the >>>> errors seem rare enough to not be able to conclude much. >>>=20 >>> For aarch64 targeting aarch64 there was also this >>> explicit corruption notice during the poudriere(-devel) >>> bulk build: >>>=20 >>> . . . >>> [CA72_ZFS] Extracting arm-none-eabi-gcc-8.4.0_3: ......... >>> pkg-static: Fail to extract = /usr/local/libexec/gcc/arm-none-eabi/8.4.0/lto1 from package: Lzma = library error: Corrupted input data >>> [CA72_ZFS] Extracting arm-none-eabi-gcc-8.4.0_3... done >>>=20 >>> Failed to install the following 1 package(s): = /packages/All/arm-none-eabi-gcc-8.4.0_3.pkg >>> *** Error code 1 >>> Stop. >>> make: stopped in /usr/ports/sysutils/u-boot-orangepi-plus-2e >>>=20 >>> I'm not yet to the point of retrying after removing >>> arm-none-eabi-gcc-8.4.0_3 : other things are being built. >>=20 >>=20 >> Another context with my prior general update of /usr/ports/ >> and the matching port builds: Back then I used USE_TMPFS=3Dall >> but the failure is based on USE_TMPFS-"data" instead. So: >> lots more I/O. >>=20 >=20 > None of the 3 corruptions repeated during bulk builds that > retried the builds that generated the files. All of the > ports that failed by hitting the corruptions in what they > depended on, built fine in teh retries. >=20 > For reference: >=20 > I'll note that, back when I was using USE_TMPFS=3Dall , I also > did some separate bulk -a test runs, both aarch64 (Cortex-A72) > native and Cortext-A72 targeting Cortex-A7 (armv7). None of > those showed evidence of file corruptions. In general I've > not had previous file corruptions with this system. (There > was a little more than 245 GiBytes swap, which covered the > tmpfs needs when they were large.) I set up a contrasting test context and got no evidence of corruptions in that context. (Note: the 3 bulk builds total to around 24 hrs of activity for the 3 examples of 460+ ports building.) So, for the Cortex-A72 system, root on UFS on portable USB3 SSD: no evidence of corruptions vs.: root on ZFS on optane in PCIe slot: solid evidence of 3 known = corruptions Both had USE_TMPFS=3D"data" in use. The same system build had been installed and booted for both tests. The evidence of corruptions is rare enough for this not to be determinative, but it is suggestive. Unfortunately, ZFS vs. UFS and Optane-in-PCIe vs. USB3 are not differentiated by this test result. There is also the result that I've not seen evidence of corruptions on the ThreadRipper 1950 X (amd64) system. Again, not determinative, but suggestive, given how rare the corruptions seem to be. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Wed Nov 17 20:07:21 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 2835E18A3E6F for ; Wed, 17 Nov 2021 20:07:26 +0000 (UTC) (envelope-from se@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HvYqy0S9Yz4jXZ; Wed, 17 Nov 2021 20:07:26 +0000 (UTC) (envelope-from se@freebsd.org) Received: from [IPV6:2003:cd:5f2e:2500:fc45:3285:e123:4572] (p200300cd5f2e2500fc453285e1234572.dip0.t-ipconnect.de [IPv6:2003:cd:5f2e:2500:fc45:3285:e123:4572]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: se/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 803D4F736; Wed, 17 Nov 2021 20:07:25 +0000 (UTC) (envelope-from se@freebsd.org) Message-ID: Date: Wed, 17 Nov 2021 21:07:21 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Content-Language: en-US From: Stefan Esser To: FreeBSD CURRENT Subject: Incompatible change in LLD13 causing link errors? Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------gEb4qyRsoCQhzgoIqxQXDmf8" X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------gEb4qyRsoCQhzgoIqxQXDmf8 Content-Type: multipart/mixed; boundary="------------QGSakzp46Y2h82iqf5c0AWU0"; protected-headers="v1" From: Stefan Esser To: FreeBSD CURRENT Message-ID: Subject: Incompatible change in LLD13 causing link errors? --------------QGSakzp46Y2h82iqf5c0AWU0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I have just received pkg-fallout for a port that has not been touched for several months, specifically lang/silq. ld.lld: error: undefined hidden symbol: __start___minfo >>> referenced by terminal.d >>> silq.o:(ldc.register_dso) ld.lld: error: undefined hidden symbol: __stop___minfo >>> referenced by terminal.d >>> silq.o:(ldc.register_dso) cc: error: linker command failed with exit code 1 (use -v to see invocati= on) Error: /usr/bin/cc failed with status: 1 *** Error code 1 This port builds correctly with LLD12 from a port, but fails with the error message included above for both LLD13 from a port and LLD from the FreeBSD-CURRENT base system. There seems to be a difference in the visibility of symbols between the LLD versions 12 and 13, but I have no idea what changed and which LLD flags might be available to restore the previous behavior. Any ideas? --------------QGSakzp46Y2h82iqf5c0AWU0-- --------------gEb4qyRsoCQhzgoIqxQXDmf8 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEo3HqZZwL7MgrcVMTR+u171r99UQFAmGVYPkFAwAAAAAACgkQR+u171r99UTA wwf/QI/XscBfa3LfgsiMoDFQ8MNH1Zr0dQult5MF4H/tipGXiUNms5HYPvyWq8EZ9JwDsyBuGw5K 6rdAoT4bvJlMADIYBXFdavJ3GcrUO34rVIo4DHWFe4WWoQNywiq/wzm6wQVHaSqNAO0aA1BNRefU XI5ZL2XnTiB3k5i6FZgLlQswDe7d1hpsTRovzcIbQt4aIUmxPLHKwQc9uxKuLIPUl+gEIyZqQqGo 3iP8cBv3ItCWYZnvWBnPYBziGa1ldDWaDr8PjgOYq5Mb8HpWSMvrHkd1ddsOYZD4xp8bQKUnYAb8 DhL17PSL3bxUlF1qF5GTw+Riw33B0Pf7SXNd8+gRYw== =xJ4f -----END PGP SIGNATURE----- --------------gEb4qyRsoCQhzgoIqxQXDmf8-- From nobody Wed Nov 17 20:13:18 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 64FC818A6778 for ; Wed, 17 Nov 2021 20:13:30 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-21.consmr.mail.gq1.yahoo.com (sonic310-21.consmr.mail.gq1.yahoo.com [98.137.69.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HvYyw6NSMz4lyn for ; Wed, 17 Nov 2021 20:13:28 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637180002; bh=awT8FBEqueYlsPRz8QAnfacfpO5LGghjpkNdxy5WQAE=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=Qy8gvZ00GFf4zuSC2lgesGcUcOOHzDf3S2MVFMerqplYnIcGCoMzhW+mRsxmuT78Cd/AtKd58AB820zonUXaADVpUUec5qSz/E+eL9eW1VBSwzzM3KrqxOSGnkXQHaEGjmsMfpoUmUHSsuTmY7yVMyvVGr6zAsgynvscSCBH9Mu550N/+pn9dDtUbqJR+pN51g8ljbXKC68A45gjq4DWa1REgKAP/C4Kq93YLzvXo5hS1a74HLHPtPlF6OYmXexib1chVL+RYPyybN9jpJsWrJaXAE4wC8XpQfiDeBrfd9P/wUe0c2nuTQd0lBCmLO+a8GsYs/ZyNZvYqg1MpvEG8w== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637180002; bh=vEghWUZfScD5oEXk6cM2WhcfTTfru7rXVS9KiSCjjW4=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=Dhzh1SL3aAKTNPEY868x4wX9Erq7APPkVSizaBkc0ul2iuEWeQMtExe47oRPN7eY5HJ1rGvWeBVgRmwClCjpVx5eLGbnzgNK6ggtcMGVOVy23Msah0YhrCPszlwSeBu7UPLaY1vJX/sDGa+fMWZYq8n5dkf/UbUkAbyDwCXER9pJlKW3DH6qY9tishE2UhFddpx9BGQp/jxhsaQQzOlz3Fkvx3B7JGMlj+XHzflvWPfeIE9SZ0VEmARCjbLbiSEBz3/wIQtGtIAUshaN5pzMiLEye07iWDivMfjH9CgyQJnSSsP3oTgWQoKq+kyqQLAqw8cfMPTQZ6K4bVT6ukZSLA== X-YMail-OSG: 1ApHP8cVM1kS1poAvQGWtwmH850vIdrsNo8BbUj3de.Py00zIRRuJ.L5llQc8hW BnpuKpJEmStPD37pF9FxedQfFwV81ry_cwiE8CMv4uph8ccrpS00zL2etDF_G3itelcLpiGyCNeK XPKc_cmPSaUv.nTWxBFP8nUO4ZdHGFXO5czlyOZSpB6cgA4BIN2ZB63xBT_nlJi0SLq83307Q.bE 81OG3Trgalfvlv9ow6yQRgZDm7gazXFjGUO96RTm6zkKwSCHZpYyB0gFlL3enVCOEY2S2jqCY1B6 pKf63Ld3gTcf1EgNB4OYx669CymQWsv29BMUvR4G6JoDyMA91lpwGskEjuwuTsBOcNdnLjBb_uyt gGdwGz487gjH.e2qCOuy18J0Cae_7Wat9y9caXnug_ZBWnp9BBehxE2YqbeFOyJvtY9uvin4Cg6k F.cdNe6npG72Mm9p7QIKegNOVbvxyg7AiVToCbAO9njVYBa5tD6jJB6fyCNfpZUb1sz.MOERTIZK lq0dYOnCpbHcIKH8GzzxyYbvBSCIpWETeeKIDpfihdPjEHzeS7yJYjFUL6_fZQrUtm2m.tXZiQnd A5HrLyYyMnX8Src_ORDzBZ.ZqprgWBfsOrkH6.54KFZ478TjL22QpeaccPAAtJ.lDR3d_jPzKG8y O5dqvSDr9ZerLUgzVMXJHCMh4DxOn3qV7oTQNrhTFm5xyn4KwL_t6nqT92vUna9rzZkgbiYFXihK euN3jEbhMYWjaouC4iivz1RcvQkq9TbwPkFLLTUuuldYE9c_BuhrwYOrOCkoNF98OQRNBpLD8aBq dUYRYC4dPN5.FM_QuicQyk6fNhOnGNWXleBo75TN4IM5Ty1tSV_oJLiVXChAeEH054wf17AeJHKd EgdWMIY_dktxyA_7RQk01ZrKhCe3u5LGlUmLc9T8HrsdBnx_NwrZq8VoNznMV7YVR_pfSmmqSwqp N_xMOdRICX0n4tAM9B9cssiAZcdV_8O20heNjl2PNooMYYsaIrCCXTJTVqCxci06LBfB6Kp6HVFq Ph0gvchIHRCm5AczZtC__yDuSvhCzKd8K7YTyFIyhoG5.xyWELtcKjW.dxiHBl3q7eRC4JOTB4jU PAGG8FJ_ToID321JWT3Yyizfz5nbo3BnjZ7Pc_F7ho68r3N1yHW43ZW9eod41aWu0b6jqNTtH2Zr pneJ6lVcpPufZBQhPEXnYL65nFOMTctY.EG6vS8sCsmyGPMcrijViqDKAgqR_qeZLdCnSAA9AxkB lwtfQm7IRpPULCz1fKUmLKeTxdS4SGpQNFeRzmGHBN3o79CHubY84QsR_ZFS6YSRiWdwO2NJo7lf NUnsxhSmtrvGbOq1T4MkaHi8cJnblvImbdiUiLLWvP7xZRMFzzXuw2Thxl3oZzVo2GStN1gNQMXR DS7VgEGUTxY4NufCWa7RyZfPesC5YTX.U6b8fwYT6l_wo4.RFxEzpIZPwnEjYotILyMlPp_TG.fi n.wB1jzUIpx4dmoM86gDNIkT7Nz7P4loYgMOzvzDvMzwvnytAMC5X1g7XZR9U31s_yAtZQf0kXWW n3licS5vbO8zjaTHRCVlgD6Xkptb79TA2mtye7yGJAUgcpuk2vY3VmdSbxYOiHg4hj05Ry_e8wPf hhGvgHYZ3tDxNW8e.dEB3YcYTb2XIdz1p34yTDDQ9j.nkI5fuw6cb9RAVlp5Tb93hbR2CSVrsncc 6OKVqVe.EXT69WNL1atxOBSZ6KyxqZmN9J1RI4xfJnsRKgqL0r4cX8SwgmHNGv9yw6mcJq22UGIs t_tX7kK70ERF5_VNhNyp747DQw7BSwjM1S9npi2SP_GylHAI90gItUvOoHW2_yjL4MSMnCprDcYA iMUcQ5PeYocgsUysoyLSXTkelrExeIEGo8Oz8qWD..ohydWcQNuzvJ9sI7.U8Hlr4efB_iggmVrs .k7j4PL8SCb64CE9XMdWuUrtIPJ.WafR8Qf6Am90tiPYngkfmIBEwHRjQ.jzBF12YAO47va67ulh BFTg5mrl3V6.X62IcBPVj0OGf0hVtmRBfyNN0p4XkLPutWbjmpZAmJc86AOn8R3jHKseAX.aOIAF 1f4l8KGoP7hchnVAbzmY7q_N_UtgIOh7.T.lCifUZXIgPi_OR0Fr2S1Yxdd6jIzKgpKWZBzD92F7 xPRxq1ysIZRx1tIS3pRZANm.BCdClgm1CtC7yLR36D8rXIiFivWo11qGizRUN4Z8VR9h95lXY2hz Aflk_yjfmTDmzZMl9utc4mi501x8Rlw-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Wed, 17 Nov 2021 20:13:22 +0000 Received: by kubenode548.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 60d4c00e112dd7e44a70f09835870e65; Wed, 17 Nov 2021 20:13:20 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: "Khelp module "ertt" can't unload until its refcount drops from 1 to 0." after "All buffers synced."? Message-Id: <119DC979-EC2C-4BE4-A6E8-2DBF222115A0@yahoo.com> Date: Wed, 17 Nov 2021 12:13:18 -0800 To: freebsd-current X-Mailer: Apple Mail (2.3654.120.0.1.13) References: <119DC979-EC2C-4BE4-A6E8-2DBF222115A0.ref@yahoo.com> X-Rspamd-Queue-Id: 4HvYyw6NSMz4lyn X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=Qy8gvZ00; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-2.39 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.89)[-0.890]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; SUBJECT_ENDS_QUESTION(1.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.147:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.147:from]; RCVD_COUNT_TWO(0.00)[2] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-current X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N I've not noticed the ertt message before in: . . . Waiting (max 60 seconds) for system thread `bufspacedaemon-1' to stop... done All buffers synced. Uptime: 1d9h57m18s Khelp module "ertt" can't unload until its refcount drops from 1 to 0. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Wed Nov 17 20:20:45 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id D55FA185229C for ; Wed, 17 Nov 2021 20:20:59 +0000 (UTC) (envelope-from dim@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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HvZ7b5PJLz4pH3; Wed, 17 Nov 2021 20:20:59 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "R3" (verified OK)) (Authenticated sender: dim) by smtp.freebsd.org (Postfix) with ESMTPSA id 7C0DEFBDD; Wed, 17 Nov 2021 20:20:59 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtpclient.apple (longrow.home.andric.com [192.168.0.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 0CC541857; Wed, 17 Nov 2021 21:20:58 +0100 (CET) From: Dimitry Andric Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_3A7FC25C-77DF-4DA3-A5F2-0A9F62B6674C"; protocol="application/pgp-signature"; micalg=pgp-sha1 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: Incompatible change in LLD13 causing link errors? Date: Wed, 17 Nov 2021 21:20:45 +0100 In-Reply-To: Cc: FreeBSD CURRENT , Jessica Clarke To: Stefan Esser References: X-Mailer: Apple Mail (2.3654.120.0.1.13) X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_3A7FC25C-77DF-4DA3-A5F2-0A9F62B6674C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 17 Nov 2021, at 21:07, Stefan Esser wrote: >=20 > I have just received pkg-fallout for a port that has not been touched > for several months, specifically lang/silq. >=20 > ld.lld: error: undefined hidden symbol: __start___minfo >>>> referenced by terminal.d >>>> silq.o:(ldc.register_dso) >=20 > ld.lld: error: undefined hidden symbol: __stop___minfo >>>> referenced by terminal.d >>>> silq.o:(ldc.register_dso) > cc: error: linker command failed with exit code 1 (use -v to see = invocation) > Error: /usr/bin/cc failed with status: 1 > *** Error code 1 >=20 > This port builds correctly with LLD12 from a port, but fails with the > error message included above for both LLD13 from a port and LLD from > the FreeBSD-CURRENT base system. See https://bugs.llvm.org/show_bug.cgi?id=3D52384 where this is = discussed. Executive summary is to add -Wl,-z,nostart-stop-gc to your LDFLAGS, for now at least. But as you can see in the upstream PR, not everybody is happy with them flipping the default to on. -Dimitry --Apple-Mail=_3A7FC25C-77DF-4DA3-A5F2-0A9F62B6674C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCYZVkHQAKCRCwXqMKLiCW o+YMAKCzEHGuUiWRzvuX1lqx0xTttwq7KACeKI3i4nOUGVxq6DIjtElsTusmtcw= =5nos -----END PGP SIGNATURE----- --Apple-Mail=_3A7FC25C-77DF-4DA3-A5F2-0A9F62B6674C-- From nobody Wed Nov 17 21:44:46 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B1C1718963BD for ; Wed, 17 Nov 2021 21:44:50 +0000 (UTC) (envelope-from se@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Hvc0L4Lfwz4bgD; Wed, 17 Nov 2021 21:44:50 +0000 (UTC) (envelope-from se@freebsd.org) Received: from [IPV6:2003:cd:5f2e:2500:fc45:3285:e123:4572] (p200300cd5f2e2500fc453285e1234572.dip0.t-ipconnect.de [IPv6:2003:cd:5f2e:2500:fc45:3285:e123:4572]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: se/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id B7710FFDC; Wed, 17 Nov 2021 21:44:49 +0000 (UTC) (envelope-from se@freebsd.org) Message-ID: <51a2d269-53c3-4bee-a69d-86b36f436e04@freebsd.org> Date: Wed, 17 Nov 2021 22:44:46 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: Incompatible change in LLD13 causing link errors? Content-Language: en-US To: Dimitry Andric , acm@FreeBSD.org Cc: FreeBSD CURRENT , Jessica Clarke References: From: Stefan Esser In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------0h4060H0KBJoJCwmMgzYqH8n" X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------0h4060H0KBJoJCwmMgzYqH8n Content-Type: multipart/mixed; boundary="------------wrCLEdGwalYcgERdjhKakvxF"; protected-headers="v1" From: Stefan Esser To: Dimitry Andric , acm@FreeBSD.org Cc: FreeBSD CURRENT , Jessica Clarke Message-ID: <51a2d269-53c3-4bee-a69d-86b36f436e04@freebsd.org> Subject: Re: Incompatible change in LLD13 causing link errors? References: In-Reply-To: --------------wrCLEdGwalYcgERdjhKakvxF Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am 17.11.21 um 21:20 schrieb Dimitry Andric: > On 17 Nov 2021, at 21:07, Stefan Esser wrote: >> >> I have just received pkg-fallout for a port that has not been touched >> for several months, specifically lang/silq. >> >> ld.lld: error: undefined hidden symbol: __start___minfo >>>>> referenced by terminal.d >>>>> silq.o:(ldc.register_dso) >> >> ld.lld: error: undefined hidden symbol: __stop___minfo >>>>> referenced by terminal.d >>>>> silq.o:(ldc.register_dso) >> cc: error: linker command failed with exit code 1 (use -v to see invoc= ation) >> Error: /usr/bin/cc failed with status: 1 >> *** Error code 1 >> >> This port builds correctly with LLD12 from a port, but fails with the >> error message included above for both LLD13 from a port and LLD from >> the FreeBSD-CURRENT base system. >=20 > See https://bugs.llvm.org/show_bug.cgi?id=3D52384 where this is discuss= ed. > Executive summary is to add -Wl,-z,nostart-stop-gc to your LDFLAGS, for= > now at least. But as you can see in the upstream PR, not everybody is > happy with them flipping the default to on. Hi Dimitry, thank you for the quick reply! Seems that the breakage of LDC had been noticed (by Jessica?) a few weeks ago, and that a possible solution could be to build LDC with LLVM>=3D13.0.0. But apparently LDC-1.23.0 cannot be built with llvm13, and a naive attempt to upgrade the LDC port to 1.28.0 failed (MAINTAINER in CC). Since LDC currently depends on LLVM10 I'll just add that as a dependency to my failing port and hard-code lld10 as the linker to use. A better fix could be to import the (apparently not yet completely accepted) patch https://github.com/ldc-developers/ldc/pull/3850/ to explicitly define the garbage collected symbols in rt.dso into LDC. Anyway, my lang/silq port seems to be fixed by using llvm10 (poudriere test builds ongoing). Regards, STefan --------------wrCLEdGwalYcgERdjhKakvxF-- --------------0h4060H0KBJoJCwmMgzYqH8n Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEo3HqZZwL7MgrcVMTR+u171r99UQFAmGVd84FAwAAAAAACgkQR+u171r99USv Ogf9GIibyq+in4WG+GEgjfrphhQF2vBs2EynuiZnjIIc9I7rUrvkFWTd2/zG1ES/X/0oXO+t3Cn8 RFq4BWmOiHmGxsrwx5j5/QKoDx/D1PxuxkDEZq3h2usAlPI0CqDEojKl1eXn/HjQ2b5pxuFVK8gH kkSi5z008/dkjScWWzxuM5f8Pel7kPkHnvv6jegb7/cXy4PN+ufQdL5BOqTMOswcz7ZCvD2fQQKn CbSTPr9fZfMe2x9O5+UlDLTbKRJUqUZ9d5GFb3LHmZUsY/1343i3DRg78SUOXCD+GoxtEVVLnRIQ Eti5SDygIzi/EQUKziXiVtu/eFDMHgTW6UAT2guUpQ== =bYnJ -----END PGP SIGNATURE----- --------------0h4060H0KBJoJCwmMgzYqH8n-- From nobody Thu Nov 18 05:22:04 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 568F418A19F4 for ; Thu, 18 Nov 2021 05:22:20 +0000 (UTC) (envelope-from dmarquess@gmail.com) Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Hvp8C4Q5tz4ptB for ; Thu, 18 Nov 2021 05:22:19 +0000 (UTC) (envelope-from dmarquess@gmail.com) Received: by mail-ed1-x52a.google.com with SMTP id l25so5066215eda.11 for ; Wed, 17 Nov 2021 21:22:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=scWSuWlkvTDAth+U9cTiR/JtYNbamYdWofIQJpEkR+Y=; b=K+BVXI4ePIZlxAJBaPHhYZ9IloGnQUKz965tipwqCu4rkEeRo4ZHIrihPhGfcmxrrX NmhSzsy0gRiB2RBKR+nWejY3RO1nprp1f3U0TfUTpExTM/ONeT833BsDxddw0e3QFto+ loALBWajIISYLSQQbl3tmHs0c7mK5uIWR8rPC9Poui6BVcUqs5oGHnfTfJ7KhoQqVxjm 9Outw/QqSs5wVORXWJ2j6AP+yGUsxQxjuRTubZp1Ua0+o0vm6o2eRu8NG+VAsIVCYElY 2nw/OM4eiOxG3i8XwF4n697ydu8JsSa23jGYwsNJIBT/Kmo6ytD4sHDFuBhelzkhubEw M4Kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=scWSuWlkvTDAth+U9cTiR/JtYNbamYdWofIQJpEkR+Y=; b=nARa/rycbvyPoQIIVRL4TaPpGGcw0akmZdfehrtSU2xgz3yDY4ekKrX2IG098Cx9/O b9h7VkYqpb/nM4Ny/xQTI9HEWmMW8kT1RV12hVLiVoH+Eik759BaXkiDLoAyUMDPkYx4 jyCPQSPxWs00WeYqJYUMN8Dp4Z5DFuohw2ZsludWDptndMVJqBVXCJhGWQ86hY/VP8ZZ QpbGjn9e6LWJqfBG7WeSv+oFJB0KsqmHm1KQxvHMl5+E4QTIrBnKVj5FjQRcC9tUxjBi ENuWMFBiap3xqP6Qc54FX7/gvA4olZOA+CJE6gVhyGta6T4Or4GgdOQrr+AsmeYHyuCK wn7Q== X-Gm-Message-State: AOAM530CaZL8jgBXaHCN41+zQxFf3jWTLbM2Ec8iNZv4rWqTI7ss6n4k pxxXAaQHc9amu1woWfxAIA87WRTX0V0HSC1RGBoyVaGwf9UliA== X-Google-Smtp-Source: ABdhPJyaIhg+uszno6flVHFq3lmgzmEVcQccLi4XWuG07CVLNppSlaZ6x7uOGxoCbVrddrCoku6WP3IOQJ6JK9FxYI4= X-Received: by 2002:a05:6402:50d0:: with SMTP id h16mr7307114edb.70.1637212937111; Wed, 17 Nov 2021 21:22:17 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 From: Dustin Marquess Date: Wed, 17 Nov 2021 23:22:04 -0600 Message-ID: Subject: 14.0-CURRENT panic in early boot To: FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4Hvp8C4Q5tz4ptB X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=K+BVXI4e; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of dmarquess@gmail.com designates 2a00:1450:4864:20::52a as permitted sender) smtp.mailfrom=dmarquess@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52a:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N I just updated a machine from a build that was ~2 weeks old. The latest commit when I built it was 2e946f87055. The system boots using UEFI, if that matters. The system is panicking pretty early in the boot, however: real memory = 137438953472 (131072 MB) avail memory = 133651496960 (127460 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 32 CPUs FreeBSD/SMP: 2 package(s) x 8 core(s) x 2 hardware threads random: registering fast source Intel Secure Key RNG random: fast provider: "Intel Secure Key RNG" random: unblocking device. kernel trap 12 with interrupts disabled panic: vm_fault_lookup: fault on nofault entry, addr: 0xffffffff81e1d000 cpuid = 0 time = 1 The backtrace shows: KDB: stack backtrace: #0 0xffffffff806deb5b at kdb_backtrace+0x6b #1 0xffffffff80693b44 at vpanic+0x184 #2 0xffffffff806939b3 at panic+0x43 #3 0xffffffff8091d4b3 at vm_fault+0x1423 #4 0xffffffff8091bfb0 at vm_fault_trap+0xb0 #5 0xffffffff809c0902 at trap_pfault+0x1f2 #6 0xffffffff809992b8 at calltrap+0x8 #7 0xffffffff806ebcc1 at vsscanf+0x31 #8 0xffffffff806ebc7f at sscanf+0x3f #9 0xffffffff806bd9ab at validate_uuid+0x8b #10 0xffffffff80655be0 at prison0_init+0x90 #11 0xffffffff80623aba at proc0_init+0x29a #12 0xffffffff80623689 at mi_startup+0xe9 #13 0xffffffff802e3062 at btext+0x22 Uptime: 1s Compared to a boot using the old working kernel: real memory = 137438953472 (131072 MB) avail memory = 133651505152 (127460 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 32 CPUs FreeBSD/SMP: 2 package(s) x 8 core(s) x 2 hardware threads random: registering fast source Intel Secure Key RNG random: fast provider: "Intel Secure Key RNG" random: unblocking device. ioapic0 irqs 0-23 ioapic1 irqs 24-47 ioapic2 irqs 48-71 Launching APs: 1 11 28 15 18 6 29 4 16 9 24 7 3 10 27 22 14 13 12 23 25 20 26 30 17 5 2 21 19 8 31 Timecounter "TSC-low" frequency 1197250876 Hz quality 1000 Has anybody else seen this? -Dustin From nobody Thu Nov 18 17:46:43 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4AB7B1888D60 for ; Thu, 18 Nov 2021 17:46:47 +0000 (UTC) (envelope-from gardask@gmail.com) Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Hw6gC1LcHz4mfZ for ; Thu, 18 Nov 2021 17:46:47 +0000 (UTC) (envelope-from gardask@gmail.com) Received: by mail-wm1-x332.google.com with SMTP id g191-20020a1c9dc8000000b0032fbf912885so5439798wme.4 for ; Thu, 18 Nov 2021 09:46:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=Js/OomctKsUr8OS60suVKBF2DKH6KY4CJAAHvWir0lY=; b=eYcvtFhSNPnDAM3EZJspheAzwidWx8VAekzir3vl7Z/KROdwzrBhKofwYokfpCfKPc jENlscQ77Ese0c7TYxjRQq13PmigWlAC8/MIvYR92WWq2KUD+dN9qoEnFjhNFgqtfOOe iWgUS2pvoFes/nhEzFZpu3/SEPuNLmPC8JXzZ0lPaVTFvbdkVZT+XHpN0DX0SGzgjp3i sl0IuFEEEAaQFUqSE4EsjZItNDExaiedM1our7vHuknCkmseeBlwxApf7EyB7JUsjm4+ FYzakZ68FEFSfKUmGusNcKsGD9c3IJm1zD7krqz+gkwSadggsZt4255eCzN6PnnuZSa2 9ZZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Js/OomctKsUr8OS60suVKBF2DKH6KY4CJAAHvWir0lY=; b=CcxZb6Hki6l+88En8ejtJCMZ7r51hQUAedCM6KOXV3jEWdyXqXQs+awXUT3YQeX3y8 D0P05vtPxtN0/Jine7ZfA1SkEMPk2W5MyzBOTMVIn/P4Q1rhmhCnmHmOQ62ZcCMS1A/u Vckdpxt7r2bVm9aPhFEvBnyqy64uKCjGd04J3jUunJhu8ds8PcHbYlJDZTbKgCeSzlL4 wA/w8GQiTvcP55z3kR+++llvA3YRnvo0ubR96GD7zQbb8IjXpMwquYXzAZX2azHt3fTY DOZG3+wwRTisNLE0LsMU9idysITKUKBUkwkBYiqvjM84g1I2cJPI5+rPVVqhYbcci5j3 jYAw== X-Gm-Message-State: AOAM530DBiYIB2BeVUB/2HhPItgsVl7puHA8s+17ntJ5xjj7XDZJnjEn JQh/bIS6IK/WDXWPeuI/rqouA+A8IpE= X-Google-Smtp-Source: ABdhPJyY2LFzXE9GAdWeAx1ZyrLxRDP3mIXNgcLQBXLnCKjxFe7XTTFfWcAtUqDF30riSrIWaU4J2Q== X-Received: by 2002:a1c:a301:: with SMTP id m1mr11923909wme.118.1637257605761; Thu, 18 Nov 2021 09:46:45 -0800 (PST) Received: from [10.0.30.5] ([31.47.99.1]) by smtp.gmail.com with ESMTPSA id f19sm13421829wmq.34.2021.11.18.09.46.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 18 Nov 2021 09:46:45 -0800 (PST) Subject: Re: 14.0-CURRENT panic in early boot To: Dustin Marquess , FreeBSD CURRENT References: From: Karel Gardas Message-ID: Date: Thu, 18 Nov 2021 18:46:43 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4Hw6gC1LcHz4mfZ X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Completely speculating, but since you don't see ioapic's are you sure this is just ~2 weeks old build? If not, then it may be relevant to: commit 1b7a2680fba589daf6f700565214919cb941ab56 Author: Jung-uk Kim Date: Thu Sep 30 16:23:21 2021 -0400 Import ACPICA 20210930 (cherry picked from commit c509b6ab0d7e5bafc5348b08653b8738bd40716e) IMHO! On 11/18/21 6:22 AM, Dustin Marquess wrote: > I just updated a machine from a build that was ~2 weeks old. The > latest commit when I built it was 2e946f87055. > > The system boots using UEFI, if that matters. The system is panicking > pretty early in the boot, however: > > real memory = 137438953472 (131072 MB) > avail memory = 133651496960 (127460 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 32 CPUs > FreeBSD/SMP: 2 package(s) x 8 core(s) x 2 hardware threads > random: registering fast source Intel Secure Key RNG > random: fast provider: "Intel Secure Key RNG" > random: unblocking device. > kernel trap 12 with interrupts disabled > panic: vm_fault_lookup: fault on nofault entry, addr: 0xffffffff81e1d000 > cpuid = 0 > time = 1 > > > The backtrace shows: > > KDB: stack backtrace: > #0 0xffffffff806deb5b at kdb_backtrace+0x6b > #1 0xffffffff80693b44 at vpanic+0x184 > #2 0xffffffff806939b3 at panic+0x43 > #3 0xffffffff8091d4b3 at vm_fault+0x1423 > #4 0xffffffff8091bfb0 at vm_fault_trap+0xb0 > #5 0xffffffff809c0902 at trap_pfault+0x1f2 > #6 0xffffffff809992b8 at calltrap+0x8 > #7 0xffffffff806ebcc1 at vsscanf+0x31 > #8 0xffffffff806ebc7f at sscanf+0x3f > #9 0xffffffff806bd9ab at validate_uuid+0x8b > #10 0xffffffff80655be0 at prison0_init+0x90 > #11 0xffffffff80623aba at proc0_init+0x29a > #12 0xffffffff80623689 at mi_startup+0xe9 > #13 0xffffffff802e3062 at btext+0x22 > Uptime: 1s > > Compared to a boot using the old working kernel: > > real memory = 137438953472 (131072 MB) > avail memory = 133651505152 (127460 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 32 CPUs > FreeBSD/SMP: 2 package(s) x 8 core(s) x 2 hardware threads > random: registering fast source Intel Secure Key RNG > random: fast provider: "Intel Secure Key RNG" > random: unblocking device. > ioapic0 irqs 0-23 > ioapic1 irqs 24-47 > ioapic2 irqs 48-71 > Launching APs: 1 11 28 15 18 6 29 4 16 9 24 7 3 10 27 22 14 13 12 23 > 25 20 26 30 17 5 2 21 19 8 31 > Timecounter "TSC-low" frequency 1197250876 Hz quality 1000 > > Has anybody else seen this? > -Dustin > From nobody Thu Nov 18 18:07:19 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 6B6A5189408C for ; Thu, 18 Nov 2021 18:07:32 +0000 (UTC) (envelope-from lwhsu@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Hw7782cZnz3CY9 for ; Thu, 18 Nov 2021 18:07:32 +0000 (UTC) (envelope-from lwhsu@freebsd.org) Received: from mail-ed1-f50.google.com (mail-ed1-f50.google.com [209.85.208.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) (Authenticated sender: lwhsu/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 3449C2A152 for ; Thu, 18 Nov 2021 18:07:32 +0000 (UTC) (envelope-from lwhsu@freebsd.org) Received: by mail-ed1-f50.google.com with SMTP id w1so30724915edd.10 for ; Thu, 18 Nov 2021 10:07:32 -0800 (PST) X-Gm-Message-State: AOAM532m2CHOoGR0LEuXBJu30tQkK2slFodZqMZX+BPL7b2gbfavWmgH rBh7N/zC48BytUD2ORVOgwoNGVKt1b+F4AK3Dfw= X-Google-Smtp-Source: ABdhPJwMufpXNvKvr3sjEHJK1JpWXziBpVgi1wmVq3g8mgJ8y4T7pEzdzih9OmOZUh88VZDChuqIAmTX+8/wLam9DZY= X-Received: by 2002:a50:955c:: with SMTP id v28mr13614280eda.293.1637258851062; Thu, 18 Nov 2021 10:07:31 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Li-Wen Hsu Date: Fri, 19 Nov 2021 02:07:19 +0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: HEADS-UP: ASLR for 64-bit executables enabled by default on main To: Marcin Wojtas Cc: freebsd-current , Fabien Thomas , MARECHAL Boris , Rafal Jaworowski , Damien DEVILLE Content-Type: text/plain; charset="UTF-8" X-ThisMailContainsUnwantedMimeParts: N On Wed, Nov 17, 2021 at 6:30 AM Marcin Wojtas wrote: > > As of b014e0f15bc7 the ASLR (Address Space Layout > Randomization) feature becomes enabled for the all 64-bit > binaries by default. > > Address Space Layout Randomization (ASLR) is an exploit mitigation > technique implemented in the majority of modern operating systems. > It involves randomly positioning the base address of an executable > and the position of libraries, heap, and stack, in a process's address > space. Although over the years ASLR proved to not guarantee full OS > security on its own, this mechanism can make exploitation more difficult > (especially when combined with other methods, such as W^X). > > Tests on the tier 1 64-bit architectures demonstrated that the ASLR is > stable and does not result in noticeable performance degradation, > therefore it is considered safe to enable this mechanism by default. > Moreover its effectiveness is increased for PIE (Position Independent > Executable) binaries. Thanks to commit 9a227a2fd642 ("Enable PIE by > default on 64-bit architectures"), building from src is not necessary > to have PIE binaries and it is enough to control usage of ASLR in the > OS solely by setting the appropriate sysctls. The defaults were toggled > for the 64-bit PIE and non-PIE executables. > > As for the drawbacks, a consequence of using the ASLR is more > significant VM fragmentation, hence the issues may be encountered > in the systems with a limited address space in high memory consumption > cases, such as buildworld. As a result, although the tests on 32-bit > architectures with ASLR enabled were mostly on par with what was > observed on 64-bit ones, the defaults for the former are not changed > at this time. Also, for the sake of safety the feature remains disabled > for 32-bit executables on 64-bit machines, too. > > The committed change affects the overall OS operation, so the > following should be taken into consideration: > * Address space fragmentation. > * A changed ABI due to modified layout of address space. > * More complicated debugging due to: > * Non-reproducible address space layout between runs. > * Some debuggers automatically disable ASLR for spawned processes, > making target's environment different between debug and > non-debug runs. > > The known issues (such as PR239873 or PR253208) have been fixed in > HEAD up front, however please pay attention to the system behavior after > upgrading the kernel to the newest revisions. > In order to confirm/rule-out the dependency of any encountered issue > on ASLR it is strongly advised to re-run the test with the feature > disabled - it can be done by setting the following sysctls > in the /etc/sysctl.conf file: > kern.elf64.aslr.enable=0 > kern.elf64.aslr.pie_enable=0 > > The change is a result of combined efforts under the auspices > of the FreeBSD Foundation and the Semihalf team sponsored > by Stormshield. > > Best regards, > Marcin Thanks very much for working on this. FYI, there are some test cases seem to be affected by this: https://ci.freebsd.org/job/FreeBSD-main-amd64-test/19828/testReport/ The mkimg ones are a bit tricky, it seems the output is changed in each run. We may need a way to generate reproducible results.. I'm still checking them, but hope more people can join and fix them. Best, Li-Wen From nobody Thu Nov 18 18:29:13 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3FE76189F3CE for ; Thu, 18 Nov 2021 18:29:16 +0000 (UTC) (envelope-from otis@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Hw7cD1JTPz3L4b; Thu, 18 Nov 2021 18:29:16 +0000 (UTC) (envelope-from otis@FreeBSD.org) Received: from ns2.wilbury.net (ns2.wilbury.net [IPv6:2a01:b200:0:1:f816:3eff:fecd:13e6]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "svc.wilbury.net", Issuer "R3" (verified OK)) (Authenticated sender: otis) by smtp.freebsd.org (Postfix) with ESMTPSA id E5B1A2A77E; Thu, 18 Nov 2021 18:29:15 +0000 (UTC) (envelope-from otis@FreeBSD.org) Received: from smtpclient.apple (gw-upc.owhome.net [188.167.168.254]) (Authenticated sender: juraj@lutter.sk) by svc.wilbury.net (Postfix) with ESMTPSA id 4F2A445CF6F; Thu, 18 Nov 2021 19:29:14 +0100 (CET) From: Juraj Lutter Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_9D6E8AA2-786F-4DAE-99D5-4F70B8A95C51" List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: 14.0-CURRENT panic in early boot Date: Thu, 18 Nov 2021 19:29:13 +0100 In-Reply-To: Cc: Dustin Marquess , FreeBSD CURRENT To: Karel Gardas References: X-Mailer: Apple Mail (2.3654.120.0.1.13) X-ThisMailContainsUnwantedMimeParts: Y --Apple-Mail=_9D6E8AA2-786F-4DAE-99D5-4F70B8A95C51 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 18 Nov 2021, at 18:46, Karel Gardas wrote: >=20 >=20 > Completely speculating, but since you don't see ioapic's are you sure = this is just ~2 weeks old build? If not, then it may be relevant to: Bisecting would be a better approach. otis >=20 > commit 1b7a2680fba589daf6f700565214919cb941ab56 > Author: Jung-uk Kim > Date: Thu Sep 30 16:23:21 2021 -0400 >=20 > Import ACPICA 20210930 >=20 > (cherry picked from commit = c509b6ab0d7e5bafc5348b08653b8738bd40716e) >=20 =E2=80=94 Juraj Lutter XMPP: juraj (at) lutter.sk GSM: +421907986576 --Apple-Mail=_9D6E8AA2-786F-4DAE-99D5-4F70B8A95C51-- From nobody Thu Nov 18 18:41:29 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0505A18A5FFE for ; Thu, 18 Nov 2021 18:41:42 +0000 (UTC) (envelope-from mw@semihalf.com) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Hw7tY6Gz2z3Qgn for ; Thu, 18 Nov 2021 18:41:41 +0000 (UTC) (envelope-from mw@semihalf.com) Received: by mail-lf1-x12c.google.com with SMTP id f18so30742251lfv.6 for ; Thu, 18 Nov 2021 10:41:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=jeyv0SbDAht7cVXGpPhGjNmwFJjADvneH4tCy52viwQ=; b=7iGgBEhYAcD+ACIojntqorGheI/tGa1ytm4qbXkBTUk26kzDa7J1qrugNF30a0Q2Az BXmms0Pju8WOcO/2jy0VweqLj2K4+TCJjJiibQ7x/xAw3/nZu2J8KOwPWvRYWEhE3oLJ tG3OxN8VdOhcJOvXDJmX7DAt9XTc0UlhL981BksMnY5Jyhqcp1upjRXhSHqDAmDVLIve ScYUoNG+TjSO1Mv0OvQl4OLZdBqSwIc8dgSGAT+1c1uxFhPYuB1dG5B3kT+/S+1e4rAw 3lwEcmxc7MsJrs2jOpObW1GEoAcI/Z0vCsE2oFbl3Y6MGV/+NRr+RPV2PnVrmBFE6Jfj 1upg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=jeyv0SbDAht7cVXGpPhGjNmwFJjADvneH4tCy52viwQ=; b=BHi0Y6oDeEAXa249UvO1REmIuz2CNBtnxxikOo4ror6P7XEojtPcyIK+EoSRikSTVD OrjaNANppI1CPLJB6atz8EUW7jFC6Z63YlroYmrD1T0ekLOSXq9SLpST6ZPh1+zskW9V 0cQM4PHybfmgwSQNTgZRMqjTT84XFEm8xCbhI+yK2+PU/3fT4nA7qmIuI9Jy4boTl+NZ xM3Jlt2X6FC3X/deM4MawpmxzHnk0H86Aez6quGpW+uOpTjbn8+TYe0eBLdUdPxhdWuD tZqxPeK6HP66Oh7l4j8H8rGZHT+e8untfK+g05Wh4hFNiP3IHMbS59Eszg1pcZ8TZuLU jOkA== X-Gm-Message-State: AOAM531iFkH+2pSHEl2Ex6mohtY9nxRRYbKAbwwZMpjj7DKwNgYxuUw5 81+Ffs1O0KQ23+vS9a4ShBWR9iBDFni+ysiD/KQnQA== X-Google-Smtp-Source: ABdhPJxwX4T/4I3stAOIarW+iFcX9xhz26SRWzuOb0dLGngZ3kwxrdY+UK87yuGVxpE6jVqEC0MxcWK3sBTuiNAM4v8= X-Received: by 2002:a05:6512:10c2:: with SMTP id k2mr26463025lfg.209.1637260900351; Thu, 18 Nov 2021 10:41:40 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Marcin Wojtas Date: Thu, 18 Nov 2021 19:41:29 +0100 Message-ID: Subject: Re: HEADS-UP: ASLR for 64-bit executables enabled by default on main To: Li-Wen Hsu Cc: freebsd-current , Fabien Thomas , MARECHAL Boris , Rafal Jaworowski , Damien DEVILLE Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4Hw7tY6Gz2z3Qgn X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi, czw., 18 lis 2021 o 19:07 Li-Wen Hsu napisa=C5=82(a): > > On Wed, Nov 17, 2021 at 6:30 AM Marcin Wojtas wrote: > > > > As of b014e0f15bc7 the ASLR (Address Space Layout > > Randomization) feature becomes enabled for the all 64-bit > > binaries by default. > > > > Address Space Layout Randomization (ASLR) is an exploit mitigation > > technique implemented in the majority of modern operating systems. > > It involves randomly positioning the base address of an executable > > and the position of libraries, heap, and stack, in a process's address > > space. Although over the years ASLR proved to not guarantee full OS > > security on its own, this mechanism can make exploitation more difficul= t > > (especially when combined with other methods, such as W^X). > > > > Tests on the tier 1 64-bit architectures demonstrated that the ASLR is > > stable and does not result in noticeable performance degradation, > > therefore it is considered safe to enable this mechanism by default. > > Moreover its effectiveness is increased for PIE (Position Independent > > Executable) binaries. Thanks to commit 9a227a2fd642 ("Enable PIE by > > default on 64-bit architectures"), building from src is not necessary > > to have PIE binaries and it is enough to control usage of ASLR in the > > OS solely by setting the appropriate sysctls. The defaults were toggled > > for the 64-bit PIE and non-PIE executables. > > > > As for the drawbacks, a consequence of using the ASLR is more > > significant VM fragmentation, hence the issues may be encountered > > in the systems with a limited address space in high memory consumption > > cases, such as buildworld. As a result, although the tests on 32-bit > > architectures with ASLR enabled were mostly on par with what was > > observed on 64-bit ones, the defaults for the former are not changed > > at this time. Also, for the sake of safety the feature remains disabled > > for 32-bit executables on 64-bit machines, too. > > > > The committed change affects the overall OS operation, so the > > following should be taken into consideration: > > * Address space fragmentation. > > * A changed ABI due to modified layout of address space. > > * More complicated debugging due to: > > * Non-reproducible address space layout between runs. > > * Some debuggers automatically disable ASLR for spawned processes, > > making target's environment different between debug and > > non-debug runs. > > > > The known issues (such as PR239873 or PR253208) have been fixed in > > HEAD up front, however please pay attention to the system behavior afte= r > > upgrading the kernel to the newest revisions. > > In order to confirm/rule-out the dependency of any encountered issue > > on ASLR it is strongly advised to re-run the test with the feature > > disabled - it can be done by setting the following sysctls > > in the /etc/sysctl.conf file: > > kern.elf64.aslr.enable=3D0 > > kern.elf64.aslr.pie_enable=3D0 > > > > The change is a result of combined efforts under the auspices > > of the FreeBSD Foundation and the Semihalf team sponsored > > by Stormshield. > > > > Best regards, > > Marcin > > Thanks very much for working on this. FYI, there are some test cases > seem to be affected by this: > > https://ci.freebsd.org/job/FreeBSD-main-amd64-test/19828/testReport/ > > The mkimg ones are a bit tricky, it seems the output is changed in > each run. We may need a way to generate reproducible results.. > > I'm still checking them, but hope more people can join and fix them. > Thanks for bringing this up! Apart from sys.netpfil.common.dummynet.pf_nat other are 23 are new. I checked a couple of next builds and the results seems to be consistent. There are: lib.libc.sys.setrlimit_test.setrlimit_stack lib.libc.regex.exhaust_test.regcomp_too_big sys.kern.coredump_phnum_test.coredump_phnum and 20 of usr.bin.mkimg.* We will also check and try to fix the new issues (however any help would be appreciated), it may be also worth to create dedicated tickets in bugzilla. Best regards, Marcin From nobody Thu Nov 18 20:15:24 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E4AF3188C428 for ; Thu, 18 Nov 2021 20:15:35 +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 4Hw9yt31R1z4gp4 for ; Thu, 18 Nov 2021 20:15:34 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637266527; bh=J5jTDIaTnEZkZoigEBqXE+AgCkZprZHN4kz4vMa+nd0=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=jPQ+PN9rOwtoNQdj8UK47+zCMS3Xq+pIIIQJzafw4K+cVI0pR0CqAc7gGXMDEvp5VYsU+D2UFkayiiMmWt+G+LdBmU8EkzqNGsN+9GJTBrmkL52mTUvQmQKHTx8sMRYkKNVaimclqqr1hYxN2v2YA3Reh4pKplmlH0iq9iaB7qI/4X8drFaQv31f5dFguj/oBnTP87oG3XZy+RSQYSqw8zGm0gOP6RXEqJiU1+N0iPPZGi6E9yjsubjgfn9RQJYX2apo33fO8tj/vdFQtyWpgXNbEOZtSofuFXKaJX5Ea3F/DYCj3gsz5pu1K2l5Rpn7KrGZ+o10ExgaHsih7oig+g== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637266527; bh=22TNxPffxf7O4ZS25ulyT9IpWTp0oSxF8C2IRXdmggt=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=OtPgkFlsYOZo0ueOEput32mGu4zEz0lY1jhF00IOYf96dHozTDt+aOzrbW4paCu3qy10YDheDpM+awhcmpZMA4BpAdBQ+DPplpaUok5tDF5kIrW1ZhbGqwLXWgmHHv3ckNI/UQ+ItEs7aSdE5CeS0dMW35+F8O5wum/XGvS/jsfAIC4k1TSOna+RP0Ke+O6yyQ1ncgTkmF/ALLp/z9TULlD3hQ/SFNd9O3k15JtPpMdsfoCbsOr6ow8ur65eRWPJK6Ltdn2r3aAuU/62cvIjUuB0Xdft8vF9TFuEX86Dw4U0qs9gidY/4GGiMmaiTV27jQ+x+R4b0bT0v4xgFZoNNQ== X-YMail-OSG: iJQVXacVM1lNwdySzIF0T1h4BvJBeaVlYFk7da7Wlyef06G2QJsNQPWp4YmSNX_ CZsWrJYYV73UWrvCzb9B8zbrNNjAgXpI45qklwTp5LMgnwJnc9ho32DKcYH79p8Yz7ksPNwFaPpk Dg9NKKoPGL0XjhLWf6zLA.okwH4h1cwzYglZ3GoSkArxGPJ.E2nm8Unn5epmBzU08zfN3Crt_z2a VXxaJ9DWorh1NqCgfAvYqLFumnKzS9E3gYsyY2ioT7kWKAbDdlgBrIcZG18vqMPIvx.HdVB3B033 1srElwg_9Jqp0V.ksFYgg6FMh.a2FB.cxq5lyByc3ikDNAMl3bxq3ZwHulnZNb_iXq2hJiLyqrXH m65lXZ_ts6knfXPwdNqQzqY6dmCZ.iqD5cka7rkc8e3Ld5SuLRrVRUDR8kVwY24h3W7iouculGmR Cq_pNws01zBEp0WkPEzu5oPsGrl5KlqUE1gLbVbNKtCTUoC05735.5dQuHkVh1KblyBtUw9cQrwf YJCFZoNuV9haSeEaWwFb5MrL5s7Y.2l.5fX6_TKq_Qq5XayK7oh.wXMxoycJTHlr0WgHQG8Ax._W nAIs_8cHrSZWL3xIOf2c0Y9CfxbyLo0TFnLNXAItShL1DfNzwuWfH7KK7rWL_OS7Nsap7CO7YVkE XLHHAiz8PF0pVaIYknGNb4Ml67Pn.loYpsrMe51ON_6KhBIQN79m9I8kjYF0AI.ve31JVenWEo9v UDnot1sYmASroxfvjwlnpX3VIvsmL1gmvq4WLPcpSGo7FEp.HPjZmJJBQ5_9Bc0wSu81mPZKbtOq s52b5NVTija.hMVmyMPUIlGxawoSTXFThc5n6BWmCB0g6VPyxwzJIGZXagnqtCvbRt3kbXAIgCIQ fW7v7leydEDEIyf.eX7FrJ6mrsM6JDXOld409Gf3hE8cR7.4HX_D9hVrc_7okfLoku4qLrYwADZB Wqn_pDjVwbHsKjX1.J1M3_NLts4qDdHbcfZIFYRXh4Mu6xT7Wd4fg0KcFt9lKaOm5VK7y4AdQiDv mzwYE1U50lajNorcvRUbmX91rtvFeXD3snrgHJZ7Xc.NZBe2fYWs2G0ar1Zo8LDBuh5aYr56N37H c26QLoDveSAmcKr6hek1WUcUqTrPZlzgfuN9wDfxHQozmw4BRw5eiCAXObHKcEctagoS2z9_KnQ9 yLs8oaqNoK8Zx40866_CefYGOVP3jXddPt5TB5smy7yO2ScNNenfpQX.rPZRTQmLJduwt9Yx5nEI ce0Y_uEZFjFJ3XtZDAS3aYPB_TWRxHn1PlpbZdNvYrfsnkgzG2XqU0wsE1DYp8dHWfwZ9LdyudOZ OPLq7AbQdB5PTZIL5kONxfqe_whxBRgH3n8_eyL3J44zhOpJJgc6vQH3MEFxBW6wUMslAwfreES_ RD6fYvXwUJ5dLBl9btC1aszAMilSJIxNnTSey8YuQ.wgRcS_iN46UNUZj793i0pGwhkUvl9WCasy ieShb__19pguVvZ7QwiG4eZhA_T0ThkwjpDo_3sGVPSEJfhWBDzDYHKRgLrg9O_YWakpHNTBmusc dc4j_oi7xWl.glPbGtLv8y33aRvMXNHdx_4Hs54NIboo2kWYg4qzsXEmiycWTDG8yhXDZFSKVuF2 eRHdHL7CYaW_QNeNRthGRUWVHBEuduMa2UNThOVT2xDYecmQZlXa5PDx3TLK.wZTYWd0UVHXqSO5 U3hcFDPUfJ69eb2iNrGmDVjie3ggejxzEG_R2.TaN92P2If143nLEfypUPvO4.JU8SSLlyHOKiNl uTwXbOMUVgWERuMxFzAie4KSHM5eoYhYIYZub6oCqJ2F_SHW59smPb9daoOuk0BjF0vop0CV7ry9 DLSVb_6eIfdATNiCX_kdEK5zO5qHmFWr6WpBeeE8x2LuN_99pRQS76_zfcXI4_Kg_jCjzZais2E3 IDIF8wlg8YlriN3CBSsu4Y8Pi1k5OVVd2DKbNwwWz9QBKoNP9mSrDmNSfHPY8YYP762sQnpHvR53 CSATrluBi.bneRbwX97o7aIMUobVMWHEuISSDKlmDTeEoDcX.XkPhCP_JvcdFhQSu5U.Y8UU9iYh RJj46enm.juku.UMc_3bvgk82NT39UKd5bv0HOnhcN6dnLppnM.mxyfTsmv2tNiQos0C4Z2EZ7yv LFjAxMlRxuY3D1ytbyj_TN4whiSo3aqnDjOci7VgD5gI5LBDOaSO6UQ.u10MumC1LMQk.rOs1wji VTlJeObJpjsPYm_XjrRU7._c3PczcRfXskLuU6Qff.HfRNA-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Thu, 18 Nov 2021 20:15:27 +0000 Received: by kubenode524.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 587cd65cf2b323b8c51e3fe72ea561ae; Thu, 18 Nov 2021 20:15:25 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: aarch64(?) poudiere-devel based builds seem to get fairly-rare corrupted files after recent system update(s?) Date: Thu, 18 Nov 2021 12:15:24 -0800 References: <2CA61249-321C-45AA-9755-597146AB8E9F@yahoo.com> <65AA4BCD-EC4B-4A19-B750-C7FC6E5ADDF5@yahoo.com> <9BF4F65B-6437-4D88-AF34-9BCFBF90D6F3@yahoo.com> To: freebsd-current , "freebsd-arm@freebsd.org" In-Reply-To: Message-Id: <4B591638-4693-4403-8549-88D7A1D9D669@yahoo.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4Hw9yt31R1z4gp4 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=jPQ+PN9r; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.83:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.83:from]; RCVD_COUNT_TWO(0.00)[2] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-current X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Nov-17, at 11:17, Mark Millard wrote: > On 2021-Nov-15, at 15:43, Mark Millard wrote: >=20 >> On 2021-Nov-15, at 13:13, Mark Millard wrote: >>=20 >>> On 2021-Nov-15, at 12:51, Mark Millard wrote: >>>=20 >>>> On 2021-Nov-15, at 11:31, Mark Millard wrote: >>>>=20 >>>>> I updated from (shown a system that I've not updated yet): >>>>>=20 >>>>> # uname -apKU >>>>> FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #18 = main-n250455-890cae197737-dirty: Thu Nov 4 13:43:17 PDT 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64=20 >>>>> 1400040 1400040 >>>>>=20 >>>>> to: >>>>>=20 >>>>> # uname -apKU >>>>> FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #19 = main-n250667-20aa359773be-dirty: Sun Nov 14 02:57:32 PST 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400042 1400042 >>>>>=20 >>>>> and then updated /usr/ports/ and started poudriere-devel based = builds of >>>>> the ports I's set up to use. However my last round of port builds = from >>>>> a general update of /usr/ports/ were on 2021-10-23 before either = of the >>>>> above. >>>>>=20 >>>>> I've had at least two files that seem to be corrupted, where a = later part >>>>> of the build hits problematical file(s) from earlier build = activity. For >>>>> example: >>>>>=20 >>>>> /usr/local/include/X11/extensions/XvMC.h:1:1: warning: null = character ignored [-Wnull-character] >>>>> =20 >>>>> ^ >>>>> /usr/local/include/X11/extensions/XvMC.h:1:2: warning: null = character ignored [-Wnull-character] >>>>> >>>>> ^ >>>>> /usr/local/include/X11/extensions/XvMC.h:1:3: warning: null = character ignored [-Wnull-character] >>>>> =20 >>>>> ^ =20 >>>>> /usr/local/include/X11/extensions/XvMC.h:1:4: warning: null = character ignored [-Wnull-character] >>>>> >>>>> ^ >>>>> . . . >>>>>=20 >>>>> Removing the xorgproto-2021.4 package and rebuilding via >>>>> poudiere-devel did not get a failure of any ports dependent >>>>> on it. >>>>>=20 >>>>> This was from a use of: >>>>>=20 >>>>> # poudriere jail -j13_0R-CA7 -i >>>>> Jail name: 13_0R-CA7 >>>>> Jail version: 13.0-RELEASE-p5 >>>>> Jail arch: arm.armv7 >>>>> Jail method: null >>>>> Jail mount: /usr/obj/DESTDIRs/13_0R-CA7-poud >>>>> Jail fs: =20 >>>>> Jail updated: 2021-11-04 01:48:49 >>>>> Jail pkgbase: disabled >>>>>=20 >>>>> but another not-investigated example was from: >>>>>=20 >>>>> # poudriere jail -j13_0R-CA72 -i >>>>> Jail name: 13_0R-CA72 >>>>> Jail version: 13.0-RELEASE-p5 >>>>> Jail arch: arm64.aarch64 >>>>> Jail method: null >>>>> Jail mount: /usr/obj/DESTDIRs/13_0R-CA72-poud >>>>> Jail fs: =20 >>>>> Jail updated: 2021-11-04 01:48:01 >>>>> Jail pkgbase: disabled >>>>>=20 >>>>> (so no 32-bit COMPAT involved). The apparent corruption >>>>> was in a different port (autoconfig, noticed by the >>>>> build of automake failing via config reporting >>>>> /usr/local/share/autoconf-2.69/autoconf/autoconf.m4f >>>>> being rejected). >>>>>=20 >>>>> /usr/obj/DESTDIRs/13_0R-CA7-poud/ and >>>>> /usr/obj/DESTDIRs/13_0R-CA72-poud/ and the like track the >>>>> system versions. >>>>>=20 >>>>> The media is an Optane 960 in the PCIe slot of a HoneyComb >>>>> (16 Cortex-A72's). The context is a root on ZFS one, ZFS >>>>> used in order to have bectl, not redundancy. >>>>>=20 >>>>> The ThreadRipper 1950X (so amd64) port builds did not give >>>>> evidence of such problems based on the updated system. (Also >>>>> Optane media in a PCIe slot, also root on ZFS.) But the >>>>> errors seem rare enough to not be able to conclude much. >>>>=20 >>>> For aarch64 targeting aarch64 there was also this >>>> explicit corruption notice during the poudriere(-devel) >>>> bulk build: >>>>=20 >>>> . . . >>>> [CA72_ZFS] Extracting arm-none-eabi-gcc-8.4.0_3: ......... >>>> pkg-static: Fail to extract = /usr/local/libexec/gcc/arm-none-eabi/8.4.0/lto1 from package: Lzma = library error: Corrupted input data >>>> [CA72_ZFS] Extracting arm-none-eabi-gcc-8.4.0_3... done >>>>=20 >>>> Failed to install the following 1 package(s): = /packages/All/arm-none-eabi-gcc-8.4.0_3.pkg >>>> *** Error code 1 >>>> Stop. >>>> make: stopped in /usr/ports/sysutils/u-boot-orangepi-plus-2e >>>>=20 >>>> I'm not yet to the point of retrying after removing >>>> arm-none-eabi-gcc-8.4.0_3 : other things are being built. >>>=20 >>>=20 >>> Another context with my prior general update of /usr/ports/ >>> and the matching port builds: Back then I used USE_TMPFS=3Dall >>> but the failure is based on USE_TMPFS-"data" instead. So: >>> lots more I/O. >>>=20 >>=20 >> None of the 3 corruptions repeated during bulk builds that >> retried the builds that generated the files. All of the >> ports that failed by hitting the corruptions in what they >> depended on, built fine in teh retries. >>=20 >> For reference: >>=20 >> I'll note that, back when I was using USE_TMPFS=3Dall , I also >> did some separate bulk -a test runs, both aarch64 (Cortex-A72) >> native and Cortext-A72 targeting Cortex-A7 (armv7). None of >> those showed evidence of file corruptions. In general I've >> not had previous file corruptions with this system. (There >> was a little more than 245 GiBytes swap, which covered the >> tmpfs needs when they were large.) >=20 >=20 > I set up a contrasting test context and got no evidence of > corruptions in that context. (Note: the 3 bulk builds > total to around 24 hrs of activity for the 3 examples > of 460+ ports building.) So, for the Cortex-A72 system, I set up a UFS on Optane (U.2 via M.2 adapter) context and also got no evidence of corruptions in that context (same hardware and a copy of the USB3 SSD based system). The sequence of 3 bulks took somewhat over 18 hrs using the Optane. > root on UFS on portable USB3 SSD: no evidence of corruptions Also: root on UFS on Optane U.2 via M.2: no evidence of corruptions > vs.: > root on ZFS on optane in PCIe slot: solid evidence of 3 known = corruptions >=20 > Both had USE_TMPFS=3D"data" in use. The same system build > had been installed and booted for both tests. >=20 > The evidence of corruptions is rare enough for this not to > be determinative, but it is suggestive. >=20 > Unfortunately, ZFS vs. UFS and Optane-in-PCIe vs. USB3 are > not differentiated by this test result. >=20 > There is also the result that I've not seen evidence of > corruptions on the ThreadRipper 1950 X (amd64) system. > Again, not determinative, but suggestive, given how rare > the corruptions seem to be. So far the only things unique to the observed corruptions are: root on ZFS context (vs. root on UFS) and: Optane in a PCIe slot (but no contrasting ZFS case tested) The PCIe slot does not seem to me to be likely to be contributing. So this seem to be suggestive of a ZFS problem. A contributing point might be that the main [so: 14] system was built via -mcpu=3Dcortex-a72 for execution on a Cortext-A72 system. [I previously ran into a USB subsystem mishandling of keeping things coherent for the week memory ordering in this sort of context. That issue was fixed. But back then I was lucky enough to be able to demonstrate fails vs. works by adding an appropriate instruction to FreeBSD in a few specific places (more than necessary as it turned out). Someone else determined where the actual mishandling was that covered all required places. My generating that much information in this context seems unlikely.] =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Thu Nov 18 20:31:29 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B87511893DAD for ; Thu, 18 Nov 2021 20:31:39 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.franken.de", Issuer "Sectigo RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HwBKR2yB2z4myv for ; Thu, 18 Nov 2021 20:31:39 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from smtpclient.apple (unknown [IPv6:2a02:8109:1140:c3d:cd66:fc66:9ba3:f1eb]) (Authenticated sender: macmic) by drew.franken.de (Postfix) with ESMTPSA id 4CDCD721E280A; Thu, 18 Nov 2021 21:31:30 +0100 (CET) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.32\)) Subject: Re: "Khelp module "ertt" can't unload until its refcount drops from 1 to 0." after "All buffers synced."? From: tuexen@freebsd.org In-Reply-To: <119DC979-EC2C-4BE4-A6E8-2DBF222115A0@yahoo.com> Date: Thu, 18 Nov 2021 21:31:29 +0100 Cc: freebsd-current Content-Transfer-Encoding: quoted-printable Message-Id: <52374B7E-6ABB-4E55-984C-B7EC82B48506@freebsd.org> References: <119DC979-EC2C-4BE4-A6E8-2DBF222115A0.ref@yahoo.com> <119DC979-EC2C-4BE4-A6E8-2DBF222115A0@yahoo.com> To: Mark Millard X-Mailer: Apple Mail (2.3693.20.0.1.32) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail-n.franken.de X-Rspamd-Queue-Id: 4HwBKR2yB2z4myv X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; local_wl_from(0.00)[freebsd.org]; ASN(0.00)[asn:680, ipnet:2001:638::/32, country:DE] X-ThisMailContainsUnwantedMimeParts: N > On 17. Nov 2021, at 21:13, Mark Millard via freebsd-current = wrote: >=20 > I've not noticed the ertt message before in: >=20 > . . . > Waiting (max 60 seconds) for system thread `bufspacedaemon-1' to = stop... done > All buffers synced. > Uptime: 1d9h57m18s > Khelp module "ertt" can't unload until its refcount drops from 1 to 0. Hi Mark, what kernel configuration are you using? What kernel modules are loaded? Best regards Michael >=20 >=20 >=20 > =3D=3D=3D > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) >=20 >=20 From nobody Thu Nov 18 21:54:22 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 5C689188F42B for ; Thu, 18 Nov 2021 21:54:35 +0000 (UTC) (envelope-from dmarquess@gmail.com) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HwD971nTbz3kNr; Thu, 18 Nov 2021 21:54:35 +0000 (UTC) (envelope-from dmarquess@gmail.com) Received: by mail-ed1-x532.google.com with SMTP id x15so33513635edv.1; Thu, 18 Nov 2021 13:54:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=QUgTyE0fzs/oBz1TLDPnVlm/OhyljYtqrsmj7sEsqWs=; b=j3RzaC3qqVw1jPU/zpeee+/RJSFp/H8dpAqJdJHS5ON4wFrXK/gMOORhuzdu3MElTr G7IsM+I97oVl8Z7ALswc/oGDQuB8jQacZ7ImOgBm4IFoyZ4Z6LnysmDc0573b7YVWSns oct2A8g8qD7+Zf08dbQs8Qent1NzNmpvcFf64RNJLODii7UHVxTOX2NQPY/3mfh/M3RB OBCOpTc92vecYNBucmxDFYFTk37jrRYMOIxvLokcAXGTeFr9wU6nOoRusH+QWQ4WNvFI SUahoJYfdw7OOZJQI79Y+IV/j5Drq5uBSyt0jbf/0T+q8XjH9HjynKFv3HqDSz0lA9DV lu3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=QUgTyE0fzs/oBz1TLDPnVlm/OhyljYtqrsmj7sEsqWs=; b=qeY/x4Nc/9eHXbwOFshPYGKzJZWFUl+CmQo2LZZP0pw7h/pWl44nIW2mP1Po9e4tlA q5ms4AkbRPJbIU3PZiCLJnwrttI/iTdDduq+KnsvBE/ME8NXiz7K+qk/fjNnTymkMfcz dPKbo48WkWVanaBm+OzVm5cTg603K9kQwJs7Q0epLFfPCpBEKsJ3k9VeDj3RSSZMYP0/ Dr1PZ2LqZJ0MSqYkC1Wc2STcgXbW5u+se05xgp14lu+BDBGZHk5FZNrMqk0tmehj1qwi oPVDrT5xzTn0Vfjq5b9k7LMdx5Nuz5KfWWkkjrFF+m0AE/viBhUGMtPi3kqigXb3lJVA zysQ== X-Gm-Message-State: AOAM533o8sND0OD1WR49TSbkq89raduQ9v8loLxqf8EWkOgSEZsdlNRl G87HUqKqqh0lmTEonbIAdksDCY0mOMAXT97fg7fyWYE34FU= X-Google-Smtp-Source: ABdhPJzphJfV35otbwsbrDrvZsm4LMhWAXeZW0Zvy5jJa/ZLzGu97h2TqmdT+3E1093Q6Zi3lM/aDGA79+jIn+DIC1g= X-Received: by 2002:a05:6402:26d4:: with SMTP id x20mr16119627edd.119.1637272474051; Thu, 18 Nov 2021 13:54:34 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Dustin Marquess Date: Thu, 18 Nov 2021 15:54:22 -0600 Message-ID: Subject: Re: 14.0-CURRENT panic in early boot To: Juraj Lutter Cc: Karel Gardas , FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4HwD971nTbz3kNr X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N It was 16 days ago, so just a tad over 2 weeks :). Indeed, I'll start a bisect here in a few and I'll update as soon as I know. I figured I'd ask ahead of time before I did the work :). Thanks! -Dustin On Thu, Nov 18, 2021 at 12:29 PM Juraj Lutter wrote: > > > > On 18 Nov 2021, at 18:46, Karel Gardas wrote: > > > Completely speculating, but since you don't see ioapic's are you sure thi= s is just ~2 weeks old build? If not, then it may be relevant to: > > > Bisecting would be a better approach. > > otis > > > commit 1b7a2680fba589daf6f700565214919cb941ab56 > Author: Jung-uk Kim > Date: Thu Sep 30 16:23:21 2021 -0400 > > Import ACPICA 20210930 > > (cherry picked from commit c509b6ab0d7e5bafc5348b08653b8738bd40716e) > > > > =E2=80=94 > Juraj Lutter > XMPP: juraj (at) lutter.sk > GSM: +421907986576 > From nobody Thu Nov 18 23:11:45 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3DD43189E762 for ; Thu, 18 Nov 2021 23:12:00 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-22.consmr.mail.gq1.yahoo.com (sonic310-22.consmr.mail.gq1.yahoo.com [98.137.69.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HwFtR6WGzz4dtt for ; Thu, 18 Nov 2021 23:11:59 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637277112; bh=DzJE8IIRizpUo0MOW9Nw20wksbtfFrcN71jqlM0pHm0=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=sE18sgO4kIU2reTQPiStE7YOd8bGT/imr3XmWMpcUiA52/7iin2pRKhReq0QCdlYP+w7MJDnoBGeKR4GdqMwMBG31s8cGUxH+OK0toelBDvSpVGXfmtKh6pzY2S41+Ja3OmmIm+tMM1U8iIjjg6Sffec/eGtMnbDhOYT3YyE1rW237vtnMP3D3GcTGarHipKULrFFv6SZ1+Hp+g7skgJ9wXZbJGuESUH0lia6wla2BuYnZwYEYfIkssGvi3ROrqdEaQUps8CQrdYwyuH1szeB/wFzBI2PjlGeblg9W5i+GPHxq0m8fys7XUcS4BTrTi5nT/Txxu4ATURyQw2BXDDCw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637277112; bh=sLpDeSvQzQrTD2X6z+o2d9fH77MANtUrF9zszjZN380=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=bgHb+1su5iBWkNJrEJvrF9FFJlFXebgMsfksPYznIu/7zCkVksnctOmhrt0Q0+nhQg4CwP0F4vAkhrM8BrQZZJGvpOTnT5jxcnHAYTA5kA5W5lWWMoeCeVwe/G8VaC6lytCM8xEiPyXAWshnnNIc4xkqUjjblGpfaQu/WCOdENSrTxbzodCRXExwI5HPm/RvzHQ59AjT9TnI7HzOgXn5m/kyVMc/FPQjbml1KGW4n2NiTv+jPrzqDFRWE6C8ZbXhxA8o2fG1OJlT0AG/fI4snc+03kesAC/luYEZIqfTGzmpb30GRb74it0bo0EoMe7E0/28gef99g/QdiwWAQ6vdQ== X-YMail-OSG: zmuyg9cVM1lJP48yE4ho9Sl6mKz8Wj5gYQMhFafy2iBnnTJCOSCuVa7.Gx2Wljz Kr_75szQiB25I24USOTYgzj1T1bgLUgfzJENl02v7QrRr5V3sXKQwjcfBXibZNTujP.Ocd3GV1du XYDUlB3g9oVC2Ax0fTvetKva4OZR9KdECLxsD1xNTjmmttmTg8b6_Pr3CEShQU04jCMprfRi7vzm 3JN16HLgwZ2m3CwKCkh3MKp5KAhbcprTMl7XyEi0PprT6pbbwt.6Wxq4YQs_FfXeeYP7taMnhuqW v_6K6MZUgpQHXJNKoMA2BOJsBGduqAZ2qxJ5bfFzj9KwVyZWKmGLzMf1vwPqECoPAwENSFFbyZRk oMv_Z7JeLm_k64GN7fojys9AuUyYFQUE.IdIHnZViH9ISd24yLrv1CGC2yKaEDPBnjmj.L.YtAX4 DqInraR3yLf5nEHwd83tTqjAf7T.l4KnRoHwkYOKLBoHExbZSQNBE2t7wvVgQP14oa_.wAKU4CeE FDO8KmW66OGQScyQNB1JuNvMg72lkbK0Ggdibw3XcDdI.U2ulZQtcRXg8bJVBgqAbd2VEcFJAKUo YOopr8RU50Gu3_2_UIbEsCdyWcYqAtWHfV2swVsr99FmJkxwjlZxGJevfcX1QtCBlNTOIf.aI9Ip WHGjIwuiwz7udm1Ovotzklou4nYJ1OvdT6i9NmNK2X05B81dkKykg0BtkDorIgpeYv_tGFZx2aCm woX82Zz1oIoHLY3S0LPssRNnlPA394CL4NZ59GhngLRs19HVAFBpTiumvmCWytMO.oTIxU.r9K1R ouMFmTgoZuEpQxsJxnCQ63OjjQUjCWmUT6oFIpv17i7qk6oEjxdVGu6_xdaOXBro.4eAWTDEJy8d yDdgfBhX9YyiurLngOsTj61F4_fouUjALzsBjTcfVxtlOSAmzZsXob2Wa4etU30Yb4SulJQarSj9 sT11imscAC5tvVPe3CzqHFgn_piM5exaLSsOCk8uuLTPreI.6Q2qVZxWJHjGtxezydw5EujBxWuD x6r5PFKuLWw_Ua_udkwCTgcjLXFbFkLPcgp1B_PRzwBeZ9aHN5AmWyf_ZfHkCSuOkLtYOvV7Xnwc ZebOE27mQDcj9f9_aiUVcJ8PybUZIYUA7UqrK9ftqZjBxer395ITqwVI40_nWbncMn4LTCVvxF0i bNwIQ_qFOSXWT0ZnMlIKjkf9uyspcKp2xofMnRKkkSGfGUjCY1ojAFbs8hQtXg9VZz3mFlmMTcH9 RBhvX9FLH7aDmp9IOPxRWMzTTvvPi3DGY__Zq9YeKQDEB18vkH8wvXRFIiRGOky4dcHuR0vVZcPr KZSl3jPZQ5nOQW2JpiUxE38piyklua84nzruOWgn0QsnrmVVnrKJojCFvt8uTYIzqBQA8n.LZGDn Rvy2oPUVRzcucd3ceqjBbFI4zslVj.v7d902uKvhc5.LIngTbo644U_33WrxYlLaS7kHiZ9oRTUu ZgcVxXY1bpk5vvkjQCEGHvU1XLrgrzM16RwqC.SA2tPzkbbluAwN10l.P6iYCt0ntyrN5QG1IGGc FW2KlS62ziGenEICe3nQfXfMTy6Uv9VPEZyr9TszRxlNKToC.KLhy5ItnMSo8j0hvY7zwwNdrmdM bLWiYdoI2ai0uEv3aWC5w3V1evNPFCTkoYKqK_eAc1wEFMesBx5Kvjb1zybFkVd5rU.EOolWhjCi sMUKHpizOuwUMZC_XmfMjUy371_.ZY9mQA1OY6sJvD1MigjN.cuPhddsalIO6EOdDtFcu2ikP3oH Ofl_RuZG.xrd6eIWnO.0Dx9Swj2hmVbH9tMu43PW0MlP6tz5T9uPt18wW6MdzK0.elHS4HS3iMNx 3NqUw5VVbbZbAam3K7uwujgy.Ny2Tb2OaDnvw29Sn7MbhuVgj2MRANpbxHCNb6cQvdnXuACIf6dY w6mLhyofW01LpG_.uCixqFiBU4Vfd15zRgZarMQEF_ko0pN_LMydCzygoeLA_FtpDq_DXdcv1b62 j504bwY0wz8CHpP2Uzoe7OXWCrCORhiPm8R36zZQX5o3aQn27B584x7_P.CjYsXYGK86jlRBuNcM xvLds.6zw02WJ8cm3kRASTeMPr6nT4owYSK3jtogA32GxMgvKFLo7TtO6AKdMYuuCqKL3q..tkyE lz52I9lulXoRJ_bWHTTH2O78qxEssqSJ8bACGisM4vVmWxc0pSisV1YfPItMWyiU5eDKYxnWEgw9 Yu3UK7UZHNge3FUj9cKO6iTUjlWcOlF6IJMguH1K5OeZ7ssaRKODBqBHTNNGw.zoWNpRnvqJpIus YfOySSC.EI1j7j69mCYXXgpzmfj879cnE_QdcIzLJIDMjHacmoTMQgd6.HjuL X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Thu, 18 Nov 2021 23:11:52 +0000 Received: by kubenode516.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 32e1decfbd1270aac4cfee0220c08896; Thu, 18 Nov 2021 23:11:47 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: "Khelp module "ertt" can't unload until its refcount drops from 1 to 0." after "All buffers synced."? In-Reply-To: <52374B7E-6ABB-4E55-984C-B7EC82B48506@freebsd.org> Date: Thu, 18 Nov 2021 15:11:45 -0800 Cc: freebsd-current Content-Transfer-Encoding: quoted-printable Message-Id: References: <119DC979-EC2C-4BE4-A6E8-2DBF222115A0.ref@yahoo.com> <119DC979-EC2C-4BE4-A6E8-2DBF222115A0@yahoo.com> <52374B7E-6ABB-4E55-984C-B7EC82B48506@freebsd.org> To: "tuexen@freebsd.org" X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4HwFtR6WGzz4dtt X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-current X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N > On 2021-Nov-18, at 12:31, tuexen@freebsd.org = wrote: >=20 >> On 17. Nov 2021, at 21:13, Mark Millard via freebsd-current = wrote: >>=20 >> I've not noticed the ertt message before in: >>=20 >> . . . >> Waiting (max 60 seconds) for system thread `bufspacedaemon-1' to = stop... done >> All buffers synced. >> Uptime: 1d9h57m18s >> Khelp module "ertt" can't unload until its refcount drops from 1 to = 0. > Hi Mark, >=20 > what kernel configuration are you using? What kernel modules are = loaded? The shutdown was of my ZFS boot media but the machine is currently doing builds on the UFS media. (The ZFS media is present but not mounted). For now I provide information from the booted UFS system. The UFS context is intended to be nearly a copy of the brctl selection for main [so: 14] from the ZFS media. Both systems have been doing the same poudriere builds for various comparison/contrast purposes. The current build activity will likely take 16+ hrs. For reference for now (from UFS context): # uname -apKU FreeBSD HC_CA72_UFS 14.0-CURRENT FreeBSD 14.0-CURRENT #19 = main-n250667-20aa359773be-dirty: Sun Nov 14 02:57:32 PST 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400042 1400042 This environment was built with -mcpu=3Dcortex-a72 in use and the system is a 16 core Cortex-A72 system. (I've caught a FreeBSD weak memory model error in the past with such -mcpu=3Dcortext-a72 use on a Cortext-A72 system, not that I have evidence of such here.) # kldstat Id Refs Address Size Name 1 18 0xffff000000000000 12b1660 kernel 2 1 0xffff0000012b2000 41e070 zfs.ko 3 1 0xffff0000016d1000 26af8 cryptodev.ko 4 1 0xffff00019a400000 27000 nullfs.ko 5 1 0xffff00019a427000 25000 fdescfs.ko # more /usr/main-src/sys/arm64/conf/GENERIC-NODBG-CA72 include "GENERIC-NODBG" ident GENERIC-NODBG-CA72 makeoptions CONF_CFLAGS=3D"-mcpu=3Dcortex-a72" # more /usr/main-src/sys/arm64/conf/GENERIC-NODBG # # GENERIC -- Custom configuration for the arm64/aarch64 # include "GENERIC" ident GENERIC-NODBG makeoptions DEBUG=3D-g # Build kernel with gdb(1) = debug symbols options ALT_BREAK_TO_DEBUGGER options KDB # Enable kernel debugger support # For minimum debugger support (stable branch) use: #options KDB_TRACE # Print a stack trace for a = panic options DDB # Enable the kernel debugger # Extra stuff: #options VERBOSE_SYSINIT=3D0 # Enable verbose sysinit = messages #options BOOTVERBOSE=3D1 #options BOOTHOWTO=3DRB_VERBOSE #options KTR #options KTR_MASK=3DKTR_TRAP ##options KTR_CPUMASK=3D0xF #options KTR_VERBOSE # Disable any extra checking for. . . nooptions DEADLKRES # Enable the deadlock resolver nooptions INVARIANTS # Enable calls of extra sanity = checking nooptions INVARIANT_SUPPORT # Extra sanity checks of = internal structures, required by INVARIANTS nooptions WITNESS # Enable checks to detect = deadlocks and cycles nooptions WITNESS_SKIPSPIN # Don't run witness on spinlocks = for speed nooptions DIAGNOSTIC nooptions MALLOC_DEBUG_MAXZONES # Separate malloc(9) zones nooptions BUF_TRACKING nooptions FULL_BUF_TRACKING The builds do include a bulk for targeting armv7 (so 32-bit compatibility) but that bulk has not started yet in the UFS context. # poudriere jail -jmain-CA7 -i Jail name: main-CA7 Jail version: 14.0-CURRENT Jail arch: arm.armv7 Jail method: null Jail mount: /usr/obj/DESTDIRs/main-CA7-poud Jail fs: =20 Jail updated: 2021-11-16 02:24:57 Jail pkgbase: disabled My networking context is simple context does not provide services outside the local network. The services are normal ones, such as nfs, ssh, and whatever default things. ntpd is in use. distfiles are downloaded during builds. It is not a desktop environment, not even a video card. I've noticed a 2021-Feb-22 report in: = https://forums.freebsd.org/threads/whats-the-error-khelp-module-ertt-unloa= d.79009/ so getting the message does not appear to be unique to my context. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Thu Nov 18 23:54:58 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 25531188BFD6 for ; Thu, 18 Nov 2021 23:55:13 +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 4HwGrH74nNz4rwW for ; Thu, 18 Nov 2021 23:55:11 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637279704; bh=KBYbujy3LHZu6uIswgNyK3Q+nO6FdJJLh7r1w6/PLoE=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=PlKCLJlBCWNXO/izrAaD+ivHM2FgnLnshG//22WLhnJqVkqxy3osIlA6rVsSM4bBd47mBnT6CJYhcA0HSN/fZAhdaM8eHDy1/eUvDW11pNkqd7gUSVtoqjDmrmquvy2u2FV7ujAsyBMF7lyrs4anOW6sJwL6OCw+lWd7fQvIvftliSgqPYTGVYlZWk06t0MXVlTCF2uZuDFwAJ9OYZoQUdRatvlrxt4HtShKOxGOOUx/t9U54WSEVqqib9PMe2L8OdV/1aqkpxwdyBEIQjIPSznCPAoxA+fC0DNMcJ1dvGXqBNMC/VA5VkK1pDVBOoNbMmoFK+ZOrIv4LsSNfEf5BQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637279704; bh=lsS0ZE9x+n/gAFf306c8oaTwwkNHpmcJ/rsNh3SbGs9=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=O58Lc+9LrPx4szDE5F70S6fpvzCPu4VA/NZX/rEUvmOLKqrqbJ5jGOO0Tqk8kObodWGV7vbTERZSOigqvMNYTAOhiSflUl6mXkPlVAl6V5cpUzJ00gYqIcPfZSh8koAQF93AVGgn8zJY9Oo0J2g49JVNRuz2qudbbjd5F30265RPsXMVE+mPwEsIuhdOBLvb5GVtSjvm56dLTjYx8VOXmJVU3Yf2FYIsaWU4wBSUehlyVYiCLfQ/ZTHT8lp3TXKwOX8rxA+BpeBJ2RqGQwyRs7D58lVbCHYcA2KPfQxpEkvxHiyNslXV688KaxLJMq98Y8H36l8Lmu4MPnfPA8sCDQ== X-YMail-OSG: yTGG9kcVM1lVIh0lNgt4TVuis4tkz.frmP5Qs67lvUjljvIbTI3td85IWFssKye q6ThpDeE_3FzSzV4feZ2zt6Whn11pYEI6JxKxeDueo5AEHL2NTPil.9llbpzSSLZOFm.5LH3dZM9 wwbEmduEsnGASGz40yw.ebhHvPiKG7GHIYJaadEh2IrcSnvaOm0hELuKGHiRo6ePZcagPBBr2bip WhBGqboKMlQPF_C8NSD1hPq6YKJZW4NcnV5fbvpJCYwYFqI4Kyr.A0RV4eYS.cgdW5_dJk8xcEVP 7YGu0mT8uTV53X9PWLroO.7lHXPG0VtSDAXLQoRF2fw8mNCY6t0s7hKmh0HcN9dZBB892KrxpQdQ mD2LYBOygd_M12pMhTAJD09aQevplJGHdC0SYP77csi1zUeN_R6TzP51QZM03BJS91WHsLVgLcNc ukXVXyanaUt3ZUnHyHGV7HfatFmP_bIJAnmug.5936iZW3gwMXDhu6rdpTfeO7G._6KKl98I9Mof zyGVhrJjObaZAQ1KFnNoB8wUCml6ivTfJqaSLhwr4vhC6q8EYSHix9SJpuduRjgie5gZPYPVj1ZJ JVQZBv4RvOxs9nJdwRmjaAgh70wabi5lXqbL8IMCS5djSffXVnvfjrxxzw7pLPO79YvgYEYBsfuZ 56ivvb3AA8pGFzGl4wZOgKGY.KItK4zovcaIlJq0NqBWdu.RamAW0bV5vEJ9Rmci3D284zpRWvPU YIuG4ssBCuya9idbYqbHe5z5WpaODCsgL6xPUi4BRfamsjtSsnHGdc_p4f6clswb_c3P36gGnyIo sxnXfq4nOmU7IhN6pMMxausIOb1lk_OIrzyUwD42Nl0dvB3_EJGCm6NvAxGCXCXV6DNvRIpsL00m d797oXzGlWSykMl0xhBVbYlROtRaskcOVWaPSlSRu2Phm67UWkm.GnOxKF3IlwZArawgKGQoslRD 4WCq3np2E.upzDW8REk6yfUt3._P1n.3rc5yjdxbZFV_IObLCAUlmr2kUhb3knBATZcSU.JZWkWK 7.2kqFpfULyFQ.PnX.DeLXLRgNVQHsc7IeyhmYygMwAqNDn7y9NhuBArhGYEZ1VOuG4jevkxQrZb zdDXrxpe2044XfgZySYgybhSrrZF4nEhmyMBgV_4BKpkkqVpLbwe.NfFvhRNCpbngJypvrgD2gyx I074GrkUgxePY53A4h4U_0Vm1grBe.mDBpIQFjXtXMUJZscSXEqFlkpACf39iYkAcGA6Ka2C0P_R m7irF8j1jbYYeoNkGYGdzvqWdw_5FauQqLr0al2BN8ILx08DDuuXZPgv4909AUo_pKXpfLbBdzRw CIIlP1Lz4p.ayflboNrYm1P34lKF34EBGXM_s8XGC7KKHZQ6.OiDmfpLlKTzgHWRGduZYtaa46un bXzTpws.O98_V5sgJZYnkx_bZ2mT6Djic.SbChNXQvobP0oK8Vo9mOdDmbZWOoe.MGiiyaIfyV2p jSBvO0ElgGFZOkb2jDWkdftx8f.vrBkYCME4p0JjG4pV_dUdxt9IayIKAXLptWd1fjbGw.K3j5vg W2pc_lVxjTY0b16.8L7ImNggTFHLjO.yrGtcUGtCD_hvXgp.8LfBPn1ojnCZRbqjmbXR9h4Q9eCf HHwedN86SpfaG8rb2mdKb6.pa5cmLqOmSGW5WEejBKlrjznyD_i2.EsQM_u5nLRkl1cKZHX_0Jp1 layB2XMZhMCukZxCV2Qw31rYibSPZtS6M0njyMLn89H3YR6OyIt.Ebr13O0EJ9.eoHTX2Mfo_LG7 TUXm5MZejOkB6G8zXDxQQkZStrkFWd7jAQtdwlA17e0rKZ3rOoKH53.QbyHVluRRYzjhNFDf__oq kmLsKcKGAdBbbRvQEKQk9eN.Mxd3j4SOTNHvw1JuS1viAo8aXrK_OeC2jpU36ZGP244blTpxk.tb QSzDM6oeY9kwNEMhh7.RHNHGIBGkbqblkpT6Xo5S82iwCvZUEas_wLLYoFrjx5MaU3_onR8hnyYJ DSBo7CH4mXpUNJaXbbfSBTJd.QzKL87tzUZT7bjmApJnd5g9aeaPG59q6V_EvvzIiywtQjesLrx2 9wTrbrFxvBkvQim1Hl5fn_0cfatz6y2qCjEI6kAaW8kQdKXUK4k3NZ4W_HHDXLJ4pE_CusyFS9DV EnuYFU7lfd34QBFWX_3KihVa6Wqw.pMmTU5sXfFTTFLIw3leJj6KyNOT4uGzcox0EsXoqzF2ckbj q4lnj5uRlDPb0898nkXJQDJqnhebCq3m7e6HiARf2JB3EX0_SY3TrVdYFW68ry_qTXd_7NsBOIyV fs2UuRg-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Thu, 18 Nov 2021 23:55:04 +0000 Received: by kubenode503.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 178233f3bcdb399596fcf51fdf1a4474; Thu, 18 Nov 2021 23:55:00 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: FYI: amd64 system: "error: fileid changed. fsid 0:0: expected fileid 0xa, got 0x2. (BROKEN NFS SERVER OR MIDDLEWARE)"? Message-Id: Date: Thu, 18 Nov 2021 15:54:58 -0800 To: freebsd-current X-Mailer: Apple Mail (2.3654.120.0.1.13) References: X-Rspamd-Queue-Id: 4HwGrH74nNz4rwW X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=PlKCLJlB; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-0.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; SUBJECT_ENDS_QUESTION(1.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.206:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.206:from]; RCVD_COUNT_TWO(0.00)[2] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-current X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N The ThreadRipper 1950X FreeBSD system is reporting a message at 03:01:10 or so for the last 3 days. The .148 is a aarch64 system (HoneyComb). None of the other systems (aarch64 Small Board Computers and a armv7 SBC) are reporting such. Nov 16 03:01:10 amd64_ZFS kernel: newnfs: server '192.168.1.148' error: = fileid changed. fsid 0:0: expected fileid 0xa, got 0x2. (BROKEN NFS = SERVER OR MIDDLEWARE) Nov 17 03:01:10 amd64_ZFS kernel: newnfs: server '192.168.1.148' error: = fileid changed. fsid 0:0: expected fileid 0xa, got 0x2. (BROKEN NFS = SERVER OR MIDDLEWARE) Nov 18 03:01:09 amd64_ZFS kernel: newnfs: server '192.168.1.148' error: = fileid changed. fsid 0:0: expected fileid 0xa, got 0x2. (BROKEN NFS = SERVER OR MIDDLEWARE) # uname -apKU FreeBSD amd64_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #10 = main-n250667-20aa359773be-dirty: Sun Nov 14 00:24:51 PST 2021 = root@amd64_ZFS:/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.a= md64/sys/GENERIC-NODBG amd64 amd64 1400042 1400042 The .148 : # uname -apKU FreeBSD HC_CA72_UFS 14.0-CURRENT FreeBSD 14.0-CURRENT #19 = main-n250667-20aa359773be-dirty: Sun Nov 14 02:57:32 PST 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400042 1400042 (At times it is booted from a root-on-zfs media or a USB3 SSD UFS media instead but it is the same system build that is running for all those.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Fri Nov 19 00:04:00 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id A4FF31891B99 for ; Fri, 19 Nov 2021 00:04:12 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-25.consmr.mail.gq1.yahoo.com (sonic311-25.consmr.mail.gq1.yahoo.com [98.137.65.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 4HwH2f2qwvz3Cmj for ; Fri, 19 Nov 2021 00:04:10 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637280243; bh=qgrKy8yVRIwqDVfFTI7oz2xhYXiw0mlRpMb0sh2tCD8=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=gRVi0/m1s0JF6S1V5QnxeWuk2ro2MFr6G8nPgSOyydh3DgOMe/xWmnnB0z94CuXqEPWHvDAb5kDwuJXel1d0M9wIY3QRD2GBw54W3sDY7WwPirmxASon6X2fVC7JdKjO2V8guAdnadTOqEi4zBoPJN/U0PSRZRxlWDX9xcm8NniI6/IktGEkZGwGs5XU9qtsCehsFT5HWG2u+21OS7UccDvepiwYIAULde4ZYMbu/ypg1uFFan0j6PriI4tt5ZjIbnxkZCuYyCJ7QzWLpZw3yoXNggi7mnZjpLBlxl42Lh3jemBp9HhxxFHQtbe3Z09F4lnpGMfiFEEUdcOLq2CdEA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637280243; bh=6avDxrl61uaf46qJQ1t5PmnYBinhPdK0uSzncEQ6XM0=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=Yn9+XVtJQZyCDbcWhHQxw4cWeiTHtxC7hnzsZa10lWNeJa745w9uvAzY9O7wkhZvx3xlaXQ1oeIclpITpTr0Aiod+YhWaS0lyMwao2LJRntK5IhUaX08yApzPTBVt68nVUOzsO4nr5a58tg46O3TYT2/XPd34rv+nHwCL6NL9oJGZesFYLnBVOpICXBRuF0GL5BNHs8F5zNrtTht/j+4o1aQTdLJQGl5wAHDWRIl47Hl0QnUPyg80WLu6zA1mXU086ZFjTIiWu52s7PqEWQkzylvVbuvitBRxb/C1aFy9ocJmbjuYH33CC2u+VMhV3Js+uoJlBeGlgzugvVe0gXczg== X-YMail-OSG: zoyev.gVM1n2kELMXE8OWwGc0sV_wIPMtLJYBGD0.9f86bx2SAzOuA6w0h1WnzJ pQIL8L80KN4zPUD0bl0VHS39Gcdj8JZYVefwoyOqEANtxoMnYdtORQlGNKysL_Z_sLFQ.SWnRjqI Kcc0DkduIlzFY3oUufb1sNqt7VaMMP36OAbqsl0NvKBef_CW2.orsMvKgbXCSV_QXLrSLnF4K4LQ O8xxe9tc6qjAAh7T3RjIat6dE4RsQmefz5RG9WKYwqFkdNHaqvawEa6q3.VhY3xFXXgfITSrZQZf E_ra3aU0YOD.JcYsyP1viSmwXXc0HupEtdczz7WBv04N79Qabg579cq.jdNpOHgV.logsVWbIObc P_chNRdH.XAPNYc4ya3uoBmZ1bk.KKOvxmK7rvlubxEOnSADxB3ea.tlImq4qIMuaiUu5OhfmUTP 7T1RTxtL7PC7.cpS66k594lnBO69PVkkd42.vd0T5bC8FkodY9m9kYzigW0L23XV0AMbl0ryOsN9 RdXSos7xerTIPqHXmqNBDgAQ9Ss2bwApnRkO50xeLqjJV.eeri_0sYKp2Q2iCoVjnyFK9yqsOQWQ XW8NJksThv1N0Qwg_rJWglPR46c3vAzOEKe05uJaz70jF5Do70vtuhTUsk1CxCTQ8TnlrXTIyTaI AfTTmqfA0eh34dOEohwtopI.ORcQ0QYJBwSzNBgVdojdHtzz_9aWMrLPcRxiad0oupPw.kj9fh6A a40eN1ku_5gKBZwBZ.wu0PoA_3DPuodwXFEzzC7HwF1v3e6C6YdGUF_fxZsPMIzVwzHvo5s4fhSt MUSP4_c03A2A_DwpvSJ3Lm3O.GFrLu9IKZ3kDARFGiIS3K_klt.h0dDqmc6ZSgdpN7ceJh8puRnU 3tFh3j_LekvJMbYE89qfyDLQWUsDGZACRAK1F1D3a6xjRo05Cbezbrq0C4j2nIs4Vg80OlN3RvgJ ZD774lsNrUxL9eCvWLKmF0eUwYJUOPvEA98OSbzZlUr7_svEnuj7O4JpmsDUM1xzP3GMoGIa_QUu ApOQ4vjqIZhBqf0LE0ZfR.usfj0WBwjbyXSYayJAQWm88lIv8l3qHhgMQLxcsEuzVLXgn6kSCbwm pdYvicnft2kPOBwKwqGifkAM6j9EhF2qdwDIuaVUGQ_U_dpZE0nM9sg8iJOd748sa4qGP2.2G9vc RVqOKRDoCp.8ybuAtbyBKDFl50NnnVFcKfosOmp_yx0LTVeH3ONZwaZeEdQZKAWBNOPKU794bZZX VLUl.iicrpahM.hil7.OMA1s2NS5h5OaGd_GFcfOdyBgfVUBpTxzTxEs4ZzufiNxa4.GAK9Thpjz NzmaLbKK9ACMEi7Z.8Gw8i_6mgXENCul8PBHkSHrCLzN87LWP3XtkvM6ZEgd6hgf.wLDxVcvf.ZH KeEe9DvTt6zUCZSFwHb3ascRykrggN.CCUwP0E6QbqM1ZqhPWCTOKpgI.t1HJp8p4b_USkWk4wzK OKZv0KkTG1WuYFDT4qxm7zrtN8aEqGWOK4AwgFEnV4zlsiNkFv0fQR7yVHdTYKy8PW1tScou1WEq Oq3L4c.tXssDxk04WvusG9z2VzljGednE95HLaXuMW9byCRaGzAq91HyAL3YRQ0oRUDH7eNNrMtG 28BcZH.O4GE1O3tYAlbKqPQaNK_t1IgoPf2vf1dakVy43Gjb5NxhEZnuzScdZ6FjKLyBJ5TGceWi 7UABr0oJ7bh5.ofpsKimh7RbZLS9nD6hxHK4HqEXqt3pu3Qp3OIpeBfxgX5etzd3w5bpOf7z8PXX xNyMo2iqkXBFu3pN3N3oiL9jZLn.8DzZgWjyg_2z3Wu4HnaqLrjUEjtXMdhRabON5VyeeWrEeBoq VwdfFEgKnN8_ROnolurmX3mSMotMVZLlmtTQ9WGcxvJSy35a5DJY89kfBkZ2Sijf.JpjqCM3CPaA HNyknbUmXzWLKCbqJ0D_Ompkvys8l3wZZ_C86zttP9CU7RYRQgnZ99VoseqFahzgZz6oL7iA_AIu cpaWTRHoiarKet7pXfC7fEyab3n2uUYBw57rIRyb0.SaRaUdChGrzDywtbQkXVcPeTAQUD0wRaFf xX9rPoYzJVtxZuBRSTUxrsQ0CpDAU5GHzupwBRlwAscNV_k5CycIM8NHruCEAJ2yY9LwwDn58CXr wdzRMihP43jATsCX2jrq1gsDec2LDk.JCM7xlYyEgpEyHzNcH5eCl7ggbiK9Ki8O21gbcbqG4w70 1jFdjqWZFq7O2i52Zla_eI3a.RtNVpHOey1b4jctwRBEqKglnEg8V90j0uSbGtQJ.yLDDAlSdFm. fOQpe3Q-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Fri, 19 Nov 2021 00:04:03 +0000 Received: by kubenode532.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 7fb46a754a8c19e1f3fa1ed36f831100; Fri, 19 Nov 2021 00:04:01 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: FYI: amd64 system: "error: fileid changed. fsid 0:0: expected fileid 0xa, got 0x2. (BROKEN NFS SERVER OR MIDDLEWARE)"? Date: Thu, 18 Nov 2021 16:04:00 -0800 References: To: freebsd-current In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4HwH2f2qwvz3Cmj X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b="gRVi0/m1"; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-0.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; SUBJECT_ENDS_QUESTION(1.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.206:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.206:from]; RCVD_COUNT_TWO(0.00)[2] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-current X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Nov-18, at 15:54, Mark Millard wrote: > The ThreadRipper 1950X FreeBSD system is reporting a message at > 03:01:10 or so for the last 3 days. The .148 is a aarch64 system > (HoneyComb). None of the other systems (aarch64 Small Board > Computers and a armv7 SBC) are reporting such. >=20 > Nov 16 03:01:10 amd64_ZFS kernel: newnfs: server '192.168.1.148' = error: fileid changed. fsid 0:0: expected fileid 0xa, got 0x2. (BROKEN = NFS SERVER OR MIDDLEWARE) > Nov 17 03:01:10 amd64_ZFS kernel: newnfs: server '192.168.1.148' = error: fileid changed. fsid 0:0: expected fileid 0xa, got 0x2. (BROKEN = NFS SERVER OR MIDDLEWARE) > Nov 18 03:01:09 amd64_ZFS kernel: newnfs: server '192.168.1.148' = error: fileid changed. fsid 0:0: expected fileid 0xa, got 0x2. (BROKEN = NFS SERVER OR MIDDLEWARE) >=20 > # uname -apKU > FreeBSD amd64_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #10 = main-n250667-20aa359773be-dirty: Sun Nov 14 00:24:51 PST 2021 = root@amd64_ZFS:/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.a= md64/sys/GENERIC-NODBG amd64 amd64 1400042 1400042 >=20 > The .148 : >=20 > # uname -apKU > FreeBSD HC_CA72_UFS 14.0-CURRENT FreeBSD 14.0-CURRENT #19 = main-n250667-20aa359773be-dirty: Sun Nov 14 02:57:32 PST 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400042 1400042 >=20 > (At times it is booted from a root-on-zfs media or a USB3 SSD UFS = media > instead but it is the same system build that is running for all = those.) >=20 For reference: I forgot to mention that the other aarch systems are running: # uname -apKU FreeBSD FBSDmacch 14.0-CURRENT FreeBSD 14.0-CURRENT #18 = main-n250455-890cae197737-dirty: Thu Nov 4 13:43:17 PDT 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400040 1400040 (all installed from the same build, so the example is sufficient). The armv7 system is running: # uname -apKU FreeBSD OPiP2E_RPi2v11 14.0-CURRENT FreeBSD 14.0-CURRENT #14 = main-n250455-890cae197737-dirty: Thu Nov 4 16:13:56 PDT 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA7-nodbg-clang/usr/main-src/arm.a= rmv7/sys/GENERIC-NODBG-CA7 arm armv7 1400040 1400040 (At some point they will all be updated.) This vintage difference might be part of why they do not report anything. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Fri Nov 19 10:30:08 2021 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 75E1318942E1 for ; Fri, 19 Nov 2021 10:30:21 +0000 (UTC) (envelope-from filippomore@yahoo.com) Received: from sonic304-20.consmr.mail.ne1.yahoo.com (sonic304-20.consmr.mail.ne1.yahoo.com [66.163.191.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HwXx83ZD7z4XWp for ; Fri, 19 Nov 2021 10:30:20 +0000 (UTC) (envelope-from filippomore@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637317813; bh=6KxiuowqVuJR+RQsdEqBGangV7ioaZXOfXDvvFRc078=; h=Date:From:To:Subject:References:From:Subject:Reply-To; b=byEyMrgZFfYHVvUwj63O9zJVK7spHLRcC8D0xZrwsTGay4KX3EYNtJ+JvuKztc0mBZo3uaLGxav8jIrKysSKZnh3bYSdtHmlq0Brp8dOYaxKcwC8FfSpSnr2ewl30zEZ9Aje2dQh9NxOYLBz0SbdHgg0lZeIBHvi7M6fupb5gEOhlTryOyGGKJTKNbBpegOgI9GZrAdQgDmvQ1pvzgYMNAB3QNSMnn1nbJ1CbWbH5NPs4r3mAmIzH+4QKMH9hwIT8xkiJPT38lU2+d3BXABIdoHML12AwBRMKIxkXTzW8saDfSvDX8etIWDEmU1zmllOXMcREcan0Ye2VBQPnEKT8w== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637317813; bh=dnUp24yM0H56eYlzv3y+3Ff+XeHQ8KIeDPYrbDaazW0=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=g9rjaTwgq7sobRqHheCzvYUTpCTVoQKzkRYHSm52G9+JCCeER70sJapFdOI3E7G/SeGtssmuCyxzg/elPhfc5IcLgWCQNG6S1wb5ZeSU3DrNdINlyKwa1Sd6ciYN7G6wB7ux0NO5BzSGh1cv7FdxAepn6zFQ6dDFdm6q08R4VlcHEX+6wCjO69m3WYS3mggdwG5Ld9AvlRO+VPFA+YfOqOIDIHDsXUE8UuuDgAY7dD5BUtjgz3iEn1WVyF+rJC8yl0I68VLnMwz6+TU6uyfUO4QYHimD4GHhpZDz1D1UsYtCkxrh1XpfVdn7D5nHJOd9LotDYFISFU6X1cgjcQGVfA== X-YMail-OSG: ACmuaJcVM1mho.Pr7ksIQhQ2vFml8ErypyIHA9bEbac5N2P7Cq4rq5eh9cBYlcH ZUKHJ_68_ahOsleVDOAc4t962a9MmBbPE2Hz.lsnKxiyFMIMr5ZBRAtYThMeE5S4umWoSm65ssZ2 EtwoqMzBENX04V6mvNellzN1.NvtPohQYcDIYt2CIotcTnRhVal0SvnhtYsrSP7Cu66.wNCnqOeV 4Ytcfomr2FIZsGgk2GpL8zlm2pFujat7EztNUUs30bLLjhFIJ2HadmNzWZNPDs36ezpMR2ZhemAI eKVtWHLnsbmKxMq8C5ddTLkMutmnWuaE2GHpseZm7qzhgRiynEkkN6zjaBlLIgb_M.iO1OHZz6Ge r3SKwIXNNiW0I4JbSKEPFEZuh1o.WGVpv5OgXxNVOjf7r7_WxxYfqy_aJNepGF06YAsUhT0xPUvV NJusUlcSF6AWSBLxP7twWAFn07rNrChKJiyLzyroHPEkMRF12BxrumnQ.7A0ezC3wICTq2yD9IJn F207GbVPD19s89ummVwDJ5ioewXTfqSR5lvU7SCVh22Ik9tCmE76Ny3.wZ6WBH9WuyNkRUNtqsfi XMZRc464AMBT1NtcvB_Ayrv7pU22k4SwNfYHbeh6KjD0gnXLX6eTHxjRG9ksivZR2IerW2srx2RD FALlJgCzPgF_O5QqQMF_1PDlSQA5STrDjFPnnmvrIg7Hx8IXi30cZcFXfZRRmpYOXL80wDvURufs RsiHwt.2aCzYNPBzuSnJfR9CNNQMIs.4Ivk5m8DYidFnVAGcz5xOG9ZV1BEE9CUL3zlag7oQW6OM LjxplczHq6MEyxLs.ioFlnbcVRxvlIOu1wWsQK6UDgsQF7ySHt43GzRzPyqjEo3e8Ko2toYShoM5 iWNE5wP8gBb9f5_7Nx8G.5nCgxoEN..IyyO4GjQ7fSoM_9lUP3nl2g4fKV2JDUcU3tVxJQygCaQh _ejcP74cfCrn4OE.kLTQZ39Qac0xhH4U3hxnCcGwoXrj7n1W2_YibYyckU49poOaXzD56lpuyidX eL6IweNh2rn2oVaDy0YXJHfI1e5LoBAYcyJJuXNFc09trPvPDLuQYnVVl15ZpIdkpSL7vS59WSyC QlymoSIaLwBTkWasucnp3JvMYSJiS3KvhIbKYRUbCJmyZ2nRPSVfRAEcUgrl6a1X9wheFpNj.rcy lqIKKaePePT2yCwHeBdivzMT8PJSfFvw5IVkXGFN1RF1jJtHa7h8tioBKFYGd22nteLO7ux9bdUS b2B5f05hDNrt9AcCHKCBRHgdNR4knkIOsMM2jJfyGALwpUOwg1l74sNY0lvCCnvz_GVCUL.jHWby s9.npGP5ozim2JwhYBnlyGWByIVcpXlxDwOkGPti1l0MyP21JRAZWx2MC20FGJbj661pz3Q3W0Tc esKaUF2FrMSNg5DMRCNSUvFG2zjSeMX3NUj656doI7CSMeHk_iQv7Txm9ZEwpYsjhK7Odf_J18OL lkrcu2LCFSjjAovbD03Fqb2ck_pQs2IdgEW3yhhMOoCYMu46Ubg7UM7fCMss8HJXZOpdy0laSQiL gqsM2mKv3Xde9wHvxGe82mnv996HvPPiKJVMve6s2dA2brWF1IPbjauRVne5BPZcBY.VV2uUDz89 vXVyHeeSk8yDqTys5bkg4_eGgnE7SBzygSKHQJPhSsOOkdkf1wFkwvajSpGzkM0_411N7t64pd0q E10jjLS5.v09EgdJX9PDxGrUylPgoB1xpwlQt8UX2yX5GK7tnnrQ7CM1SZpL52bJobAnfdazuyCh B_uzsp3S4n_Fr9Fsn_NlzHXtuJKf7SkovCv_l9LQdbvBnUzyCIzrFI.52DLW4AVPPJ0shjej4rtO eZUKIYXTfdza5jcBayZo3pFKrZ5GM79JI8Zu3GVZiwtC42GHnLX.MZNSmvGx5kFcVekSdL.g8h.. DTq_7mTo1bkEgRNZiuLXX9S60ronannT8PufivpvTF1rym9BqO8orTiPAb2ZoO_sKmRzTfFUve57 eIegZq_bGy9uSexpscrOgbktfkQGxaXSJ5IZLrj1BdaaaWEisyjQRH7c5DzZTomBcNDONrrWoR33 RbQJCcWbWzKw4COeGo4nclcB3yzl7F2plUh0qfwcEI_Q.uYKppUApnJVRTdpBEv8YZ4p6Amy0PbB Rnok32GWhe5xNxd1Z.vXtJ69izaLf.ccCpOqU6yB3Iosc8YJUNHP.yQ-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.ne1.yahoo.com with HTTP; Fri, 19 Nov 2021 10:30:13 +0000 Date: Fri, 19 Nov 2021 10:30:08 +0000 (UTC) To: FreeBSD Current Message-ID: <1899088412.3452349.1637317808845@mail.yahoo.com> Subject: Problem with newer version of firefox List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3452348_1443414909.1637317808844" References: <1899088412.3452349.1637317808845.ref@mail.yahoo.com> X-Mailer: WebService/1.1.19306 YMailNorrin X-Rspamd-Queue-Id: 4HwXx83ZD7z4XWp X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=byEyMrgZ; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of filippomore@yahoo.com designates 66.163.191.146 as permitted sender) smtp.mailfrom=filippomore@yahoo.com X-Spamd-Result: default: False [-2.00 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; RWL_MAILSPIKE_POSSIBLE(0.00)[66.163.191.146:from]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCVD_IN_DNSWL_NONE(0.00)[66.163.191.146:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36646, ipnet:66.163.184.0/21, country:US]; RCVD_COUNT_TWO(0.00)[2]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] Reply-To: filippomore@yahoo.com From: Filippo Moretti via current X-Original-From: Filippo Moretti X-ThisMailContainsUnwantedMimeParts: Y ------=_Part_3452348_1443414909.1637317808844 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Good morning,=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0after upgrading firefox I get the following error:XPCOMGlueLo= ad error for file /usr/local/lib/firefox/libxul.so:Shared object "libmozsql= ite3.so" not found, required by "libxul.so"Couldn't load XPCOM. it is present in the directory /usr/local/lib/firefox/libmozsqlite3.soI the= n symlinked the above to /usr/local/lib and got this error:XPCOMGlueLoad er= ror for file /usr/local/lib/firefox/libxul.so:/usr/local/lib/firefox/libmoz= sqlite3.so: version libmozsqlite3.so required by /usr/local/lib/firefox/lib= xul.so not defined=C2=A0FreeBSD sting 14.0-CURRENT FreeBSD 14.0-CURRENT #61= heads/main-n250837-5085153ae4d: Thu Nov 18 21:57:09 CET 2021=C2=A0 =C2=A0 = =C2=A0filippo@sting:/usr/obj/usr/src/amd64.amd64/sys/STING=C2=A0 amd64 Any help appreciatedsincerelyFilippo ------=_Part_3452348_1443414909.1637317808844-- From nobody Fri Nov 19 12:29:14 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 169ED18551BE for ; Fri, 19 Nov 2021 12:29:25 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.franken.de", Issuer "Sectigo RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HwbZX6L0Lz3Nyt for ; Fri, 19 Nov 2021 12:29:24 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from smtpclient.apple (unknown [IPv6:2a02:8109:1140:c3d:b4da:1c50:71cc:9345]) (Authenticated sender: macmic) by drew.franken.de (Postfix) with ESMTPSA id 239EC721E280A; Fri, 19 Nov 2021 13:29:15 +0100 (CET) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.32\)) Subject: Re: "Khelp module "ertt" can't unload until its refcount drops from 1 to 0." after "All buffers synced."? From: tuexen@freebsd.org In-Reply-To: Date: Fri, 19 Nov 2021 13:29:14 +0100 Cc: freebsd-current Content-Transfer-Encoding: quoted-printable Message-Id: <3A646420-0FB9-4C58-BA97-EE1040958B6E@freebsd.org> References: <119DC979-EC2C-4BE4-A6E8-2DBF222115A0.ref@yahoo.com> <119DC979-EC2C-4BE4-A6E8-2DBF222115A0@yahoo.com> <52374B7E-6ABB-4E55-984C-B7EC82B48506@freebsd.org> To: Mark Millard X-Mailer: Apple Mail (2.3693.20.0.1.32) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail-n.franken.de X-Rspamd-Queue-Id: 4HwbZX6L0Lz3Nyt X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N > On 19. Nov 2021, at 00:11, Mark Millard wrote: >=20 >> On 2021-Nov-18, at 12:31, tuexen@freebsd.org = wrote: >>=20 >>> On 17. Nov 2021, at 21:13, Mark Millard via freebsd-current = wrote: >>>=20 >>> I've not noticed the ertt message before in: >>>=20 >>> . . . >>> Waiting (max 60 seconds) for system thread `bufspacedaemon-1' to = stop... done >>> All buffers synced. >>> Uptime: 1d9h57m18s >>> Khelp module "ertt" can't unload until its refcount drops from 1 to = 0. >> Hi Mark, >>=20 >> what kernel configuration are you using? What kernel modules are = loaded? >=20 > The shutdown was of my ZFS boot media but the machine is > currently doing builds on the UFS media. (The ZFS media is > present but not mounted). For now I provide information > from the booted UFS system. The UFS context is intended > to be nearly a copy of the brctl selection for main [so: 14] > from the ZFS media. Both systems have been doing the same > poudriere builds for various comparison/contrast purposes. > The current build activity will likely take 16+ hrs. Hi Mark, thanks a lot for the information. I was contemplating whether this = message was related to a recent change in the TCP congestion module handling, = but since it was already there in February, this is not the case. Will try = to reproduce this, but wasn't able up to now. Best regards Michael >=20 > For reference for now (from UFS context): >=20 > # uname -apKU > FreeBSD HC_CA72_UFS 14.0-CURRENT FreeBSD 14.0-CURRENT #19 = main-n250667-20aa359773be-dirty: Sun Nov 14 02:57:32 PST 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400042 1400042 >=20 > This environment was built with -mcpu=3Dcortex-a72 in use and the > system is a 16 core Cortex-A72 system. (I've caught a FreeBSD > weak memory model error in the past with such -mcpu=3Dcortext-a72 > use on a Cortext-A72 system, not that I have evidence of such > here.) >=20 > # kldstat > Id Refs Address Size Name > 1 18 0xffff000000000000 12b1660 kernel > 2 1 0xffff0000012b2000 41e070 zfs.ko > 3 1 0xffff0000016d1000 26af8 cryptodev.ko > 4 1 0xffff00019a400000 27000 nullfs.ko > 5 1 0xffff00019a427000 25000 fdescfs.ko >=20 > # more /usr/main-src/sys/arm64/conf/GENERIC-NODBG-CA72 > include "GENERIC-NODBG" >=20 > ident GENERIC-NODBG-CA72 >=20 > makeoptions CONF_CFLAGS=3D"-mcpu=3Dcortex-a72" >=20 > # more /usr/main-src/sys/arm64/conf/GENERIC-NODBG > # > # GENERIC -- Custom configuration for the arm64/aarch64 > # >=20 > include "GENERIC" >=20 > ident GENERIC-NODBG >=20 > makeoptions DEBUG=3D-g # Build kernel with gdb(1) = debug symbols >=20 > options ALT_BREAK_TO_DEBUGGER >=20 > options KDB # Enable kernel debugger = support >=20 > # For minimum debugger support (stable branch) use: > #options KDB_TRACE # Print a stack trace for a = panic > options DDB # Enable the kernel debugger >=20 > # Extra stuff: > #options VERBOSE_SYSINIT=3D0 # Enable verbose sysinit = messages > #options BOOTVERBOSE=3D1 > #options BOOTHOWTO=3DRB_VERBOSE > #options KTR > #options KTR_MASK=3DKTR_TRAP > ##options KTR_CPUMASK=3D0xF > #options KTR_VERBOSE >=20 > # Disable any extra checking for. . . > nooptions DEADLKRES # Enable the deadlock resolver > nooptions INVARIANTS # Enable calls of extra sanity = checking > nooptions INVARIANT_SUPPORT # Extra sanity checks of = internal structures, required by INVARIANTS > nooptions WITNESS # Enable checks to detect = deadlocks and cycles > nooptions WITNESS_SKIPSPIN # Don't run witness on = spinlocks for speed > nooptions DIAGNOSTIC > nooptions MALLOC_DEBUG_MAXZONES # Separate malloc(9) zones > nooptions BUF_TRACKING > nooptions FULL_BUF_TRACKING >=20 >=20 > The builds do include a bulk for targeting armv7 > (so 32-bit compatibility) but that bulk has not > started yet in the UFS context. >=20 > # poudriere jail -jmain-CA7 -i > Jail name: main-CA7 > Jail version: 14.0-CURRENT > Jail arch: arm.armv7 > Jail method: null > Jail mount: /usr/obj/DESTDIRs/main-CA7-poud > Jail fs: =20 > Jail updated: 2021-11-16 02:24:57 > Jail pkgbase: disabled >=20 > My networking context is simple context does not provide > services outside the local network. The services are normal > ones, such as nfs, ssh, and whatever default things. ntpd > is in use. distfiles are downloaded during builds. It is not > a desktop environment, not even a video card. >=20 > I've noticed a 2021-Feb-22 report in: >=20 > = https://forums.freebsd.org/threads/whats-the-error-khelp-module-ertt-unloa= d.79009/ >=20 > so getting the message does not appear to be unique to my > context. >=20 > =3D=3D=3D > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) >=20 From nobody Fri Nov 19 19:08:58 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 650EA189B80C for ; Fri, 19 Nov 2021 19:09:12 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-25.consmr.mail.gq1.yahoo.com (sonic303-25.consmr.mail.gq1.yahoo.com [98.137.64.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HwmRq2mC2z4TgV for ; Fri, 19 Nov 2021 19:09:11 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637348944; bh=ZX56WDd7s6jeiBDTC+SliUAk7IvT7xrwfdKnybIRJJM=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=cAWfoKRE8Z6sFEP/lZ5Gf97BbuLxx2xMiClPiNSa1OGoEWttI3lvfKQMxAIzvaHVpIgdt59vkIWQfY7405jMz9p4BEXCCrp5HpXm7/vYO8DEgOLoVAev+9RogBxDhM5u3OdXGZg4sdqkaYF1ooD6FOo6qpNimNQ0tgGH24ONEmQX8dCL94X7rSfAxsHQWIv56vpAfRyImw91DK4sPGxaBRMHnDvjh6SMoGjl7I0o+lao/emA2C1n7HS4J0yvpIQ/FdLml308RV28FuziXq5VCn61lsmaXmy8JZjHNoDgvUvq5pCuBtlDmqyFmCuo4N/udwJr9w89TRNnY/u/EhHy/A== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637348944; bh=dyWk6NdDPc3jNa5AzTAfQ8bwePOING0VJMZxFJSAzY4=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=Oey1fsHlF1V8Kkpwjyw7+gtxlvC3OOspUKjuy0+LWWlZXkcPs0kk5yZ0uGhDPqUsd4PbCAcMrwZM6KN2zEgXtXuTApQAyD8gKL8eAjyAInYBPWTUNcjaZujoh9BQb0/+IXzScSrhDGaWbSLyDlMUuwpyzk6ixaR9F7pheWU3PaqRFgZ0QS9RP97WK+Y6Gpbw6FqrpSfa2a3MISJJ1O+5CVPo+voOXRNj8OFgmkgDiKR+0wbHqeTVExY1k1Z8/qfKtmWb155qM52MsFEE0n8rwy77pb5NxKkS4vwwUSZwtGmw1reGPaWnvEq1sNCVyDw4iWgQz86+HU+Xl/NVSa1wVw== X-YMail-OSG: XBkgwVoVM1lMn8vgaRH3TZMrb1LHNgnYC1FN3sfqrz2mG_6UQ3Caxpue.C4byoz WxHUxhPaJgw05UPp9CoAgTKQqap543hxy3Y8wj6FZF.yucxyb_SWaExhYNbTwg1jK2ImqBWD2jVy 341lp5uIjsoKMDt5S6Et.hbpVhKrhnEUmZrg4Rult2JABu3jKaDfnJllkx862GPLfdw2Lv2AjwG_ dzmhJcXbTsqo0Wzi3KEpGWVsCsliokC0dP38I.swNLuAtnBiaIDm1J7Z3d.fglAkRD1VrHuwH7hV O_0vNi0z38WN1vrAgXZFZWrdnZEZ7teqY3GlfoLT7xxLilv_V1G1Ez9hmleEJnN7r6RvuAOL177w 2BDdEuluJhxKNj8T0mNRJitaijBbQzTO5Sd0lkqV0tWFAQU8HVMGQ8mlgkEmuylAvibL5g.FTf2j ltiAJa72bsW.1B0oUQwKmeL9mO12EUxVjyDHIKWdz2.LRSghci52PzmOXevP8zswAEO1HRx3T7R5 WvPsY0dysroUJcGtomvLFZskZd4HVpXZ8Doffm0r4SIoNSG5sZBjaAhHMd6mfpdS4RDQdkehVRk0 S7SBRk.86DCUtlBjAoOp1hacrBlWnNnNcTWV4sD0nG0YNs4.CNoi4OsGBjNA1rIEXFuuTKFN1jFp 1juJpbwkjRjbdM7U7Hv6SRiHHcKdBYX01EjtHra0_.kQytMTda6fVeJ0BBrBRXbLnutgIFM1glQe eOyPleCQxcXM4nrhb2oDrPEiDtwV9Je6.mexAIFvUWiVTXKx5FirpQyNPHpiAdJa_9u1tGAxf3D5 TpPp24uj12N77V375wQrLm6ETnPk.jBaRsc4sMkvaoRFP8dEJl9Npq20zMNgeu9yY4r3m0Ha2l0U 54jVWlBHG1o5dhk9P_U_CUY6lud7P33GsbtSyxvAm_nTqwlTg_c9u0f_J_iJXjYOoDicu5Tzpk51 E.GL6TTfSXSwY17Waudzbl8hwKq7flOVy6MsO6mg7y5vm4QaO2Ig.caiSnoEh.ZenWeIDwXb3G0S 2f5LIDPEC2_j_u0Ia0SQBH__7ljMslpdQydphT0hcPQ0IAoue9jXtZmn1O23KEuAu9MwtMQEt9cJ FACH1Tv6hbcfwezh2G7G3CuGIR1.F5eLiTtOTzJFhoU1.AzP4WtxYkqRlesBNLdJkiqYCL2Bsksa 8DCIgtB2wxaHwK0FiUjoJtFveKlzWOA7z7KAs2A2CwoYq4lA5nTOy1va7rqUB_pGyaoGrRVroydA 4LfnxBgj2bAs2uBjPtm7ptDBvAkVm5ItlNhpLuON7g_dWmjweMGx6TNKWxgeHKMXM3rmQox5KyM. K3OCgu_dp96E2_P5mLeXRuMpuRUPi9wzsexOYuR3FJp5sTv1R.YTEPdtkanxVRT7c8usF4x1hfv9 8w4TB5PB8wtXbPYb_vzQwmSKVhYvwJ2vAlEBA5IcrDqaTrbgm6wqIwTJAZh6uBsJ22UapTUhmU2j AXcwuT.FcBrf.CCpaHVYzT.jSD3KyyHqrIfQ04bfCFF7FTHqu6Mw5xvTN0ZokSiP2zpK8b7_Ok8_ WqUBfOaBM_EOj9cZnV4SqkR1e6.dtMituHzdtjEUwzBLtbZOjKgxrRuzjal5HE03pwOmbkMzPheU oGUOD.w8fxm3.kwwOEPSLpfVeTJb0XkXmD.qQBLaLXK51NPTl47emMZR8dk8a_s79A1y_HOxBhtE 6F0zsAxhVrniB6TPoZG.j_ohas7ZnGlGe5X5EoouyzziJBVPHgYdPVUEJW62zGr.ztHDaNrRXohm Am4vPc5SdcpBfPpBXdFqqQ4xW675uwetY4MlmBLF5HzhlU0vpOJCf.HdyVz7PmT1GzNWq9dDdQqE 17lumISEcM_NNpQ5sc3R7Lol9oPvadR702I8EKr_tMK.ta37Q4RTdmu1KbYIDyptagkLRtmpAxd_ ZPGBJYALVPLQFHHpmV0k6rPjNPEIHumSNu1NdSePDuEwa_bZmNT2mC6zrzIpswJqjXKrLg80tDqe QLOYGfO.mcO4IU3eEaWDpwNIeTQ5480KTienNKpBX2xS11rf54m8oolF0o6cDTG6y0Eqxu2FoMqT JJDFeG9Y8jzIHa_SPvnaYQLAQUipBX8NFnToNHSqF6x9anSAK11KQNzPHxSs4wBZ0M6jL4dZ4cFz HB_Yf1K0ozT9rJvlvjiavZvTWdWr_2OcfdeNSgJOoC1vq4dt.nYZDM9K5w40i2j1MThbm7it9Q1d IwlESmrRgpNaB8EIbt71S7E3oRntLp_Ype.PozeKojn52Xl0oiCy3Q8j01WYv1m1bMc4xeLxEyFc X.sRKJv6YpaU6mjbuKVJg5VM- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Fri, 19 Nov 2021 19:09:04 +0000 Received: by kubenode527.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 90d826abde6eeb10822a09d541675b1a; Fri, 19 Nov 2021 19:09:02 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: FYI: aarch64 main [so: 14] system hung up with a large amount of memory in use (given the RAM+SWAP configuration) but lots of swap left Date: Fri, 19 Nov 2021 11:08:58 -0800 References: <50D9DD1F-6949-412B-AE86-46E6F0129E8B@yahoo.com> To: freebsd-current , "freebsd-arm@freebsd.org" In-Reply-To: <50D9DD1F-6949-412B-AE86-46E6F0129E8B@yahoo.com> Message-Id: X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4HwmRq2mC2z4TgV X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=cAWfoKRE; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.206:from]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.206:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-current X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Nov-13, at 03:40, Mark Millard wrote: > On 2021-Nov-13, at 03:20, Mark Millard wrote: >=20 >=20 >> While attempting to see if I could repeat a bugzilla report in a >> somewhat different context, I has the system hang up to the >> point that ^C and ^Z did not work and ^T did not echo out what >> would be expected for poudriere (or even the kernel backtrace). >> I was able to escape to ddb. >>=20 >> The context was Cortex-A72 based aarch64 system using: >>=20 >> # poudriere jail -jmain-CA7 -i >> Jail name: main-CA7 >> Jail version: 14.0-CURRENT >> Jail arch: arm.armv7 >> Jail method: null >> Jail mount: /usr/obj/DESTDIRs/main-CA7-poud >> Jail fs: =20 >> Jail updated: 2021-06-27 17:58:33 >> Jail pkgbase: disabled >>=20 >> # uname -apKU >> FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #18 = main-n250455-890cae197737-dirty: Thu Nov 4 13:43:17 PDT 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400040 1400040 >>=20 >> It is a non-debug build (but with symbols). >>=20 >> 16 cortex-A72 cores, 64 GiBytes RAM, root on ZFS, 251904Mi swap, >> USE_TMPFS=3Dall in use. ALLOW_PARALLEL_JOBS=3D in use too. >> (Mentioned only for context: I've no specific evidence if other >> contexts would also have failed, say, USE+TMPFS=3D"data" or UFS.) Of course not a "+": USE_TMPFS=3D"data" >> When I looked around at the db> prompts I noticed one >> oddity (I'm no expert at such inspections): >>=20 >> db> show allchains >> . . . >> chain 92: >> thread 100671 (pid 15928, make) is blocked on lockmgr 0%A%0EXCL >> thread 100671 (pid 15928, make) is blocked on lockmgr 0%A%0EXCL >> thread 100671 (pid 15928, make) is blocked on lockmgr 0%A%0EXCL >> thread 100671 (pid 15928, make) is blocked on lockmgr 0%A%0EXCL >> thread 100671 (pid 15928, make) is blocked on lockmgr 0%A%0EXCL >> thread 100671 (pid 15928, make) is blocked on lockmgr 0%A%0EXCL >> . . . (thousands of more instances of that line content, >> I never found the last) . . . >>=20 >> My patched top (that reports some "maximum observed" (MaxObs???) >> figures) was showing (having hung up with the system): >>=20 >> last pid: 18816; load averages: 10.11, 16.76, 18.73 MaxObs: 115.65, = 103.13, 96.36 = up 8+06:52:04 20:30:57 >> 324 threads: 17 running, 305 sleeping, 2 waiting, 147 MaxObsRunning >> CPU: 2.8% user, 0.0% nice, 97.1% system, 0.0% interrupt, 0.0% = idle >> Mem: 19044Ki Active, 331776B Inact, 73728B Laundry, 6950Mi Wired, = 69632B Buf, 558860Ki Free, 47709Mi MaxObsActive, 12556Mi MaxObsWired, = 59622Mi MaxObs(Act+Wir+Lndry) >> ARC: 2005Mi Total, 623319Ki MFU, 654020Ki MRU, 2048Ki Anon, 27462Ki = Header, 745685Ki Other >> 783741Ki Compressed, 3981Mi Uncompressed, 5.20:1 Ratio >> Swap: 251904Mi Total, 101719Mi Used, 150185Mi Free, 40% Inuse, 3432Ki = In, 3064Ki Out, 101719Mi MaxObsUsed, 101737Mi = MaxObs(Act+Lndry+SwapUsed), 109816Mi MaxObs(Act+Wir+Lndry+SwapUsed) >>=20 >> (Based on the 20:30:57 time shown, it had been hung up for over >> 2 hours when I got to it.) >>=20 >> There were no console messages. /var/log/messages had its >> last message at 18:57:52. No out-of-swap or such >> messages. >>=20 >>=20 >> I did get a dump via the db> prompt. >>=20 >=20 > In retrying the poudriere-devel run expiriment I'm > getting various builds that are generating > multi-GiByte log files (and growing) that have > lines like: >=20 > thread 'rustc' panicked at 'capacity overflow', = library/alloc/src/raw_vec.rs:559:5 > stack backtrace: > note: Some details are omitted, run with `RUST_BACKTRACE=3Dfull` for a = verbose backtrace. >=20 > error: internal compiler error: unexpected panic >=20 > note: the compiler unexpectedly panicked. this is a bug. >=20 > note: we would appreciate a bug report:=20 > = https://github.com/rust-lang/rust/issues/new?labels=3DC-bug%2C+I-ICE%2C+T-= compiler&template=3Dice.md >=20 >=20 > note: rustc 1.55.0 running on armv7-unknown-freebsd >=20 > note: compiler flags: -C embed-bitcode=3Dno -C debuginfo=3D2 -C = linker=3Dcc --crate-type lib >=20 > note: some of the compiler flags provided by cargo are hidden >=20 > query stack during panic: > #0 [trimmed_def_paths] calculating trimmed def paths > #1 [lint_mod] linting module `transitions` > #2 [analysis] running analysis passes on this crate > end of query stack > thread 'rustc' panicked at 'cannot panic during the backtrace = function', library/std/src/../../backtrace/src/lib.rs:147:13 > stack backtrace: > 0: 0x4710076c - = ::fmt::h4428caffcb182c5b > 1: 0x471c9d00 - core::fmt::write::h91f4a7678561fd61 > 2: 0x470e2180 - > 3: 0x470ebd40 - > 4: 0x470eb824 - > 5: 0x41ed4848 - > 6: 0x470ec690 - = std::panicking::rust_panic_with_hook::h6bc4b7e83060df25 > 7: 0x47100f0c - > 8: 0x47100900 - > 9: 0x470ec374 - > . . . > 65: 0x470ee71c - > 66: 0x401361bc - > 67: 0x40135cd8 - pthread_create > 68: 0x40138b9c - pthread_peekjoin_np > 69: 0x40138b9c - pthread_peekjoin_np > 70: 0x40138b9c - pthread_peekjoin_np > 71: 0x40138b9c - pthread_peekjoin_np > 72: 0x40138b9c - pthread_peekjoin_np > 73: 0x40138b9c - pthread_peekjoin_np > . . . massive repitition of pthread_peekjoin_np lines . . . >=20 > (I used USE_TMPFS=3D"data" to avoid tmpfs memory usage this > time.) >=20 In trying stress tests such as: # stress --vm 16 --vm-bytes 16G --vm-stride 4096 --vm-hang 30 I've not reproduced a hang under root-on-ZFS (or root-on-UFS). Using USE_TMPFS=3D"data" in poudriere has not produced the hangup in any bulk rebuild runs. (I eventually have to stop such bulk run because of the indefinitely growing files.) These, with the earlier, suggest that the tmpfs use via USE_TMPFS=3Dall in poudriere contributes to the hangup condition involved, as does the indefinitely growing files in various tmpfs instances for various builders. Side notes: Luckily, with the Optane PCIe orOptane U.2-via-M.2-adapter based media, USE_TMPFS=3Dall is only a little faster than USE_TMPFS=3D"data" for the bulk builds. Example from UFS context test results that happen to be handy: # poudriere status -a =3D>> Warning: Looking up all matching builds. This may take a while. SET PORTS JAIL BUILD STATUS QUEUE BUILT FAIL SKIP = IGNORE FETCH REMAIN TIME LOGS . . . - default 13_0R-CA72 2021-11-17_17h29m50s done 485 481 4 0 = 0 0 0 06:07:05 = /usr/local/poudriere/data/logs/bulk/13_0R-CA72-default/2021-11-17_17h29m50= s - default 13_0R-CA72 2021-11-18_12h42m09s done 485 481 4 0 = 0 0 0 06:02:27 = /usr/local/poudriere/data/logs/bulk/13_0R-CA72-default/2021-11-18_12h42m09= s . . . Using a portable USB3 SSD media with USE_TMPFS=3D"data" took noticeably = longer: - default 13_0R-CA72 2021-11-16_02h28m29s done 485 481 4 0 = 0 0 0 07:55:25 = /usr/local/poudriere/data/logs/bulk/13_0R-CA72-default/2021-11-16_02h28m29= s These bulk runs do not involve the indefinitely growing files. Much of the time goes into gcc11, llvm12, llvm13, and rust builds, for = example. The builds use ALLOW_PARALLEL_JOBS=3D and had 16 builders, so maximum = observed load averages (via my personal variation of top): USB3 SSD USE_TMPFS=3D"data" test: last pid: . . .; load averages: . . . MaxObs: 124.65, 106.26, 90.03 Optane USE_TMPFS=3D"data" test: last pid: . . .; load averages: . . . MaxObs: 99.60, 84.64, 78.15 Optane USE_TMPFS=3Dall test: last pid: . . .; load averages: . . . MaxObs: 113.79, 97.04, 84.88 The context is a 16 Cortex-A72 HoneyComb system, 64 GiBytes of RAM. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Fri Nov 19 23:52:56 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9A38818A0F6B for ; Fri, 19 Nov 2021 23:53:10 +0000 (UTC) (envelope-from dmarquess@gmail.com) Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HwtlT5cSXz3HLM; Fri, 19 Nov 2021 23:53:09 +0000 (UTC) (envelope-from dmarquess@gmail.com) Received: by mail-ed1-x52f.google.com with SMTP id z5so49214092edd.3; Fri, 19 Nov 2021 15:53:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=yF4fvZKaBQU6kTZ587qjwwFJjQtuURlTBp8CmjQzUes=; b=eVVbtLt9n2xkhBNDZGec02AjXQ0I+oInFAwmNhHjNTmJKRZ0U/dXmgGcSUnkS+EBjb tC/UplXaDX5i2NmJyVX63cmw51NNChEE2kgCrBYSTmYBwPEH++bgeGMG4EN4IGkpR5BJ rbRx9bodtSjTjtiHebUp4P63UB7h4y+N5RiEqB8edOLwNzckk6K7ODuV0J9x3LxKFUG1 A/3Rjm8O64vYzwNvDsn2l4d2t/1GDFxdpClWMKnwsQJVwmtAo6VrVBAfi5Uz2+iapM6B lUjhUqRG2MeR7l6yVfjKSVhAX+uhhffIAEZh/5k/Knw7cveObpsH2mfpueoA8GV8B6iz n/6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=yF4fvZKaBQU6kTZ587qjwwFJjQtuURlTBp8CmjQzUes=; b=bn0zHVFQHKhMclR7Im13w3raXRQHHtettF1WSjeNHgImTd84BNazpxfzrd7WgvLHL9 BfRdY8cG5QYNejSPR+yC+60AnRFFiswqYtQOilJVTGzE5eqyDa2lBWOA4NQggZvdGFLb Zuy7A16pbaWWxN0GaEFhkHDZN4bigCctO25FrKAMZ6GATi8wAr0N6kdVfvqp/w5u/iRM o5DLUK9SSi4Lq5ikfdxIUW2yox814UYkHy/S5nb8WvQkm8YYZt49vLvKssjZgu/RbHFQ zwQbAVH4ggv+XdUKds+hdItt+FftrXOQK2r0mBXfCJYZsHe5BoRGL5USQcVnAoQ2KaOb dSww== X-Gm-Message-State: AOAM5330cSwwKbTEafyL3vsokZghlXMAX19m0KxmgEpJ49Ec9tYBZFik GmVZpkXdvbV+OZgrb2+dPbbHQpaF3t4ZGk3vq6/w+E0ZOmE= X-Google-Smtp-Source: ABdhPJw91honNghoc4NRVhTHbA3vvM7biiEuJ/Cn5CjW9MFt2Kx8y12OD5MKFO658goqiHnYg9h2GjTwT3aA3OG9YMo= X-Received: by 2002:a17:907:60ca:: with SMTP id hv10mr12857156ejc.500.1637365988657; Fri, 19 Nov 2021 15:53:08 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Dustin Marquess Date: Fri, 19 Nov 2021 17:52:56 -0600 Message-ID: Subject: Re: 14.0-CURRENT panic in early boot To: Juraj Lutter Cc: Karel Gardas , FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4HwtlT5cSXz3HLM X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=eVVbtLt9; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of dmarquess@gmail.com designates 2a00:1450:4864:20::52f as permitted sender) smtp.mailfrom=dmarquess@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52f:from]; NEURAL_SPAM_LONG(1.00)[1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Just a quick update.. A kernel built from today boots just fine, so whatever the problem was, it's already fixed :). -Dustin On Thu, Nov 18, 2021 at 3:54 PM Dustin Marquess wrote= : > > It was 16 days ago, so just a tad over 2 weeks :). > > Indeed, I'll start a bisect here in a few and I'll update as soon as I > know. I figured I'd ask ahead of time before I did the work :). > > Thanks! > -Dustin > > On Thu, Nov 18, 2021 at 12:29 PM Juraj Lutter wrote: > > > > > > > > On 18 Nov 2021, at 18:46, Karel Gardas wrote: > > > > > > Completely speculating, but since you don't see ioapic's are you sure t= his is just ~2 weeks old build? If not, then it may be relevant to: > > > > > > Bisecting would be a better approach. > > > > otis > > > > > > commit 1b7a2680fba589daf6f700565214919cb941ab56 > > Author: Jung-uk Kim > > Date: Thu Sep 30 16:23:21 2021 -0400 > > > > Import ACPICA 20210930 > > > > (cherry picked from commit c509b6ab0d7e5bafc5348b08653b8738bd40716e) > > > > > > > > =E2=80=94 > > Juraj Lutter > > XMPP: juraj (at) lutter.sk > > GSM: +421907986576 > > From nobody Sat Nov 20 02:32:22 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 5E6A118A8F8E for ; Sat, 20 Nov 2021 02:32:28 +0000 (UTC) (envelope-from kp@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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HwyHJ2DWHz4t1k; Sat, 20 Nov 2021 02:32:28 +0000 (UTC) (envelope-from kp@freebsd.org) Received: from venus.codepro.be (venus.codepro.be [5.9.86.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.codepro.be", Issuer "R3" (verified OK)) (Authenticated sender: kp) by smtp.freebsd.org (Postfix) with ESMTPSA id 17C96A166; Sat, 20 Nov 2021 02:32:28 +0000 (UTC) (envelope-from kp@freebsd.org) Received: by venus.codepro.be (Postfix, authenticated sender kp) id AEB702DE73; Sat, 20 Nov 2021 03:32:25 +0100 (CET) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Kristof Provost List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (1.0) Subject: Re: HEADS-UP: ASLR for 64-bit executables enabled by default on main Date: Fri, 19 Nov 2021 19:32:22 -0700 Message-Id: References: Cc: Li-Wen Hsu , freebsd-current , Fabien Thomas , MARECHAL Boris , Rafal Jaworowski , Damien DEVILLE In-Reply-To: To: Marcin Wojtas X-Mailer: iPhone Mail (19B74) X-ThisMailContainsUnwantedMimeParts: N > On 18 Nov 2021, at 11:43, Marcin Wojtas wrote: > czw., 18 lis 2021 o 19:07 Li-Wen Hsu napisa=C5=82(a): >>=20 >>> On Wed, Nov 17, 2021 at 6:30 AM Marcin Wojtas wrote: >>>=20 >>> As of b014e0f15bc7 the ASLR (Address Space Layout >>> Randomization) feature becomes enabled for the all 64-bit >>> binaries by default. >>>=20 >>> Address Space Layout Randomization (ASLR) is an exploit mitigation >>> technique implemented in the majority of modern operating systems. >>> It involves randomly positioning the base address of an executable >>> and the position of libraries, heap, and stack, in a process's address >>> space. Although over the years ASLR proved to not guarantee full OS >>> security on its own, this mechanism can make exploitation more difficult= >>> (especially when combined with other methods, such as W^X). >>>=20 >>> Tests on the tier 1 64-bit architectures demonstrated that the ASLR is >>> stable and does not result in noticeable performance degradation, >>> therefore it is considered safe to enable this mechanism by default. >>> Moreover its effectiveness is increased for PIE (Position Independent >>> Executable) binaries. Thanks to commit 9a227a2fd642 ("Enable PIE by >>> default on 64-bit architectures"), building from src is not necessary >>> to have PIE binaries and it is enough to control usage of ASLR in the >>> OS solely by setting the appropriate sysctls. The defaults were toggled >>> for the 64-bit PIE and non-PIE executables. >>>=20 >>> As for the drawbacks, a consequence of using the ASLR is more >>> significant VM fragmentation, hence the issues may be encountered >>> in the systems with a limited address space in high memory consumption >>> cases, such as buildworld. As a result, although the tests on 32-bit >>> architectures with ASLR enabled were mostly on par with what was >>> observed on 64-bit ones, the defaults for the former are not changed >>> at this time. Also, for the sake of safety the feature remains disabled >>> for 32-bit executables on 64-bit machines, too. >>>=20 >>> The committed change affects the overall OS operation, so the >>> following should be taken into consideration: >>> * Address space fragmentation. >>> * A changed ABI due to modified layout of address space. >>> * More complicated debugging due to: >>> * Non-reproducible address space layout between runs. >>> * Some debuggers automatically disable ASLR for spawned processes, >>> making target's environment different between debug and >>> non-debug runs. >>>=20 >>> The known issues (such as PR239873 or PR253208) have been fixed in >>> HEAD up front, however please pay attention to the system behavior after= >>> upgrading the kernel to the newest revisions. >>> In order to confirm/rule-out the dependency of any encountered issue >>> on ASLR it is strongly advised to re-run the test with the feature >>> disabled - it can be done by setting the following sysctls >>> in the /etc/sysctl.conf file: >>> kern.elf64.aslr.enable=3D0 >>> kern.elf64.aslr.pie_enable=3D0 >>>=20 >>> The change is a result of combined efforts under the auspices >>> of the FreeBSD Foundation and the Semihalf team sponsored >>> by Stormshield. >>>=20 >>> Best regards, >>> Marcin >>=20 >> Thanks very much for working on this. FYI, there are some test cases >> seem to be affected by this: >>=20 >> https://ci.freebsd.org/job/FreeBSD-main-amd64-test/19828/testReport/ >>=20 >> The mkimg ones are a bit tricky, it seems the output is changed in >> each run. We may need a way to generate reproducible results.. >>=20 >> I'm still checking them, but hope more people can join and fix them. >>=20 >=20 > Thanks for bringing this up! Apart from > sys.netpfil.common.dummynet.pf_nat other are 23 are new. I=E2=80=99ve just managed to reproduce that one locally (it only happens if i= pfw is also loaded) and will dig in soon. It=E2=80=99s not going to be aslr r= elated. You can ignore that failure.=20 Kristof=20 From nobody Sat Nov 20 06:20:40 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 29301189D483 for ; Sat, 20 Nov 2021 06:20:57 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-22.consmr.mail.gq1.yahoo.com (sonic317-22.consmr.mail.gq1.yahoo.com [98.137.66.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 4Hx3Lv6gXBz4mkM for ; Sat, 20 Nov 2021 06:20:55 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637389247; bh=BiOpSI/RYBIeQyNVjZkH281xPU5T8DTLYytOiqeQhXE=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=I3LOupmo6Djz/1FyDarOuDFXKJJI4M5dhpjaGoIUbW+Vq67iYw5G6Nnmy0mRSUD5RehSh3fT6EusFcLvC8BTWyLQivHMgH7tvsq1tj5QMljBhp/gwkAe8qb1JHnaqbE44jHiYgMM91zxovXEhVdGmJmoHi4ir1PT76H5v9wrwximO8yNE/7x1yobYp33jpDliYgl1rbk20zr4t/dzfPCoCfIgyWLwnAhrDJDEoHGMqkqZXvrc8xqhLcBtfwcUcxGJROtFUOCSP1+iu8oUAoFb5ICpz6k7lgnz93y9+pIsWgtCCj1Sr+1zkoWqBSXh7fn8V3k5Q+9CBEORjrg2szhTQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637389247; bh=mKULppDzdKQMNbpIqplmxLlYFcFgUhqnqZNTijRw71G=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=SfhmoHVIdiXtrPVj1sX+u9HfM/n1U/PFfVjbjt06ZpebGTOOb0UZV95uZyOqdfQC29iKBWrZ3+Tx3xFiLizII+hucY/aJGX8m5tCIN63Yjp3XJ1WOgeFx847Kfc0FfIunnqgBQc4IK+geXAF2KNI5WXHAWbBVBE48hN0E24skSUw+q4vLFohvj9/EsnZLcBw3MxoDlTl9d5mGGJBjmxST2UGopqkzvaM9FAUyuopLIJEH44agkBfG7tyt/+IyAHQ6BXLSZX4uKexo7UZ3AviVCdvJGZokBXFr2RVbD5Jw6cpTIGd/p71GHelTvSn9y56ffL67WNiVhNQKt4NeonqtA== X-YMail-OSG: 1ZcKlJEVM1mbIp3JGxAsImzdTS4TCdmv2jlx2dHShQ5z0FHmyM36k9Cz7Yp2yTq P0C8G_izhGn6YY1m7eMhP6Qi2mc8HI10IYUz5iHiTsz1_m7x3Doe.C32Z56tNvKPUIbg9u5JmrpW zV9il9Gz2mbx9IKrPbdfbjCrlmqQcjDjzWVs0SpXVYd5B8L3eT5ui53_nwgAQr7w4jM923Qz0YcR zHOlS0DG7BLNQdXbzHOuOQuYoTErg5W9SeWoQ8_k7EG89HsRAqYfKu4Lqi6FEcCGISU19HGi4Uhe OmfcCX_oix1tD7i0DggFV6Qj4ZBiSSrenkh4Hjp.3dJ6hDoKT_ncCL3xjBqDxjWol0mcMNJ_JIDJ bvW2dcv2244kopmTJg615xXoggHBweqJO_9eKlkdZWDe8JfZNa4kI1oY6Wtufel7YYIyg1C4qDgb 6N9r4b7dqeJQiVjzY15ev2_LFnXPSGRH9TNSvvLVzHb3F1Gaer7Cj8OMFvj.8xMprRWDsU7l5Ai0 EoTRGyoRJwdkMbSbf1W8FaFMOy5H.faz.MzyCj1kYqyfOsSidVwbBwYphHToQfUocoO5H2z.iAWF FJHAAtcJzHt0t1Qm7OGhfNQ1_llUIl8CRm5hdAbLPeeNZTe18WrbyKh7HSioIxB_Oxwx3A0PaT6m uKRAczgaEq4uIDtASEUoB7uyEI5w7aNDztdDs_ZUBT5wWLG5lXZjLsqm59csqGLboDzwZdNM7gsy Aebt08FeyBUMbbopb58li.3eV4h8sAGMesPfot2Xe6ideCzK.xN4E2YmA0nul1bku9tyYV1lP8h_ HeCfcUm_JW6GQXk5Hkmb4vCvmdm1C63pnSBgkSZgICM9DCChPzhbhFjvnICnYnfuKhQzGIVnPofC y6ZEo9Ayo5zEznRPobc2noRwBk5TGy0H1ZqskR3uKw8VPmMA0y.eQ6fO8tvWpdP6O82FVCJBOhYt ROwskg5wBeCOW_GO37xWlsBkADpBkrsAtwIVYbbkLqpsXtWl8c17ihgD1tTP8AyX8bUjq1U7.uiO uEYWLj5IFhz1zrYzKtmAEiExvGh4lzDPlo6EBF0al9bEGJ2PNlP3UtAucmbJE8Cf.0BGYop6kP8n t5TA7HLt95kPqqtLSKpEfAWkty6ycqsW.FLW6n2J3pi.Vrq.RrqwJcNVru9Py.xpkDNDcg1bwKf8 UcCZuc79nyrL_UJSiR5NKmz6oRr2z1bMaGIwHb7L3PqVPq8SI7lqJ7EXOGCpS3yqjrROQT8aYiv_ ybeMn7HATAYnA22HfItb9iFS4I94LYe8EgqJzB3CYtPWUaLpYa6ES17kHbOdEHAg0dAXeMV_OITn Qspw.5kWB2lt1kOGEw84S.3O72KVmq_Xd2bVnJbhKBCFtnX3vyCQJni8UdRNZ6fmXXm6fSUwNLLf F4gLl0WVcqZWamDtHBF0EFKZZSFgdJ8Wztgc_tOG6Sw1i1oo6nUxZRmC5G4oCJSaUJTjiAjZ9JEh Elr12a7aQk3bFq8RchKPPyYSnpMiGV2dIFR44RTg8bPJ7vRda7jUbgt4zWTC.gRUP1d_g81V5k4D Norl8QrEH8pB69dDo9BdYv6hVPT8Y4AezgBPQOdA7FrlkZm231P6v6ZqUvNXi5npRcIzAEpI8ZiY atglNxo5h3HXctT75EVzLWEKOnqb8irFFM5rDQugP7yC6F9d3Hkz1km58oed0uyGnfu1kVFIBri8 oCjS35PfrQOvHAf_bEmbg9wt60xYDTwsk7oGy_VgQSYI1XS0h2h8Zf_Hk9emXe1OrsjG7A45kCRl USQ72z_fmGBo__nzOKfZUZL2vzJBlfTHd3_FUjaKUMc.lhd9n5wLc.7oMG0JpUwxUgdySsWLX2h0 UtQ49DNmj_wmKTP2Lj8OfXWJGfamIPq43VeqlX_dshOarQe6v35_aD85QfTnyb9IJDnCOu0o0keZ utCJivRX6SNTKZIsglZYZnzudKqmlgOCHAk_VEk3VxDnPuTH6AwaTydFlLdmQXN6hMtpZly2mNMD bydbh5msDxQNmpg00MP8hc3qqSEuz1jG_6xsUMNPBtZZXo7LoD.ZeuY9mDOjgOC0EFyLLntwStz1 eU_j8cXgzTbHnuMeo.8szF64UG8hq0jvrL5JwBEzUmeZELKBYhSHSUt8gRVg_UMc7M3fS3rc_iYB .7u8c5zYe.diBToRPSwWwgOdUTEDrOSSuKYq4U9ZX4I6Sp2.wO9bnlNTM_2VLVkRQRzUs2Wt5zWE rZ9Dgq9r0Ds6YVoFt5dCs9OJMLBq2B0ruTTPjm4U4Da77Vbw- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Sat, 20 Nov 2021 06:20:47 +0000 Received: by kubenode528.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID feee28c9cabcb0fca281a6ed60859c67; Sat, 20 Nov 2021 06:20:42 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: aarch64(?) poudiere-devel based builds seem to get fairly-rare corrupted files after recent system update(s?) Date: Fri, 19 Nov 2021 22:20:40 -0800 References: <2CA61249-321C-45AA-9755-597146AB8E9F@yahoo.com> <65AA4BCD-EC4B-4A19-B750-C7FC6E5ADDF5@yahoo.com> <9BF4F65B-6437-4D88-AF34-9BCFBF90D6F3@yahoo.com> <4B591638-4693-4403-8549-88D7A1D9D669@yahoo.com> To: freebsd-current , "freebsd-arm@freebsd.org" In-Reply-To: <4B591638-4693-4403-8549-88D7A1D9D669@yahoo.com> Message-Id: <0006EB30-B9F9-465A-8B9A-A0C03899CEFC@yahoo.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4Hx3Lv6gXBz4mkM X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=I3LOupmo; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.66.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(1.00)[1.000]; RCVD_IN_DNSWL_NONE(0.00)[98.137.66.148:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.66.148:from]; RCVD_COUNT_TWO(0.00)[2] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-current X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Nov-18, at 12:15, Mark Millard wrote: > On 2021-Nov-17, at 11:17, Mark Millard wrote: >=20 >> On 2021-Nov-15, at 15:43, Mark Millard wrote: >>=20 >>> On 2021-Nov-15, at 13:13, Mark Millard wrote: >>>=20 >>>> On 2021-Nov-15, at 12:51, Mark Millard wrote: >>>>=20 >>>>> On 2021-Nov-15, at 11:31, Mark Millard wrote: >>>>>=20 >>>>>> I updated from (shown a system that I've not updated yet): >>>>>>=20 >>>>>> # uname -apKU >>>>>> FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #18 = main-n250455-890cae197737-dirty: Thu Nov 4 13:43:17 PDT 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64=20 >>>>>> 1400040 1400040 >>>>>>=20 >>>>>> to: >>>>>>=20 >>>>>> # uname -apKU >>>>>> FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #19 = main-n250667-20aa359773be-dirty: Sun Nov 14 02:57:32 PST 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400042 1400042 >>>>>>=20 >>>>>> and then updated /usr/ports/ and started poudriere-devel based = builds of >>>>>> the ports I's set up to use. However my last round of port builds = from >>>>>> a general update of /usr/ports/ were on 2021-10-23 before either = of the >>>>>> above. >>>>>>=20 >>>>>> I've had at least two files that seem to be corrupted, where a = later part >>>>>> of the build hits problematical file(s) from earlier build = activity. For >>>>>> example: >>>>>>=20 >>>>>> /usr/local/include/X11/extensions/XvMC.h:1:1: warning: null = character ignored [-Wnull-character] >>>>>> =20 >>>>>> ^ >>>>>> /usr/local/include/X11/extensions/XvMC.h:1:2: warning: null = character ignored [-Wnull-character] >>>>>> >>>>>> ^ >>>>>> /usr/local/include/X11/extensions/XvMC.h:1:3: warning: null = character ignored [-Wnull-character] >>>>>> =20 >>>>>> ^ =20 >>>>>> /usr/local/include/X11/extensions/XvMC.h:1:4: warning: null = character ignored [-Wnull-character] >>>>>> >>>>>> ^ >>>>>> . . . >>>>>>=20 >>>>>> Removing the xorgproto-2021.4 package and rebuilding via >>>>>> poudiere-devel did not get a failure of any ports dependent >>>>>> on it. >>>>>>=20 >>>>>> This was from a use of: >>>>>>=20 >>>>>> # poudriere jail -j13_0R-CA7 -i >>>>>> Jail name: 13_0R-CA7 >>>>>> Jail version: 13.0-RELEASE-p5 >>>>>> Jail arch: arm.armv7 >>>>>> Jail method: null >>>>>> Jail mount: /usr/obj/DESTDIRs/13_0R-CA7-poud >>>>>> Jail fs: =20 >>>>>> Jail updated: 2021-11-04 01:48:49 >>>>>> Jail pkgbase: disabled >>>>>>=20 >>>>>> but another not-investigated example was from: >>>>>>=20 >>>>>> # poudriere jail -j13_0R-CA72 -i >>>>>> Jail name: 13_0R-CA72 >>>>>> Jail version: 13.0-RELEASE-p5 >>>>>> Jail arch: arm64.aarch64 >>>>>> Jail method: null >>>>>> Jail mount: /usr/obj/DESTDIRs/13_0R-CA72-poud >>>>>> Jail fs: =20 >>>>>> Jail updated: 2021-11-04 01:48:01 >>>>>> Jail pkgbase: disabled >>>>>>=20 >>>>>> (so no 32-bit COMPAT involved). The apparent corruption >>>>>> was in a different port (autoconfig, noticed by the >>>>>> build of automake failing via config reporting >>>>>> /usr/local/share/autoconf-2.69/autoconf/autoconf.m4f >>>>>> being rejected). >>>>>>=20 >>>>>> /usr/obj/DESTDIRs/13_0R-CA7-poud/ and >>>>>> /usr/obj/DESTDIRs/13_0R-CA72-poud/ and the like track the >>>>>> system versions. >>>>>>=20 >>>>>> The media is an Optane 960 in the PCIe slot of a HoneyComb >>>>>> (16 Cortex-A72's). The context is a root on ZFS one, ZFS >>>>>> used in order to have bectl, not redundancy. >>>>>>=20 >>>>>> The ThreadRipper 1950X (so amd64) port builds did not give >>>>>> evidence of such problems based on the updated system. (Also >>>>>> Optane media in a PCIe slot, also root on ZFS.) But the >>>>>> errors seem rare enough to not be able to conclude much. >>>>>=20 >>>>> For aarch64 targeting aarch64 there was also this >>>>> explicit corruption notice during the poudriere(-devel) >>>>> bulk build: >>>>>=20 >>>>> . . . >>>>> [CA72_ZFS] Extracting arm-none-eabi-gcc-8.4.0_3: ......... >>>>> pkg-static: Fail to extract = /usr/local/libexec/gcc/arm-none-eabi/8.4.0/lto1 from package: Lzma = library error: Corrupted input data >>>>> [CA72_ZFS] Extracting arm-none-eabi-gcc-8.4.0_3... done >>>>>=20 >>>>> Failed to install the following 1 package(s): = /packages/All/arm-none-eabi-gcc-8.4.0_3.pkg >>>>> *** Error code 1 >>>>> Stop. >>>>> make: stopped in /usr/ports/sysutils/u-boot-orangepi-plus-2e >>>>>=20 >>>>> I'm not yet to the point of retrying after removing >>>>> arm-none-eabi-gcc-8.4.0_3 : other things are being built. >>>>=20 >>>>=20 >>>> Another context with my prior general update of /usr/ports/ >>>> and the matching port builds: Back then I used USE_TMPFS=3Dall >>>> but the failure is based on USE_TMPFS-"data" instead. So: >>>> lots more I/O. >>>>=20 >>>=20 >>> None of the 3 corruptions repeated during bulk builds that >>> retried the builds that generated the files. All of the >>> ports that failed by hitting the corruptions in what they >>> depended on, built fine in teh retries. >>>=20 >>> For reference: >>>=20 >>> I'll note that, back when I was using USE_TMPFS=3Dall , I also >>> did some separate bulk -a test runs, both aarch64 (Cortex-A72) >>> native and Cortext-A72 targeting Cortex-A7 (armv7). None of >>> those showed evidence of file corruptions. In general I've >>> not had previous file corruptions with this system. (There >>> was a little more than 245 GiBytes swap, which covered the >>> tmpfs needs when they were large.) >>=20 >>=20 >> I set up a contrasting test context and got no evidence of >> corruptions in that context. (Note: the 3 bulk builds >> total to around 24 hrs of activity for the 3 examples >> of 460+ ports building.) So, for the Cortex-A72 system, >=20 > I set up a UFS on Optane (U.2 via M.2 adapter) context and > also got no evidence of corruptions in that context (same > hardware and a copy of the USB3 SSD based system). The > sequence of 3 bulks took somewhat over 18 hrs using the > Optane. >=20 >> root on UFS on portable USB3 SSD: no evidence of corruptions > Also: > root on UFS on Optane U.2 via M.2: no evidence of corruptions >> vs.: >> root on ZFS on optane in PCIe slot: solid evidence of 3 known = corruptions >>=20 >> Both had USE_TMPFS=3D"data" in use. The same system build >> had been installed and booted for both tests. >>=20 >> The evidence of corruptions is rare enough for this not to >> be determinative, but it is suggestive. >>=20 >> Unfortunately, ZFS vs. UFS and Optane-in-PCIe vs. USB3 are >> not differentiated by this test result. >>=20 >> There is also the result that I've not seen evidence of >> corruptions on the ThreadRipper 1950 X (amd64) system. >> Again, not determinative, but suggestive, given how rare >> the corruptions seem to be. >=20 > So far the only things unique to the observed corruptions are: >=20 > root on ZFS context (vs. root on UFS) > and: > Optane in a PCIe slot (but no contrasting ZFS case tested) >=20 > The PCIe slot does not seem to me to be likely to be contributing. > So this seem to be suggestive of a ZFS problem. >=20 > A contributing point might be that the main [so: 14] system was > built via -mcpu=3Dcortex-a72 for execution on a Cortext-A72 system. >=20 > [I previously ran into a USB subsystem mishandling of keeping > things coherent for the week memory ordering in this sort of > context. That issue was fixed. But back then I was lucky enough > to be able to demonstrate fails vs. works by adding an > appropriate instruction to FreeBSD in a few specific places > (more than necessary as it turned out). Someone else determined > where the actual mishandling was that covered all required > places. My generating that much information in this context > seems unlikely.] I started a retry of root-on-ZFS with the Optane-in-PCIe-slot media and it got its first corruption (in a different place, 2nd bulk build this time). The use of the corrupted file reports: configure:13269: cc -o conftest -Wall -Wextra -fsigned-char = -Wdeclaration-after-statement -O2 -pipe -mcpu=3Dcortex-a53 -g = -fstack-protector-strong -fno-strict-aliasing -DUSE_MEMORY_H = -I/usr/local/incl ude -mcpu=3Dcortex-a53 -fstack-protector-strong conftest.c = -L/usr/local/lib -logg >&5 In file included from conftest.c:27: In file included from /usr/local/include/ogg/ogg.h:24: In file included from /usr/local/include/ogg/os_types.h:154: /usr/local/include/ogg/config_types.h:1:1: warning: null character = ignored [-Wnull-character] ^ /usr/local/include/ogg/config_types.h:1:2: warning: null character = ignored [-Wnull-character] ^ /usr/local/include/ogg/config_types.h:1:3: warning: null character = ignored [-Wnull-character] ^ . . . /usr/local/include/ogg/config_types.h:1:538: warning: null character = ignored [-Wnull-character] . . . (nulls) . . . So: 538 such null bytes. Thus, another example of something like a page of nulls being written out when ZFS is in use. audio/gstreamer1-plugins-ogg also failed via referencing the file during its build. (The bulk run is still going and there is one more bulk run to go.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Sat Nov 20 19:54:09 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 6B519188F288 for ; Sat, 20 Nov 2021 19:54:23 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-22.consmr.mail.gq1.yahoo.com (sonic301-22.consmr.mail.gq1.yahoo.com [98.137.64.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HxPPV0hCtz3kGn for ; Sat, 20 Nov 2021 19:54:22 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637438053; bh=cYcKVeA8+06t3AFainxt+18bdXJU9Njlit5Ir6W06W0=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=O0XEz6/WBkJyU7csQ6ABwayX+R6J46Otje6GlZ35UUni5p6rPdTyF5ZaEQm+VgMl7Vvh1dvT7C6DH83YK+h0hdaZt8aC6dGHSTloWOnbOFcnHtCKsvIx691y9K7XNmOGUOLLzaNT9jwPzEzHyZfnUsIh86UP9rOnPEaPlupLeb1MyvKwGapH1c1jFghWQr8iRYLwnMEHsDCpFJO2Iv/YeEkdBLBxmU64TbyVgAnnoETl5WDLcPVguarn25K/pTFgpVKdDnKnJ+HgCnQdFqF6tzuvCgX/ebBPGyk1ao9TjGgQVOke2eEBrVnc/DMN1wAnCLhgZ06oKpEhf2MIPqS4Dw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637438053; bh=7Yv/3tTt6GcbfAGgh5kvrhu3m6fRn3q8m4fwwzleaqM=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=tqkZDZM4IJuXHV6rjrrLEB5/7ZJJOF6kfw0Qzc0nGRq95osz6/Tvgm7kBmTcf4TcX5qy98U4GgG4DLgbRIeZCB2wvVtNEa77Vvn0o6uTjqwLkNwgVte+b14b6zYUONaRUaSvvM7JO2//Oc2oOqI5aK/eKRxn8MIZQEL8HeEBwZjqfnLAlj7ZWVtGq5Sl1AloA6cMwrjG5uiF6BvzQt44WTWcBD8FBtG0OhEqA422k0MfgbUSyzepLO8UtY+NfvlpQKxfsNEAH0VVZiv3wMshVOdIECbf6MTok/CDhacyU9oWKA/PXYXW3RW4SiNfoGnAVEc+jmEukQliuQk4OWWvbQ== X-YMail-OSG: KAF.tNQVM1lxJEOe981imz_mHXsdmEQEwWrjn497ze6soeJwkuKKd1EPOiENzka Kakc7uLv2j8Go9Cq1hWuuCPoWs3IbRP_vZQbGgHOnUB4z.VlEWGjLwEr7Xcihd16_txv34jzYJ.9 .WX0yFB74GYyRy9K.C6ksoiT0XVmnU.eVswbMac4Xcz.mljbHplZcq0JA0fODed_Rq9NL4T.ISDU flEX9QuiiTznjv_M8OlMGXHRK6JWWIgti5mcR2GUPN6ynNqbMuzLeYFUq2pHCTFLm0wDgl8h2ILg Z2WQfRQICwCYR0ReC966qFEELBpeNlJiqvDj27vlVOPy5LPvak_l660wBsuZPQJHh7lF.ZAbWfD5 nIVwI9jQULxx7Vb_F19le0XRbarcTyNgZntAEfS3YBAVTme4r_XHejBIlI12ztKuIC605C7eslh6 0S9nAJQ4gFHVDNGD2QbY4RvU8AFpZ.toDdrIrrXgxuWnc4.U03Q1ijaJ7xxjFY.Zio.iPZVJTXZd FkyyLtg_DmVZY..ixcsBypwOFlSCA8gUlPP_E7OSbv36sJzFfABRT7Ebu.hFb1o4vjxkImBujm9E qJCE8P5e1H8kMNz8jB3HVvLzHcEz.HYO2YXmhtwtOkaM9RpaUcrQ_ztajgHGuunzu_apiVfLd.XK I_O8NlUMj1zZzfEcLsQTeuAuHJnML0sagcZMq6_D7IFYrc8s2a_hicfPIHzlBPqQGlpvME1STbCC glfSHgTXLahingYgld4zoWiyI4Tvm.65rY5.dHGpji56B4E9nQD1P4eQ8CWIGKhwLBNDA7Cxtvr8 tw1NsAKRtw4.WzN4j2gbn_UeQ2nQ8JM_kWo1oeJu7m5pi6UH8I1H5j8knYMN06.NgJIdQWQBAB_e 2SoiOmy3UVrYGh0Fus6hwHlyIGk.wQiljijU8jG1N1khM.r16DBs6GNALQx8_L4Y2eQ4xlHe0Ylw CaDVyQm_9Rn8ZfNHctjEg7Ke6.JXsez95q0_vh1BaRGqHqDq4jLdzF7bIKGvwnF4zyaIO64HSMkH spOssem7pNVH.H6J7U1P0Jife5Jr0YJYDEmMFxmjteaVxGwyFWuMYcFewPs.6a4JWGWeHGNP4L8l JwqEWpcRL5yYgYdvAmfISaU_C6DevPflPALnBR6jUbmM5WXMl2SJngbJWb1xfDqSqVkoez8W8_MW WQXCdg3D7aCHebhI2x6fsLEb.GxHPgjmR5V3pbEHv07.w.Mi_CsLk_BoRnPIhmPdEQoauGPUmHdU k4Trajq.1yGpx74ZCWIeM_0DIRit8t4IKimdOF2nxGuEggYEap.05vovuGdj47IlLjJpcmyWblw2 A1x8R_k28wTr59VyIiqU4r7x8Hsxnb77XzFdxp2alrJIkyUJa5EaozaZ3LP2Sdh6GUh4f6E2G1nz PeexgoixxqqkoMafg_28uvKgKubHXSMKhSr5jhcS9wZZ2DbOAafVHvjF6SwPefUDqfK7aMUjp.fC y0Z232.fcj5BbBgcpz3chZH5Ga5a0TqGHCwbD2BYhsYcAjDuSdGdtu9aMacdAZfpZgr2VxW6A0yd KTXnbbRzpL17RELCF0PDMK9aFEV80r18c9siRg6eF..vDKaKKOXpvnxsmwt5gTfc.s5G.Mm4QZZj dZ4cVHkYNEpp05BjDEw6_pI8y7c6qFSSYQLZYP1KUyx.iY.X6UmIFi5_E76Kp0GvUcAd4Y4pWz0n KZ_QYl1vOTZRNIAtZRLcHwvE2gJm4PYdNFjcLHH70qp4RTxSU.gwJQN4QodOpgScgDVqAXDEF38g NLUJAE2slA89YbDoCRpoz4vjhzCNUK7O3FxcF7LJFt.Hxu6xiJ2GUPd2Tdix5KWtVabQpyQZL4pJ ENdgf7YcLS_.uKX_88c4JzyiLcuVSegUSZKJZe8UhsnTjzAkGLPCfvBRy2yjSTFCt7kokV5ho3ta kW_YyagubyD1bhNWV5EZlUJkE3ddA.Q2g5idyXjruHptlIxamk0n0xNaT0Sor_nhz6PT1vWD4AUO UpVsfMffUhhd4jC7DFHhcxdb0obJhp1N1RPz.ghlTWFmjSFkP.IsAHp78nYg.HOw64ppcJiX4S_h s7GV3BR2z5FWShdoxLpaEemnigFqAmXGIT2daQuhHYN066fqHG0j5YoLWe111aYBcTsTQ7gqxMSx vY5fiHJBQeTbtOYcVbG9lWTzEfVm1Jns262oF75dh.JDTEbTpAdr2ylnItA9mSpL6CdLe2oCKU7_ btqSGB6G0x2VYBBO6Twg0y3V_MAqJCXebGRnoZAbYnT5LloYnsJVOfuzXgbdvrG8HttXtcrkorod fDyQRvcl4Owvbzg4si8bZ X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Sat, 20 Nov 2021 19:54:13 +0000 Received: by kubenode511.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID a6d4bebea471a42359ddf873a13f06ab; Sat, 20 Nov 2021 19:54:10 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: aarch64(?) poudiere-devel based builds seem to get fairly-rare corrupted files after recent system update(s?) Date: Sat, 20 Nov 2021 11:54:09 -0800 References: <2CA61249-321C-45AA-9755-597146AB8E9F@yahoo.com> <65AA4BCD-EC4B-4A19-B750-C7FC6E5ADDF5@yahoo.com> <9BF4F65B-6437-4D88-AF34-9BCFBF90D6F3@yahoo.com> <4B591638-4693-4403-8549-88D7A1D9D669@yahoo.com> <0006EB30-B9F9-465A-8B9A-A0C03899CEFC@yahoo.com> To: freebsd-current , "freebsd-arm@freebsd.org" In-Reply-To: <0006EB30-B9F9-465A-8B9A-A0C03899CEFC@yahoo.com> Message-Id: X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4HxPPV0hCtz3kGn X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b="O0XEz6/W"; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(1.00)[1.000]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.148:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.148:from]; RCVD_COUNT_TWO(0.00)[2] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-current X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Nov-19, at 22:20, Mark Millard wrote: > On 2021-Nov-18, at 12:15, Mark Millard wrote: >=20 >> On 2021-Nov-17, at 11:17, Mark Millard wrote: >>=20 >>> On 2021-Nov-15, at 15:43, Mark Millard wrote: >>>=20 >>>> On 2021-Nov-15, at 13:13, Mark Millard wrote: >>>>=20 >>>>> On 2021-Nov-15, at 12:51, Mark Millard wrote: >>>>>=20 >>>>>> On 2021-Nov-15, at 11:31, Mark Millard wrote: >>>>>>=20 >>>>>>> I updated from (shown a system that I've not updated yet): >>>>>>>=20 >>>>>>> # uname -apKU >>>>>>> FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #18 = main-n250455-890cae197737-dirty: Thu Nov 4 13:43:17 PDT 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64=20 >>>>>>> 1400040 1400040 >>>>>>>=20 >>>>>>> to: >>>>>>>=20 >>>>>>> # uname -apKU >>>>>>> FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #19 = main-n250667-20aa359773be-dirty: Sun Nov 14 02:57:32 PST 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400042 1400042 >>>>>>>=20 >>>>>>> and then updated /usr/ports/ and started poudriere-devel based = builds of >>>>>>> the ports I's set up to use. However my last round of port = builds from >>>>>>> a general update of /usr/ports/ were on 2021-10-23 before either = of the >>>>>>> above. >>>>>>>=20 >>>>>>> I've had at least two files that seem to be corrupted, where a = later part >>>>>>> of the build hits problematical file(s) from earlier build = activity. For >>>>>>> example: >>>>>>>=20 >>>>>>> /usr/local/include/X11/extensions/XvMC.h:1:1: warning: null = character ignored [-Wnull-character] >>>>>>> =20 >>>>>>> ^ >>>>>>> /usr/local/include/X11/extensions/XvMC.h:1:2: warning: null = character ignored [-Wnull-character] >>>>>>> >>>>>>> ^ >>>>>>> /usr/local/include/X11/extensions/XvMC.h:1:3: warning: null = character ignored [-Wnull-character] >>>>>>> =20 >>>>>>> ^ =20 >>>>>>> /usr/local/include/X11/extensions/XvMC.h:1:4: warning: null = character ignored [-Wnull-character] >>>>>>> >>>>>>> ^ >>>>>>> . . . >>>>>>>=20 >>>>>>> Removing the xorgproto-2021.4 package and rebuilding via >>>>>>> poudiere-devel did not get a failure of any ports dependent >>>>>>> on it. >>>>>>>=20 >>>>>>> This was from a use of: >>>>>>>=20 >>>>>>> # poudriere jail -j13_0R-CA7 -i >>>>>>> Jail name: 13_0R-CA7 >>>>>>> Jail version: 13.0-RELEASE-p5 >>>>>>> Jail arch: arm.armv7 >>>>>>> Jail method: null >>>>>>> Jail mount: /usr/obj/DESTDIRs/13_0R-CA7-poud >>>>>>> Jail fs: =20 >>>>>>> Jail updated: 2021-11-04 01:48:49 >>>>>>> Jail pkgbase: disabled >>>>>>>=20 >>>>>>> but another not-investigated example was from: >>>>>>>=20 >>>>>>> # poudriere jail -j13_0R-CA72 -i >>>>>>> Jail name: 13_0R-CA72 >>>>>>> Jail version: 13.0-RELEASE-p5 >>>>>>> Jail arch: arm64.aarch64 >>>>>>> Jail method: null >>>>>>> Jail mount: /usr/obj/DESTDIRs/13_0R-CA72-poud >>>>>>> Jail fs: =20 >>>>>>> Jail updated: 2021-11-04 01:48:01 >>>>>>> Jail pkgbase: disabled >>>>>>>=20 >>>>>>> (so no 32-bit COMPAT involved). The apparent corruption >>>>>>> was in a different port (autoconfig, noticed by the >>>>>>> build of automake failing via config reporting >>>>>>> /usr/local/share/autoconf-2.69/autoconf/autoconf.m4f >>>>>>> being rejected). >>>>>>>=20 >>>>>>> /usr/obj/DESTDIRs/13_0R-CA7-poud/ and >>>>>>> /usr/obj/DESTDIRs/13_0R-CA72-poud/ and the like track the >>>>>>> system versions. >>>>>>>=20 >>>>>>> The media is an Optane 960 in the PCIe slot of a HoneyComb >>>>>>> (16 Cortex-A72's). The context is a root on ZFS one, ZFS >>>>>>> used in order to have bectl, not redundancy. >>>>>>>=20 >>>>>>> The ThreadRipper 1950X (so amd64) port builds did not give >>>>>>> evidence of such problems based on the updated system. (Also >>>>>>> Optane media in a PCIe slot, also root on ZFS.) But the >>>>>>> errors seem rare enough to not be able to conclude much. >>>>>>=20 >>>>>> For aarch64 targeting aarch64 there was also this >>>>>> explicit corruption notice during the poudriere(-devel) >>>>>> bulk build: >>>>>>=20 >>>>>> . . . >>>>>> [CA72_ZFS] Extracting arm-none-eabi-gcc-8.4.0_3: ......... >>>>>> pkg-static: Fail to extract = /usr/local/libexec/gcc/arm-none-eabi/8.4.0/lto1 from package: Lzma = library error: Corrupted input data >>>>>> [CA72_ZFS] Extracting arm-none-eabi-gcc-8.4.0_3... done >>>>>>=20 >>>>>> Failed to install the following 1 package(s): = /packages/All/arm-none-eabi-gcc-8.4.0_3.pkg >>>>>> *** Error code 1 >>>>>> Stop. >>>>>> make: stopped in /usr/ports/sysutils/u-boot-orangepi-plus-2e >>>>>>=20 >>>>>> I'm not yet to the point of retrying after removing >>>>>> arm-none-eabi-gcc-8.4.0_3 : other things are being built. >>>>>=20 >>>>>=20 >>>>> Another context with my prior general update of /usr/ports/ >>>>> and the matching port builds: Back then I used USE_TMPFS=3Dall >>>>> but the failure is based on USE_TMPFS-"data" instead. So: >>>>> lots more I/O. >>>>>=20 >>>>=20 >>>> None of the 3 corruptions repeated during bulk builds that >>>> retried the builds that generated the files. All of the >>>> ports that failed by hitting the corruptions in what they >>>> depended on, built fine in teh retries. >>>>=20 >>>> For reference: >>>>=20 >>>> I'll note that, back when I was using USE_TMPFS=3Dall , I also >>>> did some separate bulk -a test runs, both aarch64 (Cortex-A72) >>>> native and Cortext-A72 targeting Cortex-A7 (armv7). None of >>>> those showed evidence of file corruptions. In general I've >>>> not had previous file corruptions with this system. (There >>>> was a little more than 245 GiBytes swap, which covered the >>>> tmpfs needs when they were large.) >>>=20 >>>=20 >>> I set up a contrasting test context and got no evidence of >>> corruptions in that context. (Note: the 3 bulk builds >>> total to around 24 hrs of activity for the 3 examples >>> of 460+ ports building.) So, for the Cortex-A72 system, >>=20 >> I set up a UFS on Optane (U.2 via M.2 adapter) context and >> also got no evidence of corruptions in that context (same >> hardware and a copy of the USB3 SSD based system). The >> sequence of 3 bulks took somewhat over 18 hrs using the >> Optane. >>=20 >>> root on UFS on portable USB3 SSD: no evidence of corruptions >> Also: >> root on UFS on Optane U.2 via M.2: no evidence of corruptions >>> vs.: >>> root on ZFS on optane in PCIe slot: solid evidence of 3 known = corruptions >>>=20 >>> Both had USE_TMPFS=3D"data" in use. The same system build >>> had been installed and booted for both tests. >>>=20 >>> The evidence of corruptions is rare enough for this not to >>> be determinative, but it is suggestive. >>>=20 >>> Unfortunately, ZFS vs. UFS and Optane-in-PCIe vs. USB3 are >>> not differentiated by this test result. >>>=20 >>> There is also the result that I've not seen evidence of >>> corruptions on the ThreadRipper 1950 X (amd64) system. >>> Again, not determinative, but suggestive, given how rare >>> the corruptions seem to be. >>=20 >> So far the only things unique to the observed corruptions are: >>=20 >> root on ZFS context (vs. root on UFS) >> and: >> Optane in a PCIe slot (but no contrasting ZFS case tested) >>=20 >> The PCIe slot does not seem to me to be likely to be contributing. >> So this seem to be suggestive of a ZFS problem. >>=20 >> A contributing point might be that the main [so: 14] system was >> built via -mcpu=3Dcortex-a72 for execution on a Cortext-A72 system. >>=20 >> [I previously ran into a USB subsystem mishandling of keeping >> things coherent for the week memory ordering in this sort of >> context. That issue was fixed. But back then I was lucky enough >> to be able to demonstrate fails vs. works by adding an >> appropriate instruction to FreeBSD in a few specific places >> (more than necessary as it turned out). Someone else determined >> where the actual mishandling was that covered all required >> places. My generating that much information in this context >> seems unlikely.] >=20 >=20 > I started a retry of root-on-ZFS with the Optane-in-PCIe-slot media > and it got its first corruption (in a different place, 2nd bulk > build this time). The use of the corrupted file reports: >=20 > configure:13269: cc -o conftest -Wall -Wextra -fsigned-char = -Wdeclaration-after-statement -O2 -pipe -mcpu=3Dcortex-a53 -g = -fstack-protector-strong -fno-strict-aliasing -DUSE_MEMORY_H = -I/usr/local/incl > ude -mcpu=3Dcortex-a53 -fstack-protector-strong conftest.c = -L/usr/local/lib -logg >&5 > In file included from conftest.c:27: > In file included from /usr/local/include/ogg/ogg.h:24: > In file included from /usr/local/include/ogg/os_types.h:154: > /usr/local/include/ogg/config_types.h:1:1: warning: null character = ignored [-Wnull-character] > > ^ > /usr/local/include/ogg/config_types.h:1:2: warning: null character = ignored [-Wnull-character] > > ^ > /usr/local/include/ogg/config_types.h:1:3: warning: null character = ignored [-Wnull-character] > > ^ > . . . > /usr/local/include/ogg/config_types.h:1:538: warning: null character = ignored [-Wnull-character] > . . . (nulls) . . . >=20 > So: 538 such null bytes. >=20 > Thus, another example of something like a page of nulls being > written out when ZFS is in use. >=20 > audio/gstreamer1-plugins-ogg also failed via referencing the file > during its build. >=20 > (The bulk run is still going and there is one more bulk run to go.) >=20 Well, 528 happened to be the size of config_types.h --and of config_types.h from a build that did not get the corruption there. So looking at the other (later) corruption, which was a bigger file (looking via bulk -i and installing what contained the file but looking from outside the jail): # find /usr/local/ -name "libtextstyle.so*" -exec ls -Tld {} \; -rwxr-xr-x 1 root wheel 2339104 Nov 20 01:05:05 2021 = /usr/local/poudriere/data/.m/13_0R-CA7-default/ref/usr/local/lib/libtextst= yle.so.0.1.1 lrwxr-xr-x 1 root wheel 21 Nov 20 01:05:05 2021 = /usr/local/poudriere/data/.m/13_0R-CA7-default/ref/usr/local/lib/libtextst= yle.so.0 -> libtextstyle.so.0.1.1 lrwxr-xr-x 1 root wheel 21 Nov 20 01:05:05 2021 = /usr/local/poudriere/data/.m/13_0R-CA7-default/ref/usr/local/lib/libtextst= yle.so -> libtextstyle.so.0.1.1 hd = /usr/local/poudriere/data/.m/13_0R-CA7-default/ref/usr/local/lib/libtextst= yle.so.0.1.1 | more 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| * 0023b120 So the whole, over 2 MiByte, the whole file ended up with just null = Bytes. To cross check on live system caching vs. on disk, I rebooted and redid = the bulk -i based install of libtextstyle and looked at = libtextstyle.so.0.1.1 : still all zeros. For reference, zpool scrub afterward resulted in: # zpool status pool: zopt0 state: ONLINE scan: scrub repaired 0B in 00:01:49 with 0 errors on Sat Nov 20 = 11:47:31 2021 config: NAME STATE READ WRITE CKSUM zopt0 ONLINE 0 0 0 nda1p3 ONLINE 0 0 0 But it is not a ZFS redundancy context: ZFS used just to use bectl . =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Sat Nov 20 22:00:12 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id AA95018A7845 for ; Sat, 20 Nov 2021 22:00:47 +0000 (UTC) (envelope-from daniel@morante.net) Received: from venus.morante.net (venus.morante.net [63.247.147.163]) by mx1.freebsd.org (Postfix) with ESMTP id 4HxSCL608Vz4vdd for ; Sat, 20 Nov 2021 22:00:46 +0000 (UTC) (envelope-from daniel@morante.net) Received: from venus.morante.net (zenon.morante.com [192.168.0.233]) by saturn.morante.com (Postfix) with ESMTP id 4A6FA11F813 for ; Sat, 20 Nov 2021 17:00:44 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on zenon.morante.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=ALL_TRUSTED,NICE_REPLY_A, SPF_PASS autolearn=ham autolearn_force=no version=3.4.5 X-Spam-RelaysUntrusted: Received-SPF: pass (venus.morante.net: 192.168.0.2 is whitelisted) receiver=venus.morante.net; client-ip=192.168.0.2; helo=[192.168.0.2]; envelope-from=daniel@morante.net; x-software=SPF Validation 2.001 http://pacyworld.com/spf with libspf2-1.2.10; Received: from [192.168.0.2] (my-room.morante.com [192.168.0.2]) by venus.morante.net (Postfix) with ESMTPSA id C9EB311F807 for ; Sat, 20 Nov 2021 17:00:43 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=morante.net; s=default; t=1637445644; bh=3hsehPZ2vYkc5RNVJHuGHnKH+bOUmQKNtZNwNaGj7xs=; h=Date:Subject:To:References:From:In-Reply-To; b=QcDwUZkFTgx5sOWWgnDroD8URiJJM/2IYxSZmPh3r0t9TUyWFp04afbtJwu6dQTRU nQDMlTh0vwFgJtsulLMxpbbc18KG1Ru5ZwOmfmrjNqOi+qI9UaBxPfX5q7x6JTMw7l nF1RnX5E1O8PBEMmvq5BscnPVT2l/FT3yv/VCamI= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.3 at zenon.morante.com Message-ID: <4a4b73d7-5a9c-748e-9360-274fbc8292c8@morante.net> Date: Sat, 20 Nov 2021 17:00:12 -0500 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: 14.0-CURRENT panic in early boot Content-Language: en-US To: freebsd-current@freebsd.org References: In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms030409090309030700000509" X-Rspamd-Queue-Id: 4HxSCL608Vz4vdd X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=morante.net header.s=default header.b=QcDwUZkF; dmarc=pass (policy=reject) header.from=morante.net; spf=pass (mx1.freebsd.org: domain of daniel@morante.net designates 63.247.147.163 as permitted sender) smtp.mailfrom=daniel@morante.net X-Spamd-Result: default: False [-4.00 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[morante.net:s=default]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; SIGNED_SMIME(-2.00)[]; R_SPF_ALLOW(-0.20)[+mx:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; HAS_ATTACHMENT(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[morante.net:+]; DMARC_POLICY_ALLOW(-0.50)[morante.net,reject]; NEURAL_SPAM_LONG(1.00)[1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:30221, ipnet:63.247.144.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[] Reply-To: daniel@morante.net From: Daniel Morante via freebsd-current X-Original-From: Daniel Morante X-ThisMailContainsUnwantedMimeParts: N This is a cryptographically signed message in MIME format. --------------ms030409090309030700000509 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit I've seen it on an arm64 system: KDB: stack backtrace: db_trace_self() at db_trace_self db_trace_self_wrapper() at db_trace_self_wrapper+0x30 vpanic() at vpanic+0x174 panic() at panic+0x44 do_el1h_sync() at do_el1h_sync+0x184 handle_el1h_sync() at handle_el1h_sync+0x78 --- exception, esr 0x2000000 vt_conswindow() at vt_conswindow+0x10 (null)() at -0x4 (null)() at 0xffffffff00000001 Uptime: 3s The full log is here: http://venus.morante.net/downloads/unibia/screenshots/freebsd/R281-T91/14-CURRENT-4082b189d2c/failed-boot1.txt On 11/18/2021 12:22 AM, Dustin Marquess wrote: > I just updated a machine from a build that was ~2 weeks old. The > latest commit when I built it was 2e946f87055. > > The system boots using UEFI, if that matters. The system is panicking > pretty early in the boot, however: > > real memory = 137438953472 (131072 MB) > avail memory = 133651496960 (127460 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 32 CPUs > FreeBSD/SMP: 2 package(s) x 8 core(s) x 2 hardware threads > random: registering fast source Intel Secure Key RNG > random: fast provider: "Intel Secure Key RNG" > random: unblocking device. > kernel trap 12 with interrupts disabled > panic: vm_fault_lookup: fault on nofault entry, addr: 0xffffffff81e1d000 > cpuid = 0 > time = 1 > > > The backtrace shows: > > KDB: stack backtrace: > #0 0xffffffff806deb5b at kdb_backtrace+0x6b > #1 0xffffffff80693b44 at vpanic+0x184 > #2 0xffffffff806939b3 at panic+0x43 > #3 0xffffffff8091d4b3 at vm_fault+0x1423 > #4 0xffffffff8091bfb0 at vm_fault_trap+0xb0 > #5 0xffffffff809c0902 at trap_pfault+0x1f2 > #6 0xffffffff809992b8 at calltrap+0x8 > #7 0xffffffff806ebcc1 at vsscanf+0x31 > #8 0xffffffff806ebc7f at sscanf+0x3f > #9 0xffffffff806bd9ab at validate_uuid+0x8b > #10 0xffffffff80655be0 at prison0_init+0x90 > #11 0xffffffff80623aba at proc0_init+0x29a > #12 0xffffffff80623689 at mi_startup+0xe9 > #13 0xffffffff802e3062 at btext+0x22 > Uptime: 1s > > Compared to a boot using the old working kernel: > > real memory = 137438953472 (131072 MB) > avail memory = 133651505152 (127460 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 32 CPUs > FreeBSD/SMP: 2 package(s) x 8 core(s) x 2 hardware threads > random: registering fast source Intel Secure Key RNG > random: fast provider: "Intel Secure Key RNG" > random: unblocking device. > ioapic0 irqs 0-23 > ioapic1 irqs 24-47 > ioapic2 irqs 48-71 > Launching APs: 1 11 28 15 18 6 29 4 16 9 24 7 3 10 27 22 14 13 12 23 > 25 20 26 30 17 5 2 21 19 8 31 > Timecounter "TSC-low" frequency 1197250876 Hz quality 1000 > > Has anybody else seen this? > -Dustin > --------------ms030409090309030700000509 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC DJgwggX/MIID56ADAgECAgIQADANBgkqhkiG9w0BAQsFADCBkjELMAkGA1UEBhMCVVMxEDAO BgNVBAgMB0Zsb3JpZGExDzANBgNVBAcMBk5hcGxlczEpMCcGA1UECgwgVGhlIERhbmllbCBN b3JhbnRlIENvbXBhbnksIEluYy4xGDAWBgNVBAsMD1BhY3kgV29ybGQsIExMQzEbMBkGA1UE AwwSUGFjeSBXb3JsZCBSb290IENBMB4XDTE4MDcwNzE3MzUzMVoXDTI4MDcwNDE3MzUzMVow gYkxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMSkwJwYDVQQKDCBUaGUgRGFuaWVs IE1vcmFudGUgQ29tcGFueSwgSW5jLjEYMBYGA1UECwwPUGFjeSBXb3JsZCwgTExDMSMwIQYD VQQDDBpQYWN5IFdvcmxkIEludGVybWVkaWF0ZSBDQTCCAiIwDQYJKoZIhvcNAQEBBQADggIP ADCCAgoCggIBAMU0vt8sGT82c8BLAT+otS3VQVw4rf566bmYzJ7wm+D/vcp5jiwL1PAnGFch bSSpe1KCFQ7LCnjrl7nQg1EglHKETfHI7QxVqE22q92G/2rIDfPnNTYlLJ0d5xmM0q1P+yEI XYZErQyBthDhHfrDIEdWJ5tWevfFAUFjXmWy5V7eHGgndB8TQFEp9ML6Bks4tKH3ykwAZbib hKd7L2EthiqSJvvyIP3Kg/AwVjX67JTbKgQfcsfYGm5dofHmL+3uIhovLL5HFbADU6AoqXlh lNY83RfaD60G6IhPZwzZboBi6qxHnjwqsbV+S81SZdoMEnHDMZNzP4RC27ZMaTmxH3IN8JN4 XuszONstvUAuzdhmcG4q+K7HrO+SG0eEhDBUrxKrmFCUh8pwYU2o4q52/yDrZasid1NBFHZt Wfsyoe1ArhqnO4yz95h53dR9aCISwOGIMExNUJlH91KYNrLeSbPMR7LXgu48hY+CGkSYXhcS fPF9p9OUjgUeZ02+K8iI4a0CYCjuJNF1N/rJ7UkT0b5hdkcLPrXCd8P6NfJotoX6cGITF7Rm z+fq/3NbjF2Gu3nWeCdOXyECW9/HBzTlILZI10VOmfqDGZK3z6SlRBlaXK4lUvbqfDM+E785 CxStIlNqx/FDM6O8F+OP17Yb1vNpDhAblV/eYFiGZOw0YZAzAgMBAAGjZjBkMB0GA1UdDgQW BBR8ncAAcpI2KRTREkGd4Qpdx7IpVTAfBgNVHSMEGDAWgBR6BEY736L1bCcrmtwFaEg93nZd uTASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB/wQEAwIBhjANBgkqhkiG9w0BAQsFAAOC AgEAs/eYLE+jKO3hpHJ8QYaL8FH7iFFNbB4SVBDyH0arb9uqK/FY8uGlOn2A9ul8cE7sSA3E dXptZzFqY+C69UjlV2kvw2+35gvKoiIncwYhCA2JOQgm0QaXBAxZijF5UOL3+i1IE8JpdShz IoUvPtXBQiVnW9HJ5jZnZJNy4Jid+RQd5fNL2WmJf1Ob48YoeB23Y0KUnUvhmmu52OUG+bni hbP4ULTL4egmR783ZA5CqBWFb0J7HhXDaPBM1dGf+gQ5YzJqGWZXZ3YRe83IlDXm76rK+wlO uPlRUGSBbkgv7YRKzBx2JNLdNPBXIDxT71b1kGip8q0Mk9f/VXeudgCLzqa1+gphE3lNYQMa 0CHYfezask6ee5999rezWDx/T2/U0xy8i+bBlRNL7QRwk5JRTOemxbJJ5fzdLgwxEjkASPWy nIrf1O6C9f2vkUVGAWEo8wqhO+iLLmTRTt0GTsaIzA5aBmMz4KoByjOVwy6wAwoLTcFQrbGE jk5Cve+1AlXylTyokaeiYnKBjPMPSa5e3gcr3DfYQN5SbN3hXc8OFfkYzwqkZz4kMIWlP7pQ O0NqX8N+IiHJFc8BB8T8P4GRjO7jJYGtCJeTSVrO5tacpvJvg0BsHf48IpETH7Hs0oy1IXdZ DJQOceJCuOwDe7Q1ELHtIrjDeloN1CR+7M3qNc8wggaRMIIEeaADAgECAgIQHTANBgkqhkiG 9w0BAQsFADCBiTELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExKTAnBgNVBAoMIFRo ZSBEYW5pZWwgTW9yYW50ZSBDb21wYW55LCBJbmMuMRgwFgYDVQQLDA9QYWN5IFdvcmxkLCBM TEMxIzAhBgNVBAMMGlBhY3kgV29ybGQgSW50ZXJtZWRpYXRlIENBMB4XDTIxMDMyOTA0Mjc0 NloXDTMxMDMyNzA0Mjc0NlowgaYxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMQ8w DQYDVQQHDAZOYXBsZXMxJjAkBgNVBAoMHVBlcnNvbmFsIElkZW50aXR5IENlcnRpZmljYXRl MRAwDgYDVQQLDAdIb21lIFBDMRcwFQYDVQQDDA5EYW5pZWwgTW9yYW50ZTEhMB8GCSqGSIb3 DQEJARYSZGFuaWVsQG1vcmFudGUubmV0MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKC AgEAyjTH7YpZsiRpbQUpldun7uSfij/VVxewKjq5HusXO81CWrth5nYIe754ASllND1BkJkI Y1eRDDp8fgvEDmddk8+8idUlhcKNhtuGs1Z43Bk6PjQTNefzT2agbgrS+4pZsDG2xEuNx28L y1A0pLzmsUtLDZpuW6wnrN+1KlFnDcBBRjC6cZxGYogcz/Kd35f4OtIXdxNOuBMyJcn2W/h9 YZi6msZejTbp/Hod8sqG5SnoZAVr9rn4X1+/KIDJDItHf10hzX65AgU0NJXIxS5sTP8DStst twAgAXyKjaIE2RTTvxqMhlT1wJCKG5t63PSZ7ZIN8Quy2F2nNJr5MCBkA1+cKC7UDXrHs9xT OsuCf0iOhR3KfN5aRNkR1gdqInqtd/oscWhKByqtIjo/bi77NDcChRMS6gYF+lo5STnhAsFz z9fjNMOQQ4cDdZ0VffTv8wgGUOdo6LHyXI38AQUrJMRFdjiD/ol1j8++rGH9veTtSoLtbKVl YsdYXJ7CQniqS/BuL0PH9q35aDxhz2Thgdb1WpOgb8lpwUliKFaitXk7HUy/t6ThlWDhWtCm bFJcWdTKZoPUIrDxSzHMiVglIhkO33DAYZYBRC9TlhTMYTJJHioXIX+pjZ+xSzklEZo7I5Ob /08lomPW8C9do76EJcqdMEIjbAFTtcLnoTeIXpkCAwEAAaOB4zCB4DAJBgNVHRMEAjAAMA4G A1UdDwEB/wQEAwID+DAdBgNVHQ4EFgQUneNjyWA303ludVIz+7MVlPRjTzMwHwYDVR0jBBgw FoAUfJ3AAHKSNikU0RJBneEKXceyKVUwHQYDVR0RBBYwFIESZGFuaWVsQG1vcmFudGUubmV0 MCcGA1UdJQQgMB4GCCsGAQUFBwMEBggrBgEFBQcDAgYIKwYBBQUHAwgwOwYIKwYBBQUHAQEE LzAtMCsGCCsGAQUFBzAChh9odHRwOi8vd3d3LnBhY3l3b3JsZC5jb20vY2EucGhwMA0GCSqG SIb3DQEBCwUAA4ICAQCNZqZqo1Y8DXGyt6xMuTTya5+aUoIMhcwPpDwsze9l4sjEdrbngjOl lC5Cx0h31mL41oyoPbO3K+qjvbZHORasZRcEA/1uM4v5yV8s9DMlboEDLCwe3sjG7IwNXhcU GvAoVEalg9mQpr0Qfdb/m4VhDvGsqZa0wW7+vl8Sof6tPqIh7blLKwLHQPt1sZ8yYX4Sm2Bk IwpCfuNAniZOWWPQEYw2hVEqh1nhyhKBxt7W8ioEK/we6Nd4ivBjzEo3SmVvGcJHlDBfEOmH TqhMJp+wA30UJx4+4o2Z4frhCVIzhy4mKhLkG9a0Jj/ihJ/Cn/7R4ezDJ+a+FHim+sfsUST1 QhThcj2SIyfDaYqjE+zVx5yfp5aCdKG4xQQzPWZC0FGaBQ4ON6CGUe+XuBssiOXK7tkO5OQf q/qE+82UiwpVrbQ0by12V22zwVk/DiCEVd2L6Fhs2tDbdte2uLPFAhOyc4E7AW7VGjL81arV 0/ACWBdhuCaNOqvsk7koukM2lksY5FGvz4zARKIySjEyj2uI+iRWQFOjO4cea7UZKjHc44gf JBehl/Gdp8cdrAxo7fCnMbH3fYbagq+pF94bLcQZm61zO01Qz7TFfbaDv4YjHOilEAB30JdH JqWjYBp8LFj75VR6Ixt+uUtWVfWKBzlpIBZufbLsWNRzJZo9+5+lzjGCBQEwggT9AgEBMIGQ MIGJMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTEpMCcGA1UECgwgVGhlIERhbmll bCBNb3JhbnRlIENvbXBhbnksIEluYy4xGDAWBgNVBAsMD1BhY3kgV29ybGQsIExMQzEjMCEG A1UEAwwaUGFjeSBXb3JsZCBJbnRlcm1lZGlhdGUgQ0ECAhAdMA0GCWCGSAFlAwQCAwUAoIIC QTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMTExMjAyMjAw MTNaME8GCSqGSIb3DQEJBDFCBECR5GZgDBvQcB2jmFdTl40s3Fu8ONR0Dwm3jHJt8nuOrW3o PyVojK/U59e5FZReMvJ1QlHn1GEamlrj+UFYPhf4MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZI AWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZI hvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgaEGCSsGAQQBgjcQBDGBkzCBkDCB iTELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExKTAnBgNVBAoMIFRoZSBEYW5pZWwg TW9yYW50ZSBDb21wYW55LCBJbmMuMRgwFgYDVQQLDA9QYWN5IFdvcmxkLCBMTEMxIzAhBgNV BAMMGlBhY3kgV29ybGQgSW50ZXJtZWRpYXRlIENBAgIQHTCBowYLKoZIhvcNAQkQAgsxgZOg gZAwgYkxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMSkwJwYDVQQKDCBUaGUgRGFu aWVsIE1vcmFudGUgQ29tcGFueSwgSW5jLjEYMBYGA1UECwwPUGFjeSBXb3JsZCwgTExDMSMw IQYDVQQDDBpQYWN5IFdvcmxkIEludGVybWVkaWF0ZSBDQQICEB0wDQYJKoZIhvcNAQEBBQAE ggIAhWIRk4/dLxlWCUFz95fH9WmcSpvBSOMuEYWBSNyTU62bXhvx4Iz5dT1cpbSlf6BZNae/ F7LKVoL/ufMaWVpaGwSTOdpjkk0JEo64xDO3eX5yBSAeAbLjUNGOiVwl4OVaFO9+0NxSTHgS Zk07k5/YYCKQfWJeS7FifPThsY+jqE70f6Bv5iGM/tgH99bCGkPaeEGL0NjhjfK1UJqKTjk0 fAG4YUJeBhYBJnNOtO++cHYaZxb/GHD9Qnlf2LyHB38XB6I3n/FwruNcwZSO0oZ8+Emao6mv 1joLVWEuRhtppC8j5XTA4A7O0MumJkM+R3UJ8llMjkGDOPuTfcP1bCnxmhPSCfL/CEoD1eqc ymFFqG1DVFZ0FIPWkn/26A4gB48WscORukrwUAoPkJoNnxnFEXuPsXhp7SgziuCpG7038Ili 4UPFI8Kq0gJx/OOL8nZkBfuBDgO7H1OIAgKTLe+fUo9B3wqeeFne6teJR7pnt/l0xDl0JyJS M6YtTriaOitaX9P+anyIE08vK2rxRZ0ttMMkpzur8eoP8GFw55Y7x1P3qYsgVyvPE6g+Fied FE0WS/leIC7k/hj+gm4kJZfxH4KXGjTPsBC/OhVzjcpsxGltzXu6c7LH/HUtMsGNpI7+SDSG MPGg7uBBvzHffeEuucSH41iBkgNbg0o4wvkrySEAAAAAAAA= --------------ms030409090309030700000509-- From nobody Sun Nov 21 01:00:20 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3207E189A21A for ; Sun, 21 Nov 2021 01:00:46 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-il1-f172.google.com (mail-il1-f172.google.com [209.85.166.172]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HxXC13Vjbz4sw7; Sun, 21 Nov 2021 01:00:45 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-il1-f172.google.com with SMTP id l19so14227589ilk.0; Sat, 20 Nov 2021 17:00:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1e4OAsxZps+1I7f74W4aC0yW3Ayw5ypFKxCKW1Pfib0=; b=sDEQ4oQG2xG2177UZsYgGXZU0bgWMcwrqKjfvvW/tgLMSTFsNJcPIMHk3S5GsgakWt DmpRwRXA6vVJz+xG5qWWzYpWhvBP3qr5OEYroL0wM4t5si3FC6uYNAiUAnW/34HIg9cu /cQ8rG9kw4JYa9QkapMyHPd6jIovxfARaNlF9JCJikdSjpPzlTUu5VQ8Q8cNdkasEZIU BUosGaf1umX7megGXRv2dsBqdfmarBb58PBSLkntbdouFRPaXbNUQ5R7WKCae49r452g rK+SXmqYcEasEe/x59Zs9O26Qzm+sRW/2JSxNdfdHCxEE5Hs3b/8Ciz9FKpJiDnbEo7B akaQ== X-Gm-Message-State: AOAM533+dp1W/fc5oMyxGVS4BbP2AOBPyFO6hoL9gSNbS3LwCtYhOFie dGjWr5yspHWPpSlUw8s6hSHy9A9nrP7jyKlIYqAUMRO/XXA= X-Google-Smtp-Source: ABdhPJxTpaJRXpMLgf6B2ZmKreljtRYBXUOcHQrEVrEKCHn1IGWWTMM4jKKRscQqxosyuBKhAMGR8VADm87IPlmjq+4= X-Received: by 2002:a92:b00c:: with SMTP id x12mr5135537ilh.260.1637456438955; Sat, 20 Nov 2021 17:00:38 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Ed Maste Date: Sat, 20 Nov 2021 20:00:20 -0500 Message-ID: Subject: Re: HEADS-UP: ASLR for 64-bit executables enabled by default on main To: Li-Wen Hsu Cc: Marcin Wojtas , freebsd-current , Fabien Thomas , MARECHAL Boris , Rafal Jaworowski , Damien DEVILLE Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4HxXC13Vjbz4sw7 X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.172 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [3.00 / 15.00]; RCVD_TLS_ALL(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FREEFALL_USER(0.00)[carpeddiem]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; NEURAL_SPAM_SHORT(1.00)[1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; ARC_NA(0.00)[]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_SPAM_LONG(1.00)[1.000]; RCPT_COUNT_SEVEN(0.00)[7]; RCVD_IN_DNSWL_NONE(0.00)[209.85.166.172:from]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.166.172:from]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com] X-ThisMailContainsUnwantedMimeParts: N On Thu, 18 Nov 2021 at 13:09, Li-Wen Hsu wrote: > > The mkimg ones are a bit tricky, it seems the output is changed in > each run. We may need a way to generate reproducible results.. Hopefully fixed by 036af1053acd6cae68c5fb6bed30508f2e40be13. From nobody Sun Nov 21 15:50:47 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 290D5189256A for ; Sun, 21 Nov 2021 15:51:46 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-21.consmr.mail.gq1.yahoo.com (sonic310-21.consmr.mail.gq1.yahoo.com [98.137.69.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Hxvz43rXMz3P4x for ; Sun, 21 Nov 2021 15:51:44 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637509897; bh=QZSEXVV7FCogL5NbOUTECsNErnqrYYObbNZQsklWEuA=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=r/T5YcS8y840HIuty/HiQvPzqNyjbk5hspQ5sSgeuyYCM3j0OkhgytCmk8strx3ALKBuwwIzfi63Ke1Qox74gnXT9AuNFLeH/VsRPscVBXcpzePghgOiuyeE7tVyYxfe/tYdQUS9mKVOodMhMqsyNIMZA1Zl8eYIDq0GXOiJoDi5UiL4zvxn1uwjkEioJCjTIIP+LHoS5UKCbj20Zc/75tzv6P40jx+mCZGMzHS5WAA0usYdX7JsuG1Shv4iAuoHyBg5T5vxp3igE9tgNq1/CIy4YmEIrvzOI8oJHtqCUcQjMKI23DKglDhRVBwQgXY+l/xXFcNAllTslkrHh5pwCQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637509897; bh=RFWsQzl2v2I2nXC4DJ3ikpMeKzH5HZFYZZySPTNUrZz=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=Wb0T74S72scCFiulqYyK43FjLU46Fcm2veWZbipoPWgr1d4Vg7gItB3hPcPRBGMgN/sDfN3wtPXV7fyvJQFEHzRwIOr/IDBVH6p2K+g27dXyFCctBFRFVbJ2cQZ2J85olsSBkAyNSeYyHgQLpPr+slVMSe0u/KPUf+qowKGtrE/MhAnil8mxejaa/ZSNnj8HlIjHMyxl87NEkLDehTXjt3HKS+Biu9koVU2nPeCUK5yOiBCuuAOTQNy9qAe2oIDHJwNLO9+n/OYO8CHGKrEdVNDGk6JhQ2jW148qitisI3QLIXTsBHiAm69wM2TeVU4+BSXBRWUdSjbiOcIuGruFKQ== X-YMail-OSG: JKJw9FIVM1m3C82aTQft.Nz141yIMMdHHvkIjLLEbYUqu_jjBC1D.46UhvIqaBD 76teelPRC95TjqqurKg1GvJQWKsK3A.m5X5aMNaWTt1EX44QOeGqjjgrYdIsBFE0PhzVYh8ZUGWc yob_vrPYMYSTa7GyL.9s7SyAcfaudn7.FNX8py6vaChfmi72C8x424aMBAqzLjI_4.RckifbrWQM QyolScqF.uFFHdH68oQcUGVeMJ1X49bKXLSU0bpzwOHOkAj2kxtelrcVLL6PLF.JOnkhwIKZvheH UpNQw3yMm17bqDleVCunGrHHvFtv3vGyVZXXjnpVQIF5T6Ow2pexjDizpdcToKige2GtP4Tkfe_V FXf0R6AuGu.ohMpE0F2damb3qpI41czmbzG8UoX6erGLULRV1hZ6o4pBL1qw8duUae3GZ45qK7Zb PhF80whT92a5OXrjGSGYqCEpdfpzSem3qFGZDDxq75ui63X1g.h9VFhfbLSnoVyYCmtlkrE0_1sb 5pSzL6pKeepSxhM1lwfk.mowX9WdPmUf0w8vk.7BU2bmpQklT4NWHRl5JcZqZT49Vs4tj_rfbeVF QRewH2j1iscJUBes5eD4RTR7YF4.i.1NyCZzd6iksI4lA7lvJZ9aOCfYhM.TdqJlKU9XWi.bdlcm x9j7SbSnEjEh4Xze_XB..zjWJ.8SQL62BD.5bnhbu5OrhjXvooSJTqsckBXQxUcWlq8WqntLxJ0E 8MAfgMDTfKJcSyplM9RQ4l67qZWG_D1WrKwyICrHlpu9kdcakOtJKN_axqZEfy4GaqlymHCy62Zv 1ReeAS1Ig149ba122MtHK9rnw1yYnUTZM8thTSE2JT0ehuo0_frtKvHZbS0Fe8jbZmTSthDwe2M7 jKg.54nvYVgP2y2FD9fGaapr6pWfSUlXiN9GUbAgeLXKPpPto6paQLJJui7ypprVg0SUjRS0l8AT J5QU63NTNklXLDHUeJKVTMhkwkVILd3mNYY8rkNqunfdfmMpo5DgSB_t2UJUO856.Is7w_.1utri nAyk_4mBAAVikslN19T7wHpHDwOaSOU1n7zwcyho6Sk.Ag5IqTElxrfbjn4EfgHbYD.y0KtFauVT K4g7dB21PO74b7bSMwoGPosW6EzmrV7q7KvCmrqc0TtJPo4yBkkA7iMXVC13adzYMhtff4eDzCz9 5Xv7cOCIb3BCeCbtmI.bDArEHWhdc1V7o__Z38q60T5RnRD4TzGLt8xBIDZdH2s79WtScFcesgPe 5EPAfurxpXw9cxI7w8wL2kaONGctNUBHNp5nyYp1j7cWnmgvSJ9eyKcY7BHPHn3nlPg7K6ASQ5V1 I8MZzfdaNJFL_Ymu9bPQHMMVLl4bY_Knvjo24b0dKyVT.zW8yzK5cZmgbqFfPnS07riSExuvowcX .AQUwjyu2shJGVIVLNnYV2rqX6TQDepTBI.j9WSOfSLXORKLsYWnJ9l1XxGl0ewK71unWnhKBppy TQlNZ1cvOqpP_DXdab8ahsoOdNWmCfsenBD_6GPirQA7UaMuvPbxC7PhGe.2NCWiFbBzhf_c0.nm hTGP5Ca0n2NheBOuGzWkrfka5yl9P_q.XIXJVIG9NhsyY.y2IFuoWOENE4LWyqDAvbTVL6mIvwg5 EYqNs0s99_ZkH60bHwlZNY6aOTmP0zEJqInNPLmjTDjTQiOMccI.pDOFXl00f4Mpa2_dK6XNB9u3 qJPW91RMvFt2IHAaLOyPBP9t59ji8IVhcYcKTU17gTHdqjehxOPEBJr3QzhV34qh4cn50xEeeAiJ keuPM7S5BDtoh01Bnv.MXgn.TO9KRA5CqwMzXXpnikc6yDgJGikF3NWf5s8ZIoCCWRuhD9Mfr_6r KCTyqYFwUlGQZzlwmnr7AMIeWAwjwA3utCAcS7GGJ_RuA8_ErErkELPuVFXEzi617qn2zdvzGSSM p9SPc4OuCi2w3aBoPVwWLZtkfrBlbbcidFMjQ_3YwAkA.9RjFAZmoV9eBYiT7.YNDtDDpuxVHP.y z3Jn0pQYDZfC5v2IhHVtOEpwOaex3IIIGk.Xo6OOCtVaj.FKTGaPJ13pr5GXDFuAMTSAmsBS4xPl vQ3v2qMR4.FKBDq8MSm.mT6Ybal_faZbr57erYz1DXaa7.WYVCpPQbjRRzbzKBVIyr6VvrsIN5M8 VELf7NwXZkTJbKkyrU.WAIYvIcBENs4y1kTxI0vYUrd39eXTN8aEbtiUr2fACFNIFA1_KwCaNi4r s7dFCuLUNzW84eujv9AV.t0uOLOLKfZWHS4oYo.b.8g-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Sun, 21 Nov 2021 15:51:37 +0000 Received: by kubenode527.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 200c7f179f811ed8c8d4f0075a2965ea; Sun, 21 Nov 2021 15:50:50 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: aarch64(?) poudiere-devel based builds seem to get fairly-rare corrupted files after recent system update(s?) Date: Sun, 21 Nov 2021 07:50:47 -0800 References: <2CA61249-321C-45AA-9755-597146AB8E9F@yahoo.com> <65AA4BCD-EC4B-4A19-B750-C7FC6E5ADDF5@yahoo.com> <9BF4F65B-6437-4D88-AF34-9BCFBF90D6F3@yahoo.com> <4B591638-4693-4403-8549-88D7A1D9D669@yahoo.com> <0006EB30-B9F9-465A-8B9A-A0C03899CEFC@yahoo.com> To: freebsd-current , "freebsd-arm@freebsd.org" In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4Hxvz43rXMz3P4x X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b="r/T5YcS8"; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.147:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.147:from]; RCVD_COUNT_TWO(0.00)[2] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-current X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Nov-20, at 11:54, Mark Millard wrote: > On 2021-Nov-19, at 22:20, Mark Millard wrote: >=20 >> On 2021-Nov-18, at 12:15, Mark Millard wrote: >>=20 >>> On 2021-Nov-17, at 11:17, Mark Millard wrote: >>>=20 >>>> On 2021-Nov-15, at 15:43, Mark Millard wrote: >>>>=20 >>>>> On 2021-Nov-15, at 13:13, Mark Millard wrote: >>>>>=20 >>>>>> On 2021-Nov-15, at 12:51, Mark Millard wrote: >>>>>>=20 >>>>>>> On 2021-Nov-15, at 11:31, Mark Millard = wrote: >>>>>>>=20 >>>>>>>> I updated from (shown a system that I've not updated yet): >>>>>>>>=20 >>>>>>>> # uname -apKU >>>>>>>> FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #18 = main-n250455-890cae197737-dirty: Thu Nov 4 13:43:17 PDT 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64=20 >>>>>>>> 1400040 1400040 >>>>>>>>=20 >>>>>>>> to: >>>>>>>>=20 >>>>>>>> # uname -apKU >>>>>>>> FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #19 = main-n250667-20aa359773be-dirty: Sun Nov 14 02:57:32 PST 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400042 1400042 >>>>>>>>=20 >>>>>>>> and then updated /usr/ports/ and started poudriere-devel based = builds of >>>>>>>> the ports I's set up to use. However my last round of port = builds from >>>>>>>> a general update of /usr/ports/ were on 2021-10-23 before = either of the >>>>>>>> above. >>>>>>>>=20 >>>>>>>> I've had at least two files that seem to be corrupted, where a = later part >>>>>>>> of the build hits problematical file(s) from earlier build = activity. For >>>>>>>> example: >>>>>>>>=20 >>>>>>>> /usr/local/include/X11/extensions/XvMC.h:1:1: warning: null = character ignored [-Wnull-character] >>>>>>>> =20 >>>>>>>> ^ >>>>>>>> /usr/local/include/X11/extensions/XvMC.h:1:2: warning: null = character ignored [-Wnull-character] >>>>>>>> >>>>>>>> ^ >>>>>>>> /usr/local/include/X11/extensions/XvMC.h:1:3: warning: null = character ignored [-Wnull-character] >>>>>>>> =20 >>>>>>>> ^ =20 >>>>>>>> /usr/local/include/X11/extensions/XvMC.h:1:4: warning: null = character ignored [-Wnull-character] >>>>>>>> >>>>>>>> ^ >>>>>>>> . . . >>>>>>>>=20 >>>>>>>> Removing the xorgproto-2021.4 package and rebuilding via >>>>>>>> poudiere-devel did not get a failure of any ports dependent >>>>>>>> on it. >>>>>>>>=20 >>>>>>>> This was from a use of: >>>>>>>>=20 >>>>>>>> # poudriere jail -j13_0R-CA7 -i >>>>>>>> Jail name: 13_0R-CA7 >>>>>>>> Jail version: 13.0-RELEASE-p5 >>>>>>>> Jail arch: arm.armv7 >>>>>>>> Jail method: null >>>>>>>> Jail mount: /usr/obj/DESTDIRs/13_0R-CA7-poud >>>>>>>> Jail fs: =20 >>>>>>>> Jail updated: 2021-11-04 01:48:49 >>>>>>>> Jail pkgbase: disabled >>>>>>>>=20 >>>>>>>> but another not-investigated example was from: >>>>>>>>=20 >>>>>>>> # poudriere jail -j13_0R-CA72 -i >>>>>>>> Jail name: 13_0R-CA72 >>>>>>>> Jail version: 13.0-RELEASE-p5 >>>>>>>> Jail arch: arm64.aarch64 >>>>>>>> Jail method: null >>>>>>>> Jail mount: /usr/obj/DESTDIRs/13_0R-CA72-poud >>>>>>>> Jail fs: =20 >>>>>>>> Jail updated: 2021-11-04 01:48:01 >>>>>>>> Jail pkgbase: disabled >>>>>>>>=20 >>>>>>>> (so no 32-bit COMPAT involved). The apparent corruption >>>>>>>> was in a different port (autoconfig, noticed by the >>>>>>>> build of automake failing via config reporting >>>>>>>> /usr/local/share/autoconf-2.69/autoconf/autoconf.m4f >>>>>>>> being rejected). >>>>>>>>=20 >>>>>>>> /usr/obj/DESTDIRs/13_0R-CA7-poud/ and >>>>>>>> /usr/obj/DESTDIRs/13_0R-CA72-poud/ and the like track the >>>>>>>> system versions. >>>>>>>>=20 >>>>>>>> The media is an Optane 960 in the PCIe slot of a HoneyComb >>>>>>>> (16 Cortex-A72's). The context is a root on ZFS one, ZFS >>>>>>>> used in order to have bectl, not redundancy. >>>>>>>>=20 >>>>>>>> The ThreadRipper 1950X (so amd64) port builds did not give >>>>>>>> evidence of such problems based on the updated system. (Also >>>>>>>> Optane media in a PCIe slot, also root on ZFS.) But the >>>>>>>> errors seem rare enough to not be able to conclude much. >>>>>>>=20 >>>>>>> For aarch64 targeting aarch64 there was also this >>>>>>> explicit corruption notice during the poudriere(-devel) >>>>>>> bulk build: >>>>>>>=20 >>>>>>> . . . >>>>>>> [CA72_ZFS] Extracting arm-none-eabi-gcc-8.4.0_3: ......... >>>>>>> pkg-static: Fail to extract = /usr/local/libexec/gcc/arm-none-eabi/8.4.0/lto1 from package: Lzma = library error: Corrupted input data >>>>>>> [CA72_ZFS] Extracting arm-none-eabi-gcc-8.4.0_3... done >>>>>>>=20 >>>>>>> Failed to install the following 1 package(s): = /packages/All/arm-none-eabi-gcc-8.4.0_3.pkg >>>>>>> *** Error code 1 >>>>>>> Stop. >>>>>>> make: stopped in /usr/ports/sysutils/u-boot-orangepi-plus-2e >>>>>>>=20 >>>>>>> I'm not yet to the point of retrying after removing >>>>>>> arm-none-eabi-gcc-8.4.0_3 : other things are being built. >>>>>>=20 >>>>>>=20 >>>>>> Another context with my prior general update of /usr/ports/ >>>>>> and the matching port builds: Back then I used USE_TMPFS=3Dall >>>>>> but the failure is based on USE_TMPFS-"data" instead. So: >>>>>> lots more I/O. >>>>>>=20 >>>>>=20 >>>>> None of the 3 corruptions repeated during bulk builds that >>>>> retried the builds that generated the files. All of the >>>>> ports that failed by hitting the corruptions in what they >>>>> depended on, built fine in teh retries. >>>>>=20 >>>>> For reference: >>>>>=20 >>>>> I'll note that, back when I was using USE_TMPFS=3Dall , I also >>>>> did some separate bulk -a test runs, both aarch64 (Cortex-A72) >>>>> native and Cortext-A72 targeting Cortex-A7 (armv7). None of >>>>> those showed evidence of file corruptions. In general I've >>>>> not had previous file corruptions with this system. (There >>>>> was a little more than 245 GiBytes swap, which covered the >>>>> tmpfs needs when they were large.) >>>>=20 >>>>=20 >>>> I set up a contrasting test context and got no evidence of >>>> corruptions in that context. (Note: the 3 bulk builds >>>> total to around 24 hrs of activity for the 3 examples >>>> of 460+ ports building.) So, for the Cortex-A72 system, >>>=20 >>> I set up a UFS on Optane (U.2 via M.2 adapter) context and >>> also got no evidence of corruptions in that context (same >>> hardware and a copy of the USB3 SSD based system). The >>> sequence of 3 bulks took somewhat over 18 hrs using the >>> Optane. >>>=20 >>>> root on UFS on portable USB3 SSD: no evidence of corruptions >>> Also: >>> root on UFS on Optane U.2 via M.2: no evidence of corruptions >>>> vs.: >>>> root on ZFS on optane in PCIe slot: solid evidence of 3 known = corruptions >>>>=20 >>>> Both had USE_TMPFS=3D"data" in use. The same system build >>>> had been installed and booted for both tests. >>>>=20 >>>> The evidence of corruptions is rare enough for this not to >>>> be determinative, but it is suggestive. >>>>=20 >>>> Unfortunately, ZFS vs. UFS and Optane-in-PCIe vs. USB3 are >>>> not differentiated by this test result. >>>>=20 >>>> There is also the result that I've not seen evidence of >>>> corruptions on the ThreadRipper 1950 X (amd64) system. >>>> Again, not determinative, but suggestive, given how rare >>>> the corruptions seem to be. >>>=20 >>> So far the only things unique to the observed corruptions are: >>>=20 >>> root on ZFS context (vs. root on UFS) >>> and: >>> Optane in a PCIe slot (but no contrasting ZFS case tested) >>>=20 >>> The PCIe slot does not seem to me to be likely to be contributing. >>> So this seem to be suggestive of a ZFS problem. >>>=20 >>> A contributing point might be that the main [so: 14] system was >>> built via -mcpu=3Dcortex-a72 for execution on a Cortext-A72 system. >>>=20 >>> [I previously ran into a USB subsystem mishandling of keeping >>> things coherent for the week memory ordering in this sort of >>> context. That issue was fixed. But back then I was lucky enough >>> to be able to demonstrate fails vs. works by adding an >>> appropriate instruction to FreeBSD in a few specific places >>> (more than necessary as it turned out). Someone else determined >>> where the actual mishandling was that covered all required >>> places. My generating that much information in this context >>> seems unlikely.] >>=20 >>=20 >> I started a retry of root-on-ZFS with the Optane-in-PCIe-slot media >> and it got its first corruption (in a different place, 2nd bulk >> build this time). The use of the corrupted file reports: >>=20 >> configure:13269: cc -o conftest -Wall -Wextra -fsigned-char = -Wdeclaration-after-statement -O2 -pipe -mcpu=3Dcortex-a53 -g = -fstack-protector-strong -fno-strict-aliasing -DUSE_MEMORY_H = -I/usr/local/incl >> ude -mcpu=3Dcortex-a53 -fstack-protector-strong conftest.c = -L/usr/local/lib -logg >&5 >> In file included from conftest.c:27: >> In file included from /usr/local/include/ogg/ogg.h:24: >> In file included from /usr/local/include/ogg/os_types.h:154: >> /usr/local/include/ogg/config_types.h:1:1: warning: null character = ignored [-Wnull-character] >> >> ^ >> /usr/local/include/ogg/config_types.h:1:2: warning: null character = ignored [-Wnull-character] >> >> ^ >> /usr/local/include/ogg/config_types.h:1:3: warning: null character = ignored [-Wnull-character] >> >> ^ >> . . . >> /usr/local/include/ogg/config_types.h:1:538: warning: null character = ignored [-Wnull-character] >> . . . (nulls) . . . >>=20 >> So: 538 such null bytes. >>=20 >> Thus, another example of something like a page of nulls being >> written out when ZFS is in use. >>=20 >> audio/gstreamer1-plugins-ogg also failed via referencing the file >> during its build. >>=20 >> (The bulk run is still going and there is one more bulk run to go.) >>=20 >=20 > Well, 528 happened to be the size of config_types.h --and of > config_types.h from a build that did not get the corruption there. >=20 > So looking at the other (later) corruption, which was a bigger file > (looking via bulk -i and installing what contained the file but > looking from outside the jail): >=20 > # find /usr/local/ -name "libtextstyle.so*" -exec ls -Tld {} \; > -rwxr-xr-x 1 root wheel 2339104 Nov 20 01:05:05 2021 = /usr/local/poudriere/data/.m/13_0R-CA7-default/ref/usr/local/lib/libtextst= yle.so.0.1.1 > lrwxr-xr-x 1 root wheel 21 Nov 20 01:05:05 2021 = /usr/local/poudriere/data/.m/13_0R-CA7-default/ref/usr/local/lib/libtextst= yle.so.0 -> libtextstyle.so.0.1.1 > lrwxr-xr-x 1 root wheel 21 Nov 20 01:05:05 2021 = /usr/local/poudriere/data/.m/13_0R-CA7-default/ref/usr/local/lib/libtextst= yle.so -> libtextstyle.so.0.1.1 >=20 > hd = /usr/local/poudriere/data/.m/13_0R-CA7-default/ref/usr/local/lib/libtextst= yle.so.0.1.1 | more > 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| > * > 0023b120 >=20 > So the whole, over 2 MiByte, the whole file ended up with just null = Bytes. >=20 > To cross check on live system caching vs. on disk, I rebooted and = redid the > bulk -i based install of libtextstyle and looked at = libtextstyle.so.0.1.1 : > still all zeros. >=20 > For reference, zpool scrub afterward resulted in: >=20 > # zpool status > pool: zopt0 > state: ONLINE > scan: scrub repaired 0B in 00:01:49 with 0 errors on Sat Nov 20 = 11:47:31 2021 > config: >=20 > NAME STATE READ WRITE CKSUM > zopt0 ONLINE 0 0 0 > nda1p3 ONLINE 0 0 0 >=20 > But it is not a ZFS redundancy context: ZFS used just to use bectl . Using bectl (on the root-on-ZFS Optane in PCIe slot), I booted stable/13 : # uname -apKU FreeBSD CA72_16Gp_ZFS 13.0-STABLE FreeBSD 13.0-STABLE #13 = stable/13-n248062-109330155000-dirty: Sat Nov 13 23:55:14 PST 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/13S-CA72-nodbg-clang/usr/13S-src/arm64.= aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1300520 1300520 and tried the sequence of 3 bulk runs: There was no evidence of corruptions, suggesting that the Optane in the PCIe slot is not the source of the problem of having some file(s) end up with all bytes being null bytes. So, overall, ending up with evidence of corruptions generated during bulk builds seem to be tied to main's [so: 14's] ZFS implementation in: # uname -apKU FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #18 = main-n250455-890cae197737-dirty: Thu Nov 4 13:43:17 PDT 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64=20 1400040 1400040 because that is all that is unique to having the evidence of corruptions. Since there have been ZFS updates in main since then, it seems that the next experiment would be to update main and try again under main. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Sun Nov 21 16:11:25 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9716918A002C for ; Sun, 21 Nov 2021 16:11:53 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f52.google.com (mail-io1-f52.google.com [209.85.166.52]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HxwQJ4FjKz3qjS; Sun, 21 Nov 2021 16:11:52 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io1-f52.google.com with SMTP id p23so20047817iod.7; Sun, 21 Nov 2021 08:11:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vLLTUBDXOjOdg3c0aZnJ7aPhQMK5nfsFFhYnBJNrynE=; b=wSZkbrK0MU98emXce4je/zmPlVWzoXVzgfseAu7pwBQlKujoIfK059OWauhkhMgEea tYRf7rJhQyTTNfNMmCJJ1MtWtp3rYYWPNCMWEBsSa1E8fIB6EzvkhcEKB7nQNg9JWlrZ EN6JYkIS/idj5sIOuSMDpTv/Se8XhUirLZgdAbKXXW+hcsN1hlS32nM+c0XhUcsSuLHn pXihSlIpn8+N8rivD8fuVWTKE7A3A9mvUDry/CwagxbAYJ9f8aHyKhBvXZoYIoB7Ym/S ml+DG5/oMIiIsjuHrA9g1cz/DmHd7tdu1U6kY1L42KiWuY8032rr1HHzcgJ/mXdsntF8 VQiA== X-Gm-Message-State: AOAM532A1o3LJ2nwcau2KQu3HY1qxROKwLne+NfFIFG43un0cXwwLjQH su1QEDx3ehWUKUQ0ebm2LJMjrFLtbx9l+uRY7W3M7A6WlRg= X-Google-Smtp-Source: ABdhPJz3bkODOx837KIYpwYixpsxAs9E5NkvH8h/9rEmbzq/gFNnfR27qzuiYtqMzAuWuWyYoO5/gWQezHhnkNAFOIA= X-Received: by 2002:a5d:818a:: with SMTP id u10mr2239556ion.140.1637511106228; Sun, 21 Nov 2021 08:11:46 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Ed Maste Date: Sun, 21 Nov 2021 11:11:25 -0500 Message-ID: Subject: Re: HEADS-UP: ASLR for 64-bit executables enabled by default on main To: Li-Wen Hsu Cc: Marcin Wojtas , freebsd-current , Fabien Thomas , MARECHAL Boris , Rafal Jaworowski , Damien DEVILLE Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4HxwQJ4FjKz3qjS X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.52 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [3.00 / 15.00]; RCVD_TLS_ALL(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FREEFALL_USER(0.00)[carpeddiem]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; NEURAL_SPAM_SHORT(1.00)[1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; ARC_NA(0.00)[]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_SPAM_LONG(1.00)[1.000]; RCPT_COUNT_SEVEN(0.00)[7]; RCVD_IN_DNSWL_NONE(0.00)[209.85.166.52:from]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.166.52:from]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com] X-ThisMailContainsUnwantedMimeParts: N On Sat, 20 Nov 2021 at 20:00, Ed Maste wrote: > > On Thu, 18 Nov 2021 at 13:09, Li-Wen Hsu wrote: > > > > The mkimg ones are a bit tricky, it seems the output is changed in > > each run. We may need a way to generate reproducible results.. > > Hopefully fixed by 036af1053acd6cae68c5fb6bed30508f2e40be13. The mkimg failures are indeed fixed by the above commit - it was just a latent bug in mkimg. I've opened PR 259968 as a tracking bug for outstanding issues found as a result of enabling ASLR by default, and submitted a PR for each of the three outstanding issues. From nobody Sun Nov 21 23:09:23 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 974D418A8A6E for ; Sun, 21 Nov 2021 23:09:37 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660086.outbound.protection.outlook.com [40.107.66.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Hy5hH6CnQz3M0Z; Sun, 21 Nov 2021 23:09:35 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RASncHC2ONtM/84Eo8WX1Z3QdUqJ/z9zr+M1nLce9Ob55EYCuiXIfFqI52kfEFAe0yTJoXw+/grpf9hS9gl0LTfyAXZJx/Wch9UmXeCfVo6VemHQ+v4ft4rEY4japVGAZNgT2TYUfVSkkdqusDgpQJc2WPlWuvxmzUi8cjrTCyMiBB8kbUyaAu96eoL7idffw/2qqsf9ZiP312QJHZJ4JeTDZlyzeuYydyS3DYv0fBmoYfiHz6Sys7aglBf//5J2Z7vL+X9BI86MeoYPFUOhyC1pMc/GXRfINfQtxh/STa6OWeWXCf7G9MHEE4fon+DZy5muCHNuIp91H20VhFM9fw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=rd+VJxqPB/AUOwyJT7txmg7tdsAQ7+RAfw2rB7j7qOM=; b=TEa+GtI1abDec/lJ9jTNXwULBrACh769lDZEDoknE+3KkwLUJXxg1O81/EbY3hGb5l39lEtrzEQkhc/ed4V9X8BwxU9w07/qVagz5+b2Jibszf1LjG0DN2r9SK4b5FwdXT+En9DyfihdzmJYvwqDEbgj+WcEwsXjhygbewMAcSkIEe1A10toSqtBRcPdrSioRZjiHPKr74P5oanzyLAA9HNO+mFSGZ43JJPpKEtL2VV0QE0DWOrB7f+gCdnhdYtYLKX5DnM6jHA82P7mkLc8opVel2cahgtw1MF+09ZzvOrcVRjlBvGui/oAcpeO9EA0ZlHOUuurHwC7zmkpXKh+Bw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca; dkim=pass header.d=uoguelph.ca; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rd+VJxqPB/AUOwyJT7txmg7tdsAQ7+RAfw2rB7j7qOM=; b=h9G5tf7ecNuXiuDQnpbJyBlExw7EnmX47Xs8Er1nS+mbWD88hAyYdXYSQEqBopbR3B5P0wF+q/hZ6Yi4W99PjymjaxvMjEKc9KcKVpTbtYvQZW0iVJqf7qo2H7Sv0ZcnciyKJ39b9ygf1tbvHBLukaHXR6CfgmVFsKNQhy5059X20lzP3e1wXGARhzJkOZBBNYvm/71RqhX/xV0QCgN8Um40sxruNYV+SqXTkCJ2QaPUQ71YakundKV2myiWwSAWimOEvLrdbJNRI3Y17GJyNTCYJmZB5OoE8UohVrQiXGWikRw6PgOTUX+tr8BB2swl/yUpE9I5d8dv0LFEhCcxvA== Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:19::29) by QB1PR01MB2868.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:3f::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4713.19; Sun, 21 Nov 2021 23:09:28 +0000 Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::e56f:b7a2:3830:5706]) by YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::e56f:b7a2:3830:5706%3]) with mapi id 15.20.4713.024; Sun, 21 Nov 2021 23:09:23 +0000 From: Rick Macklem To: FreeBSD Current CC: "dfr@freebsd.org" Subject: Anyone know why /etc/rc.d/lockd REQUIRES nfsd? Thread-Topic: Anyone know why /etc/rc.d/lockd REQUIRES nfsd? Thread-Index: AQHX3ysLQsAK0XC930ixT+cyJVg2Sw== Date: Sun, 21 Nov 2021 23:09:23 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: 0f371d6d-1e2a-8f0f-db3a-7e11a77b09eb x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0aca609e-d2bc-4cdb-0e8e-08d9ad43f4ee x-ms-traffictypediagnostic: QB1PR01MB2868: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: SSS+9FNFgME3IPR22CAhqxpKlCMlTJ9iGSig2ykhSYb7G3NCRsB4V1JVC36PCJ2mQ7RUURkIwIHchMJpMAKgSwZ6SwE4KbhTkJ+sEH77/yUr5SnTA8e6gKbZNZWbWfWI0lIOXLsVw30y5n8yowX1gkLYUb2CLtbatpCglaAs5QdaElv90/iSzyopObJE6LvWgkMbOCsC/PS4eJd7IgLuUaEmz4XTh/Jp0K0OMiWGm1NPXMYTdCjMPPjWQmCy3rVKND8W8ZMFBh88+fOckfG0OaoWZIM1bGemrWffMbf5JLX/l77wcAloqAO2g9gozYpF0tZO3XYreYqf8a3oNCGjYH87y4Wiii7CH60R/Wiy6TDhvguKPkEWsSyAFG0/UEvX6j2Mw/iKFi5ynjwQERmMvH1O2rEYZMS8545vvKFZOQl8tggxeLu5CJvBAz58JlW7aj15NcChbBmD2TXwkf96mHGtBrzkX766K2BGh/E3H3duWoBIpExbExK+tuQGPQ2xIJGHuHSbRHAUzpdxuuqvko05vG3DwWKzPuSrZKZx4dDkzInYOzVc9eYfe5zUbxDmPqxieRGCeu3V/YhMbOtN9FeaqQCM+KvsgEVlaqHNkgvNFpB0O3TiRuXPH2EXdu0dMmO2bKyxiAUPtY4Tt5UBuGeaFRrl+JVr2gmhy7vKemQot6OXczwTTK9rhzaiJuWZfnKlPj8JzLLWknr9sv6Gsw== x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(366004)(7696005)(76116006)(450100002)(786003)(508600001)(8936002)(71200400001)(6916009)(52536014)(4326008)(38100700002)(33656002)(5660300002)(38070700005)(8676002)(6506007)(186003)(2906002)(316002)(66446008)(64756008)(91956017)(66556008)(66946007)(66476007)(83380400001)(86362001)(55016002)(122000001)(9686003);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?4fp3EA4WMU3cniRgF/2PVdFR7gH6Nfj6PDQxtt/7lXUlBD7srXwAPNUTcp?= =?iso-8859-1?Q?KmrEjstBxHW53Ba2nkXF2GU9nTtMXRfEHE++eOBj8yYMMsiE9QDimoX1/8?= =?iso-8859-1?Q?EGvBM/nHmwnnDCTQeqOI1Mf9N23yyC5oZF6cf6aM3KXVOe4SHNGMiFJwXm?= =?iso-8859-1?Q?uzzflkZiz67IPIL7NqxzM6SkOt2WOkir6BxwkThaRnbymm4vrT+Z7Yasbe?= =?iso-8859-1?Q?ROE/JJ/rcMTK8LGFcw2wPux/2bZniY71bma1oPEL8mdK8p9TpOjVdt6xCM?= =?iso-8859-1?Q?7jSkl/AbS9O975iFfJb22E7zs1NJPsdyI2r7obAVZkTZ4gyR0DUh6UPK4N?= =?iso-8859-1?Q?pZ6BRPRh3gCjeiko3gl5TmTkj/6ZDjhod81uJcWXlt+S6IDuqWx9fOCEq2?= =?iso-8859-1?Q?UH8GmSEYV9IUNPjedkdCo1K7rwVbH4RsLqmhfR0dHFYq9v4gxO4xPo9xDD?= =?iso-8859-1?Q?2ofkmUaPeKkXVrE/7h+WsTF/SkHmBi8KsndPRlJ2dG4cbxNRNSzcyzuAl+?= =?iso-8859-1?Q?EAS2Ro36kVvDUS+KW2gl8ZhPXJgFTjX4yseSPOjnDN2nV9l9n4W5zqDbFp?= =?iso-8859-1?Q?DMYyMq+xT2cPsXzKy/OP0gXU2FiDspWvJo7MptxctDKh2L7Vo2lgokEahJ?= =?iso-8859-1?Q?wnTaGh8SCQircANeXSSYi6NPm96zvw/0ldyxbC27zMYxwjXR8NwC9kOKXH?= =?iso-8859-1?Q?wkXCwOODbqwX+lI2Cs/PQZzEAJk3xTp+HxCj8bzO5DrlApg3UfXDFtRS7l?= =?iso-8859-1?Q?jONyMqsdGiuqYZIRDxUzlc7MG1Vn9lWXdUN6Izvsyb2Ltc9EGRzXbHJlh5?= =?iso-8859-1?Q?hxi9xkqJ8CxPltfhq3yLUZtWPQPcJiNLHt+DvLOiIaTzuYjKRPKjJBPg2b?= =?iso-8859-1?Q?bNy25o3nQBUtHhKFpijHm4SIS4y4BINJ6Kj2+ZSbGOBOqfSTsLc0hlQoAx?= =?iso-8859-1?Q?eKgPgeNPyoenrkNhFGVx554fyyh8YQANp3k3aLvm3ndCr8IPY+4KUM3B6W?= =?iso-8859-1?Q?mfL6rxfn8uU1GyV1mHB8m0Y6Rtm+p8rhPr3sfgaGRY99L2pMjlRbvhYYBX?= =?iso-8859-1?Q?7db7hC6P3RMW8gNa4XgBj2pEP2mm/8aS/0T/wahjB6ldNU5lPvu3PcmyuU?= =?iso-8859-1?Q?bktI2z3iPqF9MjNIc5o+rXAQgiz+6v/7Z+vvtdW+5h36zOT4mUbs5af9SU?= =?iso-8859-1?Q?3Dj0965Hl1A94ExeKLKcA66ueWD4jK71mK/dRK84J5mFIRB9S/8WT5CxBe?= =?iso-8859-1?Q?8pE6L56vAigYLRosEpwycGcTn+KLSbmc18osKnWDraLa9qQDxqD5MtUTQg?= =?iso-8859-1?Q?AhiDg+yG6+aqUV9VpT2kp8rYC80KaHkKjm0EXQZ08PzCFztfw4JeCgEeDu?= =?iso-8859-1?Q?+vpNUWI9Pmq/4/bOuz4og1G++6uW/qRmx6+CJWDPOySe9EOnDbBGKfl4dn?= =?iso-8859-1?Q?meluw5AKPWopScEEKVsuOIbevh5y8RP8kC5ZZZFxzwKyNLJjZCpKGg/gdF?= =?iso-8859-1?Q?DEUUfUMgavQUcIeDY9dWxuNois8MmOj9aJML0Ci2yMiA8YyCFZKjnj/5Uz?= =?iso-8859-1?Q?joEnDKgzrQUqtVsbDhpE+MBYU5WsfF6f6TBgGAJUSE/JHi8VW8Ohn4vaKx?= =?iso-8859-1?Q?3MF63PPbp6juXKJiLtvhmqyb5K/WFyJmSaznuo5oVk/VBJwONYyu0lx22x?= =?iso-8859-1?Q?yKVBguuhfLiuv8fUTq6sqPGONGO+fPaOo7aO1QWx61TqDINHGL3r5Ix1LW?= =?iso-8859-1?Q?GqKA=3D=3D?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 0aca609e-d2bc-4cdb-0e8e-08d9ad43f4ee X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Nov 2021 23:09:23.2362 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: kVCCdO2b55o01+juCq8NeW6FkoVn9tISOiqCc110Zn7VsFNuO0fsCRXGOZlPH2bTUI+BIDk1sC3zYLp33h518Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: QB1PR01MB2868 X-Rspamd-Queue-Id: 4Hy5hH6CnQz3M0Z X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=uoguelph.ca header.s=selector2 header.b=h9G5tf7e; arc=pass ("microsoft.com:s=arcselector9901:i=1"); dmarc=pass (policy=none) header.from=uoguelph.ca; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.66.86 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-5.00 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector2]; FREEFALL_USER(0.00)[rmacklem]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; DWL_DNSWL_LOW(-1.00)[uoguelph.ca:dkim]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[uoguelph.ca:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[40.107.66.86:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[uoguelph.ca,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US]; RCVD_TLS_LAST(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.66.86:from] X-ThisMailContainsUnwantedMimeParts: N Hi,=0A= =0A= PR#254282 reports a problem where nullfs mounts cannot be=0A= exported via mountd for FreeBSD 13.0.=0A= =0A= The problem seems to be that, to do the nullfs mounts in=0A= /etc/fstab, they require the "late" mount option, so that the=0A= underlying filesystem is mounted (ZFS for the PR).=0A= =0A= Adding "mountlate" to the REQUIRE list in /etc/rc.d/mountd=0A= fixes the problem, but that results in a dependency cycle=0A= because /etc/rc.d/lockd specifies:=0A= # REQUIRE: nfsd=0A= # BEFORE: DAEMON=0A= --> which forces mountd to preceed DAEMON.=0A= =0A= I think I know why lockd specifies:=0A= # BEFORE: DAEMON=0A= --> I suspect that some daemon requires file locking and that=0A= requires lockd to be running, for an NFS mounted root fs.=0A= =0A= However, I cannot think of any reason that nfsd must be running=0A= before lockd is started. The "REQUIRE: nfsd" seems to have been=0A= inherited from NetBSD when first imported to FreeBSD about 20=0A= years ago.=0A= =0A= So, can anyone see why lockd might need nfsd running first?=0A= (Without "# REQUIRE: nfsd" in lockd and statd, "# REQUIRE: mountlate"=0A= can be added to /etc/rc.d/mountd without creating a dependency cycle=0A= and seems to fix the problem in the PR during limited testing.)=0A= =0A= =0A= rick= From nobody Mon Nov 22 16:47:34 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E29CF188FE6E for ; Mon, 22 Nov 2021 16:47:49 +0000 (UTC) (envelope-from ctuffli@gmail.com) Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HyY9J6SSvz3qDf for ; Mon, 22 Nov 2021 16:47:48 +0000 (UTC) (envelope-from ctuffli@gmail.com) Received: by mail-ed1-x534.google.com with SMTP id z5so79986751edd.3 for ; Mon, 22 Nov 2021 08:47:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=mnVdeZy7X8noq1PUJBJ1bHal3G0Hh5H2KF0XdJ7PHto=; b=LP+vYRgD85CxiIjVoMXfa6qa+5X8MWUddvnTRIV5Dgl/oPMjOyEqt6ZjtsqQ5VMyiV XLWYcJV/mpkKwakGWQXezHfB1i17oKI23v1d1FA3Y0wLGaTiwS6lpPhfbEcOj4IeL/iY Qot9/vpcyqjoSqphjCx4kmk9z+Uwv1uKxi6rYQbr2urSMdD0CPcUUUpeGHt0FwQzxQ+j Y8cHUynKXzwD3pOaPcHAd7o5JZOYDu3cRnJjvb/qlsOCr8kORzVLWYaaqLAk/A4+wltO /KIGdq2CnAKshKeap41OW8z9695mHEB+4ttY8NQqISNCdaHCDtoV2+Fiid+3sbNsCikf AgzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=mnVdeZy7X8noq1PUJBJ1bHal3G0Hh5H2KF0XdJ7PHto=; b=qWCXJt5Rc/kxon7AHHEF0kNUx2n150iuTBsjxp/WiNVkOmThrmgc0wrCboxatJm0oE rqapGlfhpqw3QcwuZPZv6hu9w1uqNG2IeEmRIUg1GrnGiT5fy25USsgbUAYh/ZnXUJ6M RUAgCIP4K8PQTezt0wjB6d17DiPfmFCmLSyHjepU8q9mjSpYWBiV9o23UuxZ89qbK6Oe jVZNZQfFuNQOZfXpjYDAfovHxdcx4w82B+HbMmXEzy5GV6JGv0ao2s1aNvDKzI/PztZz r/uuA9SbMihJzSMcQ2JIkVqKYSJvC0KJATxZ4P5KeEoqEm0qsl+tTRj9UXcEB9KvgFGL Oj+A== X-Gm-Message-State: AOAM531PenXSPmEJveYCXecBHGipif8WcBInmdN14XkB9LBXlbd+37vy x2RA6qfGqMwQKvOgL3am52X20nQZS+zbf0k35bCdIY9iGAlN0Q== X-Google-Smtp-Source: ABdhPJxL3jkhBrcq4n884zytQhdr7g/U/0TNydiBQf94tYZxsvTD2dsAL5O66++bfGiQg+2rOu5hV6F9Er3zWzfdfKo= X-Received: by 2002:a17:907:d9f:: with SMTP id go31mr43744889ejc.412.1637599667004; Mon, 22 Nov 2021 08:47:47 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 From: Chuck Tuffli Date: Mon, 22 Nov 2021 08:47:34 -0800 Message-ID: Subject: problem with re(4) interface To: FreeBSD-Current Content-Type: multipart/alternative; boundary="0000000000006fb99305d16362e2" X-Rspamd-Queue-Id: 4HyY9J6SSvz3qDf X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=LP+vYRgD; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of ctuffli@gmail.com designates 2a00:1450:4864:20::534 as permitted sender) smtp.mailfrom=ctuffli@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; URI_COUNT_ODD(1.00)[3]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-0.995]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::534:from]; HTTP_TO_IP(1.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: Y --0000000000006fb99305d16362e2 Content-Type: text/plain; charset="UTF-8" Running on a recent-ish -current # uname -a FreeBSD stargate.tuffli.net 14.0-CURRENT FreeBSD 14.0-CURRENT main-81b22a9892 GENERIC amd64 I'm having trouble using the second NIC interface in a bridge to provide network connectivity to bhyve VMs and need some help figuring out what is wrong. The system is an AMD Ryzen mini-pc (UM250) with two RealTek gigabit NICs (8168/8111). The second NIC (re1) is a member of a bridge. A configuration similar to this works on a different system with Intel NICs, but on this system, the VMs aren't able to connect to the network. I've done the easy things and verified, for example, the interface can pass traffic (i.e. hardware, cable, switch are fine). There are some additional "odd" things. For example, ifconfig doesn't configure an address or even enable the interface. E.g., # ifconfig re1 10.0.0.10/24 up # ifconfig re1 re1: flags=8902 metric 0 mtu 1500 options=82099 ether 1c:83:41:28:c9:e4 media: Ethernet autoselect (1000baseT ) status: active nd6 options=29 The command does appear to enable/disable the port: # tail -f /var/log/messages Nov 22 08:31:03 stargate kernel: re1: link state changed to DOWN Nov 22 08:31:11 stargate kernel: re1: link state changed to UP Note that setting the interface's address from rc.conf works, but after the system boots, setting the address from the command line doesn't. What else should I check? # ifconfig -a -G lo re0: flags=8843 metric 0 mtu 1500 options=8209b ether 1c:83:41:28:c9:e3 inet 192.168.5.10 netmask 0xffffff00 broadcast 192.168.5.255 media: Ethernet autoselect (1000baseT ) status: active nd6 options=29 re1: flags=8902 metric 0 mtu 1500 options=82099 ether 1c:83:41:28:c9:e4 media: Ethernet autoselect (1000baseT ) status: active nd6 options=29 vm-public: flags=8843 metric 0 mtu 1500 ether 46:76:29:af:7b:fa id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: tap0 flags=143 ifmaxaddr 0 port 5 priority 128 path cost 2000000 member: re1 flags=143 ifmaxaddr 0 port 2 priority 128 path cost 20000 groups: bridge vm-switch viid-4c918@ nd6 options=9 tap0: flags=8943 metric 0 mtu 1500 description: vmnet-freebsd-0-public options=80000 ether 58:9c:fc:10:ff:f6 groups: tap vm-port media: Ethernet autoselect status: active nd6 options=29 Opened by PID 38298 --chuck --0000000000006fb99305d16362e2-- From nobody Mon Nov 22 16:48:51 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B0256189177D for ; Mon, 22 Nov 2021 16:48:53 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HyYBY3HWkz3r8J; Mon, 22 Nov 2021 16:48:53 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from [IPV6:2601:648:8601:8b20:7de4:e77a:791:6f5] (unknown [IPv6:2601:648:8601:8b20:7de4:e77a:791:6f5]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 859859161; Mon, 22 Nov 2021 16:48:52 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: Date: Mon, 22 Nov 2021 08:48:51 -0800 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: "Khelp module "ertt" can't unload until its refcount drops from 1 to 0." after "All buffers synced."? Content-Language: en-US To: tuexen@freebsd.org, Mark Millard Cc: freebsd-current References: <119DC979-EC2C-4BE4-A6E8-2DBF222115A0.ref@yahoo.com> <119DC979-EC2C-4BE4-A6E8-2DBF222115A0@yahoo.com> <52374B7E-6ABB-4E55-984C-B7EC82B48506@freebsd.org> <3A646420-0FB9-4C58-BA97-EE1040958B6E@freebsd.org> From: John Baldwin In-Reply-To: <3A646420-0FB9-4C58-BA97-EE1040958B6E@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N On 11/19/21 4:29 AM, tuexen@freebsd.org wrote: >> On 19. Nov 2021, at 00:11, Mark Millard wrote: >> >>> On 2021-Nov-18, at 12:31, tuexen@freebsd.org wrote: >>> >>>> On 17. Nov 2021, at 21:13, Mark Millard via freebsd-current wrote: >>>> >>>> I've not noticed the ertt message before in: >>>> >>>> . . . >>>> Waiting (max 60 seconds) for system thread `bufspacedaemon-1' to stop... done >>>> All buffers synced. >>>> Uptime: 1d9h57m18s >>>> Khelp module "ertt" can't unload until its refcount drops from 1 to 0. >>> Hi Mark, >>> >>> what kernel configuration are you using? What kernel modules are loaded? >> >> The shutdown was of my ZFS boot media but the machine is >> currently doing builds on the UFS media. (The ZFS media is >> present but not mounted). For now I provide information >> from the booted UFS system. The UFS context is intended >> to be nearly a copy of the brctl selection for main [so: 14] >> from the ZFS media. Both systems have been doing the same >> poudriere builds for various comparison/contrast purposes. >> The current build activity will likely take 16+ hrs. > Hi Mark, > > thanks a lot for the information. I was contemplating whether this message > was related to a recent change in the TCP congestion module handling, but > since it was already there in February, this is not the case. Will try to > reproduce this, but wasn't able up to now. The congestion control changes just probably exacerbated the bug by adding a new reference on this module, just as they exposed the bug with khelp using the wrong SYSINIT subsystem. -- John Baldwin From nobody Mon Nov 22 17:33:36 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4889718AAAEB for ; Mon, 22 Nov 2021 17:33:50 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "ultimatedns.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HyZBP6ggHz4fGh for ; Mon, 22 Nov 2021 17:33:49 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.16.1/8.16.1) with ESMTP id 1AMHXar1030871 for ; Mon, 22 Nov 2021 09:33:42 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Date: Mon, 22 Nov 2021 09:33:36 -0800 From: Chris To: freebsd-current@freebsd.org Subject: Re: problem with re(4) interface In-Reply-To: References: User-Agent: UDNSMS/17.0 Message-ID: X-Sender: bsd-lists@bsdforge.com Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4HyZBP6ggHz4fGh X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; local_wl_ip(0.00)[24.113.41.81] X-ThisMailContainsUnwantedMimeParts: N On 2021-11-22 08:47, Chuck Tuffli wrote: > Running on a recent-ish -current > # uname -a > FreeBSD stargate.tuffli.net 14.0-CURRENT FreeBSD 14.0-CURRENT > main-81b22a9892 GENERIC amd64 > > I'm having trouble using the second NIC interface in a bridge to provide > network connectivity to bhyve VMs and need some help figuring out what is > wrong. > > The system is an AMD Ryzen mini-pc (UM250) with two RealTek gigabit NICs > (8168/8111). The second NIC (re1) is a member of a bridge. A configuration > similar to this works on a different system with Intel NICs, but on this > system, the VMs aren't able to connect to the network. I've done the easy > things and verified, for example, the interface can pass traffic (i.e. > hardware, cable, switch are fine). There are some additional "odd" things. > For example, ifconfig doesn't configure an address or even enable the > interface. E.g., > > # ifconfig re1 10.0.0.10/24 up > # ifconfig re1 > re1: flags=8902 metric 0 mtu 1500 > > options=82099 > ether 1c:83:41:28:c9:e4 > media: Ethernet autoselect (1000baseT ) > status: active > nd6 options=29 > > The command does appear to enable/disable the port: > # tail -f /var/log/messages > Nov 22 08:31:03 stargate kernel: re1: link state changed to DOWN > Nov 22 08:31:11 stargate kernel: re1: link state changed to UP > > Note that setting the interface's address from rc.conf works, but after the > system boots, setting the address from the command line doesn't. What else > should I check? > > # ifconfig -a -G lo > re0: flags=8843 metric 0 mtu 1500 > > options=8209b > ether 1c:83:41:28:c9:e3 > inet 192.168.5.10 netmask 0xffffff00 broadcast 192.168.5.255 > media: Ethernet autoselect (1000baseT ) > status: active > nd6 options=29 > re1: flags=8902 metric 0 mtu 1500 > > options=82099 > ether 1c:83:41:28:c9:e4 > media: Ethernet autoselect (1000baseT ) > status: active > nd6 options=29 > vm-public: flags=8843 metric 0 mtu > 1500 > ether 46:76:29:af:7b:fa > id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 > maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 > root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 > member: tap0 flags=143 > ifmaxaddr 0 port 5 priority 128 path cost 2000000 > member: re1 flags=143 > ifmaxaddr 0 port 2 priority 128 path cost 20000 > groups: bridge vm-switch viid-4c918@ > nd6 options=9 > tap0: flags=8943 metric 0 > mtu 1500 > description: vmnet-freebsd-0-public > options=80000 > ether 58:9c:fc:10:ff:f6 > groups: tap vm-port > media: Ethernet autoselect > status: active > nd6 options=29 > Opened by PID 38298 Because there's subtle differences between them; are you using the re driver from base, or from ports? > > --chuck --Chris From nobody Mon Nov 22 17:50:00 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 574F5188AEDB for ; Mon, 22 Nov 2021 17:50:18 +0000 (UTC) (envelope-from ctuffli@gmail.com) Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HyZYQ1vqsz4m7n for ; Mon, 22 Nov 2021 17:50:18 +0000 (UTC) (envelope-from ctuffli@gmail.com) Received: by mail-ed1-x52f.google.com with SMTP id x6so68467291edr.5 for ; Mon, 22 Nov 2021 09:50:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3sn2sKTQVhGS7rHThGVmNs/eABbrDkqjkq+3ZZE/Ywc=; b=buiIPIcmKukOXwQuMV4m0ziLNdtwg9ANcAVQzTUODcI9jAn/xniAxxQy39OGe1KRvD ++guUFmWewEu/BMUldVKW7a9sy0/Ic/YjjPhaXhf2uoCwQv1PbB7TnuW6TNZY762fGrQ TdxN7N7SHFP68ZHgye0LYnsctD03GVExISE4MgU4HkVdwBDOgdxxpf3Lga9ByEvOTYcW hF/+Z7mVEhdjglk2vXgpUQ/qHC5IAZ1zyirr/dcKtQxIO+b2ZvmZQ/L44Wkqrn1WMM9v ToJemqmhqJsf5peg0TxOkSaHRIIF6X373Es2MLEEe84vk8tYj0TeWkC2pqeIsxyZAmbF uBvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3sn2sKTQVhGS7rHThGVmNs/eABbrDkqjkq+3ZZE/Ywc=; b=Vjp19JS0kNBWR4xCvtauvbURPbopDRe555WX1k0k1NwdFqH9UxpHhOQIGVhc7NNfF1 57ZyJmS+gpp20r5yHkVUcBgTxePWg0KgccfO2/OK2ApIhyjXkJSF/XHU19nL4kAaCIW9 wXh/P+cGlkQkiO2RT3P2kAy2mvcZyhhw752Xe6fpW8+8Z+fdFL+Rys9e1G6v4Z+BhVxa HIBRariSEb84BIDrkvhytN6rArwvCSUcSWrENfL6eXM1HpSpGYfP6uHEDqLJG+jtmOKU 5lH3lSrMhjnuyHIWZSlB5ZscJcONKyCtTkisaPNh2bjoKqXoruS5Fc6JgloNXinL+NOx pRRg== X-Gm-Message-State: AOAM533raa92s7ARiXL8GPqdGz/jEIbXDx8F6ljgH3HlREPPV9/++x1D 8qkzyM84gXY8uTjj2a2sVMisPruza9IXmtH2HRbkgEIAoo4= X-Google-Smtp-Source: ABdhPJzjqs42S6iW5cq3BUGWa5QvV1ZnDMAeKg/7CnNFdlO42ll8vRPjIWELHzRlHTtFlRjNtzGnvzJgkSuHxfM/lWE= X-Received: by 2002:a17:906:f856:: with SMTP id ks22mr42049616ejb.367.1637603411610; Mon, 22 Nov 2021 09:50:11 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Chuck Tuffli Date: Mon, 22 Nov 2021 09:50:00 -0800 Message-ID: Subject: Re: problem with re(4) interface To: Chris Cc: FreeBSD-Current Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4HyZYQ1vqsz4m7n X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Mon, Nov 22, 2021 at 9:34 AM Chris wrote: > > On 2021-11-22 08:47, Chuck Tuffli wrote: > > Running on a recent-ish -current > > # uname -a > > FreeBSD stargate.tuffli.net 14.0-CURRENT FreeBSD 14.0-CURRENT > > main-81b22a9892 GENERIC amd64 > > > > I'm having trouble using the second NIC interface in a bridge to provide > > network connectivity to bhyve VMs and need some help figuring out what is > > wrong. ... > Because there's subtle differences between them; are you using the re driver > from base, or from ports? The driver is from base. Didn't realize there was one in ports. --chuck From nobody Mon Nov 22 17:55:08 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 79218188F0AF for ; Mon, 22 Nov 2021 17:55:25 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vk1-xa2b.google.com (mail-vk1-xa2b.google.com [IPv6:2607:f8b0:4864:20::a2b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HyZgK2sVFz4pmf for ; Mon, 22 Nov 2021 17:55:25 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vk1-xa2b.google.com with SMTP id j1so10824410vkr.1 for ; Mon, 22 Nov 2021 09:55:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XQFRBKPA9sU1lynP492oTKkZRNcOImaPcehzlZvSmJU=; b=yYrw6BrFUFAq4c4YnbRpO1N1kCbKvlzxF8sWDLqIG03iRrtNioGlVemAbOGS+n6YPg 63DrcOLBqtsPGp7y9O9ekuF7uAuyZNx9MS3e0HYmqbOrccPI+GQSzCucfqRdD7LOVu6y 4hlfjYC27PxOofYmUGdCbWzvCSrkYCtjdUpIDwR8b690+IJyY/GyUY0QwWw2aobHGbfD vlh8RZfu9ck8wl+dmKll92wK+WcZ+5I1NJ+UG2hntw35dMX7ecPp63yOgx11nxe5DKnf 61g8GeoxNRXHthTsUqBLIVIh82pVt2GVeGHAP4cqKhH0Q27hCSoZTcWWQeDGXvgLlOB2 PH8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XQFRBKPA9sU1lynP492oTKkZRNcOImaPcehzlZvSmJU=; b=ygnoI1kKYw+cJfwpZ2jRMyVmCNQxfWfmXdrGifMnJNHPLtREsGTGTUi06y9OHmIEG3 H8gQEFoq+UTMaRnLSvdvIqOYI5Cu6207eIC5/MuK/cRGOT04C2nb7kn2XrPi06C41lb4 EihGqLRoFl+AHcdO0yFzNzQOpP2vtG/4tHdIPIjQYHjgZNiDXwM+9ci3QiKvTCFr6gxz jjxn/uoXnvfS+9098eKcQDUaXlH/+0l9+KX7YTqBN3JlqLigr2mr+Yyd+7PqblAN9oJZ YshNFq3BWj10gMeEprdW+PULGDvx0ugyH5WDO5PZC5aOa+h3qCFMfg6JVQMpdsudiH6a RfdQ== X-Gm-Message-State: AOAM532y1tNYpUWnPItujHr+iaTsbHBYnKQ2LKHL38aod+TJOl5qnTud Q3Bad1B9aoMbn5DwSIXVcc1vQM3oDnQb/lXKqMZ8IvqX24HpvQ== X-Google-Smtp-Source: ABdhPJwsz6cMUnsEtCD1LeYMCHHWDyHRYEWS6V0LLjubTmmq2gnnWPrGP+obXxNJ5VhXkj/D2+By9yUb5qiraXqdZV4= X-Received: by 2002:a05:6122:114c:: with SMTP id p12mr164380593vko.21.1637603718874; Mon, 22 Nov 2021 09:55:18 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Mon, 22 Nov 2021 10:55:08 -0700 Message-ID: Subject: Re: problem with re(4) interface To: Chuck Tuffli Cc: Chris , FreeBSD-Current Content-Type: multipart/alternative; boundary="000000000000f266fc05d1645323" X-Rspamd-Queue-Id: 4HyZgK2sVFz4pmf X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --000000000000f266fc05d1645323 Content-Type: text/plain; charset="UTF-8" On Mon, Nov 22, 2021 at 10:51 AM Chuck Tuffli wrote: > On Mon, Nov 22, 2021 at 9:34 AM Chris wrote: > > > > On 2021-11-22 08:47, Chuck Tuffli wrote: > > > Running on a recent-ish -current > > > # uname -a > > > FreeBSD stargate.tuffli.net 14.0-CURRENT FreeBSD 14.0-CURRENT > > > main-81b22a9892 GENERIC amd64 > > > > > > I'm having trouble using the second NIC interface in a bridge to > provide > > > network connectivity to bhyve VMs and need some help figuring out what > is > > > wrong. > ... > > Because there's subtle differences between them; are you using the re > driver > > from base, or from ports? > > The driver is from base. Didn't realize there was one in ports. > The ports driver is tricky... It's an older, buggier version of the base driver... *BUT* a number of issues that aren't fixed in base are fixed in it (mostly dealing better with errata)... Ideally, we'd pull in the actual fixes from this driver, but it's a huge patch-set where it's unclear which bits are for what thing fixed, so nobody (that I know of) has gone through and even come up with an ugly patch for -current. Warner --000000000000f266fc05d1645323-- From nobody Mon Nov 22 18:40:21 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 2D8FE18AC82C for ; Mon, 22 Nov 2021 18:40:25 +0000 (UTC) (envelope-from se@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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HybgF0H8dz3jK0; Mon, 22 Nov 2021 18:40:25 +0000 (UTC) (envelope-from se@freebsd.org) Received: from [IPV6:2003:cd:5f2e:2500:c0bb:26f6:805a:a20b] (p200300cd5f2e2500c0bb26f6805aa20b.dip0.t-ipconnect.de [IPv6:2003:cd:5f2e:2500:c0bb:26f6:805a:a20b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: se/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 438499BEE; Mon, 22 Nov 2021 18:40:24 +0000 (UTC) (envelope-from se@freebsd.org) Message-ID: <60683883-6673-3e24-a040-4188d1e22556@freebsd.org> Date: Mon, 22 Nov 2021 19:40:21 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Subject: Re: problem with re(4) interface Content-Language: en-US To: Warner Losh , Chuck Tuffli Cc: Chris , FreeBSD-Current References: From: Stefan Esser In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------yWseIeoipEBVh79Pe10yL8Cf" X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------yWseIeoipEBVh79Pe10yL8Cf Content-Type: multipart/mixed; boundary="------------00wRUFVtLXmuuDRiEB4atMA1"; protected-headers="v1" From: Stefan Esser To: Warner Losh , Chuck Tuffli Cc: Chris , FreeBSD-Current Message-ID: <60683883-6673-3e24-a040-4188d1e22556@freebsd.org> Subject: Re: problem with re(4) interface References: In-Reply-To: --------------00wRUFVtLXmuuDRiEB4atMA1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am 22.11.21 um 18:55 schrieb Warner Losh: > On Mon, Nov 22, 2021 at 10:51 AM Chuck Tuffli wrote= : >=20 >> On Mon, Nov 22, 2021 at 9:34 AM Chris wrote: >>> >>> On 2021-11-22 08:47, Chuck Tuffli wrote: >>>> Running on a recent-ish -current >>>> # uname -a >>>> FreeBSD stargate.tuffli.net 14.0-CURRENT FreeBSD 14.0-CURRENT >>>> main-81b22a9892 GENERIC amd64 >>>> >>>> I'm having trouble using the second NIC interface in a bridge to >> provide >>>> network connectivity to bhyve VMs and need some help figuring out wh= at >> is >>>> wrong. >> ... >>> Because there's subtle differences between them; are you using the re= >> driver >>> from base, or from ports? >> >> The driver is from base. Didn't realize there was one in ports. >> >=20 > The ports driver is tricky... It's an older, buggier version of the bas= e > driver... *BUT* > a number of issues that aren't fixed in base are fixed in it (mostly > dealing better with > errata)... Ideally, we'd pull in the actual fixes from this driver, bu= t > it's a huge patch-set > where it's unclear which bits are for what thing fixed, so nobody (that= I > know of) has > gone through and even come up with an ugly patch for -current. I had hoped to be able to merge RTL8125 support into our driver, based on= the Realtek version the port uses, but gave up for lack of documentation that describes the RTL8125 chips and their PHYs. But in preparation for this work I have analyzed the differences between our driver in base and the one from Realtek. The Realtek driver: - lacks support for a lot of newer features (e.g. NETMAP) - has lots of conditional sections for antique FreeBSD versions - special cases some 50 chip versions with regard to features, timing, ..= =2E - contains microcode patches for nearly every RTL chip version There are even 4 chip versions of the RTL8125 (as the latest Realtek chip= ) that are distinguished in the driver (some need microcode patches, some d= o not). I have created patches to bring our version more in line with additions present in the Realtek driver (e.g. register definitions for RTL8125), bu= t had decided not to commit them, since I had no way of testing them with t= he variety of hardware the driver supports. I could commit the register definitions and other changes that I consider= low risk (even if I do not have the particular hardware revision the chan= ges address). It is sad that Realtek does not provide developers with detailed informat= ion. I'll look again for any leaked RTL8125 data books, but last I checked, th= ere were none. Regards, STefan --------------00wRUFVtLXmuuDRiEB4atMA1-- --------------yWseIeoipEBVh79Pe10yL8Cf Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEo3HqZZwL7MgrcVMTR+u171r99UQFAmGb5BUFAwAAAAAACgkQR+u171r99UQL OwgAkLNnJMkSnBjEE+ndtYAAqGcPXdQrcEFNxKgEko0AVhgvWJMUb3axcVHqG7EuS01nz1EuXxAs 7+nxodAyRRvM9AXo1LW8BmWIS3rErsSWGykCYsOdclJVJrarNeYEsM7PCT0nbF7cpJH5R1Oim6yY WmYxgNBIgZPTQuRQ6/EkzGFS/Bd3mAJNm/C254U+hVKZtXJcE1Mfct+y33RqVfMtkpK/8XPzAmff mk9+WotqEE9tuSphoDpd89D9vdvDc7orrN/b3jLSNpZxyPWLlBMFY9PTJN8xVrVMIDRl883jbpbC geVD8SzxDKF33MLEZ4HFa9egA2a3fKAKJwKky8gQ1w== =JRhC -----END PGP SIGNATURE----- --------------yWseIeoipEBVh79Pe10yL8Cf-- From nobody Tue Nov 23 08:43:11 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 5D7AF18A15F0 for ; Tue, 23 Nov 2021 08:43:23 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-23.consmr.mail.gq1.yahoo.com (sonic311-23.consmr.mail.gq1.yahoo.com [98.137.65.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 4HyyMt1zQSz4kHP for ; Tue, 23 Nov 2021 08:43:22 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637656994; bh=Pr6rR2lEIfwENCla7H0CNaTIcvKHU82y4b/a7y0tciI=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=tKaxyNgTyzkWAKTo05lLISYom1SvAEV+Ky18NnxNgA8MqhIZseaiU5sTpmN8cy1pYjTLHXpFbQxM+MHiXogPmh0agnbnMB5Nbia+GhDB/UixM029Fbx/tkgRE8X7Sp8z0FI+Vrobgynx+VnvScUz7mLSsMyv8QxkYS46nnEr8chuaILLRy7wlDizlYJpQh933YDGTt2um+GmsOzFE8piLNtBVgT3aKb2kyxYJ+uBRp0R8qZwhGjuvv5LvQznvGQoxr+0fXpmc/n1BSw2kdfHVzJCPXAmT3HcpIxpfscpPmto8P7zBzcG0wFXiovmN1TBQLlqrX3xeSnRHJ6Ygbhr+w== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637656994; bh=B7BH871VGILXRG1SSveUIOq/fa4OnrzJnS7SDhRwq5Q=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=ooqMCcTmDXcbxIF7lwsIeZ/AMBhArZAFrYrK9WHSDuzsJxTGJb3exZ9f8hmfRlKJwN7OFXOj+1LxrXnIOThIrQRx09AIp8IDbkX757A2vMRiP2b+i7wFS/YxIDJu/TDrGYXWFoW2+cTaXnqA4PiV4w4fJlx7u7WVLOSwF+AlDhShddaZilY+B9R4JK92DuRH5pcVwZnd9uFw02cHCuj+cjTs989SKdKLL5zD0T1pKM1V1/sQRx9COc0gYXY8YXruZN3youuZW5w3s1+YM4eLO8yYPW1nj4FJoGQvcucErnlmTWGocPIUGv798Rl1HEeEqy29D/kL9FKopr7NZNdHMA== X-YMail-OSG: LgrVpEEVM1lfa8sU9CCUUaZr7z3Q1zd3osOMZLuq8X_ZlGcLgBOI_Bau7fgGYHD NvQ4ImAerwFhD5Ozrb535bG90TOBMF17IqEcIWmS1lMT3201l5LIHW3XzPqxjs8NPSnx1kIgrHMr Xww0vC0Yn.HpdqULhks0niq9VbBw2EJzPOFxqhb1Cp7DaFc7Fd5mOXPpaJqekxtJ_qEbmtyNbFHo WdQ7SDGVcIsWm6nnok55puMWceBVELVSrtqtDiG2sNQeUWGIwJqqrChjmImWTCZkVOxoSrs_ZB.W hk0lRNXB4.ZoAZziMfGwdtxI5f0.VOXrVBzm0SAbevviL04P6488hAIma8Pkmt70WIeKK6N7iSRl PJXqa2pcprqfUvQeP5p0oXowc70618sYXVO95vOO_aInUzgt12uvbDnYuVPU67DMAhLLgp7RWern o34DVRco6VprsibbHDTB1GWJoqiunVStU64aTYCAtIAxZsUOQ8sGGgH2jTi3HNaDodf23JcTjabJ J41XAwtuqPyqTwPqGad_Mlbt5maV2_9Vy2LxgtoAliHNBliAwSycxNr7dN9nQYB5LWdMJ802kMMD KbNuPpJ6e6bNuGLQv43ReAmyoyHaKY04JcVCR0Q_8T11ivW4.Rp7I3L9TV7CT5Lmm5hQVnZcbtbx 98Kd3OLa8tzUTwOf477z33xCIIbqmCl37fQioBi.6kUOgBq8u5XE1gPYfLh7JAs4aP6HvKKfL.rh mQQaXOLIBGp9ltARkcKG.NquqgpPxC8cFbzJPQ0yV8a4wVsqhlf_CPoSEH7tvpZ2L0C12MsaWF4v s1LtoCK9IabjcheYGFkBuFCXViWD684ddPTcBZDL3ydQTI_cBdvgLvlMJbCXPlcEE2owexMtrj0U c_qfyBnWVr7PxbI9PZJOnDgVq9.0RYrIgZX8bhSNivyBRPchvl4rALgruVl0ki2wbDVaT6ZDTOMH NZrE38lbQyi1_rxn_skdc6eiQ_WPEQz9Yvy2SB8VuUFcumRdhWhoTEZvO4i3VfxUOqKiKhOrWFCX cv_bTdnUaonw8S0eIwg8L59LFo.cWg3WO5WM7oF7S7p4D.01xkpoETmTo3gI4GVDZ.tKK2pKR29t t3Nkb1yDyfM1V9Ag8jPgKjywAKbenyl2a_efMQIe7FoV3Fk0mqgA6hH.sAP4PVhXvxN7XF_BrwbY q17X0OVqBRBUji_J0.m2aGA9rRS1JTJbr.TAPG9eRSjBxshOWCQoXC.A0_qXycYXaiNXZmlbcEZM vvXNM.aCuWnrJrPuskFnC.MHEts20.st4eV2O4Obqh8.Z8PdVjrdmia_NPyw9SXvVcJNOCHuRRsc 6JgHFhUE_C7cqd8t.mij80xXnwMAbaxor1X0i.ZFghlHDg5zgvATOteyIs0kRp_xCyejwKeUnG7U B_BT7hk1b0nG7jbRy1SJnN269Bn7UjEQ_urA3AtjPfTkYXbDNrTthBF.tXtuzzYnQ96j.nDTG2nr ksS.E5IPHdTu5PtPuA6ofwJUoHY4oqOG1rP_72yaiCzhXQZ8B21NHgDI_SkBDjwMJLz.PuLyHNEk skRADvS9H3NtQYqQ2qFoR15EB3_sF9bhoiJblIZ3a10dSC3PsX6W6IvPJfOAopf0vdFCRgSTAWHu 6ogK3rowlVQyYqbWisSzmN0OhpppHobH9Ykc7r8op4jZU3dcFuIMBYM1210jLbMX6TmrHxcxWLOD clcy3_33OS8Qho7Z0x3boN9yq0G5YrBl1JEROUh6h7PGYogpgj99f9Uzn8jgp9v5dIQF1KQyCcba tCXEhAzhf0373npJ.8nUC11wcdz0n99teac05U6bClTVLCZNJ2TJg2wvUMxqonTrh_1uZpFIpPTs GA6QzBhpr3OZCzVTStBpGqoFt5I9bCajBTA7lAA18Plw.fJtvlmPtS50YV.NKviqH9OsxYA77qzC cFmvD.7LC166ZgYzwxYi9W79iPlAgmVlUvqFexKxQA8ICgaxuhKAcOvTZ_CKV.A3Qhjtfkkt_mvA IE9T6.vHAtV2rqBX9KXOvZkhporPV5oDjJ6PTgAI_jiVhYxQgLKCldIivuCmWdKL2j7pCA.VHIs4 i34HKo7e9v6_G_.Kx3q1gDwmDryMH4a_KHmmsk2uNqFgXIsSN9W87IWRBArWccptMvLGGdQdiH2E BmiMHGyl5_6xuL2Fqiyz1_sAUY0W2g9NEjpw5N3B0K09QvIX_FniY6EZx.uD0MCUJrKORuC4o360 5r8pgiAYbAKpr91TliGudAffPkfb88hboe__fJP0mZ2rI5g-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Tue, 23 Nov 2021 08:43:14 +0000 Received: by kubenode545.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 3d7e4f650e22930b114022d53702e6ba; Tue, 23 Nov 2021 08:43:12 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: aarch64(?) poudiere-devel based builds seem to get fairly-rare corrupted files after recent system update(s?) Date: Tue, 23 Nov 2021 00:43:11 -0800 References: <2CA61249-321C-45AA-9755-597146AB8E9F@yahoo.com> <65AA4BCD-EC4B-4A19-B750-C7FC6E5ADDF5@yahoo.com> <9BF4F65B-6437-4D88-AF34-9BCFBF90D6F3@yahoo.com> <4B591638-4693-4403-8549-88D7A1D9D669@yahoo.com> <0006EB30-B9F9-465A-8B9A-A0C03899CEFC@yahoo.com> To: freebsd-current , "freebsd-arm@freebsd.org" In-Reply-To: Message-Id: <52F86CFA-7189-4AB6-BFB8-BFAB7EDBAFC0@yahoo.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4HyyMt1zQSz4kHP X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=tKaxyNgT; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.204 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.204:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.204:from]; RCVD_COUNT_TWO(0.00)[2] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-current X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Nov-21, at 07:50, Mark Millard wrote: > On 2021-Nov-20, at 11:54, Mark Millard wrote: >=20 >> On 2021-Nov-19, at 22:20, Mark Millard wrote: >>=20 >>> On 2021-Nov-18, at 12:15, Mark Millard wrote: >>>=20 >>>> On 2021-Nov-17, at 11:17, Mark Millard wrote: >>>>=20 >>>>> On 2021-Nov-15, at 15:43, Mark Millard wrote: >>>>>=20 >>>>>> On 2021-Nov-15, at 13:13, Mark Millard wrote: >>>>>>=20 >>>>>>> On 2021-Nov-15, at 12:51, Mark Millard = wrote: >>>>>>>=20 >>>>>>>> On 2021-Nov-15, at 11:31, Mark Millard = wrote: >>>>>>>>=20 >>>>>>>>> I updated from (shown a system that I've not updated yet): >>>>>>>>>=20 >>>>>>>>> # uname -apKU >>>>>>>>> FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #18 = main-n250455-890cae197737-dirty: Thu Nov 4 13:43:17 PDT 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64=20 >>>>>>>>> 1400040 1400040 >>>>>>>>>=20 >>>>>>>>> to: >>>>>>>>>=20 >>>>>>>>> # uname -apKU >>>>>>>>> FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #19 = main-n250667-20aa359773be-dirty: Sun Nov 14 02:57:32 PST 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400042 1400042 >>>>>>>>>=20 >>>>>>>>> and then updated /usr/ports/ and started poudriere-devel based = builds of >>>>>>>>> the ports I's set up to use. However my last round of port = builds from >>>>>>>>> a general update of /usr/ports/ were on 2021-10-23 before = either of the >>>>>>>>> above. >>>>>>>>>=20 >>>>>>>>> I've had at least two files that seem to be corrupted, where a = later part >>>>>>>>> of the build hits problematical file(s) from earlier build = activity. For >>>>>>>>> example: >>>>>>>>>=20 >>>>>>>>> /usr/local/include/X11/extensions/XvMC.h:1:1: warning: null = character ignored [-Wnull-character] >>>>>>>>> =20 >>>>>>>>> ^ >>>>>>>>> /usr/local/include/X11/extensions/XvMC.h:1:2: warning: null = character ignored [-Wnull-character] >>>>>>>>> >>>>>>>>> ^ >>>>>>>>> /usr/local/include/X11/extensions/XvMC.h:1:3: warning: null = character ignored [-Wnull-character] >>>>>>>>> =20 >>>>>>>>> ^ =20 >>>>>>>>> /usr/local/include/X11/extensions/XvMC.h:1:4: warning: null = character ignored [-Wnull-character] >>>>>>>>> >>>>>>>>> ^ >>>>>>>>> . . . >>>>>>>>>=20 >>>>>>>>> Removing the xorgproto-2021.4 package and rebuilding via >>>>>>>>> poudiere-devel did not get a failure of any ports dependent >>>>>>>>> on it. >>>>>>>>>=20 >>>>>>>>> This was from a use of: >>>>>>>>>=20 >>>>>>>>> # poudriere jail -j13_0R-CA7 -i >>>>>>>>> Jail name: 13_0R-CA7 >>>>>>>>> Jail version: 13.0-RELEASE-p5 >>>>>>>>> Jail arch: arm.armv7 >>>>>>>>> Jail method: null >>>>>>>>> Jail mount: /usr/obj/DESTDIRs/13_0R-CA7-poud >>>>>>>>> Jail fs: =20 >>>>>>>>> Jail updated: 2021-11-04 01:48:49 >>>>>>>>> Jail pkgbase: disabled >>>>>>>>>=20 >>>>>>>>> but another not-investigated example was from: >>>>>>>>>=20 >>>>>>>>> # poudriere jail -j13_0R-CA72 -i >>>>>>>>> Jail name: 13_0R-CA72 >>>>>>>>> Jail version: 13.0-RELEASE-p5 >>>>>>>>> Jail arch: arm64.aarch64 >>>>>>>>> Jail method: null >>>>>>>>> Jail mount: /usr/obj/DESTDIRs/13_0R-CA72-poud >>>>>>>>> Jail fs: =20 >>>>>>>>> Jail updated: 2021-11-04 01:48:01 >>>>>>>>> Jail pkgbase: disabled >>>>>>>>>=20 >>>>>>>>> (so no 32-bit COMPAT involved). The apparent corruption >>>>>>>>> was in a different port (autoconfig, noticed by the >>>>>>>>> build of automake failing via config reporting >>>>>>>>> /usr/local/share/autoconf-2.69/autoconf/autoconf.m4f >>>>>>>>> being rejected). >>>>>>>>>=20 >>>>>>>>> /usr/obj/DESTDIRs/13_0R-CA7-poud/ and >>>>>>>>> /usr/obj/DESTDIRs/13_0R-CA72-poud/ and the like track the >>>>>>>>> system versions. >>>>>>>>>=20 >>>>>>>>> The media is an Optane 960 in the PCIe slot of a HoneyComb >>>>>>>>> (16 Cortex-A72's). The context is a root on ZFS one, ZFS >>>>>>>>> used in order to have bectl, not redundancy. >>>>>>>>>=20 >>>>>>>>> The ThreadRipper 1950X (so amd64) port builds did not give >>>>>>>>> evidence of such problems based on the updated system. (Also >>>>>>>>> Optane media in a PCIe slot, also root on ZFS.) But the >>>>>>>>> errors seem rare enough to not be able to conclude much. >>>>>>>>=20 >>>>>>>> For aarch64 targeting aarch64 there was also this >>>>>>>> explicit corruption notice during the poudriere(-devel) >>>>>>>> bulk build: >>>>>>>>=20 >>>>>>>> . . . >>>>>>>> [CA72_ZFS] Extracting arm-none-eabi-gcc-8.4.0_3: ......... >>>>>>>> pkg-static: Fail to extract = /usr/local/libexec/gcc/arm-none-eabi/8.4.0/lto1 from package: Lzma = library error: Corrupted input data >>>>>>>> [CA72_ZFS] Extracting arm-none-eabi-gcc-8.4.0_3... done >>>>>>>>=20 >>>>>>>> Failed to install the following 1 package(s): = /packages/All/arm-none-eabi-gcc-8.4.0_3.pkg >>>>>>>> *** Error code 1 >>>>>>>> Stop. >>>>>>>> make: stopped in /usr/ports/sysutils/u-boot-orangepi-plus-2e >>>>>>>>=20 >>>>>>>> I'm not yet to the point of retrying after removing >>>>>>>> arm-none-eabi-gcc-8.4.0_3 : other things are being built. >>>>>>>=20 >>>>>>>=20 >>>>>>> Another context with my prior general update of /usr/ports/ >>>>>>> and the matching port builds: Back then I used USE_TMPFS=3Dall >>>>>>> but the failure is based on USE_TMPFS-"data" instead. So: >>>>>>> lots more I/O. >>>>>>>=20 >>>>>>=20 >>>>>> None of the 3 corruptions repeated during bulk builds that >>>>>> retried the builds that generated the files. All of the >>>>>> ports that failed by hitting the corruptions in what they >>>>>> depended on, built fine in teh retries. >>>>>>=20 >>>>>> For reference: >>>>>>=20 >>>>>> I'll note that, back when I was using USE_TMPFS=3Dall , I also >>>>>> did some separate bulk -a test runs, both aarch64 (Cortex-A72) >>>>>> native and Cortext-A72 targeting Cortex-A7 (armv7). None of >>>>>> those showed evidence of file corruptions. In general I've >>>>>> not had previous file corruptions with this system. (There >>>>>> was a little more than 245 GiBytes swap, which covered the >>>>>> tmpfs needs when they were large.) >>>>>=20 >>>>>=20 >>>>> I set up a contrasting test context and got no evidence of >>>>> corruptions in that context. (Note: the 3 bulk builds >>>>> total to around 24 hrs of activity for the 3 examples >>>>> of 460+ ports building.) So, for the Cortex-A72 system, >>>>=20 >>>> I set up a UFS on Optane (U.2 via M.2 adapter) context and >>>> also got no evidence of corruptions in that context (same >>>> hardware and a copy of the USB3 SSD based system). The >>>> sequence of 3 bulks took somewhat over 18 hrs using the >>>> Optane. >>>>=20 >>>>> root on UFS on portable USB3 SSD: no evidence of corruptions >>>> Also: >>>> root on UFS on Optane U.2 via M.2: no evidence of corruptions >>>>> vs.: >>>>> root on ZFS on optane in PCIe slot: solid evidence of 3 known = corruptions >>>>>=20 >>>>> Both had USE_TMPFS=3D"data" in use. The same system build >>>>> had been installed and booted for both tests. >>>>>=20 >>>>> The evidence of corruptions is rare enough for this not to >>>>> be determinative, but it is suggestive. >>>>>=20 >>>>> Unfortunately, ZFS vs. UFS and Optane-in-PCIe vs. USB3 are >>>>> not differentiated by this test result. >>>>>=20 >>>>> There is also the result that I've not seen evidence of >>>>> corruptions on the ThreadRipper 1950 X (amd64) system. >>>>> Again, not determinative, but suggestive, given how rare >>>>> the corruptions seem to be. >>>>=20 >>>> So far the only things unique to the observed corruptions are: >>>>=20 >>>> root on ZFS context (vs. root on UFS) >>>> and: >>>> Optane in a PCIe slot (but no contrasting ZFS case tested) >>>>=20 >>>> The PCIe slot does not seem to me to be likely to be contributing. >>>> So this seem to be suggestive of a ZFS problem. >>>>=20 >>>> A contributing point might be that the main [so: 14] system was >>>> built via -mcpu=3Dcortex-a72 for execution on a Cortext-A72 system. >>>>=20 >>>> [I previously ran into a USB subsystem mishandling of keeping >>>> things coherent for the week memory ordering in this sort of >>>> context. That issue was fixed. But back then I was lucky enough >>>> to be able to demonstrate fails vs. works by adding an >>>> appropriate instruction to FreeBSD in a few specific places >>>> (more than necessary as it turned out). Someone else determined >>>> where the actual mishandling was that covered all required >>>> places. My generating that much information in this context >>>> seems unlikely.] >>>=20 >>>=20 >>> I started a retry of root-on-ZFS with the Optane-in-PCIe-slot media >>> and it got its first corruption (in a different place, 2nd bulk >>> build this time). The use of the corrupted file reports: >>>=20 >>> configure:13269: cc -o conftest -Wall -Wextra -fsigned-char = -Wdeclaration-after-statement -O2 -pipe -mcpu=3Dcortex-a53 -g = -fstack-protector-strong -fno-strict-aliasing -DUSE_MEMORY_H = -I/usr/local/incl >>> ude -mcpu=3Dcortex-a53 -fstack-protector-strong conftest.c = -L/usr/local/lib -logg >&5 >>> In file included from conftest.c:27: >>> In file included from /usr/local/include/ogg/ogg.h:24: >>> In file included from /usr/local/include/ogg/os_types.h:154: >>> /usr/local/include/ogg/config_types.h:1:1: warning: null character = ignored [-Wnull-character] >>> >>> ^ >>> /usr/local/include/ogg/config_types.h:1:2: warning: null character = ignored [-Wnull-character] >>> >>> ^ >>> /usr/local/include/ogg/config_types.h:1:3: warning: null character = ignored [-Wnull-character] >>> >>> ^ >>> . . . >>> /usr/local/include/ogg/config_types.h:1:538: warning: null character = ignored [-Wnull-character] >>> . . . (nulls) . . . >>>=20 >>> So: 538 such null bytes. >>>=20 >>> Thus, another example of something like a page of nulls being >>> written out when ZFS is in use. >>>=20 >>> audio/gstreamer1-plugins-ogg also failed via referencing the file >>> during its build. >>>=20 >>> (The bulk run is still going and there is one more bulk run to go.) >>>=20 >>=20 >> Well, 528 happened to be the size of config_types.h --and of >> config_types.h from a build that did not get the corruption there. >>=20 >> So looking at the other (later) corruption, which was a bigger file >> (looking via bulk -i and installing what contained the file but >> looking from outside the jail): >>=20 >> # find /usr/local/ -name "libtextstyle.so*" -exec ls -Tld {} \; >> -rwxr-xr-x 1 root wheel 2339104 Nov 20 01:05:05 2021 = /usr/local/poudriere/data/.m/13_0R-CA7-default/ref/usr/local/lib/libtextst= yle.so.0.1.1 >> lrwxr-xr-x 1 root wheel 21 Nov 20 01:05:05 2021 = /usr/local/poudriere/data/.m/13_0R-CA7-default/ref/usr/local/lib/libtextst= yle.so.0 -> libtextstyle.so.0.1.1 >> lrwxr-xr-x 1 root wheel 21 Nov 20 01:05:05 2021 = /usr/local/poudriere/data/.m/13_0R-CA7-default/ref/usr/local/lib/libtextst= yle.so -> libtextstyle.so.0.1.1 >>=20 >> hd = /usr/local/poudriere/data/.m/13_0R-CA7-default/ref/usr/local/lib/libtextst= yle.so.0.1.1 | more >> 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| >> * >> 0023b120 >>=20 >> So the whole, over 2 MiByte, the whole file ended up with just null = Bytes. >>=20 >> To cross check on live system caching vs. on disk, I rebooted and = redid the >> bulk -i based install of libtextstyle and looked at = libtextstyle.so.0.1.1 : >> still all zeros. >>=20 >> For reference, zpool scrub afterward resulted in: >>=20 >> # zpool status >> pool: zopt0 >> state: ONLINE >> scan: scrub repaired 0B in 00:01:49 with 0 errors on Sat Nov 20 = 11:47:31 2021 >> config: >>=20 >> NAME STATE READ WRITE CKSUM >> zopt0 ONLINE 0 0 0 >> nda1p3 ONLINE 0 0 0 >>=20 >> But it is not a ZFS redundancy context: ZFS used just to use bectl . >=20 > Using bectl (on the root-on-ZFS Optane in PCIe slot), > I booted stable/13 : >=20 > # uname -apKU > FreeBSD CA72_16Gp_ZFS 13.0-STABLE FreeBSD 13.0-STABLE #13 = stable/13-n248062-109330155000-dirty: Sat Nov 13 23:55:14 PST 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/13S-CA72-nodbg-clang/usr/13S-src/arm64.= aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1300520 1300520 >=20 > and tried the sequence of 3 bulk runs: >=20 > There was no evidence of corruptions, suggesting that > the Optane in the PCIe slot is not the source of the > problem of having some file(s) end up with all bytes > being null bytes. >=20 > So, overall, ending up with evidence of corruptions > generated during bulk builds seem to be tied to main's > [so: 14's] ZFS implementation in: >=20 > # uname -apKU > FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #18 = main-n250455-890cae197737-dirty: Thu Nov 4 13:43:17 PDT 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64=20 > 1400040 1400040 >=20 > because that is all that is unique to having the > evidence of corruptions. >=20 > Since there have been ZFS updates in main since then, it > seems that the next experiment would be to update main > and try again under main. Given that the issue seems to be a ZFS issue, I updated to: # uname -apKU FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #21 = main-n250903-06bd74e1e39c-dirty: Mon Nov 22 04:15:08 PST 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400042 1400042 (which involved updating some ZFS material). I ran the sequence of 3 bulk's again: no evidence of corruptions. For reference: The bulks targeting Cortex-A72 and Cortex-A53 each took somewhat under 10 minutes more than the earlier stable/13 and main [so: 14] builds that otherwise matched (including the Optane used), for bulks that each took somewhat over 6 hr either way. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Wed Nov 24 11:30:27 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 618751888E8D for ; Wed, 24 Nov 2021 11:30:38 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (cross.sbone.de [195.201.62.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Hzf2P2WmVz4Vly for ; Wed, 24 Nov 2021 11:30:37 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 5D5228D4A179 for ; Wed, 24 Nov 2021 11:30:30 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 81482E70847 for ; Wed, 24 Nov 2021 11:30:29 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id GtfiWy8aVjn0 for ; Wed, 24 Nov 2021 11:30:28 +0000 (UTC) Received: from nv.sbone.de (nv.sbone.de [IPv6:fde9:577b:c1a9:31::2013:138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 49874E70846 for ; Wed, 24 Nov 2021 11:30:28 +0000 (UTC) Date: Wed, 24 Nov 2021 11:30:27 +0000 (UTC) From: "Bjoern A. Zeeb" To: freebsd-current@freebsd.org Subject: make cleandiry tries to access /lib/geom Message-ID: X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Rspamd-Queue-Id: 4Hzf2P2WmVz4Vly X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of bzeeb-lists@lists.zabbadoz.net designates 195.201.62.131 as permitted sender) smtp.mailfrom=bzeeb-lists@lists.zabbadoz.net X-Spamd-Result: default: False [-3.20 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; NEURAL_HAM_MEDIUM(-0.96)[-0.956]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:195.201.62.131]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.95)[-0.948]; DMARC_NA(0.00)[zabbadoz.net]; NEURAL_HAM_SHORT(-1.00)[-0.999]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:24940, ipnet:195.201.0.0/16, country:DE]; MIME_TRACE(0.00)[0:+] X-ThisMailContainsUnwantedMimeParts: N Hi, 673 ===> usr.bin/diff/tests (cleandir) 674 ===> lib/geom (cleandir) 675 ===> sbin/mount_udf (cleandir) 676 make[6] warning: /lib/geom: Permission denied. ^^^^ not sure what is going on here? 677 ===> share/i18n/esdb/ISO-8859 (cleandir) 678 ===> tests/sys/cddl/zfs/tests/cli_root/zfs_clone (cleandir) -- Bjoern A. Zeeb r15:7 From nobody Wed Nov 24 11:55:25 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B089B1895DB8 for ; Wed, 24 Nov 2021 11:55:30 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (cross.sbone.de [195.201.62.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Hzfb56m3Hz4f6q for ; Wed, 24 Nov 2021 11:55:29 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id CBA1C8D4A179 for ; Wed, 24 Nov 2021 11:55:28 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 027BDE70847 for ; Wed, 24 Nov 2021 11:55:27 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id ntXaJrvi4qfh for ; Wed, 24 Nov 2021 11:55:26 +0000 (UTC) Received: from nv.sbone.de (nv.sbone.de [IPv6:fde9:577b:c1a9:31::2013:138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id B3DE5E70846 for ; Wed, 24 Nov 2021 11:55:26 +0000 (UTC) Date: Wed, 24 Nov 2021 11:55:25 +0000 (UTC) From: "Bjoern A. Zeeb" To: freebsd-current@freebsd.org Subject: Re: make cleandir tries to access /... In-Reply-To: Message-ID: References: X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Rspamd-Queue-Id: 4Hzfb56m3Hz4f6q X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of bzeeb-lists@lists.zabbadoz.net designates 195.201.62.131 as permitted sender) smtp.mailfrom=bzeeb-lists@lists.zabbadoz.net X-Spamd-Result: default: False [-3.21 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; NEURAL_HAM_MEDIUM(-0.96)[-0.958]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:195.201.62.131:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.96)[-0.955]; DMARC_NA(0.00)[zabbadoz.net]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:195.201.0.0/16, country:DE]; RCVD_TLS_LAST(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Wed, 24 Nov 2021, Bjoern A. Zeeb wrote: > Hi, > > 673 ===> usr.bin/diff/tests (cleandir) > 674 ===> lib/geom (cleandir) > 675 ===> sbin/mount_udf (cleandir) > 676 make[6] warning: /lib/geom: Permission denied. > > ^^^^ not sure what is going on here? > > 677 ===> share/i18n/esdb/ISO-8859 (cleandir) > 678 ===> tests/sys/cddl/zfs/tests/cli_root/zfs_clone (cleandir) On closer look it feels like MAKeOBJDIRPREFIX or something is missing somewhere? make[5] warning: /lib: Permission denied. make[5] warning: /libexec: Permission denied. make[5] warning: /bin: Permission denied. make[5] warning: /rescue: Permission denied. make[5] warning: /sbin: Permission denied. make[5] warning: /sys: Permission denied. make[5] warning: /etc: Permission denied. make[6] warning: /lib/geom: Permission denied. ... -- Bjoern A. Zeeb r15:7 From nobody Wed Nov 24 12:50:09 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C9A141895AAC for ; Wed, 24 Nov 2021 12:50:17 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from transit01.runbox.com (transit01.runbox.com [91.220.196.211]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HzgpK3wsrz3Hn7 for ; Wed, 24 Nov 2021 12:50:17 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from mailtransmit03.runbox ([10.9.9.163] helo=aibo.runbox.com) by transit01.runbox.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1mprj0-00Digg-2J; Wed, 24 Nov 2021 13:50:10 +0100 Received: from [10.9.9.129] (helo=rmmprod07.runbox) by mailtransmit03.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1mpriz-0002pu-3b; Wed, 24 Nov 2021 13:50:09 +0100 Received: from mail by rmmprod07.runbox with local (Exim 4.86_2) (envelope-from ) id 1mpriz-0002Yq-24; Wed, 24 Nov 2021 13:50:09 +0100 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Received: from [Authenticated alias (650894)] by runbox.com with http (RMM6); Wed, 24 Nov 2021 12:50:09 GMT From: "Jeffrey Bouquet" Reply-To: jbtakk@iherebuywisely.com To: "Bjoern A. Zeeb" CC: "freebsd-current" Subject: Re: make cleandir tries to access /... Date: Wed, 24 Nov 2021 04:50:09 -0800 (PST) X-RMM-Aliasid: 650894 X-Mailer: RMM6 In-Reply-To: Message-Id: X-Rspamd-Queue-Id: 4HzgpK3wsrz3Hn7 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Wed, 24 Nov 2021 11:55:25 +0000 (UTC), "Bjoern A. Zeeb" wrote: > On Wed, 24 Nov 2021, Bjoern A. Zeeb wrote: >=20 > > Hi, > > > > 673 =3D=3D=3D> usr.bin/diff/tests (cleandir) > > 674 =3D=3D=3D> lib/geom (cleandir) > > 675 =3D=3D=3D> sbin/mount_udf (cleandir) > > 676 make[6] warning: /lib/geom: Permission denied. > > > > ^^^^ not sure what is going on here? > > > > 677 =3D=3D=3D> share/i18n/esdb/ISO-8859 (cleandir) > > 678 =3D=3D=3D> tests/sys/cddl/zfs/tests/cli_root/zfs_clone (cleandir) >=20 > On closer look it feels like MAKeOBJDIRPREFIX or something is missing > somewhere? >=20 > make[5] warning: /lib: Permission denied. > make[5] warning: /libexec: Permission denied. > make[5] warning: /bin: Permission denied. > make[5] warning: /rescue: Permission denied. > make[5] warning: /sbin: Permission denied. > make[5] warning: /sys: Permission denied. > make[5] warning: /etc: Permission denied. > make[6] warning: /lib/geom: Permission denied. > ... >=20 > --=20 > Bjoern A. Zeeb r15:7 on a recent 13.-0 STABLE buildworld I had to use cd /usr/obj gfind . -type f -exec chflags noschg {} \;=20=20 for the first time in 17 years ... if that helps ...........................................................................= .......... as an aside, from July to Nov 13.0-STABLE the newer wpa_supplicant failed with an ioctl* error, the july backup into the Nov new base/userland fixed that issue. ...........................................................................= ..... as another aside, etcupdate still has no capability in /var/* [here] to fixup /etc properly so I had to use mergemaster again as I am not well versed in its methods of operation. ...........................................................................= .. Just posting the latter two in here as non urgent?? footnotes, did not wish to put in an email to CURRENT a 13-STABLE issue... I consider them each regressions to BSD ease of upgrade if it affects=20 recently new users or anyone else.=20 From nobody Wed Nov 24 16:51:16 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 09DCD18A78E2 for ; Wed, 24 Nov 2021 16:51:18 +0000 (UTC) (envelope-from jhb@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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Hzn8P6NNnz4Yv4; Wed, 24 Nov 2021 16:51:17 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from [10.0.1.4] (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 57DB91A7; Wed, 24 Nov 2021 16:51:17 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: Date: Wed, 24 Nov 2021 08:51:16 -0800 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: make cleandiry tries to access /lib/geom Content-Language: en-US To: "Bjoern A. Zeeb" , freebsd-current@freebsd.org References: Cc: Jessica Clarke From: John Baldwin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1637772677; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=icys0xhuY+6zkcaRuCWzAR1rgAuMAN2FIzCoLynTr3M=; b=uxj2ixTnWIsUoRLoAsL9Efa6i9IowWJPHFRIVZZBgeROE08WM1NbU1hfRdAqyR+2r1j5Wk cx5OJr7YiijUjWKbMn0qOE3Iz/jVe1IUp5CcRrc/j5uR/jDBd+gBpYvRGpXUQQREPUhpiS uqAKdye1YwOna740NfB12QloDh7NJDV0NdF4vC+a9h3CmnUiioRo8xEy5UuIXXOMxPtro/ r/Vt6+QR/SQZMcSUKKWxp38mAFIiLGybLPHqrnuPRB796RZ8ydjNPT2wz82mWCm6rspmJC NGZ0lAiG+fVrzfxH08dv21Hipb3lu8fp3Zuta84H0ekWt0vrdXxNlj9oAmVA8Q== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1637772677; a=rsa-sha256; cv=none; b=UgIqchmMY4X/hZNdXnjlbzzJe3vAKLja3RB8zIFobnJWdckEgi566o6zGQ7X+cckO2GgaG 6bsxQS+fH+aN/WXfL73a6oq0GOzT6ALB6gHVtR3U6DEqnqkuQ3FqLbov+/bHSxPACi+dGh 5sfaz8V/DycQXCearx1xGqKubzm+854BU4t2g+hBn2nfIlqQVQgAsiOM42J9s4Qef2LbWL wm3sNm2iehARep6nVPuuAGWm1jw6VMcWo/iSskl5Ii38rglxZ3ToJJ9d30C3yG/m9VL27F KfcN8/tWqrwWe8fWji7tSlNd8nrbAxQFD3dcACxy1+6kMyIcYQx6kuBLCsVHJg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 11/24/21 3:30 AM, Bjoern A. Zeeb wrote: > Hi, > > 673 ===> usr.bin/diff/tests (cleandir) > 674 ===> lib/geom (cleandir) > 675 ===> sbin/mount_udf (cleandir) > 676 make[6] warning: /lib/geom: Permission denied. > > ^^^^ not sure what is going on here? > > 677 ===> share/i18n/esdb/ISO-8859 (cleandir) > 678 ===> tests/sys/cddl/zfs/tests/cli_root/zfs_clone (cleandir) I think Jess has a possible fix. This is some regression added in the build system several months ago. -- John Baldwin From nobody Wed Nov 24 16:52:47 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 8B09E18AA3C1 for ; Wed, 24 Nov 2021 16:53:04 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vk1-xa2a.google.com (mail-vk1-xa2a.google.com [IPv6:2607:f8b0:4864:20::a2a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HznBS2mR6z4bkj for ; Wed, 24 Nov 2021 16:53:04 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vk1-xa2a.google.com with SMTP id m16so1055631vkl.13 for ; Wed, 24 Nov 2021 08:53:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NwecyAyuvRuQ97d+1Ck5reP7czitbstVnx2Tqre1rDk=; b=n7C3AckqHAw9shhaxFxmnM8s066AisAPnIaiQdnyOeUJ/G/gBN8fikTCgWWvvccc2x 2woAvsmjUu4z6NIXFsWJ0TRZc2Hq6CDxqHXELHu01wgI4b9huy7qgR+m4pqtY1s3ucpI 2oDh8rHdFYOUWdkKmL1KDqOZ/hUOqLkWWFmDM8XgtIsEPjD6V4aI5p/glLZ5z89aTm1f eTZbl3iyeqp1fA6TYbqRGRoHbe4AdZ2mYu32QEuiZtvujRu2HwFNqjCCAYlEir3Okf2k UOseyOpIkk0Xgx2WWcOQeMDQHFX/5DDQz1Vk5i5u1hvDINVw8iXRdkBYu3d/2iuDz9R/ +x5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NwecyAyuvRuQ97d+1Ck5reP7czitbstVnx2Tqre1rDk=; b=M8Vds9FHneHji6OUD9HKnSezrFUlsfLM2dcThsBesKxnOW1pl8M67KJz3Mlzs1lUbq Ohs47ESnICW+IJ3Xs8tBKM2P1AkbQDdK0QGJMVn8BRuS3PyYfIVLyMMUzlkFUgersd02 4cj+gB2CQJ9WWZCfNN0iTf7MJH4fGihhbYANOtHZbjrNqTif77v3YhgXocFeDLcJSTNo jQrInJf18t5bhuR+imukycMhIeN19pyKfX+3BrwHCvim/thjjEysm27ateOfj83hMIqO S7OoMvkBGiidgvZsRXjWvEYhmfsk+Fsn7VdLLM8Mjr7YIRZG0bb/ageJVCwu4vr757gv ImGw== X-Gm-Message-State: AOAM5311x45/M67pDRA87Ao2J3N2UprLWoxk+9Pvu+noYyyBp9a+MTAd HD8yXzhU2y4GmkpBiqPkn8Ojsc1+vTQmOMm2VhfZpL85BAwO9o2A X-Google-Smtp-Source: ABdhPJxvca12+6ODc3Uw6Ywc2cknIA9eixeIx6Q4aWgx/plUGQ+CacVTv0K9G2u2D6+FMnb+u4H013dECLCf/2F6WBg= X-Received: by 2002:a05:6122:a03:: with SMTP id 3mr30335454vkn.8.1637772778410; Wed, 24 Nov 2021 08:52:58 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Wed, 24 Nov 2021 09:52:47 -0700 Message-ID: Subject: Re: make cleandir tries to access /... To: "Bjoern A. Zeeb" Cc: FreeBSD Current Content-Type: multipart/alternative; boundary="000000000000ae24ba05d18bb01a" X-Rspamd-Queue-Id: 4HznBS2mR6z4bkj X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --000000000000ae24ba05d18bb01a Content-Type: text/plain; charset="UTF-8" On Wed, Nov 24, 2021 at 4:56 AM Bjoern A. Zeeb < bzeeb-lists@lists.zabbadoz.net> wrote: > On Wed, 24 Nov 2021, Bjoern A. Zeeb wrote: > > > Hi, > > > > 673 ===> usr.bin/diff/tests (cleandir) > > 674 ===> lib/geom (cleandir) > > 675 ===> sbin/mount_udf (cleandir) > > 676 make[6] warning: /lib/geom: Permission denied. > > > > ^^^^ not sure what is going on here? > > > > 677 ===> share/i18n/esdb/ISO-8859 (cleandir) > > 678 ===> tests/sys/cddl/zfs/tests/cli_root/zfs_clone (cleandir) > > On closer look it feels like MAKeOBJDIRPREFIX or something is missing > somewhere? > > make[5] warning: /lib: Permission denied. > make[5] warning: /libexec: Permission denied. > make[5] warning: /bin: Permission denied. > make[5] warning: /rescue: Permission denied. > make[5] warning: /sbin: Permission denied. > make[5] warning: /sys: Permission denied. > make[5] warning: /etc: Permission denied. > make[6] warning: /lib/geom: Permission denied. > ... > I think Jessica's review fixes these: https://reviews.freebsd.org/D30990 Can you try it and comment if it works? Warner --000000000000ae24ba05d18bb01a-- From nobody Wed Nov 24 17:03:22 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9D44F18B0A6C for ; Wed, 24 Nov 2021 17:03:33 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ua1-x936.google.com (mail-ua1-x936.google.com [IPv6:2607:f8b0:4864:20::936]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HznQY3qK9z4jG4 for ; Wed, 24 Nov 2021 17:03:33 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ua1-x936.google.com with SMTP id r15so6538679uao.3 for ; Wed, 24 Nov 2021 09:03:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HtFUsfRphDYRfx6s/6WHBsrepo4rApUvEGCB7H6WPmY=; b=y8gFXyk1LQzad0mHpzhEbOMqg1/NUIyCKv9LcdGFfFVclJaTFeZ4G3l5xBbQmWtg5w PrymqtHz5m7GtpDGKcN+pxitxXOhdLzNXR9NDjH8RwhdOl+JFxeKShUxdN554GSybog1 qRlls+BwsP1yJzct5ywRxuEmmShQ4y1SU8Lq+/HMjzt5woSFWjnZ27v/GLyWmepXjpPd tMfsJjTHdKGLVvfQaU0KbbyT1OUFS7mf/XaBpHgu0OA1xgnr+TSxe8kKqIr5ObZ+Jtad 4DUG008GwaHus3E/Q72C8ClcizjaFzm/6RNcoVJPhoK3ooY/q9mCoPDjUUMtMqPuA04b mnNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HtFUsfRphDYRfx6s/6WHBsrepo4rApUvEGCB7H6WPmY=; b=hD5kJvj5AeogC9aSyrwqwiQjrIdriO5iwoIB4PtOqQiS7beH9CWjGZTY6kMF95PbuB 7tDNY2Y9TEV8cnE+klsp+o/IwI0LubSjDURHloatCaRi8ciMWfD6oNftRSSCDcx3k0TR GbIfEzGyH2aR9RT12fca3nj4Sjg6y0ZHJXoOYiFG+8gmhqQFejzK6vDtZegegYD9KlTU G80ZbetcYjtzmKb9vThN9WfnEC8B5P5Ma04WsYVV8m7qAlBygUgZ9G0WiZI5Fmm00GkY igya0AzCZpeSBZo4aVY/W/v3+EduY9iwuVbgV1y8v6qn7H3Hpijc/zg5MSn+kMoGnhaE 6oHg== X-Gm-Message-State: AOAM533WO6pxaBhHZ3LhWa4F5GWUI6BlD/kP6M5izzbYNywHUfjUvSPf nTJi85QzvMWwf35zU9nUgQ3aHEITFRgQD3K+fQdGFg== X-Google-Smtp-Source: ABdhPJzov8Ravu5PxHvD04dAgT/Ir/2yxvg554yZbsUns1rwE/5lC63C5AeiRMSvhboFivoRSYi+YWhlS37Q4CL2po0= X-Received: by 2002:a05:6102:3e8d:: with SMTP id m13mr27252872vsv.6.1637773413037; Wed, 24 Nov 2021 09:03:33 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Wed, 24 Nov 2021 10:03:22 -0700 Message-ID: Subject: Re: make cleandiry tries to access /lib/geom To: John Baldwin Cc: "Bjoern A. Zeeb" , FreeBSD Current , Jessica Clarke Content-Type: multipart/alternative; boundary="00000000000081d49e05d18bd62f" X-Rspamd-Queue-Id: 4HznQY3qK9z4jG4 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --00000000000081d49e05d18bd62f Content-Type: text/plain; charset="UTF-8" On Wed, Nov 24, 2021 at 9:52 AM John Baldwin wrote: > On 11/24/21 3:30 AM, Bjoern A. Zeeb wrote: > > Hi, > > > > 673 ===> usr.bin/diff/tests (cleandir) > > 674 ===> lib/geom (cleandir) > > 675 ===> sbin/mount_udf (cleandir) > > 676 make[6] warning: /lib/geom: Permission denied. > > > > ^^^^ not sure what is going on here? > > > > 677 ===> share/i18n/esdb/ISO-8859 (cleandir) > > 678 ===> tests/sys/cddl/zfs/tests/cli_root/zfs_clone (cleandir) > > I think Jess has a possible fix. This is some regression added in the > build system several months ago. https://reviews.freebsd.org/D30990 --00000000000081d49e05d18bd62f-- From nobody Wed Nov 24 18:29:32 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B8BEA1896702 for ; Wed, 24 Nov 2021 18:29:38 +0000 (UTC) (envelope-from jsm@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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HzqKs74Kwz3kq6; Wed, 24 Nov 2021 18:29:37 +0000 (UTC) (envelope-from jsm@FreeBSD.org) Received: from [192.168.1.5] (mail.northatlanticmusicsupplies.com [212.237.182.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jsm) by smtp.freebsd.org (Postfix) with ESMTPSA id 28CC41484; Wed, 24 Nov 2021 18:29:37 +0000 (UTC) (envelope-from jsm@FreeBSD.org) Message-ID: Date: Wed, 24 Nov 2021 19:29:32 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 To: freebsd-current Content-Language: en-US From: Jesper Schmitz Mouridsen Subject: bsddialog cannot crosscompile to arm64 from amd64 -lformw not found. Cc: bapt@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1637778578; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=UQImsWO6q6OTx1CzzymWqw8KOjl/Ub68gbrIQsIdFjY=; b=jz0ROwysmPsroeeHOBHbeeFeWRLOXTYBpYSEcGZ3s7j9rZM5Z13zn7OILDURCh4JqtGoyU zeZMwIBNCkim1kGAgo9b7kkLyv44rkXNdihidzrCFlKK48TqEF96ODvwC1JOrTk7oC2/iU LylMBFG7F0DlFXt5qdQPTlmM8SSzwzy+HRqdGRWj/Jl56P/EtjMMGTbFSnBChItXTqSjVU hwjt0C8s51apWG4bL0JaBsTfUAj6TlJzepedPVedDthuJ+5LRs3udVKPWKhAzFKgVDrneF AdepzDG68aOK7Eth8yN9/mOirhKsWwUwFYLJdOgMqj0s7SLABWMg4y2QlrG2gA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1637778578; a=rsa-sha256; cv=none; b=HbxEiDYy+57GNG5fGIR/CZy+LMJGCs7leSk75ayC8l4skLqMJoPjWdCO5nZWIULtoauzW/ tKQ0daTzr5jOibqOGnHFBGhKC+lK3Ltzz2EwZAIS/eonm0JVyOa1Z5/wvw/ztCZlULO5W8 VYsfT6warBn4MXL/unYSZO0VH+mpKu+s6MMKuvu1DMXxj2cA7yJX30s1XnbzqSzTqDaSG9 tWovxFk6r/4vmqMhIN1fnmDOPzVcN2od6zf6XCMW3Z2FFjhO+vRL1MmBsOqXcJM9ZFsRzJ bk9OKcocBtB3RR0xv75qfSbwV0rKV9QixwlzIs1MSEJ14ALylPZIv1fXDe55yA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N /usr/home/jesper/arm64-workspace/obj/usr/home/jesper/freebsd-drm-n/main/arm64.aarch64/lib/libbsddialog/.depend, 1: ignoring stale .depend for /usr/home/jesper/arm64-workspace/obj/usr/home/jesper/freebsd-drm-n/main/arm64.aarch64/tmp/usr/lib/libformw.a --- libprivatebsddialog.so.0.full --- building shared library libprivatebsddialog.so.0 cc -target aarch64-unknown-freebsd14.0 --sysroot=/usr/home/jesper/arm64-workspace/obj/usr/home/jesper/freebsd-drm-n/main/arm64.aarch64/tmp -B/usr/home/jesper/arm64-workspace/obj/usr/home/jesper/freebsd-drm-n/main/arm64.aarch64/tmp/usr/bin -fstack-protector-strong -shared -Wl,-x -Wl,--fatal-warnings -Wl,--warn-shared-textrel -o libprivatebsddialog.so.0.full -Wl,-soname,libprivatebsddialog.so.0 barbox.pico commandbox.pico editorbox.pico filebox.pico formbox.pico infobox.pico lib_util.pico libbsddialog.pico menubox.pico messagebox.pico textbox.pico theme.pico timebox.pico -lncursesw -ltinfow -lformw --- all_subdir_lib/ofed --- --- all_subdir_lib/ofed/libibnetdisc --- ===> lib/ofed/libibnetdisc (all) --- all_subdir_lib/libbsddialog --- ld: error: unable to find library -lformw Same error here https://github.com/freebsd/freebsd-src/runs/4314231703 /jsm From nobody Wed Nov 24 20:45:20 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id DB4C018B720E for ; Wed, 24 Nov 2021 20:45:23 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HztLW5blyz3Mrx; Wed, 24 Nov 2021 20:45:23 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wm1-x333.google.com with SMTP id i12so3633293wmq.4; Wed, 24 Nov 2021 12:45:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :mime-version:content-transfer-encoding; bh=ZS1v9YmRcVYKXLRtC+eY6HC7eRGVN5etn12rT4dqxGA=; b=nKbwqiVmpz9L2AWSiwLQI1ZAfXQtgJq9dhpUOzRCtATvmIV1EK8rM6Db3qzF8HD5Go YxwgW6eM8IeRexsXZHuWk3ihvsZS56eBwYSdaFfvRxM8LYi+MDdHvhBwUi4KinWwfA9B s4MfV1Fizy9qGe+UewKfiXyegMVSz0d+gJMjXYAjxxoGNGIdtqAYuTa66EdrTCcMxMwC oSGBHNc5bQI3uk2c8kGPsRgL/kp/2504MdJS8sPHvR8KUVv1bfRMgdHEtrWlZvRPwTL1 y8fb7a6yuBP/sXcuDpbjhVfk2x/PHT/+SEHRfe2xm/karWX7huiJFjml8Uv1AEgXyX7n KycQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:reply-to:mime-version:content-transfer-encoding; bh=ZS1v9YmRcVYKXLRtC+eY6HC7eRGVN5etn12rT4dqxGA=; b=BgUq0GRyo97J2ZvH+IC9IMc6nXjdmWGW1A0CezU0lL7SYqS1O67BMxjnYCVBZKvveV Tt6FjVJmWQZGvvHNjt6EK3nfb+AXj6AjAKs6pM11TYjyUkh5TwFMT0pR8xCXS94w1VDI bUVxqoxSGiNy/TxeZABBKLBSnB7nhjTST1qeXQCnCCU+GoYZVWLR8NnYwtaR+NBF7l6Y vyqhJZ4wgamgyK8T+0GjYlrksSVje08KZTN+rHYDstsSSMVDpTm40NuOEecF4ZzVwp3l MSvsuo7wslhdl8hoUvUGsyPwFLmE4xnrMzW9YUfd0kY8kFZkbPo0hYd15org7C1Hi+WJ xNJA== X-Gm-Message-State: AOAM53147lTj3WTatKcyvQWu0bpZeVubCMYdqNHgPqwpEhSyKitvW4EM d8+ZwhPcJwPfb7q3jKgT8E8= X-Google-Smtp-Source: ABdhPJzJqV6RwczCIHgVWS7BWKX+2hv+aXgGIKnqB1n0IMC2VB9rsA1lRwmmGcpDlpvMiMp+JXC8Rg== X-Received: by 2002:a05:600c:19d1:: with SMTP id u17mr19494437wmq.148.1637786722576; Wed, 24 Nov 2021 12:45:22 -0800 (PST) Received: from ernst.home (pd9e234a7.dip0.t-ipconnect.de. [217.226.52.167]) by smtp.gmail.com with ESMTPSA id l5sm1146570wrs.59.2021.11.24.12.45.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Nov 2021 12:45:22 -0800 (PST) Date: Wed, 24 Nov 2021 21:45:20 +0100 From: Gary Jennejohn To: Warner Losh Cc: John Baldwin , "Bjoern A. Zeeb" , FreeBSD Current , Jessica Clarke Subject: Re: make cleandiry tries to access /lib/geom Message-ID: <20211124214520.65e2c3cd@ernst.home> In-Reply-To: References: Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4HztLW5blyz3Mrx X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Wed, 24 Nov 2021 10:03:22 -0700 Warner Losh wrote: > On Wed, Nov 24, 2021 at 9:52 AM John Baldwin wrote: > > > On 11/24/21 3:30 AM, Bjoern A. Zeeb wrote: > > > Hi, > > > > > > 673 ===> usr.bin/diff/tests (cleandir) > > > 674 ===> lib/geom (cleandir) > > > 675 ===> sbin/mount_udf (cleandir) > > > 676 make[6] warning: /lib/geom: Permission denied. > > > > > > ^^^^ not sure what is going on here? > > > > > > 677 ===> share/i18n/esdb/ISO-8859 (cleandir) > > > 678 ===> tests/sys/cddl/zfs/tests/cli_root/zfs_clone (cleandir) > > > > I think Jess has a possible fix. This is some regression added in the > > build system several months ago. > > > https://reviews.freebsd.org/D30990 I have MAKEOBJDIRPREFIX pointing to ~/obj. This works for me, no longer any /xxx/yyy/ permisson denied errors. -- Gary Jennejohn From nobody Wed Nov 24 21:26:45 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id BF15218A7329 for ; Wed, 24 Nov 2021 21:27:28 +0000 (UTC) (envelope-from jsm@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HzvH43d2Nz3srH; Wed, 24 Nov 2021 21:27:28 +0000 (UTC) (envelope-from jsm@FreeBSD.org) Received: from [192.168.1.5] (mail.northatlanticmusicsupplies.com [212.237.182.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jsm) by smtp.freebsd.org (Postfix) with ESMTPSA id 0D2C12933; Wed, 24 Nov 2021 21:27:27 +0000 (UTC) (envelope-from jsm@FreeBSD.org) Message-ID: <2973ca16-428d-b5a3-6e60-89d4aa4a5d98@FreeBSD.org> Date: Wed, 24 Nov 2021 22:26:45 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: bsddialog cannot crosscompile to arm64 from amd64 -lformw not found. Content-Language: en-US From: Jesper Schmitz Mouridsen To: freebsd-current Cc: bapt@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1637789248; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=y6ejB07X6PMkVTK705IR8A2j5cSATvwvspr2EFQA70E=; b=AiasGj396cMJzbeUQTXXcxpLZ7hXWnpJb5KhBCJ9vC5rDL9I9htF2AhNGBt3Eq3iZ//mJX bmiOQWs6UHaxDyl6rLaNpuMh8UdXgEfWvH3e3T0uBUOnnObRQDlB+S2eeRUPLsxshAHhqp 0127nvMPCcak+HGvW3ygFH2jsjI/0qG7IQEwFmS6cRDVp6DCB2dql50U4GMYUUGUI2UJ7z gzjvpBanhwj8kyTi1PpN9kO7boWEDM1vZZjQr/TnkLHCkQjGa1RUs2VJ+QLlhXw13LLYfY EJnfZK0pwGKybMhSeKqkQ6VKgEYXu58ut531Lu84Y8F+xYiIvthBFPrsiApqYw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1637789248; a=rsa-sha256; cv=none; b=q1NTEASVz9em79p60r2q9jB/K1Ia2PfdTSobwT9VdEwPxA1OA7gK315SdfUa/4PNesyeeL Eg//hR5twCvmVEWLlmNYR8QR+Ygn6MqwyWyAWmkvcwAhw93m1Wj07olezJCw7hXqVCEj3/ 6tYC79OJBEs+X9+5CX4cXNIbuNcxXYMWBbP/xj2uTVqNntxmRYArFIQY64cGYo/xcm/oa/ 802ZmSH2fF+BL9mnv2B1BN9pv57tjYDFlvphb2WW60m3mgShze8EgEZKZkerV+/CK9Ah+I XE1biG2/Y6sEvVywSUldlFjrX2odJ61dkNdnxKgTiHFVzACB5aFWImf9G3gsOg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N fixed by emaste in 483a226238ed8949c6d280ae0757a0683962a74b On 24.11.2021 19.29, Jesper Schmitz Mouridsen wrote: > /usr/home/jesper/arm64-workspace/obj/usr/home/jesper/freebsd-drm-n/main/arm64.aarch64/lib/libbsddialog/.depend, > 1: ignoring stale .depend for > /usr/home/jesper/arm64-workspace/obj/usr/home/jesper/freebsd-drm-n/main/arm64.aarch64/tmp/usr/lib/libformw.a > > > > > --- libprivatebsddialog.so.0.full --- > building shared library libprivatebsddialog.so.0 > cc -target aarch64-unknown-freebsd14.0 > --sysroot=/usr/home/jesper/arm64-workspace/obj/usr/home/jesper/freebsd-drm-n/main/arm64.aarch64/tmp > -B/usr/home/jesper/arm64-workspace/obj/usr/home/jesper/freebsd-drm-n/main/arm64.aarch64/tmp/usr/bin >    -fstack-protector-strong -shared -Wl,-x -Wl,--fatal-warnings > -Wl,--warn-shared-textrel  -o libprivatebsddialog.so.0.full > -Wl,-soname,libprivatebsddialog.so.0 barbox.pico commandbox.pico > editorbox.pico filebox.pico formbox.pico infobox.pico lib_util.pico > libbsddialog.pico menubox.pico messagebox.pico textbox.pico theme.pico > timebox.pico  -lncursesw  -ltinfow  -lformw > --- all_subdir_lib/ofed --- > --- all_subdir_lib/ofed/libibnetdisc --- > ===> lib/ofed/libibnetdisc (all) > --- all_subdir_lib/libbsddialog --- > ld: error: unable to find library -lformw > > > Same error here > https://github.com/freebsd/freebsd-src/runs/4314231703 > > /jsm > From nobody Wed Nov 24 23:15:31 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 996A41895C52 for ; Wed, 24 Nov 2021 23:15:32 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Hzxgl73snz3Q5t for ; Wed, 24 Nov 2021 23:15:31 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: by mail-wm1-x334.google.com with SMTP id d72-20020a1c1d4b000000b00331140f3dc8so3353376wmd.1 for ; Wed, 24 Nov 2021 15:15:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=NShU+csR9Q9GAxKg5MscIwxA0pflVu700EhLTA8yOnQ=; b=qEtZVX7eKXOwUA6XBVR4VWBpvH4c62BQtFB7CLJnK/x42iuqkvzCBXvdd2P9shYRqn 15nf8VlSdZvo8tTZlSgPGyPeBRMWpi+A0kZI2g9JpRbNAMziA4LZnSTd/5ezB2f9WnTw 7CgKgcke2uSAmxN6CLhtuDpZZKvzq4I8gACA2KCHilMhlt7tYFyopUWE9CIkG5U4DAsB BSFV6ePvOAiqPWvW6HL/GfD1uUgwve/H+TIQqFZ3y8U302GW4slH8dhSbnoLn+P9N00N YwwiHDYCWhqMMUpMJTaAArbwSVMDKqBFvlybGtCYwunPRHWkoY0opd9jaOgePu1x85yC Ah8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=NShU+csR9Q9GAxKg5MscIwxA0pflVu700EhLTA8yOnQ=; b=yH8ev+HIHFo80RLK5YniiIcYQ1X6TSsicRUi5kyDypRxcKYKVZhuz8Zg4zqr764/Tv DX3T7wSjEbSaeEUw+ER1ESNCQM265Rp6EfA8xcin1relYZHLvvu3XgjwxT9Jdb1vCnHm VvVJ25DrPDKLW2XkdAHgyGEXRdgR5Z9Ca0zEVorr35LiPPUt7uCu5rChbOwqj3QsNvXj +iVVqWvwlL11XEkwOv4DVOYxdQJxYWr0NmF7xCOugzMKbYgTY3ciEdV5opzUJihNvU3u wiJAgXpaR8Ku7SaVo8QMlS2Zhh7XTpHJwXn8l5mN2R6cxnOeH6/Oe8i+kCpWUqn6/Us9 d70Q== X-Gm-Message-State: AOAM5305zVG5buCttThAsHSuCRnatluYSZc2jDqNbK/CegE9ymafaAjB m6CHZpz/27P8T3MIBGkBizJGqJTX2HjLyg== X-Google-Smtp-Source: ABdhPJzYxr15aOu2SKYwfODj5Ic/S7NZadEO+OZvu3MLY5MbqrgRxLEETP/5dtVF49iYI+uZC4svSQ== X-Received: by 2002:a7b:c157:: with SMTP id z23mr1167355wmi.113.1637795730558; Wed, 24 Nov 2021 15:15:30 -0800 (PST) Received: from ?IPV6:2001:470:1f1c:a0::2? (tunnel642390-pt.tunnel.tserv1.lon2.ipv6.he.net. [2001:470:1f1c:a0::2]) by smtp.gmail.com with ESMTPSA id k8sm1041217wrn.91.2021.11.24.15.15.29 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 24 Nov 2021 15:15:29 -0800 (PST) Message-ID: <3fa71306-5826-4f23-9350-a39ef1b90074@gmail.com> Date: Wed, 24 Nov 2021 23:15:31 +0000 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: Problem with newer version of firefox Content-Language: en-GB To: freebsd-current@freebsd.org References: <1899088412.3452349.1637317808845.ref@mail.yahoo.com> <1899088412.3452349.1637317808845@mail.yahoo.com> From: Graham Perrin In-Reply-To: <1899088412.3452349.1637317808845@mail.yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4Hzxgl73snz3Q5t X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=qEtZVX7e; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grahamperrin@gmail.com designates 2a00:1450:4864:20::334 as permitted sender) smtp.mailfrom=grahamperrin@gmail.com X-Spamd-Result: default: False [-3.99 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::334:from]; NEURAL_HAM_SHORT(-0.99)[-0.994]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N On 19/11/2021 10:30, Filippo Moretti via current wrote: > … after upgrading firefox To which version, exactly? The package from the FreeBSD repo? pkg query '%o %v %R' firefox Which build of CURRENT? uname -aKU ---- Here, no problem with www/firefox 94.0.1_1,2. FreeBSD mowa219-gjp4-8570p-freebsd 14.0-CURRENT FreeBSD 14.0-CURRENT #115 main-n250650-ef396441ceb: Sat Nov 13 23:52:09 GMT 2021 root@mowa219-gjp4-8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64 1400041 1400041 > … "libmozsqlite3.so" not found, … Output from `pkg provides libmozsqlite3.so` shows the file provided by firefox-94.0.1_1,2 and four other packages. From nobody Thu Nov 25 02:36:02 2021 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 5BCEB18940FB for ; Thu, 25 Nov 2021 02:36:11 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4J027G2sd4z3gyY for ; Thu, 25 Nov 2021 02:36:10 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 1AP2a2Dd010761 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Thu, 25 Nov 2021 04:36:05 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 1AP2a2Dd010761 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 1AP2a20r010760 for current@freebsd.org; Thu, 25 Nov 2021 04:36:02 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 25 Nov 2021 04:36:02 +0200 From: Konstantin Belousov To: current@freebsd.org Subject: VDSO on amd64 Message-ID: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on tom.home X-Rspamd-Queue-Id: 4J027G2sd4z3gyY X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com X-Spamd-Result: default: False [-2.73 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.74)[-0.740]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org]; HAS_XAW(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all:c]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_DN_NONE(0.00)[]; NEURAL_HAM_SHORT(-0.99)[-0.993]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; FREEMAIL_ENVFROM(0.00)[gmail.com]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none] X-ThisMailContainsUnwantedMimeParts: N I have mostly finished implementation of "proper" vdso for amd64 native binaries, both 64bit and 32bit. Vdso wraps signal trampolines into real dynamic shared object, which is prelinked into dynamically linked image. The main (and in fact, now the only) reason for wrapping trampolines into vdso is to provide proper unwind annotation for the signal frame, without a need to teach each unwinder about special frame types. In reality, most of them are already aware of our signal trampolines, since there is no other way to walk over them except to match instructions sequence in the frame. Also, we provide sysctl kern.proc.sigtramp which reports the location of the trampoline. So this patch should not make much difference for e.g. gdb or lldb. On the other hand, I noted that llvm13 unwinder with vdso is able to catch exceptions thrown from the signal handler, which was a suprise to me. Corresponding test code is available at https://gist.github.com/b886401fcc92dc37b49316eaf0e871ca Another advantage for us is that having vdso allows to change trampoline code without breaking unwinders. Vdso's for both 64bit and 32bit ABI are put into existing shared page. This means that total size of both objects should be below 4k, and some more space needs to be left available, for stuff like timehands and fxrng. Using linker tricks, which is where the most complexity in this patch belongs, I was able to reduce size of objects below 1.5k. I believe some more space saving could be achieved, but I stopped there for now. Or we might extend shared region object to two pages, if current situation appears to be too tight. The implementation can be found at https://reviews.freebsd.org/D32960 Signal delivery for old i386 elf (freebsd 4.x) and a.out binaries was not yet tested. Your reviews, testing, and any other form of feedback is welcomed. The work was sponsored by The FreeBSD Foundation. From nobody Thu Nov 25 05:34:19 2021 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 33EDF18A9142 for ; Thu, 25 Nov 2021 05:34:29 +0000 (UTC) (envelope-from pi@freebsd.org) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4J065114ryz3PYg for ; Thu, 25 Nov 2021 05:34:29 +0000 (UTC) (envelope-from pi@freebsd.org) Received: from pi by home.opsec.eu with local (Exim 4.94.2 (FreeBSD)) (envelope-from ) id 1mq7Ol-0006eZ-8v; Thu, 25 Nov 2021 06:34:19 +0100 Date: Thu, 25 Nov 2021 06:34:19 +0100 From: Kurt Jaeger To: Konstantin Belousov Cc: current@freebsd.org Subject: Re: VDSO on amd64 Message-ID: References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4J065114ryz3PYg X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi! > I have mostly finished implementation of "proper" vdso for amd64 > native binaries, both 64bit and 32bit. Vdso wraps signal trampolines > into real dynamic shared object, which is prelinked into dynamically > linked image. Eleven years ago Giuseppe Cocomazzi posted this: http://lists.freebsd.org/pipermail/freebsd-hackers/2010-April/031553.html vdso and shared page patch My question: What's the difference between https://reviews.freebsd.org/D32960 and those changes from 2010 ? I'm curious and maybe a little explaination would help me understand what happened between 2010 and now. -- pi@opsec.eu +49 171 3101372 Now what ? From nobody Thu Nov 25 08:20:54 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 813FC18B2C6E for ; Thu, 25 Nov 2021 08:21:07 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp6.goneo.de (smtp6.goneo.de [85.220.129.31]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4J09nG4F2nz3Lrv for ; Thu, 25 Nov 2021 08:21:06 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from hub1.goneo.de (hub1.goneo.de [85.220.129.52]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by smtp6.goneo.de (Postfix) with ESMTPS id CF9DF10A3310 for ; Thu, 25 Nov 2021 09:20:58 +0100 (CET) Received: from hub1.goneo.de (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPS id 89B4510A75DF for ; Thu, 25 Nov 2021 09:20:56 +0100 (CET) Received: from hermann (dynamic-2a01-0c22-accf-9600-c9bf-7e8a-0692-4200.c22.pool.telefonica.de [IPv6:2a01:c22:accf:9600:c9bf:7e8a:692:4200]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPSA id 4B0A710A75DE for ; Thu, 25 Nov 2021 09:20:56 +0100 (CET) Date: Thu, 25 Nov 2021 09:20:54 +0100 From: FreeBSD User To: FreeBSD CURRENT Subject: CURRENT: llvm13 seem to miscompile dns/bind916 (9.16.23) Message-ID: <20211125092054.4696b6f2@hermann> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-UID: 842dfd X-Rspamd-UID: d792fb X-Rspamd-Queue-Id: 4J09nG4F2nz3Lrv X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd@walstatt-de.de has no SPF policy when checking 85.220.129.31) smtp.mailfrom=freebsd@walstatt-de.de X-Spamd-Result: default: False [1.55 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[walstatt-de.de]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[4]; MID_RHS_NOT_FQDN(0.50)[]; TO_DN_ALL(0.00)[]; NEURAL_SPAM_MEDIUM(0.96)[0.964]; NEURAL_SPAM_LONG(0.28)[0.283]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:25394, ipnet:85.220.128.0/17, country:DE]; RCVD_TLS_ALL(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[85.220.129.31:from] X-ThisMailContainsUnwantedMimeParts: N Running CURRENT (FreeBSD 14.0-CURRENT #7 main-n250911-a11983366ea7: Mon Nov 22 18:17:54 CET 2021 amd64) troubles me with our DNS server/service. Aproximately the same time we switched on CURRENT to the CURRENT LLVM13 version and also, after the compilation of a fresh OS with LLVM13, the upgrade from bind-9.16.22 to bind-9.16.23 took place as well as ASLR being the default. Since then named is crashing with a mysterious segmentation fault (see PR 259921, https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259921). Disabling ASLR as recommended to check whether ASLR triggers the SegFault did not solve the problem, so I suspect a miscompilation due to llvm13. On 13-STABLE bind-9.16.23 seem not to have this behaviour. I'm floating like a dead man in the water, can someone help? Kind regards, oh From nobody Thu Nov 25 09:35:53 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id A8A9C18B7861 for ; Thu, 25 Nov 2021 09:35:59 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J0CRf6Fhtz4TZc for ; Thu, 25 Nov 2021 09:35:58 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtp.theravensnest.org (smtp.theravensnest.org [45.77.103.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: theraven) by smtp.freebsd.org (Postfix) with ESMTPSA id 59D0A8B38 for ; Thu, 25 Nov 2021 09:35:58 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from [192.168.1.202] (unknown [81.141.223.90]) by smtp.theravensnest.org (Postfix) with ESMTPSA id 6E0D42D7CE for ; Thu, 25 Nov 2021 09:35:56 +0000 (GMT) Message-ID: <7e7f4ba7-16b3-fa6e-fa1d-e9df957e91f1@FreeBSD.org> Date: Thu, 25 Nov 2021 09:35:53 +0000 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Subject: Re: VDSO on amd64 Content-Language: en-GB To: freebsd-current@freebsd.org References: From: David Chisnall In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1637832959; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=LRJyhtOjbLrvfU40ZoDwGsFzLDpOZ5KfivVcDUuq6Qc=; b=gMmhFFP2ZbthTbxj313lIw3IKsFBRPNZL06eM9CcMymDnQOE6FcZeYUzJn8XHjQlIs1yOE 8Cr08uhvmOkykcLvqPlttfnSv//OY+8M5wf9uXVBMOTNto+I9I1Km2163wOA2r7bpgxTPs u+EjSXd5AjmTggVIY5rPI0dY8U2mrpUTov0hN9UIXnJLp9iZ4RTNebl9vtgyY7ukM14HKG pSQj4COwGYm1TnKO3SUUDINtYEpGzhnfjbeFvBpKt1bx41JNEFKcoNMb0eLMotkmGFXfwA ATUNqDbu3cUXID+aYKqjpvoV/IiP82AspzbYqHMikz35Sg6JMGTndoLnCH/I9Q== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1637832959; a=rsa-sha256; cv=none; b=ID8pBUKQj3VkdmUj5NVLiT6Al8FdffhG1/owYIC52VADA1kl32GJ13oMXXmmw87LprFoc9 MIwLNeZKBmWnueOg+tgAKKSelW0BAlAC5Ej91vH+hZXBtDWgWbBmfHoopEJL06pYWuDBQe 6grrCFh5tsKa7ltodZ7DENuH+atKV2jjPE2eaEToFWFYCD2LSCQS7QY0Ig3OI7XADBfZGK Ke9NWVay0k8lo7ePqyoPRKOUy5osVX+Snpg31RB8XcBOOUy7b721tD7Mfw0uwrnJBpO0VE 2UVRAOLEpYTWOJJoXN3sBRvSASAkDJ1RuexPgtVJUfkUJOCTurDN+XdtJ4DecQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Great news! Note that your example of throwing an exception from a signal handler works because the signal is delivered during a system call. The compiler generates correct unwind tables for calls because any call may throw. If you did something like a division by zero to get a SIGFPE or a null-pointer dereference to get a SIGSEGV then the throw would probably not work (or, rather, would be delivered to the right place but might corrupt some register state). Neither clang nor GCC currently supports non-call exceptions by default. This mechanism is more useful for Java VMs and similar. Some Linux-based implementations (including Android) use this to avoid null-pointer checks in Java. The VDSO mechanism in Linux is also used for providing some syscall implementations. In particular, getting the current approximate time and getting the current CPU (either by reading from the VDSO's data section or by doing a real syscall, without userspace knowing which). It also provides the syscall stub that is used for the kernel transition for all 'real' syscalls. This doesn't matter so much on amd64, but on i386 it lets them select between int 80h, syscall or sysenter, depending on what the hardware supports. A few questions about future plans: - Do you have plans to extend the VDSO to provide system call entry points and fast-path syscalls? It would be really nice if we could move all of the libsyscalls bits into the VDSO so that any compartmentalisation mechanism that wanted to interpose on syscalls just needed to provide a replacement for the VDSO. - It looks as if the Linux VDSO mechanism isn't yet using this. Do you plan on moving it over? - I can't quite tell from kern_sharedpage.c (this file has almost no comments) - is the userspace mapping of the VDSO randomised? This has been done on Linux for a while because the VDSO is an incredibly high-value target for code reuse attacks (it can do system calls and it can restore the entire register state from the contents of an on-stack buffer if you can jump into it). David On 25/11/2021 02:36, Konstantin Belousov wrote: > I have mostly finished implementation of "proper" vdso for amd64 > native binaries, both 64bit and 32bit. Vdso wraps signal trampolines > into real dynamic shared object, which is prelinked into dynamically > linked image. > > The main (and in fact, now the only) reason for wrapping trampolines > into vdso is to provide proper unwind annotation for the signal frame, > without a need to teach each unwinder about special frame types. In > reality, most of them are already aware of our signal trampolines, > since there is no other way to walk over them except to match > instructions sequence in the frame. Also, we provide sysctl > kern.proc.sigtramp which reports the location of the trampoline. > > So this patch should not make much difference for e.g. gdb or lldb. > On the other hand, I noted that llvm13 unwinder with vdso is able to > catch exceptions thrown from the signal handler, which was a suprise > to me. Corresponding test code is available at > https://gist.github.com/b886401fcc92dc37b49316eaf0e871ca > > Another advantage for us is that having vdso allows to change > trampoline code without breaking unwinders. > > Vdso's for both 64bit and 32bit ABI are put into existing shared page. > This means that total size of both objects should be below 4k, and > some more space needs to be left available, for stuff like timehands > and fxrng. Using linker tricks, which is where the most complexity in > this patch belongs, I was able to reduce size of objects below 1.5k. > I believe some more space saving could be achieved, but I stopped > there for now. Or we might extend shared region object to two pages, > if current situation appears to be too tight. > > The implementation can be found at https://reviews.freebsd.org/D32960 > > Signal delivery for old i386 elf (freebsd 4.x) and a.out binaries was > not yet tested. > > Your reviews, testing, and any other form of feedback is welcomed. > The work was sponsored by The FreeBSD Foundation. > From nobody Thu Nov 25 19:53:19 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 7EAA718B0460 for ; Thu, 25 Nov 2021 19:53:28 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4J0T880s0Tz3Lt0; Thu, 25 Nov 2021 19:53:27 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 1APJrJoW066046 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 25 Nov 2021 21:53:22 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 1APJrJoW066046 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 1APJrJXE066045; Thu, 25 Nov 2021 21:53:19 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 25 Nov 2021 21:53:19 +0200 From: Konstantin Belousov To: David Chisnall Cc: freebsd-current@freebsd.org Subject: Re: VDSO on amd64 Message-ID: References: <7e7f4ba7-16b3-fa6e-fa1d-e9df957e91f1@FreeBSD.org> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7e7f4ba7-16b3-fa6e-fa1d-e9df957e91f1@FreeBSD.org> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on tom.home X-Rspamd-Queue-Id: 4J0T880s0Tz3Lt0 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Thu, Nov 25, 2021 at 09:35:53AM +0000, David Chisnall wrote: > Great news! > > Note that your example of throwing an exception from a signal handler works > because the signal is delivered during a system call. The compiler > generates correct unwind tables for calls because any call may throw. The syscalls itself are not annotated, I consider fixing this after vdso lands. > > If you did something like a division by zero to get a SIGFPE or a > null-pointer dereference to get a SIGSEGV then the throw would probably not > work (or, rather, would be delivered to the right place but might corrupt > some register state). Neither clang nor GCC currently supports non-call > exceptions by default. Well, yes, the part of it was that the signal was synchronous. I was always curious, how good are unwind tables generated by -fasynchronous-unwind-tables with this regard. But still, the fact that unwinder stepped over the signal frame amused me. > > This mechanism is more useful for Java VMs and similar. Some Linux-based > implementations (including Android) use this to avoid null-pointer checks in > Java. > > The VDSO mechanism in Linux is also used for providing some syscall > implementations. In particular, getting the current approximate time and > getting the current CPU (either by reading from the VDSO's data section or > by doing a real syscall, without userspace knowing which). It also provides > the syscall stub that is used for the kernel transition for all 'real' > syscalls. This doesn't matter so much on amd64, but on i386 it lets them > select between int 80h, syscall or sysenter, depending on what the hardware > supports. > > > A few questions about future plans: > > - Do you have plans to extend the VDSO to provide system call entry points > and fast-path syscalls? It would be really nice if we could move all of the > libsyscalls bits into the VDSO so that any compartmentalisation mechanism > that wanted to interpose on syscalls just needed to provide a replacement > for the VDSO. No. Moving syscall entry point to VDSO is pointless: - it would add one more level of indirection before SYSCALL, - we do not have slow syscall entry point on amd64 so there is nothing to choose. And optimizing 32bit binaries (where we could implement slightly faster syscall entry) is past its importance. Basically, we do not have to split libc into libc proper and VDSO, as Linux has. We can implement features for syscall boundary from both sides of kernel, because libc and kernel are developed under the same project. Usermode timehands, fast signal blocks, upcoming rseq support, just to name a few of them, all benefit from this model. VDSO is only needed for us to provide the unwind annotations on the signal trampoline, in a way expected by unwinders. > > - It looks as if the Linux VDSO mechanism isn't yet using this. Do you > plan on moving it over? No. > > - I can't quite tell from kern_sharedpage.c (this file has almost no > comments) - is the userspace mapping of the VDSO randomised? This has been > done on Linux for a while because the VDSO is an incredibly high-value > target for code reuse attacks (it can do system calls and it can restore the > entire register state from the contents of an on-stack buffer if you can > jump into it). Not now. Randomizing shared page location is not too hard, but there are some ABI issues to sort out. We live with fixed-mapped shared page for more than 10 years. > > David > > On 25/11/2021 02:36, Konstantin Belousov wrote: > > I have mostly finished implementation of "proper" vdso for amd64 > > native binaries, both 64bit and 32bit. Vdso wraps signal trampolines > > into real dynamic shared object, which is prelinked into dynamically > > linked image. > > > > The main (and in fact, now the only) reason for wrapping trampolines > > into vdso is to provide proper unwind annotation for the signal frame, > > without a need to teach each unwinder about special frame types. In > > reality, most of them are already aware of our signal trampolines, > > since there is no other way to walk over them except to match > > instructions sequence in the frame. Also, we provide sysctl > > kern.proc.sigtramp which reports the location of the trampoline. > > > > So this patch should not make much difference for e.g. gdb or lldb. > > On the other hand, I noted that llvm13 unwinder with vdso is able to > > catch exceptions thrown from the signal handler, which was a suprise > > to me. Corresponding test code is available at > > https://gist.github.com/b886401fcc92dc37b49316eaf0e871ca > > > > Another advantage for us is that having vdso allows to change > > trampoline code without breaking unwinders. > > > > Vdso's for both 64bit and 32bit ABI are put into existing shared page. > > This means that total size of both objects should be below 4k, and > > some more space needs to be left available, for stuff like timehands > > and fxrng. Using linker tricks, which is where the most complexity in > > this patch belongs, I was able to reduce size of objects below 1.5k. > > I believe some more space saving could be achieved, but I stopped > > there for now. Or we might extend shared region object to two pages, > > if current situation appears to be too tight. > > > > The implementation can be found at https://reviews.freebsd.org/D32960 > > > > Signal delivery for old i386 elf (freebsd 4.x) and a.out binaries was > > not yet tested. > > > > Your reviews, testing, and any other form of feedback is welcomed. > > The work was sponsored by The FreeBSD Foundation. > > From nobody Thu Nov 25 20:48:36 2021 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E1BFF18AB5C0 for ; Thu, 25 Nov 2021 20:48:43 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J0VMv5Fx2z3tlb for ; Thu, 25 Nov 2021 20:48:43 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from [192.168.0.88] (unknown [195.64.148.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: avg/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 55DECE5FD for ; Thu, 25 Nov 2021 20:48:43 +0000 (UTC) (envelope-from avg@FreeBSD.org) Message-ID: Date: Thu, 25 Nov 2021 22:48:36 +0200 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Firefox/91.0 Thunderbird/91.3.0 Content-Language: en-US From: Andriy Gapon Subject: ctfconvert: rc = 1 Unsupported version [_dwarf_info_load(229)] To: FreeBSD Current Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1637873323; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=TQtk5V/GzyYbHgIAzQ0X3TqdvG47RoVfk/5L7tFa55w=; b=R0qPcA2t0g2oejntmyKBSthqD9Wzs48KV5PvpBzddwhpbefBZ2q21Uc8BJi/8PlBDWBMpB ejMHq6lYktVWHDRtvuegv/E6GqqK0npp1mluSahei+RNquFUJSEN6wjzDyd2XPXpWqomgM kDRGnMNSAOuxdxvnmraDKoCO5HpNwvTnL60cIwKln6nyipbr7vvS2gkMAQirpaXF54wPxx OJeqh0Kds2sAIxTTq2pgPSqxCbq24ly9Dx/OTn+atwAvMDwLEeHHrNIBJAWsYjxlWDFSv9 pNC1+hG4zQG0zpH18igbp508m79ZvTu0jrZDhjaD27n/LVey3SSlozMZSchQVA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1637873323; a=rsa-sha256; cv=none; b=NmL8Rwtv+QlTqTGxWXxXRl7BXbzk4WtktpHns/Htt4UemC7O0kF1x8eWnIQgLnJ0FyuZ8E netukNMFYK1PGtQbqJTBU1iDQVLgvyMLwmT7rws1nVt5+xv2ww75d92EHWwr3nfDu83xIq cM1L7KEe9A+RVHBV3hsXQgZY+vMEd90W+pBZaLu9AOpVyUyM58K95pVpDe7gXlFzfrOJyS bgPiKy5/I1/SCVemqttbJa789MmHm1M3/aFAl6NQdAp/9dFfozVLZubCjJiqBl6U3KKDul ppoN0WYFNFQ/5Ci1F2a63nY1/6OAXrOYHTtvtdTVTniYYUV1VyzGl1eKWlGZjQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N I've just finished builds of yesterday's CURRENT / main for arm and arm64. In both builds I got lots of messages from ctfconvert: ctfconvert: rc = 1 Unsupported version [_dwarf_info_load(229)] I got an impression that there was a message for each object file, that's how many of them were there. I don't recall seeing those messages before. Should I be concerned? Maybe I am doing something wrong or have an unusual configuration? Any way to fix the issue? Thanks! P.S. The builds were done on stable/13, so maybe there is an issue with host tools not being able to grok something new. -- Andriy Gapon From nobody Thu Nov 25 20:52:54 2021 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id DA2B418AD287 for ; Thu, 25 Nov 2021 20:53:04 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4J0VSv6nn7z4Qm2; Thu, 25 Nov 2021 20:53:03 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 1APKqs5e081827 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 25 Nov 2021 22:52:57 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 1APKqs5e081827 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 1APKqspB081826; Thu, 25 Nov 2021 22:52:54 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 25 Nov 2021 22:52:54 +0200 From: Konstantin Belousov To: Kurt Jaeger Cc: current@freebsd.org Subject: Re: VDSO on amd64 Message-ID: References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on tom.home X-Rspamd-Queue-Id: 4J0VSv6nn7z4Qm2 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Thu, Nov 25, 2021 at 06:34:19AM +0100, Kurt Jaeger wrote: > Hi! > > > I have mostly finished implementation of "proper" vdso for amd64 > > native binaries, both 64bit and 32bit. Vdso wraps signal trampolines > > into real dynamic shared object, which is prelinked into dynamically > > linked image. > > Eleven years ago Giuseppe Cocomazzi posted this: > > http://lists.freebsd.org/pipermail/freebsd-hackers/2010-April/031553.html > > vdso and shared page patch > > My question: What's the difference between > > https://reviews.freebsd.org/D32960 > > and those changes from 2010 ? I'm curious and maybe a little explaination > would help me understand what happened between 2010 and now. No idea. If you are so curious, read both and compare. From nobody Fri Nov 26 01:52:04 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 7B7F818A6757 for ; Fri, 26 Nov 2021 01:52:12 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J0d642ZjFz3LjH for ; Fri, 26 Nov 2021 01:52:12 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qt1-x835.google.com with SMTP id q14so7626478qtx.10 for ; Thu, 25 Nov 2021 17:52:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=iRQkQITCiEVnx+DdEGSy3Gw5kxgFCUKwwjWI8tw/eVU=; b=U0SsPF2iNMyJ0dARZBBNF9hALl8z4pe055sRwAFy+0wWg2j6dIi28FO4aFJxD3mWRL PUjyFFgT7Cg5fCyn/fpb7mYdxU6F9nyvQ+Y+EpVDo+a3QYS8kto2rQWHMqfcUW6y6WZJ mfHSueXoVWhEkzM+IkB/nxMGY5/pF2X8/qgh/r+eXAdUXK4JpbJyrn8pI4SO5DzJ+P1h YXachVTL112I1AYObOZXCHIzJR2S63M1nRsPRj2WJni5lukANYz8uifZZHk/NVSy6xkY d1QYrienljW0ccSe3wqnV7cMKLN+oA0cK5Owcw+b4kNg9swW5MLuQZRiOP3oh6t5m0N5 hVzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=iRQkQITCiEVnx+DdEGSy3Gw5kxgFCUKwwjWI8tw/eVU=; b=jXErZoYpwGYFnRBfeonxwZtjkDuemK9z9OXpG0/1tON2UrfNwB1zdxE/bpep4scPvt uCLYNQMtypzw6tdBorVA5wvceXSOU3CGC2ctnmQQ5Auxf7bp5vameiBBYpomWPYwof1a S6UgqfF66wgVhBYPn3aFI+gCZSstI5VmgMAnHvGp9otbl+txj4yB/nTaR6jsjmvRNesW 6kJjbqbI+aVukSZMvyPH8vIRiUQ64SbBwNBlFY53eJjhzMMKj4XluRuGwvubsi511Prz 5ZFpGPsuuxkWYtMiCz9LONhIzbIJdAvfEHL3O39uQ0VKKLC9lTuHIEN+N2untGluwmG3 RcOg== X-Gm-Message-State: AOAM532kdx3cL35r8mgTDkCz3Kur9J8zXiEuVGNiBSlSZjMhv1iPMl71 nU+AyXMJEU9/ujSmw9jCd8xsVQ== X-Google-Smtp-Source: ABdhPJy6BTGuHeA/PZFy14wFkovKXco6jsFBFnBqUkb8zO9+c8ihG2JDtn//qP6FHVBuMred/Mk+lw== X-Received: by 2002:a05:622a:138a:: with SMTP id o10mr21306914qtk.237.1637891526127; Thu, 25 Nov 2021 17:52:06 -0800 (PST) Received: from mutt-hbsd (pool-100-16-224-136.bltmmd.fios.verizon.net. [100.16.224.136]) by smtp.gmail.com with ESMTPSA id g5sm2276885qko.12.2021.11.25.17.52.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 25 Nov 2021 17:52:05 -0800 (PST) Date: Thu, 25 Nov 2021 20:52:04 -0500 From: Shawn Webb To: Konstantin Belousov Cc: David Chisnall , freebsd-current@freebsd.org Subject: Re: VDSO on amd64 Message-ID: <20211126015204.5pbzmctz2fqha6o4@mutt-hbsd> X-Operating-System: FreeBSD mutt-hbsd 14.0-CURRENT-HBSD FreeBSD 14.0-CURRENT-HBSD X-PGP-Key: https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/blob/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc References: <7e7f4ba7-16b3-fa6e-fa1d-e9df957e91f1@FreeBSD.org> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="22hc2edju7gzauni" Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4J0d642ZjFz3LjH X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N --22hc2edju7gzauni Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 25, 2021 at 09:53:19PM +0200, Konstantin Belousov wrote: > On Thu, Nov 25, 2021 at 09:35:53AM +0000, David Chisnall wrote: > > Great news! > >=20 > > Note that your example of throwing an exception from a signal handler w= orks > > because the signal is delivered during a system call. The compiler > > generates correct unwind tables for calls because any call may throw. > The syscalls itself are not annotated, I consider fixing this after vdso > lands. >=20 > >=20 > > If you did something like a division by zero to get a SIGFPE or a > > null-pointer dereference to get a SIGSEGV then the throw would probably= not > > work (or, rather, would be delivered to the right place but might corru= pt > > some register state). Neither clang nor GCC currently supports non-call > > exceptions by default. > Well, yes, the part of it was that the signal was synchronous. I was alw= ays > curious, how good are unwind tables generated by -fasynchronous-unwind-ta= bles > with this regard. >=20 > But still, the fact that unwinder stepped over the signal frame amused me. >=20 > >=20 > > This mechanism is more useful for Java VMs and similar. Some Linux-bas= ed > > implementations (including Android) use this to avoid null-pointer chec= ks in > > Java. > >=20 > > The VDSO mechanism in Linux is also used for providing some syscall > > implementations. In particular, getting the current approximate time a= nd > > getting the current CPU (either by reading from the VDSO's data section= or > > by doing a real syscall, without userspace knowing which). It also prov= ides > > the syscall stub that is used for the kernel transition for all 'real' > > syscalls. This doesn't matter so much on amd64, but on i386 it lets th= em > > select between int 80h, syscall or sysenter, depending on what the hard= ware > > supports. > >=20 > >=20 > > A few questions about future plans: > >=20 > > - Do you have plans to extend the VDSO to provide system call entry po= ints > > and fast-path syscalls? It would be really nice if we could move all o= f the > > libsyscalls bits into the VDSO so that any compartmentalisation mechani= sm > > that wanted to interpose on syscalls just needed to provide a replaceme= nt > > for the VDSO. > No. >=20 > Moving syscall entry point to VDSO is pointless: > - it would add one more level of indirection before SYSCALL, > - we do not have slow syscall entry point on amd64 so there is nothing to > choose. >=20 > And optimizing 32bit binaries (where we could implement slightly faster > syscall entry) is past its importance. >=20 > Basically, we do not have to split libc into libc proper and VDSO, as > Linux has. We can implement features for syscall boundary from both > sides of kernel, because libc and kernel are developed under the same > project. Usermode timehands, fast signal blocks, upcoming rseq support, > just to name a few of them, all benefit from this model. >=20 > VDSO is only needed for us to provide the unwind annotations on the signal > trampoline, in a way expected by unwinders. >=20 > >=20 > > - It looks as if the Linux VDSO mechanism isn't yet using this. Do you > > plan on moving it over? > No. >=20 > >=20 > > - I can't quite tell from kern_sharedpage.c (this file has almost no > > comments) - is the userspace mapping of the VDSO randomised? This has = been > > done on Linux for a while because the VDSO is an incredibly high-value > > target for code reuse attacks (it can do system calls and it can restor= e the > > entire register state from the contents of an on-stack buffer if you can > > jump into it). > Not now. Randomizing shared page location is not too hard, but there are > some ABI issues to sort out. We live with fixed-mapped shared page for > more than 10 years. As a point of reference, HardenedBSD's PaX-inspired ASLR implementation has randomized the shared page for more than half a decade now without issue. I suspect FreeBSD will find, if applied properly, randomization of the shared page (now VDSO) likely won't break anything. Thanks, --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A= 4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc --22hc2edju7gzauni Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAmGgPcIACgkQ/y5nonf4 4fqBoA//S2YLTbp/fAnoPQ9FoD0S6VFdZAqoFkC/EmJqhi2f6/3y5JaSrOX8odi6 G0oBmkIBemL9yUpNnV99+KD/AJwzGlI9ZkeGfFYqFjtB6JwS0ejjff/AYXzy/Pyp ZF5EOo/fRZhOtQGAu1ix798otFPC33UCH579hSOcCpDGg3jxmUdXxXQgegxduQkw zOYLz8UXNv0dD9MkY1VbhZtnhUfN8uEwr9zdCwF8yuwHXlKcWywSxeZP3BUY4fkr 89jBoUQWhOw6e/tfauX5aKBtnuIikkYYVihBrmtt/Qad5/n2dzECpmeI7UW+klc2 Mwqa0ef+Yp+WNqCoFaj8Kc98oFdpoSucfFxERJpHQ7CaE6+P1bll9fgiZEMIz+uN fJTC64yIp+Kjn/O37Zijh47sruQKC3tR+5+soOG3GV8ZcflGmeBcUBdnQ8IcqD5g X/kmmYS48ejyhRzD7OGOMcVpIL+5eGi+gsprhbPmTCtQVGHYh32nD6VXYWwXXXs5 wGMT2pxxgwOEiYE1RQhnhLIEwxpj1D+3MjyzpqN3S9lGFoFk25vxnoz3FGyZaX4h 7wvFxKzVu2UDWwI574bit6v8VTiGzI8l9TCthQSnTcOd/tpPkPGKhGh5916Gt/Yi sfMbAbCOtVLwWYxGf1UW1m3t+XaXn0yKW3wID6iDcWP+RZEBN7g= =ydTv -----END PGP SIGNATURE----- --22hc2edju7gzauni-- From nobody Fri Nov 26 16:06:09 2021 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 771C218BD5C7 for ; Fri, 26 Nov 2021 16:06:18 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qv1-xf2e.google.com (mail-qv1-xf2e.google.com [IPv6:2607:f8b0:4864:20::f2e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J103Z2lJ5z3mDq; Fri, 26 Nov 2021 16:06:18 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qv1-xf2e.google.com with SMTP id gu12so7542923qvb.6; Fri, 26 Nov 2021 08:06:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=/kgpnakEBG0cl2Rf4k8x116LJgeJfrJkmOfseA+38Xg=; b=JfudS64+eB7TQyhu5YTNgWBQhkobSeXSALJt0U7fX7CP9U/5jKcGKu7hkcbbRkg8WA ooVrmR5U5iYKDnl1dhvAHUHH0CniRONMRC1iJLM0nHVzcouH1I4W1kqyF03P2PHHAmEP LXTKK6cKrqD8r9WyJMg0vwnevBJRLezDx0vPoh7bk1g1buyZ9Nnc74u2iGutY5hfi/oJ ek3xNDmdcIm9DzSTcFKBBpnLpUd+IfMUDLopzrUNTWR95BjtmWT87VZZZs90riTsPQGP YSA0QBwl58uq2FyjNTsMjSUjLiXU+/4j8V5fNtRdpH9Kc/KGqLb3h0nRDD5GB/qlHx2h mWVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=/kgpnakEBG0cl2Rf4k8x116LJgeJfrJkmOfseA+38Xg=; b=SH3sSB8MyFjbolOORXIh6bmsTGQbJBmIQPRhU9rTE9QjQwPJaEMyyrfm4/aNqJzSh4 4c80WGcabPvqQmcgi5uvV8wlsSX78qL5ftm3xxSiVHvCwIjDcofuzlMfUcC9ibDEYPZB C4m2UjJK5d1DYflCS3+KbOm05jSrrQOS8ZsOfSqFYFFoBCgLPxDQg68A4dIxG5TEaI0n gN6bV65Ua0VFXqzsDiuK9YnXhuNjYqII0vEcs9d+VcHosKknildf7+voxRab3NH5i0KP tGoHCH3TV5KkPJnHpku/Fdq4xsBLwDev2yidGp9em+m8MiU42cxwHo/OUDbcWv0OWH5t PoUQ== X-Gm-Message-State: AOAM532+dwVdpwZZ4rqlz3k/Zh4C/S7hnIAXoAJobVdFiSHOtnR1vwPC Q+WVAUcoWEhvQ3/JEpEwWs3+MxCMVZI= X-Google-Smtp-Source: ABdhPJzUFLLf8UgvnryzUQCNlibVYhORJTSAyV2eJ9vMQ8HJi8iR1L60aqn3w7SPRPMB9QN6XdaX9A== X-Received: by 2002:a05:6214:15c6:: with SMTP id p6mr25656925qvz.12.1637942771445; Fri, 26 Nov 2021 08:06:11 -0800 (PST) Received: from nuc ([142.126.186.191]) by smtp.gmail.com with ESMTPSA id bp18sm3359660qkb.39.2021.11.26.08.06.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 26 Nov 2021 08:06:11 -0800 (PST) Date: Fri, 26 Nov 2021 11:06:09 -0500 From: Mark Johnston To: Andriy Gapon Cc: FreeBSD Current Subject: Re: ctfconvert: rc = 1 Unsupported version [_dwarf_info_load(229)] Message-ID: References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4J103Z2lJ5z3mDq X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Thu, Nov 25, 2021 at 10:48:36PM +0200, Andriy Gapon wrote: > > I've just finished builds of yesterday's CURRENT / main for arm and arm64. > In both builds I got lots of messages from ctfconvert: > ctfconvert: rc = 1 Unsupported version [_dwarf_info_load(229)] > > I got an impression that there was a message for each object file, that's how > many of them were there. > > I don't recall seeing those messages before. > > Should I be concerned? > Maybe I am doing something wrong or have an unusual configuration? > Any way to fix the issue? > > Thanks! > > P.S. > The builds were done on stable/13, so maybe there is an issue with host tools > not being able to grok something new. I haven't seen this before, for what it's worth. I presume this is from a kernel build? Does the configuration enable generation of debug info with, e.g., "makeoptions DEBUG=-g"? From nobody Fri Nov 26 16:12:49 2021 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 7233C18C1E42 for ; Fri, 26 Nov 2021 16:12:53 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J10C90kjFz3rLx; Fri, 26 Nov 2021 16:12:53 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from [192.168.0.88] (unknown [195.64.148.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: avg/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 98B0F27DB8; Fri, 26 Nov 2021 16:12:52 +0000 (UTC) (envelope-from avg@freebsd.org) Message-ID: Date: Fri, 26 Nov 2021 18:12:49 +0200 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Firefox/91.0 Thunderbird/91.3.0 From: Andriy Gapon Subject: Re: ctfconvert: rc = 1 Unsupported version [_dwarf_info_load(229)] Content-Language: en-US To: Mark Johnston Cc: FreeBSD Current References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1637943173; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Z7y5GYz90+mRLHhCyfpt7vUHmZV5cM8RaIrRGRMBM+8=; b=Ep45YwGD8tJPW+fi4NB+ZH/XYXwQ55UVL0GO2uvGhFn/KO2O5IOTfVSaglmdfk2WEAXodG uHYKBJtRvplRKgEJQ+DEpZ0TPbYjFj2dF82Q8pnjLQU/fo/7MPxlxc2cFYbeP2f3RhbVmT x4GPWo1yNFoDyD1tzqRRR/UhMgoAxFkgN1GKTqEL5L+Xs0+eifZ2LZJHhNAt+dcsYp7odG h3twv1tcy8Rh29gWvsTnruMsJcF5QgfvQp2C4aKfVGBwjamSiWDADsfPoW2oaMNaO5wbvM MnvOoy5n1342gD3WeyMKaWzR43muKvGuJnbFCTA2i8C0/Sf9dYlUd8kLS+hEBA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1637943173; a=rsa-sha256; cv=none; b=Zfh1XvqGKltmmsIV8erEsaRBL2bRtZ6m1amYso0DSAD4331orub3HUj9RbFY7mwby+2KWO QsUs/CfbusyxhHZc05LVa5NSOVQ8ldJ2JC2hIqUdgzKzAW7NdrSUlSJlk5r6ys8AfUQ1TQ wB2wvsVEiSfgKGD+WqUCW4tNblfeXvWavEMwetfIucB06U3fmyiM3Cx3PJtRgPWMd8OmaJ 6+P2vPDzUuF0L/OvhcOTGcyUUByHzHgvOIM2c5szt6nhMKzdxkPLNPYD9RyJ+ydoBud+ZW SMNeGuDdEXFgPuvTnYAyKktywwnwbvQQKdpYnyYUf4I0nQK2u63IxEhVYfpS6A== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 26/11/2021 18:06, Mark Johnston wrote: > On Thu, Nov 25, 2021 at 10:48:36PM +0200, Andriy Gapon wrote: >> >> I've just finished builds of yesterday's CURRENT / main for arm and arm64. >> In both builds I got lots of messages from ctfconvert: >> ctfconvert: rc = 1 Unsupported version [_dwarf_info_load(229)] >> >> I got an impression that there was a message for each object file, that's how >> many of them were there. >> >> I don't recall seeing those messages before. >> >> Should I be concerned? >> Maybe I am doing something wrong or have an unusual configuration? >> Any way to fix the issue? >> >> Thanks! >> >> P.S. >> The builds were done on stable/13, so maybe there is an issue with host tools >> not being able to grok something new. > > I haven't seen this before, for what it's worth. I presume this is from > a kernel build? Does the configuration enable generation of debug info > with, e.g., "makeoptions DEBUG=-g"? This is actually from buildworld. buildkernel is silent. I have WITH_CTF=yes in src.conf for both arm and arm64. For completeness, here are all other options in the src.conf (many of them are probably obsolete): WITHOUT_ACCT=yes WITHOUT_ACPI=yes WITHOUT_AMD=yes WITHOUT_APM=yes WITHOUT_ATM=yes WITHOUT_BLACKLIST=yes WITHOUT_BLACKLIST_SUPPORT=yes WITHOUT_BLUETOOTH=yes WITHOUT_BOOTPARAMD=yes WITHOUT_BOOTPD=yes WITHOUT_CCD=yes WITHOUT_CUSE=yes WITHOUT_CXGBETOOL=yes WITHOUT_EXAMPLES=yes WITHOUT_FINGER=yes WITHOUT_FLOPPY=yes WITHOUT_GOOGLETEST=yes WITHOUT_HAST=yes WITHOUT_HTML=yes WITHOUT_HYPERV=yes WITHOUT_IPFILTER=yes WITHOUT_KERBEROS=yes WITHOUT_KERBEROS_SUPPORT=yes WITHOUT_LOADER_GELI=yes WITHOUT_LPR=yes WITHOUT_MLX5TOOL=yes WITHOUT_NDIS=yes WITHOUT_PROFILE=yes WITHOUT_RBOOTD=yes WITHOUT_ROUTED=yes WITHOUT_SHAREDOCS=yes WITHOUT_TALK=yes WITHOUT_TESTS=yes WITHOUT_TESTS_SUPPORT=yes WITHOUT_USB_GADGET_EXAMPLES=yes WITHOUT_ZONEINFO=yes # comes from the misc/zoneinfo port -- Andriy Gapon From nobody Fri Nov 26 19:00:27 2021 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E8C4118B1AE4 for ; Fri, 26 Nov 2021 19:00:31 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J13wb64hKz4WFx; Fri, 26 Nov 2021 19:00:31 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-io1-xd2d.google.com with SMTP id b187so1415355iof.11; Fri, 26 Nov 2021 11:00:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=uLbOjhUxGn3jU7ZzT0JWc+8f8VArUGUEaaDgAFzVJ/k=; b=SxvJLHZ+ovQbYzgYcyfrco9AabISLBIXU3J4OXSAJh5e6gkRVShnyi9ruI9mufmAo4 hWKIRGcL0ccvGD215QuMvfG/eUd4XNjAAl5vk8GtGUWHDeK9nDMQXN9/JucggXwzDrjS nss4O9EfeTe+L4KTiGexX/yD8y+JQhB5FPH5Lp3TlUEgahP+ZkP061qZxFlrdxq2y03D q/+wTD4JcJK+zAXinmqzr0VBQAgeaXfpEV+l9EQRwziO8vqW2xTKU4rYycJrDwsFGjl+ neYBX0FxS/xjHLL79O3RcluLf0ArXN6+LgbXPNv/+9IHyqDZ9vmSokMqCHbJSm6hK7zk 3bsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=uLbOjhUxGn3jU7ZzT0JWc+8f8VArUGUEaaDgAFzVJ/k=; b=IFJAJBcdiwxxQJ/C2aYN3Z86bIrUgXTFRkTE9C4ypyVbVuYKTsPBCBcVyipN55MT64 NGFvNuv7IhO7/k2WJBsrVT2TE8TTx9qQrS6CPMSIXzKT56yRmLCO3J5ULFSqePqnCaUE zOahvRcONWVIrP8LX8ygY5yFvBP7o37RmGyVoJ3BAIdkxeg/mIDpGTu0YAEIsIuX8SqC MQ8GYOLPDFo+Ya8KGyNPtPYxiQYxUdAiYpmLM4OrVEgTMbo/YSMxEDG7EnAJQaDy3Zan jIg16zScEdwd3nQpPUnAqd8L6qaS2XMOh4BHKXd9yfJeRZUNiivx33PyqwVcC5AATkjC GpQw== X-Gm-Message-State: AOAM5317VGNaE2o48m/U+L2m+n4i84I6MZx5yoygf7m0hXbnFsKuvuFn qjUkczNO4TCqFiSm+0idM8gSgBpcHa4= X-Google-Smtp-Source: ABdhPJz9YIHotZv7O4rF8okRdj/L5t2MxWZyCON+2p3XLmBdHKcow093epR1VyuC7rMFfnTA1GlTjA== X-Received: by 2002:a05:6638:2054:: with SMTP id t20mr47298792jaj.42.1637953230353; Fri, 26 Nov 2021 11:00:30 -0800 (PST) Received: from nuc ([142.126.186.191]) by smtp.gmail.com with ESMTPSA id o10sm3506571ioa.26.2021.11.26.11.00.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 26 Nov 2021 11:00:29 -0800 (PST) Date: Fri, 26 Nov 2021 14:00:27 -0500 From: Mark Johnston To: Andriy Gapon Cc: FreeBSD Current Subject: Re: ctfconvert: rc = 1 Unsupported version [_dwarf_info_load(229)] Message-ID: References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4J13wb64hKz4WFx X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Fri, Nov 26, 2021 at 06:12:49PM +0200, Andriy Gapon wrote: > On 26/11/2021 18:06, Mark Johnston wrote: > > On Thu, Nov 25, 2021 at 10:48:36PM +0200, Andriy Gapon wrote: > >> > >> I've just finished builds of yesterday's CURRENT / main for arm and arm64. > >> In both builds I got lots of messages from ctfconvert: > >> ctfconvert: rc = 1 Unsupported version [_dwarf_info_load(229)] > >> > >> I got an impression that there was a message for each object file, that's how > >> many of them were there. > >> > >> I don't recall seeing those messages before. > >> > >> Should I be concerned? > >> Maybe I am doing something wrong or have an unusual configuration? > >> Any way to fix the issue? > >> > >> Thanks! > >> > >> P.S. > >> The builds were done on stable/13, so maybe there is an issue with host tools > >> not being able to grok something new. > > > > I haven't seen this before, for what it's worth. I presume this is from > > a kernel build? Does the configuration enable generation of debug info > > with, e.g., "makeoptions DEBUG=-g"? > > This is actually from buildworld. > buildkernel is silent. Thanks, I can reproduce it now. Our libdwarf is complaining that the first compilation unit header in .debug_info contains an unsupported DWARF version number (libdwarf only supports 2, 3 and 4). In files compiled by clang it ends up being zero. For instance, compiling bin/cat and dumping the .debug_info section: gcc10: c1250000 04000000 00000801 00000000 ^ DWARF version clang: 01000000 00000000 4e230000 00000000 llvm-dwarfdump and binutils readelf are somehow still able to find a valid-looking unit header, but I haven't yet been able to figure out how they do that from reading the DWARF 4/5 specs or the LLVM sources. From nobody Fri Nov 26 19:24:06 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id DA94318BD91F for ; Fri, 26 Nov 2021 19:24:39 +0000 (UTC) (envelope-from yasu@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J14SR3JDkz4hd5; Fri, 26 Nov 2021 19:24:39 +0000 (UTC) (envelope-from yasu@FreeBSD.org) Received: from localhost (gate.home.utahime.org [183.180.29.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: yasu/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 8EE6728DD0; Fri, 26 Nov 2021 19:24:38 +0000 (UTC) (envelope-from yasu@FreeBSD.org) Date: Sat, 27 Nov 2021 04:24:06 +0900 (JST) Message-Id: <20211127.042406.778157072317505227.yasu@FreeBSD.org> To: freebsd-current@freebsd.org Subject: Kernel panic by executing `poudriere bulk` From: Yasuhiro Kimura X-Mailer: Mew version 6.8 on Emacs 29.0.50 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1637954679; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=/P3PIjEXUMb29YZde63vnQ4ycCUJuNXTG1SMvvxdqjY=; b=mSBSU6EW2IM1/8xzYaOoCGYwxTaG7l/I1/2HnjOkBsYBtYpWM38c9UbcNL2pm5lxdpN4IE v9acrWfC/TIVuNV19w2jeBbdais7YVdb+YcHp7HFAUIHaIqi46dtkO5zS/qcV1/taYbiUu rgT8O5dabPQW5SGpMgygxsOlk3dcdbtS8Rlm9wBpbHCb9td6OlopLfnGEfrhdfej3THy4F tqhHX4rMdQJER6jHLsqjFIbp/EEJSSo7K9XFp8kCIaGkdPi+WijzyamKZqn+8vWiW3mTfd /tk+bM6z/OhEFVl8QyJDUOUyEoQorQvDwBH0fZ38nd/iElteYkotoKI0iHdwGg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1637954679; a=rsa-sha256; cv=none; b=EBUZuynlecrdHtnYB/LoCinT+pQ7Ej9efVD96TWNAF4nYq63bpajLZAGHXtOKIwDBOF0/i cmxqowUlaPs4voEkbJs82Z4xiwU/EF+kcpzl5BNNVOEA+tvwBhvWaBF9vEhKZbInX9TZ5u dkU8OJzLUyuRvsjxXu258dv3IQeZNBBwNbam6Y+vHgMmzcWcgSYtEzRvNM2gEeCix4KZz4 VpOnhE87cihUBBXGVvqCL7jKB28aIUk1W+fhPt7x+KMwIEIBdaHJ8gV2fKdqsmSmvtllMW txdVMrkadhszsylgmZ0LtLWimnbDZxIfYiPDfNFnZr5gsPCmV+BCaMDvZEerzQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N yasu@rolling-vm-freebsd1[1015]% uname -a ~ FreeBSD rolling-vm-freebsd1.home.utahime.org 14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-n251115-ae92ace05fd: Sat Nov 27 01:47:15 JST 2021 rootz@rolling-vm-freebsd1.home.utahime.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 yasu@rolling-vm-freebsd1[1016]% After regular weekly update of my 14-current amd64 system, kernel panic happens when I execute `poudriere bulk`. Snapshot of console: https://www.utahime.org/FreeBSD/FreeBSD-14-CURRENT-amd64-main-n251115-ae92ace05fd.panic.png --- Yasuhiro Kimura From nobody Fri Nov 26 19:33:22 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9A46818C31E1 for ; Fri, 26 Nov 2021 19:33:29 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-oi1-x22a.google.com (mail-oi1-x22a.google.com [IPv6:2607:f8b0:4864:20::22a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J14fd3Swzz4mfW; Fri, 26 Nov 2021 19:33:29 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-oi1-x22a.google.com with SMTP id bf8so20594757oib.6; Fri, 26 Nov 2021 11:33:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/0o2qCu9RS/ge3TeqGj9LIbM9UOix1dnd/qcOzsK97c=; b=DNy47qCcRAaJRLt0X9jzz0CGyq8HABshmmWe1DrjU0lVmP9bKUomB2dLtLCQ8ShGi2 vam2hl6BAI3lH9WdO3Ti+5rwlunR5ApqdupLwYSdTtXSfVVuMSi2md/dQjbX42qSnp/W 2yV8xIvmlOtHOV5YunQqP+R2nRcGVS7Nc2RlTFDjx87cVA3jNBX8/0LlLNySyvYoq/Lr XxNCuEKFtlN3RDcey0NqkDkQZK4aIun8a+1fB1L/UEfk7pNavlic/7iNBDLekLmCu1zl bUZFtctRo6uNskR3pg6/X2w12uVZRub5ckwlRHaRYZB9AWk3sSAONS7c0Y9AkOQsevQG eO+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/0o2qCu9RS/ge3TeqGj9LIbM9UOix1dnd/qcOzsK97c=; b=M5G3FKv8dUQd338JHmQ9g8f2sZdqcnEsJwCNxMDcBeG5z1/OI65Cn5OtZMHn3SQyZi SGG9m36dq8i2GExFJn2BIjjks8iSzR/su91sc5TyghMIj1oH7mM2h1tBjN5j0OTyBjrs fP/Ho1ajZusZnQQ0exG55QQpTqDl5d1s4W3GYFQ9VXiTbvF9CNFJTJqjZK1KaWNT7U8O uJEfwUHqpQmBNlOfkMZl+wD40wnsUbiag9kwFfeUAL5JE48wYv/3/AuuHi2UiSgo+YJd JHwLKf+I5Iqeofd5t7ZH4uIM9+cskEDoanLuFRq9IJoIl7I+OBmPBE3+mq9VPmzKl1WG wOOQ== X-Gm-Message-State: AOAM533qZd7jtK7iM5A0vezmswODSgw+S6p5LwnX6EEoKqR79lZTb95t Af53UQR8w6DxPvuK5A5rSnV+D4E4ArquHkZwSGxM8TmR X-Google-Smtp-Source: ABdhPJxh1Hl/a7LlEQ0QoxxbtFxwefyIoHuM6hNCCcsFtCx+XcOsjr2sQUSsFJ7/Xk8BTXemtHApUI/0fQmzed8fEL8= X-Received: by 2002:a05:6808:10d0:: with SMTP id s16mr25876446ois.0.1637955203592; Fri, 26 Nov 2021 11:33:23 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Received: by 2002:ac9:126d:0:b0:3b4:5824:6a18 with HTTP; Fri, 26 Nov 2021 11:33:22 -0800 (PST) In-Reply-To: <20211127.042406.778157072317505227.yasu@FreeBSD.org> References: <20211127.042406.778157072317505227.yasu@FreeBSD.org> From: Mateusz Guzik Date: Fri, 26 Nov 2021 20:33:22 +0100 Message-ID: Subject: Re: Kernel panic by executing `poudriere bulk` To: Yasuhiro Kimura Cc: freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4J14fd3Swzz4mfW X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On 11/26/21, Yasuhiro Kimura wrote: > yasu@rolling-vm-freebsd1[1015]% uname -a > ~ > FreeBSD rolling-vm-freebsd1.home.utahime.org 14.0-CURRENT FreeBSD > 14.0-CURRENT #0 main-n251115-ae92ace05fd: Sat Nov 27 01:47:15 JST 2021 > rootz@rolling-vm-freebsd1.home.utahime.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC > amd64 > yasu@rolling-vm-freebsd1[1016]% > > After regular weekly update of my 14-current amd64 system, kernel > panic happens when I execute `poudriere bulk`. > > Snapshot of console: > https://www.utahime.org/FreeBSD/FreeBSD-14-CURRENT-amd64-main-n251115-ae92ace05fd.panic.png > Should be fixed by https://cgit.freebsd.org/src/commit?id=1879021942f56c8b264f4aeb1966b3733908ef62 -- Mateusz Guzik From nobody Fri Nov 26 19:48:03 2021 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9C34318A3F0B for ; Fri, 26 Nov 2021 19:48:13 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J14zc5t3bz4v7L; Fri, 26 Nov 2021 19:48:12 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-il1-x132.google.com with SMTP id w4so10061413ilv.12; Fri, 26 Nov 2021 11:48:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=jUdaTo6D8UzHy5v6DB6KHv5mjmi53f/sEgDMmTEf/i4=; b=Qltm1KcSdhbY++XpSDQxKasv8ho64hzRRxaSAIlKu3TGJkxN/k7j5G6CKb4Y3BtwM0 Bo9fLxfrKzySgf8TWzmjhzC19bQJBj6StVWZ1dAm85zpOrt5/VuXbXzVSsATWltOis5n FtdJuS7XneXsyb4PyKQkjKzmc5de8aLz5wlQUP+vi8jM9vq5f0a42jC7cdbLK7Ywbwxm zaApoxWw8Y50It9DN8KjE9bc/g3U4iGV9Jeoc3Ek8G/p6Hv+ogYsLXZEGoSO9G6l3/5D 0uEgXdk8/616H2HBTnDd5+Ze+dFrtkriNXGfkuPYwcuBRSmRT+OifcOdpc5ja0wRNhfZ WWZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=jUdaTo6D8UzHy5v6DB6KHv5mjmi53f/sEgDMmTEf/i4=; b=iV2TfyYc7LP4CS9Ln6qRS5FoqMPRWSxcZBbXciXlqwX3Fc7bCyWTv/jHWFNYVJVIZX FkW4Jqp9bcT1Qgx5tD6MOWGv9rJbA9RJS8kFygxJNkHJXqob33x+8U2kubogVyCUg1/F Z9D9VnxLpfFJMv4gpqSm4wa1bs4ZSQLMPsciY9Ke92EIlHWZlmVf/wHPvmPrypd9ZX+/ M6/M28RhozptnBWex0uxc10IcDL1/ks/33IvE9vRSUMjewc922ZTo4naSIQNq8imr09t 3YIMPH8gn2gwc4HMdpNNu7QSd0yGSPp4JhnmwNCuhVm/hapi3dbuvcip7HJCx8440FM/ QuYA== X-Gm-Message-State: AOAM532rN0H5KPkWyG8zcT8andVIX8PmbbRuYYKkBlo5QPnnR3Eg77mD BmPtploZxhU0+m/S5Yi5lZ6NuMKAWnM= X-Google-Smtp-Source: ABdhPJyzqwhmBKu5IIVLBcmUmndUsYRpHHcFg6qnHlAnHUwR2T9HNBeyB38OL9fkCH9hfu2xWDhCIQ== X-Received: by 2002:a92:d2cc:: with SMTP id w12mr32806059ilg.111.1637956086038; Fri, 26 Nov 2021 11:48:06 -0800 (PST) Received: from nuc ([142.126.186.191]) by smtp.gmail.com with ESMTPSA id o14sm3576076ioo.36.2021.11.26.11.48.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 26 Nov 2021 11:48:05 -0800 (PST) Date: Fri, 26 Nov 2021 14:48:03 -0500 From: Mark Johnston To: Andriy Gapon Cc: FreeBSD Current Subject: Re: ctfconvert: rc = 1 Unsupported version [_dwarf_info_load(229)] Message-ID: References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4J14zc5t3bz4v7L X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=Qltm1KcS; dmarc=none; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::132 as permitted sender) smtp.mailfrom=markjdb@gmail.com X-Spamd-Result: default: False [1.30 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_NA(0.00)[freebsd.org]; NEURAL_SPAM_SHORT(1.00)[0.998]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::132:from]; NEURAL_SPAM_LONG(1.00)[1.000]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N On Fri, Nov 26, 2021 at 02:00:27PM -0500, Mark Johnston wrote: > On Fri, Nov 26, 2021 at 06:12:49PM +0200, Andriy Gapon wrote: > > On 26/11/2021 18:06, Mark Johnston wrote: > > > On Thu, Nov 25, 2021 at 10:48:36PM +0200, Andriy Gapon wrote: > > >> > > >> I've just finished builds of yesterday's CURRENT / main for arm and arm64. > > >> In both builds I got lots of messages from ctfconvert: > > >> ctfconvert: rc = 1 Unsupported version [_dwarf_info_load(229)] > > >> > > >> I got an impression that there was a message for each object file, that's how > > >> many of them were there. > > >> > > >> I don't recall seeing those messages before. > > >> > > >> Should I be concerned? > > >> Maybe I am doing something wrong or have an unusual configuration? > > >> Any way to fix the issue? > > >> > > >> Thanks! > > >> > > >> P.S. > > >> The builds were done on stable/13, so maybe there is an issue with host tools > > >> not being able to grok something new. > > > > > > I haven't seen this before, for what it's worth. I presume this is from > > > a kernel build? Does the configuration enable generation of debug info > > > with, e.g., "makeoptions DEBUG=-g"? > > > > This is actually from buildworld. > > buildkernel is silent. > > Thanks, I can reproduce it now. > > Our libdwarf is complaining that the first compilation unit header in > .debug_info contains an unsupported DWARF version number (libdwarf only > supports 2, 3 and 4). In files compiled by clang it ends up being zero. > For instance, compiling bin/cat and dumping the .debug_info section: > > gcc10: > c1250000 04000000 00000801 00000000 > ^ DWARF version > clang: > 01000000 00000000 4e230000 00000000 > > llvm-dwarfdump and binutils readelf are somehow still able to find a > valid-looking unit header, but I haven't yet been able to figure out how > they do that from reading the DWARF 4/5 specs or the LLVM sources. Ah, we recently started configuring clang to compress debug sections by default, and our libdwarf doesn't know how to handle that. As an interim workaround this could simply be disabled with WITH_CTF is configured: diff --git a/share/mk/bsd.lib.mk b/share/mk/bsd.lib.mk index 10262e6bb80c..5a5be3494471 100644 --- a/share/mk/bsd.lib.mk +++ b/share/mk/bsd.lib.mk @@ -113,7 +113,7 @@ CXXFLAGS+= -ftrivial-auto-var-init=pattern .if ${MK_DEBUG_FILES} != "no" && empty(DEBUG_FLAGS:M-g) && \ empty(DEBUG_FLAGS:M-gdwarf*) -.if !${COMPILER_FEATURES:Mcompressed-debug} +.if !${COMPILER_FEATURES:Mcompressed-debug} || ${MK_CTF} == "yes" CFLAGS+= ${DEBUG_FILES_CFLAGS:N-gz*} CXXFLAGS+= ${DEBUG_FILES_CFLAGS:N-gz*} .else diff --git a/share/mk/bsd.prog.mk b/share/mk/bsd.prog.mk index 437ccf373130..21597128f991 100644 --- a/share/mk/bsd.prog.mk +++ b/share/mk/bsd.prog.mk @@ -93,7 +93,7 @@ CFLAGS+=${CRUNCH_CFLAGS} .else .if ${MK_DEBUG_FILES} != "no" && empty(DEBUG_FLAGS:M-g) && \ empty(DEBUG_FLAGS:M-gdwarf-*) -.if !${COMPILER_FEATURES:Mcompressed-debug} +.if !${COMPILER_FEATURES:Mcompressed-debug} || ${MK_CTF} == "yes" CFLAGS+= ${DEBUG_FILES_CFLAGS:N-gz*} .else CFLAGS+= ${DEBUG_FILES_CFLAGS} From nobody Fri Nov 26 19:51:13 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 118DC18A4C7B for ; Fri, 26 Nov 2021 19:51:41 +0000 (UTC) (envelope-from yasu@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J153c5g22z3C2W; Fri, 26 Nov 2021 19:51:40 +0000 (UTC) (envelope-from yasu@FreeBSD.org) Received: from localhost (gate.home.utahime.org [183.180.29.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: yasu/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 55F8429459; Fri, 26 Nov 2021 19:51:37 +0000 (UTC) (envelope-from yasu@FreeBSD.org) Date: Sat, 27 Nov 2021 04:51:13 +0900 (JST) Message-Id: <20211127.045113.579848018915149475.yasu@FreeBSD.org> To: mjguzik@gmail.com Cc: freebsd-current@freebsd.org Subject: Re: Kernel panic by executing `poudriere bulk` From: Yasuhiro Kimura In-Reply-To: References: <20211127.042406.778157072317505227.yasu@FreeBSD.org> X-Mailer: Mew version 6.8 on Emacs 29.0.50 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1637956300; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=e+5Jr0MjYQqxURjOSF7JjK2MiRjmsY2D76XgtbSYxR4=; b=M0DP3NPf6jPAekC/q7M8gSge30d96wN+gyehcMH1X+6U+zeXyJOT3LYvAXlFmHrM192faq 7REZNAWFsIv1I/FDPLGSxEh2iLGLuxWp6UkHTlMcK3YlCLRBkR8Bmpm/7Um3Aflde6Iibl Ri+JR1Sp1o+kLlKmDLOOukyC8LHg+AR8lqWMFVABMm3lX66Q5q7L5DVLvN3NhOeA+AdvKU DLzL5Lnn212wlwMaLETdBEds7J8w8LGeWTCDBqCsODHBlhcrXQVr+cMMWGBNBEMgR5HQC3 C+Pbz1emkrMOMS8Kjm+t/p2sS4a5xR7eGy2tyz66l1cso3D+MG83WTObDJsu7w== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1637956300; a=rsa-sha256; cv=none; b=YxQiuzwwYVXIxm/rgHDanZm1ic4vHopNva6iB9YaEQSXUhEmAk04lKDGodVAhFCuhBc0lt FyKCDiwHkBFu/aD9tJVPNuItmyf+9kRGXnTUXe8y77Ek79VfvndSBSSRSbfj2fGlcdOBlw RsTXFfH2g4+Ek7+02AteoyoGCQgsKjz7fKzd+xTMbeYobF2CiVfsCbxIsAqMDW6gCPMppl 89OzQBZQ3j4cvXKdviDQvS+D2vTrTDlkWBdm2dcoYFm+LcnUsY0iDQqG6vxsBN+YXb3bef 9QaMCLJjAakMLLxey55IoPgVWkzcxBSRU6+n1TppEw7tRt5vGiZ+inbQzNXhyA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N From: Mateusz Guzik Subject: Re: Kernel panic by executing `poudriere bulk` Date: Fri, 26 Nov 2021 20:33:22 +0100 > On 11/26/21, Yasuhiro Kimura wrote: >> yasu@rolling-vm-freebsd1[1015]% uname -a >> ~ >> FreeBSD rolling-vm-freebsd1.home.utahime.org 14.0-CURRENT FreeBSD >> 14.0-CURRENT #0 main-n251115-ae92ace05fd: Sat Nov 27 01:47:15 JST 2021 >> rootz@rolling-vm-freebsd1.home.utahime.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC >> amd64 >> yasu@rolling-vm-freebsd1[1016]% >> >> After regular weekly update of my 14-current amd64 system, kernel >> panic happens when I execute `poudriere bulk`. >> >> Snapshot of console: >> https://www.utahime.org/FreeBSD/FreeBSD-14-CURRENT-amd64-main-n251115-ae92ace05fd.panic.png >> > > Should be fixed by > https://cgit.freebsd.org/src/commit?id=1879021942f56c8b264f4aeb1966b3733908ef62 Confirmed. Thanks for quick fix! --- Yasuhiro Kimura From nobody Fri Nov 26 19:55:54 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 287B118A877E for ; Fri, 26 Nov 2021 19:56:07 +0000 (UTC) (envelope-from scoobi_doo@yahoo.com) Received: from sonic311-24.consmr.mail.ne1.yahoo.com (sonic311-24.consmr.mail.ne1.yahoo.com [66.163.188.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4J158j4wjVz3FY8 for ; Fri, 26 Nov 2021 19:56:05 +0000 (UTC) (envelope-from scoobi_doo@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637956559; bh=KyXgHqh2kYFmp1ZCThxVw9STf7su+FZM9bYT2IQjcSc=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject:Reply-To; b=U1lfEV7DJCie8nMiT4eG67nwpL2i0dd++cZhJ7nj+cbzKonCpzoLCagJXNIqKIdU01hx4AYJYiPrnzRp1N77CYUyUhDdzeNjvgLaIlYNz/gvaFVkCLVAq0QFK/B0BXy58ZvwJnBrkR6t8rJ21zVNh9FyU1uou/zsNPig1S8vys5AxIzTN/gHalb+GpiT7byAC+rJYS6wvVwV6wzazye2Lbo1QoBuJepp5Ykzz9kYFaNQ9XjJboBnIAs9Nb9s1gVe/e+D4Lffibw2FYJHwxEHxfrZ8XhkwdV4+RVjG5+FJAPkOIDXq1SWAfsg05gqu8++M2BXqvTpjEehuk33QNq/kg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1637956559; bh=hwAoUOSTYAJThCPYYS+2ENQKMpEPXfdk69eoGxIVAfa=; h=X-Sonic-MF:Subject:To:From:Date:From:Subject; b=sSbj+tchfBDiz30lxvD0rWJc6gxk3H68SXiru40Yifo1yKwZBcF6hrahzquF2w6GlOWz3/E+8ubVaEQoZOKfLpA1u34lcCxscWz05WlSJr+DYX5v3MVWmaroLAmf932nWT4MxmK5ckpIDp99o1bQ6xh5Nd9PxjLKhO64pDM7V99qhu8+2RWPle0XM7mAsfZ2nZXpKlUizeeyoke1XBA22izavKCd55A/yzZocnpqmA5TZ2KwfEUYCr5R4KVBK52CqHKZr3AxJ6QS0HlP5Yr39yW28HgAzFSc9hGKPEFumG823J0goTJ5H3Eoxc6vd+DtnCkDB2XARrnFE6O6PAB4IA== X-YMail-OSG: mrBfWxcVM1khzb6lsX4WPelf5g_62IdAWbBmXmcznP90msxMPPoovoq8mB_3pUU soQu1PR7Kpm4PZC9l5TQ6BROMwyled7CNUV3VyLUFasfZpKaLFJxITGnGpzCmd92xQAYp.MRW2GY olWIYzYHs9_VOTlPFN4T_7HDI1cU7VMRd8oho81idQekSdwr5LsMf1VPDbWa0bq64npOuuVcynmM AQ_Qr46ULmAY2E8Y8lbiHuajC0lPezM750dNy9AeiEq__A4d91_Ow6FDgQRdUIwTy42PcgjtVhtK 7EblXvJQtZ6YPzUDyVbQqM1bJRSEU3YMcS9ZnNATrPyG.1OofLsLk.j8fHLa0EWugIHik6AWURu2 vUbsZyTBJS9vuvVvivnlD1YwwrT4MhehDdFGWrwHnxxMrCfBiv.29Bs5Y3GbfzATcqGmAWZHGUt. SET3SVnjJXQo3.6NBXSrVgZYpbyKvxYNxEbqg7bo3LoD6YM3tTV6uukyLQvPXmF._JtmvyucfqX9 0QrDB5Snx6VyqPQgeIT49oK8jZa5e01goa5guHoHX6yX2aMb1vRRn.qz5pvgJXlRxXoB.sMBSCgd jnvQt9rg2u4dEWwSLGJUz2mK60frd87U3eEjuyBF3f3IcCW4BQb4nrQ4Pr69s1slc5TYV2PiNqSm YwqnWwwMZ8xlvD70Nk3dfCf8c6d6f3cTMKRlNUcYa3HezPhw11jC.iHzEe3LAqHq0wQqKiogPmY6 l8TfztJ6f6nfQH7FBBF6KcVb48JfbSc_5uLmBzHqXW9HZLv78Kl.4aKV9gKYw_667yb9uhXZn0TW W6zYor.v2oWHc43eFc9bYbkd7PcnvnDruCPPxOrsapA3OK1zY.aQMkBWIm.tV8rtjxlWnrmtPi3l zkAr8R4vr4f8jmWtB.gpH3xmKmH8twpoTSNEYnJjrf7EYXqqz_Y.ZCFj21cDtXzmMNZ0St184DGs d6TCK1SFtoHaq2Lv2rDQcEpm6o20O9QTKUYQmcsW.gUvswa6b.XaRoPEFbDYWznh9xpUnGhUKLuK z9br38bSJgdZflNeMfw4rjDAAMb3XW.i1u7PKULNVuSNiAx3_M9aSpTBOpTiVABJLFK.jbYlJoob eSyB.KpKQTmPeeODKlzRgZU5xHgFP353FJ0kobjzaLTZvAuUJo8qNzOBr89.PFAhzT.7BV2lmCvM 0NwQxU36_9zuBAi73E3qOQuvUE8kmOiXQtws4ZyD1sJgBVTkBsu6lSit2jPCo0Izwq4uykuRM3mJ HJzYaInP2NjKkfE7eG_fIeHAZxSO2JvMB5XaP_UWj7SN6bbEB5MUAe8cZ00m3sjTLhlqjZAywTas NFygyUN8UvpJwDwcVdkBEZZ2q81_vfwdrZNvLaVTuaD2eRV9jFhG7q9Q.GlKOGgQ.I2_oHm3TJSJ 3C6cE5zF2f3Eke_grIRdFEmSO2owtxSpJo8nkOjYHpZquoCmt.jtpXP1gthDswqUupHN_RzMm8G8 74zC5V3T67N0YzONImXkuUGqNkW8l34iQBFKaR0ic1O7TDBDovs8SQM5mRB006zvcQKL3yNFAc.0 rSa7IHnGo_9j1VBrm2NU0b5btk4Vmt6ec9n8meIzBKsXfPMlU4CkoboT.aCaxb3o_KO.Jf0.WCCN 1GbLms.L9Ib.IgNjo968HZ_TXUjrGl.O15yY9BV0zfsJigdAV.NERyAPTL8I4gaHglTnSedDw.rk LvKQy540b7bcCnN0cmIoAwAS0NfC6vB5kqQj8xXRHdMLZtbGB1VLbU9rmBkzoSruS00iDfNENShc uOlU3G_RB292MsECDySTuPk5bN9.eUO94PUtgHvB_PkBb9qIJJ8IbBaxEWr_KhOTqaGiMj58EIzz nDquVQM2MogURyzwB5_XWHR5qZF.9D2YM83xQIJtbt4gBhYWpayP9mMZR4xFzY0keVYEv9X3XBIf b2fG0.7OxGHzyZ4BKk.zPPONcrtlieMySPaYIrikOJmUAJQ7x7WFLh.W.HkHOdblcg_3UYfoC3xC YfJkt3QivekD6s_bWZ6o3manpNuoMOp2OEFkkEoclXeb1ykpAVEimv4vI3w0ltxdEFJndei.uGrA DrxyP4yrqu9yZRgBPrRmtLdeCUmnPQVBBS4gCFjGAadHvvxpAemQoP698u2fBS7WlSDihAyVNo10 AE22y0mGvdAgmkrDSw0h09g1r6Za579DlFqIuJvQTWq8VqFjhWcnLgSnFANkDM_eAhOwfG4J5Lm2 .JAaJItQmAJq_9jGeVtqezO2P06.gTP8xHgIJzCfNBP3C6jLaEwsKd97T17tFLsHlYO6y2w5a_05 xKU5yxL3BPISaBfBadAZMd7bXSibuY0kSWqCxeOxaHZZKyBvCqB7mBekafXSMZGE7USm_tTGkfKd KpTwt X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.ne1.yahoo.com with HTTP; Fri, 26 Nov 2021 19:55:59 +0000 Received: by kubenode514.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 79fd13f65fb16eb527c3a7ed11e102af; Fri, 26 Nov 2021 19:55:56 +0000 (UTC) Subject: Re: problem with re(4) interface To: Warner Losh , Chuck Tuffli Cc: Chris , FreeBSD-Current References: Message-ID: <97ac9123-48fc-68f8-16cb-ebfdd96037ac@yahoo.com> Date: Fri, 26 Nov 2021 14:55:54 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Mailer: WebService/1.1.19306 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo X-Rspamd-Queue-Id: 4J158j4wjVz3FY8 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=U1lfEV7D; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of scoobi_doo@yahoo.com designates 66.163.188.205 as permitted sender) smtp.mailfrom=scoobi_doo@yahoo.com X-Spamd-Result: default: False [-1.53 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; RWL_MAILSPIKE_POSSIBLE(0.00)[66.163.188.205:from]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; FREEMAIL_FROM(0.00)[yahoo.com]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCVD_IN_DNSWL_NONE(0.00)[66.163.188.205:from]; NEURAL_HAM_SHORT(-0.53)[-0.534]; NEURAL_SPAM_LONG(1.00)[1.000]; FREEMAIL_TO(0.00)[bsdimp.com,gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36646, ipnet:66.163.184.0/21, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] Reply-To: Scoobi_doo@yahoo.com From: Anthony Jenkins via freebsd-current X-Original-From: Anthony Jenkins X-ThisMailContainsUnwantedMimeParts: N On 11/22/21 12:55 PM, Warner Losh wrote: > On Mon, Nov 22, 2021 at 10:51 AM Chuck Tuffli wrote: > >> On Mon, Nov 22, 2021 at 9:34 AM Chris wrote: >>> On 2021-11-22 08:47, Chuck Tuffli wrote: >>>> Running on a recent-ish -current >>>> # uname -a >>>> FreeBSD stargate.tuffli.net 14.0-CURRENT FreeBSD 14.0-CURRENT >>>> main-81b22a9892 GENERIC amd64 >>>> >>>> I'm having trouble using the second NIC interface in a bridge to >> provide >>>> network connectivity to bhyve VMs and need some help figuring out what >> is >>>> wrong. >> ... >>> Because there's subtle differences between them; are you using the re >> driver >>> from base, or from ports? >> The driver is from base. Didn't realize there was one in ports. >> > The ports driver is tricky... It's an older, buggier version of the base > driver... *BUT* > a number of issues that aren't fixed in base are fixed in it (mostly > dealing better with > errata)... Ideally, we'd pull in the actual fixes from this driver, but > it's a huge patch-set > where it's unclear which bits are for what thing fixed, so nobody (that I > know of) has > gone through and even come up with an ugly patch for -current. > > Warner > I use the Realtek BSD driver; it supports one of their newer 2.5GbE Ethernet chips on my motherboard. Aug 22 19:37:29 vickie kernel: re1: port 0xc000-0xc0ff mem 0xfc200000-0xfc20ffff,0xfc210000-0xfc213fff at device 0.0 on pci7 Aug 22 19:37:29 vickie kernel: re1: Using Memory Mapping! Aug 22 19:37:29 vickie kernel: re1: attempting to allocate 1 MSI-X vectors (32 supported) Aug 22 19:37:29 vickie kernel: msi: routing MSI-X IRQ 84 to local APIC 2 vector 51 Aug 22 19:37:29 vickie kernel: re1: using IRQ 84 for MSI-X Aug 22 19:37:29 vickie kernel: re1: Using 1 MSI-X message Aug 22 19:37:29 vickie kernel: re1: version:1.96.04 Aug 22 19:37:29 vickie kernel: re1: Ethernet address: 2c:f0:5d:**:**:** Aug 22 19:37:29 vickie kernel: Aug 22 19:37:29 vickie kernel: This product is covered by one or more of the following patents: Aug 22 19:37:29 vickie kernel: US6,570,884, US6,115,776, and US6,327,625. Aug 22 19:37:29 vickie kernel: re1: bpf attached Aug 22 19:37:29 vickie kernel: re1: Ethernet address: 2c:f0:5d:**:**:** The stock re(4) driver doesn't detect it. The Realtek driver sources are here https://www.realtek.com/en/component/zoo/category/network-interface-controllers-10-100-1000m-gigabit-ethernet-pci-express-software but they're for FreeBSD 7.x and 8.0; I had to patch the driver for my 14.0-CURRENT  box (panic on an mtx_lock(9) call; adding flag MTX_RECURSE to the mtx_init(9) call "fixes" it). diff --git a/if_rereg.h b/if_rereg.h index 18592a7..4885063 100755 --- a/if_rereg.h +++ b/if_rereg.h @@ -1016,7 +1016,7 @@ enum bits {  #define RE_LOCK(_sc)           mtx_lock(&(_sc)->mtx)  #define RE_UNLOCK(_sc)         mtx_unlock(&(_sc)->mtx) -#define RE_LOCK_INIT(_sc,_name) mtx_init(&(_sc)->mtx,_name,MTX_NETWORK_LOCK,MTX_DEF) +#define RE_LOCK_INIT(_sc,_name) mtx_init(&(_sc)->mtx,_name,MTX_NETWORK_LOCK,MTX_DEF | MTX_RECURSE)  #define RE_LOCK_DESTROY(_sc)   mtx_destroy(&(_sc)->mtx)  #define RE_LOCK_ASSERT(_sc) mtx_assert(&(_sc)->mtx,MA_OWNED) Maybe I can try making this into a port - oh great, someone beat me to it! https://www.freshports.org/net/realtek-re-kmod Looks like they "properly" fix the locking isue - https://bugs.freebsd.org/bugzilla/attachment.cgi?id=225980&action=diff Anthony From nobody Fri Nov 26 20:56:19 2021 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 6B8FA18A78BC for ; Fri, 26 Nov 2021 20:56:39 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f50.google.com (mail-io1-f50.google.com [209.85.166.50]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J16VZ41rXz3rR1; Fri, 26 Nov 2021 20:56:38 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io1-f50.google.com with SMTP id z26so12888505iod.10; Fri, 26 Nov 2021 12:56:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gqXXiFRIJ0rKS0OzOp6XwBbi054wDz+Rma7YTk01sg0=; b=vngxq7+NUjyzNGUPTUXadwpeCUfAej2qbR04y0brZ2Nzm/p5ifdl6aah5hnWztELqs 3hwI8KznALTWe8Ycdcj1YKWNbZwy1MY5OcOSzvIH6cKdcYNxl5UcevapOLDcSnj0Lv96 8knZkBqDdqBb/iS8nsOjbVCgNK0UmF1kczRlXH0H8ZqCCCu/q4nSDM5iybezoaG4OuYy JveTx+r0PZUPKJuekeIhqFhpNuk1viTTX9/RE7GOSb0eoW+HKk17X0mUm0E10/q8C1v4 xpIQNGADW91W30KrEknzD3AL1w2dEWFp7+B03IwklLfPB/9wJl3GPiujuI6mqoen4hAs KlJQ== X-Gm-Message-State: AOAM530tjTzLUJIeigFKBR5D5fnji8Uo1/t7ntnT9jjkA92LGB9fB4ZK 2cV3QcqaM44PmB03/xoyow5hual1HIkHs9X678gGZXfl X-Google-Smtp-Source: ABdhPJx4CoPZc0OAXz7XNa0IHu8goIJ6XKDm9uGN3TIv5XrFIJUwjAJBQzWVsVYnlts86YC0FIG9w0fZvO1BtfefRO0= X-Received: by 2002:a5d:818a:: with SMTP id u10mr37383619ion.140.1637960191219; Fri, 26 Nov 2021 12:56:31 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Ed Maste Date: Fri, 26 Nov 2021 15:56:19 -0500 Message-ID: Subject: Re: VDSO on amd64 To: Kurt Jaeger Cc: current Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4J16VZ41rXz3rR1 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.50 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [1.00 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[carpeddiem]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_SPAM_SHORT(1.00)[1.000]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[209.85.166.50:from]; NEURAL_SPAM_LONG(1.00)[1.000]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.166.50:from]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Thu, 25 Nov 2021 at 00:36, Kurt Jaeger wrote: > > Eleven years ago Giuseppe Cocomazzi posted this: > > http://lists.freebsd.org/pipermail/freebsd-hackers/2010-April/031553.html > > vdso and shared page patch I see the patch generated a couple of responses on the list when it was posted, including a plan to follow up with a detailed review that appears not to have happened. It's unfortunate, and as a project we definitely have an issue that not all contributions are addressed in a timely manner. One of the goals of the Git working group, and Warner's newer development practices working group, is to make it easier to handle contributions. Of course contributions can be overlooked regardless of whether they're patches on a mailing list, attached to a Bugzilla PR, opened as a Phabricator review, or as a GitHub or Gitlab pull or merge request. There isn't a technical solution that will fully address this, but we can reduce friction as much as possible. From nobody Sat Nov 27 01:31:22 2021 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id D192418BD2B5 for ; Sat, 27 Nov 2021 01:31:27 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J1Dbf1qZlz4pST; Sat, 27 Nov 2021 01:31:26 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-io1-xd2d.google.com with SMTP id v23so13505722iom.12; Fri, 26 Nov 2021 17:31:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=qxNGhbSYmV5Ze1PnVuA2I6ZooK+7k2/+Qp7jO93ZK9k=; b=ju32Hm0mSktz3/yYTnKyK/19mJX5YboT33XGvdmKjl/wDwzpD8tjhe+dI+S+zlkf4Q q3GJOY1NB8W1sRd/IiUZmM0T5cXjqx33J9fnzjmYPmElMuhCEcfI93pw83iCeB9Xh294 zT10l8RnTiInRY1wRGAkdy/LXpqRDyM87sdhhCigV87CxN1wBZpGzNynl5zxE51qiIss BACQDM15uczdCQi33RUW3rUwUfyZN4sue0DdwmXxn3AebLnx8FLh5K/ssc1P5sjwZ2aG FgI7+FxGI1mWcWHdF1l9g36dyZNLFcePTiputacfk0ChwU6FsErhMa3Y3LgrN/5I8nIn bmLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=qxNGhbSYmV5Ze1PnVuA2I6ZooK+7k2/+Qp7jO93ZK9k=; b=nS5gz1Ke0PULn51WiXvifJCLJ5pMPcpyq22Zz64tEFCdClYXe7V5+glRecAPCFgm5X FAowvGt7KhqE3MQCmJfNaxYdvrAwOf4ILRwE339KXZW2ChReuQYbPZRBoY7VLxY0/3FT wqGQW+C+79idvwlAYvxGeUB1fA5fEplbqqf3EfNJhrsz13mda79Cr+Hdm9fE7rAdU/rv zqV76RqT5sa+sepzoalXXbH9hEAK5In0ok/ZeTJOFKsI/anpryOB1lRHt4sEffkdN2Ni ogylNVcbyEplpMgc8lZaPFYt8ZhswSUsAsXtKhN0DjAdJnZf4RO0lV8GQL14XyEuZlCv zEWA== X-Gm-Message-State: AOAM532KmB0BwUX7BFGAIodSCr+r6K5zBYSCaczjmT/feylQ/tBwHZJs IAPxpCudqX6Xqp3NLy3y8dWFhJmj+tg= X-Google-Smtp-Source: ABdhPJw0YBgWFfBTzOWhvqZ1ZGaJ2glSjl3TxOVv0pTdI/JiHr/R/cUnLyOXpprqa3DBgqhyH/qftw== X-Received: by 2002:a05:6638:19a:: with SMTP id a26mr51085974jaq.133.1637976685228; Fri, 26 Nov 2021 17:31:25 -0800 (PST) Received: from nuc ([142.126.186.191]) by smtp.gmail.com with ESMTPSA id x2sm3058477ilv.65.2021.11.26.17.31.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 26 Nov 2021 17:31:24 -0800 (PST) Date: Fri, 26 Nov 2021 20:31:22 -0500 From: Mark Johnston To: Andriy Gapon Cc: FreeBSD Current Subject: Re: ctfconvert: rc = 1 Unsupported version [_dwarf_info_load(229)] Message-ID: References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4J1Dbf1qZlz4pST X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=ju32Hm0m; dmarc=none; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::d2d as permitted sender) smtp.mailfrom=markjdb@gmail.com X-Spamd-Result: default: False [-2.28 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; NEURAL_HAM_MEDIUM(-0.71)[-0.714]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[text/plain]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::d2d:from]; NEURAL_HAM_SHORT(-0.87)[-0.869]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N On Fri, Nov 26, 2021 at 02:48:03PM -0500, Mark Johnston wrote: > On Fri, Nov 26, 2021 at 02:00:27PM -0500, Mark Johnston wrote: > > On Fri, Nov 26, 2021 at 06:12:49PM +0200, Andriy Gapon wrote: > > > On 26/11/2021 18:06, Mark Johnston wrote: > > > > On Thu, Nov 25, 2021 at 10:48:36PM +0200, Andriy Gapon wrote: > > > >> > > > >> I've just finished builds of yesterday's CURRENT / main for arm and arm64. > > > >> In both builds I got lots of messages from ctfconvert: > > > >> ctfconvert: rc = 1 Unsupported version [_dwarf_info_load(229)] > > > >> > > > >> I got an impression that there was a message for each object file, that's how > > > >> many of them were there. > > > >> > > > >> I don't recall seeing those messages before. > > > >> > > > >> Should I be concerned? > > > >> Maybe I am doing something wrong or have an unusual configuration? > > > >> Any way to fix the issue? > > > >> > > > >> Thanks! > > > >> > > > >> P.S. > > > >> The builds were done on stable/13, so maybe there is an issue with host tools > > > >> not being able to grok something new. > > > > > > > > I haven't seen this before, for what it's worth. I presume this is from > > > > a kernel build? Does the configuration enable generation of debug info > > > > with, e.g., "makeoptions DEBUG=-g"? > > > > > > This is actually from buildworld. > > > buildkernel is silent. > > > > Thanks, I can reproduce it now. > > > > Our libdwarf is complaining that the first compilation unit header in > > .debug_info contains an unsupported DWARF version number (libdwarf only > > supports 2, 3 and 4). In files compiled by clang it ends up being zero. > > For instance, compiling bin/cat and dumping the .debug_info section: > > > > gcc10: > > c1250000 04000000 00000801 00000000 > > ^ DWARF version > > clang: > > 01000000 00000000 4e230000 00000000 > > > > llvm-dwarfdump and binutils readelf are somehow still able to find a > > valid-looking unit header, but I haven't yet been able to figure out how > > they do that from reading the DWARF 4/5 specs or the LLVM sources. > > Ah, we recently started configuring clang to compress debug sections by > default, and our libdwarf doesn't know how to handle that. As an > interim workaround this could simply be disabled with WITH_CTF is > configured: ... or give this a try: https://reviews.freebsd.org/D33139 From nobody Sat Nov 27 08:42:12 2021 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 2666918B6E78 for ; Sat, 27 Nov 2021 08:42:15 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J1Q8k6Vb8z4dr0; Sat, 27 Nov 2021 08:42:14 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from [192.168.0.88] (unknown [195.64.148.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: avg/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 6CD522FC68; Sat, 27 Nov 2021 08:42:14 +0000 (UTC) (envelope-from avg@freebsd.org) Message-ID: Date: Sat, 27 Nov 2021 10:42:12 +0200 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Firefox/91.0 Thunderbird/91.3.0 From: Andriy Gapon Subject: Re: ctfconvert: rc = 1 Unsupported version [_dwarf_info_load(229)] Content-Language: en-US To: Mark Johnston Cc: FreeBSD Current References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1638002534; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=V25bGptePsbj6AcGRAvuMBEwBZ02NcJbRzEysqyAXY0=; b=WqiYo+bdo9+z1ycUVWlS0LbbzFTNm/wwwQ9OZ7g3HmRSXYSJkXl+TRPSqGSofOfNsmf6P+ smLQKbaf8OyFmCQde1TNQ0AjW5egYSDYXA+BRgSnVgxVKYoqyHGd2EJOQQaKsMf5OshfL5 1xFk/BTvgtj2RylSsjyF09I3jCcYSLJqI6NGDFAu3BMrz8pGc10NXE7xt1LvM6AEvRTR8+ 9rLlEwag5I+Rog31q/sAdwEiuQeIU5GCPIXaJx08I3bxdjl1+20t/J3LD1cc0/AsL4v8Fj Z+oMSO/aDTozddMk/Hpq2ajO1vc26GLQLhhxHSldI65CQ9LTolRwUP6crB1UsQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1638002534; a=rsa-sha256; cv=none; b=rNoaNArdM/yk/T5jnmNJM4L0FF2u8LJPQ0mpflimV4gOsNxdHySxbgjO3o90dHnqSJanWj X+rkKYr61KMVLJbUT4lLZiY8Zru1Djss1z4tfH+tZ+vlJsx5ObjhgF6qQLdVga//crRxQp zVsbxH2p5Cnxahp+hMsQ8lpl2O5QBYezAwtBf3SOzq3Ars4F152SrPPuCbxiVdigeYQ8ac OkHCKn6FyzcFvLu0gB3TklPjJr0popMii25CrjZk7DQ01G4fd5pZruEzv6RbK95HfJiXqK a8QTSEDvnJ2Te6MiaV5qWa5sRtXYz/SpnS/zuTzyAI6FPgIubOccJ3sKqTWERg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 26/11/2021 21:48, Mark Johnston wrote: > On Fri, Nov 26, 2021 at 02:00:27PM -0500, Mark Johnston wrote: >> Thanks, I can reproduce it now. >> >> Our libdwarf is complaining that the first compilation unit header in >> .debug_info contains an unsupported DWARF version number (libdwarf only >> supports 2, 3 and 4). In files compiled by clang it ends up being zero. >> For instance, compiling bin/cat and dumping the .debug_info section: >> >> gcc10: >> c1250000 04000000 00000801 00000000 >> ^ DWARF version >> clang: >> 01000000 00000000 4e230000 00000000 >> >> llvm-dwarfdump and binutils readelf are somehow still able to find a >> valid-looking unit header, but I haven't yet been able to figure out how >> they do that from reading the DWARF 4/5 specs or the LLVM sources. > |Ah, we recently started configuring clang to compress debug sections by > default, and our libdwarf doesn't know how to handle that. As an interim > workaround this could simply be disabled with WITH_CTF is configured: Oh wow, you were very fast at figuring this out. Thank you very much! I'll give the build change a whirl first and then test D33139 a bit later. -- Andriy Gapon From nobody Sat Nov 27 17:49:39 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 6928518BC690 for ; Sat, 27 Nov 2021 17:49:55 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-20.consmr.mail.gq1.yahoo.com (sonic305-20.consmr.mail.gq1.yahoo.com [98.137.64.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 4J1fJf26ltz3tXT for ; Sat, 27 Nov 2021 17:49:54 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1638035387; bh=slkC98I3+ObhNWquRarEZsDTwzu+g34hBUvOC8BKTLw=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=MU2vNVXSrMzknA3jugAyf5wxC3ZwLk5XENfa3dBW2JG3CfjklbkgGNL7gEkmYFJWDu7YSs24nuRQLJUTEbYurJX0IB0j23Gnk2/ymx58Y5Osvlrr6lHK13HHXADRtnKT2Ky+KHyOvtQCNlls5J5i47PEB/b2VS7lOnQFqEKAiAYup/2vP/1viAnAX/LViv40ioVY+lEk3RIRgsevQlWhviaNS8dGd2ZSDO1Ydm76JHItkrdB76avzNriEhDEmeCN55fDvI5JiPxewfuz7O/tisZ5vU9tro+3TmSszLoRh9opMbCI9XsPJC2Er77YuYKk/HHMniIVxzQxpdnHsX6L5A== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1638035387; bh=2odp3STlsw2xFa2UIclnSHqeoD2rAGU5DxH5UPTBjDd=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=VhoJvzcQFYZdwXaWHKbx8T4FIwAt3hmcV6cVyA0kzi4ClRt2BnIzbsc3+ZeCN8BDjh1bri+MDbi3xxYIeoPo5cBOnji7V4fPdbVuU2O//5yLpiamiyFA4tmAwI0gnfeTogc1IosLWrqc/YzCZV9vBnvOLMwl3nLoI0JEvleklljOpYSyYZigJ6NNYYui8GRKl4lXeNeYbBbkmcqy4cTqeLrw2ZT5+24lpbFlqXwjk2b1DLsk9Uzk3CbZq5YkYCmcMY2tXNyR8dGJKr1Up2rHtcR7bmKpwmTjBNTKOPCl12yAJbZ0oK3iVtLIxnDbxkzhHizaOZBmJFUzLbWX7GBxJQ== X-YMail-OSG: YytQojQVM1m.8lk2sx27UwQmqmwvyjNaAujC0fMQx6ISQYxUwfLyVj6FYoOhXkT V.f3V0ixGMxbCD7N3RwuS2UZTmSNK6gzvw0aWGnJdHbCMa_mUILSuHh4BzhpHTCP44erxZPLnpzy gaVZoWxaF_nKS2QoCaAbysiiyED2pMGcAXCPAenpgnz5D_ZnqXFYoIHr9R02AY9TNu5SaRSfpE4a UlVDSzrFTu3dFKZillIgXRwCyz3n08cUlE4FT1Sa08MLrl.Cl_Afg2mt8BCQqiQGxDrHTHZ5oZSE 7L7dJfgPjpudZSzVs7T1lBVyucoa6EVObQBDn5DXbABQBgN.xRHjQRZpmD7u2stSP9W4KSBz6RTR 4AcA79gKpTDgwHNZDasTuWnr5JgyeXaITTkNAM4WJH_YWMjoM2IMQzCvborsmnJUPUouX9i4aA3G uPK4dssxGi6TdkfVtZs4vHWwf8SygqMf7XYhf4DMQO0a3YAnvFw13zOZDUkJS8nhgTHn2II288AN 83tWN9hfLzrmdDDRNggX6nlTcT_xzhuie3xg0Ssd0jtOxVDjXF9HX_ZJcIsQA7_jyER9NNQ.mQLc XfaSjLdHkbRp7oiDZRMY34varzrTy2XnQG5UrBVZhbvPoWiLyl1zcXaTDDAblUV0_Vpr1QWcgVQB cU9tmRKQHjaP5isdrFLTxhEyIuEMWRShvVDQvTxbBB1WRmH7Nzh4hE1rYDz0ixzY_zMNEzBTIGU6 udszLHcppesGtP77wNk3zTSMixzptto8GV745ETu1rYhORjVwOWR0OleYf4rPRUCH5_uLLI5aNRp CrEDry9S5dHCxT8pgtTGn2_VnkUGM5aFV01m8Fhguvoao20OyLIC_ZRNtuSnR6WpYEtQEeQuHLsB uV2TOnkH2YHjflBH0fA7laHhMZR1ygg8N6qCq_00cA6BduEENhOvvs_VKzNBHhZRbspnBqE6YvSB aRTB5BqcjXBh9Qf5kNtp7HAtxYinbdrQt050CQst34QI5sJDSIQ_BHfyQ7iYb.Cvmx0I7YADARVM u04g2JDYBc3MY2cQ077w8SUmTWsIZ.Uw2CAlF_Utzs1DZiWx3MEhtD3WlhsFJa9wfW0axgi3Kgf6 1HF9h661nkY0a0eIn9LPFW9TarS2LpjYcJEP2lAVbgm8g4POKBG5aXent.NtoBvyrYFqFtxH_FcV B_YE2SRnlBqjxzzuK3zxtB6PYJqSen0AbFtC7gqnXSuJq8FjlPSYHlR4m_lkTXnqv4VEl_7.YewH qF.MmzyP0Jg0P2.EYNO6qJB7HeqkTYRZS124qOpd3.6sbRoqc5ieI2QXNjF9AkAK8tsr6iGaI7xO 98ASIIZdydLeTXvzM9KAy.lj..IuRw2hXLoDnaFIfMDn4vfJs0jjFBEMirHpb2CQZMkHRZR0wK6D Redkt8qlZ_bhxJgrf9SqhLJNqtvZcuEnkLyqAjlIhfyA4qlGeoDT7HFj40sMWKD0WznXBFI7UenN R7S9JrpHGjh2bnoQhSqIPcFrEYZBP7FW9i06TcOPIj3CzdQu80._BWdInSQGIIhGrDMlswC9tfQi o4yKUKAk48wNq6jrJ5Wt1hQ9Q2vz4bx34jHISCu1hYOdtx35fV2DCL35wdlwPn_mMPHxN5MK26cJ wmcQ41xXqnvgCFe41ygYoD4Y5E.wSwWUrgiuvQq1IumX1DXPG5hrOrcuSDggoURQC4g88GmJ2ck5 3bGTnw0JlJcvICQLnldpU9XyiNo_KMJkm4NCfI3CTvqXH4U4Vimx7e56IGtwMEQu1jKImCw3rd5e 8sT..OG5hpOJKtYGgZrVftka_5dHyCZ_.Xrq7wpmRJVV.WgrINYpvRTD3ojoRFF4kFTT000drJ.. a2ybWdoeP4rM6ExKpgDBdIynaPEeedvHLFN6hyKh00LElxuQarWBS55KutruvSvTjsIpf_f_P4nf CUB_.Uy32VSV921hO0UhBVk9YL8S4vTCvwrkmM6lTs1ld08cRGUEYDvRdrE0UP4Rkbi_6_TTTKxw xtjyma0v7ZkITkL6JVHP69HCmqCA27v9kEypygkMzjGL9Pa54NLfW8uU0iN.Juiqhz5qsghtsltu mPVy0yb1A5amYIwWu2uQg64Hke8HpwkejRQ6NRbPXBi9YkUeIOWdEB2cTOnTUHM6utxGBsnCy9VY 6MglHjpcBpZTPLKvNxaFnyc.LEX9K1qLODM0XPmFffXbXvZAAHs9fuiPvTuo_QaJA6lNGZU1hkuJ OjFNne2MAdNoWGC_i34j.y1exwlXNFNt.nCtQHa0IMeV52CACy6JU9cEhHOtb.CriWKv.g_y_xx7 AJv6eJbgpXHdKeTAhywLY X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Sat, 27 Nov 2021 17:49:47 +0000 Received: by kubenode542.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 6b516206b97909cd83620819b9d76e7e; Sat, 27 Nov 2021 17:49:42 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: main [so: 14]: contrib/llvm-project/libunwind/src/Unwind-EHABI.cpp:915 failure in armv7 context Message-Id: <07C4B8C4-4EB8-44C4-B627-1ABA8722AEB3@yahoo.com> Date: Sat, 27 Nov 2021 09:49:39 -0800 To: Free BSD , freebsd-current X-Mailer: Apple Mail (2.3654.120.0.1.13) References: <07C4B8C4-4EB8-44C4-B627-1ABA8722AEB3.ref@yahoo.com> X-Rspamd-Queue-Id: 4J1fJf26ltz3tXT X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=MU2vNVXS; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.51 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_SHORT(0.99)[0.990]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.83:from]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.83:from] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N In tracking down a armv7 build failure for some ports the fail during rustc, I managed to get a gdb backtrace for an example .core finally. This is based on not striping (no debug information). (rustc's build in armv7 contexts attempt links that fail for lack of a sufficient process address space.) The thing is that the .core file is generated during rustc itself attempting to do a backtrace for its internal failure. The gdb backtrace shows the top-of-call-stack (larger address) stack frames as being in FreeBSD code. The freeBSD builds involved are a non-debug builds but with debug information present. Note that the thread involved is not the main thread but one created via _pthread_create instead. Also note that the SIGSEGV happened at: /usr/main-src/contrib/llvm-project/libunwind/src/Unwind-EHABI.cpp:915 which looks like: 915 uint32_t value =3D *sp++; I could get the other source lines for the FreeBSD call frames if needed. gdb reports: Core was generated by `/usr/local/bin/rustc --crate-name tempfile = --edition=3D2018 /wrkdirs/usr/ports/dev'. Program terminated with signal SIGSEGV, Segmentation fault. Address not mapped to object. #0 _Unwind_VRS_Pop (context=3D0xbfff5b80, regclass=3D_UVRSC_CORE, = discriminator=3D18432, representation=3D_UVRSD_UINT32) at = /usr/main-src/contrib/llvm-project/libunwind/src/Unwind-EHABI.cpp:915 915 uint32_t value =3D *sp++; [Current thread is 1 (LWP 710038)] (gdb) bt #0 _Unwind_VRS_Pop (context=3D0xbfff5b80, regclass=3D_UVRSC_CORE, = discriminator=3D18432, representation=3D_UVRSD_UINT32) at = /usr/main-src/contrib/llvm-project/libunwind/src/Unwind-EHABI.cpp:915 #1 _Unwind_VRS_Interpret (context=3D0xbfff5b80, data=3D, = offset=3D4, len=3D4) at = /usr/main-src/contrib/llvm-project/libunwind/src/Unwind-EHABI.cpp:281 #2 0x400c83e0 in libunwind::UnwindCursor::stepWithEHABI (this=3D0xbfff5b80) at = /usr/main-src/contrib/llvm-project/libunwind/src/UnwindCursor.hpp:921 #3 libunwind::UnwindCursor::step (this=3D0xbfff5b80) at = /usr/main-src/contrib/llvm-project/libunwind/src/UnwindCursor.hpp:2094 #4 0x400c7134 in (anonymous namespace)::unwindOneFrame = (state=3D, ucbp=3D0xbfff59d8, context=3D0xbfff5b80) at = /usr/main-src/contrib/llvm-project/libunwind/src/Unwind-EHABI.cpp:190 #5 0x400c7708 in _Unwind_Backtrace (callback=3D0x47346bc0 = , = ref=3D0xbfff5d58) at = /usr/main-src/contrib/llvm-project/libunwind/src/UnwindLevel1-gcc-ext.c:15= 6 #6 0x47311b58 in std::backtrace::Backtrace::create () from = /usr/local/lib/libstd-21f5f79d0bba7291.so #7 0x47311ac8 in std::backtrace::Backtrace::force_capture () from = /usr/local/lib/libstd-21f5f79d0bba7291.so #8 0x46c61f28 in rustc_errors::Handler::delay_good_path_bug () from = /usr/local/lib/librustc_driver-a196dfc434d07325.so #9 0x46a33998 in = rustc_middle::ty::print::pretty::trimmed_def_paths::h696a2e73b4fe3316 () = from /usr/local/lib/librustc_driver-a196dfc434d07325.so . . . #42 0x401371ac in thread_start (curthread=3D0x40073a00) at = /usr/main-src/lib/libthr/thread/thr_create.c:292 #43 0x40136cdc in _pthread_create (thread=3D0xffffb0b8, attr=3D, start_routine=3D, arg=3D) at = /usr/main-src/lib/libthr/thread/thr_create.c:187 #44 0x40139a4c in _thr_umutex_unlock2 (mtx=3D0x0, id=3D11, defer=3D0x0) = at /usr/main-src/lib/libthr/thread/thr_umtx.h:160 #45 _thr_umutex_unlock (mtx=3D0x0, id=3D11) at = /usr/main-src/lib/libthr/thread/thr_umtx.h:183Backtrace stopped: Cannot = access memory at address 0x4 For reference: # uname -apKU FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #22 = main-n250972-319e9fc642a1-dirty: Tue Nov 23 12:25:36 PST 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400042 1400042 # poudriere jail -jmain-CA7 -i Jail name: main-CA7 Jail version: 14.0-CURRENT Jail arch: arm.armv7 Jail method: null Jail mount: /usr/obj/DESTDIRs/main-CA7-poud Jail fs: =20 Jail updated: 2021-06-27 17:58:33 Jail pkgbase: disabled # uname -apKU FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #22 = main-n250972-319e9fc642a1-dirty: Tue Nov 23 12:25:36 PST 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm armv7 1400042 1400042 The backtracking also fails for releng/13.0 (-p5) poudriere jail targeting armv7 but some details are different that make it more complicated to deal with. I've only gone after gathering and reporting evidence from the simpler context that gets the somewhat earlier failure. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Sat Nov 27 21:56:20 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9C73F18B10F6 for ; Sat, 27 Nov 2021 21:56:40 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f50.google.com (mail-io1-f50.google.com [209.85.166.50]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J1lnM4wvdz4f2m for ; Sat, 27 Nov 2021 21:56:39 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io1-f50.google.com with SMTP id e144so15991580iof.3 for ; Sat, 27 Nov 2021 13:56:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=FdQq5SsPXTDQ+VXMVlJZagIIcxGNobtM13AI3K2Gu88=; b=BMzu6KSIkIIgxgJtw+XDgHyNH61+cMoVC7ZEaWRFYzwqGPslhhe2SB93Hv2c1CFGyG WzejBkfgxc0QYXAyv7OPD5zRLL5Jnnmd0BJ6ISmMR6YvZr3QI5Qz+LGnkfyvv0d1Qt1Y E5diYW7I4V6+qpKBjR9Fxd71+IDcF+nqhBJo9I/OLcIV8UrZ4nAwrAwCLkpYng/Vcyb+ qCY0xbTCB/YCHW4rA3LRIcEzaZ+rrpkSPqEblW3aH/O79HQTTtJS3q3HPzEC0C6EbVo9 SPpKqNIH4i9T7PhkwTtrRF/p4pw6+S3sVqsmkqbNvfuUGt/84DKNZFkieviEtUFykspc JQWQ== X-Gm-Message-State: AOAM530Rm7pIQayA8wUmFs0t+BRG4w58/IGkTwCLbZSakaWE3k2re5LZ Jji+HZX9U9TAcNK3edPcRurUP/lq7+UU7lQQEwBZuiyKsec= X-Google-Smtp-Source: ABdhPJwE1ItPEOVDLmI5XCww3d2Z68jtwc0/DKcYne58rowaFEitKIoOw7vh5whoF4MtvhIaIMSwMA/Jj0/Zwv8iG24= X-Received: by 2002:a05:6602:2d81:: with SMTP id k1mr45888243iow.112.1638050192401; Sat, 27 Nov 2021 13:56:32 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 From: Ed Maste Date: Sat, 27 Nov 2021 16:56:20 -0500 Message-ID: Subject: HEADS-UP: options VESA removal from x86 GENERIC To: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4J1lnM4wvdz4f2m X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.50 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [2.33 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FREEFALL_USER(0.00)[carpeddiem]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; NEURAL_SPAM_MEDIUM(0.33)[0.330]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_ALL(0.00)[]; NEURAL_SPAM_LONG(1.00)[1.000]; RCVD_IN_DNSWL_NONE(0.00)[209.85.166.50:from]; NEURAL_SPAM_SHORT(1.00)[1.000]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.166.50:from]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TO_DOM_EQ_FROM_DOM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N As reported by Stefan Blachmann in a reply on freebsd-hackers[1], having `options VESA` compiled into the kernel or loaded as a module breaks suspend-resume with the nvidia driver. See PR 253733. The default console is provided by vt(4), which does not use the `options VESA` driver, which serves no purpose for most users. (vt(4) supports a loader-set VBE mode via the vt_vbefb driver.) Thus, I plan to remove[2] options VESA from the x86 kernel config files. sc(4) users who wish to select alternate VBE modes will still be able to do so by loading the kernel module. [1] https://lists.freebsd.org/archives/freebsd-hackers/2021-November/000469.html [2] https://reviews.freebsd.org/D33141 From nobody Mon Nov 29 11:01:22 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 86DBE18B66A8 for ; Mon, 29 Nov 2021 11:01:42 +0000 (UTC) (envelope-from dclarke@blastwave.org) Received: from mail.oetec.com (mail.oetec.com [108.160.241.186]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.oetec.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J2j8j568fz3KR1 for ; Mon, 29 Nov 2021 11:01:41 +0000 (UTC) (envelope-from dclarke@blastwave.org) X-Spam-Status: No X-oetec-MailScanner-From: dclarke@blastwave.org X-oetec-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.099, required 6, autolearn=not spam, ALL_TRUSTED -1.00, BAYES_00 -1.90, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, DKIM_VALID_EF -0.10, URIBL_BLOCKED 0.00) X-oetec-MailScanner: Found to be clean X-oetec-MailScanner-ID: 1ATB1NHn011976 X-oetec-MailScanner-Information: Please contact oetec for more information Received: from [10.14.0.5] (static-198-54-132-56.cust.tzulo.com [198.54.132.56]) (authenticated bits=0) by mail.oetec.com (8.15.2/8.15.2/Debian-8) with ESMTPSA id 1ATB1NHn011976 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Mon, 29 Nov 2021 06:01:24 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blastwave.org; s=default; t=1638183684; bh=zXeb2JzIpSqRWQ9evf4zepAsC8W0x2YTA4BFBLvMkkQ=; h=Date:To:From:Subject:From; b=h/CRcsqB1jaug3UYzb3rUwic7CAzTdt8lR9HOI/erG6WnoGWrHr9/2xKga/WlmcLP Gz2zNo6CKfCJklfNP9XL0Xuo/75dRRFcdffCch3ha/UceiuFYhdFOoYsPifI22dmPh clIASvj9gIaNZ/88qxhMzIg+6+dW/x3+lf+1DFUMBQTmavc4fVSKXlGm9BAWoWUiF5 M80oxcg/h9ssI3ws14lMlnUZeb/cTLEgOi27EcO6ETcjeoUpSN4wFd7x+V4PYeywYC PRgfeqOEQgW1GtF9ULnMy4OPU4hJTEwa81ZtKSYiCxoNOmDyhM4+eYqEJIQpTaSQ5i 5BL1yBNq4H7lw== Message-ID: <4d9d5406-c257-e5cb-d237-d26889468f62@blastwave.org> Date: Mon, 29 Nov 2021 06:01:22 -0500 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:95.0) Gecko/20100101 Thunderbird/95.0 To: FreeBSD Current Content-Language: en-US Subject: pkg sqlite database borked ( again ). How to restore? Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4J2j8j568fz3KR1 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=blastwave.org header.s=default header.b="h/CRcsqB"; dmarc=pass (policy=quarantine) header.from=blastwave.org; spf=pass (mx1.freebsd.org: domain of dclarke@blastwave.org designates 108.160.241.186 as permitted sender) smtp.mailfrom=dclarke@blastwave.org X-Spamd-Result: default: False [-3.31 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[blastwave.org:s=default]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.98)[-0.978]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_DN_ALL(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[108.160.241.186:from]; DKIM_TRACE(0.00)[blastwave.org:+]; DMARC_POLICY_ALLOW(-0.50)[blastwave.org,quarantine]; NEURAL_HAM_SHORT(-0.63)[-0.630]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:812, ipnet:108.160.240.0/20, country:CA]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] Reply-To: dclarke@blastwave.org From: Dennis Clarke via freebsd-current X-Original-From: Dennis Clarke X-ThisMailContainsUnwantedMimeParts: N I had another kernel panic on an AMD64 server. This has resulted in the pkg database being messed up. Also I was running a QEMU instance for aarch64 and that ended up with a messed up pkg database also. I saw some docs in section 4.4.8. Restoring the Package Database here: https://docs.freebsd.org/en/books/handbook/ports/#pkgng-intro However that does not work and issues a truely worthless error : europa# uname -apKU FreeBSD europa 14.0-CURRENT FreeBSD 14.0-CURRENT #6 main-n250839-be60d8f276f: Fri Nov 19 00:02:38 GMT 2021 root@europa:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 amd64 1400042 1400042 europa# europa# ls -lap /var/backups/pkg* -rw-r--r-- 1 root wheel 2714084 Nov 29 03:04 /var/backups/pkg.sql.xz -rw-r--r-- 1 root wheel 2714084 Nov 28 03:20 /var/backups/pkg.sql.xz.1 -rw-r--r-- 1 root wheel 2714084 Nov 27 03:03 /var/backups/pkg.sql.xz.2 -rw-r--r-- 1 root wheel 2714084 Nov 26 03:03 /var/backups/pkg.sql.xz.3 -rw-r--r-- 1 root wheel 2714084 Nov 25 03:29 /var/backups/pkg.sql.xz.4 -rw-r--r-- 1 root wheel 2712568 Nov 24 03:04 /var/backups/pkg.sql.xz.5 -rw-r--r-- 1 root wheel 2712568 Nov 23 03:03 /var/backups/pkg.sql.xz.6 -rw-r--r-- 1 root wheel 2711928 Nov 22 03:54 /var/backups/pkg.sql.xz.7 europa# So I took a backup from there that looked reasonable : europa# xz -dc /var/backups/pkg.sql.xz.3 > /var/db/pkg/local.sqlite.dump europa# europa# pkg backup -r /var/db/pkg/local.sqlite.dump Restoring database: Restoring: 100% pkg: sqlite error while executing backup step in file backup.c:98: not an error pkg: sqlite error -- (null) europa# echo $? 1 europa# I don't know what to make of that mess. Can I create a new blank sqlite3 database and then restore from that dump file or is there a method that works better? Also is there a blank sqlite3 database for pkg on the install media? -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional From nobody Mon Nov 29 11:22:01 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id BC26518C04C4 for ; Mon, 29 Nov 2021 11:22:11 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [IPv6:2001:19f0:300:2185:123::1]) by mx1.freebsd.org (Postfix) with ESMTP id 4J2jcM4vfCz3h09 for ; Mon, 29 Nov 2021 11:22:11 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [104.207.135.49]) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id 1ATBM2pi034287; Mon, 29 Nov 2021 11:22:02 GMT (envelope-from jamie@donotpassgo.dyslexicfish.net) Received: (from jamie@localhost) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id 1ATBM1vp034286; Mon, 29 Nov 2021 11:22:01 GMT (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <202111291122.1ATBM1vp034286@donotpassgo.dyslexicfish.net> Date: Mon, 29 Nov 2021 11:22:01 +0000 Organization: Dyslexic Fish To: freebsd-current@FreeBSD.org, dclarke@blastwave.org Subject: Re: pkg sqlite database borked ( again ). How to restore? References: <4d9d5406-c257-e5cb-d237-d26889468f62@blastwave.org> In-Reply-To: <4d9d5406-c257-e5cb-d237-d26889468f62@blastwave.org> User-Agent: Heirloom mailx 12.4 7/29/08 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (donotpassgo.dyslexicfish.net [104.207.135.49]); Mon, 29 Nov 2021 11:22:02 +0000 (GMT) X-Rspamd-Queue-Id: 4J2jcM4vfCz3h09 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Dennis Clarke via freebsd-current wrote: > europa# xz -dc /var/backups/pkg.sql.xz.3 > /var/db/pkg/local.sqlite.dump > > europa# > europa# pkg backup -r /var/db/pkg/local.sqlite.dump > Restoring database: > Restoring: 100% > pkg: sqlite error while executing backup step in file backup.c:98: not > an error The backup file consists of sql statements, the pkg backup -r I think requires a binary db file. I think you need to do this: pkg shell < /var/db/pkg/local.sqlite.dump Cheers, Jamie From nobody Mon Nov 29 12:32:01 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E826218C2090 for ; Mon, 29 Nov 2021 12:32:08 +0000 (UTC) (envelope-from dclarke@blastwave.org) Received: from mail.oetec.com (mail.oetec.com [108.160.241.186]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.oetec.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J2l941cKPz4XlX for ; Mon, 29 Nov 2021 12:32:07 +0000 (UTC) (envelope-from dclarke@blastwave.org) X-Spam-Status: No X-oetec-MailScanner-From: dclarke@blastwave.org X-oetec-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-4.416, required 6, autolearn=not spam, ALL_TRUSTED -1.00, BAYES_00 -1.90, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, DKIM_VALID_EF -0.10, NICE_REPLY_A -1.32, URIBL_BLOCKED 0.00) X-oetec-MailScanner: Found to be clean X-oetec-MailScanner-ID: 1ATCW1eE015069 X-oetec-MailScanner-Information: Please contact oetec for more information Received: from [10.14.0.5] (static-198-54-132-56.cust.tzulo.com [198.54.132.56]) (authenticated bits=0) by mail.oetec.com (8.15.2/8.15.2/Debian-8) with ESMTPSA id 1ATCW1eE015069 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Mon, 29 Nov 2021 07:32:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blastwave.org; s=default; t=1638189123; bh=A9yvIRoXAb4eih5r7RiTkOybe+RjJTNmT/ucgHl2UnU=; h=Date:Subject:To:References:From:In-Reply-To:From; b=tNsh6OiO8wmn8+ZOsva8nMV2GkYv13OWzBUdM3+8HIuCSv07TpVjoIIXKqB4yHsh9 RZMO9dhlTici5Rx44zhHmm7KeU/pAN0CA5tuh4XBBsKnnia0xrjOtao74S6NNUJDxC jwQ82DBib/1nYBogrTSucJl+JxTEOZa+FHJmJOJu8R9OumusDb34dDexjMQ40O3nrr Rdgr0FCbd8flC98R7l/fWb5xDIzs4qbN7dViBzvQ0FSreU2HuML6+pP6u6xcQZc85l Z5jpM6cyBiE0V2MOrVItBsw2NavttuYqatRhmFQJdK24G11srSYPri5UC9RvMKvVAH gpS4hpVaRSaiw== Message-ID: <3b4d90c7-cacf-8b9d-60cd-694e68e76ed1@blastwave.org> Date: Mon, 29 Nov 2021 07:32:01 -0500 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:95.0) Gecko/20100101 Thunderbird/95.0 Subject: Re: pkg sqlite database borked ( again ). How to restore? Content-Language: en-US To: freebsd-current@freebsd.org References: <4d9d5406-c257-e5cb-d237-d26889468f62@blastwave.org> <202111291122.1ATBM1vp034286@donotpassgo.dyslexicfish.net> In-Reply-To: <202111291122.1ATBM1vp034286@donotpassgo.dyslexicfish.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4J2l941cKPz4XlX X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=blastwave.org header.s=default header.b=tNsh6OiO; dmarc=pass (policy=quarantine) header.from=blastwave.org; spf=pass (mx1.freebsd.org: domain of dclarke@blastwave.org designates 108.160.241.186 as permitted sender) smtp.mailfrom=dclarke@blastwave.org X-Spamd-Result: default: False [-3.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[blastwave.org:s=default]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; RCVD_IN_DNSWL_MED(-0.20)[108.160.241.186:from]; DKIM_TRACE(0.00)[blastwave.org:+]; DMARC_POLICY_ALLOW(-0.50)[blastwave.org,quarantine]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:812, ipnet:108.160.240.0/20, country:CA]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] Reply-To: dclarke@blastwave.org From: Dennis Clarke via freebsd-current X-Original-From: Dennis Clarke X-ThisMailContainsUnwantedMimeParts: N On 11/29/21 06:22, Jamie Landeg-Jones wrote: > Dennis Clarke via freebsd-current wrote: > >> europa# xz -dc /var/backups/pkg.sql.xz.3 > /var/db/pkg/local.sqlite.dump >> >> europa# >> europa# pkg backup -r /var/db/pkg/local.sqlite.dump >> Restoring database: >> Restoring: 100% >> pkg: sqlite error while executing backup step in file backup.c:98: not >> an error > > The backup file consists of sql statements, the pkg backup -r I think > requires a binary db file. > > I think you need to do this: > > pkg shell < /var/db/pkg/local.sqlite.dump > > Cheers, Jamie > Ah well ... that seems to toss a ton of errors and yet works ? europa# europa# pkg shell < /var/db/pkg/local.sqlite.dump Error: near line 4: table packages already exists Error: near line 212: UNIQUE constraint failed: packages.name Error: near line 246: table mtree already exists Error: near line 247: table pkg_script already exists Error: near line 611: table script already exists Error: near line 612: UNIQUE constraint failed: script.script_id Error: near line 684: table option already exists Error: near line 685: UNIQUE constraint failed: option.option_id Error: near line 1049: table option_desc already exists Error: near line 1050: table pkg_option already exists Error: near line 1591: table pkg_option_desc already exists Error: near line 1592: table pkg_option_default already exists Error: near line 1593: table deps already exists Error: near line 2393: table files already exists Error: near line 61890: UNIQUE constraint failed: files.path Error: near line 61891: UNIQUE constraint failed: files.path Error: near line 61892: UNIQUE constraint failed: files.path Error: near line 61893: UNIQUE constraint failed: files.path Error: near line 61894: UNIQUE constraint failed: files.path Error: near line 61895: UNIQUE constraint failed: files.path Error: near line 61896: UNIQUE constraint failed: files.path Error: near line 61897: UNIQUE constraint failed: files.path Error: near line 61898: UNIQUE constraint failed: files.path Error: near line 61899: UNIQUE constraint failed: files.path Error: near line 61900: UNIQUE constraint failed: files.path Error: near line 61901: UNIQUE constraint failed: files.path Error: near line 61902: UNIQUE constraint failed: files.path Error: near line 61903: UNIQUE constraint failed: files.path Error: near line 61904: UNIQUE constraint failed: files.path Error: near line 61905: UNIQUE constraint failed: files.path Error: near line 61906: UNIQUE constraint failed: files.path Error: near line 61907: UNIQUE constraint failed: files.path Error: near line 61908: UNIQUE constraint failed: files.path Error: near line 61909: UNIQUE constraint failed: files.path Error: near line 61910: UNIQUE constraint failed: files.path Error: near line 61911: UNIQUE constraint failed: files.path Error: near line 61912: UNIQUE constraint failed: files.path Error: near line 61913: UNIQUE constraint failed: files.path Error: near line 61914: UNIQUE constraint failed: files.path Error: near line 61915: UNIQUE constraint failed: files.path Error: near line 61916: UNIQUE constraint failed: files.path Error: near line 61917: UNIQUE constraint failed: files.path Error: near line 61918: UNIQUE constraint failed: files.path Error: near line 61919: UNIQUE constraint failed: files.path Error: near line 61920: UNIQUE constraint failed: files.path Error: near line 61921: UNIQUE constraint failed: files.path Error: near line 61922: UNIQUE constraint failed: files.path Error: near line 61923: UNIQUE constraint failed: files.path Error: near line 61924: UNIQUE constraint failed: files.path Error: near line 61925: UNIQUE constraint failed: files.path Error: near line 61926: UNIQUE constraint failed: files.path Error: near line 61927: UNIQUE constraint failed: files.path Error: near line 61928: UNIQUE constraint failed: files.path Error: near line 61929: UNIQUE constraint failed: files.path Error: near line 61930: UNIQUE constraint failed: files.path Error: near line 61931: UNIQUE constraint failed: files.path Error: near line 61932: UNIQUE constraint failed: files.path Error: near line 61933: UNIQUE constraint failed: files.path Error: near line 61934: UNIQUE constraint failed: files.path Error: near line 61935: UNIQUE constraint failed: files.path Error: near line 61936: UNIQUE constraint failed: files.path Error: near line 61937: UNIQUE constraint failed: files.path Error: near line 61938: UNIQUE constraint failed: files.path Error: near line 61939: UNIQUE constraint failed: files.path Error: near line 61940: UNIQUE constraint failed: files.path Error: near line 61941: UNIQUE constraint failed: files.path Error: near line 61942: UNIQUE constraint failed: files.path Error: near line 61943: UNIQUE constraint failed: files.path Error: near line 61944: UNIQUE constraint failed: files.path Error: near line 61945: UNIQUE constraint failed: files.path Error: near line 61946: UNIQUE constraint failed: files.path Error: near line 61947: UNIQUE constraint failed: files.path Error: near line 61948: UNIQUE constraint failed: files.path Error: near line 61949: UNIQUE constraint failed: files.path Error: near line 61950: UNIQUE constraint failed: files.path Error: near line 61951: UNIQUE constraint failed: files.path Error: near line 72921: table directories already exists Error: near line 72927: UNIQUE constraint failed: directories.path Error: near line 73338: table pkg_directories already exists Error: near line 73759: table categories already exists Error: near line 73760: UNIQUE constraint failed: categories.id Error: near line 73794: table pkg_categories already exists Error: near line 74112: table licenses already exists Error: near line 74113: UNIQUE constraint failed: licenses.id Error: near line 74157: table pkg_licenses already exists Error: near line 74456: table users already exists Error: near line 74464: table pkg_users already exists Error: near line 74473: table groups already exists Error: near line 74481: table pkg_groups already exists Error: near line 74490: table shlibs already exists Error: near line 74587: UNIQUE constraint failed: shlibs.name Error: near line 74987: table pkg_shlibs_required already exists Error: near line 75701: table pkg_shlibs_provided already exists Error: near line 76192: table annotation already exists Error: near line 76193: UNIQUE constraint failed: annotation.annotation_id Error: near line 76194: UNIQUE constraint failed: annotation.annotation_id Error: near line 76408: table pkg_annotation already exists Error: near line 77219: table pkg_conflicts already exists Error: near line 77220: table pkg_lock already exists Error: near line 77222: table pkg_lock_pid already exists Error: near line 77223: table provides already exists Error: near line 77224: table pkg_provides already exists Error: near line 77225: table config_files already exists Error: near line 77226: table requires already exists Error: near line 77227: table pkg_requires already exists Error: near line 77228: table lua_script already exists Error: near line 77233: UNIQUE constraint failed: lua_script.lua_script Error: near line 77277: table pkg_lua_script already exists Error: near line 77326: index packages_unique already exists Error: near line 77327: index deps_unique already exists Error: near line 77328: index deporigini already exists Error: near line 77329: index pkg_script_package_id already exists Error: near line 77330: index deps_package_id already exists Error: near line 77331: index files_package_id already exists Error: near line 77332: index pkg_directories_package_id already exists Error: near line 77333: index pkg_categories_package_id already exists Error: near line 77334: index pkg_licenses_package_id already exists Error: near line 77335: index pkg_users_package_id already exists Error: near line 77336: index pkg_groups_package_id already exists Error: near line 77337: index pkg_shlibs_required_package_id already exists Error: near line 77338: index pkg_shlibs_provided_package_id already exists Error: near line 77339: index pkg_directories_directory_id already exists Error: near line 77340: index pkg_annotation_package_id already exists Error: near line 77341: index pkg_conflicts_pid already exists Error: near line 77342: index pkg_conflicts_cid already exists Error: near line 77343: index pkg_provides_id already exists Error: near line 77344: index packages_origin already exists Error: near line 77345: index packages_name already exists Error: near line 77346: index pkg_digest_id already exists Error: near line 77347: table pkg_shlibs already exists Error: near line 77348: trigger pkg_shlibs_update already exists Error: near line 77349: trigger pkg_shlibs_insert already exists Error: near line 77350: trigger pkg_shlibs_delete already exists Error: near line 77351: table scripts already exists Error: near line 77352: trigger scripts_update already exists Error: near line 77353: trigger scripts_insert already exists Error: near line 77354: trigger scripts_delete already exists Error: near line 77355: table options already exists Error: near line 77356: trigger options_update already exists Error: near line 77357: trigger options_insert already exists Error: near line 77358: trigger options_delete already exists Error: near line 77359: table lua_scripts already exists Error: near line 77360: trigger lua_script_update already exists Error: near line 77361: trigger lua_script_insert already exists Error: near line 77362: trigger lua_script_delete already exists europa# europa# pkg query %n\ %v\ %o adwaita-icon-theme 40.1.1 x11-themes/adwaita-icon-theme argyllcms 1.9.2_5 graphics/argyllcms at-spi2-atk 2.34.2 accessibility/at-spi2-atk at-spi2-core 2.36.0 accessibility/at-spi2-core atk 2.36.0 accessibility/atk autoconf 2.69_3 devel/autoconf autoconf-wrapper 20131203 devel/autoconf-wrapper autoconf213 2.13.000227_7 devel/autoconf213 automake 1.16.4 devel/automake autotools 20130627 devel/autotools avahi-app 0.8 net/avahi-app bash 5.1.8 shells/bash bind-tools 9.16.22 dns/bind-tools binutils 2.37_1,1 devel/binutils bison 3.7.6,1 devel/bison bitmap 1.0.9 x11/bitmap boost-libs 1.72.0_6 devel/boost-libs brotli 1.0.9,1 archivers/brotli ca_root_nss 3.71 security/ca_root_nss cairo 1.17.4,3 graphics/cairo colord 1.3.5_1 graphics/colord cups 2.3.3op2 print/cups curl 7.79.1 ftp/curl cyrus-sasl 2.1.27_2 security/cyrus-sasl2 dbus 1.12.20_5 devel/dbus dbus-glib 0.112 devel/dbus-glib dejavu 2.37_1 x11-fonts/dejavu dialog4ports 0.1.6_1 ports-mgmt/dialog4ports dtc 1.6.0 sysutils/dtc enchant2 2.2.15 textproc/enchant2 encodings 1.0.5,1 x11-fonts/encodings expat 2.4.1 textproc/expat2 expect 5.45.4_2,1 lang/expect font-bh-ttf 1.0.3_4 x11-fonts/font-bh-ttf font-misc-ethiopic 1.0.4 x11-fonts/font-misc-ethiopic font-misc-meltho 1.0.3_4 x11-fonts/font-misc-meltho fontconfig 2.13.94_1,1 x11-fonts/fontconfig freeglut 3.2.1 graphics/freeglut freetype2 2.11.0 print/freetype2 fribidi 1.0.11 converters/fribidi gawk 5.1.1 lang/gawk gdb 11.1_1 devel/gdb gdbm 1.22 databases/gdbm gdk-pixbuf2 2.40.0 graphics/gdk-pixbuf2 geoclue 2.5.7 net/geoclue gettext-runtime 0.21 devel/gettext-runtime giflib 5.2.1 graphics/giflib git 2.33.1 devel/git glew 2.2.0_3 graphics/glew glfw 3.3.4_1 graphics/glfw glib 2.70.1,2 devel/glib20 glib-networking 2.66.0_1 net/glib-networking gmake 4.3_2 devel/gmake gmp 6.2.1 math/gmp gnome_subr 1.0 sysutils/gnome_subr gnuplot 5.4.1_1 math/gnuplot gnutls 3.6.16 security/gnutls gobject-introspection 1.66.1,1 devel/gobject-introspection graphene 1.10.6 graphics/graphene graphite2 1.3.14 graphics/graphite2 groff 1.22.4_4 textproc/groff gsed 4.8 textproc/gsed gsettings-desktop-schemas 41.0 devel/gsettings-desktop-schemas gstreamer1 1.16.2 multimedia/gstreamer1 gstreamer1-plugins 1.16.2_3 multimedia/gstreamer1-plugins gstreamer1-plugins-bad 1.16.2 multimedia/gstreamer1-plugins-bad gstreamer1-plugins-gl 1.16.2_2 graphics/gstreamer1-plugins-gl gtk-update-icon-cache 3.24.26_1 graphics/gtk-update-icon-cache gtk3 3.24.30 x11-toolkits/gtk30 harfbuzz 3.1.1 print/harfbuzz harfbuzz-icu 3.1.1 print/harfbuzz-icu hicolor-icon-theme 0.17 misc/hicolor-icon-theme hunspell 1.7.0_2 textproc/hunspell hyphen 2.8.8 textproc/hyphen icu 70.1_1,1 devel/icu indexinfo 0.3.1 print/indexinfo iperf3 3.10.1_1 benchmarks/iperf3 iso-codes 4.2 misc/iso-codes jbigkit 2.1_1 graphics/jbigkit jpeg-turbo 2.1.1 graphics/jpeg-turbo json-c 0.15_1 devel/json-c json-glib 1.6.2_1 devel/json-glib lcms2 2.12 graphics/lcms2 libGLU 9.0.2_1 graphics/libGLU libICE 1.0.10,1 x11/libICE libSM 1.2.3,1 x11/libSM libX11 1.7.2,1 x11/libX11 libXScrnSaver 1.2.3_2 x11/libXScrnSaver libXau 1.0.9 x11/libXau libXaw 1.0.14,2 x11-toolkits/libXaw libXcomposite 0.4.5,1 x11/libXcomposite libXcursor 1.2.0 x11/libXcursor libXdamage 1.1.5 x11/libXdamage libXdmcp 1.1.3 x11/libXdmcp libXext 1.3.4,1 x11/libXext libXfixes 5.0.3_2 x11/libXfixes libXft 2.3.3 x11-fonts/libXft libXi 1.7.10,1 x11/libXi libXinerama 1.1.4_2,1 x11/libXinerama libXmu 1.1.3,1 x11-toolkits/libXmu libXpm 3.5.13 x11/libXpm libXrandr 1.5.2 x11/libXrandr libXrender 0.9.10_2 x11/libXrender libXt 1.2.1,1 x11-toolkits/libXt libXtst 1.2.3_2 x11/libXtst libXv 1.0.11_2,1 x11/libXv libXvMC 1.0.12 x11/libXvMC libXxf86vm 1.1.4_3 x11/libXxf86vm libdaemon 0.14_1 devel/libdaemon libdrm 2.4.107_1,1 graphics/libdrm libedit 3.1.20210216,1 devel/libedit libepoll-shim 0.0.20210418 devel/libepoll-shim libepoxy 1.5.9 graphics/libepoxy libevent 2.1.12 devel/libevent libffi 3.3_1 devel/libffi libfontenc 1.1.4 x11-fonts/libfontenc libgcrypt 1.9.4 security/libgcrypt libgd 2.3.1,1 graphics/gd libglvnd 1.3.4 graphics/libglvnd libgpg-error 1.43 security/libgpg-error libgsf 1.14.47_1 devel/libgsf libiconv 1.16 converters/libiconv libidn 1.35 dns/libidn libidn2 2.3.2 dns/libidn2 liblz4 1.9.3,1 archivers/liblz4 libmspack 0.10.1 archivers/libmspack libnghttp2 1.46.0 www/libnghttp2 libnotify 0.7.9_1 devel/libnotify libpaper 1.1.24.4 print/libpaper libpcap 1.10.1 net/libpcap libpciaccess 0.16 devel/libpciaccess libproxy 0.4.17 net/libproxy libpsl 0.21.1_3 dns/libpsl libpthread-stubs 0.4 devel/libpthread-stubs librsvg2-rust 2.52.3 graphics/librsvg2-rust libsecret 0.20.4 security/libsecret libsigsegv 2.12 devel/libsigsegv libsoup 2.74.0 devel/libsoup libssh2 1.9.0_3,3 security/libssh2 libtasn1 4.17.0 security/libtasn1 libtextstyle 0.21 devel/libtextstyle libtool 2.4.6_1 devel/libtool libunistring 0.9.10_1 devel/libunistring libunwind 20201110 devel/libunwind libuv 1.42.0 devel/libuv libwpe 1.10.1 www/libwpe libxcb 1.14_1 x11/libxcb libxkbcommon 1.3.1 x11/libxkbcommon libxml2 2.9.12 textproc/libxml2 libxshmfence 1.3_1 x11/libxshmfence libxslt 1.1.34_2 textproc/libxslt libyaml 0.2.5 textproc/libyaml llvm12 12.0.1_6 devel/llvm12 lua53 5.3.6 lang/lua53 m4 1.4.19,1 devel/m4 mesa-demos 8.4.0_3 graphics/mesa-demos mesa-dri 21.1.8 graphics/mesa-dri mesa-libs 21.1.8 graphics/mesa-libs mkfontscale 1.2.1 x11-fonts/mkfontscale mpc 1.2.1 math/mpc mpdecimal 2.5.1 math/mpdecimal mpfr 4.1.0_1 math/mpfr neofetch 7.1.0 sysutils/neofetch nettle 3.7.3 security/nettle ninja 1.10.2,2 devel/ninja nspr 4.32 devel/nspr openjpeg 2.4.0 graphics/openjpeg opensbi 0.9 sysutils/opensbi orc 0.4.31 devel/orc p11-kit 0.24.0 security/p11-kit p5-Authen-SASL 2.16_1 security/p5-Authen-SASL p5-CGI 4.53 www/p5-CGI p5-Clone 0.45 devel/p5-Clone p5-Digest-HMAC 1.04 security/p5-Digest-HMAC p5-Encode-Locale 1.05 converters/p5-Encode-Locale p5-Error 0.17029 lang/p5-Error p5-GSSAPI 0.28_1 security/p5-GSSAPI p5-HTML-Parser 3.76_1 www/p5-HTML-Parser p5-HTML-Tagset 3.20_1 www/p5-HTML-Tagset p5-HTTP-Date 6.05 www/p5-HTTP-Date p5-HTTP-Message 6.33 www/p5-HTTP-Message p5-IO-HTML 1.004 devel/p5-IO-HTML p5-IO-Socket-INET6 2.72_1 net/p5-IO-Socket-INET6 p5-IO-Socket-SSL 2.072 security/p5-IO-Socket-SSL p5-LWP-MediaTypes 6.04 www/p5-LWP-MediaTypes p5-Mozilla-CA 20211001 www/p5-Mozilla-CA p5-Net-SSLeay 1.90 security/p5-Net-SSLeay p5-Socket6 0.29 net/p5-Socket6 p5-TimeDate 2.33,1 devel/p5-TimeDate p5-URI 5.10 net/p5-URI pango 1.48.7 x11-toolkits/pango pciids 20211028 misc/pciids pcre 8.45 devel/pcre pcre2 10.39 devel/pcre2 perl5 5.32.1_1 lang/perl5.32 pixman 0.40.0_1 x11/pixman pkg 1.17.5 ports-mgmt/pkg pkgconf 1.8.0,1 devel/pkgconf png 1.6.37_1 graphics/png polkit 0.120 sysutils/polkit psutils 1.17_5 print/psutils py38-cairo 1.18.1_2,1 graphics/py-cairo py38-gobject3 3.38.0 devel/py-gobject3 py38-ply 3.11 devel/py-ply py38-setuptools 57.0.0 devel/py-setuptools pygobject3-common 3.38.0 devel/pygobject3-common python38 3.8.12_1 lang/python38 qemu 5.0.1_2 emulators/qemu readline 8.1.1 devel/readline sdl2 2.0.12_7 devel/sdl20 shared-mime-info 2.0_2 misc/shared-mime-info source-highlight 3.1.9_1 textproc/source-highlight spidermonkey78 78.9.0_3 lang/spidermonkey78 sqlite3 3.35.5_4,1 databases/sqlite3 tcl86 8.6.12 lang/tcl86 tex-kpathsea 6.2.1_2 devel/tex-kpathsea tiff 4.3.0 graphics/tiff tpm-emulator 0.7.4_2 emulators/tpm-emulator trousers 0.3.14_3 security/trousers u-boot-qemu-riscv64 2021.07 sysutils/u-boot-qemu-riscv64 uchardet 0.0.7 textproc/uchardet valgrind-devel 3.18.0.g20210323,1 devel/valgrind-devel vde2 2.3.2_5 net/vde2 vim 8.2.3570 editors/vim vte3 0.64.2_1 x11-toolkits/vte3 wayland 1.19.0_1 graphics/wayland wayland-protocols 1.23 graphics/wayland-protocols webkit2-gtk3 2.34.1_1 www/webkit2-gtk3 webp 1.2.1 graphics/webp woff2 1.0.2_4 devel/woff2 wpebackend-fdo 1.10.0 www/wpebackend-fdo wx30-gtk3 3.0.5.1_1 x11-toolkits/wxgtk30 xauth 1.1 x11/xauth xbitmaps 1.1.2 x11/xbitmaps xcursorgen 1.0.7 x11/xcursorgen xkeyboard-config 2.32 x11/xkeyboard-config xlogo 1.0.5 x11/xlogo xorg-fonts-truetype 7.7_1 x11-fonts/xorg-fonts-truetype xorgproto 2021.4 x11/xorgproto xterm 369 x11/xterm zstd 1.5.0 archivers/zstd europa# I have to go out on a limb and hope that pkg works again. Thank you for the help Sir! Dennis From nobody Tue Nov 30 02:45:19 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 41FA018C0BEB for ; Tue, 30 Nov 2021 02:45:33 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-25.consmr.mail.gq1.yahoo.com (sonic311-25.consmr.mail.gq1.yahoo.com [98.137.65.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 4J365l3dX3z4jG5 for ; Tue, 30 Nov 2021 02:45:31 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1638240324; bh=NZ5feNB1tJSgMFkgAnoWjuGx4UfFxZqkSA3fB1ozkQ0=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=phsu+rNkHpBPN9aJsuUKeC5sYjQsMty+fmosjMgHWx4kjF6m2aHudtqvTU/Tpfe7/mvUqzW/warBqNYp4V/rXghSj4y8rR9BKRzo3ledNsmSWTysmiBAvkEt0rvGj6e66MLwrLAbx0cIG7Byiz1dXmIY6R8i3avtPjufe/RzHmSocK6LUNcUx9tDuUFX+9uQiDGEt3Tw8cCWXwUnCRE/JfYqw+FTAk1uTBmQ7EDmW7yjmCh+Ay0Noo9eqUeg+mWcfu9/PNMXYTnrsIK7aHarCRVhvQaZ9TtqHTkq9YBPXVRcxJfqciOOSBWNUvwg73TdMW85sqLXeAHrgwJbNbaX3w== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1638240324; bh=B374dWFOEVk/xuzuzv4FL4QHitjZzV6cLRcHzvPUFGz=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=thsVUhI9Cg+vCMFp0xkKDLHyaE7XeZHgwu0c+9/Frum5uRGzVf7BxFZteVDglIYmSnpKGOQlfE6y7MHh3TpuMmzr7dNYJD7iF/6Whe+CFK1vUA04lWiAbaPdc1HOo9XRfVluR65eEJEDSS8ogdjNGE/7Ih99/HKDaVv1wpW1VPMi7lVJIH3vibkKKs8SFkqYPpwvb6mny+xzgaunC8pNWfEWChBFpXxOKkEcF3IBMmBM8x/uRQ25W3FVUVm2bv4DYHPoZLeBVkN2czrpj3d8t9BkEk/g2o+zXRwqGPqPGRsftNfRPGB21QrbMdZ6spZXsICn2zAfy+EPNYr2HVygnQ== X-YMail-OSG: HMp.IKgVM1nXwhE8cYFAAjArceKW8Jadup_c1kmHZ9ExgwWgaHjjTlwODMn7O9m Wmzi.iNe7aGBbJnbCLAzPS5pkBRgphSfMs.Y0m0cvzh5AVlh2FMW4TdJRz0zAe9fGozyGbHBxfzp jr3LxG8keo9RsN.8ZNWiR94DJh9o.fl0wQAPSou.noVJG8MITz.kssk4DutlWEOJCHpeg6oTP9Zy FwQqpMLQONKQib_wKa_s.a34RtExApmbt0NnHmmuhB4pnsbLg1Pp9Z1ViA8Ko1eUDwBuEBUD.dEe E5UkoVmG8Q1vw55gkLdws9o5ccRFGokEAWhBkswhpXWb76Yw8DTo7Ju4JwpvIib0EFxGmHINhqXY 1A7CD1kEjoaPxfmJ5La6VQ20dPITOhnj2Yd0Ulp4BlDKevovSxg_LeRsD4u..wMl6xH3vgu0J8pc HOOfnTaiM4r2i5kzCImGDk9TDzHt4UIsiZ4mFsewFhYAE1LaN9XfygB9wUJ7Xi6MYwZJO5hY3IUC tdbshrnBdHRyVpYjd.sKGFLbb9DS6yZbSyZ.qPXBAXHbm8VNf_0LfCv_qWk7WTLHlb05nH0xa7h7 DCZYyVkQKbxV.WO0lnM7n_Bp5IFFlL22waNPxcZmfKT9esE376JnwdFPpT.ytzcWvxAXVtZ7ysjs 9xLx4buODl7bMPn9xH7ksOXgUXJUadxG.H0OZag0pdBZIziEkxm1rFurOxISLOCkDt.NPXol8IaP SlSeDFy0z_Uiv2DeIbJC1_qG.KLJLkLUpwEomCXxA9F_JG2FAsvFXizt9m_YgVCAlskbw9m2gxvq KUzZ8pdkp4T5qqYNACw_SKoq1AaoEvJT4sbfNKActljAZPrOURrxONoZzMhM65jblsFD2G7x_kNY kXLgAtsI7IFq_WHOOiGe.5j2O5.md6I8aMyYbIN3i4M0y65uVt2nR9QnVjBaem5vbnt7iDzl9FQd xXNiJyr9Rwb8QHVRMgQqaeASYI8v7Mrq29aVjLb5JJlwT4YGA7P8INuqBZ2mXYwVhjYCLu2UNKLH lEWkhFq17tQPMKXlSFznskuxjkgtRwGI1deICfWgNdiULfoRWVtkcndiZDaFnpEHPlQN0Wq2y8hU VLTXGdoL5hNBMoZd42F9B8vAtUWcjULxo2m6AjH1nxfEsVAIGJ1V96lLlP3NfTW06siYhyPQD8sg oZvjC.lv9uCBsiyy4rNzUfWIx68cbXQQJgPHPvZ0aEEAzgEKs9XxoiGCqo56ttyly_t.3ovd9hY3 yoa37GhhkhwgvAfGmZS98hJNLrjDUG9P7vyahf8TOUaZllGOpZornj9YoYSK19Q68bCkssg1b8JY bpQs3jAQY..2CVqXakZGXfBO69KwKS2ZTpne75IPk7MJeWTmFh1QYW2dhylRv3B_k1.R30vWwEum .TcJoYaRSx2PblcjdfukRLgka02udd0cCLT3FzEYoPvEs13qW6Che3HQ817rizWGjVIozEXHmUHe Bf.hDRTJTzIBHlC1hlASDwVmsyMwiB2ENFNiVR..mAZSWeBrIfowc7X9FvHUaOH17MJs_qe5szx9 2nDfkcp_O7Lx69uH6ZnxB9kdNHKOFeE92yBwW6zQfBFKepQbK0TypI2IzqkKGiSEls8FEhCCiItE osw8kf0cgGRw7yg0wdbeFSk_XjLoOx_vX2zTM0.Vibj5cSPwRtTXQtnsqSeHh..h0wdFQboCgLtU orHkUxmYAN8MJVIw3cHCRGfaaLPlnU_G8WlXtt7e4PQOD86KyQ6esqG8CBBmhWrYE3AMxOiYKy5E Wib.v1q8DWOaBAvD1PSA61zRpJqvrLDDPPJSqBMZmgPJlfGacdT3zcWOtmKfQRtmF9HdiZG.Fi5N BbJhszplvWctvxN5jPZhO5BPrpUuVg4HgJZua4W8E5OMwQkDqqkufpZHWmGvV2xkpIiMIzdpRSH8 hC54cfChkDwcpt02Or7iFhC6tos9TMYH6sLq6bY0pz2lLpSsA6gFQkA72Od.yB.TC4KbBeHSDWaW N6u8ntaGP9Gnkpnt8kGF4bamVe.dW3xla4OWnaz7iDAZNMkwyQ0SdLJ_11qoCw_xkGp_dc1flJsI fAEl6O3lboZZ4dY1JAB8g3fAYJs2MpFkXbpnyHPGT.8OWeIulDMz1cpah4kxNwFYR5Y_VXmh0EHH B_SWEJaSle91YHAWMPVdkOPxYxIgs7sCBrmHFYT6tkkT9JeqsaPipUnbW2WLAFgy07Hu5yX9j81z 2j_IzwVX3p.7KNgXNR.l92J5y6cjzz3mm_y1Fzch.RhfYessklR6rYXtb3wcH.bDXPOHt85vi1oT 7X9jGk0NOCL8- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Tue, 30 Nov 2021 02:45:24 +0000 Received: by kubenode514.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID baca60a59644174f7603f3f4ad56ac34; Tue, 30 Nov 2021 02:45:22 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: FYI: aarch64 main [so: 14] buildkernel (debug): ctfconvert: failed to get mapping for tid ????? Message-Id: <47D56092-308F-42DD-94A7-5CA9F3ED6997@yahoo.com> Date: Mon, 29 Nov 2021 18:45:19 -0800 To: Free BSD , freebsd-current X-Mailer: Apple Mail (2.3654.120.0.1.13) References: <47D56092-308F-42DD-94A7-5CA9F3ED6997.ref@yahoo.com> X-Rspamd-Queue-Id: 4J365l3dX3z4jG5 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=phsu+rNk; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.18 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.68)[-0.682]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.206:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.206:from]; RCVD_COUNT_TWO(0.00)[2] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N For: uname -apKU FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #22 = main-n250972-319e9fc642a1-dirty: Tue Nov 23 12:25:36 PST 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400042 1400042 building a variant of itself (producing a debug build instead of a non-debug), it generated a bunch of messages of the form: ctfconvert: failed to get mapping for tid ????? in the buildkernel part of the build. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Tue Nov 30 06:01:09 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id D6C7718BB806 for ; Tue, 30 Nov 2021 06:01:25 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-54.consmr.mail.gq1.yahoo.com (sonic307-54.consmr.mail.gq1.yahoo.com [98.137.64.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 4J3BRm17LXz4qnS for ; Tue, 30 Nov 2021 06:01:24 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1638252083; bh=8kZa8mRNCrN4yJ/YS+95ZpBYLH/BlJVvV6IPUAGPSfo=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=Bpbx4H9pR9xF3luQu0kzsoieb+0ZNrIrengKsh3ROeHROX22Iy3Jj07xB1qX4Su3S69Rp3xaNdSVeCmBmOl7UgNQblqG6HDwLZy9xGsELYjmZMB+eH2dWgLAvzFuTK+fW0NS1T0A48eMAppArdoJ9+alZK4TfWdiiF03CdpKq0pJgDSTnRaP6+5vLv4kSvK+lazsq0aWvuSyT+blIah04rT9CaGeH9LpfR0hIw8+LjT86pWKzXgaKCBQhEKF6x7MdpmRe5oL5HDq/ZuyLaUFyhDv6y5oNCAcNvLjMOh4GZ+WWa+1AqZg0eoXCEfoxP9rExd/ZRpc/XN1dYyyWbCmGg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1638252083; bh=ag6vP7kJHxviytLmt2mYIUeG7NfQtqfQn+wOK3U5qkp=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=kFp/32byImJ7f/nABEu5GkhnM1A5Tv4nnGyINtjwh54k+XlFT+ZWk28id1leFBbux0z8e0KVWzzwx1q4/YA5dFCWt8oJkQ5bdE/nz5muyN5piQ+H8uHlVUIqxY6ghkp/Q539kfstiJwyk765ufdWHjI+tydMmlOdy0LvDm1btduCeioFU8bbI7MRoXLnu+MiBL8vg/h3RONIgz7n2i2BBcdHaDOWGt0XLQbRbLF8DF3IYa5Ui6HFrfs7eK6+pQZTgJe43ormssNTxwaoix1kJmFIJ7Q/PXwv0DlJq+Qtkfx4eTXAtSNgqframyMeNRvUzlHrX1+FHXaHjD8CTUw5FA== X-YMail-OSG: 9GXXCuQVM1lQ3mXPQpDfKuOw2g5k6n30PnscfYQBMJmyJNQtIDYYvVctHGrsHYj bqL7XmeaZ4GFzCiJc9bCUnjONh0uqtDvp3msZ2iRPBAf0YnrWvg7gippKibex3arOUMewQQ.r32d h39GI7ND6uc9OF9ci40EEDmdXKY1p1cxIJVR4gTHP9eX3xD8kPJc64tt3pth42aH0e5RK3EvLaaO uAWeVNs5xdqRucS_5ahaeSNvhg84u9CI_dNZ7JbKfdg3ucCrGyif5RZKz20Ko_C.VgcW0r8yqsgB y71_7k1BVxKpfMHXleKEtLUqzOlObwJ6xcBsgprCarZAoYd_VSTKwQLisjPRNa0nQ7Spkd34sIxT lVUTi5hKdFa.ERQCV6VsOHmMLzqgcdRLIfYG5lQnCgjvJnjt6YpPPTcPRDMBpOxDO8NIA229B4Zb KfSr.zXmYGmKvuheWL7ZOyFufXs1EZ0Cz_bbBbyebD0Jm.M9nu7dIy0KMLhCQcXnorNNOI2ezBHv zr4B7eUKuyoZVn.uhEU69mD38rBNaRLWzfB40Rb7dyOcVOb2q3ipsdJa2Qia.kAGIzDFBUy9w6wT 4G4NyUQCTLSWIYihpIWKRAz0lDfFBIvUpy7j8rKoZWZNiXsQEiusJ1JDXWfxjBpK8IQGLykQgaIE eDVa3nsBoma65fsbozAb41ZSSp_xmrgYiicDbrdOj2T_VmrOKtLlvM21x4eQ5RVQ2MBjQAlCl2T2 YV1F3MqxDOrjjUVLe349NvBISJW0Za7WxPZMZb9xhjmGlOxcmjlvvZuy9rV0iaEAS_eWN0SkuZv0 vNVkHU6ocCADs4QI5D7WlHJeXqJYPwzPWyIGy2buXFe2VubAgw9dvGHVoko6v8_MseGFj1Zu2Sv3 lvxAOYEi3IT6NzVGAUOqklyZaSNMuNGNUw.oi6QaFPtp68QfP2w046W.9jCaTgbYzacWDguSozDi iEvNTsIQnPM85Fp7DXCbah0Gu3YpyYv0NHioWll7Kql_QvHZaysbnayaEHgt.PhVGs.D1YGwVDuS zbZiIIYbp9wNVhi0ph6cGzY9zGWP5pR.mSzVW8wumqUtcuYaGJAFn5G0XrlnA.U0xqCbKJeTs.yt d1TGjE2efMiEnwsXVYZirmiBS.8_2htoS.4hX8JVzbJO99acQoXKffca7FXXLHNDllfXZGA3N2Dv 5Y6cJHs1AsujV9brFBrhvevP76AJw1Hhw0hIfmzlC1l.Wia5PGHPX6p9aPnwUjzmVdjFLfGzllgW 8bYm_OpJ0RNMSHs9k9iDlzbboEM21PZAd5sth.peJPQG.EDBYcj4YsPmRC8luBSXuwBo4pZMhV.x Yuo9vtmVmIwtJY9REC5SfHIg.8ZosccdBatd4dbfBcvxk0ot9Wg7bayU43vLzSY4g31nxRQqIC47 GObVbxmAe63thTmrNjdWydc6spD.7aIBxS2G3LWix6mN.g4_5xPGAUTJF1Ip.fznqKSn1xtVywKh qTAg.F.qJcUyMWaWZJdjPiIh.afmzZ.s6e3pxz92_0Y6.FK9_PBeIW6DYTcLAlQk4ETeY0i6m77Y 2G5ntTsPYGJ9blvJ3GgrQRGfM.LZ1ZIJ1BXHYx.AKftDX1brNliyDe0prNJHqeKQK9LXGXoB6qSd nI0QS7mKDg8cOUyAWrwmviOaWE53dtQ_t7fMa4kO5nSB5DbAOVzy3R549CRO7MljzIWZtewh6Q2p mx7HyBrXKpI4gU_yo.JZWLpvmche1rw_HLaqIKe.TFw2CJJcgS8h7gq3DwSCm0ZKBgfZIx9836SO XTLwHeA25canaW4ppjR.NVCQleCXgnqCAy.cxG7A3fflFwKdkgfq1_J6xq7I04ry8MTQ3NtkQpw0 f_W7QkR2D7Y2xNoLtSIa_LC0bZ.5kEqOMsPFZI8jh2WEceOcB0.tdgsf0DGOf7gJnoa8WYsb1aCk 66.6UuSaqA6m6QlsdENQjimwspRuzzlomL0U5z4SApBDSCHcQPxc8IAeZ70x1nhT9BHGOUwUbXGZ qi6k7hUFQ4wf_IHxM_NSaYQfdsH.xdPnMPXRbpFuJjTJ6GmVHSzcAJRfIfSDGurBE3Aegm7fLYLw zb3lbRLWiyEb51mOfRSOHlG4OibDg3P5.KT.bOdHdDLZ_KDyxGdVuwtAA7ZFTarOJAb4jfUV9ZQo SJblP5uPqycvOS1uXbBj5..dNEESqNIDIwqb0TsLk6HtrU6i_ZJJaI6Vc_qUjNH2mrGtICk2xi.G 4vcWHZ6DDNw9pn4_u4jM1391.VEkjRO5_Y8fciskim98xkyAhSLrHY40FmDCRNA3h5mJKK3CsIOE Dp4dFj_Vbw1hBtwmm_g-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Tue, 30 Nov 2021 06:01:23 +0000 Received: by kubenode548.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 35c130540ac9484e6dd0a86c2d74045f; Tue, 30 Nov 2021 06:01:11 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: FYI: aarch64 main [so: 14] buildkernel (debug): ctfconvert: failed to get mapping for tid ????? Date: Mon, 29 Nov 2021 22:01:09 -0800 References: <47D56092-308F-42DD-94A7-5CA9F3ED6997@yahoo.com> To: Free BSD , freebsd-current , FreeBSD Toolchain In-Reply-To: <47D56092-308F-42DD-94A7-5CA9F3ED6997@yahoo.com> Message-Id: <7B9D3178-029F-46F7-AD3B-9C668CB4CB73@yahoo.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4J3BRm17LXz4qnS X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=Bpbx4H9p; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.30 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.57 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.97)[-0.971]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; NEURAL_SPAM_SHORT(0.90)[0.904]; RCPT_COUNT_THREE(0.00)[3]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.30:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.30:from]; RCVD_COUNT_TWO(0.00)[2] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Nov-29, at 18:45, Mark Millard wrote: > For: >=20 > uname -apKU > FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #22 = main-n250972-319e9fc642a1-dirty: Tue Nov 23 12:25:36 PST 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400042 1400042 >=20 > building a variant of itself (producing a debug build instead of a > non-debug), it generated a bunch of messages of the form: >=20 > ctfconvert: failed to get mapping for tid ????? >=20 > in the buildkernel part of the build. >=20 There were 98 unique tid values complained about. (The contains a hexadecimal representation.) : # grep "ctfconvert: failed to get mapping for tid" = /usr/obj/BUILDs/main-CA72-dbg-clang/sys-typescripts/typescript-make-main-C= A72-dbg-clang.aarch64-host.2021-11-29:11:34:15 | sort -n -k9 -u ERROR: ctfconvert: failed to get mapping for tid 174 ERROR: ctfconvert: failed to get mapping for tid 245 ERROR: ctfconvert: failed to get mapping for tid 259 <103> ERROR: ctfconvert: failed to get mapping for tid 267 <10b> ERROR: ctfconvert: failed to get mapping for tid 275 <113> ERROR: ctfconvert: failed to get mapping for tid 289 <121> ERROR: ctfconvert: failed to get mapping for tid 333 <14d> ERROR: ctfconvert: failed to get mapping for tid 425 <1a9> ERROR: ctfconvert: failed to get mapping for tid 435 <1b3> ERROR: ctfconvert: failed to get mapping for tid 482 <1e2> ERROR: ctfconvert: failed to get mapping for tid 1120 <460> ERROR: ctfconvert: failed to get mapping for tid 1155 <483> ERROR: ctfconvert: failed to get mapping for tid 1318 <526> ERROR: ctfconvert: failed to get mapping for tid 1671 <687> ERROR: ctfconvert: failed to get mapping for tid 1809 <711> ERROR: ctfconvert: failed to get mapping for tid 2416 <970> ERROR: ctfconvert: failed to get mapping for tid 2538 <9ea> ERROR: ctfconvert: failed to get mapping for tid 2715 ERROR: ctfconvert: failed to get mapping for tid 3107 ERROR: ctfconvert: failed to get mapping for tid 3650 ERROR: ctfconvert: failed to get mapping for tid 3868 ERROR: ctfconvert: failed to get mapping for tid 5151 <141f> ERROR: ctfconvert: failed to get mapping for tid 5342 <14de> ERROR: ctfconvert: failed to get mapping for tid 5499 <157b> ERROR: ctfconvert: failed to get mapping for tid 6075 <17bb> ERROR: ctfconvert: failed to get mapping for tid 6081 <17c1> ERROR: ctfconvert: failed to get mapping for tid 6171 <181b> ERROR: ctfconvert: failed to get mapping for tid 7775 <1e5f> ERROR: ctfconvert: failed to get mapping for tid 8674 <21e2> ERROR: ctfconvert: failed to get mapping for tid 9144 <23b8> ERROR: ctfconvert: failed to get mapping for tid 10608 <2970> ERROR: ctfconvert: failed to get mapping for tid 10638 <298e> ERROR: ctfconvert: failed to get mapping for tid 10794 <2a2a> ERROR: ctfconvert: failed to get mapping for tid 11190 <2bb6> ERROR: ctfconvert: failed to get mapping for tid 12040 <2f08> ERROR: ctfconvert: failed to get mapping for tid 12131 <2f63> ERROR: ctfconvert: failed to get mapping for tid 12232 <2fc8> ERROR: ctfconvert: failed to get mapping for tid 12266 <2fea> ERROR: ctfconvert: failed to get mapping for tid 12293 <3005> ERROR: ctfconvert: failed to get mapping for tid 12604 <313c> ERROR: ctfconvert: failed to get mapping for tid 13072 <3310> ERROR: ctfconvert: failed to get mapping for tid 13622 <3536> ERROR: ctfconvert: failed to get mapping for tid 14453 <3875> ERROR: ctfconvert: failed to get mapping for tid 14981 <3a85> ERROR: ctfconvert: failed to get mapping for tid 15104 <3b00> ERROR: ctfconvert: failed to get mapping for tid 15810 <3dc2> ERROR: ctfconvert: failed to get mapping for tid 16006 <3e86> ERROR: ctfconvert: failed to get mapping for tid 16222 <3f5e> ERROR: ctfconvert: failed to get mapping for tid 16627 <40f3> ERROR: ctfconvert: failed to get mapping for tid 16633 <40f9> ERROR: ctfconvert: failed to get mapping for tid 16849 <41d1> ERROR: ctfconvert: failed to get mapping for tid 16867 <41e3> ERROR: ctfconvert: failed to get mapping for tid 17327 <43af> ERROR: ctfconvert: failed to get mapping for tid 19216 <4b10> ERROR: ctfconvert: failed to get mapping for tid 21146 <529a> ERROR: ctfconvert: failed to get mapping for tid 21200 <52d0> ERROR: ctfconvert: failed to get mapping for tid 23011 <59e3> ERROR: ctfconvert: failed to get mapping for tid 23472 <5bb0> ERROR: ctfconvert: failed to get mapping for tid 25993 <6589> ERROR: ctfconvert: failed to get mapping for tid 26074 <65da> ERROR: ctfconvert: failed to get mapping for tid 26800 <68b0> ERROR: ctfconvert: failed to get mapping for tid 28333 <6ead> ERROR: ctfconvert: failed to get mapping for tid 30366 <769e> ERROR: ctfconvert: failed to get mapping for tid 30798 <784e> ERROR: ctfconvert: failed to get mapping for tid 32196 <7dc4> ERROR: ctfconvert: failed to get mapping for tid 32547 <7f23> ERROR: ctfconvert: failed to get mapping for tid 33724 <83bc> ERROR: ctfconvert: failed to get mapping for tid 34990 <88ae> ERROR: ctfconvert: failed to get mapping for tid 35109 <8925> ERROR: ctfconvert: failed to get mapping for tid 35984 <8c90> ERROR: ctfconvert: failed to get mapping for tid 36204 <8d6c> ERROR: ctfconvert: failed to get mapping for tid 36222 <8d7e> ERROR: ctfconvert: failed to get mapping for tid 36393 <8e29> ERROR: ctfconvert: failed to get mapping for tid 37769 <9389> ERROR: ctfconvert: failed to get mapping for tid 37788 <939c> ERROR: ctfconvert: failed to get mapping for tid 37961 <9449> ERROR: ctfconvert: failed to get mapping for tid 38207 <953f> ERROR: ctfconvert: failed to get mapping for tid 39642 <9ada> ERROR: ctfconvert: failed to get mapping for tid 39935 <9bff> ERROR: ctfconvert: failed to get mapping for tid 42787 ERROR: ctfconvert: failed to get mapping for tid 44571 ERROR: ctfconvert: failed to get mapping for tid 45582 ERROR: ctfconvert: failed to get mapping for tid 45687 ERROR: ctfconvert: failed to get mapping for tid 48695 ERROR: ctfconvert: failed to get mapping for tid 50964 ERROR: ctfconvert: failed to get mapping for tid 51801 ERROR: ctfconvert: failed to get mapping for tid 53177 ERROR: ctfconvert: failed to get mapping for tid 54249 ERROR: ctfconvert: failed to get mapping for tid 55356 ERROR: ctfconvert: failed to get mapping for tid 55795 ERROR: ctfconvert: failed to get mapping for tid 55825 ERROR: ctfconvert: failed to get mapping for tid 55913 ERROR: ctfconvert: failed to get mapping for tid 56821 ERROR: ctfconvert: failed to get mapping for tid 59783 ERROR: ctfconvert: failed to get mapping for tid 66038 <101f6> ERROR: ctfconvert: failed to get mapping for tid 66581 <10415> ERROR: ctfconvert: failed to get mapping for tid 68585 <10be9> ERROR: ctfconvert: failed to get mapping for tid 95223 <173f7> Is there an implication of a problem with the kernel built? If yes, what is the way to make the existing system build an appropriate kernel (as part of getting past the problem)? =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Tue Nov 30 13:00:37 2021 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 2FD8318B7D55 for ; Tue, 30 Nov 2021 13:00:41 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J3MlX72Kjz3N32; Tue, 30 Nov 2021 13:00:40 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from [192.168.0.88] (unknown [195.64.148.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: avg/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 77FD95595; Tue, 30 Nov 2021 13:00:40 +0000 (UTC) (envelope-from avg@FreeBSD.org) Message-ID: Date: Tue, 30 Nov 2021 15:00:37 +0200 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Firefox/91.0 Thunderbird/91.3.0 Subject: Re: ctfconvert: rc = 1 Unsupported version [_dwarf_info_load(229)] Content-Language: en-US From: Andriy Gapon To: Mark Johnston Cc: FreeBSD Current References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1638277241; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=lkYrXWax8znU1B5Zd/S8xDeSi7tjQxzxck2BMngrfzM=; b=LSl9RFl9LySSZBor1C8E30yxtR9br5QB4qVbqHm2RfwyiQlBAR8Du6O6DP2i7vhrCtIjSO jY6KLPZBnSpCckShoaj8swHmnt06Gphoo4dKnS+z/NOmPMfe2kMGFebX+cVfvA4JUGXKz8 TYfkdQTvUCkkEJbxXSjLTAka3lwxpWimn2B4PJi9HMqoZVJTQr7DZqnpolF7MZ20letYeS dRaaiEE4UDUaRFWcbWMfiNaAzprGADXJL0zkyKDXvf3JKa1eriC4TvgjrnxCza4iDB3k33 /r1H42v+CygLFKlAwlJIxi1yipLNYh5wFuctz47jaGCkLvjbmTTl/9Q67wkjeQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1638277241; a=rsa-sha256; cv=none; b=OUR/0YZ20DgtoO4ych57pBAf+pUh/9/h9y2oaWaZcwhvQLpjYvxxBGjKNcxy04N0FT7nCv CJAoz8kuIi0cm6jr+6+5JxzL776utpvcDgLow2aV0E+EAueGnLgqoi15pGWyCBxUcCGd0k dNG7Rf5gyMV0J57nH/7CfWC5U8BM6NOIEwo7PoxlINjBk/zsS3+ylwLdqymsaJl37vqbjA awBFy3jNLUEGG4OHJsgWobdGytL3Tzff23YI/HjvMMUQyRm7tnpSeShGFUdqmAtDF2U6rv 9iPS8KGobkkVfnYfx8ZMh0tyigrKkDKyYdiI+7IPfZR6edHnO/wFro8E0nDvSg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 27/11/2021 10:42, Andriy Gapon wrote: > On 26/11/2021 21:48, Mark Johnston wrote: >> On Fri, Nov 26, 2021 at 02:00:27PM -0500, Mark Johnston wrote: >>> Thanks, I can reproduce it now. >>> >>> Our libdwarf is complaining that the first compilation unit header in >>> .debug_info contains an unsupported DWARF version number (libdwarf only >>> supports 2, 3 and 4).  In files compiled by clang it ends up being zero. >>> For instance, compiling bin/cat and dumping the .debug_info section: >>> >>> gcc10: >>>   c1250000 04000000 00000801 00000000 >>>             ^ DWARF version >>> clang: >>>    01000000 00000000 4e230000 00000000 >>> >>> llvm-dwarfdump and binutils readelf are somehow still able to find a >>> valid-looking unit header, but I haven't yet been able to figure out how >>> they do that from reading the DWARF 4/5 specs or the LLVM sources. >> |Ah, we recently started configuring clang to compress debug sections by >> default, and our libdwarf doesn't know how to handle that. As an interim >> workaround this could simply be disabled with WITH_CTF is configured: > > Oh wow, you were very fast at figuring this out. > Thank you very much! > > I'll give the build change a whirl first and then test D33139 a bit later. Tested both (individually) and both do the job just as expected. -- Andriy Gapon From nobody Tue Nov 30 17:24:45 2021 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 37E0618AF871 for ; Tue, 30 Nov 2021 17:24:58 +0000 (UTC) (envelope-from filippomore@yahoo.com) Received: from sonic305-21.consmr.mail.ne1.yahoo.com (sonic305-21.consmr.mail.ne1.yahoo.com [66.163.185.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4J3TcS42pVz4n2R for ; Tue, 30 Nov 2021 17:24:56 +0000 (UTC) (envelope-from filippomore@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1638293088; bh=NY1ks6BWT5cdweU3cWIUB7WqRbvk/YMHbm4jWg80yZw=; h=Date:From:To:Subject:References:From:Subject:Reply-To; b=lgWqt8mpRR452IsNSfyNQezB8/+bNz3W0JWDnQKjcTzpEsg3uNrh1DizgjEOMcffB9xGAj/Eocq6rwtSWXSihUuo7cTFdMGoNhPjSvDhXtI+A8M5idD928wzMN2GrYuz0HILqCuk/wZ1Fbg/nWC9Nq7qX+M4x5yCsgHHLWMZYSHURxdfp8oqCkcFPqM3n38SDPBinjg60y8b18ARiYYocTMLubOphqDJd6UoO6c2wYB3Y+19uFRUgVDMyJpxR2OW6RSzKK/U/pUaXC9rEf9mbZjVQI9K+AZuohm0XNDfdIrOhxvj90rfs/siJzAhWWvEyVfsoITqcW1Z9YlB0KIXuQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1638293088; bh=XPKIZbTfVBxfzjp7sAlEodqYkcGuAv5Ot58DzJhrV5c=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=V9Y5loMwh43YPFRqHoM/+r0MDpNoCr1hsHREK6/1jrhcM4Pj90A4/kBna5+Y/W5aRWinn/5NYMBRxS5iKZfBsnUK+Dz7SBZ3JO6OeAq4sgBAWex02r4lvAWBzGuH0bKzcgm/Xu/BrV8kqt7GGE0CljsuogqiMDNEU6gJM7y7W4MOubu9jMaWf/HxalpDsfqu67OuQYVDaPf/oTbQhomjKBfOReWtRPpWxTA1cpkLCsv2k1Doc8GnkDAE7oeQJaj4zwtqGzBhkPWcH0MnoWYItQ0eHsGy5CZhVFLadujGr/qboZGTW6WbMa1VmtQ5Wsej53hHZtYlnLz+GktJ5kSi0g== X-YMail-OSG: j6vH_CAVM1kTenyrq7EPv8ZsmULg_i3kHZTyBSSJdJtZAf0D_PwEaGhjo_MD1FT XUx7LcW_rk8KQWL4TdxdT.Z7vD8AGFBsa9fvoac25nhWdinLVbr275t58mSZBWPb4Cii0h5jWiLA NEM7zbS910MgLrzF8lUVD2osgvxzVbEYpiGJpcJXE.L6_6u_.FCTokJ.Uqg7NUeC5XuDVCF3bDUi HYr3UC0nLFHFPTYqfizenKWn.yjhyrsokI460CadwAu6JP6_xrr2z_hfjkOBbZdWI445qIBpfemC H7xv_ZWp0yPQIIvPOVwRY5HosnssI6XIqAzTZ6kVkvpXI7PnCKrQIsr5IiqDn_rvFYIIUGcJVeWF zDaBbi1.h2PZ73E5felj55KiNgHGMDd4bLq0euLZm9FrHHQ3WoEn.yTsd3gpLNyfF5pFPv7H_0vA mYOOO9agJVbnW2fgw8VSoztiTQdzNZr7vGu2HjpArYJGTuYvWLS3pncMyhyngCoocK6N1VFvPdm2 jAtZAn.EoZD1eJ5MyEXHZGCaegaRXnq38wHtXDnJczNjawwH7oCiw0ufLpaV_B9vu0yVV4Rv2EiS ACOuQhBI85P5KEgKqJL0.X.mCVWYh_G9aK.GGvAFaka_TKTObEj4uOejBf3sUDyi2bYo_o7Q7DJo d1.8lZE2rbHgVyXC3Ef0VHXGZmk7VZAr4aSPxZVT1mCyFuHYelRre0duESaiuvd4ByCY_Yl312eU mGHnzfGyoql4AlpyhIn6vG_HyyrlYjSCDnPnhPGnz8hCp_3bl9s5uUg9ZASLdukv6fGwFXYe9lB4 6nLIHXuDz.j22P_IqazvUaxgdvPCVQrggPpDs5aVX738SsydrElNLeo_tsdFJaXzpQqNha8i7Ftt nVVv00mjafLVA_zfz5oiONfH_9xeR6XgWprO4tbSwVvczeH7CqloTv9LzW1C_ZFrNXoZ5X7taii3 I0siSyTw3GaYUPOX1lVtDCMCvgy5G1P6.vv0ikkOvlatSkf7jZ5lRjRHsuC9V4ibvnaVhg3GzgrV lLSiJsUrcVfjBDZz1HRMth9hzEJVpxLesdE5gYbBnT5szLxe7SXIhrId6hyLnJuwtcBs3LWXefCZ YZYNJDUtGQ27hkABM3YlYbxtIlevnJ_vmRJ5zl45OCAStgZmKSCw8lj.wsuVq0MInWSq77SqNkng 0ehCygT_Ztk8zWutqFlDs5DZSiPeCvmVW1fj5VnI3Qt8EciTklH0u4y0QR.C4uy57xEScSZESgLl I1I4oo8McWBdttQnNJSdtvumMTdRStF7iHllSS_qG1O8gGXMrJ.bMMf7X1P2Gg0UnxbRe8NKBC5e tNtbnv5Yb_CrMRV_cILmvSk.Sq.M6FS_dmVtVY6kay_IQO3K1HVIh4Ypb1shIkOOGpyFycM_aoxb A.jd.urSCM44zS6X2LMN5vWdWQ3FLTwD3qkns_GOouC55lrkTf1eT3EKGqFZjXmukA4WKFMzcTu8 K1k5fMjSnLJJXFJJe0fRZQzfQwLSlB2tcx97zmoFhwZNLzYYcZrFeBoGZvaCVU4DC2UMpIopgaGD XPidPqoLDBWSmje0WQMPylaLBuecjzM96FYJU8xDhzH0kdvVJcOyvhMAa8pJBjBIdGzC_z47UVgw KtRPqHdo4lFVknc9AcHMs4J1Z6HrRDhMp4EBeM2PGkBCMtddU3lGKJHLwbNJH44_uGwjZMZobgjS HaaIbc4oMXMHxpvMkEh1WFMr5pU2pRBHhnD8Rp1QhYcSGFWQySqhcryErhAxZsA3W.yhh6J.19zv 1dyuG9L8OKvKEEcScGKK5Mjdf3GKL5kC28zm5cA.9vq.T7JSAWn3y6hHXTr2EQh29iK.v9.XOgvF 3gJyk_qbN_YveT8losjPDqBDikeIKHihbMPiwurCV4Ef5a7BEcmYxaV1inbVSyFuExCgZZC427nr _lhVjA69rmNBL026.YcOuheYYbgse9GUIdpkrZKDHHXNoCebtxnm4Rlxj3cagpSnnq5xdCgK_a72 CkkRzAA7nX1iOVRHVzx8hKT4sRWcEG78CtnETgQ_AJ5FlIzjCbGj7IHor5ccq4jAsNLcu1QnU00u 5NC16ddNDMdxT6FDkGvmKhJfbFzjY6XUo8yLYp1zBM.YlgLt5luyZlK9QGg5WJyQwoMFSU5U2mjA Higykn_oimxER_DIzUWWRCjzszu07tXpd2fSRQJEg54hKpMgk7BtRTd1XPlW0uw-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.ne1.yahoo.com with HTTP; Tue, 30 Nov 2021 17:24:48 +0000 Date: Tue, 30 Nov 2021 17:24:45 +0000 (UTC) To: FreeBSD Current Message-ID: <28612702.6783053.1638293085302@mail.yahoo.com> Subject: Problem compiling ports List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_6783052_1532962616.1638293085301" References: <28612702.6783053.1638293085302.ref@mail.yahoo.com> X-Mailer: WebService/1.1.19306 YMailNorrin X-Rspamd-Queue-Id: 4J3TcS42pVz4n2R X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=lgWqt8mp; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of filippomore@yahoo.com designates 66.163.185.147 as permitted sender) smtp.mailfrom=filippomore@yahoo.com X-Spamd-Result: default: False [1.72 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; RWL_MAILSPIKE_POSSIBLE(0.00)[66.163.185.147:from]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_SPAM_SHORT(1.00)[1.000]; NEURAL_SPAM_MEDIUM(0.72)[0.716]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCVD_IN_DNSWL_NONE(0.00)[66.163.185.147:from]; NEURAL_SPAM_LONG(1.00)[1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36646, ipnet:66.163.184.0/21, country:US]; RCVD_COUNT_TWO(0.00)[2]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] Reply-To: filippomore@yahoo.com From: Filippo Moretti via current X-Original-From: Filippo Moretti X-ThisMailContainsUnwantedMimeParts: Y ------=_Part_6783052_1532962616.1638293085301 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable error: unable to create target: 'No available targets are compatible with t= riple "wasm32-unknown-wasi"' 1 error generated. gmake[3]: *** [Makefile:380: /usr/ports/devel/wasi-libc/work/wasi-libc-ad51= 33410f66b93a2381db5b542aad5e0964db96/build/dlmalloc/src/dlmalloc.o] Error 1 error: unable to create target: 'No available targets are compatible with t= riple "wasm32-unknown-wasi"' 1 error generated. gmake[3]: *** [Makefile:440: startup_files] Error 1 gmake[3]: Leaving directory '/usr/ports/devel/wasi-libc/work/wasi-libc-ad51= 33410f66b93a2381db5b542aad5e0964db96' =3D=3D=3D> Compilation failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=3Dyes and rebuild before reporting the failure = to the maintainer. *** Error code 1 Stop. make[2]: stopped in /usr/ports/devel/wasi-libc *** Error code 1 Stop. make[1]: stopped in /usr/ports/devel/wasi-libcxx*** Error code 1 Stop. make: stopped in /usr/ports/www/firefox =3D=3D=3D>>> make build failed for www/firefox =3D=3D=3D>>> Aborting update =C2=A0File "/usr/local/lib/python3.8/site-packages/setuptools/dist.py", lin= e 799, in =C2=A0=C2=A0=C2=A0 eps =3D map(lambda e: e.load(), pkg_resources.iter_entry= _points(group)) =C2=A0 File "/usr/local/lib/python3.8/site-packages/pkg_resources/__init__.= py", line 2449, in load =C2=A0=C2=A0=C2=A0 self.require(*args, **kwargs) =C2=A0 File "/usr/local/lib/python3.8/site-packages/pkg_resources/__init__.= py", line 2472, in require =C2=A0=C2=A0=C2=A0 items =3D working_set.resolve(reqs, env, installer, extr= as=3Dself.extras) =C2=A0 File "/usr/local/lib/python3.8/site-packages/pkg_resources/__init__.= py", line 772, in resolve =C2=A0=C2=A0=C2=A0 raise DistributionNotFound(req, requirers) pkg_resources.DistributionNotFound: The 'packaging>=3D20.0' distribution wa= s not found and is required by the application *** Error code 1 Stop. make: stopped in /usr/ports/devel/py-pycparser =3D=3D=3D>>> make build failed for devel/py-pycparser@py38 =3D=3D=3D>>> Aborting update FreeBSD sting 14.0-CURRENT FreeBSD 14.0-CURRENT #62 heads/main-n251146-d109= 559ddbf: Mon Nov 29 12:18:48 CET 2021=C2=A0=C2=A0=C2=A0=C2=A0 root@sting:/u= sr/obj/usr/src/amd64.amd64/sys/STING=C2=A0 amd64 ------=_Part_6783052_1532962616.1638293085301-- From nobody Tue Nov 30 17:45:30 2021 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 2E20518BA42F for ; Tue, 30 Nov 2021 17:45:37 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4J3V4J70Fmz3C1Q for ; Tue, 30 Nov 2021 17:45:36 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 4C88B3C0199; Tue, 30 Nov 2021 17:45:30 +0000 (UTC) Date: Tue, 30 Nov 2021 17:45:30 +0000 From: Brooks Davis To: filippomore@yahoo.com Cc: FreeBSD Current Subject: Re: Problem compiling ports Message-ID: <20211130174530.GA75149@spindle.one-eyed-alien.net> References: <28612702.6783053.1638293085302.ref@mail.yahoo.com> <28612702.6783053.1638293085302@mail.yahoo.com> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AqsLC8rIMeq19msA" Content-Disposition: inline In-Reply-To: <28612702.6783053.1638293085302@mail.yahoo.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-Rspamd-Queue-Id: 4J3V4J70Fmz3C1Q X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N --AqsLC8rIMeq19msA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In the config for devel/llvm11, is BE_STANDARD enabled? If not, you won't have the web assembly backend. -- Brooks On Tue, Nov 30, 2021 at 05:24:45PM +0000, Filippo Moretti via current wrote: > error: unable to create target: 'No available targets are compatible with= triple "wasm32-unknown-wasi"' > 1 error generated. > gmake[3]: *** [Makefile:380: /usr/ports/devel/wasi-libc/work/wasi-libc-ad= 5133410f66b93a2381db5b542aad5e0964db96/build/dlmalloc/src/dlmalloc.o] Error= 1 > error: unable to create target: 'No available targets are compatible with= triple "wasm32-unknown-wasi"' > 1 error generated. > gmake[3]: *** [Makefile:440: startup_files] Error 1 > gmake[3]: Leaving directory '/usr/ports/devel/wasi-libc/work/wasi-libc-ad= 5133410f66b93a2381db5b542aad5e0964db96' > =3D=3D=3D> Compilation failed unexpectedly. > Try to set MAKE_JOBS_UNSAFE=3Dyes and rebuild before reporting the failur= e to > the maintainer. > *** Error code 1 >=20 > Stop. > make[2]: stopped in /usr/ports/devel/wasi-libc > *** Error code 1 >=20 > Stop. > make[1]: stopped in /usr/ports/devel/wasi-libcxx*** Error code 1 >=20 > Stop. > make: stopped in /usr/ports/www/firefox >=20 > =3D=3D=3D>>> make build failed for www/firefox > =3D=3D=3D>>> Aborting update >=20 >=20 > ??File "/usr/local/lib/python3.8/site-packages/setuptools/dist.py", line = 799, in > ?????? eps =3D map(lambda e: e.load(), pkg_resources.iter_entry_points(gr= oup)) > ?? File "/usr/local/lib/python3.8/site-packages/pkg_resources/__init__.py= ", line 2449, in load > ?????? self.require(*args, **kwargs) > ?? File "/usr/local/lib/python3.8/site-packages/pkg_resources/__init__.py= ", line 2472, in require > ?????? items =3D working_set.resolve(reqs, env, installer, extras=3Dself.= extras) > ?? File "/usr/local/lib/python3.8/site-packages/pkg_resources/__init__.py= ", line 772, in resolve > ?????? raise DistributionNotFound(req, requirers) > pkg_resources.DistributionNotFound: The 'packaging>=3D20.0' distribution = was not found and is required by the application > *** Error code 1 >=20 > Stop. > make: stopped in /usr/ports/devel/py-pycparser >=20 > =3D=3D=3D>>> make build failed for devel/py-pycparser@py38 > =3D=3D=3D>>> Aborting update >=20 > FreeBSD sting 14.0-CURRENT FreeBSD 14.0-CURRENT #62 heads/main-n251146-d1= 09559ddbf: Mon Nov 29 12:18:48 CET 2021???????? root@sting:/usr/obj/usr/src= /amd64.amd64/sys/STING?? amd64 >=20 >=20 --AqsLC8rIMeq19msA Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJhpmM5AAoJEKzQXbSebgfAG4EH/2mBcjNM0er9eTiS1pNo7W6v jin92AGoT7lGJgtSds7XfzyudUM+/pyCF57u9kFp5WO/H6ceUyuixkfMD3MpGEgK jBCEHj82KX8ISR5oNUzxbswubybLKaT7wWfV88mWvyKFl7aGuzgTiALVZPpeuatC vZo2sqdQcxATaDniOhmu1O6XXk9FeiLjIChxxt/im5WJHiGMqWwmnOXlMFnZ7UcI uJmy0ok0kSf9sD1CWM6O8EmBfiOKFhWwNXy9iQVrWzp0SngP2YpN/TNW8ZDdbtcn gQFrJo34lQTDmv9UrQhqpI4RJt4uXlsYnfEkCRK+uptHulxtFSehn4/cY3wMbh8= =JPwt -----END PGP SIGNATURE----- --AqsLC8rIMeq19msA-- From nobody Tue Nov 30 21:57:56 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id CC38D18BD21E; Tue, 30 Nov 2021 21:58:00 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4J3bgX3Hr9z3px9; Tue, 30 Nov 2021 21:57:59 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from kalamity.joker.local (123-48-130-181.area1b.commufa.jp [123.48.130.181]) (authenticated bits=0) by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 1AULvusw006743; Wed, 1 Dec 2021 06:57:56 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Wed, 1 Dec 2021 06:57:56 +0900 From: Tomoaki AOKI To: freebsd-current@freebsd.org Cc: Brooks Davis , freebsd-ports@freebsd.org Subject: Re: Problem compiling ports Message-Id: <20211201065756.b8d50b150a88b0181f24ad89@dec.sakura.ne.jp> In-Reply-To: <20211130174530.GA75149@spindle.one-eyed-alien.net> References: <28612702.6783053.1638293085302.ref@mail.yahoo.com> <28612702.6783053.1638293085302@mail.yahoo.com> <20211130174530.GA75149@spindle.one-eyed-alien.net> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4J3bgX3Hr9z3px9 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N It would be better making new special handling like BE_AMDGPU for it. Building with BE_STANDARD just for this would be a pain for some users. (CC'ing freebsd-ports ML.) On Tue, 30 Nov 2021 17:45:30 +0000 Brooks Davis wrote: > In the config for devel/llvm11, is BE_STANDARD enabled? If not, you > won't have the web assembly backend. > > -- Brooks > > On Tue, Nov 30, 2021 at 05:24:45PM +0000, Filippo Moretti via current wrote: > > error: unable to create target: 'No available targets are compatible with triple "wasm32-unknown-wasi"' > > 1 error generated. > > gmake[3]: *** [Makefile:380: /usr/ports/devel/wasi-libc/work/wasi-libc-ad5133410f66b93a2381db5b542aad5e0964db96/build/dlmalloc/src/dlmalloc.o] Error 1 > > error: unable to create target: 'No available targets are compatible with triple "wasm32-unknown-wasi"' > > 1 error generated. > > gmake[3]: *** [Makefile:440: startup_files] Error 1 > > gmake[3]: Leaving directory '/usr/ports/devel/wasi-libc/work/wasi-libc-ad5133410f66b93a2381db5b542aad5e0964db96' > > ===> Compilation failed unexpectedly. > > Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to > > the maintainer. > > *** Error code 1 > > > > Stop. > > make[2]: stopped in /usr/ports/devel/wasi-libc > > *** Error code 1 > > > > Stop. > > make[1]: stopped in /usr/ports/devel/wasi-libcxx*** Error code 1 > > > > Stop. > > make: stopped in /usr/ports/www/firefox > > > > ===>>> make build failed for www/firefox > > ===>>> Aborting update > > > > > > ??File "/usr/local/lib/python3.8/site-packages/setuptools/dist.py", line 799, in > > ?????? eps = map(lambda e: e.load(), pkg_resources.iter_entry_points(group)) > > ?? File "/usr/local/lib/python3.8/site-packages/pkg_resources/__init__.py", line 2449, in load > > ?????? self.require(*args, **kwargs) > > ?? File "/usr/local/lib/python3.8/site-packages/pkg_resources/__init__.py", line 2472, in require > > ?????? items = working_set.resolve(reqs, env, installer, extras=self.extras) > > ?? File "/usr/local/lib/python3.8/site-packages/pkg_resources/__init__.py", line 772, in resolve > > ?????? raise DistributionNotFound(req, requirers) > > pkg_resources.DistributionNotFound: The 'packaging>=20.0' distribution was not found and is required by the application > > *** Error code 1 > > > > Stop. > > make: stopped in /usr/ports/devel/py-pycparser > > > > ===>>> make build failed for devel/py-pycparser@py38 > > ===>>> Aborting update > > > > FreeBSD sting 14.0-CURRENT FreeBSD 14.0-CURRENT #62 heads/main-n251146-d109559ddbf: Mon Nov 29 12:18:48 CET 2021???????? root@sting:/usr/obj/usr/src/amd64.amd64/sys/STING?? amd64 > > > > -- Tomoaki AOKI From nobody Tue Nov 30 22:45:37 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 52E1C18AFD11; Tue, 30 Nov 2021 22:45:38 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4J3ckV1rcdz4cTQ; Tue, 30 Nov 2021 22:45:38 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 7EF4E3C0199; Tue, 30 Nov 2021 22:45:37 +0000 (UTC) Date: Tue, 30 Nov 2021 22:45:37 +0000 From: Brooks Davis To: Tomoaki AOKI Cc: freebsd-current@freebsd.org, freebsd-ports@freebsd.org Subject: Re: Problem compiling ports Message-ID: <20211130224537.GE75149@spindle.one-eyed-alien.net> References: <28612702.6783053.1638293085302.ref@mail.yahoo.com> <28612702.6783053.1638293085302@mail.yahoo.com> <20211130174530.GA75149@spindle.one-eyed-alien.net> <20211201065756.b8d50b150a88b0181f24ad89@dec.sakura.ne.jp> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cYtjc4pxslFTELvY" Content-Disposition: inline In-Reply-To: <20211201065756.b8d50b150a88b0181f24ad89@dec.sakura.ne.jp> User-Agent: Mutt/1.9.4 (2018-02-28) X-Rspamd-Queue-Id: 4J3ckV1rcdz4cTQ X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N --cYtjc4pxslFTELvY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Yeah, I've got this in progress. -- Brooks On Wed, Dec 01, 2021 at 06:57:56AM +0900, Tomoaki AOKI wrote: > It would be better making new special handling like BE_AMDGPU for it. > Building with BE_STANDARD just for this would be a pain for some users. >=20 > (CC'ing freebsd-ports ML.) >=20 >=20 > On Tue, 30 Nov 2021 17:45:30 +0000 > Brooks Davis wrote: >=20 > > In the config for devel/llvm11, is BE_STANDARD enabled? If not, you > > won't have the web assembly backend. > >=20 > > -- Brooks > >=20 > > On Tue, Nov 30, 2021 at 05:24:45PM +0000, Filippo Moretti via current w= rote: > > > error: unable to create target: 'No available targets are compatible = with triple "wasm32-unknown-wasi"' > > > 1 error generated. > > > gmake[3]: *** [Makefile:380: /usr/ports/devel/wasi-libc/work/wasi-lib= c-ad5133410f66b93a2381db5b542aad5e0964db96/build/dlmalloc/src/dlmalloc.o] E= rror 1 > > > error: unable to create target: 'No available targets are compatible = with triple "wasm32-unknown-wasi"' > > > 1 error generated. > > > gmake[3]: *** [Makefile:440: startup_files] Error 1 > > > gmake[3]: Leaving directory '/usr/ports/devel/wasi-libc/work/wasi-lib= c-ad5133410f66b93a2381db5b542aad5e0964db96' > > > =3D=3D=3D> Compilation failed unexpectedly. > > > Try to set MAKE_JOBS_UNSAFE=3Dyes and rebuild before reporting the fa= ilure to > > > the maintainer. > > > *** Error code 1 > > >=20 > > > Stop. > > > make[2]: stopped in /usr/ports/devel/wasi-libc > > > *** Error code 1 > > >=20 > > > Stop. > > > make[1]: stopped in /usr/ports/devel/wasi-libcxx*** Error code 1 > > >=20 > > > Stop. > > > make: stopped in /usr/ports/www/firefox > > >=20 > > > =3D=3D=3D>>> make build failed for www/firefox > > > =3D=3D=3D>>> Aborting update > > >=20 > > >=20 > > > ??File "/usr/local/lib/python3.8/site-packages/setuptools/dist.py", l= ine 799, in > > > ?????? eps =3D map(lambda e: e.load(), pkg_resources.iter_entry_point= s(group)) > > > ?? File "/usr/local/lib/python3.8/site-packages/pkg_resources/__init_= _.py", line 2449, in load > > > ?????? self.require(*args, **kwargs) > > > ?? File "/usr/local/lib/python3.8/site-packages/pkg_resources/__init_= _.py", line 2472, in require > > > ?????? items =3D working_set.resolve(reqs, env, installer, extras=3Ds= elf.extras) > > > ?? File "/usr/local/lib/python3.8/site-packages/pkg_resources/__init_= _.py", line 772, in resolve > > > ?????? raise DistributionNotFound(req, requirers) > > > pkg_resources.DistributionNotFound: The 'packaging>=3D20.0' distribut= ion was not found and is required by the application > > > *** Error code 1 > > >=20 > > > Stop. > > > make: stopped in /usr/ports/devel/py-pycparser > > >=20 > > > =3D=3D=3D>>> make build failed for devel/py-pycparser@py38 > > > =3D=3D=3D>>> Aborting update > > >=20 > > > FreeBSD sting 14.0-CURRENT FreeBSD 14.0-CURRENT #62 heads/main-n25114= 6-d109559ddbf: Mon Nov 29 12:18:48 CET 2021???????? root@sting:/usr/obj/usr= /src/amd64.amd64/sys/STING?? amd64 > > >=20 > > >=20 >=20 >=20 > --=20 > Tomoaki AOKI >=20 --cYtjc4pxslFTELvY Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJhpqmQAAoJEKzQXbSebgfAZGMH/RHhlGbl+KJtRU7AuXEA24jN tQnKT5k8NUBbvA1kOSlJiSZxc9izTumi4A9VvK328vkPh2vRP0rLbSN3uJY6yqMd KNfiLinwsq86JzbzuuGfY1SKcy4aQckGYWjIo/tjjShMupZfmbucOpTTELhifW7W udbnOrIwRiHe6d+bbGEGlQY7oORO244poKisWzYvM5NE8M/TVvi7xX9tgAHxgYmd D+AyoWg6g3I/KWj0aZa/uoSgnzQ6WKRGlX7T+msV6jF1oBJgslg6zUuwoO7fvifL h5orrssGt5JdE9tShSu7QqoDL2hFqt/b0ex1VvqZwnLK3/fNyz1K+f1kQZ0Miks= =YeBp -----END PGP SIGNATURE----- --cYtjc4pxslFTELvY-- From nobody Wed Dec 1 02:52:17 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 051DF18BCA84 for ; Wed, 1 Dec 2021 02:52:32 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-55.consmr.mail.gq1.yahoo.com (sonic315-55.consmr.mail.gq1.yahoo.com [98.137.65.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4J3kCL2cB1z4rd7 for ; Wed, 1 Dec 2021 02:52:30 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1638327143; bh=tHz5o4uThbU/gx4IgWYAkD/fjIVdSotCE7bEPlzi9B8=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=R5ajkMNIOsFd5YN8Qiho8hD4Bsgr/NHZRLpP5L16lIM+LdxFLrusDPcC2wRT3/aEmcDKUCuZpoOWBOdLS8f0xAl7f8YMM1jdH1LP0OtVK5B74XAHS//LVIQCGnlB027axTlsOnrgHVrA2jhXGeOQ5MZzCsFQc5fkNiZ2szUBB7OsDgccv3NV+N1XCqPoMZwI9W94dxR/yc9uMcKaOoKM5yA7D4DSFYAcr5TeHx62YQfd5bS6N0W3TtBmGL2aAAtt7sfgvkzPoHQ//YZCqforBl6eH6FnxJBdr69GSWFK2AsSVOZ//TB2LJhKJKuJ2kmICKJtKBH5+DUqM+oD2lbwrQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1638327143; bh=V2Q8gjWWcRPd+kSwnlS0ID8OcSk3rPwgmVpYAqNYEBQ=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=mjyUtBWvu3os2ZkxM/jylzF1dB3/zVCAnicXOhDaZuKovxjtPoBhUTR+kZLo138sbfHX7yf3BjEuVRZYVoH9DBoppyAaAwoTHn9dnFduJgqXYT33rab1z67Jy5qBBKFQF5vr/ACKXrEhHK/EVOG1O6sCtegyBnnHhW07cCM89dXYowAubd03+xRom2aWz7KwrrpqVMGO70zPCxJwVPEsHuU+YelMrkuoePxml6UONHbw0am7g6E7pdW1i8toEOE6whBtvDKbEoW6Y1tc62ODHwxC8nmesmHUksxr/0QVyMJGLxYxS9qzaAzDcZEzsJ4RG7mUBJl9Kzbf6UX1gFlBHg== X-YMail-OSG: HA0HEQcVM1m60y8nCO5IWmkBRDSEya1DQQDRxgJJuLIzqchoASDT.cXgHCgKLna z2U3iZ_19iTESD8QawTh4wcza1U1rMJFa6A_0mQnDkKoepB.L9FJxuvrNPHwe2Fcji0dhz2uaKoh cXKuyndpNivszX4ZBHJL8DD.Jbx9sdF3MNf9HMcBxQK9PUz_Ah8HjWms0CVEMUeyK7q0jEn.hAzF lDsD0MVSBbCe4UNyD.EX2tEcCGSkU9iitRA_QCKK5bQDLN23NKxM24vxW2ZRlBcecSiGFJlZ4dp5 .0f4VDEeYLNsN4LFnP_46VfaaYguCZ1wl_A0g0Rse7OIl6AgFTIcQs86I.HiZRrJrSJu5NTBvIJo pteEkZISkL1iraKvyFP8Rte94db_3SG7fggpdZli1NDimdRz1DSP07AdxxNc3jMhfroGFZMahQ7D T6dicrbYQXaBbdkLsQ9Do_Jl23QMBUoioC5WIxV2hqhmOTATHM5MAWW4Um4vQqA5YPH89m5SArkB qjfbszaS1RccAqJaP_Hcri2ehsxXnrevPpS6pWQov01WDKt_kmsWOM.f0q6mBiCcmkhiDuseeUTb ygQ8GCH1IGBUTWPgowp2PfOHZBSZj4vFmavO.OXasgYAii_GSzTYAxlxFEBtm226e8f3nT1pHYzO 2W2PAdnr24PjJZ.vF9bpRssz_kk7MXDhofM12XEnpkAYCE7UOr9TnFRo9ZwxHJN5POdTuCgsviUj V1VzMKs6PDJac18WNIil_cShJQVx7YM9bGzvGzdSumCF_vwVoNiHsFdgisppdLbirJM_FQVR3ka. HFU430hOPQKQgY6rdN.d0PRw4ruDEvYB0ehrI_8nLhX9q0GVafE2IWXFehf73JI1GNdd0WKxqcGS nBd3lzgAAwo6LwhkdOqHzz2hFRijCFQXerrLURv_1t7booNt5W6Tml3TecDVdhrg4BNRxZi5FBYl FQmb.Wgo9nZgo2vQRZKkD7dNj4p8f6Vlbuz8OGyrT86ETTS7GwW4BzmwZtoFhTUT9nhWdMD9lM4z UIPA1RWoYpNiQ45PFxS3MmX06rBRxcxXnUj2mjz.5sRRtHUpsVAt1cUYlatYTkiStWNFPoii3Wch 0eMG1xfTnAe8tYiLwxeug0N.NPUFv7E2IZqjYYkdsmv5GC7te7Z_rE0CeueQvv2Q.TrNGXJ6QCMV IfCw9BWUlz_TUXkmr6btwvUopWXoidhQtyVTWyt5RAGLmn34ku7BK0jFj8mAmM128cSZ62_WIQgl bADAMKIPANmfjo2ZOI1sexwq_Rpg2844a7FS2aW_eSn5LHEKGjv_Nw68.i_V3vyh_jQXw3k6GcMm .uwaEt2YqLbk0Xt_cr93kzPVriYPb3weQ_2kXKXsNtICh4Nwe_FkkQGJjt6SEGQrYf.6MbKcrqGj TNNfTvDAJ0QEwQ.ER6LARj5ixXmkHDJ3Dnhuc_g2S9F9ZjsF2REUympoHUF2lebmhRNa34zhlQeA N.Ja5QLjKoMVTVwQleIYsRUCl3YycLmUlQwD5LZjB6Ye_C9QYb2504UlPGz8mdYOBhMVzTbulaQ3 6rLAW8NjRjb0z5mDXNuWVECU1hvmUOY1nsNm3MhBOSgk._kRFmF8y7vHhitZIz299cS5DOeuo3ze qDy3kCjckiaeVOzh6Bw2O7H2rAiEjuoGYjnGFZSk2xRjygp6yc1.6MGdDIzJtko_PPwjXRtrzOj8 38iVfFXdaoeaDN7Wdq6Lr9cbLgEpaBYGmnXDg_iKpXmB0A6K9O2ifefP3n365meSQOFlsy11U6qk QrtQUC.wFJS0G7Z17F0cNnqKPHSkPm911ePAkTJdb75.xlfUOI91dXTf899_qL9050FePIueTXik 75b2w8G6BsA4WEpjpnzjUmeET5Iz71sgChL6ctHzqx3OhvUlW0dk8NPXGMvFxVOjB.Bxv3rqBYKa tjrGWRujR91U1fprS4EYY1sBh9_eij6O39_1qAvCnpWYWHFXNRp7.8GIgDsDVHvwLRZ34caBVzo7 HGIbX_KBPJuaGdHSbIcqlJy0ur0RoVpIrWdXCzjpon0z0U8HBorEZeaSJHzlsP73JhLvyP2Azi1O CB3umJST3JT3LLAVdoowEfkU._cC6zAL3rgr1y6KHBH1vtOW0V3fJu4.3fKLeW8kGXeHU3EmiZqM nImfwNqtzsn7mmu9ZdlPy98ydLQZeMI6HRdipBOuiTrURl1Md7nfqWuUv8wpbjsOmEL2ncub57Dc xk0TziIPc0t5sBLBFoGJi3JXGHPygWs5A4kvrbOoqbi_s544hPclFc1bjg4Z_Wyz.4.CfuOgrDH5 eAzZCDg-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Wed, 1 Dec 2021 02:52:23 +0000 Received: by kubenode537.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID c1af598fec5d4a30ad6513bffcc5953f; Wed, 01 Dec 2021 02:52:17 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: amd64 (example) main [so: 14]: delete-old check-old delete-old-libs missing a bunch of files? Message-Id: <99B36C2B-4540-4D3E-86E8-29787BE35105@yahoo.com> Date: Tue, 30 Nov 2021 18:52:17 -0800 To: freebsd-current X-Mailer: Apple Mail (2.3654.120.0.1.13) References: <99B36C2B-4540-4D3E-86E8-29787BE35105.ref@yahoo.com> X-Rspamd-Queue-Id: 4J3kCL2cB1z4rd7 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=R5ajkMNI; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-2.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; SUBJECT_ENDS_QUESTION(1.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.31:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.31:from]; RCVD_COUNT_TWO(0.00)[2] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-current X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N /usr/obj/DESTDIRs/main-amd64-poud/ is a buildworld installation for poudriere-devel use that I've been updating on occasion for a while. Despite: >>> Checking for old files >>> Checking for old libraries >>> Checking for old directories To remove old files and directories run 'make delete-old'. To remove old libraries run 'make delete-old-libs'. in /usr/obj/DESTDIRs/main-amd64-poud for: # chroot /usr/obj/DESTDIRs/main-amd64-poud uname -apKU FreeBSD amd64_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #14 = main-n250972-319e9fc642a1-dirty: Tue Nov 23 11:43:26 PST 2021 = root@amd64_ZFS:/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.a= md64/sys/GENERIC-NODBG amd64 amd64 1400042 1400042 installing a new directory tree: # chroot /usr/obj/DESTDIRs/main-amd64-chroot uname -apKU FreeBSD amd64_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #14 = main-n250972-319e9fc642a1-dirty: Tue Nov 23 11:43:26 PST 2021 = root@amd64_ZFS:/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.a= md64/sys/GENERIC-NODBG amd64 amd64 1400042 1400042and diff ends up with diff -rq between the trees findings many old files only under /usr/obj/DESTDIRs/main-amd64-poud/ . Various .old's and .bak's and such are likely expected but most of the following would seem to not be expected. Checking the dates indicates files from August and the like (dates not shown) and the matches being Nov 23. # diff -rq /usr/obj/DESTDIRs/main-amd64-chroot = /usr/obj/DESTDIRs/main-amd64-poud | more diff: /usr/obj/DESTDIRs/main-amd64-chroot/etc/os-release: No such file = or directory Only in /usr/obj/DESTDIRs/main-amd64-poud/boot: loader_4th.old Only in /usr/obj/DESTDIRs/main-amd64-poud/boot: loader_lua.old Only in /usr/obj/DESTDIRs/main-amd64-poud/boot: loader_simp.old Only in /usr/obj/DESTDIRs/main-amd64-poud/etc/rc.d: sppp Only in /usr/obj/DESTDIRs/main-amd64-poud/libexec: ld-elf.so.1.old Only in /usr/obj/DESTDIRs/main-amd64-poud/libexec: ld-elf32.so.1.old Only in /usr/obj/DESTDIRs/main-amd64-poud/rescue: spppcontrol Only in /usr/obj/DESTDIRs/main-amd64-poud/sbin: init.bak Only in = /usr/obj/DESTDIRs/main-amd64-poud/usr/include/netgraph/bluetooth/include: = ng_h4.h Only in = /usr/obj/DESTDIRs/main-amd64-poud/usr/lib/include/netgraph/bluetooth/inclu= de: ng_h4.h Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib: lib9p_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib: libicp_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib: libicp_rescue_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib: libnetmap_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib: libprivateatf-c++_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib: libprivateatf-c_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib: libprivateauditd_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib: libprivateevent1_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib: = libprivategmock_main_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib: libprivategmock_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib: = libprivategtest_main_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib: libprivategtest_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib: libspl_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib: libstats_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib: libtpool_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib: libzfsbootenv_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib: libzutil_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: lib80211_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: lib9p_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: = libBlocksRuntime_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libalias_dummy_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libalias_ftp_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libalias_irc_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libalias_nbt_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libalias_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libalias_pptp_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libalias_skinny_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libalias_smedia_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libarchive_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libasn1_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libavl_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libbe_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libbegemot_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libblacklist_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libbluetooth_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libbsdxml_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libbsm_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libbsnmp_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libbz2_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libc++_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libc_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libcalendar_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libcam_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libcom_err_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libcompat_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libcompiler_rt_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libcrypt_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libcrypto_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libctf_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libcurses_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libcursesw_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libcuse_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libcxxrt_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libdevctl_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libdevinfo_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libdevstat_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libdialog_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libdl_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libdpv_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libdtrace_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libdwarf_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libedit_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libefivar_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libelf_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libexecinfo_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libfetch_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libfigpar_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libform_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libformw_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libgcc_eh_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libgcc_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libgeom_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libgpio_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libgssapi_krb5_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libgssapi_ntlm_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libgssapi_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: = libgssapi_spnego_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libhdb_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libheimbase_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libheimntlm_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libhx509_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libicp_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libicp_rescue_p.a diff: = /usr/obj/DESTDIRs/main-amd64-chroot/usr/share/locale/nn_NO.ISO8859-1/LC_ME= SSAGES: Too many levels of symbolic links diff: = /usr/obj/DESTDIRs/main-amd64-chroot/usr/share/locale/nn_NO.ISO8859-15/LC_M= ESSAGES: Too many levels of symbolic links diff: = /usr/obj/DESTDIRs/main-amd64-chroot/usr/share/locale/sl_SI.ISO8859-2/LC_ME= SSAGES: No such file or directory diff: /usr/obj/DESTDIRs/main-amd64-chroot/usr/tests/local: No such file = or directory diff: = /usr/obj/DESTDIRs/main-amd64-chroot/usr/tests/sys/pjdfstest/tests/tests/te= sts/tests/tests/tests/tests/tests/tests/tests/tests/tests/tests/tests/test= s/tests/tests/tests/tests/tests/tests/tests/tests/tests/tests/tests/tests/= tests/tests/tests/tests/tests/tests: Too many levels of symbolic links Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libipsec_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libjail_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libkadm5clnt_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libkadm5srv_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libkafs5_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libkdc_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libkiconv_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libkrb5_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libkvm_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: liblzma_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libm_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libmagic_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libmd_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libmemstat_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libmenu_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libmenuw_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libmilter_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libmp_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libmt_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libncurses_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libncursesw_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libnetgraph_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libnetmap_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libngatm_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libnv_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libnvpair_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libopie_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libpanel_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libpanelw_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libpathconv_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libpcap_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libpjdlog_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libpmc_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: = libprivateauditd_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: = libprivatebsdstat_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: = libprivatedevdctl_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: = libprivateevent1_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: = libprivateheimipcc_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: = libprivateheimipcs_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libprivateldns_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: = libprivatesqlite3_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libprivatessh_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libprivateucl_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: = libprivateunbound_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libprivatezstd_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libproc_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libprocstat_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libpthread_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libradius_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libregex_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libroken_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: librpcsvc_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: librss_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: librt_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: librtld_db_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libsbuf_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libsdp_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libsmb_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libspl_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libssl_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libstats_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libstdbuf_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libstdthreads_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libsysdecode_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libtacplus_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libtermcap_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libtermcapw_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libtermlib_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libtermlibw_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libthr_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libthread_db_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libtinfo_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libtinfow_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libtpool_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libufs_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libugidfw_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libulog_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libumem_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libusb_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libusbhid_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libutempter_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libutil_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libuutil_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libvgl_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libwind_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libwrap_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libxo_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: liby_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libypclnt_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libz_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libzfs_core_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libzfs_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libzfsbootenv_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libzutil_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/share/certs/trusted: = QuoVadis_Root_CA.pem Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/share/certs/trusted: = Sonera_Class_2_Root_CA.pem Only in = /usr/obj/DESTDIRs/main-amd64-poud/usr/share/locale/be_BY.ISO8859-5: = LC_COLLATE Only in = /usr/obj/DESTDIRs/main-amd64-poud/usr/share/locale/ca_IT.ISO8859-15: = LC_COLLATE Only in = /usr/obj/DESTDIRs/main-amd64-poud/usr/share/locale/hr_HR.ISO8859-2: = LC_MESSAGES Only in = /usr/obj/DESTDIRs/main-amd64-poud/usr/share/locale/nl_BE.ISO8859-1: = LC_MESSAGES Only in = /usr/obj/DESTDIRs/main-amd64-poud/usr/share/locale/nl_BE.ISO8859-15: = LC_MESSAGES Only in = /usr/obj/DESTDIRs/main-amd64-poud/usr/share/locale/sr_RS.ISO8859-2: = LC_MESSAGES Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/share/locale/zh_TW.Big5: = LC_NUMERIC Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/share/man/man4: = cloudabi32.4.gz Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/share/man/man4: = cloudabi64.4.gz Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/share/man/man9: = vm_page_sbusy.9.gz Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/share/man/man9: = vm_page_sleep_if_busy.9.gz Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/share/man/man9: = vm_page_xbusy.9.gz Files /usr/obj/DESTDIRs/main-amd64-chroot/usr/share/man/mandoc.db and = /usr/obj/DESTDIRs/main-amd64-poud/usr/share/man/mandoc.db differ Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/lib/libc/tls: = libh_tls_dlopen_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/lib/libc/tls: = libh_tls_dynamic_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/libexec/rtld-elf: = libpythagoras_p.a Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.bin/awk: = awk_test Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.bin/awk: = d_assign_NF.awk Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.bin/awk: = d_assign_NF.in Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.bin/awk: = d_assign_NF.out Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.bin/awk: = d_big_regexp.awk Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.bin/awk: = d_big_regexp.in Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.bin/awk: = d_big_regexp.out Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.bin/awk: = d_end1.awk Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.bin/awk: = d_end1.in Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.bin/awk: = d_end1.out Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.bin/awk: = d_end2.awk Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.bin/awk: = d_end2.in Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.bin/awk: = d_end2.out Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.bin/awk: = d_period.awk Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.bin/awk: = d_period.in Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.bin/awk: = d_period.out Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.bin/awk: = d_string1.awk Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.bin/awk: = d_string1.out Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.bin/awk: = d_tolower.awk Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.bin/awk: = d_tolower.in Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.bin/awk: = d_tolower.out Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.bin/awk: = d_toupper.awk Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.bin/awk: = d_toupper.in Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.bin/awk: = d_toupper.out Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.bin/gh-bc: = functions.sh Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.bin/gh-bc/tests: = afl.py Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.bin/gh-bc/tests: = diff.sh Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.bin/gh-bc/tests: = radamsa.sh Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.bin/gh-bc/tests: = radamsa.txt Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.bin/gh-bc/tests: = randmath.py Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.bin/lastcomm: = v1-sparc64-acct.in Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.bin/lastcomm: = v1-sparc64.out Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.bin/lastcomm: = v2-sparc64-acct.in Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.bin/lastcomm: = v2-sparc64.out Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.sbin/mixer: = Kyuafile Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.sbin/mixer: = mixer_test Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.sbin/sa: = v1-sparc64-sav.in Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.sbin/sa: = v1-sparc64-sav.out Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.sbin/sa: = v1-sparc64-u.out Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.sbin/sa: = v1-sparc64-usr.in Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.sbin/sa: = v1-sparc64-usr.out Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.sbin/sa: = v2-sparc64-sav.in Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.sbin/sa: = v2-sparc64-u.out Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.sbin/sa: = v2-sparc64-usr.in I first noticed the kind of issue on aarch64. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Wed Dec 1 22:26:22 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C49E418C7089 for ; Wed, 1 Dec 2021 22:26:24 +0000 (UTC) (envelope-from jhb@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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J4DFr2DL2z3tqj; Wed, 1 Dec 2021 22:26:24 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from [10.0.1.4] (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id A939125D8B; Wed, 1 Dec 2021 22:26:23 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: Date: Wed, 1 Dec 2021 14:26:22 -0800 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Content-Language: en-US To: marklmi@yahoo.com, freebsd-current References: <99B36C2B-4540-4D3E-86E8-29787BE35105.ref@yahoo.com> <99B36C2B-4540-4D3E-86E8-29787BE35105@yahoo.com> From: John Baldwin Subject: Re: amd64 (example) main [so: 14]: delete-old check-old delete-old-libs missing a bunch of files? In-Reply-To: <99B36C2B-4540-4D3E-86E8-29787BE35105@yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1638397584; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=BqM+itZbjmAah899shHNjTQzNiWOWyZ0hm97W/ewRfk=; b=aM1sMhbyTW7Fb9AxC2CEbJtQzh/KwSgs31Gp43hF6OJpHWVk+nH8SPLrVtjeWf25rYK5fB dvKUfhJ8Tb6/RT3uVq+66Uy21yF/riw277+/wyDZuc3C4pE7x1ebtwM4eO/TI7pX6MhtJb VTNIq7J5ZSVcsa8/p/41c7fx6W5CpfVpHJN7juxhmFM6zyZV/RicM5ka/RDlxfWT8zkXdh MlvdakSBBeslrWPbTpXhB+Dj1lvNxqDEXRFpm5X30r+ruoUGzxYJRGoQM9+1EPSMszdMDy Uop8Au9rcP5OmggxkD/FvEMsh0j+0CqQcR3o6zSJyRJcSekJJJSMdOHlXgFegQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1638397584; a=rsa-sha256; cv=none; b=DMVHCoo9YCQHQTexeVVbHLYz/8ec97abqMM6Ns8rfzwhfLsvrre6bis/qwUMwQSdtT29iW 71THjqtbSBQeEo6oEDGAHx9OgeE+w7GFZqS+otsDq1WF6GNt2bZ5MB/Ln9K+kR+gDgj2aH QAINhCtXQMev/cd6Y1vq6/dok67zGCNtPXBf6ztazjM/JFKMTDdEsI8aGCO/QAuc2jefjc qBgFw0TQaQLGNOm/bTmlZJ9RkqSdc4qr8KFNWmZc3KzvCEexAeAwtusf6tYK6RBb47qr9V FZooM6qrbat36b3cN/2HlIsPrP+MwDMJpsYm4tSYz1dV2crn85GYn99bHtl3oA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 11/30/21 6:52 PM, Mark Millard via freebsd-current wrote: > /usr/obj/DESTDIRs/main-amd64-poud/ is a buildworld installation > for poudriere-devel use that I've been updating on occasion for > a while. > > Despite: > >>>> Checking for old files >>>> Checking for old libraries >>>> Checking for old directories > To remove old files and directories run 'make delete-old'. > To remove old libraries run 'make delete-old-libs'. > > in /usr/obj/DESTDIRs/main-amd64-poud for: > > # chroot /usr/obj/DESTDIRs/main-amd64-poud uname -apKU > FreeBSD amd64_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #14 main-n250972-319e9fc642a1-dirty: Tue Nov 23 11:43:26 PST 2021 root@amd64_ZFS:/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERIC-NODBG amd64 amd64 1400042 1400042 > > installing a new directory tree: > > # chroot /usr/obj/DESTDIRs/main-amd64-chroot uname -apKU > FreeBSD amd64_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #14 main-n250972-319e9fc642a1-dirty: Tue Nov 23 11:43:26 PST 2021 root@amd64_ZFS:/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERIC-NODBG amd64 amd64 1400042 1400042and diff > > ends up with diff -rq between the trees findings many old > files only under /usr/obj/DESTDIRs/main-amd64-poud/ . Various > .old's and .bak's and such are likely expected but most of > the following would seem to not be expected. Checking the > dates indicates files from August and the like (dates not > shown) and the matches being Nov 23. > > # diff -rq /usr/obj/DESTDIRs/main-amd64-chroot /usr/obj/DESTDIRs/main-amd64-poud | more > diff: /usr/obj/DESTDIRs/main-amd64-chroot/etc/os-release: No such file or directory > Only in /usr/obj/DESTDIRs/main-amd64-poud/boot: loader_4th.old > Only in /usr/obj/DESTDIRs/main-amd64-poud/boot: loader_lua.old > Only in /usr/obj/DESTDIRs/main-amd64-poud/boot: loader_simp.old > Only in /usr/obj/DESTDIRs/main-amd64-poud/libexec: ld-elf.so.1.old > Only in /usr/obj/DESTDIRs/main-amd64-poud/libexec: ld-elf32.so.1.old > Only in /usr/obj/DESTDIRs/main-amd64-poud/sbin: init.bak These are false positives (all of *.old are as well as init.bak) > Only in /usr/obj/DESTDIRs/main-amd64-poud/etc/rc.d: sppp > Only in /usr/obj/DESTDIRs/main-amd64-poud/rescue: spppcontrol Leftovers for sppp(4) removal. > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/include/netgraph/bluetooth/include: ng_h4.h > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib/include/netgraph/bluetooth/include: ng_h4.h Leftovers from ng_h4(4) removal. > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib: lib9p_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib: libicp_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib: libicp_rescue_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib: libnetmap_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib: libprivateatf-c++_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib: libprivateatf-c_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib: libprivateauditd_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib: libprivateevent1_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib: libprivategmock_main_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib: libprivategmock_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib: libprivategtest_main_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib: libprivategtest_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib: libspl_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib: libstats_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib: libtpool_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib: libzfsbootenv_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib: libzutil_p.a Missing entries in WITHOUT_PROFILE in OptionalObsoleteFiles.inc > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: lib80211_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: lib9p_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libBlocksRuntime_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libalias_dummy_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libalias_ftp_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libalias_irc_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libalias_nbt_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libalias_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libalias_pptp_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libalias_skinny_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libalias_smedia_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libarchive_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libasn1_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libavl_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libbe_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libbegemot_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libblacklist_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libbluetooth_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libbsdxml_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libbsm_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libbsnmp_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libbz2_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libc++_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libc_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libcalendar_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libcam_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libcom_err_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libcompat_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libcompiler_rt_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libcrypt_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libcrypto_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libctf_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libcurses_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libcursesw_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libcuse_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libcxxrt_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libdevctl_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libdevinfo_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libdevstat_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libdialog_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libdl_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libdpv_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libdtrace_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libdwarf_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libedit_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libefivar_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libelf_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libexecinfo_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libfetch_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libfigpar_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libform_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libformw_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libgcc_eh_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libgcc_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libgeom_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libgpio_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libgssapi_krb5_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libgssapi_ntlm_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libgssapi_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libgssapi_spnego_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libhdb_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libheimbase_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libheimntlm_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libhx509_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libicp_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libicp_rescue_p.a WITHOUT_PROFILE doesn't handle lib32 it seems > diff: /usr/obj/DESTDIRs/main-amd64-chroot/usr/share/locale/nn_NO.ISO8859-1/LC_MESSAGES: Too many levels of symbolic links > diff: /usr/obj/DESTDIRs/main-amd64-chroot/usr/share/locale/nn_NO.ISO8859-15/LC_MESSAGES: Too many levels of symbolic links > diff: /usr/obj/DESTDIRs/main-amd64-chroot/usr/share/locale/sl_SI.ISO8859-2/LC_MESSAGES: No such file or directory > diff: /usr/obj/DESTDIRs/main-amd64-chroot/usr/tests/local: No such file or directory > diff: /usr/obj/DESTDIRs/main-amd64-chroot/usr/tests/sys/pjdfstest/tests/tests/tests/tests/tests/tests/tests/tests/tests/tests/tests/tests/tests/tests/tests/tests/tests/tests/tests/tests/tests/tests/tests/tests/tests/tests/tests/tests/tests/tests/tests/tests/tests: Too many levels of symbolic links No idea what's up with these. > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libipsec_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libjail_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libkadm5clnt_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libkadm5srv_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libkafs5_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libkdc_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libkiconv_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libkrb5_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libkvm_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: liblzma_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libm_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libmagic_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libmd_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libmemstat_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libmenu_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libmenuw_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libmilter_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libmp_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libmt_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libncurses_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libncursesw_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libnetgraph_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libnetmap_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libngatm_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libnv_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libnvpair_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libopie_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libpanel_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libpanelw_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libpathconv_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libpcap_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libpjdlog_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libpmc_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libprivateauditd_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libprivatebsdstat_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libprivatedevdctl_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libprivateevent1_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libprivateheimipcc_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libprivateheimipcs_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libprivateldns_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libprivatesqlite3_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libprivatessh_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libprivateucl_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libprivateunbound_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libprivatezstd_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libproc_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libprocstat_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libpthread_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libradius_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libregex_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libroken_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: librpcsvc_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: librss_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: librt_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: librtld_db_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libsbuf_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libsdp_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libsmb_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libspl_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libssl_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libstats_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libstdbuf_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libstdthreads_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libsysdecode_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libtacplus_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libtermcap_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libtermcapw_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libtermlib_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libtermlibw_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libthr_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libthread_db_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libtinfo_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libtinfow_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libtpool_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libufs_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libugidfw_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libulog_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libumem_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libusb_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libusbhid_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libutempter_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libutil_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libuutil_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libvgl_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libwind_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libwrap_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libxo_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: liby_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libypclnt_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libz_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libzfs_core_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libzfs_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libzfsbootenv_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/lib32: libzutil_p.a More missing WITHOUT_PROFILE for lib32. > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/share/certs/trusted: QuoVadis_Root_CA.pem > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/share/certs/trusted: Sonera_Class_2_Root_CA.pem Maybe these certs moved to untrusted? > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/share/locale/be_BY.ISO8859-5: LC_COLLATE > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/share/locale/ca_IT.ISO8859-15: LC_COLLATE > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/share/locale/hr_HR.ISO8859-2: LC_MESSAGES > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/share/locale/nl_BE.ISO8859-1: LC_MESSAGES > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/share/locale/nl_BE.ISO8859-15: LC_MESSAGES > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/share/locale/sr_RS.ISO8859-2: LC_MESSAGES > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/share/locale/zh_TW.Big5: LC_NUMERIC No idea. > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/share/man/man4: cloudabi32.4.gz > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/share/man/man4: cloudabi64.4.gz Missing MLINKS from cloudabi(4) removal. > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/share/man/man9: vm_page_sbusy.9.gz > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/share/man/man9: vm_page_sleep_if_busy.9.gz > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/share/man/man9: vm_page_xbusy.9.gz These should be covered by the entry for 20211115. > Files /usr/obj/DESTDIRs/main-amd64-chroot/usr/share/man/mandoc.db and /usr/obj/DESTDIRs/main-amd64-poud/usr/share/man/mandoc.db differ > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/lib/libc/tls: libh_tls_dlopen_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/lib/libc/tls: libh_tls_dynamic_p.a > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/libexec/rtld-elf: libpythagoras_p.a More WITHOUT_PROFILE fallout. > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.bin/awk: awk_test > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.bin/awk: d_assign_NF.awk > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.bin/awk: d_assign_NF.in > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.bin/awk: d_assign_NF.out > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.bin/awk: d_big_regexp.awk > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.bin/awk: d_big_regexp.in > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.bin/awk: d_big_regexp.out > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.bin/awk: d_end1.awk > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.bin/awk: d_end1.in > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.bin/awk: d_end1.out > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.bin/awk: d_end2.awk > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.bin/awk: d_end2.in > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.bin/awk: d_end2.out > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.bin/awk: d_period.awk > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.bin/awk: d_period.in > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.bin/awk: d_period.out > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.bin/awk: d_string1.awk > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.bin/awk: d_string1.out > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.bin/awk: d_tolower.awk > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.bin/awk: d_tolower.in > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.bin/awk: d_tolower.out > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.bin/awk: d_toupper.awk > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.bin/awk: d_toupper.in > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.bin/awk: d_toupper.out awk test changes? Warner might know more about those. > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.bin/gh-bc: functions.sh > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.bin/gh-bc/tests: afl.py > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.bin/gh-bc/tests: diff.sh > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.bin/gh-bc/tests: radamsa.sh > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.bin/gh-bc/tests: radamsa.txt > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.bin/gh-bc/tests: randmath.py bc(1) upgrade fallout? > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.bin/lastcomm: v1-sparc64-acct.in > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.bin/lastcomm: v1-sparc64.out > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.bin/lastcomm: v2-sparc64-acct.in > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.bin/lastcomm: v2-sparc64.out These (and the sparc64 sa tests) were removed without updating ObsoleteFiles.inc. > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.sbin/mixer: Kyuafile > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.sbin/mixer: mixer_test Fallout from recent mixer changes? Hans might know more. > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.sbin/sa: v1-sparc64-sav.in > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.sbin/sa: v1-sparc64-sav.out > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.sbin/sa: v1-sparc64-u.out > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.sbin/sa: v1-sparc64-usr.in > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.sbin/sa: v1-sparc64-usr.out > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.sbin/sa: v2-sparc64-sav.in > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.sbin/sa: v2-sparc64-u.out > Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.sbin/sa: v2-sparc64-usr.in I'll commit fixes for some of these. -- John Baldwin From nobody Thu Dec 2 01:45:16 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 8338718BD8CC for ; Thu, 2 Dec 2021 01:45:22 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J4JgP6WrXz4Vx7 for ; Thu, 2 Dec 2021 01:45:21 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: by mail-wr1-x42c.google.com with SMTP id j3so56257299wrp.1 for ; Wed, 01 Dec 2021 17:45:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:cc:from:in-reply-to:content-transfer-encoding; bh=xhWG+gvdDlhSJ1Ihu5ftrXc8qgfpFZMcBA+CojtPk6k=; b=fLUdnv42zs7FfTjSkwACfPAEO1VdcBY9sAsJ+ynzUHm03QfsENEL2/Hq5lveVYO9MC DjVd84oTLEYAVheUx3rIO3ntkIXTLz9erIoPXbeAeC8tNJH0pVSo3dEwlPGEWLVByxcK maOn7raR+zAVOtcE2efCfVppynRyr3H8KOlNpmhx6JHZ5XAeGn8JGg9LxoivzLjNF/4i DamJkka5Z0dIXM/1UuxcGLK+CtrmjXJonNTdFDDpWMtIyCgz6FH42/dJ0Xv9WoPSzLHL Ttu4eA6m2OXD6nUlbxJXo8ZRsUjOFds0AZ/rTWhPg4G8TRa/sWUvMzbALjjjwJFkbcYT rLnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:cc:from:in-reply-to :content-transfer-encoding; bh=xhWG+gvdDlhSJ1Ihu5ftrXc8qgfpFZMcBA+CojtPk6k=; b=Fq8yDO+hZKZNt3sr7UBGZuKF8ArUiIzIbAGOxYEChQwRmknzZulAEFxcwVmfaG9nM6 mO54sjjf1Dhu2S3UOvTzsNoW/FgtPVGh0GeO0fp5brjkYxDZYyKE+6Z1Q9Mdaty74mJi Jtwwqw+oTCe5FnjNm+EnIowSfv+uODHiasTzPOUpZ/xxkl6CBH7Ya/oLHNIaDBnKfm5U TxY+3KyH1sLhV9OsG+3/7psHd/4lr5o1yrZH5WudNk+8g75sRUAjhcc3FK4wNzAK9Ayt UvMMEzkxCacHh9wgMKf55m2cxdqowNrx2gKc4S9gUU8ar81zlEpJ/CyorSUo1iXQJvQo C/4Q== X-Gm-Message-State: AOAM533p6s32f5d5HmD6t6BIE+Tr/5VDhDwC3fE3CGL2t5NrY3gIwZhE nXQSe003uzWvDp49qqeorTOto9/UOG7LVw== X-Google-Smtp-Source: ABdhPJyA3UPbHpDullkrYFVjRvdc7ilOS4PgjdgaxQgK5Jh+V0xQkt3XnA+icJ6G1qjCyxTkMmwqWQ== X-Received: by 2002:a5d:5303:: with SMTP id e3mr10897530wrv.73.1638409515372; Wed, 01 Dec 2021 17:45:15 -0800 (PST) Received: from ?IPV6:2001:470:1f1c:a0::2? (tunnel642390-pt.tunnel.tserv1.lon2.ipv6.he.net. [2001:470:1f1c:a0::2]) by smtp.gmail.com with ESMTPSA id h17sm1145816wrp.34.2021.12.01.17.45.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 01 Dec 2021 17:45:14 -0800 (PST) Message-ID: <978425b8-2e44-61d9-f325-6acb2768ef08@gmail.com> Date: Thu, 2 Dec 2021 01:45:16 +0000 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Subject: Re: pkg sqlite database borked ( again ). How to restore? Content-Language: en-GB To: dclarke@blastwave.org References: <4d9d5406-c257-e5cb-d237-d26889468f62@blastwave.org> Cc: FreeBSD Current From: Graham Perrin In-Reply-To: <4d9d5406-c257-e5cb-d237-d26889468f62@blastwave.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4J4JgP6WrXz4Vx7 X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=fLUdnv42; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grahamperrin@gmail.com designates 2a00:1450:4864:20::42c as permitted sender) smtp.mailfrom=grahamperrin@gmail.com X-Spamd-Result: default: False [1.02 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; NEURAL_SPAM_SHORT(1.00)[1.000]; NEURAL_HAM_LONG(-0.98)[-0.979]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_SPAM_MEDIUM(1.00)[0.999]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::42c:from]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 29/11/2021 11:01, Dennis Clarke via freebsd-current wrote: > … kernel panic … resulted in the pkg database being messed up. … Dennis, was that an unfortunate coincidence of a panic during a write to the database? From nobody Thu Dec 2 02:03:26 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id CEA7B18C6EC0 for ; Thu, 2 Dec 2021 02:03:28 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J4K4J02yjz4cwN for ; Thu, 2 Dec 2021 02:03:27 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id 1B223QlS078974 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 1 Dec 2021 18:03:26 -0800 (PST) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id 1B223Qex078973 for freebsd-current@FreeBSD.org; Wed, 1 Dec 2021 18:03:26 -0800 (PST) (envelope-from jmg) Date: Wed, 1 Dec 2021 18:03:26 -0800 From: John-Mark Gurney To: freebsd-current@FreeBSD.org Subject: failure of pructl (atexit/_Block_copy/--no-allow-shlib-undefined) Message-ID: <20211202020326.GU35602@funkthat.com> Mail-Followup-To: freebsd-current@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD 11.3-STABLE amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Wed, 01 Dec 2021 18:03:26 -0800 (PST) X-Rspamd-Queue-Id: 4J4K4J02yjz4cwN X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of jmg@gold.funkthat.com has no SPF policy when checking 208.87.223.18) smtp.mailfrom=jmg@gold.funkthat.com X-Spamd-Result: default: False [-0.04 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[jmg]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[funkthat.com]; NEURAL_HAM_SHORT(-0.99)[-0.986]; NEURAL_SPAM_LONG(0.75)[0.747]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[jmg@funkthat.com,jmg@gold.funkthat.com]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:32354, ipnet:208.87.216.0/21, country:US]; FROM_NEQ_ENVFROM(0.00)[jmg@funkthat.com,jmg@gold.funkthat.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Hello, It seems like the recent changes to make --no-allow-shlib-undefined broke pructl. lib/libc/stdlib/atexit.c uses a weak _Block_copy symbol, but pructl does not use atexit_b, and yet gets the following error: : && /usr/bin/cc -Werror -O2 -pipe -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing -std=c99 -fstack-protector-strong CMakeFiles/pructl.dir/pructl.c.o -o pructl -Wl,-rpath,/usr/local/lib: /usr/local/lib/libpru.so && : ld: error: /lib/libc.so.7: undefined reference to _Block_copy [--no-allow-shlib-undefined] cc: error: linker command failed with exit code 1 (use -v to see invocation) What is the correct fix? It seems like atexit.c or the linker should be fixed, as pructl doesn't use atexit_b at all. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From nobody Thu Dec 2 05:42:21 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id A081318BA816 for ; Thu, 2 Dec 2021 05:42:33 +0000 (UTC) (envelope-from kevans@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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J4Px52j4Vz4jZC; Thu, 2 Dec 2021 05:42:33 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qt1-f169.google.com (mail-qt1-f169.google.com [209.85.160.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 391BB29510; Thu, 2 Dec 2021 05:42:33 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qt1-f169.google.com with SMTP id z9so26484361qtj.9; Wed, 01 Dec 2021 21:42:33 -0800 (PST) X-Gm-Message-State: AOAM531NKjm3NsWi7ob/RRfaJPd0URPg2Gog/DgLUeCv+20N7W/Ts6xX PPRSt0kGBriR9/sUr+eUjDPVR/qvuvIIdNieRIA= X-Google-Smtp-Source: ABdhPJzkdLVtv1IPflxOYvFI2hhQLTkL3xY2DOZ3VY8lwMUlwBIJRg5ZU5hR73zrn8xTBCCae+6DiWr4El8FdzhFRfg= X-Received: by 2002:a05:622a:2d6:: with SMTP id a22mr11887952qtx.29.1638423752543; Wed, 01 Dec 2021 21:42:32 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <20211202020326.GU35602@funkthat.com> In-Reply-To: <20211202020326.GU35602@funkthat.com> From: Kyle Evans Date: Wed, 1 Dec 2021 23:42:21 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: failure of pructl (atexit/_Block_copy/--no-allow-shlib-undefined) To: FreeBSD Current Cc: Dimitry Andric , Jessica Clarke Content-Type: text/plain; charset="UTF-8" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1638423753; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=ef4AQsxaQRfQch9/9N3DkiCeG1/vNztIzZ+XJ5RDkJ4=; b=u2cCdHeSjVqCAWRhb0qsN8wsUmiMaPchsJ/57baFT81pacWv0kjNYfHbHcZUuGjk4U0Pdc EhaEw5yS5i2nlvCxw2X4PJboYg8sH+yuIrDY3h1JjlxN7x5zRLXCSlriMjXxYoftcpsmza BobfBj+gmT/LGq3ffHdK2yLAC+sYrdMVtUoZZ1NOyHOQoCwg8dh+BuX/hqizwuLWrSDvPN Cn6vRbxhW1fBwarE24i3ZkdDxKvtHilbFktgEsg/hRcKgxivTJ5cb+IMDgWdX/lt+gcCf6 VvTiNmVmmxalbm4eL80biIqW38h1L02YM9f/jRvJwD3OMZ1+mlZlr3yjBtHzcg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1638423753; a=rsa-sha256; cv=none; b=Xp7cCB7r41Oapac4Uy5NZbVSzmxlwNkKSVEfwZ8OW+BXSrSEs5YBFtub5UEImOZk5FoDmr jmtI21k8tzFNB4Xd1/7i9tsRFzDdm8RUSyRoZBAXXnqHxkvaqqloc6QMJJAyvzPWOwTOxA l5ssJ/gQuoCBEo1LTfni5PBtmtRujL7+gnSgGCd9FgjGcYQP0cPU4rb3l5AImngidawi73 ZUDlFqGNZcJu0nkJHwZX9TsB06rTr+vAj8R5u4PSByWP1a6RdDPIHYbEBku+zkxxwNcXDg r1MavXCbZTD9l8HxzwV2u0SAKOhKvf56oxH7t8o3hV9Qm5z+furg3V/I5CTmXA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On Wed, Dec 1, 2021 at 8:05 PM John-Mark Gurney wrote: > > Hello, > > It seems like the recent changes to make --no-allow-shlib-undefined > broke pructl. > > lib/libc/stdlib/atexit.c uses a weak _Block_copy symbol, but > pructl does not use atexit_b, and yet gets the following error: > : && /usr/bin/cc -Werror -O2 -pipe -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing -std=c99 -fstack-protector-strong CMakeFiles/pructl.dir/pructl.c.o -o pructl -Wl,-rpath,/usr/local/lib: /usr/local/lib/libpru.so && : > ld: error: /lib/libc.so.7: undefined reference to _Block_copy [--no-allow-shlib-undefined] > cc: error: linker command failed with exit code 1 (use -v to see invocation) > > What is the correct fix? It seems like atexit.c or the linker should > be fixed, as pructl doesn't use atexit_b at all. > CC dim@ and jrtc27@... this seems like a toolchain regression? We're relying on the address of weak _Block_copy to simply evaluate to NULL if it's undefined here, which seems legit and pretty well-defined at this point from my recollection. From nobody Thu Dec 2 09:12:21 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1967F18CFA96 for ; Thu, 2 Dec 2021 09:12:27 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4J4VbG0q2Dz4gTk for ; Thu, 2 Dec 2021 09:12:26 +0000 (UTC) (envelope-from hps@selasky.org) Received: from [10.36.2.165] (unknown [178.17.145.105]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 147CA2601B4 for ; Thu, 2 Dec 2021 10:12:25 +0100 (CET) Message-ID: <36649914-f670-6d9c-709b-b525dc5e50cc@selasky.org> Date: Thu, 2 Dec 2021 10:12:21 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 To: FreeBSD Current Content-Language: en-US From: Hans Petter Selasky Subject: sys/conf: Simplify configuration files Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4J4VbG0q2Dz4gTk X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [1.94 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[selasky.org]; NEURAL_SPAM_MEDIUM(0.98)[0.976]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_ALL(0.00)[]; NEURAL_SPAM_LONG(1.00)[1.000]; NEURAL_SPAM_SHORT(0.26)[0.262]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi fellow kernel developers, I have two patches for config(8) which will allow us to group filenames in sys/conf/files* among others. Any strong opinions about the following change? https://reviews.freebsd.org/D33224 --HPS From nobody Thu Dec 2 09:51:44 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 538F918B8848 for ; Thu, 2 Dec 2021 09:51:55 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J4WSp6hS0z4r7f; Thu, 2 Dec 2021 09:51:54 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "R3" (verified OK)) (Authenticated sender: dim) by smtp.freebsd.org (Postfix) with ESMTPSA id A6E472B5B7; Thu, 2 Dec 2021 09:51:54 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtpclient.apple (longrow.home.andric.com [192.168.0.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 7DDED563DB; Thu, 2 Dec 2021 10:51:52 +0100 (CET) From: Dimitry Andric Message-Id: <75CCC6A8-F777-48F9-9AC7-5A08FA9CCD25@FreeBSD.org> Content-Type: multipart/signed; boundary="Apple-Mail=_C8AC2CF4-EB75-4385-A8E3-C47CF5CB66FF"; protocol="application/pgp-signature"; micalg=pgp-sha1 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: failure of pructl (atexit/_Block_copy/--no-allow-shlib-undefined) Date: Thu, 2 Dec 2021 10:51:44 +0100 In-Reply-To: Cc: FreeBSD Current , Jessica Clarke To: Kyle Evans References: <20211202020326.GU35602@funkthat.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1638438715; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=1zpc63vfycukBzfaykoSb2dTvyYnz8h0mhYi8Ec54No=; b=C55HrVwM1EBWBDuH3MR/elAbo9QzcNQo2s2oHiIgbtiIdJx379mOxdvnxId6YezAhGkOon dLm4O6azNLaMvOTr/btfbfX+qloq3qO70GU3AT1tkCKr4Fl1uDrntItD0GOrjqD8vU2Giq aELEwaTcDg3BTBJYijaPKxl3o1RHb55MHloiyqTe7Az8CkUnM5fDU+J4xGgDqmyalxGojs KNPvw2QGoCOX++synDK7gOBknRSam/nQ+9Pn/sRikDp36nKACDxT6e2d2IJsSJf1QaN2F8 5gZf8uCKm87C6hPvlYBCwqJxQUJNFOCe11qpAj1eITdeUiKiFigQXxD5H6DHOw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1638438715; a=rsa-sha256; cv=none; b=Itv9ipbAB8qG5cm9fhOZ79PCsALKYHKUHTNyvewPxEQHzibNeWe+uJgL7i+kfDPeQt6xLQ GO69JXvTBadXzwOx1+IUriXLeCdVLQMqKR8TLBC396o4q1+QwKyo0QMAf/OexAnBAtToR0 H+D/E1b9loTugshzr1hwe20F7vzIu6Sv7sH603xOWybuRz+0jILK4I0b6usMfglwBoyMKj XOXCV74h+klXC/BShMGsqBhW6GITK/SjBzUd8D7VXISGifNaW2uxGv70KmZsFMFplwZF1v yrlS8egrW1hgPUMF2QAnMrwL9LlciG4tI6y9xFR89mMDupjVyzHtSS3knPWJ+A== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_C8AC2CF4-EB75-4385-A8E3-C47CF5CB66FF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2 Dec 2021, at 06:42, Kyle Evans wrote: >=20 > On Wed, Dec 1, 2021 at 8:05 PM John-Mark Gurney = wrote: >>=20 >> Hello, >>=20 >> It seems like the recent changes to make --no-allow-shlib-undefined >> broke pructl. >>=20 >> lib/libc/stdlib/atexit.c uses a weak _Block_copy symbol, but >> pructl does not use atexit_b, and yet gets the following error: >> : && /usr/bin/cc -Werror -O2 -pipe -fstack-protector-strong -isystem = /usr/local/include -fno-strict-aliasing -std=3Dc99 = -fstack-protector-strong CMakeFiles/pructl.dir/pructl.c.o -o pructl = -Wl,-rpath,/usr/local/lib: /usr/local/lib/libpru.so && : >> ld: error: /lib/libc.so.7: undefined reference to _Block_copy = [--no-allow-shlib-undefined] >> cc: error: linker command failed with exit code 1 (use -v to see = invocation) >>=20 >> What is the correct fix? It seems like atexit.c or the linker should >> be fixed, as pructl doesn't use atexit_b at all. >>=20 >=20 > CC dim@ and jrtc27@... this seems like a toolchain regression? We're > relying on the address of weak _Block_copy to simply evaluate to NULL > if it's undefined here, which seems legit and pretty well-defined at > this point from my recollection. What do you mean exactly with "here"? In libc? In atexit? In libpru? I can't make it out from the context, sorry. :) As far as I can see, _Block_copy has always been a weak undefined symbol in libc.so: 4: 0000000000000000 0 NOTYPE WEAK DEFAULT UND _Block_copy Apparently the "block runtime" is supposed to provide the actual object, so I guess you have to explicitly link to that runtime? I know next to nothing about the blocks stuff, so it's all pretty much unknown territory to me... :) -Dimitry --Apple-Mail=_C8AC2CF4-EB75-4385-A8E3-C47CF5CB66FF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCYaiXMAAKCRCwXqMKLiCW o2qrAJsE+Zy0+2voHapslP1zBm8rF+/kfwCg2xpqDfYYlojks5G5uYoz9y2gsgg= =jYqh -----END PGP SIGNATURE----- --Apple-Mail=_C8AC2CF4-EB75-4385-A8E3-C47CF5CB66FF-- From nobody Thu Dec 2 10:23:37 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9DFF018C6F7C for ; Thu, 2 Dec 2021 10:23:47 +0000 (UTC) (envelope-from dim@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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J4X9b1nRsz521w; Thu, 2 Dec 2021 10:23:47 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "R3" (verified OK)) (Authenticated sender: dim) by smtp.freebsd.org (Postfix) with ESMTPSA id 067722BCFA; Thu, 2 Dec 2021 10:23:47 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtpclient.apple (longrow.home.andric.com [192.168.0.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id DAF3A56363; Thu, 2 Dec 2021 11:23:45 +0100 (CET) From: Dimitry Andric Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_43BB1695-2407-43C1-8516-107F604811E0"; protocol="application/pgp-signature"; micalg=pgp-sha1 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: failure of pructl (atexit/_Block_copy/--no-allow-shlib-undefined) Date: Thu, 2 Dec 2021 11:23:37 +0100 In-Reply-To: Cc: FreeBSD Current , Jessica Clarke To: Kyle Evans References: <20211202020326.GU35602@funkthat.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1638440627; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=3oWwxHFhIoBoGpkoVZtU5HQhCg1KauiE3QyQVOrUdzo=; b=tAobhnwGauwy9Ve8clmeoJACy6evch4zsU+OKiFQgkkAdPyqLu0Q4YpdWBk3eHW7gCWxkW b3PmNJ7Q22ZXKroeJxlOZzg/oxFwAua/f2nA6rH/gBzWOWsTVLYp03+rf+6hGDIwc83wT/ ont+jpf1nv98Gdqdns7xL4fjoLLqp5rj3IG8SKy9vIJ02RvuFRPA54+FvoPak2aW4SD6sf r+ij09ApvS3GGPADw/FRBt0zqb2gpiSo53+cKE/PAYYIHZrm9I9NIvYYzBa+EL9uSxultf JFxWZgY0NkooH9ck9Q85tkAonDrp0GuEDATb4w92SEw1NsDv5MAos4xy84Llbw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1638440627; a=rsa-sha256; cv=none; b=XQDCwUfnogA0g65uMN/neb1Uumr75CI78X9xMdONcTOnt/MwwrdIokj4PtK0ueQ4VkzDNK vmREiiXBTrYtCYGM8xdSAYNsMZsLZtQOHRggX5t426X21+9XTYE/HNTKtKcRJPwGtg0Eek Tgyw1ELnx986rxVistBrTkpguTjJSS3vNxZ9KsFAU9iX0McsjV2LjOnO826tlPLiptpZlg TFUubQrqDiSyy3EGQx10JPnyWuE2lGdpi/76b7xXToYaYpGz//64H9AANEXeVWzAYRmIEG wgF70AVlYU4kyw8uM7skXeai5iRXeqtNKomqgCcQ5mEYb2uMqu5ymmYycBAK4A== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_43BB1695-2407-43C1-8516-107F604811E0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2 Dec 2021, at 06:42, Kyle Evans wrote: > On Wed, Dec 1, 2021 at 8:05 PM John-Mark Gurney = wrote: >>=20 >> Hello, >>=20 >> It seems like the recent changes to make --no-allow-shlib-undefined >> broke pructl. >>=20 >> lib/libc/stdlib/atexit.c uses a weak _Block_copy symbol, but >> pructl does not use atexit_b, and yet gets the following error: >> : && /usr/bin/cc -Werror -O2 -pipe -fstack-protector-strong -isystem = /usr/local/include -fno-strict-aliasing -std=3Dc99 = -fstack-protector-strong CMakeFiles/pructl.dir/pructl.c.o -o pructl = -Wl,-rpath,/usr/local/lib: /usr/local/lib/libpru.so && : >> ld: error: /lib/libc.so.7: undefined reference to _Block_copy = [--no-allow-shlib-undefined] >> cc: error: linker command failed with exit code 1 (use -v to see = invocation) >>=20 >> What is the correct fix? It seems like atexit.c or the linker should >> be fixed, as pructl doesn't use atexit_b at all. >>=20 >=20 > CC dim@ and jrtc27@... this seems like a toolchain regression? We're > relying on the address of weak _Block_copy to simply evaluate to NULL > if it's undefined here, which seems legit and pretty well-defined at > this point from my recollection. Naive patch, which appears to work: diff --git a/devel/pructl/files/patch-CMakeLists.txt = b/devel/pructl/files/patch-CMakeLists.txt index f378dd44e6f6..8a41cc91aba8 100644 --- a/devel/pructl/files/patch-CMakeLists.txt +++ b/devel/pructl/files/patch-CMakeLists.txt @@ -1,9 +1,16 @@ --- CMakeLists.txt.orig 2018-12-24 20:28:37 UTC +++ CMakeLists.txt -@@ -8,5 +8,5 @@ find_library(libedit NAMES edit) +@@ -4,9 +4,10 @@ add_executable(pructl pructl.c) + add_executable(prudbg prudbg.c) + include_directories(/usr/local/include ${CMAKE_SOURCE_DIR}/../libpru) + find_library(libpru NAMES pru PATHS /usr/local/lib = ${CMAKE_SOURCE_DIR}/../libpru/build) ++find_library(libBlocksRuntime NAMES BlocksRuntime) + find_library(libedit NAMES edit) find_library(libutil NAMES util) - target_link_libraries(pructl ${libpru}) - target_link_libraries(prudbg ${libpru} ${libedit} ${libutil}) +-target_link_libraries(pructl ${libpru}) +-target_link_libraries(prudbg ${libpru} ${libedit} ${libutil}) -set(CMAKE_C_FLAGS "-Weverything -Werror") ++target_link_libraries(pructl ${libpru} ${libBlocksRuntime}) ++target_link_libraries(prudbg ${libpru} ${libBlocksRuntime} ${libedit} = ${libutil}) +set(CMAKE_C_FLAGS "-Werror") install(TARGETS pructl prudbg DESTINATION sbin) -Dimitry --Apple-Mail=_43BB1695-2407-43C1-8516-107F604811E0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCYaieqQAKCRCwXqMKLiCW o8BQAJ9ugzkvc0g6gFofIgxiYSqP69iUiwCg7fZv2BHLWvK7iWTSBTSdqpQ4yhY= =ilTB -----END PGP SIGNATURE----- --Apple-Mail=_43BB1695-2407-43C1-8516-107F604811E0-- From nobody Thu Dec 2 10:32:09 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id A914618CBD24; Thu, 2 Dec 2021 10:32:21 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4J4XMS0XGTz54cK; Thu, 2 Dec 2021 10:32:19 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from kalamity.joker.local (123-48-130-181.area1b.commufa.jp [123.48.130.181]) (authenticated bits=0) by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 1B2AWAgk098716; Thu, 2 Dec 2021 19:32:10 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Thu, 2 Dec 2021 19:32:09 +0900 From: Tomoaki AOKI To: freebsd-current@freebsd.org Cc: freebsd-ports@freebsd.org, Brooks Davis Subject: Re: Problem compiling ports Message-Id: <20211202193209.67b8696b5a74803b99ad8190@dec.sakura.ne.jp> In-Reply-To: <20211130224537.GE75149@spindle.one-eyed-alien.net> References: <28612702.6783053.1638293085302.ref@mail.yahoo.com> <28612702.6783053.1638293085302@mail.yahoo.com> <20211130174530.GA75149@spindle.one-eyed-alien.net> <20211201065756.b8d50b150a88b0181f24ad89@dec.sakura.ne.jp> <20211130224537.GE75149@spindle.one-eyed-alien.net> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4J4XMS0XGTz54cK X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp has no SPF policy when checking 153.125.133.21) smtp.mailfrom=junchoon@dec.sakura.ne.jp X-Spamd-Result: default: False [-0.67 / 15.00]; RCVD_TLS_LAST(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[sakura.ne.jp]; AUTH_NA(1.00)[]; TO_DN_SOME(0.00)[]; HAS_ORG_HEADER(0.00)[]; NEURAL_HAM_MEDIUM(-0.89)[-0.893]; NEURAL_HAM_LONG(-0.27)[-0.265]; NEURAL_HAM_SHORT(-0.91)[-0.914]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[123.48.130.181:received] X-ThisMailContainsUnwantedMimeParts: N Confirmed. Thanks for your quick reaction! On Tue, 30 Nov 2021 22:45:37 +0000 Brooks Davis wrote: > Yeah, I've got this in progress. > > -- Brooks > > On Wed, Dec 01, 2021 at 06:57:56AM +0900, Tomoaki AOKI wrote: > > It would be better making new special handling like BE_AMDGPU for it. > > Building with BE_STANDARD just for this would be a pain for some users. > > > > (CC'ing freebsd-ports ML.) > > > > > > On Tue, 30 Nov 2021 17:45:30 +0000 > > Brooks Davis wrote: > > > > > In the config for devel/llvm11, is BE_STANDARD enabled? If not, you > > > won't have the web assembly backend. > > > > > > -- Brooks > > > > > > On Tue, Nov 30, 2021 at 05:24:45PM +0000, Filippo Moretti via current wrote: > > > > error: unable to create target: 'No available targets are compatible with triple "wasm32-unknown-wasi"' > > > > 1 error generated. > > > > gmake[3]: *** [Makefile:380: /usr/ports/devel/wasi-libc/work/wasi-libc-ad5133410f66b93a2381db5b542aad5e0964db96/build/dlmalloc/src/dlmalloc.o] Error 1 > > > > error: unable to create target: 'No available targets are compatible with triple "wasm32-unknown-wasi"' > > > > 1 error generated. > > > > gmake[3]: *** [Makefile:440: startup_files] Error 1 > > > > gmake[3]: Leaving directory '/usr/ports/devel/wasi-libc/work/wasi-libc-ad5133410f66b93a2381db5b542aad5e0964db96' > > > > ===> Compilation failed unexpectedly. > > > > Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to > > > > the maintainer. > > > > *** Error code 1 > > > > > > > > Stop. > > > > make[2]: stopped in /usr/ports/devel/wasi-libc > > > > *** Error code 1 > > > > > > > > Stop. > > > > make[1]: stopped in /usr/ports/devel/wasi-libcxx*** Error code 1 > > > > > > > > Stop. > > > > make: stopped in /usr/ports/www/firefox > > > > > > > > ===>>> make build failed for www/firefox > > > > ===>>> Aborting update > > > > > > > > > > > > ??File "/usr/local/lib/python3.8/site-packages/setuptools/dist.py", line 799, in > > > > ?????? eps = map(lambda e: e.load(), pkg_resources.iter_entry_points(group)) > > > > ?? File "/usr/local/lib/python3.8/site-packages/pkg_resources/__init__.py", line 2449, in load > > > > ?????? self.require(*args, **kwargs) > > > > ?? File "/usr/local/lib/python3.8/site-packages/pkg_resources/__init__.py", line 2472, in require > > > > ?????? items = working_set.resolve(reqs, env, installer, extras=self.extras) > > > > ?? File "/usr/local/lib/python3.8/site-packages/pkg_resources/__init__.py", line 772, in resolve > > > > ?????? raise DistributionNotFound(req, requirers) > > > > pkg_resources.DistributionNotFound: The 'packaging>=20.0' distribution was not found and is required by the application > > > > *** Error code 1 > > > > > > > > Stop. > > > > make: stopped in /usr/ports/devel/py-pycparser > > > > > > > > ===>>> make build failed for devel/py-pycparser@py38 > > > > ===>>> Aborting update > > > > > > > > FreeBSD sting 14.0-CURRENT FreeBSD 14.0-CURRENT #62 heads/main-n251146-d109559ddbf: Mon Nov 29 12:18:48 CET 2021???????? root@sting:/usr/obj/usr/src/amd64.amd64/sys/STING?? amd64 > > > > > > > > > > > > > > -- > > Tomoaki AOKI > > -- $B@DLZ(B $BCNL@(B [Tomoaki AOKI] From nobody Thu Dec 2 10:34:35 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 928CA18CDC4B for ; Thu, 2 Dec 2021 10:34:40 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J4XQ834nDz56XM for ; Thu, 2 Dec 2021 10:34:40 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtp.theravensnest.org (smtp.theravensnest.org [45.77.103.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: theraven) by smtp.freebsd.org (Postfix) with ESMTPSA id 453B92BB16 for ; Thu, 2 Dec 2021 10:34:40 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from [192.168.1.202] (host86-166-82-189.range86-166.btcentralplus.com [86.166.82.189]) by smtp.theravensnest.org (Postfix) with ESMTPSA id 8C1CE2D8EA for ; Thu, 2 Dec 2021 10:34:38 +0000 (GMT) Message-ID: Date: Thu, 2 Dec 2021 10:34:35 +0000 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Subject: Re: failure of pructl (atexit/_Block_copy/--no-allow-shlib-undefined) Content-Language: en-GB To: freebsd-current@freebsd.org References: <20211202020326.GU35602@funkthat.com> <75CCC6A8-F777-48F9-9AC7-5A08FA9CCD25@FreeBSD.org> From: David Chisnall In-Reply-To: <75CCC6A8-F777-48F9-9AC7-5A08FA9CCD25@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1638441280; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=XetTbBT2mGDM8Ow6f/Qmt4NEPenBFzc6pijnKf6kyEE=; b=LiuURoD8CuJpqObWhjvzASsXpmVYKhEaIttt9vSTcExlrY/k5vezEitaZrxvEJvjrwVDhb E/T83UXadt793ElCNpjilj7XMHFjLqhSSh+mLemQdA/cSDB2sB7AtLkeoSx9pwjczZ0yeI sVE1ZT+ND/YlF5a/AAdYaw7haWe4xO3J1+y2W7ttA5OuzvDbVqgFhbZRjCxY84yWlPBt0z Rzs80dTKhH3WFisvcLuod1O9Pq3Q+4PSe5MM/YXyUfpmpM5kHFLFE2Jroo00dwLnrpSPUO Biyk6fVmM4j0l638AWQIyr/mqDmhWnGdyhdw0rbsmNKsPa3Ev89/qUp9H4ZaDQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1638441280; a=rsa-sha256; cv=none; b=GOgcxCeuRCD3c3hZKI8YrsuL1334FmM0E1a+z7C5u3utU4lCdo1eKNAbG+ny74GH2ExUKz B4wFyTIyCZUO8mPQRzUwlZHCQZIWgXATgUyewcHF8+fQLQrJQY4Ds83LIGLnxoAPhRYzQX gy0aTSdHa7EEVueHzg3CmM9QgbrFZ3DTzioA10jHwqQhydvBeuw7760I4WmOvPosA4ZwOn 0Bu87dbx5XYSD1UjOK1Ef5WnUldSSGDSO5+CC1Fjjv6VW/yeW1EhmMZ2pAYUaAamqUjedF pWJtXxn6spiFAXYm/ptSppg6w5/ONtzLBux6YTKANwKErEm5U4q5S/fLdW6zkA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 02/12/2021 09:51, Dimitry Andric wrote: > Apparently the "block runtime" is supposed to provide the actual object, > so I guess you have to explicitly link to that runtime? The block runtime provides this symbol. You use this libc API, you must be compiling with a toolchain that supports blocks and must be providing the blocks symbols. If you don't use `atexit_b` or any of the other `_b` APIs then you don't need to link the blocks runtime. I am not sure why this is causing linker failures - if it's a weak symbol and it's not defined then that's entirely expected: the point of a weak symbol is that it might not be defined. This avoids the need to link libc to the blocks runtime for code that doesn't use blocks (i.e. most code that doesn't come from macOS). This code is not using `atexit_b`, but because it is using `atexit` the linker is complaining that the compilation unit containing `atexit` is referring to a symbol that isn't defined. David From nobody Thu Dec 2 16:26:55 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id A634518B4239 for ; Thu, 2 Dec 2021 16:26:57 +0000 (UTC) (envelope-from se@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J4hDd2r10z4VTP; Thu, 2 Dec 2021 16:26:57 +0000 (UTC) (envelope-from se@freebsd.org) Received: from [IPV6:2003:cd:5f23:1000:bdef:2b4d:c5d2:547f] (p200300cd5f231000bdef2b4dc5d2547f.dip0.t-ipconnect.de [IPv6:2003:cd:5f23:1000:bdef:2b4d:c5d2:547f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: se/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id DEB842EC01; Thu, 2 Dec 2021 16:26:56 +0000 (UTC) (envelope-from se@freebsd.org) Message-ID: <7d97e129-4aa7-aa98-dc91-e332a3da620f@freebsd.org> Date: Thu, 2 Dec 2021 17:26:55 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US From: Stefan Esser To: FreeBSD CURRENT Subject: [REVIEW] Hide BIT_* macros from userland code Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------0GDF0Nbe9QfsG7VR0JvLVPqs" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1638462417; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=p7GWyF8hmZ1ilRkPnCRQRJF337elqapLWLNvYEfNv0M=; b=Q/FTfvvh+pRDOT2meEsRwA/7LhiyDWKlkTIt8vfpgQS3dvTlkACk85KeGmF3i48jovPHgh nC6iqc60ZburPrF1avO0ieWSxJ3NGEpYlQsMjEkVuMYH+ZhtCrZei2iAcoRespKI6zBKN7 FaU+03Gg1uBcWm6XghFzaFsZVieohCEZbLu7b9iqAscLeAcuRzhS2ZcTGqjU3SwTPJZLTm uk+PQR83mEhSr47QwKrRi15t5LN1morYc2ROZrVjQ92Q0KPxG8YcL+vayTQSS/XQlfF9Tw P4mWVzTxRbOnQqt3xjgBVg4S99UQrKVmqyAo8B75GXoSGkil2+OWkdesVPF6Jg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1638462417; a=rsa-sha256; cv=none; b=yDLzKgIClqbbAu+F9zuKj5NxYeC/k5KtLy3m6GIMuflZqKpxECRcC1vIq777dchoPuyeUx Kkk3SEz9F9Y4crw7B16CxKNLVTiWWSUXGYV/aPKf8AVKIWW836yyRWO8KWEDHjvGEWxoTG JAO2zSeFnMxcNL/pVawjCw5G5GkvtVVk5okMjU7TzqrBlQvap51NvqJ5btxOK0tGrNuO3q fSbguqOzcfAtrGAe8DkmbZA0Z55mIbClwBJpYxGdO9qthepAlRKnM+5m6sXEsBjyUul347 C+a1w2ficPIe+2EJalIkfYOPF7MoBdNDKSojzdm6Vl5RCAd3YjRZTfhNgYfDBA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------0GDF0Nbe9QfsG7VR0JvLVPqs Content-Type: multipart/mixed; boundary="------------ZsgtkZCa46LQKkwYhi08um5P"; protected-headers="v1" From: Stefan Esser To: FreeBSD CURRENT Message-ID: <7d97e129-4aa7-aa98-dc91-e332a3da620f@freebsd.org> Subject: [REVIEW] Hide BIT_* macros from userland code --------------ZsgtkZCa46LQKkwYhi08um5P Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I have created https://reviews.freebsd.org/D33235 to remove the BIT_* macros used in the kernel from the userland API. They conflict with differing definitions in some 3rd party code and lead to compile issues in a number of ports (via CPU_* macros based on the BIT_* macros). See PR259787 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D259787 for an example of such a problem. --------------ZsgtkZCa46LQKkwYhi08um5P-- --------------0GDF0Nbe9QfsG7VR0JvLVPqs Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEo3HqZZwL7MgrcVMTR+u171r99UQFAmGo888FAwAAAAAACgkQR+u171r99US/ gQf/WamgosJox4dsMTUuoQR1wGl8CP9FfRfyoLj9acS1qi6o++QzO/js3aV15O5hGa30GalKkL+U 7RRFlt0GpwZY5cnSgeND4EVj9EIPZVa59TDT2mFG/0An0f1I8j1SNHhd0Q/MCQbHBIhMsZU10z2e rTmP1It+ggZeVFEVx1kDo+PR3G1hjXDciPfx9qYxWz44lRS42rLAy6VV2ZWBkJtcY8RKjFy3gu5R mExDs+iAGYtlRUetbRPAtbXDw+8H3l6mLRl9W1D+GTpQG0AudvlLWVjpzAN0P+Sy+bsyrxy0+VV/ S6HUSR0Gq0EOpv+5ES2GdkKficKDBlNX/Eexrv0XxA== =Lama -----END PGP SIGNATURE----- --------------0GDF0Nbe9QfsG7VR0JvLVPqs-- From nobody Thu Dec 2 16:46:48 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C6BC318BF040 for ; Thu, 2 Dec 2021 16:46:49 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J4hgY4tJtz4fCL for ; Thu, 2 Dec 2021 16:46:49 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qk1-x72a.google.com with SMTP id a11so469088qkh.13 for ; Thu, 02 Dec 2021 08:46:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=FKJPmLBSaEBFirqvfgcQI95qni9WRD2MxlMgO/rodZ0=; b=jcLJtrZLPxq08j0gVvY1aR0vPF8YGikJDsz7n8wyiyobQx4lmK2W6PnL2lIJiZXvXd ZTj2WK1mABKI9vd9xXYx2sewCI0h6ix5W6d9mhpCY1FEVwSJK/ugo3+1Xlsv9iyq4o/T EZ5XUvmpLCN7rysNW4a2PvL8x72M2+2SyBBQkA6oEoAr3TjYYt/Pp1blmzBulHUgNLMC KNc5no3NfrSddNfEI7jxK17zuvjVOZTqsIc/DGKVTcO09LStXUCJSUV2OgS3bjhDMZ/b u/KdV2U/L49BLo7I7kHNGVhgkiptEgvg0jgSZYjtM/g0oqT75C79XhqovM04cDuGGCY9 Vl/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=FKJPmLBSaEBFirqvfgcQI95qni9WRD2MxlMgO/rodZ0=; b=4XnYBpWSOaOoU+ULYsIdhyfAZ4e4uKz8IzhTkAQ7+Le4IoJzGDOf/d8abaLqlOTFqg A6Pj6Gr7U9EDq/qxhzoq3bT7z4S8H5grX0+bY3QwH/p1LlDdBadT7XFJG6mZ9kHPba9j MobAWobgmCHWY4t/MyKFektpfIawBB4MpCjIRiEvTMKxt8VSdHVLf3NXhkVWY47sykV5 EsfUVEHyZgMnf6ls6kcshr+Ya15zT9UneqBpuSBdPS34L5bG3jFr2fGcqr2TNcnj7B+i BLNOYbhAsAdO/J6jkW3MO4BT3leVlyQKSZ1CofM0i55u+bFgP+fWxh9/kTAZACSXQo3Q BoKw== X-Gm-Message-State: AOAM530uKHZ27cKoIDbBMQEbNAZXV4fLrHWOiRWXlW5ss/tYQy4aHE+2 2Paf5E6K8X6BUmjNLchziLEdMKPcabcgUA8U X-Google-Smtp-Source: ABdhPJzUq7jcy/MWh2kK+xkCCn9F8UKZc6i960qpNC6ZVtrbNes+Tw4pPC41JZGqUEFhq6asSvZmaQ== X-Received: by 2002:a05:620a:15c8:: with SMTP id o8mr13782030qkm.385.1638463609178; Thu, 02 Dec 2021 08:46:49 -0800 (PST) Received: from mutt-hbsd (pool-100-16-224-136.bltmmd.fios.verizon.net. [100.16.224.136]) by smtp.gmail.com with ESMTPSA id o1sm153275qtw.1.2021.12.02.08.46.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 Dec 2021 08:46:48 -0800 (PST) Date: Thu, 2 Dec 2021 11:46:48 -0500 From: Shawn Webb To: Stefan Esser Cc: FreeBSD CURRENT Subject: Re: [REVIEW] Hide BIT_* macros from userland code Message-ID: <20211202164648.276kuh3blin6b2wp@mutt-hbsd> X-Operating-System: FreeBSD mutt-hbsd 14.0-CURRENT-HBSD FreeBSD 14.0-CURRENT-HBSD X-PGP-Key: https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/blob/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc References: <7d97e129-4aa7-aa98-dc91-e332a3da620f@freebsd.org> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="o5zlasg5gkhqto6j" Content-Disposition: inline In-Reply-To: <7d97e129-4aa7-aa98-dc91-e332a3da620f@freebsd.org> X-Rspamd-Queue-Id: 4J4hgY4tJtz4fCL X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N --o5zlasg5gkhqto6j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hey Stefan, On Thu, Dec 02, 2021 at 05:26:55PM +0100, Stefan Esser wrote: > I have created >=20 > https://reviews.freebsd.org/D33235 >=20 > to remove the BIT_* macros used in the kernel from the userland API. >=20 > They conflict with differing definitions in some 3rd party code and > lead to compile issues in a number of ports (via CPU_* macros based > on the BIT_* macros). >=20 > See PR259787 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D259787 > for an example of such a problem. I recently was in a position to evaluate BIT_* macros for userland use. It was around the time when the conversation regarding hiding BIT_* from userland, which conversation caused me to find another solution. I think such an API is incredibly useful, so I wonder if there's a way to satisfy both. For example, maybe prefix the userland side with a USERLAND_ or something similar? Kernel would use BIT_* and userland would use USERLAND_BIT_* (just spitballing, not actually advocating for "USERLAND_BIT_*" but rather just the idea of it.) Thanks, --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A= 4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc --o5zlasg5gkhqto6j Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAmGo+HUACgkQ/y5nonf4 4fr6eA//ZcS4ZmNskfxlZ3rciKWU6mWAkmAZ8e4Gt/YHdpziSCIl/zNdEbma1Ohn vcApMcqlZ4/Hwe9IChbyi5V5Luh0RVg418cZ2MyPKuxNWAPh4SxlL+ODhaaZHWif ZOBfbC4QoejinEPgeMgYLxMtdaEBlTB5vnL/e5DkACznmGB5/2W8I00HFUhy15n/ CrnGauN6MYk7aXs5cnXdv96eHwL+dhqYpFvl1wwQReBE5I9hKFkNgs+qYWaUlcpO 5r9OlsGoqeoYuagtzu6vZeIqdbK9G32fE1PGbTBbBYOmVBle2S+4bBZV6nsgbUBX TtHVkVL740/Bh7O8VsmiXfmvu+Cazb+4SaBprCVb5IcS2AWapLrfa08i+oDweLda nggtNwPkioSUwYPGI4DfHTaqnVwc/KZVuxTmfTenrfb66rjtFGfmbyADKpcz5Fi9 22o0eAOt160FBj7Ld635432XjPVapwLvfC84r+nuTpw9HxSgwINicBqMNf5pSdCq CNaLHiVR9v+TnW59GCR538GVyD5TtLAyHZGuwIcsxQrV6YnMoPrKR6j7l06ZWKeH simpqlej4Py4y04ijYNepRQRxZU94yY2CpgEC5vdjuAR2kiZHsVKzf3ibwMR4A0s jkZmPkaNCAqxLq31LBrVNJIllvgVmJkxVa3OHQePzVEyvr+cJZs= =8mR8 -----END PGP SIGNATURE----- --o5zlasg5gkhqto6j--