From nobody Sat Aug 5 22:35:14 2023 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 4RJHTk0Wwrz4TrBB for ; Sat, 5 Aug 2023 22:35:22 +0000 (UTC) (envelope-from grahamperrin@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 4RJHTj74qXz3Vbl for ; Sat, 5 Aug 2023 22:35:21 +0000 (UTC) (envelope-from grahamperrin@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1691274922; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=QstVRmNLmJamqyrFZuFNOmpRsO9gqwVenw2AOxA7UaY=; b=Vm/N+RBlFzyxobkUVhtpR4cQpdmrbSXnDrRwfLCa/ZmYyAT8YwkuPluiOI0SMG2+E5Kdru ZaV6+MO2/apxF4I+V9zzE4Kr5kng3mjZexVLuv8iCxddw88F13No8b3ssv+E9t0VGWML79 8JoFgMP8Gs6zgutT7f3znvB9UgrqqpIWMBdS9HJkARkhlKaC8hlUB5uHy6JVz0f4YYrwBG LoHpEbAHLPrNM0BcTU/MzQWQZVAMg8vwHKILYpMfHAhs0WOf5YDZX02GQ2fMqC+rEdcqvn SkfVql6mBCR12PUttmU/xZlCrRmjqE9y8OwJNWEhkkMtCkX2wqluVXESWdDBjA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1691274922; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=QstVRmNLmJamqyrFZuFNOmpRsO9gqwVenw2AOxA7UaY=; b=myKcOIad1DT/JermQ+Q1B1iiLD1fsm8O7QfiB/ifSEXDZ1arFzs+91c3Ry8/n2WTBmKI88 2RvFGaYY/DX8LIiUKSFFYkCO/o4uB0XS5tJQIobvYYm3jIaX/pwW2cQKwTmK+yjVCDTwsi BFqq4NwoiNUKg5E5/ak5rneCXWwwRrZhZuNkXUOO7t076/+utv2GUppoQ6inyhZqCbzDxR 2TRRjEabRHtNmPNnuBqXt1pKi/mpRwSE/EGt2VQo8Yf6mWPPAbSQX/GsVXkALb5sBrguuW N3eT4PQ3WxRdC3z8Qb2MpcIMV3x6JaxPKfdwbvT6tt3p7taiVi2n3brSDb0qTg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1691274922; a=rsa-sha256; cv=none; b=cBI4YNlyND75K8mb0a/5DVY00YE9sogo+LEn/l2XUqwSYxEscLzR4BlV5RKfrRPx1npZcJ lLecNkh/Lu5q6iZsqoiom10Oz+WMy9iXCXzo78gfsOqxrcDhxM5ZnLNurf/csIfi3LFH5f bCFeh47tfcQl7BCG5d+0XSydPFhDuEXoJjwqlVGFBjzeZPZen3MfM5+VRxVRD1/ap/kbkX +vBW2hu1JU9Ih0/Dk6Lpmlm74OZHEOlZuGirbvSbBjsPJcP6CUBWnY+3c6HeoYkYg4G5Qy XcTwzGFJzfSa1NhNTPHu2CYqGM6y8ahDD2I5Pf//1KACcaip6+9OpWijuEZdqw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from [IPV6:2001:470:1f1c:a0::2] (tunnel642390-pt.tunnel.tserv1.lon2.ipv6.he.net [IPv6:2001:470:1f1c:a0::2]) (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 did not present a certificate) (Authenticated sender: grahamperrin) by smtp.freebsd.org (Postfix) with ESMTPSA id 4RJHTj4ft4z1f00 for ; Sat, 5 Aug 2023 22:35:21 +0000 (UTC) (envelope-from grahamperrin@freebsd.org) Message-ID: <354756c9-29e0-db1f-269e-3c219b5d9ac8@freebsd.org> Date: Sat, 5 Aug 2023 23:35:14 +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:102.0) Gecko/20100101 Thunderbird/102.13.1 Subject: service routing restart (was: Unreliability with DHCP) Content-Language: en-US From: Graham Perrin To: freebsd-current@freebsd.org References: <62d300c8-2c3e-58fa-334e-23a17962279a@freebsd.org> <753f3990-9903-3718-445c-49fc01f960a7@freebsd.org> Organization: FreeBSD In-Reply-To: <753f3990-9903-3718-445c-49fc01f960a7@freebsd.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------vJZ3q2cnVhR3Bc4R9ZXBXmw7" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------vJZ3q2cnVhR3Bc4R9ZXBXmw7 Content-Type: multipart/mixed; boundary="------------DRXYFax8XQeBE0sKHs57kXus"; protected-headers="v1" From: Graham Perrin To: freebsd-current@freebsd.org Message-ID: <354756c9-29e0-db1f-269e-3c219b5d9ac8@freebsd.org> Subject: service routing restart (was: Unreliability with DHCP) References: <62d300c8-2c3e-58fa-334e-23a17962279a@freebsd.org> <753f3990-9903-3718-445c-49fc01f960a7@freebsd.org> In-Reply-To: <753f3990-9903-3718-445c-49fc01f960a7@freebsd.org> --------------DRXYFax8XQeBE0sKHs57kXus Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMDUvMDgvMjAyMyAyMzoxNiwgR3JhaGFtIFBlcnJpbiB3cm90ZToNCj4gT24gMDUvMDgv MjAyMyAxMjozOSwgT2xla3NhbmRyIEtyeXZ1bGlhIHdyb3RlOg0KPj4gMDQuMDguMjMgMTk6 MDcsIEdyYWhhbSBQZXJyaW4g0L/QuNGI0LU6DQo+Pj4NCj4+PiDigKYNCj4+Pg0KPj4NCj4+ IEFzIGRpcnR5IHdvcmthcm91bmQgSSBoYXZlIGluIG15IC9ldGMvcmMucmVzdW1lDQo+Pg0K Pj4gc2VydmljZSBuZXRpZiByZXN0YXJ0DQo+PiBzZXJ2aWNlIHJvdXRpbmcgcmVzdGFydA0K Pg0KPiDCoOKApiAnc2VydmljZSByb3V0aW5nIHJlc3RhcnQnIGNhbiBiZSBwcm9ibGVtYXRp Yy4gUGxlYXNlLCBzZWUsIGZvciANCj4gZXhhbXBsZSwgPGh0dHBzOi8vcGFzdGViaW4uY29t L3Jhdy9tWG1WUHJ1cT47IEkgaGFkIHNvbWV0aGluZyBzaW1pbGFyIA0KPiBhIGZldyBtaW51 dGVzIGFnby4NCj4NCkFmdGVyICdzZXJ2aWNlIHJvdXRpbmcgcmVzdGFydCcgKGFsb25lKSwg c2hvdWxkICdyb3V0ZSBzaG93IGRlZmF1bHQnIA0KZmluZCBhIHJvdXRlPw0KDQo8aHR0cHM6 Ly9yZXZpZXdzLmZyZWVic2Qub3JnL1A1OTkkMjk+DQoNCnJvdXRlOiByb3V0ZSBoYXMgbm90 IGJlZW4gZm91bmQ6IE5vIGVycm9yOiAwDQoNCg== --------------DRXYFax8XQeBE0sKHs57kXus-- --------------vJZ3q2cnVhR3Bc4R9ZXBXmw7 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEWT/lssMHB+28ly8Kt2dIb0oY1AsFAmTOzqIFAwAAAAAACgkQt2dIb0oY1Ath 9A//Wbkha/C/5PPAHyUc2rk7+DNIrDR47owUKi/RDKe1p2fRbGvoCH1fzUp6+HVQxscNXaNEpwHm v5rKT8J0eZASTl/aLlgFeIfD6tSs6DQejrVlBh4uQ+Io046wOyPOWbdmqseFyZJ9934a3pW3zs08 6trqb5CMGEdnawqWg0iCPCQttDcxqGfoAxJ5uBCQeNM2UCT93BTr1WTVITlxF6k37qXyXTaZbAu6 XTOGRRprpFd9mqmEnczGBgpR1I7guKZqgyz18inG0eG6RwV98BAnTMpNG1AEfkK5YHqC2c0BvaNG XY+uuyZldu1haOj2w9TVEQaOczzbNWugF37CdXWm7ppHyNY+9fB3JBZrV1skC2njmc9obbxEaNTn yM5HmDsvUNXFcuTLdC4PRPQ0HGOCtzT/HJIRgJ7KYeHfTYSISKjnBV/AK3mPJlA5tQVyjssLQzTd aVfVcsCW2fwit30wxFg8bcxSusfbeDGFmDnX4OaZk/38AJb9u9Dcb/UxxirUC4Bp1dW6+Bodp+88 GS8jy7icNIdfNvyG+qVs1NOX7bPOvqQnOgvBmstLP6/yjKjSP3OAy7ESp5hgsx/BpMh8B20rx1X0 MKwyPeDS1PBzaQbyDfnqRmKL1IOIlgxb177auBZRjljcOWLDx+UYsUhMCwEJXHNWP8Eyi1LK50ic Bn0= =peni -----END PGP SIGNATURE----- --------------vJZ3q2cnVhR3Bc4R9ZXBXmw7-- From nobody Sun Aug 6 01:56:59 2023 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 4RJMyr0YDcz4mBGy for ; Sun, 6 Aug 2023 01:57:24 +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.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 4RJMyl5G7nz4JCk for ; Sun, 6 Aug 2023 01:57:19 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=ODojWmIW; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1691287036; bh=K7SsTSsVvdglCJhARp7YmlL2STiKFUBRmSEp02kIARo=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=ODojWmIWdgKqQ5HeonG+GydxYINDFXLS5/Bmzk28CBbWkFiAKUPymf/2odKLnS1ebwVlOH9lhoEIKZmB2yNKFEz9eoUYrTdw8jL/FZ/15l9lnLenLKzBFrqoDALjTg/FDGMFfV2MPC4hcH72koLZ5Imbfds4lL5S+Xg0SgKPJPCHgldiL0wjvqiUlDJ8owfS5wXVsgLayDpfaX8s41CMk/uIm+hMAZMhSN5THLOuqH/tfFGYW7C8y2Am8cTMrbaatjn2IfAwXLBTfLcrQdSURbsHDNrdUczX9+M1t3YQFi5HiyF9IvRwdLq9LzobiSs3gvBw6Sqr9sl0pKfTnfFedg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1691287036; bh=mctKiwSVK9u/S9ZljigScmXPGW3gRBgHOV+6oDMLGUb=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=C6NFszJpv6QfcEvreD6HwlxU7diUMOl2mReBYGyOZ9eV/ORIj32azLjbDF8uIPL8U/A+wZuLwe+9a2BslnuA4EGc+sBGdZ+mxufKllavk1m1gkVnsH5HO6i0S9WuR7bQZioHiuTwC6zSgqaUG6oUKdYW4YSxBUaivauQvbeQh+7YphO2cD7dpmPqj3/XJPCTZ1UWtNJfktWE54tcFEsoUGVhSe5C3zS6WY5TksvsC/ZgX7hAlbXJUBixtm1nmsfUiTXCIUFs7Lb2vnDX2QX7utZsHJh+EfIfasqc0Nwm9J3xvsEzMo4PYIfZUUkeybwBu2ujzNo3DKz5bSypb4j2PA== X-YMail-OSG: iW1JtKgVM1mXyaNbqPph9Fexqxa5EZWvr.OGZOiT50sPYZWEEnCGJRazT6c_.s2 LdfRxR6BcWdavhrJlQKimYC.9duax_kHHDllsU3K5gpv9X.VttK3FyaYK.iK68yRMlLsQouXz0Z6 2cLWalNEGNtBexOUbF5P27Sk66bYWKTTeUeMXIGdN4RYD4.uJwMTuDkXmkAUNLtWha6dLXM.NVzy RkbaDC6OkVOtstZZnIb2fQhy6KZnMzLf._8RbaP.2sthqGxYxZQUyhQlprRR9TJ53Rs_k33IBGA6 3HIrssowG3f.fU58RvyhcFRyGbWJE1PEoi6r6w3graLLWY_3HtDRN.CAJjp70Hev6hPj5YKpC5jw hwnwTsDkgNYURp8pwpV_Zy5JbGUu20SekDkoNuc1_3.FjraMobOEImgWydBhdmwsXLw9s6z4YTNK 753F0aD2paRWhmWk1EKtSHZzwfzlESf0HrdzTwcsMRpfrdrG9RTmQAwdEU5MwMSkn90QG7JxWhCM hVOME5dM_NdfilDOJpGXxHDQN4m4CFdiu05jEaFBYgjdwNfebpEqwu7.A85AJjP8xSqrOuPSO.ea KtT7Cs8gGkGXuTIX1yf9ZmNCy5W56zDHb5ObIOgJccOUf.u9n4Gg3zb5L5gZPdnWpbIfmzwWDD3Q dNz7wXH0TmzTBAfiFtKEyCxmiI9QUcaA_C1N.zSymwAPQUM8WWY8tvFmDGYZZkOg04cCO3ZgHxM5 gtrd.QjLG1KNIHp5beD_qv9.B737AgVjvwmaUaVRpRqJ0W3N2L5c1I2JsrNuzHvzqPcsqeMVX9ea o.UagkyQvtBId_oDteMfej.h1FHZGYwD8aObboss6LHUAgdtQeeLLZAS_Q6lw_XktnpY6r2vEWSb iR7bmP8DIsED0OwUkHtOBp1b80XVbSrySjcIMlzeDQ8mcCoQhNqYbb3Um1zEu0kuXOK9JjCHicWw mrYUHzHShOD95x3gDmJ42OPUQNjkEaJHZCkxo8cXfsmWkv6vJmZCKtrHzR3zqlZaJxRcH7i_oXcJ geOIS0Uhfv.sFgzR4UoEmdfG1iO.j_i1b1XnHEez0GVj4.rJxKM0PwpKajcw15jt80VhPfHrvxKb dRSD00fjQVT7d04xasi5mWt9J59xl0bYhFV1G_iFu2_2sVONXabwDB72KDW.iCBfVBPbpnb7w6Dw W8ZWBc0Y65cJ6TzMpvnUJteUUFrnJVfTt46fhxmw7mX4Pra50ZsnsA50bErbqpeEgyc9Kcpib6xm eQ8k40m46xPb7VhyT7va5RjCec35PQazPL7vm9Lp7cQc6CgUcuO1yBoZfa7dsNs6Do9qrwNKN7Gx wXqzJGynTZzOfTDwCxLD3ZC4GR4PfZrq6CucaFXBuDdGZrVkoiXxwyewFNaSCVSJR65ikBwicADp 6vkEufehNdJXAGsoFlV5RYjJH8zYcFsXEaR0wfcFcMJPMYTInMfZ3L6r6dwejyGdhGOsQbF3TaR2 YtvkJTMRR4Zs2.yW62DUkJOGWb66Oz.Kdo0At1xyDfPy0xaneSoSoYxeeY_Uc42pyMVWh4FWhfnH EuYM3LZ10070Bf4PG8mEHJMg1WQQGhOnTRSJb85v1yHe662ZcVdq8R8DpqKsouXNtGbkuvEnatgT QrE6vSok.KbG3u6f5.y9f6oRc20NSP9gFDqXv3Ei0xQho3xJVK2EVU8KyVO5WNxKSlxLA5j.Cgpx mZiIa53cGqjKgVzMWGhJKRxVjQJCegPnJhg2tLB.dkC1InJ2VpZ48uxn4I1BmTdOtk2yVCBsW5jC nRx2nI9gc7rTzn9lY4NwFx7rjZehtrpSrj.EidnQUFVwdO70pNSWbpFfSU.hccNt0da7yiZmiGWa qH3MfG35YlKYmvuUGf0h_NONi4znK22GSr3bKF0IJlMPQVjijkrcFpqCY1ha6pRe66wHI2aE64qz 8VNWpXIJ8Ahd1iYmovoFslR8zKjXGQP3pVNNAe2Nd9LFaRhpU7_y1LBy7a1qgImtHp0tkImBB8hw IMYp59K3hKGDWH8bE8yWIih.NWHSMQI6txeDkIsMLoT6HqJal.5nBoEkOE8o_PXXSS5Xew2UKNB4 iLIR3zGfgEwBIcdD8eRFc8SCGDujOgCwRlzCIPgzrYS46U7gW8E0d.A.h0Sxbs.t7N8SPhgiehVW 8jGQyxXfA0ie9pj5i7qj7nH5_7.fcGwqJSzLvENH0kSUGgdgAjiM6jh_E.oMHnF9ZfZGsRevZxDS sNDWV..fHNMFraj8J7Fx62p12kkk4oqPgK_JUuqZ_srdEziC_hRs86OiehfTjdJ6e7DdUQ3CMPR4 - X-Sonic-MF: X-Sonic-ID: 4eb6b044-aea4-461f-8fcc-1e9acd1f6c8f Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Sun, 6 Aug 2023 01:57:16 +0000 Received: by hermes--production-ne1-549c7f6c44-9w7gj (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 80d85e8c78fb7a6a30138502f3ad336f; Sun, 06 Aug 2023 01:57:11 +0000 (UTC) From: Mark Millard 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 16.0 \(3731.700.6\)) Subject: I've shown the following 3 items via kyua testing with the latest snapshot of armv7 14 on a OrangePi+2Ed (Cortex-A7), a panic included Message-Id: Date: Sat, 5 Aug 2023 18:56:59 -0700 To: Mike Karels , FreeBSD ARM List , Current FreeBSD X-Mailer: Apple Mail (2.3731.700.6) References: X-Spamd-Result: default: False [-2.47 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.97)[-0.972]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ARC_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.206:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.206:from]; DKIM_TRACE(0.00)[yahoo.com:+]; TO_DN_ALL(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MID_RHS_MATCH_FROM(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_COUNT_TWO(0.00)[2] X-Spamd-Bar: -- X-Rspamd-Queue-Id: 4RJMyl5G7nz4JCk I've set up armv7 boot media based on: = http://ftp3.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/14.0/FreeBSD-14.0= -CURRENT-arm-armv7-GENERICSD-20230803-8a5c836b51ce-264491.img.xz for the OrangePi+2Ed (it also handles the RPi2B v1.1). No builds by me. The ports installed are from the FreeBSD servers and are for kyua activity's use, other than gdb. The presence of panic and large count of hours waiting for timeouts explain why this report only covers specific issues and no a full kyua run at this point. [I'll note that this activity has been driven by attempted testing of lib32, where I then end up with the question "is this unique to lib32?" and so end up looking at armv7 chroot on aarch64. More problems there --and so the question "is this unique to armv7 use on aarch64". This leads to looking at Cortex-A7 armv7 (a fully native armv7) context for comparison. I've had to wander well outside my original intended testing contexts and have ended up blocked in each type of context. Given the original goal, I'm sticking to main, not stable/* nor releng/*.* .] EXAMPLE issue: *.py based kyua testing problem for armv7 main: The kyua *.py based tests on armv7 main get long timeouts when python executes as armv7 code, even for very simple tests: # /usr/bin/kyua test -k /usr/tests/Kyuafile = examples/test_examples.py:TestExampleSimple::test_with_cleanup examples/test_examples.py:TestExampleSimple::test_with_cleanup -> = broken: Test case body timed out [300.062s] Results file id is usr_tests.20230806-003823-404601 Results saved to = /root/.kyua/store/results.usr_tests.20230806-003823-404601.db 0/1 passed (1 failed) This happens even on the cortex-A7 system, no lib32 involved, no chroot involved. NOTE: There are a lot of these tests and some have timeouts set at 3600s, others at 1800s and 1200s. Lots at 300s. If a full kyua run completed, it would take a very long time to do so. Kyua classifies all these long-timeout tests as broken. So lots of testing is not happening, despte the time taken. There are 10 or so: -> skipped: comment me to run the test and one each of each of: -> skipped: Current architecture 'armv7' not supported __test_cases_list__ -> broken: Test program did not exit cleanly __test_cases_list__ -> broken: Test case list wrote to stderr I do not know if this promblem type might be somehow tied to the openssl 3 compatibility issue(s) that the ports python's currently have for main. If it is, the error handling seems to not be directly reporting anything that makes it obvious. EXAMPLE armv7 related 'Alignment Fault' on read panic: The kyua sys/netinet6/exthdr:exthdr panic has a different backtrace than I've had from my builds, udp_input this time: # /usr/bin/kyua test -k /usr/tests/Kyuafile sys/netinet6/exthdr:exthdr sys/netinet6/exthdr:exthdr -> warning: KLD '/boot/kernel/if_epair.ko' = is newer than the linker.hints file Fatal kernel mode data abort: 'Alignment Fault' on read trapframe: 0xe014ab00 FSR=3D00000001, FAR=3Dda87f00e, spsr=3D20000013 r0 =3D00000000, r1 =3D00000001, r2 =3D00000001, r3 =3D00000134 r4 =3D00000000, r5 =3D00000134, r6 =3Dda87f00e, r7 =3Dda87f022 r8 =3D00000134, r9 =3Dc0918b04, r10=3D00000014, r11=3De014ac28 r12=3D00000000, ssp=3De014ab90, slr=3Dc04534f4, pc =3Dc048b34c panic: Fatal abort cpuid =3D 1 time =3D 1691281420 KDB: stack backtrace: db_trace_self() at db_trace_self pc =3D 0xc05ecde4 lr =3D 0xc0079c70 = (db_trace_self_wrapper+0x30) sp =3D 0xe014a8b8 fp =3D 0xe014a9d0 db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc =3D 0xc0079c70 lr =3D 0xc02e99a0 (vpanic+0x140) sp =3D 0xe014a9d8 fp =3D 0xe014a9f8 r4 =3D 0x00000100 r5 =3D 0x00000000 r6 =3D 0xc07597e2 r7 =3D 0xc0aeaec8 vpanic() at vpanic+0x140 pc =3D 0xc02e99a0 lr =3D 0xc02e9780 (doadump) sp =3D 0xe014aa00 fp =3D 0xe014aa04 r4 =3D 0xe014ab00 r5 =3D 0x00000013 r6 =3D 0xda87f00e r7 =3D 0x00000001 r8 =3D 0x00000001 r9 =3D 0xe0773ba0 r10 =3D 0xda87f00e doadump() at doadump pc =3D 0xc02e9780 lr =3D 0xc0611184 (abort_align) sp =3D 0xe014aa0c fp =3D 0xe014aa38 r4 =3D 0xda87f00e r5 =3D 0xe014aa04 r6 =3D 0xc02e9780 r10 =3D 0xe014aa0c abort_align() at abort_align pc =3D 0xc0611184 lr =3D 0xc06111f8 (abort_align+0x74) sp =3D 0xe014aa40 fp =3D 0xe014aa58 r4 =3D 0x00000013 r10 =3D 0xda87f00e abort_align() at abort_align+0x74 pc =3D 0xc06111f8 lr =3D 0xc0610e18 (abort_handler+0x498) sp =3D 0xe014aa60 fp =3D 0xe014aaf8 r4 =3D 0x00000000 r10 =3D 0xda87f00e abort_handler() at abort_handler+0x498 pc =3D 0xc0610e18 lr =3D 0xc05ef6ac (exception_exit) sp =3D 0xe014ab00 fp =3D 0xe014ac28 r4 =3D 0x00000000 r5 =3D 0x00000134 r6 =3D 0xda87f00e r7 =3D 0xda87f022 r8 =3D 0x00000134 r9 =3D 0xc0918b04 r10 =3D 0x00000014 exception_exit() at exception_exit pc =3D 0xc05ef6ac lr =3D 0xc04534f4 (ip_input+0x404) sp =3D 0xe014ab90 fp =3D 0xe014ac28 r0 =3D 0x00000000 r1 =3D 0x00000001 r2 =3D 0x00000001 r3 =3D 0x00000134 r4 =3D 0x00000000 r5 =3D 0x00000134 r6 =3D 0xda87f00e r7 =3D 0xda87f022 r8 =3D 0x00000134 r9 =3D 0xc0918b04 r10 =3D 0x00000014 r12 =3D 0x00000000 udp_input() at udp_input+0x1c0 pc =3D 0xc048b34c lr =3D 0xc04534f4 (ip_input+0x404) sp =3D 0xe014ac30 fp =3D 0xe014ac70 r4 =3D 0x00000001 r5 =3D 0x00000000 r6 =3D 0x00000000 r7 =3D 0x01000193 r8 =3D 0xda87f00e r9 =3D 0xc094a938 r10 =3D 0x00000014 ip_input() at ip_input+0x404 pc =3D 0xc04534f4 lr =3D 0xc04235bc = (netisr_dispatch_src+0x100) sp =3D 0xe014ac78 fp =3D 0xe014aca0 r4 =3D 0x00000004 r5 =3D 0xda854000 r6 =3D 0x00000000 r7 =3D 0xc0b5a2f8 r8 =3D 0x00000000 r9 =3D 0xc57f7780 r10 =3D 0x00000008 netisr_dispatch_src() at netisr_dispatch_src+0x100 pc =3D 0xc04235bc lr =3D 0xc041a384 (ether_demux+0x1bc) sp =3D 0xe014aca8 fp =3D 0xe014acc0 r4 =3D 0xda854000 r5 =3D 0x00000001 r6 =3D 0xdb846400 r7 =3D 0x5e4a6f28 r8 =3D 0x00000000 r9 =3D 0xc57f7780 r10 =3D 0x00000008 ether_demux() at ether_demux+0x1bc pc =3D 0xc041a384 lr =3D 0xc041bb68 (ether_nh_input+0x3dc) sp =3D 0xe014acc8 fp =3D 0xe014acf0 r4 =3D 0xdb846400 r5 =3D 0xda854000 r6 =3D 0xda87f000 r10 =3D 0x00000008 ether_nh_input() at ether_nh_input+0x3dc pc =3D 0xc041bb68 lr =3D 0xc04235bc = (netisr_dispatch_src+0x100) sp =3D 0xe014acf8 fp =3D 0xe014ad20 r4 =3D 0x00000006 r5 =3D 0xda854000 r6 =3D 0x00000000 r7 =3D 0xc0b5a378 r8 =3D 0x5e4a6f28 r9 =3D 0xc57f7780 r10 =3D 0x00000000 netisr_dispatch_src() at netisr_dispatch_src+0x100 pc =3D 0xc04235bc lr =3D 0xc041a808 (ether_input+0xec) sp =3D 0xe014ad28 fp =3D 0xe014ad60 r4 =3D 0xdb846400 r5 =3D 0x00000000 r6 =3D 0xda854000 r7 =3D 0x00000000 r8 =3D 0x5e4a6f28 r9 =3D 0xc57f7780 r10 =3D 0x00000000 ether_input() at ether_input+0xec pc =3D 0xc041a808 lr =3D 0xe098310c ($a.10+0xbc) sp =3D 0xe014ad68 fp =3D 0xe014ad90 r4 =3D 0xdb846400 r5 =3D 0xdb7bf8c0 r6 =3D 0x00000000 r7 =3D 0xda854000 r8 =3D 0xe09724d3 r9 =3D 0xdb7bf8d0 r10 =3D 0x00000000 $a.10() at $a.10+0xbc pc =3D 0xe098310c lr =3D 0xc03504dc = (taskqueue_run_locked+0xb8) sp =3D 0xe014ad98 fp =3D 0xe014ade0 r4 =3D 0xe0769e00 r5 =3D 0xe0769e50 r6 =3D 0xdb7bf8ec r7 =3D 0x00000001 r8 =3D 0x00000001 r9 =3D 0xc0768ff7 r10 =3D 0x00000000 taskqueue_run_locked() at taskqueue_run_locked+0xb8 pc =3D 0xc03504dc lr =3D 0xc0351560 = (taskqueue_thread_loop+0x108) sp =3D 0xe014ade8 fp =3D 0xe014ae18 r4 =3D 0x00000000 r5 =3D 0xe0769e00 r6 =3D 0xe0769e40 r7 =3D 0xc073cb53 r8 =3D 0xe0769e50 r9 =3D 0x00000100 r10 =3D 0xc0afde44 taskqueue_thread_loop() at taskqueue_thread_loop+0x108 pc =3D 0xc0351560 lr =3D 0xc02a384c (fork_exit+0xa0) sp =3D 0xe014ae20 fp =3D 0xe014ae38 r4 =3D 0xe0773ba0 r5 =3D 0xc0ada560 r6 =3D 0xc0351458 r7 =3D 0xe0993f94 r8 =3D 0xe014ae40 r9 =3D 0xc0afab7c fork_exit() at fork_exit+0xa0 pc =3D 0xc02a384c lr =3D 0xc05ef640 (swi_exit) sp =3D 0xe014ae40 fp =3D 0x00000000 r4 =3D 0xc0351458 r5 =3D 0xe0993f94 r6 =3D 0xc0942429 r7 =3D 0xc72f21d0 r8 =3D 0xc0ada900 r10 =3D 0xc0afde44 swi_exit() at swi_exit pc =3D 0xc05ef640 lr =3D 0xc05ef640 (swi_exit) sp =3D 0xe014ae40 fp =3D 0x00000000 KDB: enter: panic I've reported another backtrace previously that I'll not repeat here. But such was for my personal build context, unlike here. "'Alignment Fault' on read" happens even on the cortex-A7 system, no lib32 involved, no chroot involved. The details may vary for the backtrace across the contexts. NON-FAILURE EXAMPLE for the cortex-A7 context: In my in-armv7 chroot on aarch64 and/or lib32 based kyua, testing I got crashes for the below type of test that I'm not seeing in this cortex-A7 armv7 context: # kldload -v -n if_bridge.ko Loaded if_bridge.ko, id=3D5 # /usr/bin/kyua test -k /usr/tests/Kyuafile sys/net/if_bridge_test:gif sys/net/if_bridge_test:gif -> failed: atf-check failed; see the output = of the test for details [12.344s] Results file id is usr_tests.20230806-005112-971198 Results saved to = /root/.kyua/store/results.usr_tests.20230806-005112-971198.db 0/1 passed (1 failed) I'll have to continue to look into it for armv7 chroot on aarch64 and in the hackish lib32-involved kyua-based testing. The overall status suggests that for armv7 chroot and/or lib32, if_bridge.ko involvement leads to panics. OTHER POINTS beyond the 3 items . . . GDB HANDLING OF SYSTEM DUMP FOR /var/crash/core.txt.* : /var/crash/core.txt.0 ends up with gdb generated material that is basically useless: generic dumped core - see /var/crash/vmcore.0 Sun Aug 6 00:32:59 UTC 2023 FreeBSD generic 14.0-CURRENT FreeBSD 14.0-CURRENT armv7 1400093 #0 = main-n264491-8a5c836b51ce: Thu Aug 3 12:10:56 UTC 2023 = root@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm.armv7/sys/GENERIC arm panic: Fatal abort GNU gdb (GDB) 13.1 [GDB v13.1 for FreeBSD] . . . Reading symbols from /boot/kernel/kernel... Reading symbols from /usr/lib/debug//boot/kernel/kernel.debug... warning: kld_current_sos: Can't read filename /wrkdirs/usr/ports/devel/gdb/work-py39/gdb-13.1/gdb/thread.c:1337: = internal-error: switch_to_thread: Assertion `thr !=3D NULL' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. ----- Backtrace ----- 0xca962b ??? 0x11880a7 ??? --------------------- /wrkdirs/usr/ports/devel/gdb/work-py39/gdb-13.1/gdb/thread.c:1337: = internal-error: switch_to_thread: Assertion `thr !=3D NULL' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) [answered Y; input not from = terminal] This is a bug, please report it. For instructions, see: . /wrkdirs/usr/ports/devel/gdb/work-py39/gdb-13.1/gdb/thread.c:1337: = internal-error: switch_to_thread: Assertion `thr !=3D NULL' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Create a core file of GDB? (y or n) [answered Y; input not from = terminal] Abort trap (core dumped) NOTE: I ignored the rest of core.txt.0 after seeing the above. KYUA LACKS INDICATIONS ABOUT PORTS TO INSTALL AND KERNEL MODULES TO = PREINSTALL : Various kyua tests depend on kernel modules that are not automatically = loaded. Various kyua tests depend on various ports, none of which are = automatically installed. It looks to me like the appropriateness of various such things depends = on context, so that only a subset might be appropriate by default (without extra = configuration). No information about this seems to be present. I'll note that running kyua inside an armv7 chroot leads to most kernel = modules needing to be preloaded outside the chroot in order for them to be = available to the chroot's kyua run. The armv7 ports need to be installed in the = chroot as well. What I've done so far may well not be close to an optimal default. I'll = not get into the details of what I've done here. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun Aug 6 05:50:36 2023 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 4RJT815QgTz4mSSg for ; Sun, 6 Aug 2023 05:50:41 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (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 4RJT802H1Zz4ZQL for ; Sun, 6 Aug 2023 05:50:40 +0000 (UTC) (envelope-from guru@unixarea.de) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of guru@unixarea.de designates 178.254.4.101 as permitted sender) smtp.mailfrom=guru@unixarea.de; dmarc=none Received: from [188.174.50.193] (helo=localhost.unixarea.de) by ms-10.1blu.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qSWez-0004eP-Ox for freebsd-current@freebsd.org; Sun, 06 Aug 2023 07:50:37 +0200 Received: from localhost.my.domain (localhost [127.0.0.1]) by localhost.unixarea.de (8.16.1/8.14.9) with ESMTPS id 3765oa6b002818 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Sun, 6 Aug 2023 07:50:36 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.16.1/8.14.9/Submit) id 3765oakF002817 for freebsd-current@freebsd.org; Sun, 6 Aug 2023 07:50:36 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Sun, 6 Aug 2023 07:50:36 +0200 From: Matthias Apitz To: freebsd-current@freebsd.org Subject: Has the update procedure changed? Message-ID: Reply-To: Matthias Apitz 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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Operating-System: FreeBSD 13.0-CURRENT r368166 (amd64) X-message-flag: Mails containing HTML will not be read! Please send only plain text. X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 188.174.50.193 X-Spamd-Result: default: False [1.18 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_SPAM_SHORT(0.85)[0.849]; NEURAL_HAM_LONG(-0.79)[-0.791]; MID_RHS_NOT_FQDN(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:178.254.4.101]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_MEDIUM(-0.08)[-0.081]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; HAS_REPLYTO(0.00)[guru@unixarea.de]; RCPT_COUNT_ONE(0.00)[1]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[unixarea.de]; REPLYTO_EQ_FROM(0.00)[]; ARC_NA(0.00)[]; ASN(0.00)[asn:42730, ipnet:178.254.0.0/19, country:DE]; HAS_XAW(0.00)[]; HAS_XOIP(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; R_DKIM_NA(0.00)[]; RCVD_TLS_LAST(0.00)[] X-Spamd-Bar: + X-Rspamd-Queue-Id: 4RJT802H1Zz4ZQL In the past I was used to use the following procedure to install a new kernel and world: # cd /usr/src # make installkernel # shutdown -r now boot -s from the loader prompt # adjkerntz -i # mount -a -t ufs # mergemaster -p # cd /usr/src # make installworld # mergemaster # yes | make delete-old # yes | make delete-old-libs # reboot Now the handbook https://docs.freebsd.org/en/books/handbook/cutting-edge/#makeworld says only: # cd /usr/src # make installkernel # shutdown -r now # cd /usr/src # make installworld # shutdown -r now Has this changed in past two years? Thanks matthias -- Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub From nobody Sun Aug 6 06:38:14 2023 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 4RJVCG1yfrz4mWBT for ; Sun, 6 Aug 2023 06:38:34 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-yb1-xb2a.google.com (mail-yb1-xb2a.google.com [IPv6:2607:f8b0:4864:20::b2a]) (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 4RJVCD2qxwz4gB3; Sun, 6 Aug 2023 06:38:32 +0000 (UTC) (envelope-from kob6558@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-yb1-xb2a.google.com with SMTP id 3f1490d57ef6-c4cb4919bb9so3846760276.3; Sat, 05 Aug 2023 23:38:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691303911; x=1691908711; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=fFDC9DGzkOHVWUKSykql9P6cwYw3juOXSmKX7IilfhM=; b=XRoBcrdfJbvydij2IXzKKZSE9p4ctLgp1CwLf5Tp51riwUUBKNnjBmKv83CZguz3+A B4gsgjCjDoEaZ2A5qMPJKhfH1dLsLq4TCoGmKZGXdK0Zyee4dGYfE+X4VUadnbwsUo/8 JXpVoh5Lx+ql/c5iJOlJE6vVvJmJPSponXu1J7wm3GVhdgkeFMPdpEfIubVf79W+bJBm 25dwRGHGjxgYVANKDTuklejMFe34V8AhIShc8g4w9ImzidP1PKqQRZNFh2ed8vu5cP7p 7cUC2ZQEzM64R6yecFs0r3l5zvIrGxz347TMNFtlHyb5frZOvWT/97a3oeHR9yZZmn+0 JNgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691303911; x=1691908711; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=fFDC9DGzkOHVWUKSykql9P6cwYw3juOXSmKX7IilfhM=; b=kyDK+L6XVeGTGi6TYgVnro1GOK8CAOPWZ2mLyh2HFu1gL4+t/1wWURFFVa8SceOEtA Zx5DyXFFcpGbaWsyyuBgN1gft5rgEFuFjyiGOfiSlSIkW+yPrdB3O2GWC/W0tUEjSfnp 41DQhe1iFOzXAaJus5CgX/LHfTFWjJBEAWnyIp5tkrEsRL9ptocurZR182TLPgaA2jgK EehP/NdabNgSXBDBSJrkYhTm59lzXVsoJN2wcdB+HZ7dIeFs+LgW39dxTDUIL41ovo/1 c0ZJzYbqoWcyp281MuDi51OUe6zIYiWhU1bdR9jh3hhaa4o3tpI0SDCzavuD42oswlTb ZwMw== X-Gm-Message-State: AOJu0YzLr8XlKsOjsGDTn8gPQvhhR9r8b85ufXCX5xGGnb4EhYIqq9gW IUKUppOr3FlePR0pIdOGie9aKl9YNvA02mEuMHGyn/7+ X-Google-Smtp-Source: AGHT+IEnbta6g/RlcQZp+N1dXdqeTiowdEdgdpTkMqW4kFZZNe6+GCdqsEsqwio95yXGq4YX94gRQuo2jZgWLxIQTLE= X-Received: by 2002:a05:6902:4c4:b0:cfe:9981:2af3 with SMTP id v4-20020a05690204c400b00cfe99812af3mr5535915ybs.20.1691303910726; Sat, 05 Aug 2023 23:38:30 -0700 (PDT) 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: <62d300c8-2c3e-58fa-334e-23a17962279a@freebsd.org> <753f3990-9903-3718-445c-49fc01f960a7@freebsd.org> In-Reply-To: <753f3990-9903-3718-445c-49fc01f960a7@freebsd.org> From: Kevin Oberman Date: Sat, 5 Aug 2023 23:38:14 -0700 Message-ID: Subject: Re: Fwd: Unreliability with DHCP To: Graham Perrin Cc: freebsd-current@freebsd.org Content-Type: multipart/alternative; boundary="000000000000ce5edb06023b6008" X-Rspamd-Queue-Id: 4RJVCD2qxwz4gB3 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] --000000000000ce5edb06023b6008 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Aug 5, 2023 at 3:16=E2=80=AFPM Graham Perrin wrote: > On 05/08/2023 12:39, Oleksandr Kryvulia wrote: > > 04.08.23 19:07, Graham Perrin =D0=BF=D0=B8=D1=88=D0=B5: > >> > >> Can anyone from freebsd-net@ help? > >> > >> > >> -------- Forwarded Message -------- > >> Subject: Unreliability with DHCP > >> Date: Sun, 30 Jul 2023 16:17:43 +0100 > >> From: Graham Perrin > >> Organisation: FreeBSD > >> To: FreeBSD CURRENT > >> > >> > >> > >> 1. Sleep (suspend) whilst connected to one network > >> > >> 2. connect to a network elsewhere > >> > >> 3. wake (resume). > >> > >> Result: > >> > >> /etc/resolv.conf frequently contains outdated information. In some > >> (maybe all) such cases, the IPv4 inet address is outdated; and so on. > >> > >> Which /etc/rc.d/ file(s) should I attempt to fix? > >> > >> I imagine using the resume keyword, which is currently used by only > >> one script: > >> > >> % rcorder -k resume /etc/rc.d/* > >> /etc/rc.d/ntpd > >> % > >> > >> > >> I routinely run the command below to work around the bug (and observe > >> the states of things) =E2=80=93 run _after_ the bug bites. I'd prefer = a fix, > >> to prevent the bites. > >> > >> ls /var/run/resolvconf/interfaces/ ; route delete default ; ifconfig > >> wlan0 down && ifconfig em0 down && sleep 5 ; ls > >> /var/run/resolvconf/interfaces/ ; ifconfig em0 up && sleep 15 > >> ; ls /var/run/resolvconf/interfaces/ ; cat /etc/resolv.conf ; ping -c > >> 2 -4 freshports.org > >> > > > > > > As dirty workaround I have in my /etc/rc.resume > > > > service netif restart > > service routing restart > > > Thanks, I'll try when I'm next on campus. > > I do know that 'service routing restart' can be problematic. Please, > see, for example, ; I had something > similar a few minutes ago. > My usual solution is "service netif restart wlan0" (or the interface you are using). It should restart the interface, if rc.conf calls for it, dhcpclient and wpa_supplicant (if appropriate). --=20 Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkoberman@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 --000000000000ce5edb06023b6008 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Aug 5, 2023 at 3:16=E2= =80=AFPM Graham Perrin <grah= amperrin@freebsd.org> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">On 05/08/2023 12:39, Oleks= andr Kryvulia wrote:
> 04.08.23 19:07, Graham Perrin =D0=BF=D0=B8=D1=88=D0=B5:
>>
>> Can anyone from freebsd-net@ help?
>>
>>
>> -------- Forwarded Message --------
>> Subject:=C2=A0=C2=A0=C2=A0=C2=A0 Unreliability with DHCP
>> Date:=C2=A0=C2=A0=C2=A0=C2=A0 Sun, 30 Jul 2023 16:17:43 +0100
>> From:=C2=A0=C2=A0=C2=A0=C2=A0 Graham Perrin <grahamperrin@freebsd.org>= ;
>> Organisation:=C2=A0=C2=A0=C2=A0=C2=A0 FreeBSD
>> To:=C2=A0=C2=A0=C2=A0=C2=A0 FreeBSD CURRENT <freebsd-current@freebsd.org<= /a>>
>>
>>
>>
>> 1. Sleep (suspend) whilst connected to one network
>>
>> 2. connect to a network elsewhere
>>
>> 3. wake (resume).
>>
>> Result:
>>
>> /etc/resolv.conf frequently contains outdated information. In some=
>> (maybe all) such cases, the IPv4 inet address is outdated; and so = on.
>>
>> Which /etc/rc.d/ file(s) should I attempt to fix?
>>
>> I imagine using the resume keyword, which is currently used by onl= y
>> one script:
>>
>> % rcorder -k resume /etc/rc.d/*
>> /etc/rc.d/ntpd
>> %
>>
>>
>> I routinely run the command below to work around the bug (and obse= rve
>> the states of things) =E2=80=93 run _after_ the bug bites. I'd= prefer a fix,
>> to prevent the bites.
>>
>> ls /var/run/resolvconf/interfaces/ ; route delete default ; ifconf= ig
>> wlan0 down && ifconfig em0 down && sleep 5 ; ls >> /var/run/resolvconf/interfaces/ ; ifconfig em0 up && sleep= 15
>> ; ls /var/run/resolvconf/interfaces/ ; cat /etc/resolv.conf ; ping= -c
>> 2 -4 freshports.org
>>
>
>
> As dirty workaround I have in my /etc/rc.resume
>
> service netif restart
> service routing restart


Thanks, I'll try when I'm next on campus.

I do know that 'service routing restart' can be problematic. Please= ,
see, for example, <https://pastebin.com/raw/mXmVPruq>; I = had something
similar a few minutes ago.

My usual solution is "service netif restart wlan0&quo= t; (or the interface you are using). It should restart the interface, if rc= .conf calls for it, dhcpclient and wpa_supplicant (if appropriate). =
--
Kevin Oberman, Part time kid h= erder and retired Network Engineer
E-mail: rkoberman@gmail.com
PGP Finge= rprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
--000000000000ce5edb06023b6008-- From nobody Sun Aug 6 07:01:42 2023 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 4RJVnB1vJWz4pWhT for ; Sun, 6 Aug 2023 07:04:30 +0000 (UTC) (envelope-from dunric29a@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 4RJVn90jGGz3GX7 for ; Sun, 6 Aug 2023 07:04:29 +0000 (UTC) (envelope-from dunric29a@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20221208 header.b=b4nscgsA; spf=pass (mx1.freebsd.org: domain of dunric29a@gmail.com designates 2a00:1450:4864:20::52a as permitted sender) smtp.mailfrom=dunric29a@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ed1-x52a.google.com with SMTP id 4fb4d7f45d1cf-52307552b03so4821579a12.0 for ; Sun, 06 Aug 2023 00:04:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691305467; x=1691910267; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=wjunn4+x2QEs4HRrQcozT7INn2DM0lGSHIZkmkDz3T0=; b=b4nscgsAzvqM45AVqT9iWAnYXOApC+IhrwSdunCdk5GU9XdPXQXQ/D+3Q3O0ZvpAcw a5FGXYmDbOBC/w74Jk1xJOF232pSVZ3wWVvOhnRu5n6LAd0LcADnFkslKYX+8hlsvjdL rI41lo9MWFbd7VrUbeh7ZCTGD8JUqrPHESLSMZ/8GV5yirMNfbt5Kw08U8flNHfR7hxo zkoAE4dosGHqsOMZNg0v3n/cRY1yx4jifzh5dvg/5vy5V6L4MTfW67eZ7L5qAPYeeVBk JTrSbyVOY9FkhB+CKqU5rBeJOGpzu136sCuSZHfI+NSEZW3SeCUYJeOGcNzgmh/3Uthd VdvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691305467; x=1691910267; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=wjunn4+x2QEs4HRrQcozT7INn2DM0lGSHIZkmkDz3T0=; b=Jc0J/BQ4TYulsUU2woIXCeYmUqApeN/kchPxuf2lb4nA0m7fWk+rN8BVM7QFa2VvZk tif33N8weLgpTWpzOFnFnDLq0e1cbLDP/edEcO11ztHQF4309y2Mj88Esvho1Cx5DvjC 0/qbQqJb4hESgmLbAD8ViuxAlGU/sRJ8tH7cHqC5IHvroD1/XkkKHBebBlcELwkp2/HC D0/X8DS8hLTxujZZLoLuIJWhD66NsK8QWSf6YXIoGUI3kbZuelNaDsUpLrfKSZDFsrTA Ono7rGUwZkzrB3pbo/MIXU0LKdy0AM7wZEPVpsaOv7zWJhfpmM5woNcYwrNLkFJvFwqn dxiA== X-Gm-Message-State: AOJu0Yw1KL/t3rQAKmE88V6FdwK/giEaQHUkfT/Sy4gZjawD8W8A4dj0 FqiDoWTppfAwfz1MjLQvJYTN6ep3zFNiVe/GCa0qVcoZte0= X-Google-Smtp-Source: AGHT+IEvZDTx/MSMhw6w//3N+NRJZfE5WSyRu+TIDbxL/L8UZ8XceEougRcXQWx01+ISFvRBlZPtXefIa6Nol/qJaY0= X-Received: by 2002:aa7:db52:0:b0:522:36f0:f1a3 with SMTP id n18-20020aa7db52000000b0052236f0f1a3mr5082562edt.10.1691305467346; Sun, 06 Aug 2023 00:04:27 -0700 (PDT) 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: Damon Unric Date: Sun, 6 Aug 2023 09:01:42 +0200 Message-ID: Subject: unsubscribe To: freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Spamd-Result: default: False [-0.01 / 15.00]; NEURAL_SPAM_LONG(1.00)[1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_SPAM_MEDIUM(0.99)[0.990]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20221208]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; ARC_NA(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52a:from]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; FROM_HAS_DN(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-Spamd-Bar: / X-Rspamd-Queue-Id: 4RJVn90jGGz3GX7 unsubscribe From nobody Sun Aug 6 07:36:42 2023 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 4RJWVR32Fwz4pYvP for ; Sun, 6 Aug 2023 07:36:47 +0000 (UTC) (envelope-from shuriku@shurik.kiev.ua) Received: from mail.flex-it.com.ua (mail.flex-it.com.ua [193.239.74.7]) (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 4RJWVQ1KYLz3Jyr for ; Sun, 6 Aug 2023 07:36:46 +0000 (UTC) (envelope-from shuriku@shurik.kiev.ua) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of shuriku@shurik.kiev.ua designates 193.239.74.7 as permitted sender) smtp.mailfrom=shuriku@shurik.kiev.ua; dmarc=none Received: from 93.183.208.50.ipv4.datagroup.ua ([93.183.208.50] helo=[192.168.200.125]) by mail.flex-it.com.ua with esmtpsa (TLS1.3) tls TLS_AES_128_GCM_SHA256 (Exim 4.96 (FreeBSD)) (envelope-from ) id 1qSYJe-000AMC-0j for freebsd-current@freebsd.org; Sun, 06 Aug 2023 10:36:42 +0300 Message-ID: Date: Sun, 6 Aug 2023 10:36:42 +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:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: service routing restart (was: Unreliability with DHCP) Content-Language: uk-UA To: freebsd-current@freebsd.org References: <62d300c8-2c3e-58fa-334e-23a17962279a@freebsd.org> <753f3990-9903-3718-445c-49fc01f960a7@freebsd.org> <354756c9-29e0-db1f-269e-3c219b5d9ac8@freebsd.org> From: Oleksandr Kryvulia In-Reply-To: <354756c9-29e0-db1f-269e-3c219b5d9ac8@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ACL-Warn: SPF failed. 93.183.208.50 is not allowed to send mail from shurik.kiev.ua. X-Spamd-Result: default: False [0.25 / 15.00]; NEURAL_SPAM_LONG(1.00)[0.997]; NEURAL_HAM_MEDIUM(-0.80)[-0.799]; NEURAL_SPAM_SHORT(0.35)[0.350]; R_SPF_ALLOW(-0.20)[+mx:c]; MIME_GOOD(-0.10)[text/plain]; RCVD_COUNT_ONE(0.00)[1]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:35297, ipnet:193.239.72.0/22, country:UA]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[shurik.kiev.ua]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_NONE(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-Spamd-Bar: / X-Rspamd-Queue-Id: 4RJWVQ1KYLz3Jyr 06.08.23 01:35, Graham Perrin пише: > On 05/08/2023 23:16, Graham Perrin wrote: >> On 05/08/2023 12:39, Oleksandr Kryvulia wrote: >>> 04.08.23 19:07, Graham Perrin пише: >>>> >>>> … >>>> >>> >>> As dirty workaround I have in my /etc/rc.resume >>> >>> service netif restart >>> service routing restart >> >>  … 'service routing restart' can be problematic. Please, see, for >> example, ; I had something similar >> a few minutes ago. >> > After 'service routing restart' (alone), should 'route show default' > find a route? > Only if you have static route configuration. In my case default route is assigned by dhclient, so 'service routing restart' must be run quickly after 'service netif restart' - before we receive dhcp offer. Another option is to run 'service dhclient restart wlan0' after routing restart. I have lagg with em0 and wlan0 - thats why I need 'service netif restart' instead. From nobody Sun Aug 6 08:20:54 2023 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 4RJXTh3lxVz4pdN2 for ; Sun, 6 Aug 2023 08:21:12 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-23.consmr.mail.gq1.yahoo.com (sonic312-23.consmr.mail.gq1.yahoo.com [98.137.69.204]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4RJXTf5j2Zz3NXW for ; Sun, 6 Aug 2023 08:21:10 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=kk6aNzld; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.204 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1691310067; bh=GR5j2O8BIGfwO3MCekwYIwZ1fYJFsRMH2Io8TuRABS0=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=kk6aNzldagDxcI4olTz0G0uTlgZDPcjuP8Bqjpz/gSdrzIPJj9Sv8G488U2t4n2Qy46XMD0T32db0Ci245QEztopQ/ZKfMEi9EhaYxYtwq0R3kshybdQKOfHZt4nqojgoLFkB7IPxZ6kG2WBL7Kz2AnOMYHmSwyWfziPUZQj7xZqSmd3Yfm3Xlt9VSA0jburuTFyYXVL6vFJdzE0PqxU2UtH/jAgo48ZZFmNWNVmP4eOpXnI0yhLtohHm13AUN4+ENx95SCOQ44/ScJPDDfnLN+cGSiGWUQ0HckJ3y18jXzYYrB9WGX5qi+4MzUcIeK27uXuun3eGyeblk4Vz7giOA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1691310067; bh=NoXSr8SvKyKFAcZaUxyQRMJvhvSejA1N/xqOLvDEolY=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=GG/AJnIbvTqt9xbizSoLHLC88OwrLdhqQD6BEyaExjRool66jS7DkAX8gm+eljsZtnpLWVzR1XhKvy/eCpS2WScFbyYmhWg0kVp5THFFhijxMvGuLTOJ3JsslI+RXnX33O4bEUUxVU1bCnMXNA2b+8v5G2QDInS/5z4IDiAI+Nhc6VTaPnfYomhRF9yuKs3cItbMcrNlFF8WsejpeKlARHPs4L4AngbBE6+V0G+tE/pClA00n8N9uwTp95x4w3r5LiiTY9HDHZBGJ4CiOnQnjF8bnEkG8hF4gZoHMs8iMKBTwDOKaw+Z6JR9eDUUiUEheaoDRhmGgOjk0lLpJsaelQ== X-YMail-OSG: njIPa1YVM1laHFd_k79AAYCb1tCvUJmwAFfgIFgwas5ow_47zIAnzFk7exNwiDO t5QyTzxuhlpG5xEVLZHnnH_iCgQKuZJh1srtCmAYkGSoAYNOUBnPAchyJbmSHys2LCyysr20bOlq JlVkyGFq3_U3ar6NeBNxG0XlZMjaYBLkd.lAFmmsXqZtk_7VxekYaz.WhD__vyWHXJfdxlNTaacz Ng9xXAZ7oyhFhMnZ6bruxgRuWaaL0IsIsJY5uWUKIlhqMn74VtBYE8FPdfr38c.fF4UAoEibC2JB 28RNrHGNTdfAGZdSiAy3XuOKg6FxG9bYrBSYqgt9JAbowYgEwfFCwRqgJVfMYPlM2ZOs7kgzVQ55 O1.NFJBwIj1kFLDrMCfiJHEW8BLzqNtag3d4P.Elk9NicbTevuuCFFYaJSa4Xec3VK.yUA3vvgMO w0g4jdkC8zlNAju_0_ruaIdnTa0CbGSeEjSQpGBiDWCQon.deb88fLx27vZotYDe1_N0X5Jz8M.O .WEWUi8hkYI49DPa4lB3aoNVKHpM6wWieLElvgYz4a9agftxCIhQ.4vlV5XWY6apbeZMUTsYBAoF z0j7cV_Nbmnu1DE6f4a3pfjJttKghVBwA57JB5ijgo8ZIm9n.5J0vwCI9c6QidECUHJD6tGF86Nl ZIpis0gxjs448u8g88Odfl4US3znbu3D_xD4.BwUvURfFJc7AkTtQ7vAVKoVL0WRRp0EPuJCsvyT GBwjTO_PHhIC2oL0LDTlgbUcP9DA7kSUS7mwPXnDvzHGbDeur56WkOc.6yvbUPQl94k.Gcy4_w0y kSYkketz9u2CAzvoZUYdQQbvlS_Z.0Gnm4AmiTkEjWJao38CuHjLsHj.Xgnb600uxgQ_yXHal42d Yry859enTYAWYFOu.MUf7kR.MOQB7kDg4CwBHSsTxHhElvnS3UV81.3VxacYooDXXZZNB4dkJaZZ Ehv_aPRJfvKOj.AVq6C03T5j0rloRUoxKjw7bRRCtP2rVSd3yEFWTu4HrQQe3vgOb76kUEWrmnRG pVV8sxw.LKUeNSisB.fi3DAgnGa6IcUAFGPwaEkmzwRPxeTsboEz_ThTss7xQOuUJ5_0ayo4pf26 xUWYf6o5KkTMLIqn1e55nRJ2sJXl5dze1SDi3s9o6oX_NPc8NVnxUd55VNgxSldNPQqYPKw_TOe_ .2BlZdXUEZ3CrCuxx.HtqEhYojZdkide1exBdV.MwCgZ2_Vplhosepun6tjl83ppIGDcAAQLOANT N5n4Ia.0ES7LrkO6E0cgkpfiwGQtwcDPi.Qvjh36rTSGHkzpFvM60f7GtNfWjZwLhuLEcQYA.qx6 4QuSlRKC3ZCpr9gKoTlawtSflyqa5xr_odj.Vtzk6UxSf5.4hfwsFgyABshakJPFaC0HCfvxp73v 1Axdm6TSKFm_PvaykUwEjqdk8pdc4ra1mESa1YicQRUGwKVP274wnkPre5XSqTjJ4Sl_GRUCC7Yv qzsvrMiE6QC_oN52heNHJPxSFU9SXU_CmZknQPSdRfJTNphltsbiZyvb.iGrJyl9zvhXyeLgnqNY Peg2RKmRsI3js.2wUnjWETS9V9MEY6e.eOOs3MMXblAZ3vb3XpIhxSUcFgoVRHbNMovDdDuUKH2o tiZSDFZfoG8g62TEHv5ccYlz3fUb6DlnGk9H4KDpwgJOhvke2jFVWSuwI0sCRL29aX9vXjZX.BA6 o_6k99U8xIgXT79Y7WaJGb.2pvvsyUzM51yW1Ql2VqFBepTxabqChCQCWKYJ3zQoieERZsVgELj_ XnWsKQlIXw09JvMW04G8xZdUhwmZepxYMfKYVizvm3d6sze6tBAQAlr0vnXn1xIASHBQzyDD4eZn mG2tIUcoNf1JX1KEs4suOfWpK9MxdA8NNEm20mvdgCJGt1zKRTehV2ttL_OxDHZH.8ntYN93Q8RP YWleCxa7bzX3.rceqE6hqBwMk09wwCbO.n3gkb7ktUsKEfq8qgtjUxXIkPZuhxL11NDGQaT2nNwW 24JJ.eV0RBqgrEydzyKURv40DYJbGont.UY_m_f0MD7z5VHxttKqgzMjzt8vqvZyu97V_mFxuiVb 6b13mtRZr2w.Qw6h3Lagf2fjaqWk1mkU6HryH7l7phg1aweQ4vD1Q_7bgcrEVvJY5MlpisWMg_2k jk372KRM0s4_269L1DwEmtCJp_qpyTMZFTgEjnqJwAa0wBThtwWoSvIWqS_oUWPSkKENQC4CxBfL JzUmBjL9NLsc8H.xbzcDm0QTERivxMZa606KFDzCt8wIkD511cDQ_YkTP2sEb.4tarm8LyAuPsKU - X-Sonic-MF: X-Sonic-ID: 5f7be122-c084-4783-9c81-fa1c8cbbb360 Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Sun, 6 Aug 2023 08:21:07 +0000 Received: by hermes--production-gq1-7d844d8954-qb9gk (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID cda1c6a4277f66ae395a6e7997f8a83a; Sun, 06 Aug 2023 08:21:05 +0000 (UTC) From: Mark Millard 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 16.0 \(3731.700.6\)) Subject: RE: Has the update procedure changed? Message-Id: <9E1458A0-606A-42F5-A867-F6672D4CDEE9@yahoo.com> Date: Sun, 6 Aug 2023 01:20:54 -0700 To: guru@unixarea.de, Current FreeBSD X-Mailer: Apple Mail (2.3731.700.6) References: <9E1458A0-606A-42F5-A867-F6672D4CDEE9.ref@yahoo.com> X-Spamd-Result: default: False [-2.50 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.204:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.204:from]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_COUNT_TWO(0.00)[2] X-Spamd-Bar: -- X-Rspamd-Queue-Id: 4RJXTf5j2Zz3NXW Matthias Apitz wrote on Date: Sun, 06 Aug 2023 05:50:36 UTC : > In the past I was used to use the following procedure to install a new > kernel and world: >=20 > # cd /usr/src > # make installkernel > # shutdown -r now >=20 > boot -s from the loader prompt >=20 > # adjkerntz -i > # mount -a -t ufs > # mergemaster -p > # cd /usr/src > # make installworld > # mergemaster > # yes | make delete-old > # yes | make delete-old-libs >=20 > # reboot >=20 > Now the handbook = https://docs.freebsd.org/en/books/handbook/cutting-edge/#makeworld > says only: >=20 > # cd /usr/src > # make installkernel > # shutdown -r now > # cd /usr/src > # make installworld > # shutdown -r now >=20 > Has this changed in past two years? https://docs.freebsd.org/en/books/handbook/cutting-edge/#makeworld section 26.6.1 lists: # git pull /usr/src=20 check /usr/src/UPDATING=20 # cd /usr/src=20 # make -j4 buildworld=20 # make -j4 kernel=20 # shutdown -r now=20 # etcupdate -p=20 # cd /usr/src=20 # make installworld=20 # etcupdate -B=20 # shutdown -r now =20 The material in 26.6.5 does not repeat all that, it is more of a summary that is presented. There are also instructions in UPDATING (near the end) and yet other instructions in Makefile (leading comments). I've not done detailed comparisons of such in some time, but they well not be exact matches. As I remember, the UPDATING material was more explicit about various cases/contexts and what was appropriate for them. It can be appropriate to review them all. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun Aug 6 08:40:32 2023 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 4RJXwJ5TnWz4pgH8 for ; Sun, 6 Aug 2023 08:40:48 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-23.consmr.mail.gq1.yahoo.com (sonic304-23.consmr.mail.gq1.yahoo.com [98.137.68.204]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 4RJXwH5PcFz3QwY for ; Sun, 6 Aug 2023 08:40:47 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=raQGjuS4; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.204 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1691311245; bh=wZymAwngR8l5CkgJfleFlpO3En6C6mYznxX4VBqClgM=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=raQGjuS4q8m7+S34zFl8tgsUfyv0rjqCfuW9QQzCnu1uvN0Rf6lSf4tm1CXDjzREUp5HwdVTUFPcQnD6LEbhyOElcVtxAO9/pYwNwM2XcNUe3tTO2M2hS4hv675GVA7WQcDfQDZDQjczspvpxodnESCyuRmjRgDQs144WGsuA49hXZE5PvSMuo2ht0OpbP6A5KT2IOQzeDoo1X1c69rpX6WwNPaFVbX1v1wQwUDrWxDIGrB2UEJgjCARWeRz0TAsSNfxNHTbbhkR+Fj8QnVbEUkwGjYZs3X5Gc+74dJzG1+MzioQA1oQ4g/C8+7J4SZ0DeXEFmWi5CGJJBkFlBMkUA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1691311245; bh=YJ+U18X7JnPetCaYQfmzpzUHBAQIxoZvmK4yhLds/o3=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=Etsjn9smRnV/eGY30SRWddSLGCuJ2PbdFBFiX9FjkaABWa7t4Kk2x3+AVd8eYZMKFq8iIDGgsHStginSrLoD3YHOODRfVPJv0eGGQCZw3cxuE2ANmXHibYhkpcHWWrGgCzdrd6DP6DUK8KKY8ngB874FGlXOYBlCQvvs49U9be6GbIgqkINSBhEKRbijR8OvckOouAj+WtEpwhDDwXVacP4OnZhUQBNw1RG/z7Drn5bXi57dgBnH7xBJwiydol6qmwP0GrYRb+4I/hib6EN8pCBLJ5MZLqkHv65NN8VqQOU4f7aKnvqmi/38QbabzCMrIgW2YueivhjKU2FNRdaIIQ== X-YMail-OSG: W_1Zyo0VM1nf_4BuUNE.L9k_igEVF9_aNn6kfpG0A2CqLxTkTuY2jZuWbWeDkvz dZ0vvrlgN_bMsRmbgMPCs30IkWqunOBiNmf2g2lhTWtpwz2PdJ_sqzbgEtqBHGFigZXGz.re5KHv ojt2c8H1YA6AkfsN43Tc7maZQ7XvlW13vUO6syaySGBYg.ZrCgD.Oke5j0B.o46z1_jlm4xmQL7G qZa4h3aZYzsHfK7WARMLb1hQ8faIFxcQmM8QZ4CHdj0B638RlYPlOg1AXFamaGl_59dogukIjfY5 rFqv8HE4tiWSU9RvqAi1HDT5Ax5NEtwrtCv8zUoSUmElUct8D6XWrJdZhxVudEXnCvns_FTC0TmZ mxiY9zDlUMVaK8XtSP4yBT7pfCLlodlpWofgqCva5mq43u8nZ63yGmhW4tk5Zj3RXvShRXcXtGFY Ax4RI4oBxAwY1oMLjPQLBcVRJvpLDA1HYvnH0yLWE28fBME9_7vdsVCPAz7S.wsOytlARAe3K1.a XB3jiVl_VU_w8tKXis0N7kuHJ8J7Lnrx3X4PGgrOiDhZ_hIyBCsj5dDLOwTy0n.LWEyFtEm8ugJf iRfB2vfzOskYXDoIIRS0fFvPEkyNXz4SgaY1UTBrLB6IO874X6xRkzxD8ICluyZpH.0U.aKfbRMj i7Ocboq4S79vk_.nY0cQR5G0DRa9ZKelsFwSfNdLWxvMSmS7gK7sTtwpGbjVmQIrkhZN6W26R06x k77Yj5yRObkrHAJlKPxLYK00Tv7Z8JAENuoMRoyPvqfMHIzXCXD2n9aNQPNzrXaiZYqXjx8Krqg4 aUAr.jE_gwCy67A8rAuvKKaswIvDYeVP9xCQJSpjSffGZ47hF4aTmFHhuL7eY55Fmd4l7HgxK25J 1v._.dlXO.ycqiT3CA1fS9cROChn.yOKB2l1geaPs8unfDbaEMfO9BwJ8aGnYFH.FdeaYu_pAGFG S7v1sFSfWiRu.oLPdGnjTmrVQaQVB1t6zP3ShcCkCik6.P4KgR7l16tXwcnyh08O1Y.ZKGffAep. DNB9hSmjp35JCcQFiadsvrYqM_0Z3plEYyx72ebYyBkXJHdO37vblwDV9CcmStJSJPbNdSApyqNk iqJJo8rEoHFgm3lrubdWBt7MSiMHO6fJSnxiH33BTM3BgUNeOVO8rBZqU4LtUM_5iyV9H02dm8io 1QHqwZUXHgDhRnG.3j6oNZins1Ndh_0t9daGB8i4cSy9va7WudtHxeHjpvK2g8K3P5vQBkCoL5Sc fb_vDrzTjUiXyF8twbjfThCnFNtLteHuzYAivysLTB..jgZ73BwleZNoODkHqmUxiJcssj1ejy1s ivuuFVyN422jVCooXJtfJnLsOiqihjMMK.ciJyZQ26T_h2BUbp8y6vmhIZ8f7eZzgwJR3yovEvmk uQ1w9zNF2UqVNQI3JPer0ak5MI.FhGh5tvHzUUbEzOFpuYzsFj8INBfUVqtKRyF4U0LfuEblYILs .B8Ax1Ngd80tXzM8HjV.7b.jwQZC5KIR1epZD2RVYHSfa6e9q_95jeycwCYeZMsYk0gInmZdvI5H wCiBPZ8hHEZx5h0ifrwF211t8kkAyVSbLUjgpO4Y_rmv_0XTeZB0KuN20S2RS9gu_uMQQcmrF3E1 L48WaJY66B6FEEmqrjjOxOzmm4PIoLndUPaCuDN6m_V_mL9WXSOKQkOqAsyQYiIiHhuKUT.Og3aV G8IceZ2Gay5qrwZpw09__wMch3vVx6HXf02RcTb4GYXkKusXAsjtTPGM2mahpktr8WIYj1r2EeyP nlDVTJLA9f4w0H1UFR_9RRK1DjQZRTXnEVikzd726LIMAeMpi1Y5c5Nhfl1sRdwINdmC06Fh8u6H 8.sMKM1QLQ1824rqNV00rfG93k9PAwxfY_nJ1PJElrbYFt5YzrUWMVOTsTiqEWsdvm9iTIxdDsmP TfDH9T8Oc4dKFSaXbZGoAYrHZXsNQaPHE_zKd3vfVW08g09kZdEW3uCnWTs9GKNvesI1JBrlZAIj hexhOBiokkJZQhsUHE7preh4L0EAJi2xJzu0oANHnBjzsh5IJsatg3dZOcicCrfbW3Z0Ppe1_yRB 7fnSW3OaFQoFSfLcDpX2bdoAAnrWAUOJrMyVnRhciBnbV_285dmADJAdl.YrcFSa7IMBWxyxQWjn 3GeVWY2jZQahln1m_LKBOhtio5_Kr79eqIgjmdRNBsAMflNIlRJpVkvdkPIRFWble1c9J2j7B3MO hFkJVPMUl7qvsUhcgYbtYYZXiQKbQoqtqkDkJxsl3vhOiWUZPu8fo4vP6kd0rKALTNu0MuLPPy8N 3tQ-- X-Sonic-MF: X-Sonic-ID: abf490b2-51f9-4d38-92fe-29d8dca27fd7 Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Sun, 6 Aug 2023 08:40:45 +0000 Received: by hermes--production-ne1-549c7f6c44-6w8f9 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID a83a25dce5f412379593ff6f398ad99b; Sun, 06 Aug 2023 08:40:44 +0000 (UTC) From: Mark Millard 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 16.0 \(3731.700.6\)) Subject: See bugzilla's 272965 and 272966 for cortex-A7 armv7 example kyua test case panics for main [so: 14], split by backtrace structure Message-Id: <5D3B4DA0-C486-4120-9C93-F26782DC6E72@yahoo.com> Date: Sun, 6 Aug 2023 01:40:32 -0700 To: FreeBSD ARM List , Current FreeBSD X-Mailer: Apple Mail (2.3731.700.6) References: <5D3B4DA0-C486-4120-9C93-F26782DC6E72.ref@yahoo.com> X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ARC_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.204:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.204:from]; DKIM_TRACE(0.00)[yahoo.com:+]; TO_DN_ALL(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MID_RHS_MATCH_FROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2] X-Spamd-Bar: --- X-Rspamd-Queue-Id: 4RJXwH5PcFz3QwY See: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272965 and: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272966 All involve 'Alignment Fault' on read at some point but the 272966 ones first involve: Kernel page fault with the following non-sleepable locks held during in6ifa_ifwithaddr. The 272965 ones involve udp_input getting the alignment fault. These reports are based on using the most recent snapshot of main [so: 14], not based on my own builds. They do not involve aarch64 at all: no chroot use, no jail use, no lib32 existing for the already just-armv7 context. === Mark Millard marklmi at yahoo.com From nobody Sun Aug 6 08:54:50 2023 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 4RJYDZ4CHJz4ph3p for ; Sun, 6 Aug 2023 08:54:54 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (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 4RJYDZ1gkNz3VGC for ; Sun, 6 Aug 2023 08:54:54 +0000 (UTC) (envelope-from guru@unixarea.de) Authentication-Results: mx1.freebsd.org; none Received: from [188.174.50.193] (helo=localhost.unixarea.de) by ms-10.1blu.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qSZXH-0003xU-B1; Sun, 06 Aug 2023 10:54:51 +0200 Received: from localhost.my.domain (localhost [127.0.0.1]) by localhost.unixarea.de (8.16.1/8.14.9) with ESMTPS id 3768so8N015348 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 6 Aug 2023 10:54:50 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.16.1/8.14.9/Submit) id 3768soQU015347; Sun, 6 Aug 2023 10:54:50 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Sun, 6 Aug 2023 10:54:50 +0200 From: Matthias Apitz To: Mark Millard Cc: Current FreeBSD Subject: Re: Has the update procedure changed? Message-ID: Reply-To: Matthias Apitz Mail-Followup-To: Mark Millard , Current FreeBSD References: <9E1458A0-606A-42F5-A867-F6672D4CDEE9.ref@yahoo.com> <9E1458A0-606A-42F5-A867-F6672D4CDEE9@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: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9E1458A0-606A-42F5-A867-F6672D4CDEE9@yahoo.com> X-Operating-System: FreeBSD 13.0-CURRENT r368166 (amd64) X-message-flag: Mails containing HTML will not be read! Please send only plain text. X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 188.174.50.193 X-Rspamd-Queue-Id: 4RJYDZ1gkNz3VGC X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:42730, ipnet:178.254.0.0/19, country:DE] El día domingo, agosto 06, 2023 a las 01:20:54a. m. -0700, Mark Millard escribió: > The material in 26.6.5 does not repeat all that, it is > more of a summary that is presented. > > There are also instructions in UPDATING (near the end) > and yet other instructions in Makefile (leading > comments). > > I've not done detailed comparisons of such in some > time, but they well not be exact matches. As I remember, > the UPDATING material was more explicit about various > cases/contexts and what was appropriate for them. > > It can be appropriate to review them all. Thanks for the pointers. During the installation I got the following error: # make installkernel ... kldxref /boot/kernel kldxref: error while reading /boot/kernel/iwlwifi-9000-pu-b0-jf-b0-46.ucode.ko: Bad address kldxref: error while reading /boot/kernel/iwlwifi-9260-th-b0-jf-b0-46.ucode.ko: Bad address kldxref: error while reading /boot/kernel/ktest_netlink_message_writer.ko: Bad address I know the reason (the install process uses the old existing kldxref which does not can handle some things). I proceeded with the installation and all is fine, the box is up again in multiuser and /usr/sbin/kldxref is now from today. Should I run 'make installkernel' a 2nd time? matthias -- Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub From nobody Sun Aug 6 09:12:38 2023 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 4RJYdD5hnbz4pj7T for ; Sun, 6 Aug 2023 09:12:48 +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 4RJYdB3LWgz3XHj for ; Sun, 6 Aug 2023 09:12:45 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; dkim=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; dmarc=none Received: from kalamity.joker.local (123-1-88-210.area1b.commufa.jp [123.1.88.210]) (authenticated bits=0) by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 3769Cc43045187 for ; Sun, 6 Aug 2023 18:12:39 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Sun, 6 Aug 2023 18:12:38 +0900 From: Tomoaki AOKI To: freebsd-current@freebsd.org Subject: Re: [Intel AlderLake] Read&Write files to FAT32 or UFS partition cause data corrupt due to P-Core&E-Core Message-Id: <20230806181238.858f58e25dfd0f99269cfe53@dec.sakura.ne.jp> In-Reply-To: References: <5fd2a34e-1135-4237-a028-d4566ff65c69@FreeBSD.org> <20220219115534.7db1b9f199c10894e4280b33@dec.sakura.ne.jp> <7A743668-B5AA-4679-9F56-9A6220CBBC14@karels.net> <59cbcfe2-cd53-69d8-65d6-7a79e656f494@FreeBSD.org> <1f968af1-1c57-9a09-7e01-145a5262e27f@FreeBSD.org> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.2) 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-Spamd-Result: default: False [1.11 / 15.00]; AUTH_NA(1.00)[]; NEURAL_SPAM_SHORT(0.95)[0.954]; NEURAL_HAM_MEDIUM(-0.90)[-0.898]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-0.45)[-0.446]; MIME_GOOD(-0.10)[text/plain]; ONCE_RECEIVED(0.10)[]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; R_DKIM_NA(0.00)[]; HAS_ORG_HEADER(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; R_SPF_NA(0.00)[no SPF record]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; DMARC_NA(0.00)[sakura.ne.jp]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_VIA_SMTP_AUTH(0.00)[] X-Spamd-Bar: + X-Rspamd-Queue-Id: 4RJYdB3LWgz3XHj On Wed, 23 Feb 2022 01:30:28 +0200 Konstantin Belousov wrote: > On Tue, Feb 22, 2022 at 06:23:17PM -0500, Alexander Motin wrote: > > On 22.02.2022 17:46, Konstantin Belousov wrote: > > > Ok, the next step is to get the CPU feature reports from P- vs. E- cores. > > > Patch below should work, with verbose boot. > > > > Not much difference on that level: > > > > --- zzzp 2022-02-22 18:18:24.531704000 -0500 > > +++ zzze 2022-02-22 18:18:18.631236000 -0500 > > @@ -1,22 +1,21 @@ > > -CPU 2: 12th Gen Intel(R) Core(TM) i7-12700K (3609.60-MHz K8-class CPU) > > +CPU 16: 12th Gen Intel(R) Core(TM) i7-12700K (3609.60-MHz K8-class CPU) > > Origin="GenuineIntel" Id=0x90672 Family=0x6 Model=0x97 Stepping=2 > > Features=0xbfebfbff > > Features2=0x7ffafbff > > AMD Features=0x2c100800 > > AMD Features2=0x121 > > Structured Extended Features=0x239ca7eb > > Structured Extended Features2=0x98c027ac > > Structured Extended Features3=0xfc1cc410 > > XSAVE Features=0xf > > IA32_ARCH_CAPS=0xd6b > > VT-x: Basic Features=0x3da0500 > > Pin-Based Controls=0xff > > Primary Processor Controls=0xfffbfffe > > Secondary Processor Controls=0xf5d7fff > > Exit Controls=0x3da0500 > > Entry Controls=0x3da0500 > > EPT Features=0x6f34141 > > VPID Features=0x10f01 > > TSC: P-state invariant, performance statistics > > -64-Byte prefetching > > -L2 cache: 1280 kbytes, 8-way associative, 64 bytes/line > > +L2 cache: 2048 kbytes, 16-way associative, 64 bytes/line > > > > Show me the full verbose dmesg of the boot then. > > As another blind guess, try to disable pcid, vm.pmap.pcid_enabled=0. > Hi. Intel N100 is reported to crash without this tunable on 13.2 at freebsd-users-jp ML (as this is a ML in Japanese, reported in Japanese). [1] Crashes with UFS, but ZFS is claimed to be OK. N100 is an Alder Lake-N processor WITHOUT P-CORE. [2] [3] So check logics on workarouund codes (IIRC, all are MFC'ed before 13.2) wouldn't be working? Sorry, I'm just a liaison here and do not have any actual affected haedware (means that cannot test at all myself). The reporter claims that the actual hardware is as follows. Beelink EQ12 intel N100, 16GB-DDR5,512GB M.2 SSD [4] Working states are reported as follows. Installed to ZFS: OK Stock 13.2 without any custom tunalble: Crash with UFS Tunable vm.pmap.pcid_enabled=0 in /boot/loader.conf: No crash reported with situation below. *Add "vm.pmap.pcid_enabled=0" on /boot/loader (on installed geom) just after the installation finished. *Reboot to the installed partition. *`portsnap fetch extract` *`cd /usr/ports/ports-mgmt/portmaster ; make install clean` *`portmaster www/apache24` And any other operations after above are claimed OK. Tunable vm.pmap.pcid_invlpg_workaround=1 instead above: Better than stock 13.2, but crashes on `portmaster www/apache24` of the procedures above. [1] https://lists.freebsd.org/archives/freebsd-users-jp/2023-July/000205.html [2] https://www.intel.com/content/www/us/en/products/sku/231803/intel-processor-n100-6m-cache-up-to-3-40-ghz/specifications.html [3] https://en.wikipedia.org/wiki/Alder_Lake [4] https://www.bee-link.com/eq12-n100-clone-1-82615581 Regards. -- Tomoaki AOKI From nobody Sun Aug 6 09:55:07 2023 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 4RJZZS1Rftz4pmK7 for ; Sun, 6 Aug 2023 09:55: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 4RJZZR38mwz3bZG for ; Sun, 6 Aug 2023 09:55:27 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.17.1/8.17.1) with ESMTPS id 3769t7Lj032694 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 6 Aug 2023 12:55:10 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 3769t7Lj032694 Received: (from kostik@localhost) by tom.home (8.17.1/8.17.1/Submit) id 3769t75L032692; Sun, 6 Aug 2023 12:55:07 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 6 Aug 2023 12:55:07 +0300 From: Konstantin Belousov To: Tomoaki AOKI Cc: freebsd-current@freebsd.org Subject: Re: [Intel AlderLake] Read&Write files to FAT32 or UFS partition cause data corrupt due to P-Core&E-Core Message-ID: References: <5fd2a34e-1135-4237-a028-d4566ff65c69@FreeBSD.org> <20220219115534.7db1b9f199c10894e4280b33@dec.sakura.ne.jp> <7A743668-B5AA-4679-9F56-9A6220CBBC14@karels.net> <59cbcfe2-cd53-69d8-65d6-7a79e656f494@FreeBSD.org> <1f968af1-1c57-9a09-7e01-145a5262e27f@FreeBSD.org> <20230806181238.858f58e25dfd0f99269cfe53@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: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230806181238.858f58e25dfd0f99269cfe53@dec.sakura.ne.jp> 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=4.0.0 X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on tom.home X-Rspamd-Queue-Id: 4RJZZR38mwz3bZG X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] On Sun, Aug 06, 2023 at 06:12:38PM +0900, Tomoaki AOKI wrote: > On Wed, 23 Feb 2022 01:30:28 +0200 > Konstantin Belousov wrote: > > > On Tue, Feb 22, 2022 at 06:23:17PM -0500, Alexander Motin wrote: > > > On 22.02.2022 17:46, Konstantin Belousov wrote: > > > > Ok, the next step is to get the CPU feature reports from P- vs. E- cores. > > > > Patch below should work, with verbose boot. > > > > > > Not much difference on that level: > > > > > > --- zzzp 2022-02-22 18:18:24.531704000 -0500 > > > +++ zzze 2022-02-22 18:18:18.631236000 -0500 > > > @@ -1,22 +1,21 @@ > > > -CPU 2: 12th Gen Intel(R) Core(TM) i7-12700K (3609.60-MHz K8-class CPU) > > > +CPU 16: 12th Gen Intel(R) Core(TM) i7-12700K (3609.60-MHz K8-class CPU) > > > Origin="GenuineIntel" Id=0x90672 Family=0x6 Model=0x97 Stepping=2 > > > Features=0xbfebfbff > > > Features2=0x7ffafbff > > > AMD Features=0x2c100800 > > > AMD Features2=0x121 > > > Structured Extended Features=0x239ca7eb > > > Structured Extended Features2=0x98c027ac > > > Structured Extended Features3=0xfc1cc410 > > > XSAVE Features=0xf > > > IA32_ARCH_CAPS=0xd6b > > > VT-x: Basic Features=0x3da0500 > > > Pin-Based Controls=0xff > > > Primary Processor Controls=0xfffbfffe > > > Secondary Processor Controls=0xf5d7fff > > > Exit Controls=0x3da0500 > > > Entry Controls=0x3da0500 > > > EPT Features=0x6f34141 > > > VPID Features=0x10f01 > > > TSC: P-state invariant, performance statistics > > > -64-Byte prefetching > > > -L2 cache: 1280 kbytes, 8-way associative, 64 bytes/line > > > +L2 cache: 2048 kbytes, 16-way associative, 64 bytes/line > > > > > > > Show me the full verbose dmesg of the boot then. > > > > As another blind guess, try to disable pcid, vm.pmap.pcid_enabled=0. > > > > Hi. > > Intel N100 is reported to crash without this tunable on 13.2 at > freebsd-users-jp ML (as this is a ML in Japanese, reported in > Japanese). [1] > Crashes with UFS, but ZFS is claimed to be OK. > > N100 is an Alder Lake-N processor WITHOUT P-CORE. [2] [3] > So check logics on workarouund codes (IIRC, all are MFC'ed before 13.2) > wouldn't be working? Show me the output from x86info -r on the machine, I do not care which specific core it is, they should be all the same. x86info is available as sysutils/x86info. From nobody Sun Aug 6 11:42:19 2023 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 4RJczC6Ghtz4pvCj for ; Sun, 6 Aug 2023 11:43:35 +0000 (UTC) (envelope-from doctor@doctor.nl2k.ab.ca) Received: from doctor.nl2k.ab.ca (doctor.nl2k.ab.ca [204.209.81.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 4RJczC4YvJz4JML for ; Sun, 6 Aug 2023 11:43:35 +0000 (UTC) (envelope-from doctor@doctor.nl2k.ab.ca) Authentication-Results: mx1.freebsd.org; none Received: from doctor by doctor.nl2k.ab.ca with local (Exim 4.96 (FreeBSD)) (envelope-from ) id 1qSc9L-000Mr9-2C; Sun, 06 Aug 2023 05:42:19 -0600 Date: Sun, 6 Aug 2023 05:42:19 -0600 From: The Doctor To: Damon Unric Cc: freebsd-current@freebsd.org Subject: Re: unsubscribe 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: 4RJczC4YvJz4JML X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6171, ipnet:204.209.81.0/24, country:CA] On Sun, Aug 06, 2023 at 09:01:42AM +0200, Damon Unric wrote: > unsubscribe > please do this via the mailman web interface. -- Member - Liberal International This is doctor@nk.ca Ici doctor@nk.ca Yahweh, King & country!Never Satan President Republic!Beware AntiChrist rising! Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b An extremist would label a moderate an extremist: know who is lying to you, or suffer. -unknown Beware https://mindspring.com From nobody Sun Aug 6 11:55:20 2023 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 4RJdDs1BzPz4pvjm for ; Sun, 6 Aug 2023 11:55:25 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (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 4RJdDr0CT1z4LPJ; Sun, 6 Aug 2023 11:55:24 +0000 (UTC) (envelope-from guru@unixarea.de) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of guru@unixarea.de designates 178.254.4.101 as permitted sender) smtp.mailfrom=guru@unixarea.de; dmarc=none Received: from [188.174.52.107] (helo=localhost.unixarea.de) by ms-10.1blu.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qScLx-0000Rp-MU; Sun, 06 Aug 2023 13:55:21 +0200 Received: from localhost.my.domain (localhost [127.0.0.1]) by localhost.unixarea.de (8.16.1/8.14.9) with ESMTPS id 376BtKIR027625 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 6 Aug 2023 13:55:20 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.16.1/8.14.9/Submit) id 376BtKir027624; Sun, 6 Aug 2023 13:55:20 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Sun, 6 Aug 2023 13:55:20 +0200 From: Matthias Apitz To: Kurt Jaeger Cc: freebsd-current@freebsd.org Subject: Re: poudriere && git Message-ID: Reply-To: Matthias Apitz Mail-Followup-To: Kurt Jaeger , freebsd-current@freebsd.org References: <20230805080811.GA11506@home.opsec.eu> 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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20230805080811.GA11506@home.opsec.eu> X-Operating-System: FreeBSD 13.0-CURRENT r368166 (amd64) X-message-flag: Mails containing HTML will not be read! Please send only plain text. X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 188.174.52.107 X-Spamd-Result: default: False [-1.59 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MID_RHS_NOT_FQDN(0.50)[]; NEURAL_SPAM_SHORT(0.21)[0.212]; R_SPF_ALLOW(-0.20)[+ip4:178.254.4.101]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_TWO(0.00)[2]; DMARC_NA(0.00)[unixarea.de]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; HAS_REPLYTO(0.00)[guru@unixarea.de]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; HAS_XOIP(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:42730, ipnet:178.254.0.0/19, country:DE]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; REPLYTO_EQ_FROM(0.00)[]; HAS_XAW(0.00)[]; RCVD_TLS_LAST(0.00)[] X-Spamd-Bar: - X-Rspamd-Queue-Id: 4RJdDr0CT1z4LPJ El día sábado, agosto 05, 2023 a las 10:08:11a. m. +0200, Kurt Jaeger escribió: > Hi! > > > In the past I created the jails based on svn, for example with > > > > # poudriere jail -c -j freebsd-r368166 -m svn+http -v head@r368166 > > I have the src repo in /usr/src, build the host system > from that tree and then use: > > poudriere jail -j head -u -m null -S /usr/src Hello, Sure you missed '-c'. i.e. the cmd you wanted is: poudriere jail -c -j head -m null -S /usr/src which gives an error: [00:00:00] Error: Must set -M to path of jail to use I don't know what to set for the path to -M. The host system is in /usr/src and /usr/obj. My old existing jail is: poudriere jail -l JAILNAME VERSION ARCH METHOD TIMESTAMP PATH freebsd-r368166 13.0-CURRENT 1300130 r368164 amd64 svn+http 2020-11-30 12:43:46 /usr/local/poudriere/jails/freebsd-r368166 Any idea, what should I set? Thanks matthias -- Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub From nobody Sun Aug 6 13:50:15 2023 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 4RJgnm53x2z4TmNJ for ; Sun, 6 Aug 2023 13:50:36 +0000 (UTC) (envelope-from trashcan@ellael.org) Received: from mx1.enfer-du-nord.net (mx1.enfer-du-nord.net [91.121.41.56]) (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 4RJgnm1sMCz4bPJ for ; Sun, 6 Aug 2023 13:50:36 +0000 (UTC) (envelope-from trashcan@ellael.org) Authentication-Results: mx1.freebsd.org; none Received: from smtpclient.apple (p5b2e5028.dip0.t-ipconnect.de [91.46.80.40]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.enfer-du-nord.net (Postfix) with ESMTPSA id 4RJgnY5yXkzGm4; Sun, 6 Aug 2023 15:50:25 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ellael.org; s=dkim; t=1691329825; 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=HsSb5kieC8U4q2pstztGOxEVx0Vd1gjBQi6KpW8dTh0=; b=HWfJ7XVAE00RRuQlDaOfxwf5vYKamg68D9N7a86r2znbpTDW8JpI2GpmOw/MSnmNYuBJcL SG4TqrkWtp4GSLLQbAcBOTM6PUkyIIq8SoQhB4vyjJZqF369ljMN1lmwBdzpshtSa17HM7 WRGeKg33n9iSJA7ULkKItTdy7+XnDLLCyZCCqiDYrc1QhkRRH8D3GnK+sr9IACpJqk+27y sWnpksF8ez29c1HYxXiJfNdwEVbb1erNSsS2YxR5gpZCQaMp0DqKVZIFGTsSI/1q19gfJK To8kzyZ8DVqPIRFgiTpvhSS+nvdxIvqRf1nqN6YEqgr1Xo6U8QO6ZL7ubNAoOw== 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 16.0 \(3731.700.6\)) Subject: Re: poudriere && git From: Michael Grimm In-Reply-To: Date: Sun, 6 Aug 2023 15:50:15 +0200 Cc: freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <78387A8F-1F30-4BA6-97A4-8E2DDC827008@ellael.org> References: <20230805080811.GA11506@home.opsec.eu> To: Matthias Apitz X-Mailer: Apple Mail (2.3731.700.6) X-Rspamd-Queue-Id: 4RJgnm1sMCz4bPJ X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16276, ipnet:91.121.0.0/16, country:FR] Matthias Apitz wrote > poudriere jail -c -j head -m null -S /usr/src >=20 > which gives an error: >=20 > [00:00:00] Error: Must set -M to path of jail to use >=20 > I don't know what to set for the path to -M. The host system is in > /usr/src and /usr/obj. My old existing jail is: >=20 > poudriere jail -l > JAILNAME VERSION ARCH METHOD TIMESTAMP = PATH > freebsd-r368166 13.0-CURRENT 1300130 r368164 amd64 svn+http 2020-11-30 = 12:43:46 /usr/local/poudriere/jails/freebsd-r368166 Creation: poudriere jail -c -j stable -m src=3D/usr/src poudriere jail -l JAILNAME VERSION ARCH METHOD TIMESTAMP PATH stable 13.2-STABLE 1302507 amd64 src=3D/usr/src 2023-08-05 15:01:13 = /usr/home/poudriere/jails/stable Updating: poudriere jail -u -j stable Regards, Michael From nobody Sun Aug 6 13:57:50 2023 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 4RJgyC4QKnz4Tn6G for ; Sun, 6 Aug 2023 13:57:55 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (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 4RJgyB2N6sz4cyQ for ; Sun, 6 Aug 2023 13:57:54 +0000 (UTC) (envelope-from guru@unixarea.de) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of guru@unixarea.de designates 178.254.4.101 as permitted sender) smtp.mailfrom=guru@unixarea.de; dmarc=none Received: from [188.174.52.107] (helo=localhost.unixarea.de) by ms-10.1blu.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qSeGV-0006aI-UB for freebsd-current@freebsd.org; Sun, 06 Aug 2023 15:57:52 +0200 Received: from localhost.my.domain (localhost [127.0.0.1]) by localhost.unixarea.de (8.16.1/8.14.9) with ESMTPS id 376DvoSr035954 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Sun, 6 Aug 2023 15:57:50 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.16.1/8.14.9/Submit) id 376DvolR035953 for freebsd-current@freebsd.org; Sun, 6 Aug 2023 15:57:50 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Sun, 6 Aug 2023 15:57:50 +0200 From: Matthias Apitz To: freebsd-current@freebsd.org Subject: make buildworld puts legacy tools into the /usr/obj/... tree Message-ID: Reply-To: Matthias Apitz 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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Operating-System: FreeBSD 13.0-CURRENT r368166 (amd64) X-message-flag: Mails containing HTML will not be read! Please send only plain text. X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 188.174.52.107 X-Spamd-Result: default: False [1.49 / 15.00]; NEURAL_SPAM_MEDIUM(0.58)[0.583]; MID_RHS_NOT_FQDN(0.50)[]; NEURAL_SPAM_LONG(0.40)[0.403]; NEURAL_SPAM_SHORT(0.31)[0.307]; R_SPF_ALLOW(-0.20)[+ip4:178.254.4.101]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[unixarea.de]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; BLOCKLISTDE_FAIL(0.00)[188.174.52.107:server fail,178.254.4.101:server fail]; REPLYTO_EQ_FROM(0.00)[]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; HAS_XAW(0.00)[]; TO_DN_NONE(0.00)[]; HAS_XOIP(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_THREE(0.00)[3]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:42730, ipnet:178.254.0.0/19, country:DE]; MIME_TRACE(0.00)[0:+]; HAS_REPLYTO(0.00)[guru@unixarea.de] X-Spamd-Bar: + X-Rspamd-Queue-Id: 4RJgyB2N6sz4cyQ I did, based of a git clone of head, a clean compile of world and kernel with # cd /usr # rm -rf obj # mkdir obj # cd src # make -j8 buildworld # make -j8 buildkernel ... I installed the result and the system runs fine. For some test I wanted to do another installation to some DESTDIR with # make installworld DESTDIR=/home/... This failed with: --- installworld --- mkdir -p /tmp/install.j76anzU56j ... Required library libdialog.so.8 not found. *** [installworld] Error code 1 make[1]: stopped in /usr/src Investigating the problem it turned out that the 'make buildworld' puts a lot of legacy binaries in to some directory: # ls -l /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin total 36976 -r-xr-xr-x 1 root wheel 13304 Nov 30 2020 [ lrwxr-xr-x 1 root wheel 54 Aug 5 13:05 apropos -> /usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin/mandoc -rwxr-xr-x 1 root wheel 1008512 Aug 5 13:05 asn1_compile -r-xr-xr-x 1 root wheel 217504 Nov 30 2020 awk -r-xr-xr-x 1 root wheel 9576 Nov 30 2020 basename -r-xr-xr-x 1 root wheel 195712 Nov 30 2020 bmake -r-xr-xr-x 1 root wheel 33848 Nov 30 2020 bunzip2 ... They are all from the system before updating it (from Nov 30 2020) and of course are missing shared libs when they get called in the actual system, for example # ldd /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin/tzsetup /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin/tzsetup: libdialog.so.8 => not found (0) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ libncursesw.so.9 => /lib/libncursesw.so.9 (0xf283d7b4000) libc.so.7 => /lib/libc.so.7 (0xf283e729000) libtinfow.so.9 => /lib/libtinfow.so.9 (0xf283c93d000) [vdso] (0xf283c4a4000) # which tzsetup /usr/sbin/tzsetup # ldd /usr/sbin/tzsetup /usr/sbin/tzsetup: libprivatebsddialog.so.0 => /usr/lib/libprivatebsddialog.so.0 (0x1797fe45c000) libc.so.7 => /lib/libc.so.7 (0x1797fec89000) libncursesw.so.9 => /lib/libncursesw.so.9 (0x1798011df000) libtinfow.so.9 => /lib/libtinfow.so.9 (0x17980043d000) libformw.so.6 => /usr/lib/libformw.so.6 (0x17980164c000) [vdso] (0x1797fe2d9000) Why is this with the tools in /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin ? Or what I have done wrong or overlooked? matthias -- Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub From nobody Sun Aug 6 14:11:00 2023 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 4RJhFM4P1hz4Tnwd for ; Sun, 6 Aug 2023 14:11:03 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (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 4RJhFM3zPGz3CCP for ; Sun, 6 Aug 2023 14:11:03 +0000 (UTC) (envelope-from guru@unixarea.de) Authentication-Results: mx1.freebsd.org; none Received: from [188.174.52.107] (helo=localhost.unixarea.de) by ms-10.1blu.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qSeTG-0003Xp-6J; Sun, 06 Aug 2023 16:11:02 +0200 Received: from localhost.my.domain (localhost [127.0.0.1]) by localhost.unixarea.de (8.16.1/8.14.9) with ESMTPS id 376EB1Yi036851 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 6 Aug 2023 16:11:01 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.16.1/8.14.9/Submit) id 376EB0MP036850; Sun, 6 Aug 2023 16:11:00 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Sun, 6 Aug 2023 16:11:00 +0200 From: Matthias Apitz To: Michael Grimm Cc: freebsd-current@freebsd.org Subject: Re: poudriere && git Message-ID: Reply-To: Matthias Apitz Mail-Followup-To: Michael Grimm , freebsd-current@freebsd.org References: <20230805080811.GA11506@home.opsec.eu> <78387A8F-1F30-4BA6-97A4-8E2DDC827008@ellael.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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <78387A8F-1F30-4BA6-97A4-8E2DDC827008@ellael.org> X-Operating-System: FreeBSD 13.0-CURRENT r368166 (amd64) X-message-flag: Mails containing HTML will not be read! Please send only plain text. X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 188.174.52.107 X-Rspamd-Queue-Id: 4RJhFM3zPGz3CCP X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:42730, ipnet:178.254.0.0/19, country:DE] El día domingo, agosto 06, 2023 a las 03:50:15p. m. +0200, Michael Grimm escribió: > Matthias Apitz wrote > > Creation: > poudriere jail -c -j stable -m src=/usr/src > Thanks. I tested this as well some hours ago and it failed for the reason I detailed some minutes ago in the other mail with the Subject: make buildworld puts legacy tools into the /usr/obj/... The jail creation does internally also a 'make installworld': # poudriere jail -c -j 140-CURRENT -m src=/usr/src [00:00:00] Creating 140-CURRENT fs at /usr/local/poudriere/jails/140-CURRENT... done [00:00:01] Copying /usr/src to /usr/local/poudriere/jails/140-CURRENT/usr/src... [00:02:02] Starting make installworld --- installworld --- make[1]: "/usr/obj/usr/src/amd64.amd64/toolchain-metadata.mk" line 1: Using cached toolchain metadata from build at jet on Sat Aug 5 14:12:11 CEST 2023 --- _installcheck_world --- -------------------------------------------------------------- >>> Install check world -------------------------------------------------------------- --- installworld --- mkdir -p /tmp/install.j76anzU56j ... Required library libdialog.so.8 not found. *** [installworld] Error code 1 make[1]: stopped in /usr/src 1 error I'm now already running a new "make buildworld" again, which perhaps will but the actual tools into .../legacy/... and they will work because tools and shared libs fit together. I think there is something broken in buildworld with these legacy stuff. In any case, thanks for your help. matthias -- Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub From nobody Sun Aug 6 15:05:10 2023 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 4RJjS815nRz4TsFk for ; Sun, 6 Aug 2023 15:05:28 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-yb1-xb30.google.com (mail-yb1-xb30.google.com [IPv6:2607:f8b0:4864:20::b30]) (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 4RJjS76S5rz3HvK for ; Sun, 6 Aug 2023 15:05:27 +0000 (UTC) (envelope-from kob6558@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-yb1-xb30.google.com with SMTP id 3f1490d57ef6-c5f98fc4237so3179816276.2 for ; Sun, 06 Aug 2023 08:05:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691334327; x=1691939127; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=ab+jtuSU1COYL6vNNGkmmd2jqZTDeqUXz6F0V0Dip5Q=; b=SPEpajGBj9/re0uraK+ToORzLxonefpmNuzedvk14VFrkndt0sYFXkpsu7zfW6J3dh 7YxksRIqiqpiLR0t+j0W9rB057vRc8c/c+GXxL0z/X707vwXF8EhioErFptjjDcnDUAX ZNlQIIYld+VVMDf8Il9GUfvCpjWUQk4TkfvhgiSK1GMI7XPLl5hQRSW/fOH2GPHz4DzR LrO56vvDcae6gUJqAd6iApqvEivKL5tzZTc7jetYZ26idKvjm0YPG4Zg5WLerFRsFCkI sxn1cGxcV1Fb9hi006B0b3JPn+m2C6KVW1AXrZkRJ7KcVDAGQ5RhRMFn1MoaCaZXTF6N a4PA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691334327; x=1691939127; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ab+jtuSU1COYL6vNNGkmmd2jqZTDeqUXz6F0V0Dip5Q=; b=FxzEDbOEDDZ688UQq3LSVDDLelaAKj8HeCDsb5/tXRiX+WrBbOke51ih2wHvRdFgU+ lL9HJv3qWM3Pm3hA5VNIsQftlzPypYCdek/BOvpmLpQFWwgEavXSzwADEEgkNfY+KxNs GhC4HybNXLHACm4efLNS9pfgKlU0A3gqIa79bifH55QkQoT2dYMmm0yCG++qlOcTxu/W E3Q0e6donJwWtu8XP2Z1R/XaK2MhNaXj9FV6i29El1QmOhLE0WmHxNL59R6sQQ3hVFk2 VPK+a+mpY0WSaYvcGbqILEeqEh2e47/nCEoM46ZfTJgKh4qqbOgKZxwS9Gye5c8n6eWY lJdg== X-Gm-Message-State: AOJu0YxlQrwltGAUUtpwyfUeNCVVj8O/Y77d4dx9g/qzzJDS+dW2CThT JNUV8inuIvQDm8cahn/DI7LYg+Y1KxlOWwWFEmM8VdKm X-Google-Smtp-Source: AGHT+IFwq3/4K5eNqvM65JDorI+LsSEj9g1V5Kgetk8uXCxcKdKCc/w0sgBjbHLp9GJtvsIiTJay0iWFOqSYN7VO/tY= X-Received: by 2002:a5b:a43:0:b0:d11:254a:aa71 with SMTP id z3-20020a5b0a43000000b00d11254aaa71mr5695214ybq.44.1691334326876; Sun, 06 Aug 2023 08:05:26 -0700 (PDT) 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: Kevin Oberman Date: Sun, 6 Aug 2023 08:05:10 -0700 Message-ID: Subject: Re: Has the update procedure changed? To: Matthias Apitz , freebsd-current@freebsd.org Content-Type: multipart/alternative; boundary="000000000000c0002506024275c9" X-Rspamd-Queue-Id: 4RJjS76S5rz3HvK X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] --000000000000c0002506024275c9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Aug 5, 2023 at 10:51=E2=80=AFPM Matthias Apitz w= rote: > In the past I was used to use the following procedure to install a new > kernel and world: > > # cd /usr/src > # make installkernel > # shutdown -r now > > boot -s from the loader prompt > > # adjkerntz -i > # mount -a -t ufs > # mergemaster -p > # cd /usr/src > # make installworld > # mergemaster > # yes | make delete-old > # yes | make delete-old-libs > > # reboot > > Now the handbook > https://docs.freebsd.org/en/books/handbook/cutting-edge/#makeworld > says only: > > # cd /usr/src > # make installkernel > # shutdown -r now > # cd /usr/src > # make installworld > # shutdown -r now > > Has this changed in past two years? > > Thanks > > matthias > -- > Matthias Apitz, =E2=9C=89 guru@unixarea.de, http://www.unixarea.de/ > +49-176-38902045 > Public GnuPG key: http://www.unixarea.de/key.pub > Wow! Several obvious reasons that this looks just wrong. (Then again, so is yours in one case.) 1. "mergemaster -p" MUST be run before you build the kernel. (Actually, hte man page says it should be run BEFORE buildworld and that is what I've always done although I have never seen a case where it was needed until buildkernel. 2. While mergemaster(8) is still in the system, you really should be using etcupdate(8). You also need to understand how a three-way merge is done and that you often need to edit the merged file when first running it. It's pretty simple to run and rarely is needed after the first run, but it is critical to do this for /etc files that you have modified. It's generally just picking which of the two (original/yours) you want in the final file. The big win with etcupdate(8) is that it only needs to be run once for modified files in almost all cases. 3. Where is "make check-old" and the other tests to get rid of old files. Leaving these around can lead to serious issues. 4. If you don't do adjkerntz -i, you might find files installed in the future which can get REALLY confusing! Historically, the final source of truth for all of this is /usr/src/UPDATING. It has been updated for etcupdate(8) and is handled by imp@, so I tend to believe it is correct. OK. Everyone who knows better, please explain why. I didn't mention "fsck -p" but I'm really paranoid and it really, really should not be needed unless something goes wrong in the shutdown after installing the new kernel= . --=20 Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkoberman@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 --000000000000c0002506024275c9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Aug 5, 2023 at 10:51=E2= =80=AFPM Matthias Apitz <guru@unixar= ea.de> wrote:
In the past I was used to use the followi= ng procedure to install a new
kernel and world:

=C2=A0 =C2=A0 # cd /usr/src
=C2=A0 =C2=A0 # make installkernel
=C2=A0 =C2=A0 # shutdown -r now

=C2=A0 =C2=A0 boot -s from the loader prompt

=C2=A0 =C2=A0 # adjkerntz -i
=C2=A0 =C2=A0 # mount -a -t ufs
=C2=A0 =C2=A0 # mergemaster -p
=C2=A0 =C2=A0 # cd /usr/src
=C2=A0 =C2=A0 # make installworld
=C2=A0 =C2=A0 # mergemaster
=C2=A0 =C2=A0 # yes | make delete-old
=C2=A0 =C2=A0 # yes | make delete-old-libs

=C2=A0 =C2=A0 # reboot

Now the handbook https://docs.free= bsd.org/en/books/handbook/cutting-edge/#makeworld
says only:

=C2=A0 =C2=A0 # cd /usr/src
=C2=A0 =C2=A0 # make installkernel
=C2=A0 =C2=A0 # shutdown -r now
=C2=A0 =C2=A0 # cd /usr/src
=C2=A0 =C2=A0 # make installworld
=C2=A0 =C2=A0 # shutdown -r now

Has this changed in past two years?

Thanks

=C2=A0 =C2=A0 =C2=A0 =C2=A0 matthias
--
Matthias Apitz, =E2=9C=89 guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
<= div>=C2=A0
Wow! Several obvious reasons that this look= s just wrong. (Then again, so is yours in one case.)
1. &quo= t;mergemaster -p" MUST be run before you build the kernel. (Actually, = hte man page says it should be run BEFORE buildworld and that is what I'= ;ve always done although I have never seen a case where it was needed until= buildkernel.
2. While mergemaster(8) is still in the system= , you really should be using etcupdate(8). You also need to understand how = a three-way merge is done and that you=C2=A0 often need to edit the merged = file when first running it.=C2=A0 It's pretty simple to run and rarely = is needed after the first run, but it is critical to do this for /etc files= that you have modified. It's generally just picking which of the two (= original/yours) you want in the final file. The big win with etcupdate(8) i= s that it only needs to be run once for modified files in almost all cases.=
3. Where is "make check-old" and the other tests = to get rid of old files. Leaving these around can lead to serious issues.
4. If you don't do adjkerntz -i, you might find files ins= talled in the future which can get REALLY=C2=A0 confusing!

Historically, the final source of truth for all of = this is /usr/src/UPDATING. It has been updated for etcupdate(8) and is hand= led by imp@, so I tend to believe it is correct.

<= div style=3D"font-family:tahoma,sans-serif;font-size:small" class=3D"gmail_= default">OK. Everyone who knows better, please explain why. I didn't me= ntion "fsck -p" but I'm really paranoid and it really, really= should not be needed unless something goes wrong in the shutdown after ins= talling the new kernel.
-- =
Kevin Oberman= , Part time kid herder and retired Network Engineer
E-mail: rkoberman@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
--000000000000c0002506024275c9-- From nobody Sun Aug 6 15:58:32 2023 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 4RJkdW05pVz4TwZx for ; Sun, 6 Aug 2023 15:58:39 +0000 (UTC) (envelope-from wlosh@bsdimp.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 4RJkdV2Sc8z3QG6 for ; Sun, 6 Aug 2023 15:58:38 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x533.google.com with SMTP id 4fb4d7f45d1cf-52307552b03so5214323a12.0 for ; Sun, 06 Aug 2023 08:58:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20221208.gappssmtp.com; s=20221208; t=1691337517; x=1691942317; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=wOXfSfjpuVD8GABy0QoBuI265+uS3sgd+sFp7wANHH8=; b=nUBh8vS8BWCjtsaJQal9tFRAbzTg4RO4jBl/9TqwXkWo33JVAyPy/bePH5LovrmZie hZDwShCZGjbQ1D8lIXMXHK/M022l1R7EuUON6vGNla9NHG1Ji2FRQLvbs3Ew5iPBYXb1 qszueyYCDq/JVtv7M0siki0U5TypQSqpI0KgHICZ39hriN5ivi5d6YnfWNo7937aWKOe jTk+E7vOWmKWvK4i0xSdtmM0+mjl7VOWDHx0wo7wzQJ8eKTMrZd2KwExwpsxyxIGXo6V NvIseCX051JN+yhW21MmTX2dJLpjinX6f4IjNSXqkcsp7U9H6uw16WVUsfLub6C+RrJH foVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691337517; x=1691942317; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=wOXfSfjpuVD8GABy0QoBuI265+uS3sgd+sFp7wANHH8=; b=IuWTv7Bcnwmesb2Wc8uoq3NAi7ZdihLm5NMQluekexQgFULLNkdnIcSV/r12lGjZ0X /+mP3Ei+s4IlpQkIrW6r8CLxOqHVsTU4e3MEW6ziY8DBOdBZjQt0dSMcyjT4UsOqnk4O Z2VbYdGf356r6IfUDrZQY+NyeIMQBX7meD+KOXWqZT6zdF+LwpwD7ymX0eKTCi+hhHla vG99NXJDh09T5O5sXC/2lIi2oYI86wl6H3CKrXG+fJqI1bKi+EoWcVR9c8D5hfBPH1Ea 39UwnuSMsp9Lr2EehdtoJI49OLUKA33Zu0f3kV8sHHMNlrB4Q8uFdctdr/zSp5eX0KEF RnKg== X-Gm-Message-State: AOJu0YwoSEQpdYLJpjC84yNXVe4l1csCmR4ALgeOiXr7Z3zjepgS8gUY BDI3oDfkhVa7nD2GHoWnjEB5BX2q7wWj8LZRcGq8UFXY1FBLmN0LKMU= X-Google-Smtp-Source: AGHT+IG2t9h+MXPWDz6fbT7kWuu3eOSaSk2jTXl69sGvlopOjBybDqZ34k25yEaqvMEPQBUMyFyYcekhou07csy2+48= X-Received: by 2002:aa7:c943:0:b0:522:b929:9f01 with SMTP id h3-20020aa7c943000000b00522b9299f01mr6059959edt.9.1691337516934; Sun, 06 Aug 2023 08:58:36 -0700 (PDT) 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: Sun, 6 Aug 2023 09:58:32 -0600 Message-ID: Subject: Re: make buildworld puts legacy tools into the /usr/obj/... tree To: Matthias Apitz , freebsd-current@freebsd.org Content-Type: multipart/alternative; boundary="000000000000e481f7060243335d" X-Rspamd-Queue-Id: 4RJkdV2Sc8z3QG6 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] --000000000000e481f7060243335d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Aug 6, 2023 at 7:58=E2=80=AFAM Matthias Apitz wr= ote: > > I did, based of a git clone of head, a clean compile of world and kernel > with > > # cd /usr > # rm -rf obj > # mkdir obj > # cd src > # make -j8 buildworld > # make -j8 buildkernel > ... > I installed the result and the system runs fine. For some test I wanted > to do another installation to some DESTDIR with > > # make installworld DESTDIR=3D/home/... > > This failed with: > > --- installworld --- > mkdir -p /tmp/install.j76anzU56j > > ... > Required library libdialog.so.8 not found. > *** [installworld] Error code 1 > > make[1]: stopped in /usr/src > > Investigating the problem it turned out that the 'make buildworld' puts > a lot of legacy binaries in to some directory: > > # ls -l /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin > total 36976 > -r-xr-xr-x 1 root wheel 13304 Nov 30 2020 [ > lrwxr-xr-x 1 root wheel 54 Aug 5 13:05 apropos -> > /usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin/mandoc > -rwxr-xr-x 1 root wheel 1008512 Aug 5 13:05 asn1_compile > -r-xr-xr-x 1 root wheel 217504 Nov 30 2020 awk > -r-xr-xr-x 1 root wheel 9576 Nov 30 2020 basename > -r-xr-xr-x 1 root wheel 195712 Nov 30 2020 bmake > -r-xr-xr-x 1 root wheel 33848 Nov 30 2020 bunzip2 > ... > They are all from the system before updating it (from Nov 30 2020) and > of course are missing shared libs when they get called in the actual > system, for example > > # ldd /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin/tzsetup > /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin/tzsetup: > libdialog.so.8 =3D> not found (0) > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > libncursesw.so.9 =3D> /lib/libncursesw.so.9 (0xf283d7b4000) > libc.so.7 =3D> /lib/libc.so.7 (0xf283e729000) > libtinfow.so.9 =3D> /lib/libtinfow.so.9 (0xf283c93d000) > [vdso] (0xf283c4a4000) > > # which tzsetup > /usr/sbin/tzsetup > # ldd /usr/sbin/tzsetup > /usr/sbin/tzsetup: > libprivatebsddialog.so.0 =3D> /usr/lib/libprivatebsddialog.so.0 > (0x1797fe45c000) > libc.so.7 =3D> /lib/libc.so.7 (0x1797fec89000) > libncursesw.so.9 =3D> /lib/libncursesw.so.9 (0x1798011df000) > libtinfow.so.9 =3D> /lib/libtinfow.so.9 (0x17980043d000) > libformw.so.6 =3D> /usr/lib/libformw.so.6 (0x17980164c000) > [vdso] (0x1797fe2d9000) > > Why is this with the tools in /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin= ? > Or what I have done wrong or overlooked? > So, the build process builds tools that are used to make and install FreeBSD. That's what legacy is about: providing a compatible way to do all this. We setup env vars, etc, so that these tools pull their libraries from legacy as well so that we have a consistent set of binaries to run on while the rest of the world is being replaced. I'm surprised to see this failing, since it's what nanobsd does all the time, and I build new systems with nanobsd every week based on recent current trees. Is there a libdalog.so.8 in your tmp/legacy tree at all? Warner --000000000000e481f7060243335d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Aug 6, 2023 at 7:58=E2=80=AFA= M Matthias Apitz <guru@unixarea.de> wrote:
I did, based of a git clone of head, a clean compile of world and kernel with

# cd /usr
# rm -rf obj
# mkdir obj
# cd src
# make -j8 buildworld
# make -j8 buildkernel
...
I installed the result and the system runs fine. For some test I wanted
to do another installation to some DESTDIR with

# make installworld DESTDIR=3D/home/...

This failed with:

--- installworld ---
mkdir -p /tmp/install.j76anzU56j

...
Required library libdialog.so.8 not found.
*** [installworld] Error code 1

make[1]: stopped in /usr/src

Investigating the problem it turned out that the 'make buildworld' = puts
a lot of legacy binaries in to some directory:

# ls -l /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin
total 36976
-r-xr-xr-x=C2=A0 1 root wheel=C2=A0 =C2=A013304 Nov 30=C2=A0 2020 [
lrwxr-xr-x=C2=A0 1 root wheel=C2=A0 =C2=A0 =C2=A0 54 Aug=C2=A0 5 13:05 apro= pos -> /usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin/mandoc
-rwxr-xr-x=C2=A0 1 root wheel 1008512 Aug=C2=A0 5 13:05 asn1_compile
-r-xr-xr-x=C2=A0 1 root wheel=C2=A0 217504 Nov 30=C2=A0 2020 awk
-r-xr-xr-x=C2=A0 1 root wheel=C2=A0 =C2=A0 9576 Nov 30=C2=A0 2020 basename<= br> -r-xr-xr-x=C2=A0 1 root wheel=C2=A0 195712 Nov 30=C2=A0 2020 bmake
-r-xr-xr-x=C2=A0 1 root wheel=C2=A0 =C2=A033848 Nov 30=C2=A0 2020 bunzip2 ...
They are all from the system before updating it (from Nov 30 2020) and
of course are missing shared libs when they get called in the actual
system, for example

# ldd /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin/tzsetup
/usr/obj/usr/src/amd64.amd64/tmp/legacy/bin/tzsetup:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 libdialog.so.8 =3D> not found (0)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
=C2=A0 =C2=A0 =C2=A0 =C2=A0 libncursesw.so.9 =3D> /lib/libncursesw.so.9 = (0xf283d7b4000)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 libc.so.7 =3D> /lib/libc.so.7 (0xf283e729000= )
=C2=A0 =C2=A0 =C2=A0 =C2=A0 libtinfow.so.9 =3D> /lib/libtinfow.so.9 (0xf= 283c93d000)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 [vdso] (0xf283c4a4000)

# which tzsetup
/usr/sbin/tzsetup
# ldd /usr/sbin/tzsetup
/usr/sbin/tzsetup:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 libprivatebsddialog.so.0 =3D> /usr/lib/libpr= ivatebsddialog.so.0 (0x1797fe45c000)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 libc.so.7 =3D> /lib/libc.so.7 (0x1797fec8900= 0)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 libncursesw.so.9 =3D> /lib/libncursesw.so.9 = (0x1798011df000)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 libtinfow.so.9 =3D> /lib/libtinfow.so.9 (0x1= 7980043d000)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 libformw.so.6 =3D> /usr/lib/libformw.so.6 (0= x17980164c000)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 [vdso] (0x1797fe2d9000)

Why is this with the tools in /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin ?=
Or what I have done wrong or overlooked?

So, the build process builds tools that are used to make and install Free= BSD.


--000000000000e481f7060243335d-- From nobody Sun Aug 6 16:00:55 2023 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 4RJkhF18Mlz4TwbM for ; Sun, 6 Aug 2023 16:01:01 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (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 4RJkhC6Y5sz3S50 for ; Sun, 6 Aug 2023 16:00:59 +0000 (UTC) (envelope-from guru@unixarea.de) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of guru@unixarea.de designates 178.254.4.101 as permitted sender) smtp.mailfrom=guru@unixarea.de; dmarc=none Received: from [188.174.52.107] (helo=localhost.unixarea.de) by ms-10.1blu.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qSgBd-00067k-AD; Sun, 06 Aug 2023 18:00:57 +0200 Received: from localhost.my.domain (localhost [127.0.0.1]) by localhost.unixarea.de (8.16.1/8.14.9) with ESMTPS id 376G0t3P044343 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 6 Aug 2023 18:00:55 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.16.1/8.14.9/Submit) id 376G0tJ6044342; Sun, 6 Aug 2023 18:00:55 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Sun, 6 Aug 2023 18:00:55 +0200 From: Matthias Apitz To: Michael Grimm , freebsd-current@freebsd.org Subject: Re: poudriere && git Message-ID: Reply-To: Matthias Apitz Mail-Followup-To: Michael Grimm , freebsd-current@freebsd.org References: <20230805080811.GA11506@home.opsec.eu> <78387A8F-1F30-4BA6-97A4-8E2DDC827008@ellael.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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: FreeBSD 13.0-CURRENT r368166 (amd64) X-message-flag: Mails containing HTML will not be read! Please send only plain text. X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 188.174.52.107 X-Spamd-Result: default: False [-2.76 / 15.00]; NEURAL_HAM_MEDIUM(-0.99)[-0.990]; NEURAL_HAM_SHORT(-0.99)[-0.988]; NEURAL_HAM_LONG(-0.98)[-0.985]; MID_RHS_NOT_FQDN(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:178.254.4.101]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; TO_DN_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:42730, ipnet:178.254.0.0/19, country:DE]; HAS_XOIP(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; HAS_XAW(0.00)[]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[unixarea.de]; HAS_REPLYTO(0.00)[guru@unixarea.de] X-Spamd-Bar: -- X-Rspamd-Queue-Id: 4RJkhC6Y5sz3S50 El día domingo, agosto 06, 2023 a las 04:11:00p. m. +0200, Matthias Apitz escribió: > -------------------------------------------------------------- > --- installworld --- > mkdir -p /tmp/install.j76anzU56j > > ... > Required library libdialog.so.8 not found. > *** [installworld] Error code 1 > > make[1]: stopped in /usr/src > 1 error Now after a new 'make buildworld' the jail creation worked fine: # poudriere jail -c -j 140-CURRENT -m src=/usr/src ... [00:02:27] Recording filesystem state for clean... done [00:02:28] Jail 140-CURRENT 14.0-CURRENT 1400094 amd64 is ready to be used # poudriere jail -l JAILNAME VERSION ARCH METHOD TIMESTAMP PATH 140-CURRENT 14.0-CURRENT 1400094 amd64 src=/usr/src 2023-08-06 17:35:06 /usr/local/poudriere/jails/140-CURRENT freebsd-r368166 13.0-CURRENT 1300130 r368164 amd64 svn+http 2020-11-30 12:43:46 /usr/local/poudriere/jails/freebsd-r368166 I will file a PR about this legacy files problem. Thanks for your help. matthias -- Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub From nobody Sun Aug 6 16:03:48 2023 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 4RJklZ50Prz4TxRb for ; Sun, 6 Aug 2023 16:03:54 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (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 4RJklZ2ypkz3TGT for ; Sun, 6 Aug 2023 16:03:54 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x52d.google.com with SMTP id 4fb4d7f45d1cf-5230ac6dbc5so4999096a12.3 for ; Sun, 06 Aug 2023 09:03:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20221208.gappssmtp.com; s=20221208; t=1691337833; x=1691942633; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=/yuJQWXoFRVnLOOluzJWkWMNS/WK+8nT5HcBAOVIvkU=; b=L6qhH8ggKz12vsuIti2upT8nzgthVbAGUCHLkwm8KONSYV3Z9Rw7tnTdRgeWzhuaUG ouMcZ6XzSeepfUfv+/hf3DtAXpd/2aQLU0DJd4Q1924UhZWj16NkW9e8SpMaFslGFXwH t6oNPpkzsUcaREi11c6UDgqyFLrruoEKnHTBFRIpuV5p5YldTg71dMOmmGXJP2k3Idv9 1q5Vy0JQIhXZMkeqlBctYE0ClpFt4xtZrA5KO8DaplujyNjB5XAowJIL+f4g4p4/YuAS +uKTWICN4/m9b3zsyGD7M1o6x8v3heBXQa63WLcElHmutYXYPw3da7Pm+qZ20pina8iU UiJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691337833; x=1691942633; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=/yuJQWXoFRVnLOOluzJWkWMNS/WK+8nT5HcBAOVIvkU=; b=lc/15ucnRlmeNwtniATDRh9BtAcgduDIvGbcdpUPUMof2P0j59HROBYXVq0hBS/HWv KtDXZbJ42WJtD9XQwxn+L2DEKJovflNWExrwxin8lOwAPlPT6cI6XX0qUL97qVHRL4Ix +D78au7ofQYMl5TPeUg/j0V33Egg/YPe3hYF4Lvw8Tb0pgEn+0/ukSYLR6rmPX/6Y+Td Aqv/aFW/aFQcpr3eZc2gfjplKftXk2/MwDQczzqgPhZkO6o3niq6MG5tstfWGbGVfxQv QstwaKahQPvzjxrNjAa3UIHFs+WNN1xPCftC8FVnueBbuDF2LCiVM/TCZyA8bpPh/let 8Vvg== X-Gm-Message-State: AOJu0Yy147jWzq3myaCGSNB8/b1D2lt6qfGhTCM/oC9q/PEubrgQfPJD k4tm9hf4iFoBRXpIwa3UdhpIF4sxGB/rES2E/3iiF+7hyf1ft8C8cxY= X-Google-Smtp-Source: AGHT+IGFfHWVCQxepaIJg5nPZ1JoM7YHK2dKKY/56Pf/RaqhQA20/FC35ayTeNdvsQYfsDFiwa9uQfEHSHKt0/XDDfY= X-Received: by 2002:aa7:d6cd:0:b0:522:21a1:5153 with SMTP id x13-20020aa7d6cd000000b0052221a15153mr6712556edr.11.1691337832823; Sun, 06 Aug 2023 09:03:52 -0700 (PDT) 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: <20230805080811.GA11506@home.opsec.eu> <78387A8F-1F30-4BA6-97A4-8E2DDC827008@ellael.org> In-Reply-To: From: Warner Losh Date: Sun, 6 Aug 2023 10:03:48 -0600 Message-ID: Subject: Re: poudriere && git To: Matthias Apitz , Michael Grimm , freebsd-current@freebsd.org Content-Type: multipart/alternative; boundary="000000000000b88ca606024346b2" X-Rspamd-Queue-Id: 4RJklZ2ypkz3TGT X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] --000000000000b88ca606024346b2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Aug 6, 2023 at 10:01=E2=80=AFAM Matthias Apitz w= rote: > El d=C3=ADa domingo, agosto 06, 2023 a las 04:11:00p. m. +0200, Matthias = Apitz > escribi=C3=B3: > > > -------------------------------------------------------------- > > --- installworld --- > > mkdir -p /tmp/install.j76anzU56j > > > > ... > > Required library libdialog.so.8 not found. > > *** [installworld] Error code 1 > > > > make[1]: stopped in /usr/src > > 1 error > > Now after a new 'make buildworld' the jail creation worked fine: > > # poudriere jail -c -j 140-CURRENT -m src=3D/usr/src > ... > [00:02:27] Recording filesystem state for clean... done > [00:02:28] Jail 140-CURRENT 14.0-CURRENT 1400094 amd64 is ready to be use= d > > # poudriere jail -l > JAILNAME VERSION ARCH METHOD TIMESTAMP > PATH > 140-CURRENT 14.0-CURRENT 1400094 amd64 src=3D/usr/src 2023-08= -06 > 17:35:06 /usr/local/poudriere/jails/140-CURRENT > freebsd-r368166 13.0-CURRENT 1300130 r368164 amd64 svn+http 2020-11-3= 0 > 12:43:46 /usr/local/poudriere/jails/freebsd-r368166 > > I will file a PR about this legacy files problem. Thanks for your help. > Unless there's a way to reproduce the problem from a clean build, I doubt it will ever be addressed. It works for me, so I need the exact steps to do from a clean state to get to failure. I just did a installworld and that works just fine with DESTDIR for me, so puzzling out how your system got into a weird state is a big time sink that I don't have time to do. if there's a set of simple steps, then either that can be documented as broken/unsupported or fixed. Warner --000000000000b88ca606024346b2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Aug 6, 2023 at 10:01=E2=80=AF= AM Matthias Apitz <guru@unixarea.de<= /a>> wrote:
E= l d=C3=ADa domingo, agosto 06, 2023 a las 04:11:00p. m. +0200, Matthias Api= tz escribi=C3=B3:

> --------------------------------------------------------------
> --- installworld ---
> mkdir -p /tmp/install.j76anzU56j
>
> ...
> Required library libdialog.so.8 not found.
> *** [installworld] Error code 1
>
> make[1]: stopped in /usr/src
> 1 error

Now after a new 'make buildworld' the jail creation worked fine:
# poudriere jail -c -j 140-CURRENT -m src=3D/usr/src
...
[00:02:27] Recording filesystem state for clean... done
[00:02:28] Jail 140-CURRENT 14.0-CURRENT 1400094 amd64 is ready to be used<= br>
# poudriere jail -l
JAILNAME=C2=A0 =C2=A0 =C2=A0 =C2=A0 VERSION=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ARCH=C2=A0 METHOD=C2=A0 =C2= =A0 =C2=A0 =C2=A0TIMESTAMP=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0PATH
140-CURRENT=C2=A0 =C2=A0 =C2=A014.0-CURRENT 1400094=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0amd64 src=3D/usr/src 2023-08-06 17:35:06 /usr/local/poudriere/jai= ls/140-CURRENT
freebsd-r368166 13.0-CURRENT 1300130 r368164 amd64 svn+http=C2=A0 =C2=A0 = =C2=A02020-11-30 12:43:46 /usr/local/poudriere/jails/freebsd-r368166

I will file a PR about this legacy files problem. Thanks for your help.
=

--000000000000b88ca606024346b2-- From nobody Sun Aug 6 16:05:38 2023 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 4RJknd6qK2z4TxVB for ; Sun, 6 Aug 2023 16:05:41 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (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 4RJknd61sfz3V6d for ; Sun, 6 Aug 2023 16:05:41 +0000 (UTC) (envelope-from guru@unixarea.de) Authentication-Results: mx1.freebsd.org; none Received: from [188.174.52.107] (helo=localhost.unixarea.de) by ms-10.1blu.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qSgGC-0003qt-89; Sun, 06 Aug 2023 18:05:40 +0200 Received: from localhost.my.domain (localhost [127.0.0.1]) by localhost.unixarea.de (8.16.1/8.14.9) with ESMTPS id 376G5dhP044667 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 6 Aug 2023 18:05:39 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.16.1/8.14.9/Submit) id 376G5cIf044666; Sun, 6 Aug 2023 18:05:38 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Sun, 6 Aug 2023 18:05:38 +0200 From: Matthias Apitz To: Warner Losh Cc: freebsd-current@freebsd.org Subject: Re: make buildworld puts legacy tools into the /usr/obj/... tree Message-ID: Reply-To: Matthias Apitz Mail-Followup-To: Warner Losh , freebsd-current@freebsd.org 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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: FreeBSD 13.0-CURRENT r368166 (amd64) X-message-flag: Mails containing HTML will not be read! Please send only plain text. X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 188.174.52.107 X-Rspamd-Queue-Id: 4RJknd61sfz3V6d X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:42730, ipnet:178.254.0.0/19, country:DE] El día domingo, agosto 06, 2023 a las 09:58:32a. m. -0600, Warner Losh escribió: > On Sun, Aug 6, 2023 at 7:58 AM Matthias Apitz wrote: > > > > > I did, based of a git clone of head, a clean compile of world and kernel > > with > > > > # cd /usr > > # rm -rf obj > > # mkdir obj > > # cd src > > # make -j8 buildworld > > # make -j8 buildkernel > > ... > > I installed the result and the system runs fine. For some test I wanted > > to do another installation to some DESTDIR with > > > > # make installworld DESTDIR=/home/... > > > > This failed with: > > > > --- installworld --- > > mkdir -p /tmp/install.j76anzU56j > > > > ... > > Required library libdialog.so.8 not found. > > *** [installworld] Error code 1 > > > > make[1]: stopped in /usr/src > > > > Investigating the problem it turned out that the 'make buildworld' puts > > a lot of legacy binaries in to some directory: > > > > # ls -l /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin > > total 36976 > > -r-xr-xr-x 1 root wheel 13304 Nov 30 2020 [ > > lrwxr-xr-x 1 root wheel 54 Aug 5 13:05 apropos -> > > /usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin/mandoc > > -rwxr-xr-x 1 root wheel 1008512 Aug 5 13:05 asn1_compile > > -r-xr-xr-x 1 root wheel 217504 Nov 30 2020 awk > > -r-xr-xr-x 1 root wheel 9576 Nov 30 2020 basename > > -r-xr-xr-x 1 root wheel 195712 Nov 30 2020 bmake > > -r-xr-xr-x 1 root wheel 33848 Nov 30 2020 bunzip2 > > ... > > They are all from the system before updating it (from Nov 30 2020) and > > of course are missing shared libs when they get called in the actual > > system, for example > > > > # ldd /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin/tzsetup > > /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin/tzsetup: > > libdialog.so.8 => not found (0) > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > libncursesw.so.9 => /lib/libncursesw.so.9 (0xf283d7b4000) > > libc.so.7 => /lib/libc.so.7 (0xf283e729000) > > libtinfow.so.9 => /lib/libtinfow.so.9 (0xf283c93d000) > > [vdso] (0xf283c4a4000) > > > > # which tzsetup > > /usr/sbin/tzsetup > > # ldd /usr/sbin/tzsetup > > /usr/sbin/tzsetup: > > libprivatebsddialog.so.0 => /usr/lib/libprivatebsddialog.so.0 > > (0x1797fe45c000) > > libc.so.7 => /lib/libc.so.7 (0x1797fec89000) > > libncursesw.so.9 => /lib/libncursesw.so.9 (0x1798011df000) > > libtinfow.so.9 => /lib/libtinfow.so.9 (0x17980043d000) > > libformw.so.6 => /usr/lib/libformw.so.6 (0x17980164c000) > > [vdso] (0x1797fe2d9000) > > > > Why is this with the tools in /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin ? > > Or what I have done wrong or overlooked? > > > > So, the build process builds tools that are used to make and install > FreeBSD. > That's what legacy is about: providing a compatible way to do all this. We > setup env vars, etc, so that these tools pull their libraries from legacy > as well > so that we have a consistent set of binaries to run on while the rest of > the world > is being replaced. I'm surprised to see this failing, since it's what > nanobsd does > all the time, and I build new systems with nanobsd every week based on > recent > current trees. > > Is there a libdalog.so.8 in your tmp/legacy tree at all? No, there is not: root@jet:~ # find /usr/obj.broken -name libdalog.so.8 root@jet:~ # The problem, for sure, is not when you build every day, but in my case the last build (and the system used for building) was 2 years old. And note: I started with an empty new /usr/obj. matthias -- Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub From nobody Sun Aug 6 16:05:59 2023 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 4RJkp54Yzyz4TxPx for ; Sun, 6 Aug 2023 16:06:05 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (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 4RJkp51rkHz3W6j for ; Sun, 6 Aug 2023 16:06:05 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x535.google.com with SMTP id 4fb4d7f45d1cf-51a52a7d859so10177440a12.0 for ; Sun, 06 Aug 2023 09:06:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20221208.gappssmtp.com; s=20221208; t=1691337963; x=1691942763; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=hLJwVpxtS1k0WHYjpRcnmmYXvsHokp98uQlMK9Hd9gY=; b=BJzBzGPWMHYLO1APRHSb4YMbsg5M9rCrmJV1gIbSssU12ddnVvOlKi/yECsOJjqsB8 YYoPryGnJoVSdKKFFL4REkJVMQCW7Ysyx82urTF9IYBJgK0+pGjGoFH1/GDc56HrGY/x 4AoaTLMRvgD1VhdEv3ZoAYncPifjQB0i8lup1chwcOqW4BM3QZUy2CfSRF2t/ug/Qq4z Y02fBTLpntPOyPdkVzDl1sFStJMJTDFQvn4EKWmlNhyJgbbOPR4/kx8Q5EqCcl00ivf4 Z8QSzv04or1osWTL2KXvc8f+8WwkLDf4Vt9+eEmblsAvKXTRuZipC0+1LD4RE04RQC3E eutQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691337963; x=1691942763; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=hLJwVpxtS1k0WHYjpRcnmmYXvsHokp98uQlMK9Hd9gY=; b=ggsopWi3Ai9hBwsyEd8vMKNO+QtjAaMXUDL0TFqXMpuneNlvx8rdJ5s4sqe90H6eeX yulriSGXzB2tehRiEACDE3NVPe/rQ3g2Z6qbWyEo9Mk+Ca+qOVv/P0faGZN/SCCR9n2j 5GypnW/zPjMHU6UvcDn9pChYVM8vB7uBfkD8Xuh/rnBvz3xhYrh/Y4cPJG87aOZuDDtB 6WMD5EtpENKLrywtuTNnjICcawfKHS1G/8rOjK/ezszO/3Rpjy5F3644EM9YLSCd3bNG wLtuIkfB3TEFlgQfXIA1n3M+jjkHLm8DuHDsrXWryIi2uIYPXrmy8WpQbknQA9AlY64P zSxA== X-Gm-Message-State: AOJu0YzO1fcnS/8HP42cGlu1U+hvlBb2s7gFC+RiljSc5bkyD2XGp+f3 1wwKDfWW9OwzVXAghv//96OH5VU8tJ1c/xp+1jcagmxZ6w1FPatn+gY= X-Google-Smtp-Source: AGHT+IEIWjHV5/4niq0072tW9AKnzVHU1n6OTlLZg/pWi4LVVJzMvICxdjFYH0yvxy9t7uraqZbhcJRWD9FIPa+lHgE= X-Received: by 2002:a05:6402:268b:b0:522:4e49:4e45 with SMTP id w11-20020a056402268b00b005224e494e45mr6186143edd.0.1691337963634; Sun, 06 Aug 2023 09:06:03 -0700 (PDT) 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: <62d300c8-2c3e-58fa-334e-23a17962279a@freebsd.org> <753f3990-9903-3718-445c-49fc01f960a7@freebsd.org> In-Reply-To: From: Warner Losh Date: Sun, 6 Aug 2023 10:05:59 -0600 Message-ID: Subject: Re: Fwd: Unreliability with DHCP To: Kevin Oberman Cc: Graham Perrin , freebsd-current@freebsd.org Content-Type: multipart/alternative; boundary="00000000000084976b0602434e6f" X-Rspamd-Queue-Id: 4RJkp51rkHz3W6j X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] --00000000000084976b0602434e6f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Aug 6, 2023 at 12:38=E2=80=AFAM Kevin Oberman = wrote: > On Sat, Aug 5, 2023 at 3:16=E2=80=AFPM Graham Perrin > wrote: > >> On 05/08/2023 12:39, Oleksandr Kryvulia wrote: >> > 04.08.23 19:07, Graham Perrin =D0=BF=D0=B8=D1=88=D0=B5: >> >> >> >> Can anyone from freebsd-net@ help? >> >> >> >> >> >> -------- Forwarded Message -------- >> >> Subject: Unreliability with DHCP >> >> Date: Sun, 30 Jul 2023 16:17:43 +0100 >> >> From: Graham Perrin >> >> Organisation: FreeBSD >> >> To: FreeBSD CURRENT >> >> >> >> >> >> >> >> 1. Sleep (suspend) whilst connected to one network >> >> >> >> 2. connect to a network elsewhere >> >> >> >> 3. wake (resume). >> >> >> >> Result: >> >> >> >> /etc/resolv.conf frequently contains outdated information. In some >> >> (maybe all) such cases, the IPv4 inet address is outdated; and so on. >> >> >> >> Which /etc/rc.d/ file(s) should I attempt to fix? >> >> >> >> I imagine using the resume keyword, which is currently used by only >> >> one script: >> >> >> >> % rcorder -k resume /etc/rc.d/* >> >> /etc/rc.d/ntpd >> >> % >> >> >> >> >> >> I routinely run the command below to work around the bug (and observe >> >> the states of things) =E2=80=93 run _after_ the bug bites. I'd prefer= a fix, >> >> to prevent the bites. >> >> >> >> ls /var/run/resolvconf/interfaces/ ; route delete default ; ifconfig >> >> wlan0 down && ifconfig em0 down && sleep 5 ; ls >> >> /var/run/resolvconf/interfaces/ ; ifconfig em0 up && sleep 15 >> >> ; ls /var/run/resolvconf/interfaces/ ; cat /etc/resolv.conf ; ping -c >> >> 2 -4 freshports.org >> >> >> > >> > >> > As dirty workaround I have in my /etc/rc.resume >> > >> > service netif restart >> > service routing restart >> >> >> Thanks, I'll try when I'm next on campus. >> >> I do know that 'service routing restart' can be problematic. Please, >> see, for example, ; I had something >> similar a few minutes ago. >> > > My usual solution is "service netif restart wlan0" (or the interface you > are using). It should restart the interface, if rc.conf calls for it, > dhcpclient and wpa_supplicant (if appropriate). > I'll have to remember that. I've been removing and reinsterting my usb dongle when when dhclient fails. I'd like to move to the internal wlan card, but the driver support has some show-stopper issues with suspend/resume for me more basic than dhclient... However, once those are resolved, I'd need a way to workaround the dhclient bug. Anybody have a clue why this is needed? Warner --00000000000084976b0602434e6f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Aug 6, 2023 at 12:38=E2=80=AF= AM Kevin Oberman <rkoberman@gmail= .com> wrote:
On Sat, Aug 5, 2023 at 3:16=E2=80=AFPM Graham Perri= n <grahamp= errin@freebsd.org> wrote:
On 05/08/2023 12:39, Oleksand= r Kryvulia wrote:
> 04.08.23 19:07, Graham Perrin =D0=BF=D0=B8=D1=88=D0=B5:
>>
>> Can anyone from freebsd-net@ help?
>>
>>
>> -------- Forwarded Message --------
>> Subject:=C2=A0=C2=A0=C2=A0=C2=A0 Unreliability with DHCP
>> Date:=C2=A0=C2=A0=C2=A0=C2=A0 Sun, 30 Jul 2023 16:17:43 +0100
>> From:=C2=A0=C2=A0=C2=A0=C2=A0 Graham Perrin <grahamperrin@freebsd.org>= ;
>> Organisation:=C2=A0=C2=A0=C2=A0=C2=A0 FreeBSD
>> To:=C2=A0=C2=A0=C2=A0=C2=A0 FreeBSD CURRENT <freebsd-current@freebsd.org<= /a>>
>>
>>
>>
>> 1. Sleep (suspend) whilst connected to one network
>>
>> 2. connect to a network elsewhere
>>
>> 3. wake (resume).
>>
>> Result:
>>
>> /etc/resolv.conf frequently contains outdated information. In some=
>> (maybe all) such cases, the IPv4 inet address is outdated; and so = on.
>>
>> Which /etc/rc.d/ file(s) should I attempt to fix?
>>
>> I imagine using the resume keyword, which is currently used by onl= y
>> one script:
>>
>> % rcorder -k resume /etc/rc.d/*
>> /etc/rc.d/ntpd
>> %
>>
>>
>> I routinely run the command below to work around the bug (and obse= rve
>> the states of things) =E2=80=93 run _after_ the bug bites. I'd= prefer a fix,
>> to prevent the bites.
>>
>> ls /var/run/resolvconf/interfaces/ ; route delete default ; ifconf= ig
>> wlan0 down && ifconfig em0 down && sleep 5 ; ls >> /var/run/resolvconf/interfaces/ ; ifconfig em0 up && sleep= 15
>> ; ls /var/run/resolvconf/interfaces/ ; cat /etc/resolv.conf ; ping= -c
>> 2 -4 freshports.org
>>
>
>
> As dirty workaround I have in my /etc/rc.resume
>
> service netif restart
> service routing restart


Thanks, I'll try when I'm next on campus.

I do know that 'service routing restart' can be problematic. Please= ,
see, for example, <https://pastebin.com/raw/mXmVPruq>; I = had something
similar a few minutes ago.

My usual solution is "service netif restart wlan0&quo= t; (or the interface you are using). It should restart the interface, if rc= .conf calls for it, dhcpclient and wpa_supplicant (if appropriate). =

I'll have to rem= ember that. I've been removing and reinsterting my usb dongle when when= dhclient fails.
I'd like to move to the internal wlan card, = but the driver support has some show-stopper issues with
suspend/= resume for me more basic than dhclient... However, once those are resolved,= I'd need a way to
workaround the dhclient bug.
Anybody have a clue why this is needed?

Warner
--00000000000084976b0602434e6f-- From nobody Sun Aug 6 16:11:27 2023 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 4RJkwM6BJfz4Txhx for ; Sun, 6 Aug 2023 16:11:31 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (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 4RJkwM5kW3z3XMr for ; Sun, 6 Aug 2023 16:11:31 +0000 (UTC) (envelope-from guru@unixarea.de) Authentication-Results: mx1.freebsd.org; none Received: from [188.174.52.107] (helo=localhost.unixarea.de) by ms-10.1blu.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qSgLp-0002GN-KS; Sun, 06 Aug 2023 18:11:29 +0200 Received: from localhost.my.domain (localhost [127.0.0.1]) by localhost.unixarea.de (8.16.1/8.14.9) with ESMTPS id 376GBRZJ045060 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 6 Aug 2023 18:11:27 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.16.1/8.14.9/Submit) id 376GBRH0045059; Sun, 6 Aug 2023 18:11:27 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Sun, 6 Aug 2023 18:11:27 +0200 From: Matthias Apitz To: Warner Losh Cc: Michael Grimm , freebsd-current@freebsd.org Subject: Re: poudriere && git Message-ID: Reply-To: Matthias Apitz Mail-Followup-To: Warner Losh , Michael Grimm , freebsd-current@freebsd.org References: <20230805080811.GA11506@home.opsec.eu> <78387A8F-1F30-4BA6-97A4-8E2DDC827008@ellael.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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: FreeBSD 13.0-CURRENT r368166 (amd64) X-message-flag: Mails containing HTML will not be read! Please send only plain text. X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 188.174.52.107 X-Rspamd-Queue-Id: 4RJkwM5kW3z3XMr X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:42730, ipnet:178.254.0.0/19, country:DE] El día domingo, agosto 06, 2023 a las 10:03:48a. m. -0600, Warner Losh escribió: > Unless there's a way to reproduce the problem from a clean build, I doubt > it will ever be addressed. It works for me, so I need the exact steps to do > from a clean state to get to failure. I just did a installworld and that > works just fine with DESTDIR for me, so puzzling out how your system got > into a weird state is a big time sink that I don't have time to do. if > there's a set of simple steps, then either that can be documented as > broken/unsupported or fixed. There is an easy way to reproduce: install an older FreeBSD, let's say 12.0, update /usr/src with git to head, and run # rm -rf /usr/obj # make buildworld # make installworld DESTDIR=/foo HIH matthias -- Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub From nobody Sun Aug 6 16:12:03 2023 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 4RJkx66dJ9z4TxnR for ; Sun, 6 Aug 2023 16:12:10 +0000 (UTC) (envelope-from wlosh@bsdimp.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 4RJkx61JrKz3YdJ for ; Sun, 6 Aug 2023 16:12:10 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x536.google.com with SMTP id 4fb4d7f45d1cf-52164adea19so4809478a12.1 for ; Sun, 06 Aug 2023 09:12:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20221208.gappssmtp.com; s=20221208; t=1691338328; x=1691943128; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=RgxzU+sv+uSPNZ3w7eSN8sbDdkGOjRexy8XMEISVaso=; b=BYsqbJPswqTETOuDIC8WGcaucoOhQAGxdRW+ntH0AFWZM7lkdWgdpTNt3daWhM1eoO rs45pSQ0/eby+LeIOSnPsHGNiY3zbFlLdxNOsesQsFbUkFgjpzd9fm6DFDbTBvaKPgfG JmPuwj5pAcqoSJ9+8dRcLTgmLLHzo8AwI4nQgcsuAtoQXp4vD6iyIGXKQ59sb9R3PK9R kFoieAh+6so8Hsbiyba2rcL6K9fADivqcKqvJZDOhLnd6xOtmRphjbMMluX2SaZSefQ4 SN4vj/05tEuVYygX3es7A/xBprx3kbeutGmrb2JcwcOBHcMAWiqPKr8ra2CO6DgU2Z5F XCKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691338328; x=1691943128; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=RgxzU+sv+uSPNZ3w7eSN8sbDdkGOjRexy8XMEISVaso=; b=cOwJWH2yPPrWW64D5/Sgiq0MiluE9+0qrnzkPYcNQ9yU8eb+V5mAHeQHtx8qAH3727 9Pxz+qPLN6wUR0Z0uFTjXXnWYrTZG/pu/rHFst0ruTP2+D5/AYNM+SQqu0pqqBcEhN9o IR+Yrz8TTnKfhTDCi3h8sLcGH/rv2rcvaCr9Vo1/mPfQlA4kduIXQ+IBT8N1b2J/SeU3 76ltm0jKY1StpzLzFmAqfEoIENa2kxFjXjvQiIilA4CmnOMY77OaTwjLIA/jPGLx03Te hnJbK7HRTlEZ1WrrtWiE39uvjvfVWgGPxkbsY21WaN5I6ofzO4laAuu+2SJcu9X8e5uV 33KA== X-Gm-Message-State: AOJu0YwUQNcil/FiFQMQazWrJ3NdDft6L8poko2hYaP+4yOSo6aL0qpj Urvev1mxG9X8tFMCZBxczupOlEotbOC67cyTJ4oBng== X-Google-Smtp-Source: AGHT+IEs1QcBaboJlwDQ3BogFKx1aGBVQmCaKlTSmg4D5IGi2jYyuDlhRKItIxlzPpiXkKwOF5PP9RuhApRmQj7G7xs= X-Received: by 2002:a50:ec95:0:b0:523:290c:3f78 with SMTP id e21-20020a50ec95000000b00523290c3f78mr3655300edr.14.1691338327879; Sun, 06 Aug 2023 09:12:07 -0700 (PDT) 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: Sun, 6 Aug 2023 10:12:03 -0600 Message-ID: Subject: Re: make buildworld puts legacy tools into the /usr/obj/... tree To: Matthias Apitz , Warner Losh , freebsd-current@freebsd.org Content-Type: multipart/alternative; boundary="0000000000003a8e58060243644f" X-Rspamd-Queue-Id: 4RJkx61JrKz3YdJ X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] --0000000000003a8e58060243644f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Aug 6, 2023 at 10:05=E2=80=AFAM Matthias Apitz w= rote: > El d=C3=ADa domingo, agosto 06, 2023 a las 09:58:32a. m. -0600, Warner Lo= sh > escribi=C3=B3: > > > On Sun, Aug 6, 2023 at 7:58=E2=80=AFAM Matthias Apitz wrote: > > > > > > > > I did, based of a git clone of head, a clean compile of world and > kernel > > > with > > > > > > # cd /usr > > > # rm -rf obj > > > # mkdir obj > > > # cd src > > > # make -j8 buildworld > > > # make -j8 buildkernel > > > ... > > > I installed the result and the system runs fine. For some test I want= ed > > > to do another installation to some DESTDIR with > > > > > > # make installworld DESTDIR=3D/home/... > > > > > > This failed with: > > > > > > --- installworld --- > > > mkdir -p /tmp/install.j76anzU56j > > > > > > ... > > > Required library libdialog.so.8 not found. > > > *** [installworld] Error code 1 > > > > > > make[1]: stopped in /usr/src > > > > > > Investigating the problem it turned out that the 'make buildworld' pu= ts > > > a lot of legacy binaries in to some directory: > > > > > > # ls -l /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin > > > total 36976 > > > -r-xr-xr-x 1 root wheel 13304 Nov 30 2020 [ > > > lrwxr-xr-x 1 root wheel 54 Aug 5 13:05 apropos -> > > > /usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin/mandoc > > > -rwxr-xr-x 1 root wheel 1008512 Aug 5 13:05 asn1_compile > > > -r-xr-xr-x 1 root wheel 217504 Nov 30 2020 awk > > > -r-xr-xr-x 1 root wheel 9576 Nov 30 2020 basename > > > -r-xr-xr-x 1 root wheel 195712 Nov 30 2020 bmake > > > -r-xr-xr-x 1 root wheel 33848 Nov 30 2020 bunzip2 > > > ... > > > They are all from the system before updating it (from Nov 30 2020) an= d > > > of course are missing shared libs when they get called in the actual > > > system, for example > > > > > > # ldd /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin/tzsetup > > > /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin/tzsetup: > > > libdialog.so.8 =3D> not found (0) > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > libncursesw.so.9 =3D> /lib/libncursesw.so.9 (0xf283d7b4000) > > > libc.so.7 =3D> /lib/libc.so.7 (0xf283e729000) > > > libtinfow.so.9 =3D> /lib/libtinfow.so.9 (0xf283c93d000) > > > [vdso] (0xf283c4a4000) > > > > > > # which tzsetup > > > /usr/sbin/tzsetup > > > # ldd /usr/sbin/tzsetup > > > /usr/sbin/tzsetup: > > > libprivatebsddialog.so.0 =3D> /usr/lib/libprivatebsddialog.so= .0 > > > (0x1797fe45c000) > > > libc.so.7 =3D> /lib/libc.so.7 (0x1797fec89000) > > > libncursesw.so.9 =3D> /lib/libncursesw.so.9 (0x1798011df000) > > > libtinfow.so.9 =3D> /lib/libtinfow.so.9 (0x17980043d000) > > > libformw.so.6 =3D> /usr/lib/libformw.so.6 (0x17980164c000) > > > [vdso] (0x1797fe2d9000) > > > > > > Why is this with the tools in > /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin ? > > > Or what I have done wrong or overlooked? > > > > > > > So, the build process builds tools that are used to make and install > > FreeBSD. > > That's what legacy is about: providing a compatible way to do all this. > We > > setup env vars, etc, so that these tools pull their libraries from lega= cy > > as well > > so that we have a consistent set of binaries to run on while the rest o= f > > the world > > is being replaced. I'm surprised to see this failing, since it's what > > nanobsd does > > all the time, and I build new systems with nanobsd every week based on > > recent > > current trees. > > > > Is there a libdalog.so.8 in your tmp/legacy tree at all? > > No, there is not: > > root@jet:~ # find /usr/obj.broken -name libdalog.so.8 > root@jet:~ # > > The problem, for sure, is not when you build every day, but in my case > the last build (and the system used for building) was 2 years old. And > note: > I started with an empty new /usr/obj. > So what's the vintage of the host you are building with? And what sources are you building... Also of note: we switched to no-clean builds by default which is way faster, but also exposes issues like this... Warner --0000000000003a8e58060243644f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Aug 6, 2023 at 10:05=E2=80=AF= AM Matthias Apitz <guru@unixarea.de<= /a>> wrote:
E= l d=C3=ADa domingo, agosto 06, 2023 a las 09:58:32a. m. -0600, Warner Losh = escribi=C3=B3:

> On Sun, Aug 6, 2023 at 7:58=E2=80=AFAM Matthias Apitz <guru@unixarea.de> wrote: >
> >
> > I did, based of a git clone of head, a clean compile of world and= kernel
> > with
> >
> > # cd /usr
> > # rm -rf obj
> > # mkdir obj
> > # cd src
> > # make -j8 buildworld
> > # make -j8 buildkernel
> > ...
> > I installed the result and the system runs fine. For some test I = wanted
> > to do another installation to some DESTDIR with
> >
> > # make installworld DESTDIR=3D/home/...
> >
> > This failed with:
> >
> > --- installworld ---
> > mkdir -p /tmp/install.j76anzU56j
> >
> > ...
> > Required library libdialog.so.8 not found.
> > *** [installworld] Error code 1
> >
> > make[1]: stopped in /usr/src
> >
> > Investigating the problem it turned out that the 'make buildw= orld' puts
> > a lot of legacy binaries in to some directory:
> >
> > # ls -l /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin
> > total 36976
> > -r-xr-xr-x=C2=A0 1 root wheel=C2=A0 =C2=A013304 Nov 30=C2=A0 2020= [
> > lrwxr-xr-x=C2=A0 1 root wheel=C2=A0 =C2=A0 =C2=A0 54 Aug=C2=A0 5 = 13:05 apropos ->
> > /usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin/mandoc
> > -rwxr-xr-x=C2=A0 1 root wheel 1008512 Aug=C2=A0 5 13:05 asn1_comp= ile
> > -r-xr-xr-x=C2=A0 1 root wheel=C2=A0 217504 Nov 30=C2=A0 2020 awk<= br> > > -r-xr-xr-x=C2=A0 1 root wheel=C2=A0 =C2=A0 9576 Nov 30=C2=A0 2020= basename
> > -r-xr-xr-x=C2=A0 1 root wheel=C2=A0 195712 Nov 30=C2=A0 2020 bmak= e
> > -r-xr-xr-x=C2=A0 1 root wheel=C2=A0 =C2=A033848 Nov 30=C2=A0 2020= bunzip2
> > ...
> > They are all from the system before updating it (from Nov 30 2020= ) and
> > of course are missing shared libs when they get called in the act= ual
> > system, for example
> >
> > # ldd /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin/tzsetup
> > /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin/tzsetup:
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0libdialog.so.8 =3D> not found= (0)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0libncursesw.so.9 =3D> /lib/li= bncursesw.so.9 (0xf283d7b4000)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0libc.so.7 =3D> /lib/libc.so.7= (0xf283e729000)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0libtinfow.so.9 =3D> /lib/libt= infow.so.9 (0xf283c93d000)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[vdso] (0xf283c4a4000)
> >
> > # which tzsetup
> > /usr/sbin/tzsetup
> > # ldd /usr/sbin/tzsetup
> > /usr/sbin/tzsetup:
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0libprivatebsddialog.so.0 =3D>= /usr/lib/libprivatebsddialog.so.0
> > (0x1797fe45c000)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0libc.so.7 =3D> /lib/libc.so.7= (0x1797fec89000)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0libncursesw.so.9 =3D> /lib/li= bncursesw.so.9 (0x1798011df000)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0libtinfow.so.9 =3D> /lib/libt= infow.so.9 (0x17980043d000)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0libformw.so.6 =3D> /usr/lib/l= ibformw.so.6 (0x17980164c000)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[vdso] (0x1797fe2d9000)
> >
> > Why is this with the tools in /usr/obj/usr/src/amd64.amd64/tmp/le= gacy/bin ?
> > Or what I have done wrong or overlooked?
> >
>
> So, the build process builds tools that are used to make and install > FreeBSD.
> That's what legacy is about: providing a compatible way to do all = this. We
> setup env vars, etc, so that these tools pull their libraries from leg= acy
> as well
> so that we have a consistent set of binaries to run on while the rest = of
> the world
> is being replaced. I'm surprised to see this failing, since it'= ;s what
> nanobsd does
> all the time, and I build new systems with nanobsd every week based on=
> recent
> current trees.
>
> Is there a libdalog.so.8 in your tmp/legacy tree at all?

No, there is not:

root@jet:~ # find /usr/obj.broken -name libdalog.so.8
root@jet:~ #

The problem, for sure, is not when you build every day, but in my case
the last build (and the system used for building) was 2 years old. And note= :
I started with an empty new /usr/obj.

S= o what's the vintage of the host you are building with? And what source= s are
you building...

Also of note: we s= witched to no-clean builds by default which is way faster, but
al= so exposes issues like this...

Warner
--0000000000003a8e58060243644f-- From nobody Sun Aug 6 16:21:40 2023 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 4RJl881KSzz4m3Pt for ; Sun, 6 Aug 2023 16:21:44 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (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 4RJl874tZ9z3bbB for ; Sun, 6 Aug 2023 16:21:43 +0000 (UTC) (envelope-from guru@unixarea.de) Authentication-Results: mx1.freebsd.org; none Received: from [188.174.52.107] (helo=localhost.unixarea.de) by ms-10.1blu.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qSgVi-0003bd-4r; Sun, 06 Aug 2023 18:21:42 +0200 Received: from localhost.my.domain (localhost [127.0.0.1]) by localhost.unixarea.de (8.16.1/8.14.9) with ESMTPS id 376GLetC045796 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 6 Aug 2023 18:21:41 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.16.1/8.14.9/Submit) id 376GLeOJ045795; Sun, 6 Aug 2023 18:21:40 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Sun, 6 Aug 2023 18:21:40 +0200 From: Matthias Apitz To: Warner Losh Cc: freebsd-current@freebsd.org Subject: Re: make buildworld puts legacy tools into the /usr/obj/... tree Message-ID: Reply-To: Matthias Apitz Mail-Followup-To: Warner Losh , freebsd-current@freebsd.org 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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: FreeBSD 13.0-CURRENT r368166 (amd64) X-message-flag: Mails containing HTML will not be read! Please send only plain text. X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 188.174.52.107 X-Rspamd-Queue-Id: 4RJl874tZ9z3bbB X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:42730, ipnet:178.254.0.0/19, country:DE] El día domingo, agosto 06, 2023 a las 10:12:03a. m. -0600, Warner Losh escribió: > So what's the vintage of the host you are building with? And what sources > are > you building... The vintage was (now updated): 13.0-CURRENT 1300130 r368164 and /usr/src was git cloned from yesterday's head. matthias -- Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub From nobody Sun Aug 6 16:22:43 2023 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 4RJl9S6v2Kz4m3wW for ; Sun, 6 Aug 2023 16:22:52 +0000 (UTC) (envelope-from grembo@freebsd.org) Received: from mail.evolve.de (mail.evolve.de [213.239.217.29]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail.evolve.de", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RJl9S3DYMz3cpv for ; Sun, 6 Aug 2023 16:22:52 +0000 (UTC) (envelope-from grembo@freebsd.org) Authentication-Results: mx1.freebsd.org; none Received: by mail.evolve.de (OpenSMTPD) with ESMTP id aead8be1; Sun, 6 Aug 2023 16:22:44 +0000 (UTC) Received: by mail.evolve.de (OpenSMTPD) with ESMTPSA id 15bde8a8 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Sun, 6 Aug 2023 16:22:44 +0000 (UTC) Content-Type: multipart/alternative; boundary=Apple-Mail-BE6BFDC8-DAA4-4C10-B1AD-29A2BF543C85 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 (1.0) Subject: Re: make buildworld puts legacy tools into the /usr/obj/... tree From: Michael Gmelin In-Reply-To: Date: Sun, 6 Aug 2023 18:22:43 +0200 Cc: Matthias Apitz , freebsd-current@freebsd.org Message-Id: References: To: Warner Losh X-Mailer: iPhone Mail (20F75) X-Rspamd-Queue-Id: 4RJl9S3DYMz3cpv X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:24940, ipnet:213.239.192.0/18, country:DE] --Apple-Mail-BE6BFDC8-DAA4-4C10-B1AD-29A2BF543C85 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On 6. Aug 2023, at 18:12, Warner Losh <imp@bsdimp.com> wrote:

=
=EF=BB=BF


On Sun, Aug 6, 2023 at 10:05=E2=80=AFAM Matth= ias Apitz <guru@unixarea.de> w= rote:
El d=C3=ADa d= omingo, agosto 06, 2023 a las 09:58:32a. m. -0600, Warner Losh escribi=C3=B3= :

> On Sun, Aug 6, 2023 at 7:58=E2=80=AFAM Matthias Apitz <guru@unixarea.de> wrote:
= >
> >
> > I did, based of a git clone of head, a clean compile of world and k= ernel
> > with
> >
> > # cd /usr
> > # rm -rf obj
> > # mkdir obj
> > # cd src
> > # make -j8 buildworld
> > # make -j8 buildkernel
> > ...
> > I installed the result and the system runs fine. For some test I w= anted
> > to do another installation to some DESTDIR with
> >
> > # make installworld DESTDIR=3D/home/...
> >
> > This failed with:
> >
> > --- installworld ---
> > mkdir -p /tmp/install.j76anzU56j
> >
> > ...
> > Required library libdialog.so.8 not found.
> > *** [installworld] Error code 1
> >
> > make[1]: stopped in /usr/src
> >
> > Investigating the problem it turned out that the 'make buildworld'= puts
> > a lot of legacy binaries in to some directory:
> >
> > # ls -l /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin
> > total 36976
> > -r-xr-xr-x  1 root wheel   13304 Nov 30  2020 [=
> > lrwxr-xr-x  1 root wheel      54 Aug  5 1= 3:05 apropos ->
> > /usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin/mandoc
> > -rwxr-xr-x  1 root wheel 1008512 Aug  5 13:05 asn1_compi= le
> > -r-xr-xr-x  1 root wheel  217504 Nov 30  2020 awk > > -r-xr-xr-x  1 root wheel    9576 Nov 30  2020 b= asename
> > -r-xr-xr-x  1 root wheel  195712 Nov 30  2020 bmake=
> > -r-xr-xr-x  1 root wheel   33848 Nov 30  2020 b= unzip2
> > ...
> > They are all from the system before updating it (from Nov 30 2020)= and
> > of course are missing shared libs when they get called in the actu= al
> > system, for example
> >
> > # ldd /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin/tzsetup
> > /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin/tzsetup:
> >         libdialog.so.8 =3D> not found (= 0)
> >         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >         libncursesw.so.9 =3D> /lib/lib= ncursesw.so.9 (0xf283d7b4000)
> >         libc.so.7 =3D> /lib/libc.so.7 (= 0xf283e729000)
> >         libtinfow.so.9 =3D> /lib/libti= nfow.so.9 (0xf283c93d000)
> >         [vdso] (0xf283c4a4000)
> >
> > # which tzsetup
> > /usr/sbin/tzsetup
> > # ldd /usr/sbin/tzsetup
> > /usr/sbin/tzsetup:
> >         libprivatebsddialog.so.0 =3D> /= usr/lib/libprivatebsddialog.so.0
> > (0x1797fe45c000)
> >         libc.so.7 =3D> /lib/libc.so.7 (= 0x1797fec89000)
> >         libncursesw.so.9 =3D> /lib/lib= ncursesw.so.9 (0x1798011df000)
> >         libtinfow.so.9 =3D> /lib/libti= nfow.so.9 (0x17980043d000)
> >         libformw.so.6 =3D> /usr/lib/li= bformw.so.6 (0x17980164c000)
> >         [vdso] (0x1797fe2d9000)
> >
> > Why is this with the tools in /usr/obj/usr/src/amd64.amd64/tmp/leg= acy/bin ?
> > Or what I have done wrong or overlooked?
> >
>
> So, the build process builds tools that are used to make and install > FreeBSD.
> That's what legacy is about: providing a compatible way to do all this.= We
> setup env vars, etc, so that these tools pull their libraries from lega= cy
> as well
> so that we have a consistent set of binaries to run on while the rest o= f
> the world
> is being replaced. I'm surprised to see this failing, since it's what > nanobsd does
> all the time, and I build new systems with nanobsd every week based on<= br> > recent
> current trees.
>
> Is there a libdalog.so.8 in your tmp/legacy tree at all?

No, there is not:

root@jet:~ # find /usr/obj.broken -name libdalog.so.8
root@jet:~ #

The problem, for sure, is not when you build every day, but in my case
the last build (and the system used for building) was 2 years old. And note:=
I started with an empty new /usr/obj.

So= what's the vintage of the host you are building with? And what sources are<= /div>
you building...

Also of note: we switched= to no-clean builds by default which is way faster, but
also expos= es issues like this...

Thanks, this is valuable information (starts ada= pting idempotent playbooks).

-m
= --Apple-Mail-BE6BFDC8-DAA4-4C10-B1AD-29A2BF543C85-- From nobody Sun Aug 6 16:23:55 2023 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 4RJlBj1tY9z4m44T for ; Sun, 6 Aug 2023 16:23:57 +0000 (UTC) (envelope-from grahamperrin@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 4RJlBj15tDz3dmv for ; Sun, 6 Aug 2023 16:23:57 +0000 (UTC) (envelope-from grahamperrin@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1691339037; 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=INRPzX0EKsIbeJx4pIjqzi+jfilrR9SNk5AVZp29jYs=; b=e9U7rZHhYiaMRhJ3oU51t5+WgDkfTt3VGbynpFS55J+1LQvjLhhCeGEMVxjE53xBfH7uvd KuKVKAuyOdyjwY9gb8bFmD5M19Y4/OfL0QunRC9LVrazVARdIaQcAOJLT4JZLcJg8sii4f z6cpDyX5GFmlS4lz6FUAW3MfxbWt5IxPIza+GKkosSdgfSZ8hlCTOB983cSdr5dyQttrpJ 6TLLPPSXaLtpRV41zZyCA5BSJwMPc24/POrbbZhoS8ItfbnQe4C/QJE59hgN53oujS0hyK FAj48TqZUoKPZ4bmgH3iodc6px0S/BHjIgHLW6UELZInEFPtF2B0xxZIwBg42A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1691339037; 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=INRPzX0EKsIbeJx4pIjqzi+jfilrR9SNk5AVZp29jYs=; b=IpEylg56YK4kRQnkhnw/gvBVO5kO++b2yFPTiSHqX+x3FueWtCHPJj9v2yUoLq0cB2Qfik dI4oNgj0nFJP05glurFHXJOMeh5SGfvotzvzVv94xZJVWcYeo/Q1d8kQMmtMJ1Gm41RoWk 1Jq+ocv/uCW3ZSz66sHIyubMHdESvg+Ehiv/tpJhR62sf8h/Wc3K0TdOYSjjXe2j5EQ2Oc +qAvGXeKAhSvEqeZzkNDoFnH81PZle2QKCxcymu6YD4QwZ4v15IYKdk8VFwSJpo4kQFAFQ UHiOPjqamOnRZdhA435kGrZ8ucLK1T4+4LQYnU8EqWZXrZ5IpPy7yXB4HfpyRQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1691339037; a=rsa-sha256; cv=none; b=u8gMnxt5Ku4JABgIDC9HoI/SAga64CKTDrRd5doI+MUrQKJElmiLCRCcAL14JI6WzwII30 ntLKyAxYTmRnGn204+oH7aqwydshECr5tRAYNhtNxfC9+MQsbucpVg2yJgdEbyubrO1b6y 1q7EmURLGSGBE61qC4S3Nch9RLdGsWDc6FkO7pC6in7yHBkZ9uUUxa7Beh8Ajyd+yRzmZx vzFnWxepOgVwjs2AR1O+v67DAI0YEOYNltqHiq79eOVCiXzIkcXo8Mm/T7Ult0zWbvtaml GWgBfQH6OVSzXVktuP4W1roQ5P9a4k6IC0SVYeSic7rNMkxQKTA3at8qpz8G0Q== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from [192.168.1.10] (80-42-66-93.dynamic.dsl.as9105.com [80.42.66.93]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) (Authenticated sender: grahamperrin) by smtp.freebsd.org (Postfix) with ESMTPSA id 4RJlBh5zsJzl2K for ; Sun, 6 Aug 2023 16:23:56 +0000 (UTC) (envelope-from grahamperrin@freebsd.org) Message-ID: Date: Sun, 6 Aug 2023 17:23: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 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.13.1 Subject: service routing restart, service dhclient restart (was: Unreliability with DHCP) Content-Language: en-US To: freebsd-current@freebsd.org References: <62d300c8-2c3e-58fa-334e-23a17962279a@freebsd.org> <753f3990-9903-3718-445c-49fc01f960a7@freebsd.org> <354756c9-29e0-db1f-269e-3c219b5d9ac8@freebsd.org> From: Graham Perrin Organization: FreeBSD In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Thanks, On 06/08/2023 08:36, Oleksandr Kryvulia wrote: > … In my case default route is assigned by dhclient, so 'service > routing restart' must be run quickly after 'service netif restart' - > before we receive dhcp offer. Is this documented and explained somewhere, or did you learn through trial and error? > Another option is to run 'service dhclient restart wlan0' after > routing restart. … Is there, similarly, a need to rush the two commands? no route; /etc/rc.d/dhclient: WARNING: failed to start dhclient From nobody Sun Aug 6 16:51:11 2023 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 4RJlpP11vmz4m5l7 for ; Sun, 6 Aug 2023 16:51:25 +0000 (UTC) (envelope-from smsdtv@gmail.com) Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (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 4RJlpN2n9nz4DPG for ; Sun, 6 Aug 2023 16:51:24 +0000 (UTC) (envelope-from smsdtv@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ot1-x32f.google.com with SMTP id 46e09a7af769-6bcd4b5ebbaso1954593a34.1 for ; Sun, 06 Aug 2023 09:51:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691340683; x=1691945483; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc:subject:date:message-id :reply-to; bh=xTD0R+eoqKObBNCE2EEs4dyAzHJ0aUI1cJANSDoMppo=; b=iuC1tHQkSyTuI1ELXvSQXpxe73hapKT205PkbPEnu+qeoThRx7SYndeebAnGmBFkF1 svRJs5KNCOFXPl5cRI41SMsbeKuyromXO/oFaOc0loh7gFVcHBzYUbaOYV5nwo2zFKBT Mhw7owZptUkk1M8eF8Mc8Q2pm7xN3pCMnAcYIA2zbHzygScQ/mrkLeh0dhfA3fOMgeoj 02cRjja/ee5JSK4uqZG49pfRFPOvHH+q+m3sjp3KjhgTT9OZqpoUycWFbWssbHwGswxN wFZUUc3UzvN2CeKfLhqUjGrHH3B/H11aoEHqWvKm3q7BVxc/iNukax1Wktt1+DfKryTr iQ0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691340683; x=1691945483; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=xTD0R+eoqKObBNCE2EEs4dyAzHJ0aUI1cJANSDoMppo=; b=DU9Tc1UCdShuKYMox74pBvLtXHpfK7LukqgTcsjI9Nq931DIaLxse8mfmqpLiHuXAY DPQ8HdgH1n3vbfgmkteQQmAG+JoEBHe90ZSfbFb6ZzsbCBatQ/0xIvMGN65h9x8I9QwP SRN1DZrVF8ce/y89YXvlcuHGDn2A3PwUdfGrb8tm9GMQ5sMYkqZKhKJ21YvBK81QZXf6 C+ZK2ArxVThU/OZ+t8FTTq4hZSigog53sHolKCDH48nK1lW51CeMb0F1Z1v0kE7SM3HX DyaMk5mxIPb2pyhn5QwvC9GW2+kaRRRGmzXMezpO0sbkysIbMvsqfSvz4U2u6FK3j4zb CPjQ== X-Gm-Message-State: AOJu0Yz3rXmEQ2dgTqs4EZngH+zMZEPxgf/jQi7Kmc/1cMZl0oeeWauG +uCCCJK5icQDBUa29iO+UPW/tQNJrMY= X-Google-Smtp-Source: AGHT+IGBWHoFRK54rrqUdKD9CG1+mldeTfugcVPest0/i5iNInh5v6iHERFeCG771TTIsd9gUvIEww== X-Received: by 2002:a05:6870:1d3:b0:1bb:4bad:ebce with SMTP id n19-20020a05687001d300b001bb4badebcemr7782631oad.27.1691340683146; Sun, 06 Aug 2023 09:51:23 -0700 (PDT) Received: from smtpclient.apple (50-36-34-84.drr01.mybh.sc.frontiernet.net. [50.36.34.84]) by smtp.gmail.com with ESMTPSA id zv2-20020a0568714f8200b0019f188355a8sm4084478oab.17.2023.08.06.09.51.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 06 Aug 2023 09:51:22 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-C850A5FF-CDB1-42D5-A383-5B1AD2F929A4 Content-Transfer-Encoding: 7bit From: Tim Kellers 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: Has the update procedure changed? Date: Sun, 6 Aug 2023 12:51:11 -0400 Message-Id: <7A0E604D-EF40-4F10-B597-F1F076507192@gmail.com> References: Cc: Matthias Apitz , freebsd-current@freebsd.org In-Reply-To: To: Kevin Oberman X-Mailer: iPhone Mail (20G75) X-Rspamd-Queue-Id: 4RJlpN2n9nz4DPG X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] --Apple-Mail-C850A5FF-CDB1-42D5-A383-5B1AD2F929A4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On Aug 6, 2023, at 11:= 05 AM, Kevin Oberman <rkoberman@gmail.com> wrote:

=
=EF=BB=BF
<= div dir=3D"ltr">
On Sat, Aug 5, 2023 at 10:51=E2=80=AFPM Matthias Ap= itz <guru@unixarea.de> wrote:<= /div>
In the past I was used to use the following procedure to install a= new
kernel and world:

    # cd /usr/src
    # make installkernel
    # shutdown -r now

    boot -s from the loader prompt

    # adjkerntz -i
    # mount -a -t ufs
    # mergemaster -p
    # cd /usr/src
    # make installworld
    # mergemaster
    # yes | make delete-old
    # yes | make delete-old-libs

    # reboot

Now the handbook https://docs.freebs= d.org/en/books/handbook/cutting-edge/#makeworld
says only:

    # cd /usr/src
    # make installkernel
    # shutdown -r now
    # cd /usr/src
    # make installworld
    # shutdown -r now

Has this changed in past two years?

Thanks

        matthias
--
Matthias Apitz, =E2=9C=89 guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
 
Wow! Several obvious reasons that this looks ju= st wrong. (Then again, so is yours in one case.)
1. "mergemast= er -p" MUST be run before you build the kernel. (Actually, hte man page says= it should be run BEFORE buildworld and that is what I've always done althou= gh I have never seen a case where it was needed until buildkernel.
2. While mergemaster(8) is still in the system, you really should be us= ing etcupdate(8). You also need to understand how a three-way merge is done a= nd that you  often need to edit the merged file when first running it.&= nbsp; It's pretty simple to run and rarely is needed after the first run, bu= t it is critical to do this for /etc files that you have modified. It's gene= rally just picking which of the two (original/yours) you want in the final f= ile. The big win with etcupdate(8) is that it only needs to be run once for m= odified files in almost all cases.
3. Where is "make check-old= " and the other tests to get rid of old files. Leaving these around can lead= to serious issues.
4. If you don't do adjkerntz -i, you might= find files installed in the future which can get REALLY  confusing!

Historically, the final source of truth f= or all of this is /usr/src/UPDATING. It has been updated for etcupdate(8) an= d is handled by imp@, so I tend to believe it is correct.

=
OK. Everyone who knows better, please explain why. I didn't m= ention "fsck -p" but I'm really paranoid and it really, really should not be= needed unless something goes wrong in the shutdown after installing the new= kernel.
--
=
Kevin Oberman, Part time kid her= der and retired Network Engineer
E-mail: rkoberman@gmail.com
PGP Fingerpri= nt: D03FB98AFA78E3B78C1694B318AB39EF1B055683

I=E2=80=99ve always used the procedure listed at= line 90 of the Makefile in /usr/src as the source of truth. Has that change= d?

Tim
= --Apple-Mail-C850A5FF-CDB1-42D5-A383-5B1AD2F929A4-- From nobody Mon Aug 7 02:50:55 2023 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 4RK16d4JtDz4ptF8 for ; Mon, 7 Aug 2023 02:51:21 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: from hsmtpd-fgn.xspmail.jp (hsmtpd-fgn.xspmail.jp [210.130.137.13]) (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 4RK16Z22bzz4Grs for ; Mon, 7 Aug 2023 02:51:17 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=j.email.ne.jp header.s=x01 header.b=g5casqnL; spf=pass (mx1.freebsd.org: domain of ota@j.email.ne.jp designates 210.130.137.13 as permitted sender) smtp.mailfrom=ota@j.email.ne.jp; dmarc=pass (policy=none) header.from=j.email.ne.jp DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1691376667; d=j.email.ne.jp; s=x01; i=ota@j.email.ne.jp; h=content-transfer-encoding:content-type:mime-version:message-id:subject:to: from:date:from; bh=cD2fjl/XzfmPxGxARN6+65hTky3R38Yj1uZ4iBzdvhA=; b=g5casqnLTALT0DZT1nJxEuC3nj9Q6Ibx4nadrR145OhWwtgW6/TZRRUTc15Y10lgwZrJpRNa4dpQq E0DvA9n7Bn+r1O/5ELYcCmVp2NktFp8nYa5pHBHRcPJcmE+R6H4d1ZJ5LJ665GOUCxy86ThCgBAJbp OCoD+v3jKAr7hMeSdwENSQ7cKzOtx1ocGPP5TQs2Q+33+HNcismqN2rQW8OmxCC9Sep7xr/cdcgXLc CyHL8nmUmdRDry3piFxi+mzC3EBgdmmiwGxyDGD35mVYgCRdxFEec+9Dy5QqcxSZTgZuaE696vj04q ZUKl4vei0NcjW3652xUeZ66x8T4S84Q== X-Country-Code: US Received: from a315-53 (unknown [38.98.216.75]) by hsmtpd-out-1.asahinet.cluster.xspmail.jp (Halon) with ESMTPA id d1ff0949-37e5-43d0-b06e-661bf71b11ec; Mon, 07 Aug 2023 11:51:07 +0900 (JST) Date: Sun, 6 Aug 2023 22:50:55 -0400 From: Yoshihiro Ota To: freebsd-current@freebsd.org Subject: Jail compile error on CURRENT? Message-Id: <20230806225055.bbccc4fc13e41f50ec524621@j.email.ne.jp> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd12.2) 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-Spamd-Result: default: False [-2.49 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.994]; DMARC_POLICY_ALLOW(-0.50)[j.email.ne.jp,none]; MV_CASE(0.50)[]; R_DKIM_ALLOW(-0.20)[j.email.ne.jp:s=x01]; R_SPF_ALLOW(-0.20)[+ip4:210.130.137.0/27]; MIME_GOOD(-0.10)[text/plain]; RCVD_COUNT_ONE(0.00)[1]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:2497, ipnet:210.130.0.0/16, country:JP]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[j.email.ne.jp:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_NONE(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-Spamd-Bar: -- X-Rspamd-Queue-Id: 4RK16Z22bzz4Grs Hi, Am I the only one seeing this error? I'm on 12.4-RELEASE amd64 and building CURRENT as of now. jaillex.c:2228:43: error: unused parameter 'yyscanner' [-Werror,-Wunused-parameter] void *yyalloc (yy_size_t size , yyscan_t yyscanner) ^ jaillex.c:2233:58: error: unused parameter 'yyscanner' [-Werror,-Wunused-parameter] void *yyrealloc (void * ptr, yy_size_t size , yyscan_t yyscanner) ^ jaillex.c:2245:36: error: unused parameter 'yyscanner' [-Werror,-Wunused-parameter] void yyfree (void * ptr , yyscan_t yyscanner) ^ 6 errors generated. *** [jaillex.o] Error code 1 From nobody Mon Aug 7 10:28:11 2023 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 4RKCFy1Mktz4mLty for ; Mon, 7 Aug 2023 10:28:22 +0000 (UTC) (envelope-from shuriku@shurik.kiev.ua) Received: from mail.flex-it.com.ua (mail.flex-it.com.ua [193.239.74.7]) (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 4RKCFw6LJyz3PtM for ; Mon, 7 Aug 2023 10:28:20 +0000 (UTC) (envelope-from shuriku@shurik.kiev.ua) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of shuriku@shurik.kiev.ua designates 193.239.74.7 as permitted sender) smtp.mailfrom=shuriku@shurik.kiev.ua; dmarc=none Received: from 93.183.208.50.ipv4.datagroup.ua ([93.183.208.50] helo=[192.168.200.125]) by mail.flex-it.com.ua with esmtpsa (TLS1.3) tls TLS_AES_128_GCM_SHA256 (Exim 4.96 (FreeBSD)) (envelope-from ) id 1qSxT9-000ByG-1l for freebsd-current@freebsd.org; Mon, 07 Aug 2023 13:28:11 +0300 Message-ID: <06344516-ceb3-4aea-dcdb-720a19dd6e45@shurik.kiev.ua> Date: Mon, 7 Aug 2023 13:28:11 +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:102.0) Gecko/20100101 Thunderbird/102.13.1 Subject: Re: service routing restart, service dhclient restart (was: Unreliability with DHCP) Content-Language: uk-UA To: freebsd-current@freebsd.org References: <62d300c8-2c3e-58fa-334e-23a17962279a@freebsd.org> <753f3990-9903-3718-445c-49fc01f960a7@freebsd.org> <354756c9-29e0-db1f-269e-3c219b5d9ac8@freebsd.org> From: Oleksandr Kryvulia In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ACL-Warn: SPF failed. 93.183.208.50 is not allowed to send mail from shurik.kiev.ua. X-Spamd-Result: default: False [-1.28 / 15.00]; NEURAL_SPAM_LONG(1.00)[0.998]; NEURAL_HAM_MEDIUM(-1.00)[-0.996]; NEURAL_HAM_SHORT(-0.98)[-0.979]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:35297, ipnet:193.239.72.0/22, country:UA]; MIME_TRACE(0.00)[0:+]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[shurik.kiev.ua]; ARC_NA(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_NONE(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-Spamd-Bar: - X-Rspamd-Queue-Id: 4RKCFw6LJyz3PtM 06.08.23 19:23, Graham Perrin пише: > Thanks, > > On 06/08/2023 08:36, Oleksandr Kryvulia wrote: >> … In my case default route is assigned by dhclient, so 'service >> routing restart' must be run quickly after 'service netif restart' - >> before we receive dhcp offer. > > Is this documented and explained somewhere, or did you learn through > trial and error? It's my own expirience  + reading /etc/rc.d/routing > > >> Another option is to run 'service dhclient restart wlan0' after >> routing restart. … > > Is there, similarly, a need to rush the two commands? I can't answer for sure, you need to try different options and choose the one that works. If you're using typical network configuration, you'll probably be fine with routing restart + dhclient restart only. This works for me in most cases until I configured lagg interface. > > no route; > /etc/rc.d/dhclient: WARNING: > failed to start dhclient > > From nobody Mon Aug 7 15:39:31 2023 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 4RKL962Qjlz4TmX6 for ; Mon, 7 Aug 2023 15:39:38 +0000 (UTC) (envelope-from void@f-m.fm) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (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 4RKL953K72z4WXJ for ; Mon, 7 Aug 2023 15:39:37 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm3 header.b=WMBKdbrd; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=ltsN+hgg; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 64.147.123.20 as permitted sender) smtp.mailfrom=void@f-m.fm; dmarc=pass (policy=none) header.from=f-m.fm Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 180B73200930; Mon, 7 Aug 2023 11:39:35 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Mon, 07 Aug 2023 11:39:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc:cc :content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm3; t=1691422774; x=1691509174; bh=+W ExJIGOfRR8zxRNp50sDg7EGzAG5f6gAN5Eq23p+u4=; b=WMBKdbrde6RcvKV7Fr /pUPImuULZQ8fl7rE2gxMTyrH6BfMeFj2A8M9DLmExIca7BLc+/MfSeNNhJExHv8 T2/0jQAUL3QKkkBr2XeKzf+3aspdhqBq6Zt4+PlA0ABgTJEMWxiykpHlUYgjKrJh 3mgZBlsVXCqoWh8jm/5hRstCa2Fhq2ZiVMPkxqWsaCdmNjohb7m+QUdqM4QaPEzi us5lB5VnRh0AKPRAv2Pu/znySHwlGaRxTwg814gD30fHDN/2B6ZM7yBIdrKTPLSY 1XiDwnXpk24pNL7ghyPj2LEL83/OH4LKBZuPCXqmJupc1XeyAnjH+HHIICdo3/61 eQCQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; t=1691422774; x=1691509174; bh=+WExJIGOfRR8z xRNp50sDg7EGzAG5f6gAN5Eq23p+u4=; b=ltsN+hggLneJ1L+dQXJdz5FNal5bj 2ZgS0fyesb3i4+3TtV4/eqYPppf+Ydt/Hx6+RijrYOhd+hed3dz6k7UYv/dndgU9 DdD8HGra1uIP3kM08YXk8Y0aW9cQ4UWX1vm/r+kNtKeKrV9RHhPYQMS3DJHSJXRb wM8cFs4SiGRftEVR+8W6aM27eotWUSEibCWWx/Z69XM1SiYWLD2ai+4tjvLYLCKf qLXNSXOz/kqii0hOSd2jY5UaIRskYYNXEIltfPFhem0Raqoqg/oxcCavSp2S6B9M 5qg6cBv/iwxBweQ7ufNqeG5RxoIHmDXmYSlKNe2gqkJh5Vi4PQYO5lJsw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrledtgdekhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffhvfevuffkfhggtggujgesthdtre dttddtvdenucfhrhhomhepvhhoihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgr thhtvghrnhepgefghefhjeejkeetueefheefhfegjefgleeivdehvdfffffhgfeitddvtd fgheeunecuffhomhgrihhnpehfrhgvvggsshgurdhorhhgnecuvehluhhsthgvrhfuihii vgeptdenucfrrghrrghmpehmrghilhhfrhhomhepvhhoihgusehfqdhmrdhfmh X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 7 Aug 2023 11:39:33 -0400 (EDT) Date: Mon, 7 Aug 2023 16:39:31 +0100 From: void To: freebsd-current@freebsd.org Cc: Michael Grimm Subject: Re: poudriere && git Message-ID: Mail-Followup-To: freebsd-current@freebsd.org, Michael Grimm References: <20230805080811.GA11506@home.opsec.eu> <78387A8F-1F30-4BA6-97A4-8E2DDC827008@ellael.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; format=flowed Content-Disposition: inline In-Reply-To: X-Spamd-Result: default: False [-4.98 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.98)[-0.976]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; MID_RHS_NOT_FQDN(0.50)[]; RWL_MAILSPIKE_EXCELLENT(-0.40)[64.147.123.20:from]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm3,messagingengine.com:s=fm3]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.20]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.20:from]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[f-m.fm]; TO_DN_SOME(0.00)[]; ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; RCVD_VIA_SMTP_AUTH(0.00)[] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4RKL953K72z4WXJ On Sun, Aug 06, 2023 at 04:11:00PM +0200, Matthias Apitz wrote: >I'm now already running a new "make buildworld" again, which perhaps will >but the actual tools into .../legacy/... and they will work because >tools and shared libs fit together. > >I think there is something broken in buildworld with these legacy stuff. The way I build multiple versions of poudriere jails (this is on a -current box) is like this: 1. first decide what version to build. In this case, 13-stable. 2. if not already done, git clone https://git.freebsd.org/src.git /usr/src 3. cd /usr/src && git checkout stable/13 4. poudriere jail -c -j 13stable -b -m src=/usr/src -J8 -v stable/13 then if I want to make a 12.4 poudriere on the same box: 5. cd /usr/src && git checkout releng/12.4 6. poudriere jail -c -j 124releng -b -m src=/usr/src -J8 -v releng/12.4 7. if I want to update these jails, I need to first 'git checkout' the right version before running -u. I cannot accurately recall if you'd have to use -b as well, but I don't think you do. After all, -v isn't required in a -u context. So, to update, 'poudriere jail -j jailname -J8 -u'. -b builds from the specified sources *and* makes its own obj tree, from what I've seen. -- From nobody Mon Aug 7 15:51:55 2023 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 4RKLRc4jKrz4TnZG for ; Mon, 7 Aug 2023 15:52:12 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-yb1-xb2e.google.com (mail-yb1-xb2e.google.com [IPv6:2607:f8b0:4864:20::b2e]) (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 4RKLRc2kDLz4Xt7 for ; Mon, 7 Aug 2023 15:52:12 +0000 (UTC) (envelope-from kob6558@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-yb1-xb2e.google.com with SMTP id 3f1490d57ef6-c5ffb6cda23so5093682276.0 for ; Mon, 07 Aug 2023 08:52:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691423531; x=1692028331; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=n5PKr37OyNGRzxsuG5RWLZuaKV5vkq+YCexKK+iAuu8=; b=rELY6x+hMFKbH5bPonO2TabyVivkgN0QQ81eZ6Ab74y4Jgl2xwHOrlynfhAGDE1Yec yRl2gpbPo5g482atIDkY00+pGAvlowhfxM3YXFw5JQrbCoVeA4FtIfjauYEeAYjao2aO ahM/rp//o0GKTbBRGRs6/q1abCJpMVGnI8AdJi0djUlG7pxmIZmR//bHN/aRcKUeYgDD iClooZJ9fZPMZgrBZf9wUWZg0tS+qN/e03KA36iiEo53NiDSiJJej6PzRjE2GirXy2uW R9gU0LE/kJP1PcHdJDNtIpI+RU1Wes/5CW1OiF2c3AFe8dUeijgnYKg4kTT+f7symgft EBTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691423531; x=1692028331; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=n5PKr37OyNGRzxsuG5RWLZuaKV5vkq+YCexKK+iAuu8=; b=lr3WcZF9xwiUFGlOxKxDLZx9IIivDPqAeIjSF+5RsOi26TMEPvUFnbFfcEX+VUf26d 0wyE+KOUzUH95SvsVjdy/EbPL1qGIQk6LLaXzw1jslZz9kZDHIR2k2YoQiS44zG7mmaR C7QLFODQH5QKqEbPipRAmx5k2eDX4OCg6HgAldnl8kx+eKvrpEbmbFu9JE+jT3Eiwtyc p7xVolWp0Z/SX6x+eRTrfX2z2nEhIijVPsHr1Htxd54g1tQQQni0nOGfYt61bAo39TI+ wH5+Xap3vlgrZ3ym1vxHP2cX7he/eeTEfnMMOtyBXUZj1Hl2RkGQBwUtKMLzr/t7AlWv o4VQ== X-Gm-Message-State: AOJu0YwlVdcL5m+N8R1J03gGlqrbatt5kAkvnSqfePoYhdLX74awGoAy U6Sw+D558EegJEdELYIw7eMLG4qh+kG9fePaGkRgOamy7bI= X-Google-Smtp-Source: AGHT+IHHkUTVjSAlqjsy8d93Riugt7C4ntiRO0Xga6+gcXXYiH3WS6WKynycGjck37GjsfRzUa34sPu6XL5GPR7nMIo= X-Received: by 2002:a5b:547:0:b0:d13:babb:fcf0 with SMTP id r7-20020a5b0547000000b00d13babbfcf0mr8709170ybp.12.1691423531445; Mon, 07 Aug 2023 08:52:11 -0700 (PDT) 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: <7A0E604D-EF40-4F10-B597-F1F076507192@gmail.com> In-Reply-To: <7A0E604D-EF40-4F10-B597-F1F076507192@gmail.com> From: Kevin Oberman Date: Mon, 7 Aug 2023 08:51:55 -0700 Message-ID: Subject: Re: Has the update procedure changed? To: Tim Kellers Cc: Matthias Apitz , freebsd-current@freebsd.org Content-Type: multipart/alternative; boundary="000000000000c1b3290602573a22" X-Rspamd-Queue-Id: 4RKLRc2kDLz4Xt7 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] --000000000000c1b3290602573a22 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Aug 6, 2023 at 9:51=E2=80=AFAM Tim Kellers wrote= : > > > On Aug 6, 2023, at 11:05 AM, Kevin Oberman wrote: > > =EF=BB=BF > On Sat, Aug 5, 2023 at 10:51=E2=80=AFPM Matthias Apitz = wrote: > >> In the past I was used to use the following procedure to install a new >> kernel and world: >> >> # cd /usr/src >> # make installkernel >> # shutdown -r now >> >> boot -s from the loader prompt >> >> # adjkerntz -i >> # mount -a -t ufs >> # mergemaster -p >> # cd /usr/src >> # make installworld >> # mergemaster >> # yes | make delete-old >> # yes | make delete-old-libs >> >> # reboot >> >> Now the handbook >> https://docs.freebsd.org/en/books/handbook/cutting-edge/#makeworld >> says only: >> >> # cd /usr/src >> # make installkernel >> # shutdown -r now >> # cd /usr/src >> # make installworld >> # shutdown -r now >> >> Has this changed in past two years? >> >> Thanks >> >> matthias >> -- >> Matthias Apitz, =E2=9C=89 guru@unixarea.de, http://www.unixarea.de/ >> +49-176-38902045 >> Public GnuPG key: http://www.unixarea.de/key.pub >> > > Wow! Several obvious reasons that this looks just wrong. (Then again, so > is yours in one case.) > 1. "mergemaster -p" MUST be run before you build the kernel. (Actually, > hte man page says it should be run BEFORE buildworld and that is what I'v= e > always done although I have never seen a case where it was needed until > buildkernel. > 2. While mergemaster(8) is still in the system, you really should be usin= g > etcupdate(8). You also need to understand how a three-way merge is done a= nd > that you often need to edit the merged file when first running it. It's > pretty simple to run and rarely is needed after the first run, but it is > critical to do this for /etc files that you have modified. It's generally > just picking which of the two (original/yours) you want in the final file= . > The big win with etcupdate(8) is that it only needs to be run once for > modified files in almost all cases. > 3. Where is "make check-old" and the other tests to get rid of old files. > Leaving these around can lead to serious issues. > 4. If you don't do adjkerntz -i, you might find files installed in the > future which can get REALLY confusing! > > Historically, the final source of truth for all of this is > /usr/src/UPDATING. It has been updated for etcupdate(8) and is handled by > imp@, so I tend to believe it is correct. > > OK. Everyone who knows better, please explain why. I didn't mention "fsck > -p" but I'm really paranoid and it really, really should not be needed > unless something goes wrong in the shutdown after installing the new kern= el. > -- > Kevin Oberman, Part time kid herder and retired Network Engineer > E-mail: rkoberman@gmail.com > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 > > > I=E2=80=99ve always used the procedure listed at line 90 of the Makefile = in > /usr/src as the source of truth. Has that changed? > > Tim > UPDATING seems to match the Makefile except that Makefile is far less detailed. The Makefile even says "See src/UPDATING `COMMON ITEMS' for more complete information." I am more confused about "etcupdate -p". Both files put it after the kernel installation and reboot but before the installworld. The man page for etcupdate says that '-p' it should be run before "make buildworld" and I have always followed the man pages. --=20 Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkoberman@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 --000000000000c1b3290602573a22 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Aug 6, 2023 at 9:51=E2= =80=AFAM Tim Kellers <smsdtv@gmail.c= om> wrote:
<= div dir=3D"ltr">

On= Aug 6, 2023, at 11:05 AM, Kevin Oberman <rkoberman@gmail.com> wrote:

=EF=BB=BF
On Sat, Aug 5, 2023 at 10:51=E2=80=AFPM Matthias Apitz <guru@unixarea.de> = wrote:
In the past I was used to use the following procedure t= o install a new
kernel and world:

=C2=A0 =C2=A0 # cd /usr/src
=C2=A0 =C2=A0 # make installkernel
=C2=A0 =C2=A0 # shutdown -r now

=C2=A0 =C2=A0 boot -s from the loader prompt

=C2=A0 =C2=A0 # adjkerntz -i
=C2=A0 =C2=A0 # mount -a -t ufs
=C2=A0 =C2=A0 # mergemaster -p
=C2=A0 =C2=A0 # cd /usr/src
=C2=A0 =C2=A0 # make installworld
=C2=A0 =C2=A0 # mergemaster
=C2=A0 =C2=A0 # yes | make delete-old
=C2=A0 =C2=A0 # yes | make delete-old-libs

=C2=A0 =C2=A0 # reboot

Now the handbook https://docs.free= bsd.org/en/books/handbook/cutting-edge/#makeworld
says only:

=C2=A0 =C2=A0 # cd /usr/src
=C2=A0 =C2=A0 # make installkernel
=C2=A0 =C2=A0 # shutdown -r now
=C2=A0 =C2=A0 # cd /usr/src
=C2=A0 =C2=A0 # make installworld
=C2=A0 =C2=A0 # shutdown -r now

Has this changed in past two years?

Thanks

=C2=A0 =C2=A0 =C2=A0 =C2=A0 matthias
--
Matthias Apitz, =E2=9C=89 guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
<= div>=C2=A0
Wow! Several obvious reasons that this looks just wrong. (Then agai= n, so is yours in one case.)
1. "mergemaster -p" MUST be run before you bu= ild the kernel. (Actually, hte man page says it should be run BEFORE buildw= orld and that is what I've always done although I have never seen a cas= e where it was needed until buildkernel.
2. While mergemaster(8) is still in the sys= tem, you really should be using etcupdate(8). You also need to understand h= ow a three-way merge is done and that you=C2=A0 often need to edit the merg= ed file when first running it.=C2=A0 It's pretty simple to run and rare= ly is needed after the first run, but it is critical to do this for /etc fi= les that you have modified. It's generally just picking which of the tw= o (original/yours) you want in the final file. The big win with etcupdate(8= ) is that it only needs to be run once for modified files in almost all cas= es.
3. Wh= ere is "make check-old" and the other tests to get rid of old fil= es. Leaving these around can lead to serious issues.
4. If you don't do adjkernt= z -i, you might find files installed in the future which can get REALLY=C2= =A0 confusing!

Historically, the final source of truth for all of this is /usr/src/= UPDATING. It has been updated for etcupdate(8) and is handled by imp@, so I= tend to believe it is correct.

OK. Everyone who knows better, please explain why. I did= n't mention "fsck -p" but I'm really paranoid and it real= ly, really should not be needed unless something goes wrong in the shutdown= after installing the new kernel.
--
Kev= in Oberman, Part time kid herder and retired Network Engineer
E-mail: rkoberman@gmail.com<= /a>
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683=

I=E2=80=99ve always used the procedure listed a= t line 90 of the Makefile in /usr/src as the source of truth. Has that chan= ged?

Tim
=C2=A0
=
UPDATING seems to match the Makefile except that Makefile i= s far less detailed. The Makefile even says "See src/UPDATING `COMMON = ITEMS' for more complete information."

I am more confused about=C2=A0 "etcupdate -p". Both files= put it after the kernel installation and reboot but before the installworl= d. The man page for etcupdate says that '-p' it should be run befor= e "make buildworld" and I have always followed the man pages.
=
--
Kevin Oberman, Part time kid herder and = retired Network Engineer
E-mail: rkoberman@gmail.com
PGP Fingerprint: D0= 3FB98AFA78E3B78C1694B318AB39EF1B055683
<= /div>
--000000000000c1b3290602573a22-- From nobody Mon Aug 7 16:11:57 2023 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 4RKLtV0pddz4Tq2K for ; Mon, 7 Aug 2023 16:12:02 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (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 4RKLtT5vRnz4ZlN for ; Mon, 7 Aug 2023 16:12:01 +0000 (UTC) (envelope-from guru@unixarea.de) Authentication-Results: mx1.freebsd.org; none Received: from [188.174.55.7] (helo=localhost.unixarea.de) by ms-10.1blu.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qT2pq-0005f9-Mr; Mon, 07 Aug 2023 18:11:58 +0200 Received: from localhost.my.domain (localhost [127.0.0.1]) by localhost.unixarea.de (8.16.1/8.14.9) with ESMTPS id 377GBvZ1014282 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 7 Aug 2023 18:11:57 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.16.1/8.14.9/Submit) id 377GBvKV014281; Mon, 7 Aug 2023 18:11:57 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Mon, 7 Aug 2023 18:11:57 +0200 From: Matthias Apitz To: Kevin Oberman Cc: Tim Kellers , freebsd-current@freebsd.org Subject: Re: Has the update procedure changed? Message-ID: Reply-To: Matthias Apitz Mail-Followup-To: Kevin Oberman , Tim Kellers , freebsd-current@freebsd.org References: <7A0E604D-EF40-4F10-B597-F1F076507192@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: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: FreeBSD 13.0-CURRENT r368166 (amd64) X-message-flag: Mails containing HTML will not be read! Please send only plain text. X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 188.174.55.7 X-Rspamd-Queue-Id: 4RKLtT5vRnz4ZlN X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:42730, ipnet:178.254.0.0/19, country:DE] El día lunes, agosto 07, 2023 a las 08:51:55a. m. -0700, Kevin Oberman escribió: > On Sun, Aug 6, 2023 at 9:51 AM Tim Kellers wrote: > > > > > > > On Aug 6, 2023, at 11:05 AM, Kevin Oberman wrote: > > > >  > > On Sat, Aug 5, 2023 at 10:51 PM Matthias Apitz wrote: > > > >> In the past I was used to use the following procedure to install a new > >> kernel and world: > >> > >> # cd /usr/src > >> # make installkernel > >> # shutdown -r now > >> > >> boot -s from the loader prompt > >> > >> # adjkerntz -i > >> # mount -a -t ufs > >> # mergemaster -p > >> # cd /usr/src > >> # make installworld > >> # mergemaster > >> # yes | make delete-old > >> # yes | make delete-old-libs > >> > >> # reboot > >> > ... > I am more confused about "etcupdate -p". Both files put it after the > kernel installation and reboot but before the installworld. The man page > for etcupdate says that '-p' it should be run before "make buildworld" and > I have always followed the man pages. The man page of mergemaster says: -p Pre-buildworld mode. Compares only files known to be essential to the success of {build|install}world, i.e., /etc/group and /etc/master.passwd. i.e. it must be run after installkernel and before installworld to adjust the new /etc/group and /etc/master.passwd. After installworld mergemaster should be run (or etcupdate) without -p to adjust all the scripts below /etc, /etc/rc.d/ ... I've used this procedure above for many years and it always let me decide it I want the new or the old or deal later with the diff of all these files. And so I did it yesterday and it worked fine again. Will check the next time what etcupdate wants to do, because it seems the sucsessor of mergemaster. matthias -- Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub From nobody Mon Aug 7 18:29:27 2023 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 4RKPx85Y76z4m6PN; Mon, 7 Aug 2023 18:29:32 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) (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 4RKPx75l6wz3NMT; Mon, 7 Aug 2023 18:29:31 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20221208 header.b=nK6GJV3U; spf=pass (mx1.freebsd.org: domain of yaneurabeya@gmail.com designates 2607:f8b0:4864:20::42b as permitted sender) smtp.mailfrom=yaneurabeya@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-pf1-x42b.google.com with SMTP id d2e1a72fcca58-686efa1804eso3482489b3a.3; Mon, 07 Aug 2023 11:29:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691432970; x=1692037770; h=to:references:message-id:cc:date:in-reply-to:from:subject :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=oYMqs0Uhe+xXOIoFJ1YijPkvCF82gLNDiV5S30CS+Oc=; b=nK6GJV3UKiKCgrwf3PPzZii0n46WPCZcjiQRbg34Sq4U90YLaFBd1MRH+HM+pKg8AA quIeJxDwWnRp0FfIIyHA5cedG1On5zGm50WoNteUJ4tPfbRdN/VylY+FRh1/gGAyA5KH GSuB9+iPLNdlKbxNrNgSsSKcNE+cVzgZG8s8xlAm8e2LJImA8bPfyJ62/lgd5fqWdiL8 u59bwEeUK2SOBZiYTKgKzLSb16a5LgutsWiLED2ghOwd97rTZN2lJ0cNCXIHyZud7mHf gnR5dxemgCog/s2J6Uzdh0pIG6ZOVlguhrR3TlB2arzNUlNqCAXVNrh/yB6XN13kUgsN j4ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691432970; x=1692037770; h=to:references:message-id:cc:date:in-reply-to:from:subject :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=oYMqs0Uhe+xXOIoFJ1YijPkvCF82gLNDiV5S30CS+Oc=; b=InnwB9Nj4Gy5S5dtAcCiDD6W4f+D7+cc0pet2NqdvcAytv6garRirg12k9A7UMUcEs IWfPUgEnGzzFWFcSbY06FPioURWdxFQJ/swCpr8G7SlcJIGvv+tkyFxPGVr9wTqJ3vUZ hjpUbWfwQ/Q6YTGNa+mETVB3QFivx+uHlh1/ixR539QdTy+kZIH7ExiGT/tH632pLFtw 85xp7m82muEVHq61iBO/Own9Vr/bgtkEtPgsl3FdfjRLAqbErBSeT+5L95FyUv59ydJI E23syt8h+57GpD0JSTrrQsyPqvvv7m+AzZAY9D/lNG4hRDWUzKk2sKgNwul0+HHkNJpp 33CQ== X-Gm-Message-State: AOJu0Yx4GGo3ROTuLf3qGrkBXf6Oqr5phr2sMwj3QZITBkJW3m1xYkxG BTSx/Jm+Z7xmPVdXvna/0VeBFSNo8Qw= X-Google-Smtp-Source: AGHT+IHFvPF7dqVSIAC0yrZebBZsfH5ijuj+AEvaGCh+QaBGIY0yGk9lEnXOH/X+apOwLlMZ+AZwWg== X-Received: by 2002:a05:6a00:1816:b0:672:264c:e8cf with SMTP id y22-20020a056a00181600b00672264ce8cfmr12863913pfa.7.1691432970273; Mon, 07 Aug 2023 11:29:30 -0700 (PDT) Received: from smtpclient.apple (c-73-19-52-228.hsd1.wa.comcast.net. [73.19.52.228]) by smtp.gmail.com with ESMTPSA id c23-20020a62e817000000b0068783a2dfdasm6453792pfi.104.2023.08.07.11.29.29 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Aug 2023 11:29:29 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_F5EC6333-8803-4207-AA92-CFF70C7C72E7"; protocol="application/pgp-signature"; micalg=pgp-sha256 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 16.0 \(3696.120.41.1.4\)) Subject: Re: armv7 kyua runs via chroot on aarch64: zfs tests leave behind processes from timed out tests From: Enji Cooper In-Reply-To: Date: Mon, 7 Aug 2023 11:29:27 -0700 Cc: Current FreeBSD , FreeBSD ARM List Message-Id: <96486101-14EF-4588-A078-26F85AF1FE34@gmail.com> References: <1BDD2369-BCC3-469B-8094-AEFE7FC3CE94@yahoo.com> To: Mark Millard X-Mailer: Apple Mail (2.3696.120.41.1.4) X-Spamd-Result: default: False [-5.57 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.97)[-0.974]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; MV_CASE(0.50)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20221208]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; RCPT_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::42b:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-arm@freebsd.org]; TO_DN_ALL(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; HAS_ATTACHMENT(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_TO(0.00)[yahoo.com]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_TWO(0.00)[2] X-Spamd-Bar: ----- X-Rspamd-Queue-Id: 4RKPx75l6wz3NMT --Apple-Mail=_F5EC6333-8803-4207-AA92-CFF70C7C72E7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 3, 2023, at 10:20 AM, Mark Millard wrote: >=20 > On Aug 3, 2023, at 07:18, Mark Millard wrote: >=20 >> On Aug 3, 2023, at 00:19, Mark Millard wrote: >>=20 >>> This is after the patch (leading whitespace might >>> not have been preserved in what you see): >>>=20 >>> # git -C /usr/main-src/ diff sys/dev/md/ >>> diff --git a/sys/dev/md/md.c b/sys/dev/md/md.c >>> index a719dccb1955..365296ec4276 100644 >>> --- a/sys/dev/md/md.c >>> +++ b/sys/dev/md/md.c >>> @@ -147,8 +147,15 @@ struct md_ioctl32 { >>> int md_fwsectors; >>> uint32_t md_label; >>> int md_pad[MDNPAD]; >>> +#ifdef __aarch64__ >>> + uint32_t md_pad0; >>> +#endif >>> } __attribute__((__packed__)); >>> +#ifdef __aarch64__ >>> +CTASSERT((sizeof(struct md_ioctl32)) =3D=3D 440); >>> +#else >>> CTASSERT((sizeof(struct md_ioctl32)) =3D=3D 436); >>> +#endif >>>=20 >>> #define MDIOCATTACH_32 _IOC_NEWTYPE(MDIOCATTACH, struct = md_ioctl32) >>> #define MDIOCDETACH_32 _IOC_NEWTYPE(MDIOCDETACH, struct = md_ioctl32) >>>=20 >>>=20 >>> The kyua run is still in process, but at this point there is >>> the following accumulation from the zfs testing timouts: >>>=20 >>> # ps -alxdww >>> UID PID PPID C PRI NI VSZ RSS MWCHAN STAT TT TIME = COMMAND >>> . . . >>> 0 17491 1 6 20 0 36460 12324 - T - 0:24.71 |-- = fsync_integrity /testdir2316/testfile2316 >>> 0 17551 1 5 20 0 10600 7512 tx->tx_s D - 0:00.00 |-- = /sbin/zpool destroy -f testpool.2316 >>> 0 17739 1 7 20 0 10600 7308 zfs tear D - 0:00.00 |-- = /sbin/zpool destroy -f testpool.2316 >>> 0 17841 1 3 20 0 10600 7316 tx->tx_s D - 0:00.00 |-- = /sbin/zpool destroy -f testpool.2316 >>> 0 17860 1 0 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >>> 0 17888 1 3 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >>> 0 17907 1 6 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >>> 0 17928 1 7 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >>> 0 17955 1 0 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >>> 0 17976 1 4 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >>> 0 17995 1 2 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >>> 0 18023 1 2 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >>> 0 18043 1 2 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >>> 0 18064 1 3 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >>> 0 18085 1 0 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >>> 0 18114 1 7 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >>> 0 18135 1 2 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >>> 0 18157 1 6 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >>> 0 18177 1 6 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >>> 0 18205 1 4 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >>> 0 18224 1 1 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >>> 0 18255 1 3 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >>> 0 18275 1 1 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >>> 0 18296 1 5 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >>> 0 18317 1 4 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >>> 0 18345 1 4 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >>> 0 18365 1 2 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >>> 0 18386 1 3 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >>> 0 18412 1 1 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >>> 0 18447 1 5 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >>> 0 18466 1 5 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >>> 0 18516 1 6 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >>> 0 18535 1 2 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >>> 0 18632 1 0 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >>=20 >> It has added: >>=20 >> 0 18656 1 7 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >> 0 18748 1 0 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >> 0 18767 1 4 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >> 0 18858 1 5 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >> 0 18877 1 0 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >> 0 18907 1 7 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >> 0 18926 1 5 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >> 0 18956 1 7 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >> 0 18975 1 7 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >> 0 19005 1 4 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >> 0 19026 1 4 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >> 0 19298 1 6 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >> 0 19317 1 6 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >> 0 19408 1 7 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >> 0 19427 1 2 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >> 0 19518 1 4 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >> 0 19537 1 4 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >> 0 19635 1 5 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >=20 > 0 19654 1 5 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 19746 1 6 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 19767 1 6 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 19854 1 6 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 19873 1 0 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade > 0 19960 1 1 20 0 10080 6956 spa_name D - 0:00.00 |-- = /sbin/zfs upgrade >=20 >>> Lots of these are from 300s timeouts but some are from 1200s or >>> 1800s or 3600s timeouts. >>>=20 >>> For reference: >>>=20 >>> = sys/cddl/zfs/tests/txg_integrity/txg_integrity_test:fsync_integrity_001_po= s -> broken: Test case body timed out [1800.053s] >>> = sys/cddl/zfs/tests/txg_integrity/txg_integrity_test:txg_integrity_001_pos = -> passed [63.702s] >>> sys/cddl/zfs/tests/userquota/userquota_test:groupspace_001_pos -> = skipped: Required program 'runwattr' not found in PATH [0.003s] >>> sys/cddl/zfs/tests/userquota/userquota_test:groupspace_002_pos -> = skipped: Required program 'runwattr' not found in PATH [0.002s] >>> sys/cddl/zfs/tests/userquota/userquota_test:userquota_001_pos -> = skipped: Required program 'runwattr' not found in PATH [0.002s] >>> sys/cddl/zfs/tests/userquota/userquota_test:userquota_002_pos -> = broken: Test case cleanup timed out [0.148s] >>> sys/cddl/zfs/tests/userquota/userquota_test:userquota_003_pos -> = broken: Test case cleanup timed out [0.151s] >>> sys/cddl/zfs/tests/userquota/userquota_test:userquota_004_pos -> = skipped: Required program 'runwattr' not found in PATH [0.002s] >>> sys/cddl/zfs/tests/userquota/userquota_test:userquota_005_neg -> = broken: Test case body timed out [300.021s] >>> sys/cddl/zfs/tests/userquota/userquota_test:userquota_006_pos -> = broken: Test case body timed out [300.080s] >>> sys/cddl/zfs/tests/userquota/userquota_test:userquota_007_pos -> = skipped: Required program 'runwattr' not found in PATH [0.002s] >>> sys/cddl/zfs/tests/userquota/userquota_test:userquota_008_pos -> = broken: Test case body timed out [300.034s] >>> sys/cddl/zfs/tests/userquota/userquota_test:userquota_009_pos -> = broken: Test case body timed out [300.143s] >>> sys/cddl/zfs/tests/userquota/userquota_test:userquota_010_pos -> = skipped: Required program 'runwattr' not found in PATH [0.002s] >>> sys/cddl/zfs/tests/userquota/userquota_test:userquota_011_pos -> = broken: Test case body timed out [300.003s] >>> sys/cddl/zfs/tests/userquota/userquota_test:userquota_012_neg -> = broken: Test case body timed out [300.019s] >>> sys/cddl/zfs/tests/userquota/userquota_test:userspace_001_pos -> = skipped: Required program 'runwattr' not found in PATH [0.002s] >>> sys/cddl/zfs/tests/userquota/userquota_test:userspace_002_pos -> = skipped: Required program 'runwattr' not found in PATH [0.002s] >>> sys/cddl/zfs/tests/utils_test/utils_test_test:utils_test_001_pos -> = broken: Test case body timed out [300.052s] >>> sys/cddl/zfs/tests/utils_test/utils_test_test:utils_test_002_pos -> = skipped: Required program 'labelit' not found in PATH [0.002s] >>> sys/cddl/zfs/tests/utils_test/utils_test_test:utils_test_003_pos -> = broken: Test case body timed out [300.076s] >>> sys/cddl/zfs/tests/utils_test/utils_test_test:utils_test_004_pos -> = broken: Test case body timed out [300.106s] >>> sys/cddl/zfs/tests/utils_test/utils_test_test:utils_test_005_pos -> = skipped: Required program 'ff' not found in PATH [0.002s] >>> sys/cddl/zfs/tests/utils_test/utils_test_test:utils_test_006_pos -> = broken: Test case body timed out [300.015s] >>> sys/cddl/zfs/tests/utils_test/utils_test_test:utils_test_007_pos -> = broken: Test case body timed out [300.005s] >>> sys/cddl/zfs/tests/utils_test/utils_test_test:utils_test_008_pos -> = skipped: Required program 'ncheck' not found in PATH [0.002s] >>> sys/cddl/zfs/tests/utils_test/utils_test_test:utils_test_009_pos -> = broken: Test case body timed out [300.051s] >>> sys/cddl/zfs/tests/write_dirs/write_dirs_test:write_dirs_001_pos -> = broken: Test case body timed out [1200.056s] >>> sys/cddl/zfs/tests/write_dirs/write_dirs_test:write_dirs_002_pos -> = broken: Test case body timed out [1200.046s] >>> sys/cddl/zfs/tests/zfsd/zfsd_test:zfsd_autoreplace_001_neg -> = broken: Test case body timed out [3600.055s] >>=20 >> And added: >>=20 >> sys/cddl/zfs/tests/zfsd/zfsd_test:zfsd_autoreplace_002_pos -> = broken: Test case body timed out [3600.028s] >> sys/cddl/zfs/tests/zfsd/zfsd_test:zfsd_autoreplace_003_pos -> = broken: Test case body timed out [3600.146s] >> sys/cddl/zfs/tests/zfsd/zfsd_test:zfsd_degrade_001_pos -> broken: = Test case body timed out [600.067s] >> sys/cddl/zfs/tests/zfsd/zfsd_test:zfsd_degrade_002_pos -> broken: = Test case body timed out [600.015s] >> sys/cddl/zfs/tests/zfsd/zfsd_test:zfsd_fault_001_pos -> broken: = Test case body timed out [300.061s] >> sys/cddl/zfs/tests/zfsd/zfsd_test:zfsd_hotspare_001_pos -> broken: = Test case body timed out [3600.042s] >> sys/cddl/zfs/tests/zfsd/zfsd_test:zfsd_hotspare_002_pos -> broken: = Test case body timed out [3600.161s] >> sys/cddl/zfs/tests/zfsd/zfsd_test:zfsd_hotspare_003_pos -> broken: = Test case body timed out [3600.033s] >> sys/cddl/zfs/tests/zfsd/zfsd_test:zfsd_hotspare_004_pos -> broken: = Test case body timed out [3600.007s] >=20 > sys/cddl/zfs/tests/zfsd/zfsd_test:zfsd_hotspare_005_pos -> broken: = Test case body timed out [3600.065s] > sys/cddl/zfs/tests/zfsd/zfsd_test:zfsd_hotspare_006_pos -> broken: = Test case body timed out [3600.014s] > sys/cddl/zfs/tests/zfsd/zfsd_test:zfsd_hotspare_007_pos -> broken: = Test case body timed out [3600.066s] >=20 >>> Other timeouts not from zfs tests have not had an accumulation >>> of processes left behind. But these may be the set of tests >>> that use ksh93 for scripting. I make no claim of knowing the >>> zfs vs. ksh93 vs. both vs. ??? for what is contributing. >>>=20 >>>=20 >>> I'll note that the system was booted via a bectl BE environment >>> on the only FreeBSD media enabled, so is a zfs-root boot context. >>>=20 >>> For reference: >>>=20 >>> # uname -apKU >>> FreeBSD CA78C-WDK23-ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT aarch64 = 1400093 #6 main-n264334-215bab7924f6-dirty: Wed Aug 2 14:12:14 PDT 2023 = = root@CA78C-WDK23-ZFS:/usr/obj/BUILDs/main-CA78C-nodbg-clang/usr/main-src/a= rm64.aarch64/sys/GENERIC-NODBG-CA78C arm64 aarch64 1400093 1400093 >>>=20 >>> I preload various modules (6 are commented out [not preloaded] >>> and some listed may be actually built into the kernel): >>>=20 >>> # grep kldload ~/prekyua-kldloads.sh >>> kldload -v -n zfs.ko >>> kldload -v -n cryptodev.ko >>> kldload -v -n nullfs.ko >>> kldload -v -n fdescfs.ko >>> kldload -v -n filemon.ko >>> kldload -v -n nfsd.ko >>> kldload -v -n tarfs.ko >>> kldload -v -n xz.ko >>> kldload -v -n geom_concat.ko >>> kldload -v -n geom_eli.ko >>> kldload -v -n geom_nop.ko >>> kldload -v -n geom_gate.ko >>> kldload -v -n geom_mirror.ko >>> kldload -v -n geom_multipath.ko >>> kldload -v -n sdt.ko >>> kldload -v -n dtrace.ko >>> kldload -v -n opensolaris.ko >>> kldload -v -n geom_raid3.ko >>> kldload -v -n geom_shsec.ko >>> kldload -v -n geom_stripe.ko >>> kldload -v -n geom_uzip.ko >>> kldload -v -n if_epair.ko >>> kldload -v -n if_gif.ko >>> kldload -v -n if_tuntap.ko >>> kldload -v -n if_lagg.ko >>> kldload -v -n if_infiniband.ko >>> kldload -v -n if_wg.ko >>> kldload -v -n ng_socket.ko >>> kldload -v -n netgraph.ko >>> kldload -v -n ng_hub.ko >>> kldload -v -n ng_bridge.ko >>> kldload -v -n ng_ether.ko >>> kldload -v -n ng_vlan_rotate.ko >>> kldload -v -n ipdivert.ko >>> kldload -v -n pf.ko >>> kldload -v -n if_bridge.ko >>> kldload -v -n bridgestp.ko >>> kldload -v -n mqueuefs.ko >>> kldload -v -n tcpmd5.ko >>> kldload -v -n carp.ko >>> kldload -v -n sctp.ko >>> kldload -v -n if_stf.ko >>> kldload -v -n if_ovpn.ko >>> kldload -v -n ipsec.ko >>> #kldload -v -n ipfw.ko >>> #kldload -v -n pflog.ko >>> #kldload -v -n pfsync.ko >>> kldload -v -n dummynet.ko >>> #kldload -v -n mac_bsdextended.ko >>> #kldload -v -n mac_ipacl.ko >>> #kldload -v -n mac_portacl.ko >>>=20 >>> armv7 ports built and installed in the armv7 chroot >>> area include: >>>=20 >>> # more ~/origins/kyua-origins.txt >>> archivers/gtar >>> devel/gdb >>> devel/py-pytest >>> devel/py-pytest-twisted >>> devel/py-twisted >>> lang/perl5.32 >>> lang/python >>> net/scapy >>> security/nist-kat >>> security/openvpn >>> security/sudo >>> shells/ksh93 >>> shells/bash >>> sysutils/coreutils >>> sysutils/sg3_utils >>> textproc/jq >>>=20 >>> (Those cause others to also be installed.) >>=20 >> I tried gdb -p PID against a couple of the processes. >> Each got stuck, not reaching the gdb prompt. I also >> show a Control-T output: >>=20 >> Attaching to process 17491 >> load: 0.24 cmd: gdb131 19693 [uwait] 32.27r 0.02u 0.06s 0% 32152k >> #0 0xffff00000049fe20 at mi_switch+0xe0 >> #1 0xffff0000004f3658 at sleepq_catch_signals+0x318 >> #2 0xffff0000004f3318 at sleepq_wait_sig+0x8 >> #3 0xffff00000049f410 at _sleep+0x1d0 >> #4 0xffff0000004b52dc at umtxq_sleep+0x27c >> #5 0xffff0000004bab7c at do_wait+0x25c >> #6 0xffff0000004b8cdc at __umtx_op_wait_uint_private+0x5c >> #7 0xffff0000004b6e64 at sys__umtx_op+0x84 >> #8 0xffff0000008267d4 at do_el0_sync+0x9b4 >> #9 0xffff000000805910 at handle_el0_sync+0x44 >>=20 >> and: >>=20 >> Attaching to process 17860 >> load: 0.23 cmd: gdb131 19697 [uwait] 13.14r 0.06u 0.01s 0% 32184k >> #0 0xffff00000049fe20 at mi_switch+0xe0 >> #1 0xffff0000004f3658 at sleepq_catch_signals+0x318 >> #2 0xffff0000004f3318 at sleepq_wait_sig+0x8 >> #3 0xffff00000049f410 at _sleep+0x1d0 >> #4 0xffff0000004b52dc at umtxq_sleep+0x27c >> #5 0xffff0000004bab7c at do_wait+0x25c >> #6 0xffff0000004b8cdc at __umtx_op_wait_uint_private+0x5c >> #7 0xffff0000004b6e64 at sys__umtx_op+0x84 >> #8 0xffff0000008267d4 at do_el0_sync+0x9b4 >> #9 0xffff000000805910 at handle_el0_sync+0x44 >>=20 >> I was unable to Control-C the gdb's to gain control >> but was able to put them in the background (Control-Z >> then bg). >=20 > Looks like I'm going to have to reboot instead of letting > the kyua run go to completion. The periodic daily is stuck > as well. >=20 > 0 19064 1657 1 20 0 12980 2484 piperd I - 0:00.00 | `-- = cron: running job (cron) > 0 19066 19064 3 40 0 13436 2928 wait Is - 0:00.00 | = `-- /bin/sh - /usr/sbin/periodic daily > . . . > 0 19237 19235 0 68 0 13436 2936 wait I - 0:00.00 | = | | `-- /bin/sh - /etc/periodic/security/100.chksetuid > 0 19242 19237 6 68 0 21912 10292 zfs D - 0:10.21 | = | | |-- / /var/mail . . . /dev/null (find) > 0 19243 19237 7 68 0 13436 2932 wait I - 0:00.00 | = | | `-- /bin/sh - /etc/periodic/security/100.chksetuid > 0 19245 19243 1 68 0 15204 2212 piperd I - 0:00.00 | = | | `-- cat >=20 > is also stuck. So the problems are now not limited to > the kyua run. Hi Mark, Could you please submit bugs and CC freebsd-testing or another = appropriate mailing list? It looks like there are some Arm64 = architecture specific issues that need to be addressed based on the = limited information I have from these emails. Do you have DEADLKRES/INVARIANTS/WITNESS compiled into your = kernel? If not, could you please do that? If that doesn=E2=80=99t give any helpful hints, could you please = panic the kernel and dump some debug info from ddb, e.g., 1. alltrace 2. show allchains 3. show alllocks Thank you, -Enji --Apple-Mail=_F5EC6333-8803-4207-AA92-CFF70C7C72E7 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----- iQIzBAEBCAAdFiEEtvtxN6kOllEF3nmX5JFNMZeDGN4FAmTROAgACgkQ5JFNMZeD GN5QAw/+IqlWuplK0ydmi9VkiyaR3JegMrRHZijYuQZVdUFarbSvT5WD+Lsdfgqw 42jiR+Ff4Yw7S3ab+g3mAGMFmYtgmkDCWp5G4Lyfd2AFdMRzt0lodbDOUmbvwBFP 3t+qkMUMM1AeM/aiKu1tD09mHkwGeUM3LvCYKOh1fwDuo0u+tY3JuF1y+5su529u Cu8w4NoTBhfJ/GPBB/oRe3MdaFx0J1PFVN4HebPonViaQ8EohchKiaBnkqTfzLLH XKVL7gkdG2VLG1tvsPK4hcDkRXFtpvKxfKklt4arq18N0oAl4oh3ez0My+dD1tOJ 2TConrKMsnY5NTZdrPd31o5f58CLNZk1WhumQbCNXVB0UiJgV7vSM840wggYKH1f XdA5/CiYV+H8lqkWrTWQbQXVUhhexmo19DoizMtTeIr+TjxBzF85SCJiNMv4Kz4k PvZkCBKZHrBbAIRqA0umcTwczsZl6K/w/HyzXjyrRlMq1DPABUOJnwZkSO6Yk5AC mgH90M2YkLP+la2u+BenW6JoQ9N00xJ7FV1/28cSP2HkIgF5MlA7t8Mgwlv5oaZ2 HxGuEulaR8x/x+jsb6OhL5ji6j8v0rRuAg+KQAHPaxXUejgNcrJVnSgsTPuG2+nn WMNiEBzbcZul+4uE5l8nZU1LpzeXOXw394sQgmhEaNal9Hj0tiU= =NfUI -----END PGP SIGNATURE----- --Apple-Mail=_F5EC6333-8803-4207-AA92-CFF70C7C72E7-- From nobody Mon Aug 7 19:40:14 2023 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 4RKRW46BSPz4mCW6 for ; Mon, 7 Aug 2023 19:40:32 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-21.consmr.mail.gq1.yahoo.com (sonic309-21.consmr.mail.gq1.yahoo.com [98.137.65.147]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4RKRW423kPz3TBj for ; Mon, 7 Aug 2023 19:40:32 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1691437230; bh=/Wi1ufOJmtAuGCJyatGXziyB4akbYfN6FgbK0HQxXh8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=UdM1Za1ls6dsVQJjIaQuJ5Te2maq5ZMKKXpjmhrhwnKVdpYS6LcRDqfxkVs3sciDcob0Ew0YCyvEGf4FsMhlLAtS4ms4rU31M+sxEchqTVhM4HhpGFdC7gxIFH/TWKEFQzbuPqJNNTJFS6FX+tTqlECFt/8jNXO3ywZyE1466BFlW6BPDEEIIrslgqKjcHG00ip/Hl0yju/EXUHyPOUrZAh5m4vjoARX3iQul1ZMp1pAJE8HUHXHB1b9/0xFB5Waxas01HO6m8G9a3K5iFru7WEz7inpbWwaRG6F3WyceFft8hRzhqBKVrj+QKgbJgM8iwtfqTPV8kkwfYg4X/Ni5Q== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1691437230; bh=L/Hg/JNAmk130l8R51NMFGJKsbfDx9zJlDkSOGVB0ZH=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=awBd1ZO8GYgeEFtkfguP0EkHDVF1R6N/8vpki/3Skhf2pDgpXlsc58xyDH2sXqOe07O+dxo2AEJYrZuRErTrNCqD1gWj2QHiJIK+0qympaKBfZAuDsxgzMXCEhFzonUqLp2ljRuW4Hc/S8QVYAL0ID7DUMeGv+B+1zr72UTFlwKlgnLNmpKN3cqRW4PLE440fv23JfWb2Dtlil1g7AUKUhbsOJwrBGrn47VWVz/141/0XFactKEOrkVSVcMtRcge0grDSvYVmi2mr4CzpBWiYGSjTcGXlHNCMGzP77OV2dc1TroWT9VoWjZQOHytUtZGdBk1DVcXdkrMG3yqBbxz5g== X-YMail-OSG: wsK2.EUVM1lzmWP_d3OPHmDHnenCpofxzXOTuOytn5fJE6OKU.GGQ.6oLREhul9 b8GFhY9xtiIaKeH4.1EoEONEUeeTMmtEecvYvncoFEPsqZXba1Ve1sjYSFjbPZgupWPNhmVdN9Ta LtjZvXY0MArV_UidnFYOr2yzKrAe63RlKAJxKX_bvvL3i8j41ByHC_l4QMHRaO6O3VPqbUCQCph3 TFJtw.JAz2v8QWsX7zf4CWsdeHFaDtrQduj62aZpemSUHzB5hLPn6X4Dr8dhz9ONH6p.rdjQuYuk 9muBHufEbdi367KjrKdpJ3nhAvs_GsN4KFB6WOtTfJqnPYwl6Ip10qNdcNRlBfCn5J5_GJX2RdSR wR5eDTMEwy_AkCb5PHh0x9aZe_oJbpxZ5qu0aDzwntzE6p.g6.DrmOQltAM8iHvwvkyEl6T2FbOI JnGqD24Dm_PWpIt8bIjGuAdtVJgsyLSBERGn.zd_LbA5NuUP84JbcMR7Y_3Nmq2ahhxPJJXbCaiF av7klZSu.0vGrdbC6ripsLFkv71xdCxFtczNyhBXk0MfBTpmVBvdJcf76Yto6Fr2zBGi_JDHKNcR oVGshpwL26Pc5UkntSNgtH.C3dw.noJLV7RVvel8wEmCeHtYKDaV9cIGzQ8LqasTXIAeb.UvRIG4 scxOup6SWU7BdG6a2yMR7wV8pi1zcuXpDMMPIUO17Y8Exsk_b_wOnA59Y7vde65asPHAh27Dr5ri __EOjgxIGQjbgnN3MHoFy6KfXM1xKAfIfLLhqyF4t9.4jegAYN7GGJc.0cyLpmQ_3LalAvq4dniL ZLFOLgIQGET0Ths7Rd7QRArKM7PDI3dyyTLUrqPCrfXA4wmw1El62GPxoA1t3UHuxiZ_lDMpNttE XQHdLeZmNaAF1Rn2cqigJezDTNZFxKF_cdy8WBZ7VZ94Z4Vw_P6gqKGabprRinaGluYiKls9nsru NC9FR7DcAuJh1ANRVTUj63xEddX_MQ5sRGn2idgQWS3aoDPH6WHv9oWioeeCBG3w3AvcZgDzij3A ISJIa9O33mIFMdPeZ.vuxA5toLEIKD7fs7eGAuTRrZ9pPEGdNjZdaDgjAIeToVW_vth_XZD6dRfI 4gxd1HxBbgjVe7y0CCTJO1YNuJDyTAJJ9qYx7uwi9UIC8FHliZ524bAdcTsZt21n5Pl2WRqiwgrJ faYtnUaoFeW.4f9AgM.T9vhTWP2WcWjfrzlaRE_qsTSRvWfPDCZHSWz7mAlehPv1eWbJzi0.rYcD 3Lmq0edA9FwjsBH.Lbgkp5UxdGkrosQKm1mEGnA98CUx9iWraoLiZSQKt6JUfj4wngP7x_UD7YtO sPX0eQ5z_m4NaXuCdMDG1B8Mve5DHx_fFaIwXHE3D6.yKgQlrp._XgaDu81ItOm34YXEWPaAPPbo 4szVu1mzqIOV2o.FShLkhbe84JjOxXusYg4NkoVpw2FBhDdw0mYCYahD3oP1oEhG1AMTbNls3whd TUZFhGTLI_9.U1hMwc4MjXb11hB3fw3FBsHheE08ot7_mnCUImVBkjlzrelTzAHm7Mr1_ZA4jX.E LSlN4Kbr4Yo65H4Wqz2qT3I04HX3RKSwlW.eP03kzt2IVdOopIkQomXYp4Plt7ykKINfv.YmsiIx 5h8iIAmyfnGOfqpmw0ar_wJAfUze_yF7VJbMT0YN0uwZHC3ZX9p1NEjn5g24nMpiR_KkNQ2k4bY7 eFYZHuYPHK88M4SVomYPwXZGSixxJs5S6._wAR6rfrpePOfsE_wpAoiKN62TYDzN0U3UMNI1mSCa W0xkTlfXh7zjfymLrzRIRlX_rfuw7tJ21RW_Z5I.quTmwcUjzaBv2RvdcbNsGa0lzKo068v3eJaz 7olgXyMpj.2.te3QvfrfELcNWMuM0esqQpuuR1kpV4G8uwn3O9S.F3wy71RVEnCYTw0QQaOAcycV hp3jy7UYkyZR7KWxHFc50Z38PzTIvHPooYbGc2c57TZXCMSsSKxus3hbrWb3dOIFKd74p0gO_Y6O yBTAQZDSfwi0FDj1hOo44uCu7nqqyxnPQt._9hMZCWTMVG_b2LerqEt7vrP6FqH_341MLWVs44XJ y1q4jlQBf4AGEJCZNhjPiSwsYWtxBhe8HDHRt_T6rjzCbdsvbwmUEBREMolSwWBLaGp9nOdwaWQ_ gyiu2x1WbOBHMIKTZh6W3imsGTpRR4NQ0ApCls1D7aYVQEgfVqfhLR4A2.aM5uIb5iK2TGgVVWvR nGhkPuG0QXSVj8Bw78OMmk2AugXI2OrjGnegXcOEWHSfYoJFtvZmAiA3x0p26TinCdhzIwbCtvg- - X-Sonic-MF: X-Sonic-ID: 70a38877-22ae-4955-aa30-6a76ab0264c0 Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Mon, 7 Aug 2023 19:40:30 +0000 Received: by hermes--production-ne1-7b767b77cc-7tm2h (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 32f346f5e5e38d42d0176a302993e88c; Mon, 07 Aug 2023 19:40:26 +0000 (UTC) Content-Type: text/plain; charset=utf-8 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 16.0 \(3731.700.6\)) Subject: Re: armv7 kyua runs via chroot on aarch64: zfs tests leave behind processes from timed out tests From: Mark Millard In-Reply-To: <96486101-14EF-4588-A078-26F85AF1FE34@gmail.com> Date: Mon, 7 Aug 2023 12:40:14 -0700 Cc: Current FreeBSD , FreeBSD ARM List Content-Transfer-Encoding: quoted-printable Message-Id: <658F2FE2-2A3A-4160-A08E-D11A64B430A3@yahoo.com> References: <1BDD2369-BCC3-469B-8094-AEFE7FC3CE94@yahoo.com> <96486101-14EF-4588-A078-26F85AF1FE34@gmail.com> To: Enji Cooper X-Mailer: Apple Mail (2.3731.700.6) X-Rspamd-Queue-Id: 4RKRW423kPz3TBj X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] On Aug 7, 2023, at 11:29, Enji Cooper wrote: >=20 >=20 >> On Aug 3, 2023, at 10:20 AM, Mark Millard wrote: >>=20 >> .. . >=20 > Hi Mark, > Could you please submit bugs and CC freebsd-testing or another = appropriate mailing list? It looks like there are some Arm64 = architecture specific issues that need to be addressed based on the = limited information I have from these emails. > Do you have DEADLKRES/INVARIANTS/WITNESS compiled into your kernel? If = not, could you please do that? > If that doesn=E2=80=99t give any helpful hints, could you please panic = the kernel and dump some debug info from ddb, e.g., > 1. alltrace > 2. show allchains > 3. show alllocks I tend to submit only once/if I've done the work to establish the problems in snapshots or other such that do not involve my builds. Submitting only based on my builds is a means of last resort for me. Also, when a bunch of issues are showing up in the same time frame, I tend to start with a subset and let others sit for a time until I get to them. There are a bunch pending at this point. I'm more willing to report to the lists based on less information and a longer time frame to having more information, largely in case it prompts others that have related observations or the like. My recent submittals for cortex-A7 (armv7) kyua run related panics are: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D272965 ("armv7 'Alignment Fault' on read panic during udp_input for kyua's sys/netinet6/exthdr:exthdr ; other udp_input related panics") and: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D272966 ("armv7 Kernel page fault with non-sleepable locks held panic during in6ifa_ifwithaddr for kyua's sys/netpfil/pf/killstate:v6; more tests too") An interesting oddity is that, in my somewhat older environment, I do not get the udp_input related panics (272965). I only got those with the snapshot (while trying to gather information to create the other submital [272966]). Michal Meloun has been having me test patches related to these. But I could only effectively test the 272966 cases in the context I have, given that "interesting oddity". (Michal also originally thought the 2 reports were duplicates of each other. But they are not, at least in my builds.) I'll note that the "non-sleepable locks" is more of an identification of context than a cause: it is from part of the code that handles an alignment abort (that shows up in the console output somewhat later), or so I've been told. It is true that I normally run non-debug builds. But my normal build procedure builds both ways and I substitute (install) the relevant debug build (WITNESS and such included) when I get to the point that I'd use it to advantage. My testing of Michal's patches are based on my debug-build context. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Mon Aug 7 20:29:56 2023 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 4RKScD4Q8Fz4mH2D for ; Mon, 7 Aug 2023 20:30:04 +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 4RKScD3ljjz3Z2B; Mon, 7 Aug 2023 20:30:04 +0000 (UTC) (envelope-from dim@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1691440204; 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=wudkPA43XAigxDyWO9DfxFBxiEEKgZg9uwj/hp2GE8Y=; b=jgUAEiJLw+PUxoIg/y12jEhU0fcSBuh1DTk3ww1IXmRGtP2TugyWSI6N1j5aSIwXP+AId8 KgnX9MijePZyzd8tfWCz9eX9J6NTDhw3sbV3p+j0rlnGRFFw4LHSKi0Fp5C+Uk/hrKbPlF CN5B4xxDVmN3eKRprbRkpIveTt4Mq0a+GkaFFbmbsjeCy6d6YfVOrzdBiqT6VCJJOv2s8W 9YljSh3sEFnjLC9A7Kmaoc5Tc2VqPcmPtHAreQoSgbDhTpnW5QWdcdcHJ1V/JlWB3yYtrO MN7Zy+3B+prRg7FjuPnCdECQzLrq0l3B4C+PZb72luiiJRIjdB+rNnTjjUMiDQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1691440204; 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=wudkPA43XAigxDyWO9DfxFBxiEEKgZg9uwj/hp2GE8Y=; b=nNZEddk0UVr+xuCXJnJiA1k3Mt/PQU5xxCiv4yXDyzLiF9kWYIYcerUORnvDT9a0ozBP6y iS1gVk9OKlRIY7SuGrquJ4MD+BaiSf8IQjFHoqZxZF1z9C2VP+dULSXbFSoLlUNH1plNgX jN+O8dc+J25rv4Rq3g+n0Uw5YMLSYjNwaVuhBUM0FleF2J9N+sxDc+9VF7NDhPgTiRz0dq OGkKT42Jr3MXhDhfOUXe8VxQCnIKPPuThRFM5hUEFDzTXJ8gOj19KYXosnBZzlmD9vwS4g KZvNCr2EtBkS99EQ5y360adb7vGi+JP+fJcLal7y1AlPzhfPghheCzE1UFa0Yw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1691440204; a=rsa-sha256; cv=none; b=lPgeEo2nKKguKqcb1HMlIVCSzQ6aK2ilgWh3GeW2JBYlBOQRUqtbA0fGyd9jbtvhKfahx7 mhBk6FpRCuZBxQ4dpgZ6gdMRhSvTWxGq+ZvC36oQf3WNvFHx+d+ntg4JTjGmC4dIgOWUkd k2uYF211TxfQOoXnuCMjp/NRts+D5YV1S0Flk1IL9Oj1grAXOP1N3N9KxQMEVcRoF2Lzri 5jzK6qbmdCJ1fa5SSjberTjuMgjBPOBxtpIlk9KpUUydY9kWXIYB0NLmYShs6wOVQ5mxcR qbipVjlSdrK9EMM82DlaWlhKnR+j8JGTa6p3qah1yAdx4xnhDFd6/EQn8VRa1g== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (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 "tensor.andric.com", Issuer "R3" (verified OK)) (Authenticated sender: dim) by smtp.freebsd.org (Postfix) with ESMTPSA id 4RKScD249Jz1HWb; Mon, 7 Aug 2023 20:30:04 +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 02F1172BE9; Mon, 7 Aug 2023 22:30:03 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_0B45D251-3F23-40A4-BBA5-9912396AF176"; 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 16.0 \(3731.700.6\)) Subject: Re: Jail compile error on CURRENT? From: Dimitry Andric In-Reply-To: <20230806225055.bbccc4fc13e41f50ec524621@j.email.ne.jp> Date: Mon, 7 Aug 2023 22:29:56 +0200 Cc: FreeBSD Current , Jamie Gritton Message-Id: References: <20230806225055.bbccc4fc13e41f50ec524621@j.email.ne.jp> To: Yoshihiro Ota X-Mailer: Apple Mail (2.3731.700.6) --Apple-Mail=_0B45D251-3F23-40A4-BBA5-9912396AF176 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 7 Aug 2023, at 04:50, Yoshihiro Ota wrote: >=20 > Am I the only one seeing this error? > I'm on 12.4-RELEASE amd64 and building CURRENT as of now. >=20 > jaillex.c:2228:43: error: unused parameter 'yyscanner' = [-Werror,-Wunused-parameter] > void *yyalloc (yy_size_t size , yyscan_t yyscanner) > ^ > jaillex.c:2233:58: error: unused parameter 'yyscanner' = [-Werror,-Wunused-parameter] > void *yyrealloc (void * ptr, yy_size_t size , yyscan_t yyscanner) > ^ > jaillex.c:2245:36: error: unused parameter 'yyscanner' = [-Werror,-Wunused-parameter] > void yyfree (void * ptr , yyscan_t yyscanner) > ^ > 6 errors generated. > *** [jaillex.o] Error code 1 >=20 It seems you are not crazy. :) I can reproduce the error, and I think it might be caused by: = https://cgit.freebsd.org/src/commit/?id=3D086e0149ae56641af245ce472e787c2f= 67d3aea5 However, as to why this does not result in an error (or even a warning) on -CURRENT, I have no clue. Maybe in the mean time flex in -CURRENT got updated... -Dimitry --Apple-Mail=_0B45D251-3F23-40A4-BBA5-9912396AF176 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 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCZNFURAAKCRCwXqMKLiCW oyq0AJ0aOStSbYDI0cNBOApjHzc58W/H/wCgupfAeWQ5ef7vmVd6T+TR+Ld7Nso= =8WNl -----END PGP SIGNATURE----- --Apple-Mail=_0B45D251-3F23-40A4-BBA5-9912396AF176-- From nobody Mon Aug 7 20:43:22 2023 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 4RKSw04g8Sz4mJcR for ; Mon, 7 Aug 2023 20:43:44 +0000 (UTC) (envelope-from trashcan@ellael.org) Received: from mx1.enfer-du-nord.net (mx1.enfer-du-nord.net [91.121.41.56]) (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 4RKSvy71Vdz3c69 for ; Mon, 7 Aug 2023 20:43:42 +0000 (UTC) (envelope-from trashcan@ellael.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ellael.org header.s=dkim header.b="a3Zfg/SR"; spf=pass (mx1.freebsd.org: domain of trashcan@ellael.org designates 91.121.41.56 as permitted sender) smtp.mailfrom=trashcan@ellael.org; dmarc=pass (policy=quarantine) header.from=ellael.org Received: from smtpclient.apple (p5b2e5668.dip0.t-ipconnect.de [91.46.86.104]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.enfer-du-nord.net (Postfix) with ESMTPSA id 4RKSvm60VkzFd1 for ; Mon, 7 Aug 2023 22:43:32 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ellael.org; s=dkim; t=1691441012; 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=XKt7Leb1U+JTRAM6Jl7Vo2LURJsVPWMNkai9BGt+1ME=; b=a3Zfg/SRjXwvbR/mSM3s8amYFPQRFMxS5ICZrdfjG1ZUAlFO2j9gCXJwqDywaaa0W4JCs9 tT+7rVgn+tyQsD/8DqozgUgdfoxtAM33Z3zNYKEC5y6UKzw94cr16CXtxsk4hmznCsqEP9 pRETlDk6iMdKxA/TKn4G4RQ/KHufLokX0uH7e9x5bGQjlv1x4h7N81f7gvnq+dQ9GZanGC bg9FHgF48eKnKgaRHdbH19QMk/vgnrvam2f9qxcY1wub53sCLBwAYdw2uQNyqVhBk/L8vU uhJ55kmAj7OL7mtEZ0YHzsYnSmc6b5dMp8f41JI0RV23woe4sc6EhI95fbwWqA== From: Michael Grimm 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 16.0 \(3731.700.6\)) Subject: 14-CURRENT | alternatives for defunct /usr/lib/pam_opie.so? Message-Id: <613E7476-6553-4A74-BF33-EF95D95F25A9@ellael.org> Date: Mon, 7 Aug 2023 22:43:22 +0200 To: freebsd-current@freebsd.org X-Mailer: Apple Mail (2.3731.700.6) X-Spamd-Result: default: False [-2.40 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[ellael.org,quarantine]; R_DKIM_ALLOW(-0.20)[ellael.org:s=dkim]; R_SPF_ALLOW(-0.20)[+ip4:91.121.41.56]; ONCE_RECEIVED(0.10)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:16276, ipnet:91.121.0.0/16, country:FR]; RCVD_TLS_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[ellael.org:+]; RCVD_VIA_SMTP_AUTH(0.00)[] X-Spamd-Bar: -- X-Rspamd-Queue-Id: 4RKSvy71Vdz3c69 Hi, I'm currently in the process to prepare for upcoming 14-STABLE. Thus, I = upgraded one of my sytems from 13-STABLE to 14-CURRENT. Everything went fine, except for programs that need /usr/lib/pam_opie.so = which are: 1) jexec /usr/bin/login -u 2) redis-server 3) mariadb1011-server Error messages: su[6371]: in openpam_load_module(): no pam_opie.so found su[6371]: pam_start: System error Well, although it has been reported some time ago that pam_opie and = pam_opieaccess.so will become removed in Freebsd 14, there is a port = security/opie providing both libraries. Quick workaround. But I want to understand why the above mentioned programs do fail = although not dynamically linked against /usr/lib/pam_opie.so MWN> ldd /usr/bin/login /usr/bin/login: libutil.so.9 =3D> /lib/libutil.so.9 (0xd408ecf7000) libpam.so.6 =3D> /usr/lib/libpam.so.6 (0xd408f6f2000) libbsm.so.3 =3D> /usr/lib/libbsm.so.3 (0xd4090dab000) libc.so.7 =3D> /lib/libc.so.7 (0xd408f99d000) [vdso] (0xd408e18f630) MWN> ldd /usr/local/bin/redis-server /usr/local/bin/redis-server: libthr.so.3 =3D> /lib/libthr.so.3 (0x89a8847f000) libm.so.5 =3D> /lib/libm.so.5 (0x89a87beb000) libexecinfo.so.1 =3D> /usr/lib/libexecinfo.so.1 (0x89a891c7000) libssl.so.30 =3D> /usr/lib/libssl.so.30 (0x89a8a271000) libcrypto.so.30 =3D> /lib/libcrypto.so.30 (0x89a8b02b000) libc.so.7 =3D> /lib/libc.so.7 (0x89a8c7fe000) libelf.so.2 =3D> /lib/libelf.so.2 (0x89a8949b000) libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x89a8bb85000) [vdso] (0x89a87323630) MWN> ldd /usr/local/libexec/mariadbd /usr/local/libexec/mariadbd: libpcre2-8.so.0 =3D> /usr/local/lib/libpcre2-8.so.0 = (0x145ae576f000) libwrap.so.6 =3D> /usr/lib/libwrap.so.6 (0x145ae64a5000) libcrypt.so.5 =3D> /lib/libcrypt.so.5 (0x145ae74be000) libz.so.6 =3D> /lib/libz.so.6 (0x145ae7d0b000) libm.so.5 =3D> /lib/libm.so.5 (0x145ae8b3e000) libexecinfo.so.1 =3D> /usr/lib/libexecinfo.so.1 (0x145ae6e03000) libssl.so.30 =3D> /usr/lib/libssl.so.30 (0x145ae9575000) libcrypto.so.30 =3D> /lib/libcrypto.so.30 (0x145aeafff000) libc++.so.1 =3D> /lib/libc++.so.1 (0x145ae9e3b000) libcxxrt.so.1 =3D> /lib/libcxxrt.so.1 (0x145aeaa85000) libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x145aec745000) libthr.so.3 =3D> /lib/libthr.so.3 (0x145aebf10000) libc.so.7 =3D> /lib/libc.so.7 (0x145aec7fa000) libelf.so.2 =3D> /lib/libelf.so.2 (0x145aee867000) [vdso] (0x145ae5010630) Which alternatives to pam_opie should I investigate? Reason: I want to get rid of security/opie Thanks and regards, Michael From nobody Mon Aug 7 21:37:35 2023 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 4RKV6C2zjJz4mNCK for ; Mon, 7 Aug 2023 21:37:39 +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 4RKV6B337yz4GWC for ; Mon, 7 Aug 2023 21:37:38 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; dkim=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; dmarc=none Received: from kalamity.joker.local (123-1-88-210.area1b.commufa.jp [123.1.88.210]) (authenticated bits=0) by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 377LbZo2012720 for ; Tue, 8 Aug 2023 06:37:35 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Tue, 8 Aug 2023 06:37:35 +0900 From: Tomoaki AOKI To: freebsd-current@freebsd.org Subject: Re: [Intel AlderLake] Read&Write files to FAT32 or UFS partition cause data corrupt due to P-Core&E-Core Message-Id: <20230808063735.e8e1d3ede370a18f200a6f48@dec.sakura.ne.jp> In-Reply-To: References: <5fd2a34e-1135-4237-a028-d4566ff65c69@FreeBSD.org> <20220219115534.7db1b9f199c10894e4280b33@dec.sakura.ne.jp> <7A743668-B5AA-4679-9F56-9A6220CBBC14@karels.net> <59cbcfe2-cd53-69d8-65d6-7a79e656f494@FreeBSD.org> <1f968af1-1c57-9a09-7e01-145a5262e27f@FreeBSD.org> <20230806181238.858f58e25dfd0f99269cfe53@dec.sakura.ne.jp> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.2) 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-Spamd-Result: default: False [0.57 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_SPAM_LONG(0.94)[0.936]; NEURAL_HAM_MEDIUM(-0.86)[-0.862]; MV_CASE(0.50)[]; ONCE_RECEIVED(0.10)[]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[sakura.ne.jp]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; BLOCKLISTDE_FAIL(0.00)[123.1.88.210:server fail,153.125.133.21:server fail]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; HAS_ORG_HEADER(0.00)[]; TO_DN_NONE(0.00)[]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org] X-Spamd-Bar: / X-Rspamd-Queue-Id: 4RKV6B337yz4GWC On Sun, 6 Aug 2023 12:55:07 +0300 Konstantin Belousov wrote: > On Sun, Aug 06, 2023 at 06:12:38PM +0900, Tomoaki AOKI wrote: > > On Wed, 23 Feb 2022 01:30:28 +0200 > > Konstantin Belousov wrote: > > > > > On Tue, Feb 22, 2022 at 06:23:17PM -0500, Alexander Motin wrote: > > > > On 22.02.2022 17:46, Konstantin Belousov wrote: > > > > > Ok, the next step is to get the CPU feature reports from P- vs. E- cores. > > > > > Patch below should work, with verbose boot. > > > > > > > > Not much difference on that level: > > > > > > > > --- zzzp 2022-02-22 18:18:24.531704000 -0500 > > > > +++ zzze 2022-02-22 18:18:18.631236000 -0500 > > > > @@ -1,22 +1,21 @@ > > > > -CPU 2: 12th Gen Intel(R) Core(TM) i7-12700K (3609.60-MHz K8-class CPU) > > > > +CPU 16: 12th Gen Intel(R) Core(TM) i7-12700K (3609.60-MHz K8-class CPU) > > > > Origin="GenuineIntel" Id=0x90672 Family=0x6 Model=0x97 Stepping=2 > > > > Features=0xbfebfbff > > > > Features2=0x7ffafbff > > > > AMD Features=0x2c100800 > > > > AMD Features2=0x121 > > > > Structured Extended Features=0x239ca7eb > > > > Structured Extended Features2=0x98c027ac > > > > Structured Extended Features3=0xfc1cc410 > > > > XSAVE Features=0xf > > > > IA32_ARCH_CAPS=0xd6b > > > > VT-x: Basic Features=0x3da0500 > > > > Pin-Based Controls=0xff > > > > Primary Processor Controls=0xfffbfffe > > > > Secondary Processor Controls=0xf5d7fff > > > > Exit Controls=0x3da0500 > > > > Entry Controls=0x3da0500 > > > > EPT Features=0x6f34141 > > > > VPID Features=0x10f01 > > > > TSC: P-state invariant, performance statistics > > > > -64-Byte prefetching > > > > -L2 cache: 1280 kbytes, 8-way associative, 64 bytes/line > > > > +L2 cache: 2048 kbytes, 16-way associative, 64 bytes/line > > > > > > > > > > Show me the full verbose dmesg of the boot then. > > > > > > As another blind guess, try to disable pcid, vm.pmap.pcid_enabled=0. > > > > > > > Hi. > > > > Intel N100 is reported to crash without this tunable on 13.2 at > > freebsd-users-jp ML (as this is a ML in Japanese, reported in > > Japanese). [1] > > Crashes with UFS, but ZFS is claimed to be OK. > > > > N100 is an Alder Lake-N processor WITHOUT P-CORE. [2] [3] > > So check logics on workarouund codes (IIRC, all are MFC'ed before 13.2) > > wouldn't be working? > > Show me the output from x86info -r on the machine, I do not care which > specific core it is, they should be all the same. x86info is available > as sysutils/x86info. Requested to original reporter and got the result below. HTH. ----------------------- root@eq12:~ # x86info -r x86info v1.31pre /dev/cpuctl0: No such file or directory Found 4 identical CPUs Extended Family: 0 Extended Model: 11 Family: 6 Model: 190 Stepping: 0 Type: 0 (Original OEM) CPU Model (x86info's best guess): Unknown model. eax in: 0x00000000, eax = 00000020 ebx = 756e6547 ecx = 6c65746e edx = 49656e69 eax in: 0x00000001, eax = 000b06e0 ebx = 00800800 ecx = 7ffafbbf edx = bfebfbff eax in: 0x00000002, eax = 00feff01 ebx = 000000f0 ecx = 00000000 edx = 00000000 eax in: 0x00000003, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000 eax in: 0x00000004, eax = fc004121 ebx = 01c0003f ecx = 0000003f edx = 00000000 eax in: 0x00000005, eax = 00000040 ebx = 00000040 ecx = 00000003 edx = 10102020 eax in: 0x00000006, eax = 00578ff7 ebx = 00000002 ecx = 00000009 edx = 00000000 eax in: 0x00000007, eax = 00000002 ebx = 239ca7eb ecx = 98c007bc edx = fc184410 eax in: 0x00000008, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000 eax in: 0x00000009, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000 eax in: 0x0000000a, eax = 07300605 ebx = 00000000 ecx = 00000007 edx = 00008603 eax in: 0x0000000b, eax = 00000001 ebx = 00000001 ecx = 00000100 edx = 00000000 eax in: 0x0000000c, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000 eax in: 0x0000000d, eax = 00000207 ebx = 00000a88 ecx = 00000a88 edx = 00000000 eax in: 0x0000000e, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000 eax in: 0x0000000f, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000 eax in: 0x00000010, eax = 00000000 ebx = 00000004 ecx = 00000000 edx = 00000000 eax in: 0x00000011, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000 eax in: 0x00000012, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000 eax in: 0x00000013, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000 eax in: 0x00000014, eax = 00000001 ebx = 000001ff ecx = 80000007 edx = 00000000 eax in: 0x00000015, eax = 00000002 ebx = 0000002a ecx = 0249f000 edx = 00000000 eax in: 0x00000016, eax = 00000320 ebx = 00000d48 ecx = 00000064 edx = 00000000 eax in: 0x00000017, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000 eax in: 0x00000018, eax = 00000004 ebx = 00000000 ecx = 00000000 edx = 00000000 eax in: 0x00000019, eax = 00000007 ebx = 00000014 ecx = 00000003 edx = 00000000 eax in: 0x0000001a, eax = 20000001 ebx = 00000000 ecx = 00000000 edx = 00000000 eax in: 0x0000001b, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000 eax in: 0x0000001c, eax = c000000b ebx = 00000007 ecx = 00000007 edx = 00000000 eax in: 0x0000001d, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000 eax in: 0x0000001e, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000 eax in: 0x0000001f, eax = 00000001 ebx = 00000001 ecx = 00000100 edx = 00000000 eax in: 0x00000020, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000 eax in: 0x80000000, eax = 80000008 ebx = 00000000 ecx = 00000000 edx = 00000000 eax in: 0x80000001, eax = 00000000 ebx = 00000000 ecx = 00000121 edx = 2c100800 eax in: 0x80000002, eax = 65746e49 ebx = 2952286c ecx = 30314e20 edx = 00000030 eax in: 0x80000003, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000 eax in: 0x80000004, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000 eax in: 0x80000005, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000000 eax in: 0x80000006, eax = 00000000 ebx = 00000000 ecx = 08008040 edx = 00000000 eax in: 0x80000007, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00000100 eax in: 0x80000008, eax = 00003027 ebx = 00000000 ecx = 00000000 edx = 00000000 Total processor threads: 4 This system has 1 dual-core processor with hyper-threading (2 threads per core) running at an estimated 800MHz --------------------- -- Tomoaki AOKI From nobody Mon Aug 7 23:38:36 2023 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 4RKXnw0FFBz4plys for ; Mon, 7 Aug 2023 23:38:44 +0000 (UTC) (envelope-from jamie@freebsd.org) Received: from gritton.org (gritton.org [67.43.236.212]) (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 "gritton.org", Issuer "gritton.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RKXnv4fJSz4W8L; Mon, 7 Aug 2023 23:38:43 +0000 (UTC) (envelope-from jamie@freebsd.org) Authentication-Results: mx1.freebsd.org; none Received: from gritton.org (localgritton [127.0.0.212]) (authenticated bits=0) by gritton.org (8.16.1/8.16.1) with ESMTPA id 377NcaYY099021; Mon, 7 Aug 2023 16:38:36 -0700 (PDT) (envelope-from jamie@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 Date: Mon, 07 Aug 2023 16:38:36 -0700 From: James Gritton To: FreeBSD Current Cc: Yoshihiro Ota , Dimitry Andric Subject: Re: Jail compile error on CURRENT? In-Reply-To: References: <20230806225055.bbccc4fc13e41f50ec524621@j.email.ne.jp> User-Agent: Roundcube Webmail/1.4.11 Message-ID: X-Sender: jamie@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4RKXnv4fJSz4W8L X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36666, ipnet:67.43.224.0/20, country:CA] On 2023-08-07 13:29, Dimitry Andric wrote: > On 7 Aug 2023, at 04:50, Yoshihiro Ota wrote: >> >> Am I the only one seeing this error? >> I'm on 12.4-RELEASE amd64 and building CURRENT as of now. >> >> jaillex.c:2228:43: error: unused parameter 'yyscanner' >> [-Werror,-Wunused-parameter] >> void *yyalloc (yy_size_t size , yyscan_t yyscanner) >> ^ >> jaillex.c:2233:58: error: unused parameter 'yyscanner' >> [-Werror,-Wunused-parameter] >> void *yyrealloc (void * ptr, yy_size_t size , yyscan_t yyscanner) >> ^ >> jaillex.c:2245:36: error: unused parameter 'yyscanner' >> [-Werror,-Wunused-parameter] >> void yyfree (void * ptr , yyscan_t yyscanner) >> ^ >> 6 errors generated. >> *** [jaillex.o] Error code 1 >> > > It seems you are not crazy. :) I can reproduce the error, and I think > it > might be caused by: > > https://cgit.freebsd.org/src/commit/?id=086e0149ae56641af245ce472e787c2f67d3aea5 > > However, as to why this does not result in an error (or even a warning) > on -CURRENT, I have no clue. Maybe in the mean time flex in -CURRENT > got > updated... That is indeed the culprit. Fortunately, it builds from 13.2-RELEASE, so building CURRENT from 12 can be done in two steps. I hate to be the reason the update doesn't work directly, but the include capability I added to jail(8) requires re-entrant lex, which apparently managed to work around the error in 13. They reason it doesn't give a warning BTW is these two lines that lex adds: struct yyguts_t * yyg = (struct yyguts_t*)yyscanner; (void)yyg; That makes yyscanner officially "used" even though its value is never actually read. I suspect the version of lex in 12.4-RELEASE doesn't have one or both of those lines. Perhaps you could add such lines to the offending functions yourself, and continue the make. Or maybe build (and install) lex on its own first; by the time you see this error, there should already be a newer version of lex you could pop into place. There's probably something I should do to make this work better, or perhaps some note I should put into UPDATING before 14.0 is released. - Jamie From nobody Mon Aug 7 23:54:46 2023 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 4RKY8Y0j6Tz4pn4Q for ; Mon, 7 Aug 2023 23:54:53 +0000 (UTC) (envelope-from yuri@aetern.org) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.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 4RKY8X1frvz4Yhj for ; Mon, 7 Aug 2023 23:54:51 +0000 (UTC) (envelope-from yuri@aetern.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=aetern.org header.s=fm3 header.b=EbEx1dCt; dkim=pass header.d=messagingengine.com header.s=fm3 header.b="L RoQTsB"; spf=pass (mx1.freebsd.org: domain of yuri@aetern.org designates 64.147.123.21 as permitted sender) smtp.mailfrom=yuri@aetern.org Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id D856E320077A for ; Mon, 7 Aug 2023 19:54:49 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Mon, 07 Aug 2023 19:54:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aetern.org; h=cc :content-transfer-encoding:content-type:content-type:date:date :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm3; t= 1691452489; x=1691538889; bh=f/VJ2RzPXw0jPZfPBrm8TXI8+GWbi7ZNuzG Xwap3G80=; b=EbEx1dCtSEmqH/vsVfwhUjwpr6Tk3hqHFICQr3eQCrrSG9QwBug gEK+OjLLxBvSjblvSsO28e/Dsvi65BhpoZQESiQd3CiWZYcs6iUU6mBan+/PiENY 11tujxah3qcDlTfPhu6JuR87nrP2sadK+ApQQJ1Qz7FnN+Rrs0ucuO6Vi2s/djS5 pSdoDgL+HqKkNjUSk4FyHQBGhZbmjASVnluWZssOZQ0GSMjdPx9qnGjwck4HnrLc 0oJQ/87EYUlvNXhhS5pDBIq44/omXnAKnmdVEzWtfts2pjqmS8j45gW5fj9nV48g kosO/vBmD6zzzxbcGCE8SQ+5eZIt5e9wdAg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1691452489; x= 1691538889; bh=f/VJ2RzPXw0jPZfPBrm8TXI8+GWbi7ZNuzGXwap3G80=; b=L RoQTsBcOxvMQ5cH37u65Ya9vVAtGnKo9HL/dkDwNs49COHHe6Ar3IT5SsWTdWuRW We1lUnnodWvxXjvYZH8cyZ/srZkxN7YOYgC5Rpy34mtj8haq21jiNCJLNWbuTW1B FDOa632rz566DQOsdCBXdjTx403I+Zlo7s+O7rMzHwCXSJlMRyIPp8beXLI3nvEx YTON4F57wrfYjCuo98AsRIyE/tlrpRk3xEwknOMtsxT3AOoCKi4akXYMP88f7W0O bhhkgQMEVp+yEjqbVpRFAByHQkXuLNTjajuUlnJ7btBCYJmj1ui8/scXIO/j98iV SAaBl3CRr2xWpQSWg8sew== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrledugddviecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepkfffgggfuffvfhfhjggtgfesthekre dttddvjeenucfhrhhomhepjghurhhiuceohihurhhisegrvghtvghrnhdrohhrgheqnecu ggftrfgrthhtvghrnhepteekvefgfeetjeehieefudeivdekudektedufffgjeelhfdtje ekleehvdekuddunecuffhomhgrihhnpehfrhgvvggsshgurdhorhhgnecuvehluhhsthgv rhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhephihurhhisegrvghtvghrnh drohhrgh X-ME-Proxy: Feedback-ID: i0d79475b:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Mon, 7 Aug 2023 19:54:48 -0400 (EDT) Message-ID: <73d081d7-5df6-9fe4-659d-edb191c94be4@aetern.org> Date: Tue, 8 Aug 2023 01:54:46 +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 Thunderbird Subject: Re: Jail compile error on CURRENT? Content-Language: en-US To: freebsd-current@freebsd.org References: <20230806225055.bbccc4fc13e41f50ec524621@j.email.ne.jp> From: Yuri In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4RKY8X1frvz4Yhj X-Spamd-Bar: / X-Rspamd-Pre-Result: action=no action; module=multimap; Matched map: local_wl_from X-Spamd-Result: default: False [0.61 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; R_DKIM_ALLOW(-0.20)[aetern.org:s=fm3,messagingengine.com:s=fm3]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.21]; XM_UA_NO_VERSION(0.01)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; DKIM_TRACE(0.00)[aetern.org:+,messagingengine.com:+]; local_wl_from(0.00)[yuri@aetern.org]; FREEFALL_USER(0.00)[yuri]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US] James Gritton wrote: > On 2023-08-07 13:29, Dimitry Andric wrote: >> On 7 Aug 2023, at 04:50, Yoshihiro Ota wrote: >>> >>> Am I the only one seeing this error? >>> I'm on 12.4-RELEASE amd64 and building CURRENT as of now. >>> >>> jaillex.c:2228:43: error: unused parameter 'yyscanner' >>> [-Werror,-Wunused-parameter] >>> void *yyalloc (yy_size_t  size , yyscan_t yyscanner) >>>                                          ^ >>> jaillex.c:2233:58: error: unused parameter 'yyscanner' >>> [-Werror,-Wunused-parameter] >>> void *yyrealloc  (void * ptr, yy_size_t  size , yyscan_t yyscanner) >>>                                                         ^ >>> jaillex.c:2245:36: error: unused parameter 'yyscanner' >>> [-Werror,-Wunused-parameter] >>> void yyfree (void * ptr , yyscan_t yyscanner) >>>                                   ^ >>> 6 errors generated. >>> *** [jaillex.o] Error code 1 >>> >> >> It seems you are not crazy. :) I can reproduce the error, and I think it >> might be caused by: >> >> https://cgit.freebsd.org/src/commit/?id=086e0149ae56641af245ce472e787c2f67d3aea5 >> >> However, as to why this does not result in an error (or even a warning) >> on -CURRENT, I have no clue. Maybe in the mean time flex in -CURRENT got >> updated... > > That is indeed the culprit.  Fortunately, it builds from 13.2-RELEASE, > so building CURRENT from 12 can be done in two steps.  I hate to be the > reason the update doesn't work directly, but the include capability I > added to jail(8) requires re-entrant lex, which apparently managed to > work around the error in 13.  They reason it doesn't give a warning BTW > is these two lines that lex adds: > >         struct yyguts_t * yyg = (struct yyguts_t*)yyscanner; >         (void)yyg; > > That makes yyscanner officially "used" even though its value is never > actually read.  I suspect the version of lex in 12.4-RELEASE doesn't > have one or both of those lines. > > Perhaps you could add such lines to the offending functions yourself, > and continue the make.  Or maybe build (and install) lex on its own > first; by the time you see this error, there should already be a newer > version of lex you could pop into place. > > There's probably something I should do to make this work better, or > perhaps some note I should put into UPDATING before 14.0 is released. Or there is already a recipe for bootstrapping lex in Makefile.inc1, though for somewhat older versions; possibly it could be updated for < 13? .if ${BOOTSTRAPPING} < 1000033 From nobody Tue Aug 8 02:50:31 2023 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 4RKd3F4trLz4q22r for ; Tue, 8 Aug 2023 02:50:33 +0000 (UTC) (envelope-from roberthuff@rcn.com) Received: from smtp.rcn.com (mail.rcn.syn-alias.com [129.213.13.252]) (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 4RKd3D3F7rz3Hq4 for ; Tue, 8 Aug 2023 02:50:32 +0000 (UTC) (envelope-from roberthuff@rcn.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=rcn.com header.s=20180516 header.b=iLlm17g2; spf=pass (mx1.freebsd.org: domain of roberthuff@rcn.com designates 129.213.13.252 as permitted sender) smtp.mailfrom=roberthuff@rcn.com; dmarc=pass (policy=none) header.from=rcn.com DKIM-Signature: v=1; a=rsa-sha1; d=rcn.com; s=20180516; c=relaxed/simple; q=dns/txt; i=@rcn.com; t=1691463031; h=From:Subject:Date:To:MIME-Version:Content-Type; bh=eBn+9Nxu+EElI8M0FcpkfA2JL9Q=; b=iLlm17g2xVc9r5+zK/2ByxgYvzR3IBLsRUlCIqfeEmLevi2bZQruIOyGVIOvk8jp srYl4O0kNzffE8EEtEWd7OTnDBe7URnOunvgVs/Zix1DMA6O5v6TILz7mxOYr7s8 6m8msyXMvbfrbneqsfeQ7FPh8kFh+7E4Fs+m14B0OZZHrWn0lMcrl0N1WXP/k1TD JEbFKu3bQ6QRIi6lU4/BVZZKI/ODVi48ROknRDnqcS+o+evpjwytq3mM0CJrqOSz JzF0SbC5FLwud1jOVmg+nDCR2/p7qP5LYApgBYvuZ99xZmrga67MY3Otlaq767rg 1OOG7uhQ/HxgzXyJZviMuw==; X-Authed-Username: cm9iZXJ0aHVmZkByY24uY29t Received: from [130.44.151.156] ([130.44.151.156:65509] helo=jerusalem.litteratus.org.litteratus.org) by smtp.rcn.com (envelope-from ) (ecelerity 4.4.0.19839 r(msys-ecelerity:tags/4.4.0.0^0)) with ESMTPSA (cipher=AES256-GCM-SHA384) id 5C/8F-10976-77DA1D46; Mon, 07 Aug 2023 22:50:31 -0400 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 Message-ID: <25809.44407.46566.211065@jerusalem.litteratus.org> Date: Mon, 7 Aug 2023 22:50:31 -0400 From: Robert Huff To: current@freebsd.org CC: Mark Millard Subject: RE: Has the update procedure changed? In-Reply-To: <9E1458A0-606A-42F5-A867-F6672D4CDEE9@yahoo.com> References: <9E1458A0-606A-42F5-A867-F6672D4CDEE9.ref@yahoo.com> <9E1458A0-606A-42F5-A867-F6672D4CDEE9@yahoo.com> X-Mailer: VM 8.2.0b under 28.2 (amd64-portbld-freebsd14.0) X-Vade-Verdict: clean X-Vade-Analysis-1: gggruggvucftvghtrhhoucdtuddrgedviedrledugdeiudcutefuodetggdotefrodftvfcurfhrohhf X-Vade-Analysis-2: ihhlvgemucfujgfpteevqfftpdftvefppdfgpfggqdftvefppdfqfgfvnecuuegrihhlohhuthemucef X-Vade-Analysis-3: tddunecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeggtgfgkfffhffvvefujghf X-Vade-Analysis-4: ofesthejredtredtvdenucfhrhhomheptfhosggvrhhtucfjuhhffhcuoehrohgsvghrthhhuhhffhes X-Vade-Analysis-5: rhgtnhdrtghomheqnecuggftrfgrthhtvghrnhepheduiedvteehueejhffhudevhedthfeukeetudfh X-Vade-Analysis-6: keduveektedvgedvkeeuvddtnecukfhppedufedtrdeggedrudehuddrudehieenucevlhhushhtvghr X-Vade-Analysis-7: ufhiiigvpedtnecurfgrrhgrmhepihhnvghtpedufedtrdeggedrudehuddrudehiedphhgvlhhopehj X-Vade-Analysis-8: vghruhhsrghlvghmrdhlihhtthgvrhgrthhushdrohhrghdrlhhithhtvghrrghtuhhsrdhorhhgpdhm X-Vade-Analysis-9: rghilhhfrhhomheprhhosggvrhhthhhufhhfsehrtghnrdgtohhmpdhrtghpthhtohepmhgrrhhklhhm X-Vade-Analysis-10: iheshigrhhhoohdrtghomhdprhgtphhtthhopegtuhhrrhgvnhhtsehfrhgvvggsshgurdhorhhgpdhm X-Vade-Analysis-11: thgrhhhoshhtpehsmhhtphdtvddrrhgtnhdrvghmrghilhdqrghshhdurdhshihntgdrlhgrnhdpnhgs X-Vade-Analysis-12: pghrtghpthhtohepvddpihhspghnrgepthhruhgvpdgruhhthhgpuhhsvghrpehrohgsvghrthhhuhhf X-Vade-Analysis-13: fh X-Vade-Client: RCN X-Spamd-Result: default: False [-3.00 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.995]; DMARC_POLICY_ALLOW(-0.50)[rcn.com,none]; R_SPF_ALLOW(-0.20)[+ip4:129.213.13.252/32]; R_DKIM_ALLOW(-0.20)[rcn.com:s=20180516]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[current@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:31898, ipnet:129.213.8.0/21, country:US]; MIME_TRACE(0.00)[0:+]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_CC(0.00)[yahoo.com]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[129.213.13.252:from]; TO_DN_SOME(0.00)[]; DKIM_TRACE(0.00)[rcn.com:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_ALL(0.00)[] X-Spamd-Bar: -- X-Rspamd-Queue-Id: 4RKd3D3F7rz3Hq4 Mark Millard writes: > The material in 26.6.5 does not repeat all that, it is > more of a summary that is presented. > > There are also instructions in UPDATING (near the end) > and yet other instructions in Makefile (leading > comments). > > I've not done detailed comparisons of such in some > time, but they well not be exact matches. As I remember, > the UPDATING material was more explicit about various > cases/contexts and what was appropriate for them. > > It can be appropriate to review them all. 1) It would be really nice is someone would take a look and make sure these 100% non-contradictory. 2) If I can only use one of these, which one should I choose? I'm procrastinating on doing a najor update, and want to keep the long record of nothing going Horribly Wrong(tm). Respectfully, Robert Huff From nobody Tue Aug 8 03:32:03 2023 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 4RKdzQ1jZ5z4q4mX for ; Tue, 8 Aug 2023 03:32:18 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (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 4RKdzP6NcXz3MMc for ; Tue, 8 Aug 2023 03:32:17 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lf1-x134.google.com with SMTP id 2adb3069b0e04-4fe0d5f719dso8544780e87.2 for ; Mon, 07 Aug 2023 20:32:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20221208.gappssmtp.com; s=20221208; t=1691465535; x=1692070335; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=HABBHSf709WIgjKGKDSNNbMIwtus8jhTIPUTR6YbJwQ=; b=AfBb+1DMnFGa8PrCYMg2XomYTnxwU/ooP9h8IOatoPyk4RajKFkt1udDfGQKJeoy0/ T7d6ObWRswSBwpPbL2A7sg7h4x39jFE/AvZ28jWAbRsyDDp/DlLNU5RzpfZAeKcy4qec yxqAUBwbgyroZO/k+Px/PtFeQRS70hKT89qSh++/6V1VHjwherSGs//QnYTmH5cBW6Ll Hf3W/sDr89ESG9zWCRiQDP+s/TZw8DzqJHXBpXZz5rMfM0P5/6mEKNcW4LjmXp90oC5T fw3Dfnadwy+2qrt+JhipfqAgLFqwiKRq3PhEjVsLGjJkgo9ihqW9brCOpkF3UumREJeU uTYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691465535; x=1692070335; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=HABBHSf709WIgjKGKDSNNbMIwtus8jhTIPUTR6YbJwQ=; b=kIvYzB5Sm9HFWRabWs/DLtomVLsC9Un/lNXhfc6mBa6PFeYLJHtyJH5246ajgYyzxy e0SJfDdxGMFdmLT3Nwjt7REXmjjJscfxr/6aWMmYXyTJJcmB6cKi2nWFymeqNiqrwIsT Q7rsoQLAH0Wp3ZBIlMN71Vr/yzJ1WTADotEPf9ds7DxBQfvwrsFaPBfAuRIANkOLDgUJ 2YSlbQqiu5HiQf89uDo+b9PrQM+XOJwQAnxFKsR2KwX+ZkU3r0cCQlnXcjzoMi67CItG 8w6+5PZOT4XRLDoCbjNhUfmYkldovK/7HS4WIYT/d3jX6S86Gc5BG+LfSLSnyUuobAdl jLJQ== X-Gm-Message-State: AOJu0YzeGAtdir4A4JT5CUL9L0u3S0WTUIhFwinvrftHxLCe6dphEuap zUdW+6nP1E+QQj8KS2KF3K1TqRBJqsKk6ZfXLMi3hKXwB5dvS9Lh X-Google-Smtp-Source: AGHT+IFLITkzChMAdDRuKQlNnBC2r4bjGZ3EIS4if+kiEBC4PPaQTZ7jX25IoWtqF4CoBC6MiERL0X1vHfYLWEZVUO8= X-Received: by 2002:a05:6512:2821:b0:4fb:bef0:948e with SMTP id cf33-20020a056512282100b004fbbef0948emr8263641lfb.5.1691465535032; Mon, 07 Aug 2023 20:32:15 -0700 (PDT) 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: <20230806225055.bbccc4fc13e41f50ec524621@j.email.ne.jp> <73d081d7-5df6-9fe4-659d-edb191c94be4@aetern.org> In-Reply-To: <73d081d7-5df6-9fe4-659d-edb191c94be4@aetern.org> From: Warner Losh Date: Mon, 7 Aug 2023 21:32:03 -0600 Message-ID: Subject: Re: Jail compile error on CURRENT? To: Yuri Cc: FreeBSD Current Content-Type: multipart/alternative; boundary="0000000000005db60106026102bd" X-Rspamd-Queue-Id: 4RKdzP6NcXz3MMc X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] --0000000000005db60106026102bd Content-Type: text/plain; charset="UTF-8" On Mon, Aug 7, 2023, 5:55 PM Yuri wrote: > James Gritton wrote: > > On 2023-08-07 13:29, Dimitry Andric wrote: > >> On 7 Aug 2023, at 04:50, Yoshihiro Ota wrote: > >>> > >>> Am I the only one seeing this error? > >>> I'm on 12.4-RELEASE amd64 and building CURRENT as of now. > >>> > >>> jaillex.c:2228:43: error: unused parameter 'yyscanner' > >>> [-Werror,-Wunused-parameter] > >>> void *yyalloc (yy_size_t size , yyscan_t yyscanner) > >>> ^ > >>> jaillex.c:2233:58: error: unused parameter 'yyscanner' > >>> [-Werror,-Wunused-parameter] > >>> void *yyrealloc (void * ptr, yy_size_t size , yyscan_t yyscanner) > >>> ^ > >>> jaillex.c:2245:36: error: unused parameter 'yyscanner' > >>> [-Werror,-Wunused-parameter] > >>> void yyfree (void * ptr , yyscan_t yyscanner) > >>> ^ > >>> 6 errors generated. > >>> *** [jaillex.o] Error code 1 > >>> > >> > >> It seems you are not crazy. :) I can reproduce the error, and I think it > >> might be caused by: > >> > >> > https://cgit.freebsd.org/src/commit/?id=086e0149ae56641af245ce472e787c2f67d3aea5 > >> > >> However, as to why this does not result in an error (or even a warning) > >> on -CURRENT, I have no clue. Maybe in the mean time flex in -CURRENT got > >> updated... > > > > That is indeed the culprit. Fortunately, it builds from 13.2-RELEASE, > > so building CURRENT from 12 can be done in two steps. I hate to be the > > reason the update doesn't work directly, but the include capability I > > added to jail(8) requires re-entrant lex, which apparently managed to > > work around the error in 13. They reason it doesn't give a warning BTW > > is these two lines that lex adds: > > > > struct yyguts_t * yyg = (struct yyguts_t*)yyscanner; > > (void)yyg; > > > > That makes yyscanner officially "used" even though its value is never > > actually read. I suspect the version of lex in 12.4-RELEASE doesn't > > have one or both of those lines. > > > > Perhaps you could add such lines to the offending functions yourself, > > and continue the make. Or maybe build (and install) lex on its own > > first; by the time you see this error, there should already be a newer > > version of lex you could pop into place. > > > > There's probably something I should do to make this work better, or > > perhaps some note I should put into UPDATING before 14.0 is released. > > Or there is already a recipe for bootstrapping lex in Makefile.inc1, > though for somewhat older versions; possibly it could be updated for < 13? > > .if ${BOOTSTRAPPING} < 1000033 > When in doubt, adding BOOTSTRAPPING=0 can help...not sure why you'd need to bootstrap lex though... Warner > --0000000000005db60106026102bd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Aug 7, 2023, 5:55 PM Yuri <yuri@aetern.org> wrote:
James Gritton wrote:
> On 2023-08-07 13:29, Dimitry Andric wrote:
>> On 7 Aug 2023, at 04:50, Yoshihiro Ota <ota@j.email.ne.jp>= ; wrote:
>>>
>>> Am I the only one seeing this error?
>>> I'm on 12.4-RELEASE amd64 and building CURRENT as of now.<= br> >>>
>>> jaillex.c:2228:43: error: unused parameter 'yyscanner'=
>>> [-Werror,-Wunused-parameter]
>>> void *yyalloc (yy_size_t=C2=A0 size , yyscan_t yyscanner)
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ^
>>> jaillex.c:2233:58: error: unused parameter 'yyscanner'=
>>> [-Werror,-Wunused-parameter]
>>> void *yyrealloc=C2=A0 (void * ptr, yy_size_t=C2=A0 size , yysc= an_t yyscanner)
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ^
>>> jaillex.c:2245:36: error: unused parameter 'yyscanner'=
>>> [-Werror,-Wunused-parameter]
>>> void yyfree (void * ptr , yyscan_t yyscanner)
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ^
>>> 6 errors generated.
>>> *** [jaillex.o] Error code 1
>>>
>>
>> It seems you are not crazy. :) I can reproduce the error, and I th= ink it
>> might be caused by:
>>
>> https://cgit.freebsd.org/src/commit/?id=3D086e0149ae56641af245ce472e787c2= f67d3aea5
>>
>> However, as to why this does not result in an error (or even a war= ning)
>> on -CURRENT, I have no clue. Maybe in the mean time flex in -CURRE= NT got
>> updated...
>
> That is indeed the culprit.=C2=A0 Fortunately, it builds from 13.2-REL= EASE,
> so building CURRENT from 12 can be done in two steps.=C2=A0 I hate to = be the
> reason the update doesn't work directly, but the include capabilit= y I
> added to jail(8) requires re-entrant lex, which apparently managed to<= br> > work around the error in 13.=C2=A0 They reason it doesn't give a w= arning BTW
> is these two lines that lex adds:
>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 struct yyguts_t * yyg =3D (= struct yyguts_t*)yyscanner;
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (void)yyg;
>
> That makes yyscanner officially "used" even though its value= is never
> actually read.=C2=A0 I suspect the version of lex in 12.4-RELEASE does= n't
> have one or both of those lines.
>
> Perhaps you could add such lines to the offending functions yourself,<= br> > and continue the make.=C2=A0 Or maybe build (and install) lex on its o= wn
> first; by the time you see this error, there should already be a newer=
> version of lex you could pop into place.
>
> There's probably something I should do to make this work better, o= r
> perhaps some note I should put into UPDATING before 14.0 is released.<= br>
Or there is already a recipe for bootstrapping lex in Makefile.inc1,
though for somewhat older versions; possibly it could be updated for < 1= 3?

.if ${BOOTSTRAPPING} < 1000033


When in doubt,= adding BOOTSTRAPPING=3D0 can help...not sure why you'd need to bootstr= ap lex though...

Warner<= /div>
--0000000000005db60106026102bd-- From nobody Tue Aug 8 03:53:37 2023 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 4RKfSN2SF2z4q65f for ; Tue, 8 Aug 2023 03:53:56 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-55.consmr.mail.gq1.yahoo.com (sonic316-55.consmr.mail.gq1.yahoo.com [98.137.69.31]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 4RKfSM5FY6z3PcF for ; Tue, 8 Aug 2023 03:53:55 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1691466833; bh=3KWhp+mE7Ct54SbfxYGndr5kDA38si6hoG3DFVUc72o=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=G2+dNkcwllxRnglb8xsN0Jy6if9v7t/omghnXk1bnnOYyLixQEYezi7yvwmgBm4gYoxCmWmN5u9DjyJS49+Sg0WjTXaPh3hXLKZQ0Hhj5JidKS3CNDHUj8IsLPGAxDCyDQzJK3hFfGaXv76FL3eCpD/eikOHPYFeg760nIyh+XdiKsdM7Dcv/usiA+ZckbsMwnMEob7o4VAW6/o7ySYEnmGt4uXOJeEt+/cs1ZFAcvY9H0Eh2hzdf//t9U545rZc2G0yZQrNTvx1KxwfXcET6+lXMcgEogSKOXYt8HkO/GxatOxnQ1IbJ2gyyVB/r1Y+J1DYhTuJ1NpaC66e8MzZig== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1691466833; bh=Nyg0BvGAto1A24YkuE1IDwwBO5foDAuCcQkVvjcKkj8=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=jX7ENdIDSZk98MAYyoElfXdge2wTqkfObbysp94V86MRHsFC8AyG3Acu+JPb8+I0/mjAinyflkC2m9CJypQnEHF/ygrGxLCnSy9msSs9QaQxZH7UDvBpvKeDtXad4qKHT2FcTU/KSfTz0NH//CNcxVhSQYZ/Qtu266owlDgzyvXjwfVJE9jlQseJrKoRebNhfY+ybg4W+dT6LyzBqNjeB1xCTOn6JDVQDxjIpKnoBZFptafFD2D+yR671Qi7TWOeuAHpmBmtmeOxZzi/iart3oGjyGMx+xJKwPXm7mq6apWsaklOcOp8X9I8IVZU4FWhG2D3tTKeEyPsQ1idSK1iYg== X-YMail-OSG: ealUbkQVM1m7J3kFXv3TNph.RfGzR9.9zBF0Y4RYC8tMa.XwGasIVvUcC6AOnkm 7m1csd7Nc9I_aFaRUvMhLXdm_AabL8m45h2o2vIPbjdKkWpqYKguTHMI6vpPDpn5yliLyCLiSE5P A1wYAYOKf_OUgIzBkVHDmrPtpvBXP4LZezCKOWcqRAxZa3RyJnAMIaach3YENvZkDhqjWjie0a8r 9gvXg35Qg2.Y597SfQrWgdDOY9wx.2f2jIDkOVFBepLCS0Xl3OcMsSM3SI17aUbQQ_6jKZyBBnKQ HkbE36A55cDWrCiiRIG1DvCatUpowuHCsYIdAkTXd7BQEpbfG88o7MNZmoEZ2gTVouyu05k1oAeB g3wT9J9pJSJ0XfTJMqJX.VTvk0jYHq9E_WzeGNXvZipBn9lsPyRCUsXQP9idUrDmi3mmZyKli04U deaHPFsMxppuP0rU4RGI.1BFaf0cFedCGs3ayoEnFkxwmh.1FTQm9bIpHihmBCejqEFlbj.9SefS cv3eEmEWlATYkJYFkUc.bo2xKERaIXeG7XrKQ.mHHdn7cKyfmuCd1NNHjy0IxckLBpqOpYPSKiNw kzeIOeZs63PlZSCDvygRyLEfG2mibkxguFuSHHFv3yutGVbT8wIRoizq..wyxh6iXktewI_.PPUy bGG1XICmZn5yKM10weaL0yuFh5rp1mMUx6UwtDr6hIh87xTGOrkGxVlFx_LtP6GVAOrc36XDLKo6 DUE8nLnVFMR5IQ_N6uUwJSEEKIQKs7lZXYKVQhO6lg7_c6ddETcp5.21E6mQguUOUGOv2Lpb6Szp QeC0xa.rM2EAYLwAkd4uyeLH9RMXOEsuFvKdcagnu879nrFyla7XPkH3pBqr1r3OxoZ7zESp5NI. 19h_7mxNYkshls8fQK2BqPqkIBaOBrMcIkLeI9tAP7MjG_hZ.7ANlRs7JIpdzHmUb7K.turo6_dz ySvyzdDeOK11DJOW5JImkzTbLbuJAHZmjR14jmD1eGDuTACXfwrOZUlvZfemyNgPmVlor7wuxca3 CXBQz7YiOGzO.3Rzfj6yJMGubzF_3g3FzOwvRiLkPMQjrlTtI8kiOin1uEfVRCgCTt9HLGNDKywe ps4oQ0Z22yJCqhFlsj17euEFDsXqF5lDMgD_8RcklNIT2LBnTxyh.K_je.68uvFmNLHFFkpVuhkd c5jdec3EHVR4xuPmDWXSlDZTtCX0CaSyjNRVmir1i_YbKCCVidrYt5Kd3LUe1kbAbK3PQf7LGsTx KOT.wtn9bdNIa1bmtObVKdhA4jphYDa2hsmnqyyCZzeoS6z_HDuKGE7fjZ26q9fKDnhE67jx4Kyf 0o311fRbIkeTAdQc0caZAQiljfu41dqUOfdm7sgglaAcwMq95gvgjiWUW0nE2OQSSdmu74iMDRyB PeEy7oQ1_Oze1OXjA7LrECGpy6s4Pt8vQSVPL9veeUMR0lAu1bv1Ie3KWVU8dHHIfk.7L24tOakL USi4bKGFvE1LoBRkn2.a5mpd_gokP.LIOEeggG8UYB0wGAFEKfAfLQj_OxkXaW6U2gWmki9qA8bP SDKwzhjip8.AZFEloUpb2nI_8thoi8g0jL9vJrFy8hRzqiXBEW5CJ6eknd9dES2vPtkTtTrHRcOn y2EPNjGNitT2xiEDcUxkWRuGt69h8jzOzIspSUZmGpqbICzyd.UKDurHzycjNsh7jL502vrQBNMW 5GvhH7qwcBqI7Prq._7wSsb9tvr40J2ce9fB30b8PtvkHePh9usRBRIzM4PEDWgGtzSOwurRk2Hd rNBRTArJIjSzEdzIb_aNJKdO7O.RoAOaqKjEXAfrQNpw.DhaXfCnGSSnOjJl7Yg3zQOUs_N6KmN6 twvgI35OD2MNY30zb_U2lSxXNeBJn1EFB.NrZPLjjpxZPa8HMgfCZPo9hGFAnVdHAzWdLvZgIjnI jXqtTmD.N2PrTQgD1j1awLp.5ybXPwD5BTprVw8DUvqdmd5nWDtzglQfwe67FzOrj4cDsFHIw.pp H6WCuKUXrDaZtItXKiNy3vdg_bw2SiOKH2uoyu29g36nz5tUW1Sp4EN3l_sFSEwbRIZBY6Vzx7pT uYU1qsNqy8_z515T9NqTh3i4DXKqjnh4CCDkJpNiDIHjG6qtP88YhsB9yvzapzAuORO1AxxRKukt RAY2P2TqRlXKzNPsQEmDifWuflOHQy9deVKo6HuKP7pl7vCgNuHjQPq2l_qqRDYvG1NBVw_m86RE buReo0VL8CIuDU1R7K.kdWodn_T7TrhkR0ir018yZE2OBNUOM7auESay9z.p6pJqK0gRWGubr0nM - X-Sonic-MF: X-Sonic-ID: 785e1619-efda-4c9d-98a6-29c28897098e Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Tue, 8 Aug 2023 03:53:53 +0000 Received: by hermes--production-gq1-6b7c87dcf5-fl46l (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 751be5c8745dcf2751f13478e034795e; Tue, 08 Aug 2023 03:53:48 +0000 (UTC) Content-Type: text/plain; charset=utf-8 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 16.0 \(3731.700.6\)) Subject: Re: Has the update procedure changed? From: Mark Millard In-Reply-To: <25809.44407.46566.211065@jerusalem.litteratus.org> Date: Mon, 7 Aug 2023 20:53:37 -0700 Cc: current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <1C6658DB-ABC2-4930-A479-E17B078FA75F@yahoo.com> References: <9E1458A0-606A-42F5-A867-F6672D4CDEE9.ref@yahoo.com> <9E1458A0-606A-42F5-A867-F6672D4CDEE9@yahoo.com> <25809.44407.46566.211065@jerusalem.litteratus.org> To: Robert Huff X-Mailer: Apple Mail (2.3731.700.6) X-Rspamd-Queue-Id: 4RKfSM5FY6z3PcF X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] On Aug 7, 2023, at 19:50, Robert Huff wrote: > Mark Millard writes: >=20 >> The material in 26.6.5 does not repeat all that, it is >> more of a summary that is presented. >>=20 >> There are also instructions in UPDATING (near the end) >> and yet other instructions in Makefile (leading >> comments). >>=20 >> I've not done detailed comparisons of such in some >> time, but they well not be exact matches. As I remember, >> the UPDATING material was more explicit about various >> cases/contexts and what was appropriate for them. >>=20 >> It can be appropriate to review them all. >=20 > 1) It would be really nice is someone would take a look and make > sure these 100% non-contradictory. To be effective, this may require the additional criteria of being very explicit each time there is a partial listing of commands that summarize only some of the overall steps, the ones involved for the subject(s) in the local subsection but not other steps. The handbook 26.6.5 command lists would be an example. > 2) If I can only use one of these, which one should I choose? The only one that covers a variety of types of contexts is the one in UPDATING, if I remember right. It is hard to avoid referencing that, even if only to figure out which type of context one happens to be interested in for the specific update at hand. I'm not aware of installkernel depending on etcupdate activity, but "man etcupdate" reports, in part: -p Enable =E2=80=9Cpre-world=E2=80=9D mode. Only merge = changes to files that are necessary to successfully run =E2=80=98make = installworld=E2=80=99 or =E2=80=98make installkernel=E2=80=99. . . . To my knowledge not even UPDATING shows etcupdate -p being used before installkernel. "man etcupdate" may be trying to cover potential future updates that could change the status? Still, it looks contradictory. > I'm procrastinating on doing a najor update, and want to keep > the long record of nothing going Horribly Wrong(tm). =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Tue Aug 8 06:38:23 2023 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 4RKk6C1kzzz4TljK; Tue, 8 Aug 2023 06:38:27 +0000 (UTC) (envelope-from grahamperrin@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 4RKk6C1Dynz3c0n; Tue, 8 Aug 2023 06:38:27 +0000 (UTC) (envelope-from grahamperrin@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1691476707; 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=o98qkKZpkLktdJduktmXrrfJKgBiNV9XoC0qZBfs96Y=; b=poos1KgDLAI9xxQn7xsMHYQ1TVLsjtDutG+CAU2ZhQOZdQAOu80ox0WlfVL9FXQgjpcJ6g 1KwdToWvJOBf7gf9BGMBKgUwyVLdMnLffRpnCZR827UBNl8L4/Ght/MUj4YFWBNZseIAv6 JWYTsjd5WE53iHPi6+OJ55yCLBqS0FDmMgH2bOTgmug73kYRMOA5tC74vQOD8IgCDlEwo4 OSAjPXzPYPZngZW6d/Q1Yu14+qQs9LGoO0AHjnmahGgm/ojDEirRJMf6ETcdtq6kapAFNC LuWU1XM9WOzbMeA60rc2wHvmxMaYEmRRrVF7xwaNRMzbS7KZ5ZFpHItEq+dnXw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1691476707; 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=o98qkKZpkLktdJduktmXrrfJKgBiNV9XoC0qZBfs96Y=; b=kCZB+tFAausTAEhuxmL0Hujx342VYHUVwwg8reg39O3LaWadSjJ8UtP+loGsRtkjYNe3zE 9zq+OZ5BuVy+naVYJAwThHbbavNoq7/j7CGnpk5Oh4Os8G6TTf+tvvZFjQRLBYpot+qbq2 sIP6DKxInV1FIyIqGacYE7ErinJgy+sM3qPl1giSEdMTRyoHxoO9gjAWyWXCjo9rnvFsjI /5cF9drgzy2CeADY6BNxQ3rFzNk+dPEdlRkIw2SH4AxbPTW8B/d8kKJa+3uwOPMQszP9JF vszbJ37rhT+68DDiZ60T96TnMxNkGDUZMekY0hpTFlrI8uOCOkATsZ3JV/DiBw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1691476707; a=rsa-sha256; cv=none; b=iqo0etsxz9BsbgyN+dmEhIVY35H7yUP2p6U9j/AxtU8RqYO9BxYYikcIZ3pR0kJtSL8r2l oyy2E0jrx5drkk5wsUZZDMouIM+loVDUG1hU3QkJbQfXFjzzXqSYpKJ/njjtptPR1gvmZC jM1Z8gryWJ8vkrvHVs1RQArNXanG2FlgZbr7eiNjSc7LeiGZ5BozswJcl8gRZrMXql7hpU exgJ27uJdIFkoa1hnOatO63lnYa2WHf1NVzBQGT7FMEXLN8xXIgb7rzGFnlrRQPVg0n1js Ll1I+0fDFm0FYt1gxmRSuLZEwkLkbjKbp+aBcrIQDGt4zd0Kip7kAWpzuB0U7w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from [192.168.1.10] (80-42-66-93.dynamic.dsl.as9105.com [80.42.66.93]) (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 did not present a certificate) (Authenticated sender: grahamperrin) by smtp.freebsd.org (Postfix) with ESMTPSA id 4RKk6B5Zqhzv9; Tue, 8 Aug 2023 06:38:26 +0000 (UTC) (envelope-from grahamperrin@freebsd.org) Message-ID: Date: Tue, 8 Aug 2023 07:38:23 +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:102.0) Gecko/20100101 Thunderbird/102.14.0 Subject: Re: Has the update procedure changed? Content-Language: en-US To: freebsd-current@freebsd.org References: <9E1458A0-606A-42F5-A867-F6672D4CDEE9.ref@yahoo.com> <9E1458A0-606A-42F5-A867-F6672D4CDEE9@yahoo.com> <25809.44407.46566.211065@jerusalem.litteratus.org> Cc: freebsd-doc@freebsd.org From: Graham Perrin Organization: FreeBSD In-Reply-To: <25809.44407.46566.211065@jerusalem.litteratus.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------EZe0CVt6KPp6Kzv2HYYIGQ8j" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------EZe0CVt6KPp6Kzv2HYYIGQ8j Content-Type: multipart/mixed; boundary="------------FFFWBAq03wgX1AWQsuJU63vQ"; protected-headers="v1" From: Graham Perrin To: freebsd-current@freebsd.org Cc: freebsd-doc@freebsd.org Message-ID: Subject: Re: Has the update procedure changed? References: <9E1458A0-606A-42F5-A867-F6672D4CDEE9.ref@yahoo.com> <9E1458A0-606A-42F5-A867-F6672D4CDEE9@yahoo.com> <25809.44407.46566.211065@jerusalem.litteratus.org> In-Reply-To: <25809.44407.46566.211065@jerusalem.litteratus.org> --------------FFFWBAq03wgX1AWQsuJU63vQ Content-Type: multipart/alternative; boundary="------------I0lcZQVmK8eebK8K6jr7vpoQ" --------------I0lcZQVmK8eebK8K6jr7vpoQ Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMDgvMDgvMjAyMyAwMzo1MCwgUm9iZXJ0IEh1ZmYgd3JvdGU6DQoNCj4g4oCmDQo+DQo+ IAkxKSBJdCB3b3VsZCBiZSByZWFsbHkgbmljZSBpcyBzb21lb25lIHdvdWxkIHRha2UgYSBs b29rIGFuZCBtYWtlDQo+IHN1cmUgdGhlc2UgMTAwJSBub24tY29udHJhZGljdG9yeS4NCj4N Cj4g4oCmDQoNCkxvb2tzIGJ5IHBlb3BsZSBzaG91bGQsIGlkZWFsbHksIGluY2x1ZGU6DQoN CjxodHRwczovL2J1Z3MuZnJlZWJzZC5vcmcvYnVnemlsbGEvc2hvd19idWcuY2dpP2lkPTIw OTc0ND4NCjIwOTc0NCDigJMgTW92ZSBpbnN0YWxsYXRpb24gaW5zdHJ1Y3Rpb25zIGZyb20g VVBEQVRJTkcgdG8gbmV3IGZpbGUNCg0KPGh0dHBzOi8vYnVncy5mcmVlYnNkLm9yZy9idWd6 aWxsYS9zaG93X2J1Zy5jZ2k/aWQ9MjU2ODMwPg0KMjU2ODMwIOKAkyB0aGUgQ09NTU9OIElU RU1TOiBzZWN0aW9uIGluIC91c3Ivc3JjL1VQREFUSU5HIG1ha2VzIG5vIG1lbnRpb24gDQpv ZiBldGN1cGRhdGUNCg0K4oCmIHBsdXMgdGhlIGRpc2N1c3Npb24sIHdoaWNoIEkgY2FuJ3Qg ZmluZCAoSSB0aG91Z2h0IGl0IHdhcyBhIEJSKSwgYWJvdXQgDQpkaXNvcmRlcmx5IG51bWJl cmluZzsgYW5kIHNvIG9uLg0KDQo= --------------I0lcZQVmK8eebK8K6jr7vpoQ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 08/08/2023 03:50, Robert Huff wrote:

=E2=80=A6

	1) It would be really nice is someone would take a look and make
sure these 100% non-contradictory.

=E2=80=A6

Looks by people should, ideally, include:

<https://bugs.freebsd.org/bugzill= a/show_bug.cgi?id=3D209744>
209744 =E2=80=93 Move installation instructions from UPDATING to ne= w file

<https://bugs.freebsd.org/bugzill= a/show_bug.cgi?id=3D256830>
256830 =E2=80=93 the COMMON ITEMS: section in /usr/src/UPDATING mak= es no mention of etcupdate

=E2=80=A6 plus the discussion, which I can't find (I thought it was= a BR), about disorderly numbering; and so on.

--------------I0lcZQVmK8eebK8K6jr7vpoQ-- --------------FFFWBAq03wgX1AWQsuJU63vQ-- --------------EZe0CVt6KPp6Kzv2HYYIGQ8j Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEWT/lssMHB+28ly8Kt2dIb0oY1AsFAmTR4t8FAwAAAAAACgkQt2dIb0oY1AvY 7RAAigJ2EA5TYa3M2lIHW5QWn/Lj0Oy/+ZpBPV38Yu6xSbvOlHumjvXhykCU6MJ7d4PQLs44cVay a0cOliGQXHt07xlizLrVLHlerF3IW5uHR8IPJjVvx8snxqYr4FZI+Oh0Y4iXo6FM0i/9jEm7itbZ qPBkrRPKYI2QhjJldYXTq70t6/JHbGY334jkoeMo3uHupqNskYxsH+r5WaxkTMvYZ1yUhuHb+//6 OuWw+fmGewvy/EwYCAb3+eHc5l7B6Qjho9h5Knyb624kthRCeqjQNy/KIwrSEF8KVBhH6ftXNwjO 8POO0swT8XXpV4ymIAqLTaZkhUaztV6bqt9zFLh9yR0wpea4nsLSQevjKnthlFczOSFGO1e70CKZ KJHp6onl2RUZIGYvB2R9liNGLZFPPu9gh37qnPGsC9RwRaxrVY0+qwgimgv8aRpa1cZCXOjXFxyf MexnSsyIoFjJg9wJ9qnIEQOzJwsCpNRh+l24LV0RsPXtM+TEIpO7AQ2H4hy29zokcmi6owcWGeh8 DBw1dYF9oURVbkW0NR29ig1V8Tmv7Y4qSfUiqKnfMxUamajieqHGnle/BDpSXZf3FsU4qeePvdAW 4i+mNOZKX+WCEPCipJ0Xv4HBIIF9wptgXTGlPhRBCqXqWgJuuuToqGnj0shFUpHOMzcfQlHhxmum suw= =CG6z -----END PGP SIGNATURE----- --------------EZe0CVt6KPp6Kzv2HYYIGQ8j-- From nobody Tue Aug 8 06:38:30 2023 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 4RKk6b1CKjz4Tm4T for ; Tue, 8 Aug 2023 06:38:47 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-21.consmr.mail.gq1.yahoo.com (sonic313-21.consmr.mail.gq1.yahoo.com [98.137.65.84]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 4RKk6Z1MJpz3dGF for ; Tue, 8 Aug 2023 06:38:46 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=WNqtkQmo; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1691476724; bh=InHLd7mqaye15edp7EAUuEMIDyk4XBtxrr+nqQnmZCI=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=WNqtkQmoqMWhvYa39908pbHSVSY1T6gW7NhqlETS16S9pBXbFXxU+PSnplt3+WS9N+pPJgTWG4Jr6nXOQeYP0trMi33B2r98ifNkuPPHBlQPz9RpI6/7tYK4A+olrJz4TnBS2MlUgy5UN6kbpDCkFguCpEbJCbuBWHlaZQM+bbwjNsrChBwUN/2yAwdyYj9SU7WnTIur9h/cMtzVXq2AnYBi2OAC1O/ldwpwL6+ygGLjsOs2ozziM5ynJITP6lrDMI2idpe/Y0CqZp11ghUGxBLI28wr+wsgdIVTIC+GfososlAsCn1RnoOZuCaMZFjHy89BTEO5eMtc2Tn5r45DJQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1691476724; bh=nBRutJI/s/29J0oE8NAv4yjzCcht8xmh47vVM03bSnW=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=LyshFxUtNKHXy4DaBIwYurBEvX28/BWB/YTlLF5cjvqhY+slKFDtP1KuMsZqHh9OjC+tsuDiLIp5VN7OBCPFcNRAtzaymL/g9czs+L+bIFj/QPaV2lMFQfQ5NnnHJH5sw7EY+O7XoOZ0cFPW8ec40ptLX/oVv+l315QCeob+ivIDPCNurSc8a3dDHz71oEr2sWn8aqMFXbAT4KTQ2zIWxUc1YdJXqhDIYT2Ip6vwG4ba233Nc4+V3cq8t2f7f+OM+iQqBG+ArY8QEmPPCWxmXCoIcetDnfi8XdA1d2t/3b0h07wtRLb+HacHUinv+NVbnFcOj1HdL9ZA94StutB1RQ== X-YMail-OSG: PoFAXqAVM1k_0uaTZiaUgesTjseXHkgoUnUXGEvvbXMk.AH2jYrRjZ2z9PI.uN0 4D.dbUHLPIJcAOPI2lwxKjeYeyeM_p1DNDhLiOp4xYsr6gXCNL6WdY3PhQHdys5OP7uwMoWMngXI RD18fuVxQNVAZTRbvJ_EqKOhddVP.LpSBpTAhSSp4uJRoDXS0JiryXX3xAR9__u64mVJV5Ve6KBS evM2FPSB_k4T.s1lpl57H1Vt0nexMaHgD1ZKu07KswH4Oz3Y714kzOMlwyOjFFtcCQHAkcbyWlmH tLB6WpfVf5.7v4Xuv1lZR2wLaDG70KFUs2xRo055SqWGfG1nbTZAIMXq9Iwirb25QSXzvRc4U9m. omw7oxN7RrYw95qFcoE2ZTqE4WsHOqpbvsqBcyIYF.byXtdf82AdpYnY6JBmPAFMIwu2tGrtMcDJ tS9dUkFKPDxy_NOeCc4pvBhVyEr42sil9rROB9uYdb61N7g6skbsEyy5mJjBIRATEtKxrP57AIFE NIokNrMK48_s.t7VZxlPOJifU29ndkbpT06ToyYCNvI8PlWyE_fv817B9E6j9yEtxogB16_ZyZTx h7EmQWyItznU5EVBC66oo9NhxdiqQeKDkDff33Bw_nzyLSHhUlzPEg9SrEBVVrqNUPFQ07WP4qCk 0W5Zxdx_YiCo_bwwqsqdEFSDObX14NodyvZ92tzUgXD22dbnksGz_hUZ8PQ5lKWhVj1BmpHnssy0 qmJUwbSmx0QhQm5d_DNFA_nAf6oxQOPjiDsow8Qt4GLE2ZcD0CswcYrK8P1BzOrdWJfFgObrTgyX CzhQ10AhIrNQdro9ALuDuI38OkO0H5Yu7jrnYMg4RRlnjD9zVFnHF8ZO5tX8pX4TLaixEuwuuyBQ aVXxBxVGKrnvK2ritwlmTnn06UfPIsTd78_RT6iHTDmKiaYbrvA42luB4F4tclOb1BP_yimPwVL5 _WL5l6mltqNz9lkQ4sdGUiHQqAqjY9bUWlGkfcJdfV23iySproTkDMnU3sv9iq61hpoG.dbqf9wW 0OViXogNHOcB05RYsNJMNlc_vJclWlDlalUUkvquaUeEF6Ygh2lKoOsHo3qdnsZ3e5vO7uc3U4S7 HTZy8xYamBjcI8kjiEhwP.mQum8BY_4CQSpQa6men7xyuUda56aXBukhc8zb72fA3Az3mt2bRxRn XCfqSh7vJx0jk1qQ5msvf4RXkH57Xq7oQAjhVsUzu.2yFuriAwKXt_riFgqjsA7pt.yYkwMsXlK7 70Shbo4RLqz4hXtBfJJlkPyhB83WX8f1z9AkMumzNPJxT_.w3oNqA2YCt7B4.1sooGRFeG1.NdBc qU2rlErdHJu012FmNVTJgqt2.zyaASOQj5mAv9p6B5C7WsN9hWMFrG69yFzb1X4Xl995aAenoFSp 0_qfs71oQpdVz8RmJOTUbTx7XNyj0Sgxy41utEKPDEGe5Tum_qWb8kAAWVoUaZ9KARMHpInfb7fz bX90d.8G7GqOde8WxUBuJJgc2ck9etn1ExgBIDvn0YECTuP__RpWyqq8Ey555QPWbh102_2PeYzI QbTjuUZb47KEPBL6mUv8dDhvvyw9pp2uyHOs5hKJvF6I4de2atHSPTfwyKNKoggnCUGDaLyrF6uH z4.AACh9RfMqQb07Hso58Nz7xGAlp59SAtBL274P6GkcbnsslWg5OkxJXDwH5QN.D_OQnHQfMXqP 8y0gIfLr9eW_x6wxmfJjWR_uK5ks9tELRJFCRAhblXEZNiHMzgr2YD3O1VOtG9I8WLq6zr26otck Ztdbyu6mKgUD9sV_7gShX_xqceg6k7rGVhN_mhG.5XlhRKQQGGyHP6HpE6oUUxpFo2bfZRbkLDed A1e8IAnZ7ti2wiixje45EH4N3gg7SlRT0nkiSevHmFN3mr2M0WRVZ_GF8KAyIB7csbnDUUQoPRlq wdZSeBqUkouPJU_teLIO2kil773bpuPNAZmg1RJuQlnVw_5iJsYD5thwkENlZxlExa_HmDDujbJG RK0uTYAaHvbGFLIsCyq4RKsC9vGTRGZvWcusRyi7eVw8QcQKfYz.13x_e7XlHht_ib_69iF2rxAE 5d4cYutRok3FTeJ9YbNifsq1p50IJBF9MWbBduMhndfyJZq3LTLSHJaA3MaLvS9QiItmTHdBh2F. RjF6LjFhkgeU4JtNsHyWfxE3OLZoUtA2OCFylCBevVRsI2RaopqAchethEdM01krWGSRUBYNXQN6 O.atizvRkNn0lOdFLyGU2NVxnIDBiBm.i4KD3rdkZTKMfXscKvM0WkSVv21weWa8VT21.yU7uWH5 0 X-Sonic-MF: X-Sonic-ID: 24f77645-b512-4a65-8835-8eb1c6f79617 Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Tue, 8 Aug 2023 06:38:44 +0000 Received: by hermes--production-bf1-865889d799-sjjww (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID e3c17158cb432378ffddf9fdfae0da37; Tue, 08 Aug 2023 06:38:42 +0000 (UTC) From: Mark Millard 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 16.0 \(3731.700.6\)) Subject: RE: 14-CURRENT | alternatives for defunct /usr/lib/pam_opie.so? Message-Id: <2A3D0A54-EE70-47D5-A7AF-E141CC0EE6FE@yahoo.com> Date: Mon, 7 Aug 2023 23:38:30 -0700 To: trashcan@ellael.org, Current FreeBSD X-Mailer: Apple Mail (2.3731.700.6) References: <2A3D0A54-EE70-47D5-A7AF-E141CC0EE6FE.ref@yahoo.com> X-Spamd-Result: default: False [-2.50 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ARC_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.84:from]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.84:from]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_COUNT_TWO(0.00)[2] X-Spamd-Bar: -- X-Rspamd-Queue-Id: 4RKk6Z1MJpz3dGF Michael Grimm wrote on Date: Mon, 07 Aug 2023 20:43:22 UTC : > I'm currently in the process to prepare for upcoming 14-STABLE. Thus, = I upgraded one of my sytems from 13-STABLE to 14-CURRENT. >=20 > Everything went fine, except for programs that need = /usr/lib/pam_opie.so which are: >=20 > 1) jexec /usr/bin/login -u > 2) redis-server > 3) mariadb1011-server >=20 > Error messages: >=20 > su[6371]: in openpam_load_module(): no pam_opie.so found > su[6371]: pam_start: System error >=20 > Well, although it has been reported some time ago that pam_opie and = pam_opieaccess.so will become removed in Freebsd 14, there is a port = security/opie providing both libraries. Quick workaround. >=20 > But I want to understand why the above mentioned programs do fail = although not dynamically linked against /usr/lib/pam_opie.so openpam_load_module leads to dlopen use to open pam_opie.so instead of it being prebound :=20 # grep -r openpam_load_module /usr/main-src/ | more /usr/main-src/contrib/openpam/lib/libpam/openpam_impl.h:pam_module_t = *openpam_load_module(const char *) /usr/main-src/contrib/openpam/lib/libpam/openpam_configure.c: = if ((this->module =3D openpam_load_module(modulename)) =3D=3D NULL) { = /usr/main-src/contrib/openpam/lib/libpam/openpam_load.c:openpam_load_modul= e(const char *modulename) pam_module_t * openpam_load_module(const char *modulename) { pam_module_t *module; module =3D openpam_dynamic(modulename); . . . return (module); } That eventually gets to the likes of: static void * try_dlopen(const char *modfn) { int check_module_file; void *dlh; . . . if ((dlh =3D dlopen(modfn, RTLD_NOW)) =3D=3D NULL) { openpam_log(PAM_LOG_ERROR, "%s: %s", modfn, dlerror()); errno =3D 0; return (NULL); } return (dlh); } Absent that load working, pam_start also reports a failure because of the (pam_module_t *)NULL --or so I assume. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Tue Aug 8 06:45:19 2023 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 4RKkG95HxKz4TmS6 for ; Tue, 8 Aug 2023 06:45:21 +0000 (UTC) (envelope-from grahamperrin@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 4RKkG94nKjz3fqJ for ; Tue, 8 Aug 2023 06:45:21 +0000 (UTC) (envelope-from grahamperrin@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1691477121; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=kcQnK4R69jkvUAhQ0Mupfh+rr7mwFJnQCl5clhwUEtk=; b=BKtsFMbqGnpnEX3OOg1h8IlPkjFDGITZPa8k1tkWDwz/M5rdDdIk72iDDiUyray8+LqCa3 8zY4rTjJVX3nQOjvt4vJU2qNm2IRYO6XCUiq5hT+LYYoPLw+7veDw2uMCz0Fkd6v9xWbbx o8+pm2Qkk3EuTTYhnVvucTWdtdN1jildxwdcIG7fFbo40MQQ5UYkkq/j9V/ejGngTWcB5S OG+30ISQlN3coH/I4C/Asr5bhKmrm8QWXzHJc9u8PM1p5BK0eD81LaHXiPNksz7fMxXNcx IRaLMKA0zmGQOMZ+3HNszmFcyEI0QErwucq8jWQJx5fj2koJGNbk5egE45+Wxw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1691477121; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=kcQnK4R69jkvUAhQ0Mupfh+rr7mwFJnQCl5clhwUEtk=; b=k8Vi2N1qwHghq5Z09pRc9/XERo2V8bQYT+muw+Is3y7RTnlPVEskjV164xvt9KrJgS70Om ocdAaBJDhBAEkbs/WrA1CCA8hrHfSXWYNaGpg5cb9wztsqbE4sXXNT5u8UEjIbBxuOo70b Y2/wjEiKdHzxlba34biVW5sq6DXKvnsZZE44/UTqZ4fUUar1br0DyrCb8hek4v9HKs8xqr rq2FzNuJi1Yox8MmKF9Q7BYcq3Byn14iNQMJEgyiJKzxVWi0x2K2ufo4kY7nBlGgB2tfvv VVb1lbgM7oHXyfm8haNsKiqO5gmY3jKn9xATBHxHnDvbvXpq7cjn0jo8/B7xlQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1691477121; a=rsa-sha256; cv=none; b=uGW32qevD0+6LaqVZ88L6gy1MyLgKMgzA9gZaRixM3tHvFLRInOFycTbf8cIlphuM8bwj1 EMmvKXtEMsVkX6mRWdxrqJ0uSPizrACtg5eY522cFNZFlDhmTblxziO3pCAagytFxXn9RK /R39dj/4A4WShX/CfG26fFMIadngArCO4ejlmwqGEpY6EyTX+7wQBpiQRvbYbYme2IIxD6 bDuraNlNxClvQNWTO7wpRCx6mIrZKNTFRp6TzeNFJiGWWShWG8V+gRbJomJ7JlDbNEMy6S 0PUDEgHT07Wh8nhdn0cemtqTFnUYIQJfdrfbsj/a5TQ1XM8aryplVZcVr6VP7w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from [192.168.1.10] (80-42-66-93.dynamic.dsl.as9105.com [80.42.66.93]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) (Authenticated sender: grahamperrin) by smtp.freebsd.org (Postfix) with ESMTPSA id 4RKkG92bdVz1RSw for ; Tue, 8 Aug 2023 06:45:21 +0000 (UTC) (envelope-from grahamperrin@freebsd.org) Message-ID: Date: Tue, 8 Aug 2023 07:45:19 +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:102.0) Gecko/20100101 Thunderbird/102.14.0 Subject: Re: Has the update procedure changed? Content-Language: en-US To: freebsd-current@freebsd.org References: <9E1458A0-606A-42F5-A867-F6672D4CDEE9.ref@yahoo.com> <9E1458A0-606A-42F5-A867-F6672D4CDEE9@yahoo.com> From: Graham Perrin Organization: FreeBSD In-Reply-To: <9E1458A0-606A-42F5-A867-F6672D4CDEE9@yahoo.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------KS2dVx0jvBrbyr6O00Nyg44Z" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------KS2dVx0jvBrbyr6O00Nyg44Z Content-Type: multipart/mixed; boundary="------------YigHFWTHHYSAU0A4NCNvH57d"; protected-headers="v1" From: Graham Perrin To: freebsd-current@freebsd.org Message-ID: Subject: Re: Has the update procedure changed? References: <9E1458A0-606A-42F5-A867-F6672D4CDEE9.ref@yahoo.com> <9E1458A0-606A-42F5-A867-F6672D4CDEE9@yahoo.com> In-Reply-To: <9E1458A0-606A-42F5-A867-F6672D4CDEE9@yahoo.com> --------------YigHFWTHHYSAU0A4NCNvH57d Content-Type: multipart/alternative; boundary="------------qLhXzpJ8O7JIvwgacvzmY9Qg" --------------qLhXzpJ8O7JIvwgacvzmY9Qg Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMDYvMDgvMjAyMyAwOToyMCwgTWFyayBNaWxsYXJkIHdyb3RlOg0KDQo+IOKApiBodHRw czovL2RvY3MuZnJlZWJzZC5vcmcvZW4vYm9va3MvaGFuZGJvb2svY3V0dGluZy1lZGdlLyNt YWtld29ybGQNCj4gc2VjdGlvbiAyNi42LjEgbGlzdHM6DQo+DQo+ICMgZ2l0IHB1bGwgL3Vz ci9zcmMNCj4gY2hlY2sgL3Vzci9zcmMvVVBEQVRJTkcNCj4gIyBjZCAvdXNyL3NyYw0KPiAj IG1ha2UgLWo0IGJ1aWxkd29ybGQNCj4gIyBtYWtlIC1qNCBrZXJuZWwNCj4gIyBzaHV0ZG93 biAtciBub3cNCj4gIyBldGN1cGRhdGUgLXANCj4gIyBjZCAvdXNyL3NyYw0KPiAjIG1ha2Ug aW5zdGFsbHdvcmxkDQo+ICMgZXRjdXBkYXRlIC1CDQo+ICMgc2h1dGRvd24gLXIgbm93DQo+ DQo+IFRoZSBtYXRlcmlhbCBpbiAyNi42LjUgZG9lcyBub3QgcmVwZWF0IGFsbCB0aGF0LCBp dCBpcw0KPiBtb3JlIG9mIGEgc3VtbWFyeSB0aGF0IGlzIHByZXNlbnRlZC4g4oCmDQoNCklN SE8gYSBzdW1tYXJ5IHNob3VsZCBub3Qgb21pdCBhbnkgc3RlcCB0aGF0IGlzIF9lc3NlbnRp YWxfLg0KDQpldGN1cGRhdGUgLUIgaXMgbm9uLW9wdGlvbmFsLg0KDQoNCg== --------------qLhXzpJ8O7JIvwgacvzmY9Qg Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 06/08/2023 09:20, Mark Millard wrote:

=E2=80=A6

https://docs.freebsd.org/en/books/handbook/cutting-edge/#makeworld
section 26.6.1 lists:

# git pull /usr/src=20
check /usr/src/UPDATING=20
# cd /usr/src=20
# make -j4 buildworld=20
# make -j4 kernel=20
# shutdown -r now=20
# etcupdate -p=20
# cd /usr/src=20
# make installworld=20
# etcupdate -B=20
# shutdown -r now     =20

The material in 26.6.5 does not repeat all that, it is
more of a summary that is presented. =E2=80=A6

IMHO a summary should not omit any step that is _essential_.

etcupdate -B is non-optional.


--------------qLhXzpJ8O7JIvwgacvzmY9Qg-- --------------YigHFWTHHYSAU0A4NCNvH57d-- --------------KS2dVx0jvBrbyr6O00Nyg44Z Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEWT/lssMHB+28ly8Kt2dIb0oY1AsFAmTR5H8FAwAAAAAACgkQt2dIb0oY1Au2 Kg/+K2/C8KguTTDBgjhS2vmP/dJPHt2jyHBdVXXnDjuSFThRlEFAhdQS/EYJlBDyuvGGBJzNBOQo gtVMpm9KD/w9psJ47MUt5A+gV/5l8rPB+WDMuWh/4lYsty392tMMouETtTKlAyBSwReIAA49AnrO 5+iS9L09V7dhkcjdjU+QQ97TNDFF6FeeiQ7hwODmfJX4M4z1ScMEVsNKFBmo5giOrnV8Lc56NXEj A/aRrDRrs5J1Bnm8zAxVXVpbV1Rkzr9pJegKtC3zzJeCOaHpnx6FaWee5nK2nUs1A4AYLHQj0TaE wchxzGLLZ4UYZh+hMRyOFmr71TiQjKrWBgmk4ZU7sW6uRc8fNHm4bypr+CEo71TLpL9WG60YWvz+ C4BiVV6YbWF8etzm/cJWTbHP/x8gEvYyXS0eyTVK+GubXqKDvo+Cf/uMU37knnWli9IHgy+x5Q8/ H7PQQdHTKEp+YAYuAD4SlkLHYAV4AFp5AfLFs3pcsdocAwIdDapbk2w+bVAMabj60Ccb6s6HRlO/ /Sjq9RkDS3jWFcdhVOdjVP5g9lDLxOManAOMvoYxLlOIR8fx+tBWhwHypuJgQBcf03d14fm6zRuS aOC88zETwqRFNBWc1nr83l8A/BNfat2EcwdUxzw7C6ap4XRsDK/rjOzScPrk8ZoiNOcP9Fk+4Gmf iqQ= =HnQ3 -----END PGP SIGNATURE----- --------------KS2dVx0jvBrbyr6O00Nyg44Z-- From nobody Tue Aug 8 09:53:28 2023 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 4RKpRN1sFhz4m5XD for ; Tue, 8 Aug 2023 09:53:36 +0000 (UTC) (envelope-from SRS0=KM5H=DZ=klop.ws=ronald-lists@realworks.nl) Received: from smtp-relay-int-backup.realworks.nl (smtp-relay-int-backup.realworks.nl [87.255.56.188]) (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 4RKpRM68rpz4Rfb for ; Tue, 8 Aug 2023 09:53:35 +0000 (UTC) (envelope-from SRS0=KM5H=DZ=klop.ws=ronald-lists@realworks.nl) Authentication-Results: mx1.freebsd.org; none Received: from rwvirtual372.colo.realworks.nl (rwvirtual372.colo.realworks.nl [10.0.10.72]) by mailrelayint1.colo2.realworks.nl (Postfix) with ESMTP id 4RKpRD4TS7z3wdX; Tue, 8 Aug 2023 11:53:28 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1691488408; 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=LnNejo7UPa4wHZeiTZwU7hMWxnAggHzSK0xt9nDOB64=; b=q/exhqrlP4noEDpg7Zzpkk9Ha/RlMwI9e+PjPMGV6FFtw0BDzPUJh6sadSCkVBavesHFos WN4rA+TjI01R/j9qxN5w7LulcEkzDHhKnsStvKAFYVDsjdvPf08Yany66FOHqcQ/S4TCtd 1yiIUm4GfCofGpzrP3dvO31AFXm3EUUoku3X47VdBiFa1gWerkXsMhT67l+lzVr7iyQXyl 1wQ+tjBKxoyQ/X9NKfhHVmrvXzc9R2GdYbv17oMXyySqrYX/MEyO49LSWlQy4NgT5EJRBR XhRCoZHYP2L+ffWwt5LnHlf3/LTUquavUXf4dFaAm1g3IB2n/L06muSBhpCOhQ== Received: from rwvirtual372.colo.realworks.nl (localhost [127.0.0.1]) by rwvirtual372.colo.realworks.nl (Postfix) with ESMTP id 7167F1C06A8; Tue, 8 Aug 2023 11:53:28 +0200 (CEST) Date: Tue, 8 Aug 2023 11:53:28 +0200 (CEST) From: Ronald Klop To: Michael Grimm Cc: freebsd-current@freebsd.org Message-ID: <1361461519.2835.1691488408412@localhost> In-Reply-To: <613E7476-6553-4A74-BF33-EF95D95F25A9@ellael.org> References: <613E7476-6553-4A74-BF33-EF95D95F25A9@ellael.org> Subject: Re: 14-CURRENT | alternatives for defunct /usr/lib/pam_opie.so? 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_2834_799853935.1691488408382" X-Mailer: Realworks (665.159) X-Originating-Host: from (84-105-120-103.cable.dynamic.v4.ziggo.nl [84.105.120.103]) by rwvirtual372 [10.0.10.72] with HTTP; Tue, 08 Aug 2023 11:53:28 +0200 Importance: Normal X-Priority: 3 (Normal) X-Originating-User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/116.0 X-Rspamd-Queue-Id: 4RKpRM68rpz4Rfb X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:38930, ipnet:87.255.32.0/19, country:NL] ------=_Part_2834_799853935.1691488408382 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Van: Michael Grimm Datum: maandag, 7 augustus 2023 22:43 Aan: freebsd-current@freebsd.org Onderwerp: 14-CURRENT | alternatives for defunct /usr/lib/pam_opie.so? > > Hi, > > I'm currently in the process to prepare for upcoming 14-STABLE. Thus, I upgraded one of my sytems from 13-STABLE to 14-CURRENT. > > Everything went fine, except for programs that need /usr/lib/pam_opie.so which are: > > 1) jexec /usr/bin/login -u > 2) redis-server > 3) mariadb1011-server > > Error messages: > > su[6371]: in openpam_load_module(): no pam_opie.so found > su[6371]: pam_start: System error > > Well, although it has been reported some time ago that pam_opie and pam_opieaccess.so will become removed in Freebsd 14, there is a port security/opie providing both libraries. Quick workaround. > > But I want to understand why the above mentioned programs do fail although not dynamically linked against /usr/lib/pam_opie.so > > MWN> ldd /usr/bin/login > /usr/bin/login: > libutil.so.9 => /lib/libutil.so.9 (0xd408ecf7000) > libpam.so.6 => /usr/lib/libpam.so.6 (0xd408f6f2000) > libbsm.so.3 => /usr/lib/libbsm.so.3 (0xd4090dab000) > libc.so.7 => /lib/libc.so.7 (0xd408f99d000) > [vdso] (0xd408e18f630) > > MWN> ldd /usr/local/bin/redis-server > /usr/local/bin/redis-server: > libthr.so.3 => /lib/libthr.so.3 (0x89a8847f000) > libm.so.5 => /lib/libm.so.5 (0x89a87beb000) > libexecinfo.so.1 => /usr/lib/libexecinfo.so.1 (0x89a891c7000) > libssl.so.30 => /usr/lib/libssl.so.30 (0x89a8a271000) > libcrypto.so.30 => /lib/libcrypto.so.30 (0x89a8b02b000) > libc.so.7 => /lib/libc.so.7 (0x89a8c7fe000) > libelf.so.2 => /lib/libelf.so.2 (0x89a8949b000) > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x89a8bb85000) > [vdso] (0x89a87323630) > > MWN> ldd /usr/local/libexec/mariadbd > /usr/local/libexec/mariadbd: > libpcre2-8.so.0 => /usr/local/lib/libpcre2-8.so.0 (0x145ae576f000) > libwrap.so.6 => /usr/lib/libwrap.so.6 (0x145ae64a5000) > libcrypt.so.5 => /lib/libcrypt.so.5 (0x145ae74be000) > libz.so.6 => /lib/libz.so.6 (0x145ae7d0b000) > libm.so.5 => /lib/libm.so.5 (0x145ae8b3e000) > libexecinfo.so.1 => /usr/lib/libexecinfo.so.1 (0x145ae6e03000) > libssl.so.30 => /usr/lib/libssl.so.30 (0x145ae9575000) > libcrypto.so.30 => /lib/libcrypto.so.30 (0x145aeafff000) > libc++.so.1 => /lib/libc++.so.1 (0x145ae9e3b000) > libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x145aeaa85000) > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x145aec745000) > libthr.so.3 => /lib/libthr.so.3 (0x145aebf10000) > libc.so.7 => /lib/libc.so.7 (0x145aec7fa000) > libelf.so.2 => /lib/libelf.so.2 (0x145aee867000) > [vdso] (0x145ae5010630) > > Which alternatives to pam_opie should I investigate? > Reason: I want to get rid of security/opie > > Thanks and regards, > Michael > > > > > Hi, Might it be possible that pam_opie is still mentioned in a file in /etc/pam.d/* on your machine? An alternative might be https://www.freshports.org/security/pam_google_authenticator See also: https://lists.freebsd.org/archives/freebsd-security/2022-September/000081.html Regards, Ronald. ------=_Part_2834_799853935.1691488408382 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

Van: Michael Grimm <trashcan@ellael.org>
Datum: maandag, 7 augustus 2023 22:43
Aan: freebsd-current@freebsd.org
Onderwerp: 14-CURRENT | alternatives for defunct /usr/lib/pam_opie.so?

Hi,

I'm currently in the process to prepare for upcoming 14-STABLE. Thus, I upgraded one of my sytems from 13-STABLE to 14-CURRENT.

Everything went fine, except for programs that need /usr/lib/pam_opie.so which are:

1) jexec <jailname> /usr/bin/login -u <user>
2) redis-server
3) mariadb1011-server

Error messages:

    su[6371]: in openpam_load_module(): no pam_opie.so found
    su[6371]: pam_start: System error

Well, although it has been reported some time ago that pam_opie and pam_opieaccess.so will become removed in Freebsd 14, there is a port security/opie providing both libraries. Quick workaround.

But I want to understand why the above mentioned programs do fail although not dynamically linked against /usr/lib/pam_opie.so

MWN> ldd /usr/bin/login
    /usr/bin/login:
    libutil.so.9 => /lib/libutil.so.9 (0xd408ecf7000)
    libpam.so.6 => /usr/lib/libpam.so.6 (0xd408f6f2000)
    libbsm.so.3 => /usr/lib/libbsm.so.3 (0xd4090dab000)
    libc.so.7 => /lib/libc.so.7 (0xd408f99d000)
    [vdso] (0xd408e18f630)

MWN> ldd /usr/local/bin/redis-server
    /usr/local/bin/redis-server:
    libthr.so.3 => /lib/libthr.so.3 (0x89a8847f000)
    libm.so.5 => /lib/libm.so.5 (0x89a87beb000)
    libexecinfo.so.1 => /usr/lib/libexecinfo.so.1 (0x89a891c7000)
    libssl.so.30 => /usr/lib/libssl.so.30 (0x89a8a271000)
    libcrypto.so.30 => /lib/libcrypto.so.30 (0x89a8b02b000)
    libc.so.7 => /lib/libc.so.7 (0x89a8c7fe000)
    libelf.so.2 => /lib/libelf.so.2 (0x89a8949b000)
    libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x89a8bb85000)
    [vdso] (0x89a87323630)

MWN> ldd /usr/local/libexec/mariadbd
    /usr/local/libexec/mariadbd:
    libpcre2-8.so.0 => /usr/local/lib/libpcre2-8.so.0 (0x145ae576f000)
    libwrap.so.6 => /usr/lib/libwrap.so.6 (0x145ae64a5000)
    libcrypt.so.5 => /lib/libcrypt.so.5 (0x145ae74be000)
    libz.so.6 => /lib/libz.so.6 (0x145ae7d0b000)
    libm.so.5 => /lib/libm.so.5 (0x145ae8b3e000)
    libexecinfo.so.1 => /usr/lib/libexecinfo.so.1 (0x145ae6e03000)
    libssl.so.30 => /usr/lib/libssl.so.30 (0x145ae9575000)
    libcrypto.so.30 => /lib/libcrypto.so.30 (0x145aeafff000)
    libc++.so.1 => /lib/libc++.so.1 (0x145ae9e3b000)
    libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x145aeaa85000)
    libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x145aec745000)
    libthr.so.3 => /lib/libthr.so.3 (0x145aebf10000)
    libc.so.7 => /lib/libc.so.7 (0x145aec7fa000)
    libelf.so.2 => /lib/libelf.so.2 (0x145aee867000)
    [vdso] (0x145ae5010630)

Which alternatives to pam_opie should I investigate?
Reason: I want to get rid of security/opie

Thanks and regards,
Michael

 


Hi,

Might it be possible that pam_opie is still mentioned in a file in /etc/pam.d/* on your machine?
An alternative might be https://www.freshports.org/security/pam_google_authenticator

See also: https://lists.freebsd.org/archives/freebsd-security/2022-September/000081.html

Regards,
Ronald.
  ------=_Part_2834_799853935.1691488408382-- From nobody Tue Aug 8 12:38:46 2023 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 4RKt6N47p0z4mHk8 for ; Tue, 8 Aug 2023 12:39:08 +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 4RKt6N0Crkz3Dsn for ; Tue, 8 Aug 2023 12:39:07 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.17.1/8.17.1) with ESMTPS id 378Cclbs084298 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 8 Aug 2023 15:38:50 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 378Cclbs084298 Received: (from kostik@localhost) by tom.home (8.17.1/8.17.1/Submit) id 378CckW6084296; Tue, 8 Aug 2023 15:38:46 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 8 Aug 2023 15:38:46 +0300 From: Konstantin Belousov To: Tomoaki AOKI Cc: freebsd-current@freebsd.org Subject: Re: [Intel AlderLake] Read&Write files to FAT32 or UFS partition cause data corrupt due to P-Core&E-Core Message-ID: References: <7A743668-B5AA-4679-9F56-9A6220CBBC14@karels.net> <59cbcfe2-cd53-69d8-65d6-7a79e656f494@FreeBSD.org> <1f968af1-1c57-9a09-7e01-145a5262e27f@FreeBSD.org> <20230806181238.858f58e25dfd0f99269cfe53@dec.sakura.ne.jp> <20230808063735.e8e1d3ede370a18f200a6f48@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: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230808063735.e8e1d3ede370a18f200a6f48@dec.sakura.ne.jp> 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=4.0.0 X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on tom.home X-Rspamd-Queue-Id: 4RKt6N0Crkz3Dsn X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] On Tue, Aug 08, 2023 at 06:37:35AM +0900, Tomoaki AOKI wrote: > On Sun, 6 Aug 2023 12:55:07 +0300 > Konstantin Belousov wrote: > > > On Sun, Aug 06, 2023 at 06:12:38PM +0900, Tomoaki AOKI wrote: > > > On Wed, 23 Feb 2022 01:30:28 +0200 > > > Konstantin Belousov wrote: > > > > > > > On Tue, Feb 22, 2022 at 06:23:17PM -0500, Alexander Motin wrote: > > > > > On 22.02.2022 17:46, Konstantin Belousov wrote: > > > > > > Ok, the next step is to get the CPU feature reports from P- vs. E- cores. > > > > > > Patch below should work, with verbose boot. > > > > > > > > > > Not much difference on that level: > > > > > > > > > > --- zzzp 2022-02-22 18:18:24.531704000 -0500 > > > > > +++ zzze 2022-02-22 18:18:18.631236000 -0500 > > > > > @@ -1,22 +1,21 @@ > > > > > -CPU 2: 12th Gen Intel(R) Core(TM) i7-12700K (3609.60-MHz K8-class CPU) > > > > > +CPU 16: 12th Gen Intel(R) Core(TM) i7-12700K (3609.60-MHz K8-class CPU) > > > > > Origin="GenuineIntel" Id=0x90672 Family=0x6 Model=0x97 Stepping=2 > > > > > Features=0xbfebfbff > > > > > Features2=0x7ffafbff > > > > > AMD Features=0x2c100800 > > > > > AMD Features2=0x121 > > > > > Structured Extended Features=0x239ca7eb > > > > > Structured Extended Features2=0x98c027ac > > > > > Structured Extended Features3=0xfc1cc410 > > > > > XSAVE Features=0xf > > > > > IA32_ARCH_CAPS=0xd6b > > > > > VT-x: Basic Features=0x3da0500 > > > > > Pin-Based Controls=0xff > > > > > Primary Processor Controls=0xfffbfffe > > > > > Secondary Processor Controls=0xf5d7fff > > > > > Exit Controls=0x3da0500 > > > > > Entry Controls=0x3da0500 > > > > > EPT Features=0x6f34141 > > > > > VPID Features=0x10f01 > > > > > TSC: P-state invariant, performance statistics > > > > > -64-Byte prefetching > > > > > -L2 cache: 1280 kbytes, 8-way associative, 64 bytes/line > > > > > +L2 cache: 2048 kbytes, 16-way associative, 64 bytes/line > > > > > > > > > > > > > Show me the full verbose dmesg of the boot then. > > > > > > > > As another blind guess, try to disable pcid, vm.pmap.pcid_enabled=0. > > > > > > > > > > Hi. > > > > > > Intel N100 is reported to crash without this tunable on 13.2 at > > > freebsd-users-jp ML (as this is a ML in Japanese, reported in > > > Japanese). [1] > > > Crashes with UFS, but ZFS is claimed to be OK. > > > > > > N100 is an Alder Lake-N processor WITHOUT P-CORE. [2] [3] > > > So check logics on workarouund codes (IIRC, all are MFC'ed before 13.2) > > > wouldn't be working? > > > > Show me the output from x86info -r on the machine, I do not care which > > specific core it is, they should be all the same. x86info is available > > as sysutils/x86info. > > Requested to original reporter and got the result below. > HTH. > > ----------------------- > root@eq12:~ # x86info -r > x86info v1.31pre > /dev/cpuctl0: No such file or directory > Found 4 identical CPUs > Extended Family: 0 Extended Model: 11 Family: 6 Model: 190 Stepping: 0 > Type: 0 (Original OEM) > CPU Model (x86info's best guess): Unknown model. ... > eax in: 0x0000001a, eax = 20000001 ebx = 00000000 ecx = 00000000 edx = 00000000 The CPU is reported as small core/atom, so the workaround is turned on. I do not think that the issue reported is related to the TLB/PG_G errata. Why do you think that this is hw issue at all, and not some software bug in the build etc ? From nobody Tue Aug 8 13:46:12 2023 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 4RKvbw2K1vz4mN9H for ; Tue, 8 Aug 2023 13:46:20 +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 4RKvbt2R93z3LZF for ; Tue, 8 Aug 2023 13:46:17 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; dkim=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; dmarc=none Received: from kalamity.joker.local (123-1-88-210.area1b.commufa.jp [123.1.88.210]) (authenticated bits=0) by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 378DkC6d034302; Tue, 8 Aug 2023 22:46:13 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Tue, 8 Aug 2023 22:46:12 +0900 From: Tomoaki AOKI To: freebsd-current@freebsd.org Subject: Re: [Intel AlderLake] Read&Write files to FAT32 or UFS partition cause data corrupt due to P-Core&E-Core Message-Id: <20230808224612.c3889d6e20b6fc980f5278cc@dec.sakura.ne.jp> In-Reply-To: References: <7A743668-B5AA-4679-9F56-9A6220CBBC14@karels.net> <59cbcfe2-cd53-69d8-65d6-7a79e656f494@FreeBSD.org> <1f968af1-1c57-9a09-7e01-145a5262e27f@FreeBSD.org> <20230806181238.858f58e25dfd0f99269cfe53@dec.sakura.ne.jp> <20230808063735.e8e1d3ede370a18f200a6f48@dec.sakura.ne.jp> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.2) 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-Spamd-Result: default: False [0.30 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-0.97)[-0.973]; NEURAL_SPAM_SHORT(0.78)[0.778]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; ONCE_RECEIVED(0.10)[]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; R_DKIM_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; HAS_ORG_HEADER(0.00)[]; R_SPF_NA(0.00)[no SPF record]; TO_DN_NONE(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DMARC_NA(0.00)[sakura.ne.jp]; RCVD_VIA_SMTP_AUTH(0.00)[] X-Spamd-Bar: / X-Rspamd-Queue-Id: 4RKvbt2R93z3LZF On Tue, 8 Aug 2023 15:38:46 +0300 Konstantin Belousov wrote: > On Tue, Aug 08, 2023 at 06:37:35AM +0900, Tomoaki AOKI wrote: > > On Sun, 6 Aug 2023 12:55:07 +0300 > > Konstantin Belousov wrote: > > > > > On Sun, Aug 06, 2023 at 06:12:38PM +0900, Tomoaki AOKI wrote: > > > > On Wed, 23 Feb 2022 01:30:28 +0200 > > > > Konstantin Belousov wrote: > > > > > > > > > On Tue, Feb 22, 2022 at 06:23:17PM -0500, Alexander Motin wrote: > > > > > > On 22.02.2022 17:46, Konstantin Belousov wrote: > > > > > > > Ok, the next step is to get the CPU feature reports from P- vs. E- cores. > > > > > > > Patch below should work, with verbose boot. > > > > > > > > > > > > Not much difference on that level: > > > > > > > > > > > > --- zzzp 2022-02-22 18:18:24.531704000 -0500 > > > > > > +++ zzze 2022-02-22 18:18:18.631236000 -0500 > > > > > > @@ -1,22 +1,21 @@ > > > > > > -CPU 2: 12th Gen Intel(R) Core(TM) i7-12700K (3609.60-MHz K8-class CPU) > > > > > > +CPU 16: 12th Gen Intel(R) Core(TM) i7-12700K (3609.60-MHz K8-class CPU) > > > > > > Origin="GenuineIntel" Id=0x90672 Family=0x6 Model=0x97 Stepping=2 > > > > > > Features=0xbfebfbff > > > > > > Features2=0x7ffafbff > > > > > > AMD Features=0x2c100800 > > > > > > AMD Features2=0x121 > > > > > > Structured Extended Features=0x239ca7eb > > > > > > Structured Extended Features2=0x98c027ac > > > > > > Structured Extended Features3=0xfc1cc410 > > > > > > XSAVE Features=0xf > > > > > > IA32_ARCH_CAPS=0xd6b > > > > > > VT-x: Basic Features=0x3da0500 > > > > > > Pin-Based Controls=0xff > > > > > > Primary Processor Controls=0xfffbfffe > > > > > > Secondary Processor Controls=0xf5d7fff > > > > > > Exit Controls=0x3da0500 > > > > > > Entry Controls=0x3da0500 > > > > > > EPT Features=0x6f34141 > > > > > > VPID Features=0x10f01 > > > > > > TSC: P-state invariant, performance statistics > > > > > > -64-Byte prefetching > > > > > > -L2 cache: 1280 kbytes, 8-way associative, 64 bytes/line > > > > > > +L2 cache: 2048 kbytes, 16-way associative, 64 bytes/line > > > > > > > > > > > > > > > > Show me the full verbose dmesg of the boot then. > > > > > > > > > > As another blind guess, try to disable pcid, vm.pmap.pcid_enabled=0. > > > > > > > > > > > > > Hi. > > > > > > > > Intel N100 is reported to crash without this tunable on 13.2 at > > > > freebsd-users-jp ML (as this is a ML in Japanese, reported in > > > > Japanese). [1] > > > > Crashes with UFS, but ZFS is claimed to be OK. > > > > > > > > N100 is an Alder Lake-N processor WITHOUT P-CORE. [2] [3] > > > > So check logics on workarouund codes (IIRC, all are MFC'ed before 13.2) > > > > wouldn't be working? > > > > > > Show me the output from x86info -r on the machine, I do not care which > > > specific core it is, they should be all the same. x86info is available > > > as sysutils/x86info. > > > > Requested to original reporter and got the result below. > > HTH. > > > > ----------------------- > > root@eq12:~ # x86info -r > > x86info v1.31pre > > /dev/cpuctl0: No such file or directory > > Found 4 identical CPUs > > Extended Family: 0 Extended Model: 11 Family: 6 Model: 190 Stepping: 0 > > Type: 0 (Original OEM) > > CPU Model (x86info's best guess): Unknown model. > ... > > eax in: 0x0000001a, eax = 20000001 ebx = 00000000 ecx = 00000000 edx = 00000000 > > The CPU is reported as small core/atom, so the workaround is turned on. > I do not think that the issue reported is related to the TLB/PG_G errata. > > Why do you think that this is hw issue at all, and not some software bug > in the build etc ? Because the issue looks similar (crashes on UFS but not ZFS, and as far as the original reporter tested, vm.pmap.pcid_enabled=0 in /boot/loader.conf helped). Moreover, N100 CPU is Alder Lake-N. So potentially includes the same design issue (common circuits, firmwares, ...). So I suspected the same problem persists even without P-core and adviced the original reporter to add the workaround in /boot/loader.conf. It seems to help until now. -- Tomoaki AOKI From nobody Tue Aug 8 14:02:32 2023 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 4RKvyw0lz5z4mP3t for ; Tue, 8 Aug 2023 14:02:48 +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 4RKvyv5sfwz3Njx for ; Tue, 8 Aug 2023 14:02:47 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.17.1/8.17.1) with ESMTPS id 378E2Wsd005314 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 8 Aug 2023 17:02:35 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 378E2Wsd005314 Received: (from kostik@localhost) by tom.home (8.17.1/8.17.1/Submit) id 378E2WdE005313; Tue, 8 Aug 2023 17:02:32 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 8 Aug 2023 17:02:32 +0300 From: Konstantin Belousov To: Tomoaki AOKI Cc: freebsd-current@freebsd.org Subject: Re: [Intel AlderLake] Read&Write files to FAT32 or UFS partition cause data corrupt due to P-Core&E-Core Message-ID: References: <59cbcfe2-cd53-69d8-65d6-7a79e656f494@FreeBSD.org> <1f968af1-1c57-9a09-7e01-145a5262e27f@FreeBSD.org> <20230806181238.858f58e25dfd0f99269cfe53@dec.sakura.ne.jp> <20230808063735.e8e1d3ede370a18f200a6f48@dec.sakura.ne.jp> <20230808224612.c3889d6e20b6fc980f5278cc@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: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230808224612.c3889d6e20b6fc980f5278cc@dec.sakura.ne.jp> 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=4.0.0 X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on tom.home X-Rspamd-Queue-Id: 4RKvyv5sfwz3Njx X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] On Tue, Aug 08, 2023 at 10:46:12PM +0900, Tomoaki AOKI wrote: > On Tue, 8 Aug 2023 15:38:46 +0300 > Konstantin Belousov wrote: > > > On Tue, Aug 08, 2023 at 06:37:35AM +0900, Tomoaki AOKI wrote: > > > On Sun, 6 Aug 2023 12:55:07 +0300 > > > Konstantin Belousov wrote: > > > > > > > On Sun, Aug 06, 2023 at 06:12:38PM +0900, Tomoaki AOKI wrote: > > > > > On Wed, 23 Feb 2022 01:30:28 +0200 > > > > > Konstantin Belousov wrote: > > > > > > > > > > > On Tue, Feb 22, 2022 at 06:23:17PM -0500, Alexander Motin wrote: > > > > > > > On 22.02.2022 17:46, Konstantin Belousov wrote: > > > > > > > > Ok, the next step is to get the CPU feature reports from P- vs. E- cores. > > > > > > > > Patch below should work, with verbose boot. > > > > > > > > > > > > > > Not much difference on that level: > > > > > > > > > > > > > > --- zzzp 2022-02-22 18:18:24.531704000 -0500 > > > > > > > +++ zzze 2022-02-22 18:18:18.631236000 -0500 > > > > > > > @@ -1,22 +1,21 @@ > > > > > > > -CPU 2: 12th Gen Intel(R) Core(TM) i7-12700K (3609.60-MHz K8-class CPU) > > > > > > > +CPU 16: 12th Gen Intel(R) Core(TM) i7-12700K (3609.60-MHz K8-class CPU) > > > > > > > Origin="GenuineIntel" Id=0x90672 Family=0x6 Model=0x97 Stepping=2 > > > > > > > Features=0xbfebfbff > > > > > > > Features2=0x7ffafbff > > > > > > > AMD Features=0x2c100800 > > > > > > > AMD Features2=0x121 > > > > > > > Structured Extended Features=0x239ca7eb > > > > > > > Structured Extended Features2=0x98c027ac > > > > > > > Structured Extended Features3=0xfc1cc410 > > > > > > > XSAVE Features=0xf > > > > > > > IA32_ARCH_CAPS=0xd6b > > > > > > > VT-x: Basic Features=0x3da0500 > > > > > > > Pin-Based Controls=0xff > > > > > > > Primary Processor Controls=0xfffbfffe > > > > > > > Secondary Processor Controls=0xf5d7fff > > > > > > > Exit Controls=0x3da0500 > > > > > > > Entry Controls=0x3da0500 > > > > > > > EPT Features=0x6f34141 > > > > > > > VPID Features=0x10f01 > > > > > > > TSC: P-state invariant, performance statistics > > > > > > > -64-Byte prefetching > > > > > > > -L2 cache: 1280 kbytes, 8-way associative, 64 bytes/line > > > > > > > +L2 cache: 2048 kbytes, 16-way associative, 64 bytes/line > > > > > > > > > > > > > > > > > > > Show me the full verbose dmesg of the boot then. > > > > > > > > > > > > As another blind guess, try to disable pcid, vm.pmap.pcid_enabled=0. > > > > > > > > > > > > > > > > Hi. > > > > > > > > > > Intel N100 is reported to crash without this tunable on 13.2 at > > > > > freebsd-users-jp ML (as this is a ML in Japanese, reported in > > > > > Japanese). [1] > > > > > Crashes with UFS, but ZFS is claimed to be OK. > > > > > > > > > > N100 is an Alder Lake-N processor WITHOUT P-CORE. [2] [3] > > > > > So check logics on workarouund codes (IIRC, all are MFC'ed before 13.2) > > > > > wouldn't be working? > > > > > > > > Show me the output from x86info -r on the machine, I do not care which > > > > specific core it is, they should be all the same. x86info is available > > > > as sysutils/x86info. > > > > > > Requested to original reporter and got the result below. > > > HTH. > > > > > > ----------------------- > > > root@eq12:~ # x86info -r > > > x86info v1.31pre > > > /dev/cpuctl0: No such file or directory > > > Found 4 identical CPUs > > > Extended Family: 0 Extended Model: 11 Family: 6 Model: 190 Stepping: 0 > > > Type: 0 (Original OEM) > > > CPU Model (x86info's best guess): Unknown model. > > ... > > > eax in: 0x0000001a, eax = 20000001 ebx = 00000000 ecx = 00000000 edx = 00000000 > > > > The CPU is reported as small core/atom, so the workaround is turned on. > > I do not think that the issue reported is related to the TLB/PG_G errata. > > > > Why do you think that this is hw issue at all, and not some software bug > > in the build etc ? > > Because the issue looks similar (crashes on UFS but not ZFS, and as far > as the original reporter tested, vm.pmap.pcid_enabled=0 > in /boot/loader.conf helped). > > Moreover, N100 CPU is Alder Lake-N. So potentially includes the same > design issue (common circuits, firmwares, ...). > > So I suspected the same problem persists even without P-core and > adviced the original reporter to add the workaround > in /boot/loader.conf. > It seems to help until now. The workaround is switched on automatically, when kernel detects 'small cores' reported by CPUID. From nobody Tue Aug 8 14:50:48 2023 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 4RKx2N1xYQz4mS44 for ; Tue, 8 Aug 2023 14:50:52 +0000 (UTC) (envelope-from des@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 4RKx2N1Ssdz3St1; Tue, 8 Aug 2023 14:50:52 +0000 (UTC) (envelope-from des@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1691506252; 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=vfMLgFw4ijUO/4fHBnZ87lizgAIpq9PmjAJ80+aBzOs=; b=LujlkX50Gr8iA/V8/IHnxR/XIGAfReC8j5QDfIcqVLAhjX7mfp0I/Br308sTycVEEDRpEM 4pwoKYfIqBdP63SMA4idZTSHa/07orG2g6gls8tRzY+WC2dxypZTpejDWK/MkAlC9UGZyK jVhuLfego4hiXEa1Gt69fRgGYgbX5m5OQa/ACj0ZuoFN+3z0vOKgnmG2ejsQJKvJvRnmFh DQG/ZBl8GRKV2W5nTtO4LSzOYafEsYAupDD1prLOAXHaZC4qxOIjJ2O8Aa1/fuvGvuIOjF 3KP9/gQ6YXDcGfK90VIpjb6T8fz3a6/17MpwM2fePl1QWjnQ3PQ/BnseOVUY0w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1691506252; 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=vfMLgFw4ijUO/4fHBnZ87lizgAIpq9PmjAJ80+aBzOs=; b=v4u8yMjybd5hfPjWxySaSWKTTqeGMCMiIyeNp4NEsRYIyxCrJXW0qWXX7rmrH0IBWoT4Rq k8O/SSBL2G4k8geT8ZeJI1yLwKebofarnVSNYxYfVjf+ngkykArVzzQaJygrGeNbytN1kR fkQ9FTGbwsDbUmd+NLa8qbbMAEjOpmYbYhVuNKtXvBrCOVbNq6VZXGEvt72ELKcZe1GVdM pO5OG32ZXG8aGRMIAVuLcdLA501c1bpV/PN5/VeUiwhgY7wqm2T9ykLxG8tiZw6Xq6M4ID RuwgX8unXyJ/8GgL22mVAVSQfjaGlFuTxYetVVlLuyNvIPL5vdu4jKZvAsp+fQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1691506252; a=rsa-sha256; cv=none; b=Uzlny6798y4UjRqtI9mKmREyMuze3GYjSd8oP8q+aO7JwFcbAtYvB29xbSCt6T/Judo/sU 4KqO/fy23s3dNIY/MEUo9Obh++29kxnrlKXzm/ig/iebZxcpF0GvFZxhwu1fIzWVxik4Ss gmIJiEjWm3YfVPfgjbl0SocvtgfmCIr+HP1ne/FQO6+dky2mctXXRDGV1qBU1MFyQNTaTP XzeRR2k3jNdmwlrJbqVrTj7VwGJX6PL9rEeCSvvqKrSII9nhhA/6KSgKCPdZA2ZCpbtEhv y8mkt85yzpzlhi/YcqdWwyYTa56Aaca5p5vvLUcvlN9Een8lhoIKtdqUneMitg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from ltc.des.no (unknown [IPv6:2001:4647:d671:0:36e8:94ff:feca:9834]) (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) (Authenticated sender: des) by smtp.freebsd.org (Postfix) with ESMTPSA id 4RKx2M6lcJz8HN; Tue, 8 Aug 2023 14:50:51 +0000 (UTC) (envelope-from des@freebsd.org) Received: by ltc.des.no (Postfix, from userid 1001) id EC2C81809E; Tue, 8 Aug 2023 16:50:48 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Mark Millard Cc: Current FreeBSD Subject: Re: Has the update procedure changed? In-Reply-To: (Matthias Apitz's message of "Sun, 6 Aug 2023 10:54:50 +0200") References: <9E1458A0-606A-42F5-A867-F6672D4CDEE9.ref@yahoo.com> <9E1458A0-606A-42F5-A867-F6672D4CDEE9@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (berkeley-unix) Date: Tue, 08 Aug 2023 16:50:48 +0200 Message-ID: <867cq5h9kn.fsf@ltc.des.no> 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=utf-8 Content-Transfer-Encoding: quoted-printable Matthias Apitz writes: > I know the reason (the install process uses the old existing kldxref whic= h does > not can handle some things). I proceeded with the installation and all > is fine, the box is up again in multiuser and /usr/sbin/kldxref is now > from today. Should I run 'make installkernel' a 2nd time? 'make reinstallkernel' is more appropriate in this case. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@FreeBSD.org From nobody Tue Aug 8 14:56:35 2023 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 4RKx971Tskz4mS5F for ; Tue, 8 Aug 2023 14:56:43 +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 4RKx951fQlz3VMh for ; Tue, 8 Aug 2023 14:56:40 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; dkim=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; dmarc=none Received: from kalamity.joker.local (123-1-88-210.area1b.commufa.jp [123.1.88.210]) (authenticated bits=0) by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 378EuZjG042420; Tue, 8 Aug 2023 23:56:36 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Tue, 8 Aug 2023 23:56:35 +0900 From: Tomoaki AOKI To: freebsd-current@freebsd.org Subject: Re: [Intel AlderLake] Read&Write files to FAT32 or UFS partition cause data corrupt due to P-Core&E-Core Message-Id: <20230808235635.744e0e1c6a72face7fdf6a9b@dec.sakura.ne.jp> In-Reply-To: References: <59cbcfe2-cd53-69d8-65d6-7a79e656f494@FreeBSD.org> <1f968af1-1c57-9a09-7e01-145a5262e27f@FreeBSD.org> <20230806181238.858f58e25dfd0f99269cfe53@dec.sakura.ne.jp> <20230808063735.e8e1d3ede370a18f200a6f48@dec.sakura.ne.jp> <20230808224612.c3889d6e20b6fc980f5278cc@dec.sakura.ne.jp> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.2) 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-Spamd-Result: default: False [-0.06 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-0.97)[-0.974]; MV_CASE(0.50)[]; NEURAL_SPAM_SHORT(0.41)[0.411]; MIME_GOOD(-0.10)[text/plain]; ONCE_RECEIVED(0.10)[]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; R_DKIM_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; HAS_ORG_HEADER(0.00)[]; R_SPF_NA(0.00)[no SPF record]; TO_DN_NONE(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DMARC_NA(0.00)[sakura.ne.jp]; RCVD_VIA_SMTP_AUTH(0.00)[] X-Spamd-Bar: / X-Rspamd-Queue-Id: 4RKx951fQlz3VMh On Tue, 8 Aug 2023 17:02:32 +0300 Konstantin Belousov wrote: > On Tue, Aug 08, 2023 at 10:46:12PM +0900, Tomoaki AOKI wrote: > > On Tue, 8 Aug 2023 15:38:46 +0300 > > Konstantin Belousov wrote: > > > > > On Tue, Aug 08, 2023 at 06:37:35AM +0900, Tomoaki AOKI wrote: > > > > On Sun, 6 Aug 2023 12:55:07 +0300 > > > > Konstantin Belousov wrote: > > > > > > > > > On Sun, Aug 06, 2023 at 06:12:38PM +0900, Tomoaki AOKI wrote: > > > > > > On Wed, 23 Feb 2022 01:30:28 +0200 > > > > > > Konstantin Belousov wrote: > > > > > > > > > > > > > On Tue, Feb 22, 2022 at 06:23:17PM -0500, Alexander Motin wrote: > > > > > > > > On 22.02.2022 17:46, Konstantin Belousov wrote: > > > > > > > > > Ok, the next step is to get the CPU feature reports from P- vs. E- cores. > > > > > > > > > Patch below should work, with verbose boot. > > > > > > > > > > > > > > > > Not much difference on that level: > > > > > > > > > > > > > > > > --- zzzp 2022-02-22 18:18:24.531704000 -0500 > > > > > > > > +++ zzze 2022-02-22 18:18:18.631236000 -0500 > > > > > > > > @@ -1,22 +1,21 @@ > > > > > > > > -CPU 2: 12th Gen Intel(R) Core(TM) i7-12700K (3609.60-MHz K8-class CPU) > > > > > > > > +CPU 16: 12th Gen Intel(R) Core(TM) i7-12700K (3609.60-MHz K8-class CPU) > > > > > > > > Origin="GenuineIntel" Id=0x90672 Family=0x6 Model=0x97 Stepping=2 > > > > > > > > Features=0xbfebfbff > > > > > > > > Features2=0x7ffafbff > > > > > > > > AMD Features=0x2c100800 > > > > > > > > AMD Features2=0x121 > > > > > > > > Structured Extended Features=0x239ca7eb > > > > > > > > Structured Extended Features2=0x98c027ac > > > > > > > > Structured Extended Features3=0xfc1cc410 > > > > > > > > XSAVE Features=0xf > > > > > > > > IA32_ARCH_CAPS=0xd6b > > > > > > > > VT-x: Basic Features=0x3da0500 > > > > > > > > Pin-Based Controls=0xff > > > > > > > > Primary Processor Controls=0xfffbfffe > > > > > > > > Secondary Processor Controls=0xf5d7fff > > > > > > > > Exit Controls=0x3da0500 > > > > > > > > Entry Controls=0x3da0500 > > > > > > > > EPT Features=0x6f34141 > > > > > > > > VPID Features=0x10f01 > > > > > > > > TSC: P-state invariant, performance statistics > > > > > > > > -64-Byte prefetching > > > > > > > > -L2 cache: 1280 kbytes, 8-way associative, 64 bytes/line > > > > > > > > +L2 cache: 2048 kbytes, 16-way associative, 64 bytes/line > > > > > > > > > > > > > > > > > > > > > > Show me the full verbose dmesg of the boot then. > > > > > > > > > > > > > > As another blind guess, try to disable pcid, vm.pmap.pcid_enabled=0. > > > > > > > > > > > > > > > > > > > Hi. > > > > > > > > > > > > Intel N100 is reported to crash without this tunable on 13.2 at > > > > > > freebsd-users-jp ML (as this is a ML in Japanese, reported in > > > > > > Japanese). [1] > > > > > > Crashes with UFS, but ZFS is claimed to be OK. > > > > > > > > > > > > N100 is an Alder Lake-N processor WITHOUT P-CORE. [2] [3] > > > > > > So check logics on workarouund codes (IIRC, all are MFC'ed before 13.2) > > > > > > wouldn't be working? > > > > > > > > > > Show me the output from x86info -r on the machine, I do not care which > > > > > specific core it is, they should be all the same. x86info is available > > > > > as sysutils/x86info. > > > > > > > > Requested to original reporter and got the result below. > > > > HTH. > > > > > > > > ----------------------- > > > > root@eq12:~ # x86info -r > > > > x86info v1.31pre > > > > /dev/cpuctl0: No such file or directory > > > > Found 4 identical CPUs > > > > Extended Family: 0 Extended Model: 11 Family: 6 Model: 190 Stepping: 0 > > > > Type: 0 (Original OEM) > > > > CPU Model (x86info's best guess): Unknown model. > > > ... > > > > eax in: 0x0000001a, eax = 20000001 ebx = 00000000 ecx = 00000000 edx = 00000000 > > > > > > The CPU is reported as small core/atom, so the workaround is turned on. > > > I do not think that the issue reported is related to the TLB/PG_G errata. > > > > > > Why do you think that this is hw issue at all, and not some software bug > > > in the build etc ? > > > > Because the issue looks similar (crashes on UFS but not ZFS, and as far > > as the original reporter tested, vm.pmap.pcid_enabled=0 > > in /boot/loader.conf helped). > > > > Moreover, N100 CPU is Alder Lake-N. So potentially includes the same > > design issue (common circuits, firmwares, ...). > > > > So I suspected the same problem persists even without P-core and > > adviced the original reporter to add the workaround > > in /boot/loader.conf. > > It seems to help until now. > The workaround is switched on automatically, when kernel detects 'small cores' > reported by CPUID. If I read the code correctly, vm.pmap.pcid_invlpg_workaround (precicely, the corresponding variable) is set to non-zero when the workaround is enabled. Not sure it was detected correctly at the original reporter's environment, but forcibly setting the tunable to 1 didn't reported to help sufficiently. Currently, only setting tunable vm.pmap.pcid_enabled to 0 could help. -- Tomoaki AOKI From nobody Tue Aug 8 15:12:49 2023 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 4RKxX60R0Xz4mTbX for ; Tue, 8 Aug 2023 15:13:10 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-54.consmr.mail.gq1.yahoo.com (sonic316-54.consmr.mail.gq1.yahoo.com [98.137.69.30]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 4RKxX461XWz3YMh for ; Tue, 8 Aug 2023 15:13:08 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=k782dqcI; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.30 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1691507584; bh=cPEe178//oREpq2mCcjYymB7uDAjwBEdg3lTMA3/8x0=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=k782dqcIRtC24htnfXxKggEs6eCUm3EmQ2pdSiulYgecVdMQ/N0FJWrxZw5N9DU6FngVvxlzxb4NlSaslaIqiJWTtdMDxmaCo1kua07/DAic53vyQ+7WFe9cxxueWcU6j6rQE4/8Ni1NlvDB/AU7NhYhxvzD4HpUPZIoQjHWrcChmvkQnMFb1rq9ZU8jSgUL7zDmA9mPzolgMy21o1axWdbdBs3kZZ/vEE23BuyZ7bqACb37X6qqtXy36RY+ToAdhI047TcNxbNan5+QU9xkrbF1GrK5nOfhWk+DXcnfP6Q4nHXAjb7+G285XDpE0Icsd+zW+B7SP6w+tZtMCtfvnA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1691507584; bh=AdWevLvm5rTIhiqQ455l+gaOLv4nDqKnajcfYMU7OuX=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=MhGz3qYtsDxJBvAlt4cs5dkd9KqQn31sCWyIFL4G3MIUkdR5R5D07Q26cy9vj8Vq2XaC4KcasA1nO0zMmGU1UHV+0GL/yNsDjzJx3eyhes+4ThY9UYJtvy70AIG3FHvrv1QljcMuLL9xuN9EnINhnHxxM3yl5sxLGDjaLya08WGlmSUNMs49iwLZbLoHuxFowDRz+5mHbV/Bq7Dou48gVVpkDVi7W8OyYEsRmheu8+YM3jonPRQwDhGkE3XOyBzIIIw2s+ZAh+njPjM3Aq0QlrI0+hQctAwuS3mhivePBUnrRvgpSFhxNlZXFKGh3tf3R72VN2IhVdnZy9hdP7PyEw== X-YMail-OSG: WxT0T1EVM1lSYNhwiSfnCsMohuAvYzm6Ju3qXQ4KIZw6vjZDeDgtt1LjP1KPZwE HKJPGzZ7E2QjTPgklZcL1fsDJ6p7Eteca4igVa5tx8QzVCbo6bYqjFV1GNyKcvsYez5MdWUcUdLc y2fRHAwrQPaEvVmRHs2wQgj9B2Y7hM2t3WEgfI6vA6rBimZKz7beWND7h7cmPU9qCayyBEQ9N6dU isvcPuV.HSE5etqjriRS6WIe_yyxJTaqPUz.M.b.1fw1R0zTfZSI47NwMMJ3MsQS4FM6tITcT07z Iqfuxo.q9Znv.oKPn1njGHXxmgNPyP445OOvCzE3BwPMYQ6K35icywHlAPpfs5sp13UDMep9y6nH 3bW_VURJAQfIs5RB1m3Tw1GIQvqWjp0Xq0aXCRnQgh6N9bYvyuNMNUJry8fiJ2J3zMmNbef4lrMI CeWdJoMGOV_dVej9rdceipSRbDBZMCdiqv.tsfHPKGeLrjHcIec4wyuwKbDvVgmxqsz996CQsisY H252lV94.jaRzhI07MJcToAJisewI27AePqP1LSDXSK_9AyzHwHZcfNl9H0cqFDAspVow7lX5fdC Cv1orqx4akm1DHRlPX1ZNxVOPiBg1946tdyJ.0z6NRYfQwDdNJn4cBrrlF8O5qfxuqKPixbFPFRz vdhhkOUbZgSofKNDI5Bfj.H9FjQMaiJkK9mtfIjYSPMcv.yM1pBX58AMvCund6tCmo.OCBHG6CjT OAQGYooTTzdlRP5ncrbAcnqTsW9.t6xwm_nlEm9BuRU2q0GD9n.lB3dylfAg7_4j3q.QqUmB0H3x Tx102DD_YeGmZ.r4_Xgwvg_N5HHMNEo2B16Lb3LkGv6q.CZo6mUV9cglfABrPJeSBB_GyPhMeFmA SfX5UkUSQV2OvHhIFx5BrpnOrM_b3ELJGFW5os.2LkhuIMrNTqnl8mejQ_PgKk3GKORqaRKIfEf3 3SSHQPMIM1paz6Incftogx22bD235XoM3Va3mv_1pMZSHJqp0W3FSNJ93bKETurKRxEYQycPNizi ueTPUQa2mj50U90UeQARaBpWi.VGpco6g9B8.QGXTXnXXVQf_U7I1P7ACtsMhCOQVi3ILq1Qu8bn MbYWPML3iEvsHTwnX9Wehc0IXBdo9ZNePawF37RwyMDgZFVXmKzP16bN4fKDf5V98SrPQDNX5XjC Ww9f8bIV4NqS7_7xnjYAwpcE_hb81kAQJiZ2srCKxVjl0ZwWlsuW2EioMYakXmqa80KdPOAV0VK6 Gzk503HAqIDknIeH0e17503wwkd5iNQ74LpvcqnIPhhsf7DN87eXEALJpn0xJcz3bbjBXxZydefN dx_ZSWU_FuAS.WsiKSu4t0Q2eBE5plz6KlFZEhtjKPx93KNHL8zjyxHdCpldGg6oWrBiScwAnDPS 0SlMHV7mWwQKjBUBcUjfIwp7iEsq435iA42Wm28afu2lRIZQJ2bbYHd9u6asP2lt8KmP_FbakLCA 6bjbwejS5csvjYtRcbSNlBMCUjuOcWTOdDgkQ81OAyjKr5amSl4IuAXZjeB_hVVrWwrmnxl7Bb5i DJYTs7dWzUtAS7m.j4rl8DqQsa0.lkmKDIa9ckKAV77LzFqPKFsSLmOPtS5wYD8.SylXXUofSNYQ CliSy2o2yG2.wfQpGHZsXWSE02ei_82GREynA8mGveHbWRARqP1Pg5a31BOLChhA4BPhSOBumEdA UaTYCuvedB9g47ugEp9.uX280XkDBznT1yrFmszZ_d8FP0bVHf_E.I1Ha82vNYRm3pzryEpnGNUX TTKCEj5KZ3euyEmAsOhtAtw99EGti_kWm7yC_YAwWc86MY3W90jrGhLZucKmoY2kPM8ZqdrFW0cN N_yhqAw.CZzkj8v1zuiOZ9ApwHQZIYM8SfnPb2mwPJVRfSaWMOsFSmBvFqFsOBHfzRNkHWSbA.Ca SxunKiX6lmBq8nker4Hk_iRfUxgiRSPVC4QrjY1CkpFYl6oWCHLy_BBBh5ZvLEzXM.nLotVQIjpf n03SD3Lq5Y40JwlPO893LMGdqKz3Ae5TmeNqyh.lI2USdh0eTFG7zI9pt4iY80cYihYv09_8fljL 1b.cu5nytvn.HhrOeALJFPuYbh8FZ0EUZNMOgfyOB36rI3dLzaevHgCOJfRSMvL6YvG7Yp0k3YMN Uo.TI4BYOoV76OjTJQfBVVTYtV0J.mOO.Ami7r_NFXVuKZ1Kk2S_2.Jzurg5SG0Mxpwe2pGGIUWo 75tn_KerfQ885gfDZ1JTHYTh8m.Tpon6kbiErIKgrPEehVMX4x.7P8lA7biMin2qhuy70IeHz9Q- - X-Sonic-MF: X-Sonic-ID: 6a490aca-348b-408d-81a5-f5f5b0e19a8b Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Tue, 8 Aug 2023 15:13:04 +0000 Received: by hermes--production-bf1-865889d799-g7m4g (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 3f090a9fcaa4b1fe50eff19500b12035; Tue, 08 Aug 2023 15:13:02 +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 16.0 \(3731.700.6\)) Subject: Re: sys/modules/Makefile and MACHINE_ARCH vs arm64 (in use) vs aarch64 (not in use) VS. man arch; also COMPAT_FREEBSD32_ENABLED use From: Mark Millard In-Reply-To: Date: Tue, 8 Aug 2023 08:12:49 -0700 Cc: Current FreeBSD , FreeBSD ARM List Content-Transfer-Encoding: quoted-printable Message-Id: References: <2B0FE8B1-5E53-4E70-9792-15A8E423CA33@yahoo.com> To: Warner Losh X-Mailer: Apple Mail (2.3731.700.6) X-Spamd-Result: default: False [-3.49 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.990]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.30:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.30:from]; DKIM_TRACE(0.00)[yahoo.com:+]; TO_DN_ALL(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_COUNT_TWO(0.00)[2] X-Spamd-Bar: --- X-Rspamd-Queue-Id: 4RKxX461XWz3YMh On Aug 2, 2023, at 17:25, Mark Millard wrote: > On Aug 2, 2023, at 12:56, Mark Millard wrote: >=20 >> On Aug 2, 2023, at 11:16, Warner Losh wrote: >>=20 >>> Those all look wrong to me. >>>=20 >>> Warner=20 >>>=20 >>> On Wed, Aug 2, 2023, 11:27 AM Mark Millard = wrote: >>> man arch reports: >>>=20 >>> MACHINE MACHINE_CPUARCH MACHINE_ARCH >>> arm64 aarch64 aarch64 >>> . . . >>> arm arm armv6, armv7 >>>=20 >>> So I'd not expect arm64 in MACHINE_ARCH . But >>> sys/modules/Makefile has (from a grep for MACHINE_ARCH): >>>=20 >>> .if ${MACHINE_ARCH} =3D=3D "amd64" || ${MACHINE_ARCH} =3D=3D "arm64" >>> .if ${MACHINE_ARCH} =3D=3D "amd64" || ${MACHINE_ARCH} =3D=3D "arm64" = || ${MACHINE_ARCH:Mpowerpc64*} >>>=20 >>>=20 >>> Another issue may be that COMPAT_FREEBSD32_ENABLED is only >>> put to use in the Makefile for MACHINE_CPUARCH being i386 >>> or amd64 : >>>=20 >>> .if ${MACHINE_CPUARCH} =3D=3D "i386" || ${MACHINE_CPUARCH} =3D=3D = "amd64" >>> _agp=3D agp >>> .if ${MACHINE_CPUARCH} =3D=3D "i386" || = !empty(COMPAT_FREEBSD32_ENABLED) >>> . . . >>=20 >>=20 >> I'll note that, for example, i386 vs. armv7 do not match >> for some struct md_ioctl field offsets and the overall >> size. >=20 > Turns out no member offsets were different but the size > was: just differing tail padding in the structure. Still > it means some conditional differences across i386 and > armv7. (I've no clue if the 32-bit powerpc lib32/chroot > handling is working on powerpc64 vs. not. So I make no > claims relative to such.) See: = https://lists.freebsd.org/archives/dev-commits-src-main/2023-August/017561= .html (git: 58a46cfd751a - main - md driver compat32: fix structure padding = for arm, powerpc) for Mike Karels' fix for main for that "turns out". It avoids one kind of kyua run problem for armv7 on aarch64, since mdconfig is used for some of the tests. (The ${MACHINE_ARCH} =3D=3D "arm64" and COMPAT_FREEBSD32_ENABLED use are still as they were in sys/modules/Makefile . This note is not about that issue.) >> Mike Karels is looking at getting struct md_ioctl32 >> correctly matching each of of the contexts: i386, (32-bit) >> powerpc, and armv7. >>=20 >> I do not know if there are other COMPAT_FREEBSD32 adjustments >> needed for differences in memory layout across the 3 (i386, >> powerpc, armv7). md_ioctl I learned about via kyua test runs >> and looking at the background for some things it reported for >> armv7. >>=20 >> I've not found a clear indication of what is expected to work >> for chroot/lib32 vs. what is not expected to work. It seems >> one must look in the code and see if one finds conditional >> material based, in part, on COMPAT_FREEBSD32. It might also >> be that COMPAT_FREEBSD32 for i386 vs. armv7 vs. powerpc >> might not be intending identical coverage for all I know. >> So seeing COMPAT_FREEBSD32 might not be enough to know the >> intent. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Tue Aug 8 15:31:13 2023 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 4RKxx043fcz4mVC2 for ; Tue, 8 Aug 2023 15:31:16 +0000 (UTC) (envelope-from des@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 4RKxx0343Rz3bYm; Tue, 8 Aug 2023 15:31:16 +0000 (UTC) (envelope-from des@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1691508676; 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=UELAfzJPV8nHje/9Mgh5ilGElZb9DsMGNQn6s21MxD8=; b=ejp7nTZAsyqNv2MPmx6k5mI2MMZ6mUHjaWOnDvsakNARxiIpYrdlwjIjRamMP7VbOWCzLt UDybvUfDxZAPE5oMhXPJPfsOvqfqjkVJk3fEID4U7CHrlTD9LixC996lWgTNYUE4qLShX+ LKuVjT+OAMslUQopKbZRpcW45cppayzRHm9y/MDi/VFvaJhJ/JbQUNXh+KKuFsd9zVAHM2 HN0Z1sNb8jgitPfl3KMmyqT4r8NiRoHor70ulopGUnLREyd7yVFhaSTsPm8pzcswL67ej3 NRWTLE1wkUnVybWT0uH5LhnpZlt2D9aXeXaFZ0UInC1fabjN6DaIADbG3CS0ug== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1691508676; 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=UELAfzJPV8nHje/9Mgh5ilGElZb9DsMGNQn6s21MxD8=; b=A9ncHG+DSSD2+XFIPlQRCgEsR1KYwcLwQ+9jGWFTdmBn8SWEuiCQaQM35OLeKCrVEsqZgL V7m9YKVpOoSJO1mdun5RHqB2uW55Kw9UxaNNO3itmMNY7+2EO2oheLkXPd/so4cZfvnFQu kM+9Jj1fUqwNATZnVe/3sHUWp+uAa3s9ns0a6p8/TvUvBomkrxgwPC1C00EivQgUln4Ueu QURKNIM8V2e3T775DUOYCLFAk4CxBWHMbP3SjUHfF3Ao5lrxVJ8R+JAzkeiTOcc91bjE/H Nlrs5ZfOjPFZ0ZEFXPvf2oGk6nnmMeqzY57QehShM0eCHLgcAKRLhShjH48f4A== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1691508676; a=rsa-sha256; cv=none; b=Euubj1R5YGSWL0Uu0SGOfnLzkgu0D7yulZPgegWmpvMKRuFFoidh3YVR40V+dqWNJPknHc LuJy8juX8T1i/Ypj1oz99jjoXvN0xGV/ZWXKtGsj/rNE1cNaJTtnOkyCXVAEAy5+PnzZuR 2Renmyl3thKRJPvFrFjOBmf/I662+N+2l/A3rwH75aWazoZMOceuSIB4kLlGznI9xwSNWa HDnBJwtFwaS0jnQLMkuvXwP9wAvsJ1qTGGUzedzpLF58s6kgdlehTUw6TJcJY0SnP1OQ4+ wcolR0nD9F3N9P4L6cNnMpvh3c2GOzAYcluraNO2+y2WIjr0ZBbwZnPFNDryew== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from ltc.des.no (ti0187a400-1976.bb.online.no [85.166.95.197]) (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) (Authenticated sender: des) by smtp.freebsd.org (Postfix) with ESMTPSA id 4RKxx01HGzz9ql; Tue, 8 Aug 2023 15:31:16 +0000 (UTC) (envelope-from des@freebsd.org) Received: by ltc.des.no (Postfix, from userid 1001) id 12AC9183A0; Tue, 8 Aug 2023 17:31:13 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Michael Grimm Cc: freebsd-current@freebsd.org Subject: Re: 14-CURRENT | alternatives for defunct /usr/lib/pam_opie.so? In-Reply-To: <613E7476-6553-4A74-BF33-EF95D95F25A9@ellael.org> (Michael Grimm's message of "Mon, 7 Aug 2023 22:43:22 +0200") References: <613E7476-6553-4A74-BF33-EF95D95F25A9@ellael.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (berkeley-unix) Date: Tue, 08 Aug 2023 17:31:13 +0200 Message-ID: <86350th7pa.fsf@ltc.des.no> 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=utf-8 Content-Transfer-Encoding: quoted-printable Michael Grimm writes: > I'm currently in the process to prepare for upcoming 14-STABLE. Thus, > I upgraded one of my sytems from 13-STABLE to 14-CURRENT. Did you run etcupdate? DES --=20 Dag-Erling Sm=C3=B8rgrav - des@FreeBSD.org From nobody Tue Aug 8 15:45:46 2023 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 4RKyG460tJz4mWMK for ; Tue, 8 Aug 2023 15:46:04 +0000 (UTC) (envelope-from trashcan@ellael.org) Received: from mx2.enfer-du-nord.net (mx2.enfer-du-nord.net [135.125.211.209]) (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 4RKyG43r38z3d3F; Tue, 8 Aug 2023 15:46:04 +0000 (UTC) (envelope-from trashcan@ellael.org) Authentication-Results: mx1.freebsd.org; none Received: from smtpclient.apple (p5b2e5964.dip0.t-ipconnect.de [91.46.89.100]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx2.enfer-du-nord.net (Postfix) with ESMTPSA id 4RKyFw62Ltz10s7; Tue, 8 Aug 2023 17:45:56 +0200 (CEST) Content-Type: text/plain; charset=utf-8 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 16.0 \(3731.700.6\)) Subject: [SOLVED] 14-CURRENT | alternatives for defunct /usr/lib/pam_opie.so? From: Michael Grimm In-Reply-To: <86350th7pa.fsf@ltc.des.no> Date: Tue, 8 Aug 2023 17:45:46 +0200 Cc: freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <5CD088DD-701D-49CC-8DAD-5E827D03EF87@ellael.org> References: <613E7476-6553-4A74-BF33-EF95D95F25A9@ellael.org> <86350th7pa.fsf@ltc.des.no> To: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= X-Mailer: Apple Mail (2.3731.700.6) X-Rspamd-Queue-Id: 4RKyG43r38z3d3F X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16276, ipnet:135.125.128.0/17, country:FR] Dag-Erling Sm=C3=B8rgrav wrote: > Michael Grimm writes: >> I'm currently in the process to prepare for upcoming 14-STABLE. Thus, >> I upgraded one of my sytems from 13-STABLE to 14-CURRENT. >=20 > Did you run etcupdate? I was just about to report that I somehow managed to "solve" this issue = with pam_opie, but not knowing how. Yep, I did run etcupdate, but not before reporting my issue. This = morning I did reinstall world, kernel and all my ports and ran etcupdate = on host and in all my ports. Removing security/opie afterwards and = everything is fine now. Sorry for the noise, I should have known better! Regards and thanks to all, Michael= From nobody Tue Aug 8 17:07:48 2023 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 4RL04R1WMGz4pq78 for ; Tue, 8 Aug 2023 17:07:51 +0000 (UTC) (envelope-from des@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 4RL04R1DmSz4LG1 for ; Tue, 8 Aug 2023 17:07:51 +0000 (UTC) (envelope-from des@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1691514471; 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=ST0NIr/BzGaY7uGLBMzylD3vPeR83sKh1yocTV/vsLU=; b=wk+w/DCCapVJzvPj+OX+wa+ct23tCi4hILFyC2srORjitydP4/Rj3s2ORo5P/Irhdqs1R3 RZM6l27DsSAhQZADjrm0GOYoaEiBHPybHBfmCOjLVYDvdrmLlS1daScDpYC0wCKiXjKW7k QVt+qtH4ri3TDTenudrqARpAgDaEXWNEKfXNwTwid2nqEeA3gx2KQg+Xht1oQT7L+lhxUF g3CIeiQHZ3eSkGoqK9P+1e1tUT6NM6GM5OxjPRD0ZUYPg5pLdM78TNJfOt3eElI74Kmm+k zWCv/nIyx4/9KRMLg+1FjwXX/K7ofZ6PYxVGh2RyXKXOaVfkasKBd0ERAuOnBg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1691514471; 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=ST0NIr/BzGaY7uGLBMzylD3vPeR83sKh1yocTV/vsLU=; b=iR0yaV/ZJO/NGXgEcEQy7K/2CJD4oQ9zqr6Xfti/49e6t7Vg7hVBgEjjwG5qf/8aVlf5zu kLVNTvyLWH4yHIKQ42RPFLlS7Q5JJU6WaworbXE55JCYQG3Pf7hp6XYqDs5TgO+6QessxW Wb3gUO+GX+JGTjF0MltCMn2XQ/weMNvF2nsyRAkdIjgYiJtdCR1ft+XSM3WnmQG1EgwiEz 74Z/ZKpHFlBR0K5NpikxTXXUimW754fVeuufx/Pt7hmfAtVUKAJhe5t6no9uuEGRO1W54B cUAtDGnEfzvHvuK5s3WuUHBog0rhIzuXTUkHQaUzfjryRUA79K+sOMzWycOvtg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1691514471; a=rsa-sha256; cv=none; b=lX6+axqeIGqWJhqAk/hKTEkhx6J0oFKTTOqe7Bso1NNGD+rCHoXe1qqqrtZRo2IhD4Mr2B t2E5OKerYeCwTSWCXwpNQRFDQl2gjWVtRqOqlTjDM6zkiZ1kie9Lsva0HAt5r1FvS/k4+B 6b83+ZBo9pWMgv7zM1ZdsFtkSBB63o5oReEvED+8DUeSIkEgzDCR2/+ivRXEjQaQsAohbP TLenh/ahGCVOr/1biJ0nGiTmx/TUQjgfHWCc6bl7y9zhniBd0Yf1UyMBuEE5jpj3pF4GDj qpLsuWWoodwITVawyDLAph6RdUdlPhxvtFawWsydhi34NsUMpBkr74qQVjTbXA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from ltc.des.no (unknown [IPv6:2001:4647:d671:0:36e8:94ff:feca:9834]) (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) (Authenticated sender: des) by smtp.freebsd.org (Postfix) with ESMTPSA id 4RL04Q55NmzBsl for ; Tue, 8 Aug 2023 17:07:50 +0000 (UTC) (envelope-from des@freebsd.org) Received: by ltc.des.no (Postfix, from userid 1001) id B77F418686; Tue, 8 Aug 2023 19:07:48 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: current@freebsd.org Subject: ZFS deadlock in 14 User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (berkeley-unix) Date: Tue, 08 Aug 2023 19:07:48 +0200 Message-ID: <86leeltqcb.fsf@ltc.des.no> 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=utf-8 Content-Transfer-Encoding: quoted-printable At some point between 42d088299c (4 May) and f0c9703301 (26 June), a deadlock was introduced in ZFS. It is still present as of 9c2823bae9 (4 August) and is 100% reproducable just by starting poudriere bulk in a 16-core VM and waiting a few hours until deadlkres kicks in. In the latest instance, deadlkres complained about a bash process: #0 sched_switch (td=3Dtd@entry=3D0xfffffe02fb1d8000, flags=3Dflags@ent= ry=3D259) at /usr/src/sys/kern/sched_ule.c:2299 #1 0xffffffff80b5a0a3 in mi_switch (flags=3Dflags@entry=3D259) at /usr= /src/sys/kern/kern_synch.c:550 #2 0xffffffff80babcb4 in sleepq_switch (wchan=3D0xfffff818543a9e70, pr= i=3D64) at /usr/src/sys/kern/subr_sleepqueue.c:609 #3 0xffffffff80babb8c in sleepq_wait (wchan=3D, pri=3D) at /usr/src/sys/kern/subr_sleepqueue.c:660 #4 0xffffffff80b1c1b0 in sleeplk (lk=3Dlk@entry=3D0xfffff818543a9e70, = flags=3Dflags@entry=3D2121728, ilk=3Dilk@entry=3D0x0, wmesg=3Dwmesg@entry= =3D0xffffffff8222a054 "zfs", pri=3D, pri@entry=3D64, timo=3D= timo@entry=3D6, queue=3D1) at /usr/src/sys/kern/kern_lock.c:310 #5 0xffffffff80b1a23f in lockmgr_slock_hard (lk=3D0xfffff818543a9e70, = flags=3D2121728, ilk=3D, file=3D0xffffffff812544fb "/usr/src= /sys/kern/vfs_subr.c", line=3D3057, lwa=3D0x0) at /usr/src/sys/kern/kern_lo= ck.c:705 #6 0xffffffff80c59ec3 in VOP_LOCK1 (vp=3D0xfffff818543a9e00, flags=3D2= 105344, file=3D0xffffffff812544fb "/usr/src/sys/kern/vfs_subr.c", line=3D30= 57) at ./vnode_if.h:1120 #7 _vn_lock (vp=3Dvp@entry=3D0xfffff818543a9e00, flags=3D2105344, file= =3D, line=3D, line@entry=3D3057) at /usr/src/sys/= kern/vfs_vnops.c:1815 #8 0xffffffff80c4173d in vget_finish (vp=3D0xfffff818543a9e00, flags= =3D, vs=3Dvs@entry=3DVGET_USECOUNT) at /usr/src/sys/kern/vfs_s= ubr.c:3057 #9 0xffffffff80c1c9b7 in cache_lookup (dvp=3Ddvp@entry=3D0xfffff802cd0= 2ac40, vpp=3Dvpp@entry=3D0xfffffe046b20ac30, cnp=3Dcnp@entry=3D0xfffffe046b= 20ac58, tsp=3Dtsp@entry=3D0x0, ticksp=3Dticksp@entry=3D0x0) at /usr/src/sys= /kern/vfs_cache.c:2086 #10 0xffffffff80c2150c in vfs_cache_lookup (ap=3D) at /u= sr/src/sys/kern/vfs_cache.c:3068 #11 0xffffffff80c32c37 in VOP_LOOKUP (dvp=3D0xfffff802cd02ac40, vpp=3D0= xfffffe046b20ac30, cnp=3D0xfffffe046b20ac58) at ./vnode_if.h:69 #12 vfs_lookup (ndp=3Dndp@entry=3D0xfffffe046b20abd8) at /usr/src/sys/k= ern/vfs_lookup.c:1266 #13 0xffffffff80c31ce1 in namei (ndp=3Dndp@entry=3D0xfffffe046b20abd8) = at /usr/src/sys/kern/vfs_lookup.c:689 #14 0xffffffff80c52090 in kern_statat (td=3D0xfffffe02fb1d8000, flag=3D= , fd=3D-100, path=3D0xa75b480e070 , pathseg=3Dpathseg@entry=3DUIO_USERSPACE, sbp= =3Dsbp@entry=3D0xfffffe046b20ad18) at /usr/src/sys/kern/vfs_syscalls.c:2441 #15 0xffffffff80c52797 in sys_fstatat (td=3D, uap=3D0xffff= fe02fb1d8400) at /usr/src/sys/kern/vfs_syscalls.c:2419 #16 0xffffffff81049398 in syscallenter (td=3D) at /usr/s= rc/sys/amd64/amd64/../../kern/subr_syscall.c:190 #17 amd64_syscall (td=3D0xfffffe02fb1d8000, traced=3D0) at /usr/src/sys= /amd64/amd64/trap.c:1199 #18 The lock it is trying to acquire in frame 5 belongs to another bash process which is in the process of creating a fifo: #0 sched_switch (td=3Dtd@entry=3D0xfffffe046acd8e40, flags=3Dflags@ent= ry=3D259) at /usr/src/sys/kern/sched_ule.c:2299 #1 0xffffffff80b5a0a3 in mi_switch (flags=3Dflags@entry=3D259) at /usr= /src/sys/kern/kern_synch.c:550 #2 0xffffffff80babcb4 in sleepq_switch (wchan=3D0xfffff8018acbf154, pr= i=3D87) at /usr/src/sys/kern/subr_sleepqueue.c:609 #3 0xffffffff80babb8c in sleepq_wait (wchan=3D, pri=3D) at /usr/src/sys/kern/subr_sleepqueue.c:660 #4 0xffffffff80b59606 in _sleep (ident=3Dident@entry=3D0xfffff8018acbf= 154, lock=3Dlock@entry=3D0xfffff8018acbf120, priority=3Dpriority@entry=3D87= , wmesg=3D0xffffffff8223af0e "zfs teardown inactive", sbt=3Dsbt@entry=3D0, = pr=3Dpr@entry=3D0, flags=3D256) at /usr/src/sys/kern/kern_synch.c:225 #5 0xffffffff80b45dc0 in rms_rlock_fallback (rms=3D0xfffff8018acbf120)= at /usr/src/sys/kern/kern_rmlock.c:1015 #6 0xffffffff80b45c93 in rms_rlock (rms=3D, rms@entry=3D0= xfffff8018acbf120) at /usr/src/sys/kern/kern_rmlock.c:1036 #7 0xffffffff81fb147b in zfs_freebsd_reclaim (ap=3D) at= /usr/src/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vnops_os.c:5164 #8 0xffffffff8111d245 in VOP_RECLAIM_APV (vop=3D0xffffffff822e71a0 , a=3Da@entry=3D0xfffffe0410f1c9c8) at vnode_if.c:2180 #9 0xffffffff80c43569 in VOP_RECLAIM (vp=3D0xfffff802cdbaca80) at ./vn= ode_if.h:1084 #10 vgonel (vp=3Dvp@entry=3D0xfffff802cdbaca80) at /usr/src/sys/kern/vf= s_subr.c:4143 #11 0xffffffff80c3ef61 in vtryrecycle (vp=3D0xfffff802cdbaca80) at /usr= /src/sys/kern/vfs_subr.c:1693 #12 vnlru_free_impl (count=3Dcount@entry=3D1, mnt_op=3Dmnt_op@entry=3D0= x0, mvp=3D0xfffff8010864da00) at /usr/src/sys/kern/vfs_subr.c:1344 #13 0xffffffff80c49553 in vnlru_free_locked (count=3D1) at /usr/src/sys= /kern/vfs_subr.c:1357 #14 vn_alloc_hard (mp=3Dmp@entry=3D0x0) at /usr/src/sys/kern/vfs_subr.c= :1744 #15 0xffffffff80c3f6f0 in vn_alloc (mp=3D0x0) at /usr/src/sys/amd64/inc= lude/atomic.h:375 #16 getnewvnode_reserve () at /usr/src/sys/kern/vfs_subr.c:1888 #17 0xffffffff81faa072 in zfs_create (dzp=3D0xfffff812200261d0, name=3D= 0xfffff8011b8ac805 "sh-np.yPbxoo", vap=3D0xfffffe0410f1cc20, excl=3D, mode=3D, zpp=3Dzpp@entry=3D0xfffffe0410f1cbc8, cr= =3D0xfffff80140fb1100, flag=3D, vsecp=3D0x0, mnt_ns=3D0x0) at /usr/src/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vnops_os.= c:1146 #18 0xffffffff81faea57 in zfs_freebsd_create (ap=3D0xfffffe0410f1cda0) = at /usr/src/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vnops_os.c:4618 #19 0xffffffff8111aa9a in VOP_MKNOD_APV (vop=3D0xffffffff822e71a0 , a=3Da@entry=3D0xfffffe0410f1cda0) at vnode_if.c:372 #20 0xffffffff80c50207 in VOP_MKNOD (dvp=3D, cnp=3D0xfffff= e0410f1cd50, vap=3D0xfffffe0410f1cc20, vpp=3D) at ./vnode_if= .h:188 #21 kern_mkfifoat (td=3D0xfffffe046acd8e40, fd=3D-100, path=3D0x12772f0= 73500 , pathseg=3DUI= O_USERSPACE, mode=3D) at /usr/src/sys/kern/vfs_syscalls.c:14= 92 #22 0xffffffff81049398 in syscallenter (td=3D) at /usr/s= rc/sys/amd64/amd64/../../kern/subr_syscall.c:190 #23 amd64_syscall (td=3D0xfffffe046acd8e40, traced=3D0) at /usr/src/sys= /amd64/amd64/trap.c:1199 #24 Frame 7 is trying to acquire the ZFS teardown inactive lock, which is held by a process which is performing a ZFS rollback and is waiting for the transaction to sync: #0 sched_switch (td=3Dtd@entry=3D0xfffffe0422ef8560, flags=3Dflags@ent= ry=3D259) at /usr/src/sys/kern/sched_ule.c:2299 #1 0xffffffff80b5a0a3 in mi_switch (flags=3Dflags@entry=3D259) at /usr= /src/sys/kern/kern_synch.c:550 #2 0xffffffff80babcb4 in sleepq_switch (wchan=3D0xfffff8011b83d540, pr= i=3D0) at /usr/src/sys/kern/subr_sleepqueue.c:609 #3 0xffffffff80babb8c in sleepq_wait (wchan=3D, wchan@ent= ry=3D0xfffff8011b83d540, pri=3D, pri@entry=3D0) at /usr/src/sy= s/kern/subr_sleepqueue.c:660 #4 0xffffffff80ad7f75 in _cv_wait (cvp=3Dcvp@entry=3D0xfffff8011b83d54= 0, lock=3Dlock@entry=3D0xfffff8011b83d4d0) at /usr/src/sys/kern/kern_condva= r.c:146 #5 0xffffffff820b42fb in txg_wait_synced_impl (dp=3Ddp@entry=3D0xfffff= 8011b83d000, txg=3D8585097, wait_sig=3Dwait_sig@entry=3D0) at /usr/src/sys/= contrib/openzfs/module/zfs/txg.c:726 #6 0xffffffff820b3cab in txg_wait_synced (dp=3D, dp@entry= =3D0xfffff8011b83d000, txg=3D) at /usr/src/sys/contrib/openzfs= /module/zfs/txg.c:736 #7 0xffffffff8206d5b5 in dsl_sync_task_common (pool=3Dpool@entry=3D0xf= ffffe0401d15000 "zroot/poudriere/jails/13amd64-default-ref/15", checkfunc= =3D, syncfunc=3D0xffffffff8203fbc0 , sigfunc=3Dsigfunc@entry=3D0x0, arg=3Darg@entry=3D0xfffffe02fb827a90,=20 blocks_modified=3Dblocks_modified@entry=3D1, space_check=3DZFS_SPAC= E_CHECK_RESERVED, early=3D0) at /usr/src/sys/contrib/openzfs/module/zfs/dsl= _synctask.c:93 #8 0xffffffff8206d3c7 in dsl_sync_task (pool=3D, pool@ent= ry=3D0xfffffe0401d15000 "zroot/poudriere/jails/13amd64-default-ref/15", che= ckfunc=3D, syncfunc=3D, arg=3D, arg@= entry=3D0xfffffe02fb827a90, blocks_modified=3D,=20 blocks_modified@entry=3D1, space_check=3D, space_check= @entry=3DZFS_SPACE_CHECK_RESERVED) at /usr/src/sys/contrib/openzfs/module/z= fs/dsl_synctask.c:132 #9 0xffffffff8204075b in dsl_dataset_rollback (fsname=3D,= fsname@entry=3D0xfffffe0401d15000 "zroot/poudriere/jails/13amd64-default-r= ef/15", tosnap=3D, owner=3D, result=3Dresult@= entry=3D0xfffff81c826a9ea0) at /usr/src/sys/contrib/openzfs/module/zfs/dsl_dataset.c:3261 #10 0xffffffff82168dd9 in zfs_ioc_rollback (fsname=3D0xfffffe0401d15000= "zroot/poudriere/jails/13amd64-default-ref/15", fsname@entry=3D, innvl=3D, innvl@entry= =3D,=20 outnvl=3D0xfffff81c826a9ea0, outnvl@entry=3D) at /usr/src/sys/contrib/openzfs/module/zfs/zfs_i= octl.c:4405 #11 0xffffffff82164522 in zfsdev_ioctl_common (vecnum=3Dvecnum@entry=3D= 25, zc=3Dzc@entry=3D0xfffffe0401d15000, flag=3Dflag@entry=3D0) at /usr/src/= sys/contrib/openzfs/module/zfs/zfs_ioctl.c:7798 #12 0xffffffff81f97fca in zfsdev_ioctl (dev=3D, zcmd=3D<= unavailable>, zcmd@entry=3D= , arg=3D0xfffffe02fb827d50 "\017", arg@entry=3D, flag=3D, td=3D) at /usr/src/sys/contrib/openzfs/module/os/freebsd/zfs/kmod_core.c:1= 68 #13 0xffffffff809d6212 in devfs_ioctl (ap=3D0xfffffe02fb827c50) at /usr= /src/sys/fs/devfs/devfs_vnops.c:935 #14 0xffffffff80c585f2 in vn_ioctl (fp=3D0xfffff8052cdd80f0, com=3D, data=3D0xfffffe02fb827d50, active_cred=3D0xfffff80122ab1e00, t= d=3D) at /usr/src/sys/kern/vfs_vnops.c:1704 #15 0xffffffff809d68ee in devfs_ioctl_f (fp=3D, fp@entry= =3D, com=3D, c= om@entry=3D, data=3D, data@entry=3D,=20 cred=3D, cred@entry=3D, td=3D, td@entry=3D) at /usr/src/sys/fs/devfs/devfs_vnops.c:866 #16 0xffffffff80bc57e6 in fo_ioctl (fp=3D0xfffff8052cdd80f0, com=3D3222= 821401, data=3D, active_cred=3D, td=3D0xfffffe042= 2ef8560) at /usr/src/sys/sys/file.h:367 #17 kern_ioctl (td=3Dtd@entry=3D0xfffffe0422ef8560, fd=3D4, com=3Dcom@e= ntry=3D3222821401, data=3D, data@entry=3D0xfffffe02fb827d50 "\= 017") at /usr/src/sys/kern/sys_generic.c:807 #18 0xffffffff80bc54f2 in sys_ioctl (td=3D0xfffffe0422ef8560, uap=3D0xf= ffffe0422ef8960) at /usr/src/sys/kern/sys_generic.c:715 #19 0xffffffff81049398 in syscallenter (td=3D) at /usr/s= rc/sys/amd64/amd64/../../kern/subr_syscall.c:190 #20 amd64_syscall (td=3D0xfffffe0422ef8560, traced=3D0) at /usr/src/sys= /amd64/amd64/trap.c:1199 #21 OpenZFS commits in the relevant range: commit e639e0d27cc863ba1b8de20e861e6b5d9b922a8e Merge: 92c23f6d9c20 e61076683850 Author: Martin Matuska AuthorDate: Fri May 12 13:12:59 2023 +0200 Commit: Martin Matuska CommitDate: Fri May 12 13:13:33 2023 +0200 =20=20=20=20 zfs: merge openzfs/zfs@e61076683 =20=20=20=20=20=20=20=20 Notable upstream pull request merges: #14744 Optimize check_filesystem() and process_error_log() #14773 Allow zhack label repair to restore detached devices #14794 zpool import -m also removing spare and cache when log dev= ice is missing #14805 Simplify and optimize random_int_between() #14813 Enable the head_errlog feature to remove errors #14816 Fix two abd_gang_add_gang() issues #14817 Verify block pointers before writing them out #14819 Add dmu_tx_hold_append() interface #14823 Remove single parent assertion from zio_nowait() #14824 Plug memory leak in zfsdev_state #14825 Block cloning dbuf fixes #14828 Remove duplicate code in l2arc_evict() #14837 Fixes in head_errlog feature with encryption #14839 Prevent panic during concurrent snapshot rollback and zvol= read #14853 zil: Don't expect zio_shrink() to succeed =20=20=20=20=20=20=20=20 Obtained from: OpenZFS OpenZFS commit: e6107668385044718b0a73330ed6423650806473 =20=20=20=20 commit 4d846d260e2b9a3d4d0a701462568268cbfe7a5b Author: Warner Losh AuthorDate: Wed May 10 09:40:58 2023 -0600 Commit: Warner Losh CommitDate: Fri May 12 10:44:03 2023 -0600 =20=20=20=20 spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD =20=20=20=20=20=20=20=20 The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. = Catch up to that fact and revert to their recommended match of BSD-2-Clau= se. =20=20=20=20=20=20=20=20 Discussed with: pfg MFC After: 3 days Sponsored by: Netflix =20=20=20=20 commit c0a83fe074a375c66ca669bfe1f128fe12b9f377 Merge: 634a770a5e16 ad0a554614b0 Author: Martin Matuska AuthorDate: Tue May 23 11:50:17 2023 +0200 Commit: Martin Matuska CommitDate: Tue May 23 11:51:52 2023 +0200 =20=20=20=20 zfs: merge openzfs/zfs@ad0a55461 =20=20=20=20=20=20=20=20 Notable upstream pull request merges: #12355 Teach zpool scrub to scrub only blocks in error log #14811 Refine special_small_blocks property validation #14854 zil: Some micro-optimizations #14855 zil: Free lwb_buf after write completion #14860 Fixes for issues identified by recent Coverity defect repo= rts #14861 Probe vdevs before marking removed #14873 Add the ability to uninitialize a zpool #14875 Hold db_mtx when updating db_state =20=20=20=20=20=20=20=20 Obtained from: OpenZFS OpenZFS commit: ad0a554614b096698d9969340c4c593690042d5b =20=20=20=20 commit 48f52d9179d5920750cef0c5d921db63de4d767d Author: John Baldwin AuthorDate: Thu May 25 07:11:38 2023 -0700 Commit: John Baldwin CommitDate: Thu May 25 07:11:38 2023 -0700 =20=20=20=20 zfs: Fix build on 32-bit platforms after most recent import. =20=20=20=20=20=20=20=20 unsigned long is not a uint64_t on 32-bit platforms. The zfs.4 manpage documents this variable as a uint, and it is only compared with other variables of type int, so uint_t makes more sense than unsigned long. =20=20=20=20=20=20=20=20 (I also wasn't sure if ULONG would work as a ZFS_MODULE_PARAM type on other OS's) =20=20=20=20 commit 4e8d558c9d1cf3e7e424e3fb123b01979c3d57f2 Merge: 5ca7f0294694 feff9dfed3df Author: Martin Matuska AuthorDate: Sat Jun 10 19:31:17 2023 +0200 Commit: Martin Matuska CommitDate: Sat Jun 10 19:31:17 2023 +0200 =20=20=20=20 zfs: merge openzfs/zfs@feff9dfed =20=20=20=20=20=20=20=20 Notable upstream pull request merges: #14833 Update compatibility.d files #14841 ZIL: Reduce scope of per-dataset zl_issuer_lock #14863 zil: Add some more statistics #14866 btree: Implement faster binary search algorithm #14894 Fix inconsistent definition of zfs_scrub_error_blocks_per_= txg #14892 Fix concurrent resilvers initiated at same time #14903 Fix NULL pointer dereference when doing concurrent 'send' = operations #14910 ZIL: Allow to replay blocks of any size #14939 Fix the L2ARC write size calculating logic #14934 Introduce zfs_refcount_(add|remove)_few() #14946 Improve l2arc reporting in arc_summary #14953 Finally drop long disabled vdev cache #14954 Fix the L2ARC write size calculating logic (2) #14955 Use list_remove_head() where possible #14959 ZIL: Fix race introduced by f63811f0721 =20=20=20=20=20=20=20=20 Obtained from: OpenZFS OpenZFS commit: feff9dfed3df1bbae5dd74959a6ad87d11f27ffb =20=20=20=20 commit b7198dcfc03967cba191a373d99df47ee52d6e2a Merge: 2c7279bae776 10e36e17612b Author: Martin Matuska AuthorDate: Fri Jun 16 23:12:27 2023 +0200 Commit: Martin Matuska CommitDate: Fri Jun 16 23:13:05 2023 +0200 =20=20=20=20 zfs: merge openzfs/zfs@10e36e176 =20=20=20=20=20=20=20=20 Notable upstream pull request merges: #14948 Remove ARC/ZIO physdone callbacks #14963 Store the L2ARC device ashift in the vdev label #14970 Switch refcount tracking from lists to AVL-trees #14981 Shorten arcstat_quiescence sleep time =20=20=20=20=20=20=20=20 Obtained from: OpenZFS OpenZFS commit: 10e36e17612ba9c634b140ae76847bb62b5be68f =20=20=20=20 commit f190c36b5d45cbfadc922a69d79628c43cdda22f Merge: 229d643c4dd5 8e8acabdcaeb Author: Martin Matuska AuthorDate: Sun Jun 25 10:31:19 2023 +0200 Commit: Martin Matuska CommitDate: Sun Jun 25 10:32:42 2023 +0200 =20=20=20=20 zfs: merge openzfs/zfs@8e8acabdc =20=20=20=20=20=20=20=20 Notable upstream pull request merges: #14987 Fix memory leak in zil_parse() =20=20=20=20=20=20=20=20 Obtained from: OpenZFS OpenZFS commit: 8e8acabdcaeb831c777f71361722f4235b698a8d We can't ship 14.0 with this deadlock. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@FreeBSD.org From nobody Tue Aug 8 17:16:47 2023 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 4RL0H24wsQz4prG6 for ; Tue, 8 Aug 2023 17:17:02 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ot1-f48.google.com (mail-ot1-f48.google.com [209.85.210.48]) (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 4RL0H21KXCz4MTk; Tue, 8 Aug 2023 17:17:02 +0000 (UTC) (envelope-from asomers@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ot1-f48.google.com with SMTP id 46e09a7af769-6bd0a0a6766so536452a34.2; Tue, 08 Aug 2023 10:17:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691515019; x=1692119819; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=c0yW+5tIPVKPohwVZExSP6qYZMcgXzpHakEQbmOO0Fo=; b=P18MxmkfNgoi8AE6+IM0BagJqjLMUns4K0QpLzAay9RyqjMP8B/kDclEyznnP7sJP8 hhna/RET+sT+ohuOWxFmh+PUd6E/vIlgW1hHBpD0HuWIgg/hUSNVkXW+oqrTkpN5m/u3 /5cehEpeSxfH0k+Xjob5HwNlUXl7TjbAmI27NBnQzETXI5qgya80nArCxOn2wWR9aLA7 nYiDY2UmNodn/JmVZPiAaZl58aJoIoGr0ZeoemdoFS2S+Iuif6ihGbRaPoVfRuMFj4pY BC37RKdJ029QWzYiOtFJaTDr/8rdQl3CK9l00+7jtY3j2+wL8zGTdI5JCi2tUnWPP1wl Z6wg== X-Gm-Message-State: AOJu0YzoiX1OmPCnl4lRXcyuFEtPpPqSMsjD0JvbQH4+D9dkUTprZciO TO2qMZFkn/Fs2Zob9iNbep0/ri4fQr5wkBhDzJZ8UYAYTM0= X-Google-Smtp-Source: AGHT+IGW4FygXBSZOIDeks/VFe31cS8OVSl4ZHX8u7VxYQAYGMYljSZhX/bas7VtZAbhMzhqLi8c2RdD8lCUGJkSBMU= X-Received: by 2002:a05:6358:7e05:b0:134:d128:9f5f with SMTP id o5-20020a0563587e0500b00134d1289f5fmr45847rwm.9.1691515018972; Tue, 08 Aug 2023 10:16:58 -0700 (PDT) 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: <86leeltqcb.fsf@ltc.des.no> In-Reply-To: <86leeltqcb.fsf@ltc.des.no> From: Alan Somers Date: Tue, 8 Aug 2023 10:16:47 -0700 Message-ID: Subject: Re: ZFS deadlock in 14 To: =?UTF-8?Q?Dag=2DErling_Sm=C3=B8rgrav?= Cc: current@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4RL0H21KXCz4MTk X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] On Tue, Aug 8, 2023 at 10:08=E2=80=AFAM Dag-Erling Sm=C3=B8rgrav wrote: > > At some point between 42d088299c (4 May) and f0c9703301 (26 June), a > deadlock was introduced in ZFS. It is still present as of 9c2823bae9 (4 > August) and is 100% reproducable just by starting poudriere bulk in a > 16-core VM and waiting a few hours until deadlkres kicks in. In the > latest instance, deadlkres complained about a bash process: Do you have ZFS block cloning enabled on your pool? There were a lot of bugs associated with that feature. I think that was merged on 3-April. > zpool get feature@block_cloning zroot NAME PROPERTY VALUE SOURCE zroot feature@block_cloning disabled local From nobody Tue Aug 8 17:18:12 2023 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 4RL0JQ5FRVz4pr6P for ; Tue, 8 Aug 2023 17:18:14 +0000 (UTC) (envelope-from des@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 4RL0JQ4nkYz4NX6; Tue, 8 Aug 2023 17:18:14 +0000 (UTC) (envelope-from des@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1691515094; 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=GU+vJPxCf/k0bwUD/jyQY/6L/OvckM2AtgBHl6cIA7M=; b=qx0tng8BQSGIKSMhhjqB65/RdE9daVYrF/ZsB4pyGn/5b3gsPZ31wGRh6qTiwL6+3FRKGr OTeh0wFNl1h0W1QM704CDtzEpNlveWcTZxCt0bNkL7or3Ocw5HRkNPBTqMhazJjpyizDkc xTZpJS6UbsA0/lEpRiiQJRwrmxZmdOQIZ7hjP5V/8hKSAp7xgMBBRp9aeegyKg5xfs9lVa 3/ntdE2jLoUUwogknP6LjaSyoaAmxHCoSwN/qBGY+DbHJpTYpCH7iaTju+wusyyUwZVUdY Lkm+M0h/QRSUITvTZkJT2dBiU228aRxk2p8d3VgoZbqtOrk7dYHpopyFFTChfQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1691515094; 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=GU+vJPxCf/k0bwUD/jyQY/6L/OvckM2AtgBHl6cIA7M=; b=hnsuKImG/ta8wfZMM+XKpWVJw6n3YyuWmlPznGHCMcjE6OnEQrP6cca4Ly1bu9nHwHIzwi gIkhHuufMDE8F0ptmn4IhrwTiEll8n+LkqJe+pdfIJQY/ffimvGXjG3M7hWWdFQXea0+Fp VramiyVOjc6lEMVX9zk3InyYsX9t9JAs8WCxSAjr13fpQpcAGC4E0nFMc+nM8KzlLdvif8 9nND1dOE6KjvrFgQjtVmkI67ovcKOYF9oAlwMrZgV/dZx92S9jahTWiaQXpiwa8AjhRSyl wkxSHma152OHUWP2V7I6wC207emHk0YkxWbk/lEmqjXPFmeYJiUFgNaoY6GrCQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1691515094; a=rsa-sha256; cv=none; b=ebgzD5I1TiNZwCwOboVr975u+YMC9JqM1bpAmS2520P7sPXxGRHGHkToqSueyQ0vwtI6XW zXHUMQfTQXKOPQzqe+rWfii4SepRKzIj8VfLsZDGRYu9HZULWw9wROS9An1Xz9uBRLT+2S u1aBcPsqOmWzD5crzL0Sak9w2tuY/PUnP4wyOoOaJx2bjqPJ3XQtVbtC9x7SaI1cL+v9+A E/LzmX0io5jV6kxEZ/0AbcyZBOwF0PXs6Nn2jjQlBAjl6vl+o8ByHKc6W/jn/XDkdYaXfe ttug7e/rL8jel0xr0X/IyiMkX1pSTe4iF8fopjIi0DIY1MZhDJ3ipylETCpAmw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from ltc.des.no (unknown [IPv6:2001:4647:d671:0:36e8:94ff:feca:9834]) (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) (Authenticated sender: des) by smtp.freebsd.org (Postfix) with ESMTPSA id 4RL0JQ2znDzBk9; Tue, 8 Aug 2023 17:18:14 +0000 (UTC) (envelope-from des@freebsd.org) Received: by ltc.des.no (Postfix, from userid 1001) id F2B9B18702; Tue, 8 Aug 2023 19:18:12 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Alan Somers Cc: current@freebsd.org Subject: Re: ZFS deadlock in 14 In-Reply-To: (Alan Somers's message of "Tue, 8 Aug 2023 10:16:47 -0700") References: <86leeltqcb.fsf@ltc.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (berkeley-unix) Date: Tue, 08 Aug 2023 19:18:12 +0200 Message-ID: <86h6p9tpuz.fsf@ltc.des.no> 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=utf-8 Content-Transfer-Encoding: quoted-printable Alan Somers writes: > Do you have ZFS block cloning enabled on your pool? There were a lot > of bugs associated with that feature. I think that was merged on > 3-April. No, and this deadlock did not appear until May. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@FreeBSD.org From nobody Tue Aug 8 17:36:06 2023 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 4RL0j53G5Rz4psDk for ; Tue, 8 Aug 2023 17:36:09 +0000 (UTC) (envelope-from grahamperrin@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 4RL0j52lc5z4QVH for ; Tue, 8 Aug 2023 17:36:09 +0000 (UTC) (envelope-from grahamperrin@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1691516169; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=OPMT7uyyVboERSSt/uXa1vZ8wgAceR7SVAkgp1f2hQw=; b=wInKRiJ8DwmbpAPD+td2Mt4r5HeQodhdAUrxNrY0djrHx9VyQixrKKTrNXF/Jo1QNvi/TI t3nn4hYyHbRD5YpmE1JW7xU/ZnSo7jLVZ4hh8xemwqB6BkdKzv7tVYpgOhlHY9v5VahX2+ bQEef70mTjDouwfej6mMGJU9dTQvCToKejovmELhJjU85jxWI0KmCm6ZXB8s893tsWKRDN xmnqXb/o4K1w3Lnu4/W+HSvisq8P/XhUt+ev3zHEgXbK+yiQmrXJh6AxzC8Xgd1dH4zV7f XRVRE14059VMzfTSpplsUlVGWM649nmqrosiLdSvvOzNLX93qRQFAqepfELiaQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1691516169; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=OPMT7uyyVboERSSt/uXa1vZ8wgAceR7SVAkgp1f2hQw=; b=WFqEXLwlvgd2k0DugP9B5llaI7h+er+gjRFvXefKFJuvcnBPz3kNmfG1Qn3iGrRwC3yT4M y2JkOrS4FKDIJhFbGUGXaE/6JnczF76reS4TrRh69NB8BcsSm6qQaMM0tSve4O7EL9NrJc 7q+6mlIw1Am3BERgYlDtN34v54X6OdVpLXRjGu+hKh7iZ2yVy6yyXiPIj5yqecJVuVcSXE LhHnyREVjESJvYnUxmw11znUW8tsmuXk7AFJ/KVOLIfYrn2kDoNo19sBkQyWjLyZ07Y60P bOHnTVXjmrMaiZchYheKy2yn0zq4Pds2zHbdtvBYkVuqj8h5L39JM1nNiZhTDg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1691516169; a=rsa-sha256; cv=none; b=WWQH2+4I+DFa+G1cvghgYUCWnIVDVHV5oOIhnAQkd4LExRtoiyRp9UhVm08yhY/sBhc+/c dxpTrtFy9qxKxSWm6kLf7FYCfccT5STQ+B9XtcL0Pipp2EaRYQJIA9a5voAuXhtIjM9hKV PfHDQbwSciGznNBuxr3OB8a8qWP+s4T+j4L7z0IAq7byBdgdUuA1MXGzcb9fEkaAjCeVsJ vlNpQUYVDXhMf0MBnK6+RI2hhsRG/yuTc2EAdno01+29LFwoZm3mIUX3BtmFECVIboBq+M g/QdoSmkWO5fE7XXokhaR8XgHpzvkIHZ5Zx5vPleYyhJP/KPWjLIl3TNXFe6IA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from [192.168.1.10] (80-42-66-93.dynamic.dsl.as9105.com [80.42.66.93]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) (Authenticated sender: grahamperrin) by smtp.freebsd.org (Postfix) with ESMTPSA id 4RL0j50TYMzCGf for ; Tue, 8 Aug 2023 17:36:08 +0000 (UTC) (envelope-from grahamperrin@freebsd.org) Message-ID: Date: Tue, 8 Aug 2023 18:36:06 +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:102.0) Gecko/20100101 Thunderbird/102.14.0 Subject: Re: ZFS deadlock in 14 Content-Language: en-US To: freebsd-current@freebsd.org References: <86leeltqcb.fsf@ltc.des.no> From: Graham Perrin Organization: FreeBSD In-Reply-To: <86leeltqcb.fsf@ltc.des.no> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------8U80fFTuuUcYxjgrT08yOETl" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------8U80fFTuuUcYxjgrT08yOETl Content-Type: multipart/mixed; boundary="------------BXXcgqtt1qG3xZPawYE6yj0K"; protected-headers="v1" From: Graham Perrin To: freebsd-current@freebsd.org Message-ID: Subject: Re: ZFS deadlock in 14 References: <86leeltqcb.fsf@ltc.des.no> In-Reply-To: <86leeltqcb.fsf@ltc.des.no> --------------BXXcgqtt1qG3xZPawYE6yj0K Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 PGh0dHBzOi8vYnVncy5mcmVlYnNkLm9yZy9idWd6aWxsYS9zaG93X2J1Zy5jZ2k/aWQ9Mjcx OTQ1PiBtYXliZS4NCg== --------------BXXcgqtt1qG3xZPawYE6yj0K-- --------------8U80fFTuuUcYxjgrT08yOETl Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEWT/lssMHB+28ly8Kt2dIb0oY1AsFAmTSfQcFAwAAAAAACgkQt2dIb0oY1At/ Bg//ePyIuUH2JNF/hULZk0jmoaR80iJ+nEvTE3XGQJ+au4X6C3iUVqYsJgK3G7VJEgRqUKLvhVra lI5mgYFV/WJVe7PJRoz6bXXTaiDn9HE3MYvVKDLOSohzSaS5TZBnKBqjFHVBG4fCirHSKdIXMrOE qOp4q2CUKKdfHtFUWuB4k1s963sEPfv9UNwH/ebGiZ4m8EFqZh8kmgh0AO+qIetawov9KStGjhyJ rom+lbEUS8+TS3k+JJLXJSalD9m7t74qBhBwJ38d5cvIeUI7+6blRAVXJjQu0ZSwHBEbFCE8qIMM NEORC/q0fhxoiklOK6aT5whW+b58ySpV1+q/vBdOXA+1kJf0rWBJBiVsZrbp40IjCnysK5TtvA6x FgkfKvNZQgIvgDcOyXBbV6rhJ2vw/blb8Cl7T077cGNHQUxN38ezD+ifLFXDTXXtiVY+isb7vCsY 2Er1lhnCsDDmkXJTtZBoH5msiCAKAWEQiKrGeH7ywg/SrvMNbz7XCg52qxUol2YVUQSO9OUYYMYQ Vl0GrsBaFyAP7CtWDdgls6qnvZPFfImcw74FAXuDAmOddnW7lzISxMF/wMcFIfylPUe8umDTOihN k37+F1w4QyDAVJDdJkdXicb9/gdM5Q3ia9AE2t5cxjDEr4rXG6Hrs3hSJ6uqoO5yzK8fMDLIyhAi 75w= =Et/j -----END PGP SIGNATURE----- --------------8U80fFTuuUcYxjgrT08yOETl-- From nobody Tue Aug 8 17:39:02 2023 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 4RL0mT41gBz4psCM for ; Tue, 8 Aug 2023 17:39:05 +0000 (UTC) (envelope-from grahamperrin@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 4RL0mT3TCTz4Rmv for ; Tue, 8 Aug 2023 17:39:05 +0000 (UTC) (envelope-from grahamperrin@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1691516345; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=qQjKdL4Am27XuaCmYizV9EDGHt9cmHwF9D+fU5jm3BU=; b=qzq1RDd+BmCS5JHn5OwhCyTpc4EofRVLZQtUXgRwstJnbHNgSHE4TvdilwLaHPhVZK2QsV qH4GEwn7YLiUSkoQYbPHv9PdmluuQeJlMpZbwEp+yfmaD3Rpd2KgwOuIEEuQwLi+CMOOqc 1fUaVCj/eNKI5DLKfnGEPJK76NMf4MLncZ7MiGId5mNNN6JuHXrzvSRaaqwdZPJHZjfGz3 hil6yyUImiGjErin0TI51BjqT+0v/cZXeoWMloU8PhzVSBYHv6W4mIqMt+86gd66SW92tR EJIvTiJ9QmGKRe+dX0AV/XCJOqWXF42Y2M6aUPX4jx5OY5QE+yp6OKmPvxT0sg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1691516345; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=qQjKdL4Am27XuaCmYizV9EDGHt9cmHwF9D+fU5jm3BU=; b=gAeTC/6kKT1M3SAQ2EOdKT17e9dBJANFXHa+SjTV3513CPjYkE1OD16vEUCpPfD8Z/LKrT iy7RH9ZDQF2fZTEH+E4C9R0FqPFayjGdRtOnTfBtCv1RTSrQOOafZCgKUAiHTjrZ919DBe vSv4WwHrsD9bL3e36DKs/su/D53Cri0DHjHW7WyP80x6nSVrdJEPd/fssMz9+bLUzVVF9C X+FwnkVeDzOxO964vcOhXcjNNbPslNupraJbDwKPaDf9aI0mlDyCt5b8/JqequT4tgB+6U OANHVuKWijm2cLQYEijlg389FqQASN5dMGZAyilb4e7UM1CYpTWvDxQKlMQgtg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1691516345; a=rsa-sha256; cv=none; b=vs1A+J4K54zjBHrgZGE3qhT4zv1Z7/iUoRgs1n+H7pBThDiuCa8O2myHIz+nRK8zmxxdss 62MdJcDg84grKbZA2QN1B8h4OxhUrzkhXvxwChWZ/6gpVQ3XhyhhvHVcmfmN24vHkwntzH C9ihXhL3Ow6eRtIx/Apqvoqm5ork4EJilwTASmLZvDeo5YvGevZA99TrPzJ2jppo4vOg4V lZHgH8Gu64+ux0EyvMfyW+pGk5ioLIoI8IVzHVGTDqRGPgc/sKo/m4JQfosWTMuvblREoj G7DK1FZryEa09BP9IszGi41N1cE6ReSK5sHLOXoK5KcHd7GCDZgPdHOei6MkiQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from [192.168.1.10] (80-42-66-93.dynamic.dsl.as9105.com [80.42.66.93]) (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 did not present a certificate) (Authenticated sender: grahamperrin) by smtp.freebsd.org (Postfix) with ESMTPSA id 4RL0mT14kKzCGg for ; Tue, 8 Aug 2023 17:39:05 +0000 (UTC) (envelope-from grahamperrin@freebsd.org) Message-ID: <884e4afa-4687-8785-fc48-f5fff9556b8e@freebsd.org> Date: Tue, 8 Aug 2023 18:39:02 +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:102.0) Gecko/20100101 Thunderbird/102.14.0 Subject: Re: 14.0 boot failure Content-Language: en-US To: freebsd-current@freebsd.org References: From: Graham Perrin Organization: FreeBSD In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------nCv6ufkdWQjw2P3za3oFazYw" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------nCv6ufkdWQjw2P3za3oFazYw Content-Type: multipart/mixed; boundary="------------Mlk79wVnbwI0HqKwS0IJ7f8A"; protected-headers="v1" From: Graham Perrin To: freebsd-current@freebsd.org Message-ID: <884e4afa-4687-8785-fc48-f5fff9556b8e@freebsd.org> Subject: Re: 14.0 boot failure References: In-Reply-To: --------------Mlk79wVnbwI0HqKwS0IJ7f8A Content-Type: multipart/alternative; boundary="------------R4G13tbKrx3tpR7XDnrpdvbL" --------------R4G13tbKrx3tpR7XDnrpdvbL Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMDUvMDgvMjAyMyAwMDo0NSwgS2V2aW4gT2Jlcm1hbiB3cm90ZToNCj4gQSBuZXcga2Vy bmVsIGJ1aWx0IGZyb20gc291cmNlcyBwdWxsZWQgdG9kYXkgKDQtQXVnKSBhdCA1OjI2IFVU QyBmYWlscyANCj4gdG8gYm9vdC4g4oCmDQoNCkkgcmVmcmFpbmVkIGZyb20gdXBkYXRpbmcg YWZ0ZXIgcmVhZGluZyB0aGlzLg0KDQpBbnkgbmV3cz8NCg0KVElBDQoNCg== --------------R4G13tbKrx3tpR7XDnrpdvbL Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 05/08/2023 00:45, Kevin Oberman wrote:
A new kernel built from sources pulled today (4-Aug) at 5:26 UTC fails to boot. =E2=80=A6

I refrained from updating after reading this.

Any news?

TIA

--------------R4G13tbKrx3tpR7XDnrpdvbL-- --------------Mlk79wVnbwI0HqKwS0IJ7f8A-- --------------nCv6ufkdWQjw2P3za3oFazYw Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEWT/lssMHB+28ly8Kt2dIb0oY1AsFAmTSfbYFAwAAAAAACgkQt2dIb0oY1As5 kg/9FxE60Yd1TFEcPGMjwlamFSVSwLWK83uO1MfLDDGPTCLmA16G1/NjzfYz3MGmwePwRrASTWzH iqvjmgbhUcAcWOqZsGEkCU4DGzowjbNE1KsYPXysKBlKH7F4kyoVHu9iCEJa/cHjSxzMp+F1JFJN NWfGshOknrG5H1fTAxDz8cbR5hnrmFxSSaWLYM/YxWIxDINS8TTJZmRdkcJ+YyOOCkt+vwbmly0z BHftIXOwZ2vdrpH7c198a7L7VTaa46HS6r99g2J2AwBbyX6Ez1DXBSi9fH15G1efrV0cSF/SUhNS MvXw+6lOspHAlUMR/InKP5fQ8YMo00T2EOMn0QvA7ZQyJu1+MrTIi8cvzjvDDPkbq8PX1g+B1qhk pocQP4Xdy37D3FxD54xhA8QUzJPufsVKNdbtya28PF4qRN0BUeRV4PyfLfvzyk53tS0GBog9bqER GqGLKzcJopPLyYzS8B00qD5X8xhf773p3zKotaJmBaU/jBxsJO9TkR/ouJrzM7xmnN12yB8mL1nE PqDTpD/6pPp0DCLDq4SDe4mhNk1ZgNKFttoC6hhZnOPICAraGfLOuLL342Z5BEzslpQ3kNFHKXgi LlLcqffL7taQ99GE9wF26lgOpuDBs2y7mla/9SMJ51Q/0uRsVGjg56/nLzUXIPHBe+o1zgPn6aMW EdE= =Ayy4 -----END PGP SIGNATURE----- --------------nCv6ufkdWQjw2P3za3oFazYw-- From nobody Tue Aug 8 17:50:12 2023 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 4RL11P2FSCz4pt0P for ; Tue, 8 Aug 2023 17:50:17 +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 4RL11N1QBNz4TkD for ; Tue, 8 Aug 2023 17:50:16 +0000 (UTC) (envelope-from imb@protected-networks.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=protected-networks.net header.s=201508 header.b=UMpJvaTz; 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; dmarc=pass (policy=reject) header.from=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:content-language:references :subject:subject:user-agent:mime-version:date:date:message-id; s=201508; t=1691517012; bh=9O3dtq9p4PwxoOSbIZWh1QbYv0BZOHocZSdM DAgTP5o=; b=UMpJvaTzRwJ2YRY4QeNrTsj9Eo8HoWse3JaakcZXp5EQpnOGI5hO 8fD+u45DlIxr2Cj5AiDbKqxbkHiueQpX2r+jdvedws8z2O95t+C3UDTZaLkEigiz +wfGXAMfkeJGEEocNnuQTsrmtU8tfxQz0tAUW1aeTLyuSk7yf46o86A= Received: from [IPV6:2001:470:8d59:2:f21f:afff:fe66:957e] (toshi.auburn.protected-networks.net [IPv6:2001:470:8d59:2:f21f:afff:fe66:957e]) (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) (Authenticated sender: imb@mail.protected-networks.net) by mail.protected-networks.net (Postfix) with ESMTPSA id 702374E3AC for ; Tue, 8 Aug 2023 13:50:12 -0400 (EDT) Message-ID: <4f0fbb44-eebe-aa8f-f958-dcd678936fe1@protected-networks.net> Date: Tue, 8 Aug 2023 13:50:12 -0400 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:102.0) Gecko/20100101 Thunderbird/102.14.0 Subject: Re: [Intel AlderLake] Read&Write files to FAT32 or UFS partition cause data corrupt due to P-Core&E-Core To: freebsd-current@freebsd.org References: <59cbcfe2-cd53-69d8-65d6-7a79e656f494@FreeBSD.org> <1f968af1-1c57-9a09-7e01-145a5262e27f@FreeBSD.org> <20230806181238.858f58e25dfd0f99269cfe53@dec.sakura.ne.jp> <20230808063735.e8e1d3ede370a18f200a6f48@dec.sakura.ne.jp> <20230808224612.c3889d6e20b6fc980f5278cc@dec.sakura.ne.jp> <20230808235635.744e0e1c6a72face7fdf6a9b@dec.sakura.ne.jp> Content-Language: en-NZ From: Michael Butler In-Reply-To: <20230808235635.744e0e1c6a72face7fdf6a9b@dec.sakura.ne.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[protected-networks.net,reject]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_ALLOW(-0.20)[protected-networks.net:s=201508]; MIME_GOOD(-0.10)[text/plain]; ASN(0.00)[asn:5716, ipnet:202.12.127.0/24, country:US]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[protected-networks.net:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[] X-Spamd-Bar: --- X-Rspamd-Queue-Id: 4RL11N1QBNz4TkD On 8/8/23 10:56, Tomoaki AOKI wrote: > On Tue, 8 Aug 2023 17:02:32 +0300 > Konstantin Belousov wrote: [ .. snip .. ] >> The workaround is switched on automatically, when kernel detects 'small cores' >> reported by CPUID. > > If I read the code correctly, vm.pmap.pcid_invlpg_workaround > (precicely, the corresponding variable) is set to non-zero when the > workaround is enabled. Not sure it was detected correctly at the > original reporter's environment, but forcibly setting the tunable to 1 > didn't reported to help sufficiently. > Currently, only setting tunable vm.pmap.pcid_enabled to 0 could help. I'm seeing similar stability problems on an N95-based device. This too is an Alderlake-N device with only E-cores although I'm running it with a compilation with CPUTYPE=tremont .. from an older, verbose start-up .. PPIM 0: PA=0x4000000000, VA=0xffffffff82710000, size=0x1d5000, mode=0x1 pmap: large map 8 PML4 slots (4096 GB) VT(efifb): resolution 800x600 Preloaded elf kernel "/boot/kernel.new/kernel" at 0xffffffff8234e000. Preloaded boot_entropy_cache "/boot/entropy" at 0xffffffff82357d08. Preloaded cpu_microcode "/boot/firmware/intel-ucode.bin" at 0xffffffff82357d60. Preloaded hostuuid "/etc/hostid" at 0xffffffff82357dc0. Preloaded TSLOG data "TSLOG" at 0xffffffff82357e10. CPU: Intel(R) N95 (1689.60-MHz K8-class CPU) Origin="GenuineIntel" Id=0xb06e0 Family=0x6 Model=0xbe Stepping=0 Features=0xbfebfbff Features2=0x7ffafbbf AMD Features=0x2c100800 AMD Features2=0x121 Structured Extended Features=0x239ca7eb Structured Extended Features2=0x98c007bc Structured Extended Features3=0xfc184410 XSAVE Features=0xf IA32_ARCH_CAPS=0x180fd6b VT-x: Basic Features=0x3da0500 Pin-Based Controls=0xff Primary Processor Controls=0xfffbfffe Secondary Processor Controls=0x75d7fff Exit Controls=0x3da0500 Entry Controls=0x3da0500 EPT Features=0x6f34141 VPID Features=0xf01 TSC: P-state invariant, performance statistics 64-Byte prefetching L2 cache: 2048 kbytes, 16-way associative, 64 bytes/line real memory = 17179869184 (16384 MB) Physical memory chunk(s): 0x0000000000010000 - 0x000000000009dfff, 581632 bytes (142 pages) 0x000000000009f000 - 0x000000000009ffff, 4096 bytes (1 pages) 0x0000000000100000 - 0x000000005fffffff, 1609564160 bytes (392960 pages) 0x0000000062401000 - 0x000000007264dfff, 270848000 bytes (66125 pages) 0x0000000075fff000 - 0x0000000075ffffff, 4096 bytes (1 pages) 0x0000000100001000 - 0x0000000462497fff, 14533881856 bytes (3548311 pages) 0x000000047fa00000 - 0x000000047fb68fff, 1478656 bytes (361 pages) avail memory = 16363008000 (15604 MB) CPU microcode: updated from 0xc to 0x10 MADT: Found CPU APIC ID 0 ACPI ID 0: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 2 ACPI ID 1: enabled SMP: Added CPU 2 (AP) MADT: Found CPU APIC ID 4 ACPI ID 2: enabled SMP: Added CPU 4 (AP) MADT: Found CPU APIC ID 6 ACPI ID 3: enabled SMP: Added CPU 6 (AP) On start-up, vm.pmap.pcid_invlpg_workaround=1 but seemingly random faults still occurred under load, for example, 'make buildworld'. Apparent misreads of source-files resulting in syntax errors were the most common symptom. Compilation reattempts (mostly) succeed. Initially, I put this down to an inadequate power-supply but setting vm.pmap.pcid_enabled=0 seems to have stabilised it. I guess there's another dragon in there .. :-( Michael From nobody Tue Aug 8 17:55:59 2023 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 4RL1814XWXz4pt8d for ; Tue, 8 Aug 2023 17:56:01 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (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 4RL1812qk0z4WVh; Tue, 8 Aug 2023 17:56:01 +0000 (UTC) (envelope-from guru@unixarea.de) Authentication-Results: mx1.freebsd.org; none Received: from [178.254.4.75] (helo=webmail.1blu.de) by ms-10.1blu.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qTQw3-0006Ww-4K; Tue, 08 Aug 2023 19:55:59 +0200 Received: from ppp-188-174-60-42.dynamic.mnet-online.de ([188.174.60.42]) by webmail.1blu.de with HTTP (HTTP/1.1 POST); Tue, 08 Aug 2023 19:55:59 +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 Date: Tue, 08 Aug 2023 19:55:59 +0200 From: Matthias Apitz To: Graham Perrin Cc: freebsd-current@freebsd.org Subject: Re: 14.0 boot failure In-Reply-To: <884e4afa-4687-8785-fc48-f5fff9556b8e@freebsd.org> References: <884e4afa-4687-8785-fc48-f5fff9556b8e@freebsd.org> User-Agent: 1blu Webmail Message-ID: X-Sender: guru@unixarea.de Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 178.254.4.75 X-Rspamd-Queue-Id: 4RL1812qk0z4WVh X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:42730, ipnet:178.254.0.0/19, country:DE] A kernel git cloned on August 6 boots fine. -- Matthias Apitz E-mail: guru@unixarea.de WWW: http://www.unixarea.de/ phone: +49-170-4527211 Am 08.08.2023 19:39, schrieb Graham Perrin: > On 05/08/2023 00:45, Kevin Oberman wrote: >> A new kernel built from sources pulled today (4-Aug) at 5:26 UTC fails >> to boot. … > > I refrained from updating after reading this. > > Any news? > > TIA From nobody Wed Aug 9 06:10:23 2023 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 4RLKRj2fmFz4mFnF for ; Wed, 9 Aug 2023 06:10:41 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com [IPv6:2607:f8b0:4864:20::b2d]) (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 4RLKRj0hmHz4Hkg; Wed, 9 Aug 2023 06:10:41 +0000 (UTC) (envelope-from kob6558@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-yb1-xb2d.google.com with SMTP id 3f1490d57ef6-d1fb9107036so6914971276.0; Tue, 08 Aug 2023 23:10:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691561440; x=1692166240; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=m89HM2ms/GWdE3wQiUbCPa8MzT9HfhsAArDZnBnbpFo=; b=gtFCdr2wTa2hePdMmiZGzwhZ9YZqQxb2IJSp0BXheFytaPSAy/c3Ltb3FatVKBm171 doEA3riD4QUxxwGxoNVzGMsjGwn3ZaKKIDggjdAdmsooKuGR1htrvnUgpEEnQkX6aXyl wCO70T64Y010iZ5HFuhiX2V6uOtECyR0EfleBXrQP7AiB79G/Mp8pQLxLsIrp8HuV7qh ScVEl3qM5lZUUFMUpAPGdKvq3xIREkAvEt1+RD8hnrV/4ACSAYY+7V/voF8W/GqFViLB F9VzmoyoybCUdx3sTGeZ/nMkukwbJKAQFDfNM9eBkPwfXxNrvtSQeGupuIHBbqZcb0bW PWqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691561440; x=1692166240; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=m89HM2ms/GWdE3wQiUbCPa8MzT9HfhsAArDZnBnbpFo=; b=QUfxk3PR0nvk5alYe1u19SrIX2/CkfbZiNsuA4DhTxZzhPuuvh+ylA619lzLBUuqDK SGMneQNHiCoS3BENYHGdf0nfqES0KmiqsVIJ+un2n/ueRp2XbSvxX9bpywicd2mJpl1N fKiY/jWzeOtd9vIQnToEYq8Sr7kuTCK3MckHWkXF7dMtvIswosAJu+j0ebo8I8c3xmvK wlJ0QrowuPhodUWenFibE8rQv/cN7TaSC/sQaVCe/EtJLXxPUVtyrP7mi+/SQEdVVM/A RjacHhDDLhruqfSY9guzH8uK+P76VauAiTAfhXIyVOv1tzpPI8y/QuIE69sBBGBTddpm Rw6w== X-Gm-Message-State: AOJu0YxUWBW0wVJnyYowNfI6C5x/FiaQHIzw5jFDRDRbUNTMv9KXhIu8 gHE9EeBTrnTzzePK4l+0URmj/3U7KEaz0Nx5T0RSaxZc X-Google-Smtp-Source: AGHT+IGKuRg6WDa90cK/YVA9SSJavIkKu2haV0VPUI1aypK5GXoMWbitcOKUtX8d5BcLGrV1+daq5LiQaN2c/MOSP4w= X-Received: by 2002:a25:cf55:0:b0:d47:d267:26fe with SMTP id f82-20020a25cf55000000b00d47d26726femr1565199ybg.21.1691561439938; Tue, 08 Aug 2023 23:10:39 -0700 (PDT) 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: <884e4afa-4687-8785-fc48-f5fff9556b8e@freebsd.org> In-Reply-To: From: Kevin Oberman Date: Tue, 8 Aug 2023 23:10:23 -0700 Message-ID: Subject: Re: 14.0 boot failure To: Matthias Apitz Cc: Graham Perrin , freebsd-current@freebsd.org Content-Type: multipart/alternative; boundary="000000000000be4bff06027756fa" X-Rspamd-Queue-Id: 4RLKRj0hmHz4Hkg X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] --000000000000be4bff06027756fa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I closed the ticket. I think I may have pulled sources just as the MAXCPU size was updated. I did another pull the next day and it built and is running fine. On Tue, Aug 8, 2023 at 10:56=E2=80=AFAM Matthias Apitz w= rote: > > A kernel git cloned on August 6 boots fine. > > -- > Matthias Apitz > E-mail: guru@unixarea.de > WWW: http://www.unixarea.de/ > phone: +49-170-4527211 > > Am 08.08.2023 19:39, schrieb Graham Perrin: > > On 05/08/2023 00:45, Kevin Oberman wrote: > >> A new kernel built from sources pulled today (4-Aug) at 5:26 UTC fails > >> to boot. =E2=80=A6 > > > > I refrained from updating after reading this. > > > > Any news? > > > > TIA > > --=20 Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkoberman@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 --000000000000be4bff06027756fa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I closed the ticket. I think I may have pulled s= ources just as the MAXCPU size was updated. I did another pull the next day= and it built and is running fine.

On Tue, Aug 8, 2023 at 10:56=E2= =80=AFAM Matthias Apitz <guru@unixar= ea.de> wrote:

A kernel git cloned on August 6 boots fine.

--
Matthias Apitz
E-mail: guru@unixarea= .de
WWW: http://www.unixarea.de/
phone: +49-170-4527211

Am 08.08.2023 19:39, schrieb Graham Perrin:
> On 05/08/2023 00:45, Kevin Oberman wrote:
>> A new kernel built from sources pulled today (4-Aug) at 5:26 UTC f= ails
>> to boot. =E2=80=A6
>
> I refrained from updating after reading this.
>
> Any news?
>
> TIA



--
Kevin= Oberman, Part time kid herder and retired Network Engineer
E-mail: rkoberman@gmail.com
--000000000000be4bff06027756fa-- From nobody Wed Aug 9 06:22:32 2023 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 4RLKjm66nVz4mGkY for ; Wed, 9 Aug 2023 06:22:52 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-yw1-x1132.google.com (mail-yw1-x1132.google.com [IPv6:2607:f8b0:4864:20::1132]) (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 4RLKjk46Wcz4L6X for ; Wed, 9 Aug 2023 06:22:50 +0000 (UTC) (envelope-from kob6558@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20221208 header.b=k3u4Z467; spf=pass (mx1.freebsd.org: domain of kob6558@gmail.com designates 2607:f8b0:4864:20::1132 as permitted sender) smtp.mailfrom=kob6558@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-yw1-x1132.google.com with SMTP id 00721157ae682-58451f0fefeso74549077b3.3 for ; Tue, 08 Aug 2023 23:22:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691562169; x=1692166969; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=Z47ZkRsojEmnT6R165gGc12Yum/Y8w7iVWiSiYIKv+E=; b=k3u4Z467udZDRm7QQLIe+1qwN8C/rYGVfiCSyK1ocRrGLadcVhfUqJ1C3J+pRlOODS v38JXsavLNmm653JAlnlvgt7sDZamXtkY70EU8Pcfbt7xLgLVInW1Fy+sMpDobEcw/jv 87K3+FthlWvtc4EsKvrZ/Mh3vILzIKDlAq67iVxWjgnZNpzWRW9p1XfzOIowFRtQtYDm tpgp3FJspzAsfkhYO6+l3WB1G+qVXRi9wchek6JvCTQEaCoYglHovIQgApqPH/s8fVpm l1gJhsis/8tIQ4baq7l5+bsdMTDW3FfjcbB8KTBQVIHXkIDeLuK6YVb2mQ4/9pVbyzaJ 6nFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691562169; x=1692166969; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Z47ZkRsojEmnT6R165gGc12Yum/Y8w7iVWiSiYIKv+E=; b=RpwsHRVdakGBc+c//ga+Jb1l9Pp54p2BQvMZ8gR9rdHZ/wETtV2RB41W5dP7ik/e20 DLEzyB970WWLH0bAeEXo8Sv2+LL3W1/MYplSMEQfBC66MONCcyt8EDSemD9IgInvPKXw yKQz0wx9Zd97uVdq5WuTilXP8eDtmudr201ecyJ9nfpiWYdsI5FkwTK+JEdJyNUsvBAN ZkYE2qIG2SHYThN0eoUEx/aUlzx05HY5Hi0MDSQNfi+RKPEbRxwJyKix6oF6nXyDtLGk hezE73LjctNEcrMhnp15FkiX4zLSHsjyY7R9roROW36MMDcGes+UO2yP6P+Tt7Xm4osm 1kWg== X-Gm-Message-State: AOJu0YwOztWNYmkVDMof6koReAhoa3l1b3CZwcZ4UCSpKe0S6AzseSRx 8FlARiJZPLRaOGoA8UbI4e5m390PIjxmwQDlo90= X-Google-Smtp-Source: AGHT+IGoAie4a2kWFyWM5xnUAUXAKfm0QHSJ6tkMqMFjz7zY98qQ5+SMxpccjQifVvn5kkprAIXMTAuvDj7/GmVwt1s= X-Received: by 2002:a5b:48b:0:b0:d0a:127e:7478 with SMTP id n11-20020a5b048b000000b00d0a127e7478mr1514832ybp.44.1691562169303; Tue, 08 Aug 2023 23:22:49 -0700 (PDT) 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: <7A0E604D-EF40-4F10-B597-F1F076507192@gmail.com> In-Reply-To: From: Kevin Oberman Date: Tue, 8 Aug 2023 23:22:32 -0700 Message-ID: Subject: Re: Has the update procedure changed? To: Matthias Apitz , Kevin Oberman , Tim Kellers , freebsd-current@freebsd.org Content-Type: multipart/alternative; boundary="0000000000003784f1060277821d" X-Spamd-Result: default: False [-2.70 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FORGED_SENDER(0.30)[rkoberman@gmail.com,kob6558@gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20221208]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[rkoberman@gmail.com,kob6558@gmail.com]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_TO(0.00)[unixarea.de,gmail.com,freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1132:from]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org] X-Spamd-Bar: -- X-Rspamd-Queue-Id: 4RLKjk46Wcz4L6X --0000000000003784f1060277821d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Aug 7, 2023 at 9:12=E2=80=AFAM Matthias Apitz wr= ote: > El d=C3=ADa lunes, agosto 07, 2023 a las 08:51:55a. m. -0700, Kevin Oberm= an > escribi=C3=B3: > > > On Sun, Aug 6, 2023 at 9:51=E2=80=AFAM Tim Kellers w= rote: > > > > > > > > > > > On Aug 6, 2023, at 11:05 AM, Kevin Oberman > wrote: > > > > > > =EF=BB=BF > > > On Sat, Aug 5, 2023 at 10:51=E2=80=AFPM Matthias Apitz > wrote: > > > > > >> In the past I was used to use the following procedure to install a n= ew > > >> kernel and world: > > >> > > >> # cd /usr/src > > >> # make installkernel > > >> # shutdown -r now > > >> > > >> boot -s from the loader prompt > > >> > > >> # adjkerntz -i > > >> # mount -a -t ufs > > >> # mergemaster -p > > >> # cd /usr/src > > >> # make installworld > > >> # mergemaster > > >> # yes | make delete-old > > >> # yes | make delete-old-libs > > >> > > >> # reboot > > >> > > ... > > > I am more confused about "etcupdate -p". Both files put it after the > > kernel installation and reboot but before the installworld. The man pag= e > > for etcupdate says that '-p' it should be run before "make buildworld" > and > > I have always followed the man pages. > > The man page of mergemaster says: > > -p Pre-buildworld mode. > " > > i.e. it must be run after installkernel and before installworld to > adjust the new /etc/group and /etc/master.passwd. After installworld > mergemaster > should be run (or etcupdate) without -p to adjust all the scripts below > /etc, /etc/rc.d/ ... I've used this procedure above for many years and > it always let me decide it I want the new or the old or deal later with > the diff of all these files. And so I did it yesterday and it worked fine > again. > > Will check the next time what etcupdate wants to do, because it seems > the sucsessor of mergemaster. > > matthias > > -- > Matthias Apitz, =E2=9C=89 guru@unixarea.de, http://www.unixarea.de/ > +49-176-38902045 > Public GnuPG key: http://www.unixarea.de/key.pub > etcupdate is the successor to mergemaster. It is vastly better, but does have a learning curve when you first start using it. Also, it has quite a few commands that are seldom needed and I think that intimidates people a bit. Unless you understand a three-way merge, it is confusing. It's not complicated, but different from mergemster. (freebsd-update always has done a three-way merge.) I don't see how you get this from the man page. "Compares only files known to be essential to the success of {build|install}world, i.e., /etc/group and /etc/master.passwd. If it is potentially updating files that MIGHT be essential to a successful buildworld, running it after buildkernel seems quite wrong. At least I read {build|install}world as buildworld or installworld. --=20 Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkoberman@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 --0000000000003784f1060277821d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
El d=C3=ADa lunes, agosto 07, 2023 a las = 08:51:55a. m. -0700, Kevin Oberman escribi=C3=B3:

> On Sun, Aug 6, 2023 at 9:51=E2=80=AFAM Tim Kellers <smsdtv@gmail.com> wrote:
>
> >
> >
> > On Aug 6, 2023, at 11:05 AM, Kevin Oberman <rkoberman@gmail.com> wrote: > >
> > =EF=BB=BF
> > On Sat, Aug 5, 2023 at 10:51=E2=80=AFPM Matthias Apitz <guru@unixarea.de> wr= ote:
> >
> >> In the past I was used to use the following procedure to inst= all a new
> >> kernel and world:
> >>
> >>=C2=A0 =C2=A0 =C2=A0# cd /usr/src
> >>=C2=A0 =C2=A0 =C2=A0# make installkernel
> >>=C2=A0 =C2=A0 =C2=A0# shutdown -r now
> >>
> >>=C2=A0 =C2=A0 =C2=A0boot -s from the loader prompt
> >>
> >>=C2=A0 =C2=A0 =C2=A0# adjkerntz -i
> >>=C2=A0 =C2=A0 =C2=A0# mount -a -t ufs
> >>=C2=A0 =C2=A0 =C2=A0# mergemaster -p
> >>=C2=A0 =C2=A0 =C2=A0# cd /usr/src
> >>=C2=A0 =C2=A0 =C2=A0# make installworld
> >>=C2=A0 =C2=A0 =C2=A0# mergemaster
> >>=C2=A0 =C2=A0 =C2=A0# yes | make delete-old
> >>=C2=A0 =C2=A0 =C2=A0# yes | make delete-old-libs
> >>
> >>=C2=A0 =C2=A0 =C2=A0# reboot
> >>
> ...

> I am more confused about=C2=A0 "etcupdate -p". Both files pu= t it after the
> kernel installation and reboot but before the installworld. The man pa= ge
> for etcupdate says that '-p' it should be run before "mak= e buildworld" and
> I have always followed the man pages.

The man page of mergemaster says:

=C2=A0 =C2=A0 =C2=A0-p=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Pre-buildworld mod= e.=C2=A0
"

i.e. it must be run after installkernel and before installworld to
adjust the new /etc/group and /etc/master.passwd. After installworld mergem= aster
should be run (or etcupdate) without -p to adjust all the scripts below
/etc, /etc/rc.d/ ... I've used this procedure above for many years and<= br> it always let me decide it I want the new or the old or deal later with
the diff of all these files. And so I did it yesterday and it worked fine a= gain.

Will check the next time what etcupdate wants to do, because it seems
the sucsessor of mergemaster.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 matthias

--
Matthias Apitz, =E2=9C=89 guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub

etcupdate is the successor t= o mergemaster.=C2=A0 It is vastly better, but does have a learning curve wh= en you first start using it. Also, it has quite a few commands that are sel= dom needed and I think that intimidates people a bit. Unless you understand= a three-way merge, it is confusing. It's not complicated, but differen= t from mergemster. (freebsd-update always has done a three-way merge.)
<= /div>

I don't see how you get this from th= e man page.
"Compares only files known to be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0essential to = the success of {build|install}world, i.e.,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/etc/group an= d /etc/master.passwd.

If it is potential= ly updating files that MIGHT be essential to a successful buildworld, runni= ng it after buildkernel seems quite wrong. At least I read {build|install}w= orld as buildworld or installworld.

--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-ma= il: rkoberman@gmai= l.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B= 055683
--0000000000003784f1060277821d-- From nobody Wed Aug 9 09:38:42 2023 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 4RLQ3r60Hgz4mThc for ; Wed, 9 Aug 2023 09:38:48 +0000 (UTC) (envelope-from void@f-m.fm) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (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 4RLQ3q4Yvnz3D98 for ; Wed, 9 Aug 2023 09:38:47 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm3 header.b=cWn3hFAe; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=t9mLPHnB; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 64.147.123.25 as permitted sender) smtp.mailfrom=void@f-m.fm; dmarc=pass (policy=none) header.from=f-m.fm Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id BFBF33200931 for ; Wed, 9 Aug 2023 05:38:45 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Wed, 09 Aug 2023 05:38:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-type:content-type:date:date:from:from:in-reply-to :message-id:mime-version:reply-to:sender:subject:subject:to:to; s=fm3; t=1691573925; x=1691660325; bh=5mUpllCq4epPdAN9akZqOw4GJ pRxB9KVYCARdMesZjc=; b=cWn3hFAe3m1ZEhBvqULTekOJ/QYk7N70pJd3uVUsU 6wado2QwJ2AuXnlWBY4TXWbNkVQ9/2daEQ1h9UGdGvvqMbFBkhtDy65ejcGFrQ5e S7es0FDKlekbTC2vwuHkgxLOTC8rYGV2wDUZPf0a4MNSQf8rHXt2BN8gko62s1zY Vnw6kCPIAGUAXzyIy04pcsLXXfeZEL+D2IXVSJ0pj4kTcRmtdllLrq9Hu/EuiU3x qHw0KINv//YBvbEYaLc2XfxKGmmvpD2L8/FGCzk3ArG20SGeECVjFNt9MzupUu05 tth/ppfLOrmL4uBxYaLO0RhyOcDilatqIoawhdCtu9QwA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:message-id :mime-version:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1691573925; x=1691660325; bh=5mUpllCq4epPdAN9akZqOw4GJpRxB9KVYCA RdMesZjc=; b=t9mLPHnBl8W3s5hcI9rLItlz4hDRbbsZ5gQmYzPG5GJUx9tPIAR DqswnOlEo1SsH1MmXPaQwHHbJSjEJTcti96fRnFOPtBQT8VDbE6rGUfrD9acdLBW AbAazqeoifUE2n1QxlWf8aRYQ+SKftUdBLu8CxCGI5bdfyMPExHlHSTKwiJZjaJn UK/Hi2KCV+2h7+RByzxdHLAn1y4zoNAq8c15iGMKW6S664t+LXw1wQKLczM5UdUH t573I3lcwXdOiG5a3b9qlcGUWLR8kztTZoBo4d8YGvzdl6HZfE3EEifwdIJbEa+O fDSmkbBrXOHbJdGQSXzLKazbDwtoHFFeSXw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrleeggddujecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfggtggusehttdertddttd dvnecuhfhrohhmpehvohhiugcuoehvohhiugesfhdqmhdrfhhmqeenucggtffrrghtthgv rhhnpeevudffiedvffffgffhgeefjeefffdtieetheetkeefhfdvfefgtedtueehgeffue enucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehvohhi ugesfhdqmhdrfhhm X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Wed, 9 Aug 2023 05:38:44 -0400 (EDT) Date: Wed, 9 Aug 2023 10:38:42 +0100 From: void To: freebsd-current@freebsd.org Subject: qt6 the default qt on -current? Message-ID: 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; format=flowed Content-Disposition: inline X-Spamd-Result: default: False [-3.47 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; NEURAL_HAM_SHORT(-0.87)[-0.868]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm3,messagingengine.com:s=fm3]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.25]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.25:from]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; RCPT_COUNT_ONE(0.00)[1]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FREEMAIL_FROM(0.00)[f-m.fm]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; RWL_MAILSPIKE_POSSIBLE(0.00)[64.147.123.25:from]; ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US]; FROM_HAS_DN(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[] X-Spamd-Bar: --- X-Rspamd-Queue-Id: 4RLQ3q4Yvnz3D98 Hello list, How can I build making qt6 the default Qt? I'm using poudriere to build. I can see that for some ports there's a 'uses: qt6' that goes in the port. What I was looking for was a default string I can use with a poudriere make.conf like there is for python or perl. ty -- From nobody Wed Aug 9 10:40:31 2023 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 4RLRRF1RFlz4pm60 for ; Wed, 9 Aug 2023 10:40:41 +0000 (UTC) (envelope-from SRS0=y0si=D2=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (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 4RLRRD2Hncz3Mtv for ; Wed, 9 Aug 2023 10:40:40 +0000 (UTC) (envelope-from SRS0=y0si=D2=quip.cz=000.fbsd@elsa.codelab.cz) Authentication-Results: mx1.freebsd.org; none Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id B5357D7893; Wed, 9 Aug 2023 12:40:32 +0200 (CEST) Received: from [192.168.145.49] (ip-89-177-27-225.bb.vodafone.cz [89.177.27.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id D450DD7887; Wed, 9 Aug 2023 12:40:31 +0200 (CEST) Message-ID: <3f8ab464-c9c9-b637-5cc6-c14f25f055b0@quip.cz> Date: Wed, 9 Aug 2023 12:40:31 +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:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: Has the update procedure changed? Content-Language: cs-Cestina, en-US To: Kevin Oberman , Matthias Apitz , freebsd-current@freebsd.org References: <7A0E604D-EF40-4F10-B597-F1F076507192@gmail.com> From: Miroslav Lachman <000.fbsd@quip.cz> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4RLRRD2Hncz3Mtv X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:42000, ipnet:94.124.104.0/21, country:CZ] On 09/08/2023 08:22, Kevin Oberman wrote: > I don't see how you get this from the man page. > "Compares only files known to be >                  essential to the success of {build|install}world, i.e., >                  /etc/group and /etc/master.passwd. > > If it is potentially updating files that MIGHT be essential to a > successful buildworld, running it after buildkernel seems quite wrong. > At least I read {build|install}world as buildworld or installworld. Correct me if I am wrong but AFAIK etcupdate -p (or mergemaster -p) updates entries in [master.]passwd and group which are only needed to install new files with the right owner and group set, not to build these files. (installkernel installs everything ass root:wheel) Also Makefile contains this steps where mergemaster -p should be run after installkernel and reboot: 2. `make buildworld' 3. `make buildkernel KERNCONF=YOUR_KERNEL_HERE' (default is GENERIC). 4. `make installkernel KERNCONF=YOUR_KERNEL_HERE' (default is GENERIC). [steps 3. & 4. can be combined by using the "kernel" target] 5. `reboot' (in single user mode: boot -s from the loader prompt). 6. `mergemaster -p' 7. `make installworld' And man page for etcpupdate -p has this: -p Enable “pre-world” mode. Only merge changes to files that are necessary to successfully run ‘make installworld’ or ‘make installkernel Kind regards Miroslav Lachman From nobody Wed Aug 9 10:45:26 2023 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 4RLRXp5VjWz4pmX3 for ; Wed, 9 Aug 2023 10:45:30 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (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 4RLRXp4nPCz3Pj5 for ; Wed, 9 Aug 2023 10:45:30 +0000 (UTC) (envelope-from guru@unixarea.de) Authentication-Results: mx1.freebsd.org; none Received: from [132.174.172.2] (helo=pureos) by ms-10.1blu.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qTggy-0000TJ-UA; Wed, 09 Aug 2023 12:45:28 +0200 Date: Wed, 9 Aug 2023 12:45:26 +0200 From: Matthias Apitz To: Miroslav Lachman <000.fbsd@quip.cz> Cc: Kevin Oberman , freebsd-current@freebsd.org Subject: Re: Has the update procedure changed? Message-ID: Reply-To: Matthias Apitz Mail-Followup-To: Miroslav Lachman <000.fbsd@quip.cz>, Kevin Oberman , freebsd-current@freebsd.org References: <7A0E604D-EF40-4F10-B597-F1F076507192@gmail.com> <3f8ab464-c9c9-b637-5cc6-c14f25f055b0@quip.cz> 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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3f8ab464-c9c9-b637-5cc6-c14f25f055b0@quip.cz> X-Operating-System: FreeBSD 13.0-CURRENT r368166 (amd64) X-message-flag: Mails containing HTML will not be read! Please send only plain text. X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 132.174.172.2 X-Rspamd-Queue-Id: 4RLRXp4nPCz3Pj5 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:42730, ipnet:178.254.0.0/19, country:DE] El día miércoles, agosto 09, 2023 a las 12:40:31 +0200, Miroslav Lachman escribió: > On 09/08/2023 08:22, Kevin Oberman wrote: > > > I don't see how you get this from the man page. > > "Compares only files known to be > >                  essential to the success of {build|install}world, i.e., > >                  /etc/group and /etc/master.passwd. > > > > If it is potentially updating files that MIGHT be essential to a > > successful buildworld, running it after buildkernel seems quite wrong. > > At least I read {build|install}world as buildworld or installworld. > > Correct me if I am wrong but AFAIK etcupdate -p (or mergemaster -p) updates > entries in [master.]passwd and group which are only needed to install new > files with the right owner and group set, not to build these files. > (installkernel installs everything ass root:wheel) > > Also Makefile contains this steps where mergemaster -p should be run after > installkernel and reboot: > > 2. `make buildworld' > 3. `make buildkernel KERNCONF=YOUR_KERNEL_HERE' (default is GENERIC). > 4. `make installkernel KERNCONF=YOUR_KERNEL_HERE' (default is GENERIC). > [steps 3. & 4. can be combined by using the "kernel" target] > 5. `reboot' (in single user mode: boot -s from the loader prompt). > 6. `mergemaster -p' > 7. `make installworld' > > > And man page for etcpupdate -p has this: > > -p Enable “pre-world” mode. Only merge changes to files > that are necessary to successfully run ‘make > installworld’ or ‘make installkernel Yes, exactly. Running mergemaster -p or (etcupdate -p) before 'make buildworld' does not make any sense. matthias -- Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub From nobody Wed Aug 9 12:38:22 2023 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 4RLV3B4d7dz4pvVf for ; Wed, 9 Aug 2023 12:38:30 +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 4RLV381Cjnz3YVj for ; Wed, 9 Aug 2023 12:38:27 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; dkim=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; dmarc=none Received: from kalamity.joker.local (123-1-88-210.area1b.commufa.jp [123.1.88.210]) (authenticated bits=0) by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 379CcMYe093952 for ; Wed, 9 Aug 2023 21:38:23 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Wed, 9 Aug 2023 21:38:22 +0900 From: Tomoaki AOKI To: freebsd-current@freebsd.org Subject: Re: Has the update procedure changed? Message-Id: <20230809213822.950a3c337ec86c102dcbd235@dec.sakura.ne.jp> In-Reply-To: References: <7A0E604D-EF40-4F10-B597-F1F076507192@gmail.com> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.2) 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=UTF-8 Content-Transfer-Encoding: 8bit X-Spamd-Result: default: False [0.89 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; AUTH_NA(1.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-0.46)[-0.465]; NEURAL_HAM_MEDIUM(-0.14)[-0.143]; MIME_GOOD(-0.10)[text/plain]; ONCE_RECEIVED(0.10)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[sakura.ne.jp]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_NA(0.00)[no SPF record]; RCVD_COUNT_ONE(0.00)[1]; HAS_ORG_HEADER(0.00)[]; TO_DN_NONE(0.00)[]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org] X-Spamd-Bar: / X-Rspamd-Queue-Id: 4RLV381Cjnz3YVj On Tue, 8 Aug 2023 23:22:32 -0700 Kevin Oberman wrote: > On Mon, Aug 7, 2023 at 9:12 AM Matthias Apitz wrote: > > > El día lunes, agosto 07, 2023 a las 08:51:55a. m. -0700, Kevin Oberman > > escribió: > > > > > On Sun, Aug 6, 2023 at 9:51 AM Tim Kellers wrote: > > > > > > > > > > > > > > > On Aug 6, 2023, at 11:05 AM, Kevin Oberman > > wrote: > > > > > > > >  > > > > On Sat, Aug 5, 2023 at 10:51 PM Matthias Apitz > > wrote: > > > > > > > >> In the past I was used to use the following procedure to install a new > > > >> kernel and world: > > > >> > > > >> # cd /usr/src > > > >> # make installkernel > > > >> # shutdown -r now > > > >> > > > >> boot -s from the loader prompt > > > >> > > > >> # adjkerntz -i > > > >> # mount -a -t ufs > > > >> # mergemaster -p > > > >> # cd /usr/src > > > >> # make installworld > > > >> # mergemaster > > > >> # yes | make delete-old > > > >> # yes | make delete-old-libs > > > >> > > > >> # reboot > > > >> > > > ... > > > > > I am more confused about "etcupdate -p". Both files put it after the > > > kernel installation and reboot but before the installworld. The man page > > > for etcupdate says that '-p' it should be run before "make buildworld" > > and > > > I have always followed the man pages. > > > > The man page of mergemaster says: > > > > -p Pre-buildworld mode. > > > " > > > > > i.e. it must be run after installkernel and before installworld to > > adjust the new /etc/group and /etc/master.passwd. After installworld > > mergemaster > > should be run (or etcupdate) without -p to adjust all the scripts below > > /etc, /etc/rc.d/ ... I've used this procedure above for many years and > > it always let me decide it I want the new or the old or deal later with > > the diff of all these files. And so I did it yesterday and it worked fine > > again. > > > > Will check the next time what etcupdate wants to do, because it seems > > the sucsessor of mergemaster. > > > > matthias > > > > -- > > Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ > > +49-176-38902045 > > Public GnuPG key: http://www.unixarea.de/key.pub > > > > etcupdate is the successor to mergemaster. It is vastly better, but does > have a learning curve when you first start using it. Also, it has quite a > few commands that are seldom needed and I think that intimidates people a > bit. Unless you understand a three-way merge, it is confusing. It's not > complicated, but different from mergemster. (freebsd-update always has done > a three-way merge.) > > I don't see how you get this from the man page. > "Compares only files known to be > essential to the success of {build|install}world, i.e., > /etc/group and /etc/master.passwd. > > If it is potentially updating files that MIGHT be essential to a successful > buildworld, running it after buildkernel seems quite wrong. At least I read > {build|install}world as buildworld or installworld. > > -- > Kevin Oberman, Part time kid herder and retired Network Engineer > E-mail: rkoberman@gmail.com > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 Please correct me if I'm missing something. I use source update for years and not using bsdinstall nor freebsd-update. Does bsdinstall (and/or freebsd-update) create the first current tree for etcupdate, if not yet exists? This would be most confusing and harmful point of etcupdate. When I first tried etcupdate, I didn't noticed that I needed `etcupdate extract -B` BEFORE UPDATING src tree. Without this, etcupdate cannot detect what should be updated, even if a plenty of updates are required. At the moment, I must use mergemaster, and after that, `etcupdate extract -B` for next run. I think bsdinstall can create current tree, which is turned over to old tree on actual run, for etcupdate. So do freebsd-update. It would be able to create current tree JUST BEFORE INSTALLING UPDATE. I was helped by mergemaster, but after it completely retires, features above should be mandatory. -- Tomoaki AOKI From nobody Wed Aug 9 12:48:24 2023 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 4RLVH21z1Rz4pwKW for ; Wed, 9 Aug 2023 12:48:46 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: from hsmtpd-fgn.xspmail.jp (hsmtpd-fgn.xspmail.jp [210.130.137.10]) (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 4RLVGz1srYz3cZq for ; Wed, 9 Aug 2023 12:48:42 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=j.email.ne.jp header.s=x01 header.b=TJCDkPNg; spf=pass (mx1.freebsd.org: domain of ota@j.email.ne.jp designates 210.130.137.10 as permitted sender) smtp.mailfrom=ota@j.email.ne.jp; dmarc=pass (policy=none) header.from=j.email.ne.jp DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1691585312; d=j.email.ne.jp; s=x01; i=ota@j.email.ne.jp; h=content-transfer-encoding:content-type:mime-version:references:in-reply-to: message-id:subject:cc:to:from:date:from; bh=sgjv+SBX9RuD1yccUmwM1CWlFKD+VG2WNy8S1hKwZI4=; b=TJCDkPNgkMA8HChSFi6CZzYywUNX5zfmza7WqYEebZCU+GS2N7LM8eUKvcPt6WqE8CXRqWPwns1oO oUnVyvEpu2xY+l0BPmGwhhizLFloVMpiG1O7jHmSs9yaW9RJqluEsbTiMfOwS7lAOT2QEncYb3g+/Q dN9doz8CJ0ECk0fQvRGxyxiW+Ehd8jLgNwj14jmFFEUAcvGTi5Dxo2C5AnyUeNmlVTwJXNA3TvVa0W 4aj5HGrtQBR+orlZgluBtliEZIAnT3c2b/hg3L3m82Jljb1ZanShglT5xxvShi+JfxbDnOPyG/s7Lt hn10+p7qzsA6I6jr4qu4Mwyo6nMRtQw== X-Country-Code: US Received: from a315-53 (unknown [38.98.216.75]) by hsmtpd-out-1.asahinet.cluster.xspmail.jp (Halon) with ESMTPA id 211d894c-d73e-46f3-a9c7-9c853ec4d640; Wed, 09 Aug 2023 21:48:31 +0900 (JST) Date: Wed, 9 Aug 2023 08:48:24 -0400 From: Yoshihiro Ota To: Warner Losh Cc: Yuri , FreeBSD Current Subject: Re: Jail compile error on CURRENT? Message-Id: <20230809084824.1d8a7c2928d469a49f719070@j.email.ne.jp> In-Reply-To: References: <20230806225055.bbccc4fc13e41f50ec524621@j.email.ne.jp> <73d081d7-5df6-9fe4-659d-edb191c94be4@aetern.org> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd12.2) 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-Spamd-Result: default: False [-2.50 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[j.email.ne.jp,none]; R_SPF_ALLOW(-0.20)[+ip4:210.130.137.0/27]; R_DKIM_ALLOW(-0.20)[j.email.ne.jp:s=x01]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:2497, ipnet:210.130.0.0/16, country:JP]; MIME_TRACE(0.00)[0:+]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[j.email.ne.jp:+]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROM(0.00)[] X-Spamd-Bar: -- X-Rspamd-Queue-Id: 4RLVGz1srYz3cZq On Mon, 7 Aug 2023 21:32:03 -0600 Warner Losh wrote: > On Mon, Aug 7, 2023, 5:55 PM Yuri wrote: > > > James Gritton wrote: > > > On 2023-08-07 13:29, Dimitry Andric wrote: > > >> On 7 Aug 2023, at 04:50, Yoshihiro Ota wrote: > > >>> > > >>> Am I the only one seeing this error? > > >>> I'm on 12.4-RELEASE amd64 and building CURRENT as of now. > > >>> > > >>> jaillex.c:2228:43: error: unused parameter 'yyscanner' > > >>> [-Werror,-Wunused-parameter] > > >>> void *yyalloc (yy_size_t size , yyscan_t yyscanner) > > >>> ^ > > >>> jaillex.c:2233:58: error: unused parameter 'yyscanner' > > >>> [-Werror,-Wunused-parameter] > > >>> void *yyrealloc (void * ptr, yy_size_t size , yyscan_t yyscanner) > > >>> ^ > > >>> jaillex.c:2245:36: error: unused parameter 'yyscanner' > > >>> [-Werror,-Wunused-parameter] > > >>> void yyfree (void * ptr , yyscan_t yyscanner) > > >>> ^ > > >>> 6 errors generated. > > >>> *** [jaillex.o] Error code 1 > > >>> > > >> > > >> It seems you are not crazy. :) I can reproduce the error, and I think it > > >> might be caused by: > > >> > > >> > > https://cgit.freebsd.org/src/commit/?id=086e0149ae56641af245ce472e787c2f67d3aea5 > > >> > > >> However, as to why this does not result in an error (or even a warning) > > >> on -CURRENT, I have no clue. Maybe in the mean time flex in -CURRENT got > > >> updated... > > > > > > That is indeed the culprit. Fortunately, it builds from 13.2-RELEASE, > > > so building CURRENT from 12 can be done in two steps. I hate to be the > > > reason the update doesn't work directly, but the include capability I > > > added to jail(8) requires re-entrant lex, which apparently managed to > > > work around the error in 13. They reason it doesn't give a warning BTW > > > is these two lines that lex adds: > > > > > > struct yyguts_t * yyg = (struct yyguts_t*)yyscanner; > > > (void)yyg; > > > > > > That makes yyscanner officially "used" even though its value is never > > > actually read. I suspect the version of lex in 12.4-RELEASE doesn't > > > have one or both of those lines. > > > > > > Perhaps you could add such lines to the offending functions yourself, > > > and continue the make. Or maybe build (and install) lex on its own > > > first; by the time you see this error, there should already be a newer > > > version of lex you could pop into place. > > > > > > There's probably something I should do to make this work better, or > > > perhaps some note I should put into UPDATING before 14.0 is released. > > > > Or there is already a recipe for bootstrapping lex in Makefile.inc1, > > though for somewhat older versions; possibly it could be updated for < 13? > > > > .if ${BOOTSTRAPPING} < 1000033 > > > > > When in doubt, adding BOOTSTRAPPING=0 can help...not sure why you'd need to > bootstrap lex though... > > Warner > Hi, thanks for many inputs. In short, 1. the toolchain lex doesn't work as is, 2. there are other errors I didn't paste originally and failing. In more details, I tried few ways to kick off lex toolchain build but still getting errors. The 2 belows are examples only 2 of my attempts while I tried few other ways to set this on. Try #1: ``` % setenv BOOTSTRAPPING 0 % make buildworld -j 4 ``` Try #2: ``` --- a/Makefile.inc1 +++ b/Makefile.inc1 @@ -2305,7 +2305,7 @@ _zic= usr.sbin/zic # If you add a new bootstrap tool where we could also use the host version, # please ensure that you also add a .else case where you add the tool to the # _bootstrap_tools_links variable. -.if ${BOOTSTRAPPING} < 1000033 +.if ${BOOTSTRAPPING} < 1300033 # Note: lex needs m4 to build but m4 also depends on lex (which needs m4 to # generate any files). To fix this cyclic dependency we can build a bootstrap # version of m4 (with pre-generated files) then use that to build the real m4 ``` So, I looked at the generated file and grabbed one of function here: ``` void *yyalloc (yy_size_t size , yyscan_t yyscanner) { return (void *) malloc( size ); } ``` With above 2 and more attemps, I still kept getting the same error. So, I decided to fix my PATH (and started compiling usr.sbin/lex only) as below. This resulted picking up local lex and generated code looks a bit better. But there are few other errors as you can see below. (I had it originally but failed/missed to copy&paste sending the 1st email) ``` % find /usr/obj/usr/src/amd64.amd64/ -name lex -type f /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin/lex /usr/obj/usr/src/amd64.amd64/tmp/obj-tools/usr.bin/lex/lex % setenv PATH /usr/obj/usr/src/amd64.amd64/tmp/obj-tools/usr.bin/lex:$PATH % cd /usr/src/usr.sbin/jail % make cc -O2 -pipe -fno-common -I. -I/usr/src/usr.sbin/jail -DINET6 -DINET -fPIE -g -gz=zlib -MD -MF.depend.jaillex.o -MTjaillex.o -std=gnu99 -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Wnested-externs -Wold-style-definition -Wno-pointer-sign -Wdate-time -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unus ed-const-variable -Qunused-arguments -c jaillex.c -o jaillex.o jaillex.c:845:1: error: declaration shadows a variable in the global scope [-Werror,-Wshadow] YY_DECL ^ /usr/src/usr.sbin/jail/jaillex.l:41:36: note: expanded from macro 'YY_DECL' #define YY_DECL int yylex(YYSTYPE *yylval, yyscan_t yyscanner) ^ ./y.tab.h:19:16: note: previous declaration is here extern YYSTYPE yylval; ^ /usr/src/usr.sbin/jail/jaillex.l:159:59: error: declaration shadows a variable in the global scope [-Werror,-Wshadow] text2lval(size_t triml, size_t trimr, int tovar, YYSTYPE *yylval, ^ ./y.tab.h:19:16: note: previous declaration is here extern YYSTYPE yylval; ^ 2 errors generated. *** Error code 1 Stop. ``` From nobody Wed Aug 9 13:00:23 2023 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 4RLVXY3NSnz4pwqc for ; Wed, 9 Aug 2023 13:00:29 +0000 (UTC) (envelope-from sm@codenetworks.net) Received: from relayout02-q02.dominioabsoluto.net (relayout02-q02.dominioabsoluto.net [217.116.26.71]) (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 4RLVXX0DKPz3fw7 for ; Wed, 9 Aug 2023 13:00:28 +0000 (UTC) (envelope-from sm@codenetworks.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=codenetworks.net header.s=domabs header.b=pETPz1mP; spf=pass (mx1.freebsd.org: domain of sm@codenetworks.net designates 217.116.26.71 as permitted sender) smtp.mailfrom=sm@codenetworks.net; dmarc=none Received: from relayout02-redir.dominioabsoluto.net (relayout02-redir.dominioabsoluto.net [217.116.26.75]) by relayout02.dominioabsoluto.net (Postfix) with ESMTP id 4RLVXS3Gf6zlWyZ; Wed, 9 Aug 2023 15:00:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=codenetworks.net; s=domabs; t=1691586024; bh=nddpXKji41FXMSKl52mCHZ7RK4PmCH/FctYaS2PZ7A8=; h=Date:Subject:To:References:From:In-Reply-To:From; b=pETPz1mPB7RfE8t2RG7lKcjQEYa1AY+dw255Xx6M+XJV3pVbk5fv/GA4pJ3ruEEjf qm4L3D95Re3GLui2M8YSmUVvLeldws7HN4FJuQzWjmMjKw1GhMSKMQC+ydPCjBjR1u l7HrDq9Y1SBHDq/igDT7llM1Py6AzEX1vR37vPQQ= Received: from [192.168.3.100] (unknown [5.159.168.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: sm.codenetworks.net) by relayout02-dsp.dominioabsoluto.net (Postfix) with ESMTPSA id 4RLVXS16HHzlX0c; Wed, 9 Aug 2023 15:00:24 +0200 (CEST) Message-ID: Date: Wed, 9 Aug 2023 15:00:23 +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:102.0) Gecko/20100101 Thunderbird/102.13.1 Subject: Re: Bhyve NIC Passthru broken Content-Language: en-US To: skorpio dr , freebsd-current@freebsd.org, Michael Dexter References: From: Santiago Martinez In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-PostalOut-Country: IP: 5.159.168.225 | Country: ES X-PostalOut-Information: AntiSPAM and AntiVIRUS on relayout02 X-PostalOut-MsgID: 4RLVXS16HHzlX0c.A355C X-PostalOut-SpamCheck: no es spam, clean X-PostalOut-From: sm@codenetworks.net X-PostalOut-Watermark: 1692190824.33059@FMsGre/Xig970pOQl6pqDw X-Spam-Status: No X-Spamd-Result: default: False [-4.10 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RWL_MAILSPIKE_EXCELLENT(-0.40)[217.116.26.71:from]; R_SPF_ALLOW(-0.20)[+ip4:217.116.26.0/24]; RCVD_IN_DNSWL_LOW(-0.20)[217.116.26.71:from,217.116.26.75:received]; R_DKIM_ALLOW(-0.20)[codenetworks.net:s=domabs]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_DN_SOME(0.00)[]; ASN(0.00)[asn:16371, ipnet:217.116.24.0/21, country:ES]; FREEMAIL_TO(0.00)[gmail.com,freebsd.org,callfortesting.org]; RCVD_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[codenetworks.net:+]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; DMARC_NA(0.00)[codenetworks.net]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4RLVXX0DKPz3fw7 Hi there! I'm seeing the same, but at the end the machine end crashing. Seems that a complete power-off/on of the hardware clears it, until it random happen again when loading vmm and doing passthru. With 13.1p7 it was solid. I'm adding  Micheal as he probably know who is the right person to look into it. Santi On 8/3/23 06:48, skorpio dr wrote: > Hello, > > Starting a vm (FreeBSD 13.2) with passthru NIC results a constant > flood of error messages on the host (FreeBSD 14-CURRENT). > The NIC refuses to work in the vm (it works on the host if I turn off > the passthru). > This problem is persistent since 13.1-Release. > (Sidenote: the passthru mostly works under the EOL 13.0-p13 with the > same config, only occasionally showing the symptoms after multiple vm > reboots, and a host reboot solves the problem unlike in 13.1-release > 13.2-release and now 14.0-current) > > Ruling out NIC/board hardware fault and specific NIC driver problems, > I've tried with the following NICs: > - Intel I350-t4 > - Intel 82580 > - Broadcom BCM5720 > > ...in different desktop and server boards (with the latest BIOS): > - Asus M5A99X EVO R2.0 > - Asus M4A87TD EVO > - Asus KGPE-D16 > >   # freebsd-version -kru > 14.0-CURRENT > 14.0-CURRENT > 14.0-CURRENT > >   /boot/loader.conf: > vmm_load="YES" > nmdm_load="YES" > hw.vmm.amdvi.enable=1 > pptdevs="8/0/0 8/0/1" > >   # vm passthru|grep ppt0 > ppt0       8/0/0        Yes          82580 Gigabit Network Connection > >   the vm config file for vm-bhyve: > loader="bhyveload" > cpu=2 > memory=4G > disk0_type="virtio-blk" > disk0_name="ptproba.img" > # igb0: > passthru0="8/0/0" > uuid="2333ba09-dfe1-11ed-9ed6-9c5c8e54ad77" > > vm-bhyve.log: > > Aug 03 02:25:16: initialising > Aug 03 02:25:16:  [loader: bhyveload] > Aug 03 02:25:16:  [cpu: 2] > Aug 03 02:25:16:  [memory: 4G] > Aug 03 02:25:16:  [hostbridge: standard] > Aug 03 02:25:16:  [com ports: com1] > Aug 03 02:25:16:  [uuid: 2333ba09-dfe1-11ed-9ed6-9c5c8e54ad77] > Aug 03 02:25:16:  [debug mode: no] > Aug 03 02:25:16:  [primary disk: ptproba.img] > Aug 03 02:25:16:  [primary disk dev: file] > Aug 03 02:25:16: booting > Aug 03 02:25:16: bhyveload -c /dev/nmdm-ptproba.1A -S -m 4G -e > autoboot_delay=3 -d /root/vm-bhyve/ptproba/ptproba.img ptproba > Aug 03 02:25:22:  [bhyve options: -c 2 -m 4G -AHP -U > 2333ba09-dfe1-11ed-9ed6-9c5c8e54ad77 -u -S] > Aug 03 02:25:22:  [bhyve devices: -s 0,hostbridge -s 31,lpc -s > 4:0,virtio-blk,/root/vm-bhyve/ptproba/ptproba.img -s 5:0,passthru,8/0/0] > Aug 03 02:25:22:  [bhyve console: -l com1,/dev/nmdm-ptproba.1A] > Aug 03 02:25:22: starting bhyve (run 1) > > The first few dozen messages are like the followings (couple of > hundred lines): > > ivhd0: EVT INTR 0 Status:0x1a EVT Head:0x0 Tail:0x10] >   [CMD Total 0x24] Tail:0x240, Head:0x240. > ivhd0:  [Event0: Head:0x0 Tail:0x10] >         [INV_DTE devid:0xa0 addr:0xfdf9103300 type:0x3 tr:0] > ivhd0: EVT INTR 1 Status:0x1a EVT Head:0x10 Tail:0x20] >   [CMD Total 0x26] Tail:0x260, Head:0x260. > ivhd0:  [Event0: Head:0x10 Tail:0x20] >         [INV_DTE devid:0xa0 addr:0xfdf9103300 type:0x3 tr:0] > ivhd0: EVT INTR 2 Status:0x1a EVT Head:0x20 Tail:0x30] >   [CMD Total 0x26] Tail:0x260, Head:0x260. > ivhd0:  [Event0: Head:0x20 Tail:0x30] >         [INV_DTE devid:0xa0 addr:0xfdf9103300 type:0x3 tr:0] > > ...then the constant flood (about 35 lines per second in > /var/log/messages): > > ivhd0:  [Event63: Head:0x3e0 Tail:0x8d0] >         [INV_DTE devid:0xa0 addr:0xfdf9103300 type:0x3 tr:0] > ivhd0:  [Event64: Head:0x3f0 Tail:0x8d0] >         [INV_DTE devid:0xa0 addr:0xfdf9103300 type:0x3 tr:0] > ivhd0:  [Event65: Head:0x400 Tail:0x8d0] >         [INV_DTE devid:0xa0 addr:0xfdf9103300 type:0x3 tr:0] > > Any idea? > > Best From nobody Wed Aug 9 14:47:36 2023 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 4RLXwF5nBrz4Tmsq for ; Wed, 9 Aug 2023 14:47:41 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) 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 4RLXwF4zTzz4cp0 for ; Wed, 9 Aug 2023 14:47:41 +0000 (UTC) (envelope-from jbeich@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1691592461; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=pllJOTDea0BBs1DnnQ4t8peAzFPkvX+DwNKszyPAXCo=; b=DZPMx7Pc+KWeTNzWTjTbtcrArlD843x0VFqxSYT88n7mjyNcgQmENuve2uRLtWqZdaT+lb I1b1GEFQexa0L01aighp/Ofllv+BaIQTQgpvwbtfJn3nhiv3VN8FUz/Yb+oUWIMvh7ypWg SNWuk7jfsuhFAVgX3iAGl3wJGFfa1gs4l4SQT2z/h+lEnsz3X8DjkghBykcZD8L4hqqAHr cZ80XSbtkRlB0RUGMdjT1h8QAanOHtbazBjxZVYIhwRZts35GyM2zCV4IzfpZV+ygSKaVP S9NR0AKXikDC6pCNx0Bthp6QDwxDlwIhkyLDXgyan6h5diyZ+EPtA9tBmR1jiA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1691592461; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=pllJOTDea0BBs1DnnQ4t8peAzFPkvX+DwNKszyPAXCo=; b=UQZ7oUv8ou2gwubZQ5+OIxf0j4dZQkmfa0ST4j2DO5Ecixkjs2LU8Rr56twiBJevKPAgH7 lPQmlYA+eaewZ+eTg91CNsBIfPANn5bYePVaL6lBUfs6IvGA8fnUsYKm8G80zedu+5t4Gu /etZ5qBoUuBzYRmLKN7ypk8XUypb1qwmeN91gSBQBiopyA1YlWksqmT72SsubS0blMMwLG IbwsNmamlLmRvTBksDKGE6o+/Q4zn7gZYjMZcFWR4jeiv512ceLGdJjOLtVlbq4vhy0PMY dQt9VmESfaFxu4+MxhvNLAsT6jrGj8CyBoCMfKl6OSrOaoXSHEXLBkhh2gq7+A== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1691592461; a=rsa-sha256; cv=none; b=JO3L4vcUpFuVEhFrVtmrYqA1p1Yu1AhUeCtj/fLTM2i5HEgE9DhvnDv7eu4hposzwwclkJ qDULNjXC535inkSFGC7xFe40/JFooe4Bo0rHBwbZQJpXp7Wt53rcX51FGmFwlosMI1y38F yTx2S2WsEjpXiEcVv19q1PfEfQ9/0Ja3WylDqTeahWEzHya6EyTuXod33wxNIeeCwEThla jKoslOsToWnc38n/hdD/gekOMmBDjH5Zl1uxHfb8cILjO56+gniE+lm1XBCTAdny+Y/VKk M6IaCd/n9OQvExlWH5QW4VFFCJUBo8OJOI12U3vBSms3+wQ5FfN4+tqNcUM9TQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: by freefall.freebsd.org (Postfix, from userid 1354) id 872AF12276; Wed, 9 Aug 2023 14:47:41 +0000 (UTC) From: Jan Beich To: freebsd-current@freebsd.org Subject: Re: qt6 the default qt on -current? In-Reply-To: (void@f-m.fm's message of "Wed, 9 Aug 2023 10:38:42 +0100") References: Date: Wed, 09 Aug 2023 16:47:36 +0200 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 Please, use ports@ list next time. Every supported FreeBSD version uses the same ports/ tree. Not supported FreeBSD versions require a time machine i.e., rolling back the ports/ tree to a date before EOL. void writes: > How can I build making qt6 the default Qt? When everything in ports supports Qt6. Once Plasma6 arrives Qt5 may start to dilapidate and be eventually removed, similar to Qt4. For comparison, gtk2 can use modern glib but qt5-gui cannot use qt6-core. > I'm using poudriere to build. I can see that for some ports there's a > 'uses: qt6' that goes in the port. What I was looking for was a default > string I can use with a poudriere make.conf like there is for python or > perl. Only select few ports support more than one Qt version. Many use flavors in order to provide both Qt5 and Qt6 versions as binary packages. If upstream supports Qt6 but a port doesn't expose it file a bug. From nobody Wed Aug 9 16:45:01 2023 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 4RLbWk4hXqz4TvkL for ; Wed, 9 Aug 2023 16:45:06 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (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 4RLbWj6cPrz3KTK for ; Wed, 9 Aug 2023 16:45:05 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20221208 header.b=Q6PFd8sV; spf=pass (mx1.freebsd.org: domain of grahamperrin@gmail.com designates 2a00:1450:4864:20::22f as permitted sender) smtp.mailfrom=grahamperrin@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-lj1-x22f.google.com with SMTP id 38308e7fff4ca-2b9c0391749so562291fa.0 for ; Wed, 09 Aug 2023 09:45:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691599504; x=1692204304; h=in-reply-to:from:content-language:references:to:subject:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to; bh=u56Ujt68Y9phXqgtZfUxuuFjRRXCICnfnnMuWNp32yY=; b=Q6PFd8sVDIXZZJGJLciiiQyxhOnJyaESDFf9fVhB4L0V6ddAtTKUZjwFYDYNWQgbik vjsjOBJU5OpDbxbYg4TlB4Ls4NrOb0w/C4CYTJyQgSQ3x8RoLLcGkbTQ44wN8UaEh8L6 loLCk71J8arl0B9K6z+umExDhpFbAWsqvkrEo1zXZD7gicZxh4P+8yHjTSbW2+D7NS7I EK/UI2PGTmWWxFyqJhLELuNwPWpPq9ML4eYnUXhtZvy8JUkBiOBOgpKhu2W2bqAop6Yv VJnbOP1PQNsfStQVlwN5guOx0uSw01G5JHh0pTWBad6G/X20JnglkkvSBIWb4i4uKaXB lJAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691599504; x=1692204304; h=in-reply-to:from:content-language:references:to:subject:user-agent :mime-version:date:message-id:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=u56Ujt68Y9phXqgtZfUxuuFjRRXCICnfnnMuWNp32yY=; b=N/F60cS3yJdAbzXTnOcTJqtVbbYVEpGH8qtoX/GYMewkyq0Mr4ByfVCmstceqMK137 8VhNtRHz8IinSUgstbeka0RsuOf574mbhJxfYTO38rg41GqQeFJ0QKYcjEg0fzmvrA3M 9LhsWsnoJ32qWSI5yVs0unPIVrlSpHrW+GJYZGom1fdPuVE3vIvGPCeYYYKSYI0UwVcK DjmLW/gqjKOKc0MIi0ESo8OCYGKxcwbIDNa/CKBhxpWw9gtqJbZqQSj5XO4FmgQlOH52 JIrvaF9BrpkogVpJsrvkLx1Z0mA3BtVENWwojpfpTjxMgwv568gdOjGtZIS7CYCerIDk MCSw== X-Gm-Message-State: AOJu0YwXd7JUhzgFY+TO//DSkLhQlYyKm0/oNYHLvg38nerjewMnQWcx jUqug+mwEPOYwj5JeXfI/WOjqjEIxLo= X-Google-Smtp-Source: AGHT+IHPG5X8mjRSrnuKf5bhgfGHJWiXnO9DC6LfAL5sHWptf8pmispydPQ/VuqxEIG0ilUVB3H2pg== X-Received: by 2002:a2e:9905:0:b0:2b9:cc8e:8729 with SMTP id v5-20020a2e9905000000b002b9cc8e8729mr2237399lji.26.1691599503585; Wed, 09 Aug 2023 09:45:03 -0700 (PDT) Received: from [192.168.1.10] (80-42-66-93.dynamic.dsl.as9105.com. [80.42.66.93]) by smtp.gmail.com with ESMTPSA id o17-20020a17090611d100b0099bd0b5a2bcsm8306880eja.101.2023.08.09.09.45.02 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 09 Aug 2023 09:45:03 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------xOOMCdLguHu8PkGxs7OPB82M" Message-ID: <25fe3d7d-40bd-3147-8132-1c669ea33f38@gmail.com> Date: Wed, 9 Aug 2023 17:45:01 +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:102.0) Gecko/20100101 Thunderbird/102.14.0 Subject: Re: 14.0 boot failure To: freebsd-current@freebsd.org References: <884e4afa-4687-8785-fc48-f5fff9556b8e@freebsd.org> Content-Language: en-US From: Graham Perrin In-Reply-To: X-Spamd-Result: default: False [-3.93 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.93)[-0.933]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20221208]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[grahamperrin]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::22f:from]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; TO_DN_NONE(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-Spamd-Bar: --- X-Rspamd-Queue-Id: 4RLbWj6cPrz3KTK This is a multi-part message in MIME format. --------------xOOMCdLguHu8PkGxs7OPB82M Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 09/08/2023 07:10, Kevin Oberman wrote: > I closed the ticket. I wasn't aware of a ticket, thanks for the update. Yesterday's 09c20a293280 boots fine for me. --------------xOOMCdLguHu8PkGxs7OPB82M Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
On 09/08/2023 07:10, Kevin Oberman wrote:
I closed the ticket.

I wasn't aware of a ticket, thanks for the update.

Yesterday's 09c20a293280 boots fine for me.
--------------xOOMCdLguHu8PkGxs7OPB82M-- From nobody Wed Aug 9 16:54:41 2023 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 4RLbkv2nWNz4Tw5S for ; Wed, 9 Aug 2023 16:54:47 +0000 (UTC) (envelope-from void@f-m.fm) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (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 4RLbkt2rWDz3Lxn for ; Wed, 9 Aug 2023 16:54:46 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm3 header.b=TZdYfphF; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=rD0sDNTt; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 64.147.123.19 as permitted sender) smtp.mailfrom=void@f-m.fm; dmarc=pass (policy=none) header.from=f-m.fm Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 31F183200924 for ; Wed, 9 Aug 2023 12:54:44 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Wed, 09 Aug 2023 12:54:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm3; t=1691600083; x=1691686483; bh=oS pBhxM69X3j6j8mt2ltq8XUCwt3CwHEDSBrcEZKzHk=; b=TZdYfphFBSCuGftlx1 dfGrtEBPnldiooSriSTVN/Hi+ubTzmmx4KrcdA0ij7PHxttJKhspZjnjnq8lkP4G MymICwrik5jCixbh/ZtFeInywsHsj2xioUJZ1gsaPCJHbfOP1BWhjE90EHhDUpcf q/P8Lel2ODfcUgFEPLwzUzbXo/q+54tBeTLHRjQOydCYIhKjp80AzWnDjGVYBWO5 5gnfWYhu9TkvgYXhe2TE5tNfaVkwefTbgZPWHg4efN08+R+Me0jTAVmpXKnnAm2H /0gYxjJ09KE4RyDukAjkDJK2+qSD+ozSyA8DmDAZZ7EUrwNgLMgi2XZzAeuVCkou HHiQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; t=1691600083; x=1691686483; bh=oSpBhxM69X3j6 j8mt2ltq8XUCwt3CwHEDSBrcEZKzHk=; b=rD0sDNTtkpOmDccHVIgMQTG9YHMCd 3x2tOYB1XFA4OB44rir7Qhlqwy7ObKUpibfPNht1Eew5hhhvnQ/ymBOtbg23yBza M+mDKNKeHBteWTXXBB05Uppe09DmHl5TJozMha+2fipJsg2m1gaHMfgOIDgSIFwG yZkVN9NY0aojnVuDibFpJZP4zoqn3YTwPvaX9LsNbs25pK9Upm/Me6lvYzfXkTaO VXsX5e8x2KTu3HSzpsf47oWBdHJL5gEkueIysgyFGrMhLL/g5H95m3dI9f+r3YGh kJOleUsLK8XFJ+bbvQLALp1zbdwFDEslLzadvwDKXdjDueiG8n0FZ2kwg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrleeggddutdehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesthdtre dttddtvdenucfhrhhomhepvhhoihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgr thhtvghrnhepkeeluddvlefhieelfefggffhffektdehleelgfdugfdvgeekjeejuddthe ehgfeunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhep vhhoihgusehfqdhmrdhfmh X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Wed, 9 Aug 2023 12:54:43 -0400 (EDT) Date: Wed, 9 Aug 2023 17:54:41 +0100 From: void To: freebsd-current@freebsd.org Subject: Re: qt6 the default qt on -current? Message-ID: Mail-Followup-To: freebsd-current@freebsd.org 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; format=flowed Content-Disposition: inline In-Reply-To: X-Spamd-Result: default: False [-1.67 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_SPAM_SHORT(0.93)[0.931]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm3,messagingengine.com:s=fm3]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.19]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.19:from]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_NONE(0.00)[]; FREEMAIL_FROM(0.00)[f-m.fm]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; RCVD_VIA_SMTP_AUTH(0.00)[] X-Spamd-Bar: - X-Rspamd-Queue-Id: 4RLbkt2rWDz3Lxn On Wed, Aug 09, 2023 at 04:47:36PM +0200, Jan Beich wrote: >Please, use ports@ list next time. Every supported FreeBSD version uses >the same ports/ tree. Not supported FreeBSD versions require a time >machine i.e., rolling back the ports/ tree to a date before EOL. OK. I didn't think the query belonged in ports@ for the following reasons: 1. the question wasn't about a port problem or a PR 2. development happens on -current primarily 3. the system it concerns is running -current >When everything in ports supports Qt6. Once Plasma6 arrives Qt5 may >start to dilapidate and be eventually removed, similar to Qt4. ok, thanks -- From nobody Wed Aug 9 21:32:14 2023 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 4RLjw54qvyz4mKQw for ; Wed, 9 Aug 2023 21:33:09 +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 4RLjw33cvpz4FhH for ; Wed, 9 Aug 2023 21:33:06 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; dkim=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; dmarc=none Received: from kalamity.joker.local (123-1-88-210.area1b.commufa.jp [123.1.88.210]) (authenticated bits=0) by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 379LWEaK057204; Thu, 10 Aug 2023 06:32:15 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Thu, 10 Aug 2023 06:32:14 +0900 From: Tomoaki AOKI To: David Wolfskill Cc: freebsd-current@freebsd.org Subject: Re: Has the update procedure changed? Message-Id: <20230810063214.1b694140e7c284e51154fe35@dec.sakura.ne.jp> In-Reply-To: References: <7A0E604D-EF40-4F10-B597-F1F076507192@gmail.com> <20230809213822.950a3c337ec86c102dcbd235@dec.sakura.ne.jp> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.2) 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-Spamd-Result: default: False [-0.41 / 15.00]; AUTH_NA(1.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.998]; NEURAL_HAM_LONG(-1.00)[-0.998]; NEURAL_HAM_MEDIUM(-0.92)[-0.919]; MV_CASE(0.50)[]; ONCE_RECEIVED(0.10)[]; MIME_GOOD(-0.10)[text/plain]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]; RCVD_COUNT_ONE(0.00)[1]; RCPT_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_SOME(0.00)[]; HAS_ORG_HEADER(0.00)[]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[sakura.ne.jp]; TO_DN_SOME(0.00)[]; R_SPF_NA(0.00)[no SPF record]; RCVD_TLS_LAST(0.00)[] X-Spamd-Bar: / X-Rspamd-Queue-Id: 4RLjw33cvpz4FhH On Wed, 9 Aug 2023 05:50:05 -0700 David Wolfskill wrote: > On Wed, Aug 09, 2023 at 09:38:22PM +0900, Tomoaki AOKI wrote: > > ... > > > > Please correct me if I'm missing something. > > I use source update for years and not using bsdinstall nor > > freebsd-update. > > > > Does bsdinstall (and/or freebsd-update) create the first current tree > > for etcupdate, if not yet exists? > > > > This would be most confusing and harmful point of etcupdate. > > When I first tried etcupdate, I didn't noticed that I needed > > `etcupdate extract -B` BEFORE UPDATING src tree. > > Without this, etcupdate cannot detect what should be updated, even if a > > plenty of updates are required. > > > > At the moment, I must use mergemaster, and after that, `etcupdate > > extract -B` for next run. > > > > I think bsdinstall can create current tree, which is turned over to old > > tree on actual run, for etcupdate. > > So do freebsd-update. It would be able to create current tree JUST > > BEFORE INSTALLING UPDATE. > > > > I was helped by mergemaster, but after it completely retires, features > > above should be mandatory. > > .... > > TL;DR: Please see the "Bootstrapping" section of etcupdate(8). I know. ;-) I'm using etcupdate when it first MFC'ed to latest stable branch ATM, and bitten at the first time. Anyone not familiar with etcupdate would bitten by forgotton bootstrapping. :-( > Details: I have been doing source-based updates of FreeBSD since around > 1999. As such, I used mergemaster for a long time, and got used to it. > > With the switch to git, the $FreeBSD$ lines in config files became ... > well, misleading noise. And since mergemaster tried to use them, that > didn't work very well. This provided the incentive I needed to switch > to etcupdate. > > And... yeah; there was a "learning curve." And the "bootstrapping" bit > is necessary. But it has worked well for me since. Yes. But if bsdinstall and freebsd-update automatically bootstrap etcupdate if not yet done, newbies and casual users wouldn't be bitten. For source-based update users like us, *Bootstrapping section of man page should be near the top, for example, betweem DESCRIPTION and MODES section, not inside EXAMPLES section. *Also documented in UPDATING (or new document for common instructions) and handbook. should be needed. etcupdate cannot extract old tree from already-updated src. So anyone forgotton bootstrapping is forced to roll back src for bootstrapping and roll forward again BEFORE installworld, once mergemaster dissapears. > > Peace, > david > -- > David H. Wolfskill david@catwhisker.org > Given Trump's claims about fairness in elections, his notion of a > "fair trial" is almost certainly at variance with objective reality. > > See https://www.catwhisker.org/~david/publickey.gpg for my public key. -- Tomoaki AOKI From nobody Thu Aug 10 03:33:40 2023 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 4RLswM6dd1z4pxyy for ; Thu, 10 Aug 2023 03:33:55 +0000 (UTC) (envelope-from kevin.bowling@kev009.com) Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) (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 4RLswL6wZLz3PXK for ; Thu, 10 Aug 2023 03:33:54 +0000 (UTC) (envelope-from kevin.bowling@kev009.com) Authentication-Results: mx1.freebsd.org; dkim=none ("invalid DKIM record") header.d=kev009.com header.s=google header.b=R3aeZGee; spf=pass (mx1.freebsd.org: domain of kevin.bowling@kev009.com designates 2607:f8b0:4864:20::102e as permitted sender) smtp.mailfrom=kevin.bowling@kev009.com; dmarc=none Received: by mail-pj1-x102e.google.com with SMTP id 98e67ed59e1d1-268bc714ce0so1191905a91.0 for ; Wed, 09 Aug 2023 20:33:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kev009.com; s=google; t=1691638433; x=1692243233; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=qZqtzteohYtrAAnE6jqgjB7NZIgqjuZmSULYY0gwWnM=; b=R3aeZGee1l3rO/wC11YVgdsoNCe/auUazIU6vbIAGmIwzGDFt1b0HGZlc90XRQiRip leguo01GEq2RYMhnWhDw2pPssFLEle9eTgY9SxMkzADya/oemRDEL0Z49rxCoWIIobMx B0ab4ddS1xuu8ngrtWYkx5APE4A2W6YFLLeTQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691638433; x=1692243233; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=qZqtzteohYtrAAnE6jqgjB7NZIgqjuZmSULYY0gwWnM=; b=Ti2zGcUTZNt7SdqqynWcCBn2yO0Ue7hbar3Pl9MO8+mO3yBaI6offQLctjm61N5gxx BaAVckJ2rIr/wsGHt7HGybGn2Hq1VpSjb1M7vF+JWbNscfqj9JEkehuFGeBqHXC8mLlK hwliZQ6Y6O+jyTMwLVf7EERYMJB9M+NnlngCbLZe1UPtINnmauyJYDlFU5+EqpTAIl9d /EN50QuOhdr7dCZghna1ibqF2DVRMygUoaBXNMmLjSvRHUhG/FYpaF3BP6UaR7J7Av65 DBzKcVxd3QUvOvDW6YOItaO67j+2pwaWH6RFz4Riz+bIGXAedHoUc6TI/ZR3+UcGmtdK Hmbg== X-Gm-Message-State: AOJu0YzDWAjFObNA/r8phU73dG7i6XudN2NqwLfLicv85a0KNA2Wf4x/ KZ/KetzzT4UVOPsFmthjLh/n3L+gLRxBtFIRxP2G+6zvn3zO56ScRLRvpg== X-Google-Smtp-Source: AGHT+IFA0Piah2D3mmVwjiScmbf9Oe5LvFMwv83w9FfVuyde4lLsFNmL244+jDGg5qbI7BLc1GwCkcbM8MxNbERoWdo= X-Received: by 2002:a17:90a:51c5:b0:268:b54:7c13 with SMTP id u63-20020a17090a51c500b002680b547c13mr1138751pjh.9.1691638432887; Wed, 09 Aug 2023 20:33:52 -0700 (PDT) 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: <86leeltqcb.fsf@ltc.des.no> In-Reply-To: <86leeltqcb.fsf@ltc.des.no> From: Kevin Bowling Date: Wed, 9 Aug 2023 20:33:40 -0700 Message-ID: Subject: Re: ZFS deadlock in 14 To: =?UTF-8?Q?Dag=2DErling_Sm=C3=B8rgrav?= Cc: current@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [-3.04 / 15.00]; NEURAL_HAM_SHORT(-1.00)[-0.998]; NEURAL_HAM_MEDIUM(-0.90)[-0.900]; NEURAL_HAM_LONG(-0.84)[-0.842]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[text/plain]; R_DKIM_PERMFAIL(0.00)[kev009.com:s=google]; MLMMJ_DEST(0.00)[current@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; BLOCKLISTDE_FAIL(0.00)[2607:f8b0:4864:20::102e:server fail]; MIME_TRACE(0.00)[0:+]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::102e:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[kev009.com:~]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[kev009.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Spamd-Bar: --- X-Rspamd-Queue-Id: 4RLswL6wZLz3PXK Possibly https://github.com/openzfs/zfs/commit/2cb992a99ccadb78d97049b40bd4= 42eb4fdc549d On Tue, Aug 8, 2023 at 10:08=E2=80=AFAM Dag-Erling Sm=C3=B8rgrav wrote: > > At some point between 42d088299c (4 May) and f0c9703301 (26 June), a > deadlock was introduced in ZFS. It is still present as of 9c2823bae9 (4 > August) and is 100% reproducable just by starting poudriere bulk in a > 16-core VM and waiting a few hours until deadlkres kicks in. In the > latest instance, deadlkres complained about a bash process: > > #0 sched_switch (td=3Dtd@entry=3D0xfffffe02fb1d8000, flags=3Dflags@e= ntry=3D259) at /usr/src/sys/kern/sched_ule.c:2299 > #1 0xffffffff80b5a0a3 in mi_switch (flags=3Dflags@entry=3D259) at /u= sr/src/sys/kern/kern_synch.c:550 > #2 0xffffffff80babcb4 in sleepq_switch (wchan=3D0xfffff818543a9e70, = pri=3D64) at /usr/src/sys/kern/subr_sleepqueue.c:609 > #3 0xffffffff80babb8c in sleepq_wait (wchan=3D, pri=3D<= unavailable>) at /usr/src/sys/kern/subr_sleepqueue.c:660 > #4 0xffffffff80b1c1b0 in sleeplk (lk=3Dlk@entry=3D0xfffff818543a9e70= , flags=3Dflags@entry=3D2121728, ilk=3Dilk@entry=3D0x0, wmesg=3Dwmesg@entry= =3D0xffffffff8222a054 "zfs", pri=3D, pri@entry=3D64, timo=3D= timo@entry=3D6, queue=3D1) at /usr/src/sys/kern/kern_lock.c:310 > #5 0xffffffff80b1a23f in lockmgr_slock_hard (lk=3D0xfffff818543a9e70= , flags=3D2121728, ilk=3D, file=3D0xffffffff812544fb "/usr/s= rc/sys/kern/vfs_subr.c", line=3D3057, lwa=3D0x0) at /usr/src/sys/kern/kern_= lock.c:705 > #6 0xffffffff80c59ec3 in VOP_LOCK1 (vp=3D0xfffff818543a9e00, flags= =3D2105344, file=3D0xffffffff812544fb "/usr/src/sys/kern/vfs_subr.c", line= =3D3057) at ./vnode_if.h:1120 > #7 _vn_lock (vp=3Dvp@entry=3D0xfffff818543a9e00, flags=3D2105344, fi= le=3D, line=3D, line@entry=3D3057) at /usr/src/sy= s/kern/vfs_vnops.c:1815 > #8 0xffffffff80c4173d in vget_finish (vp=3D0xfffff818543a9e00, flags= =3D, vs=3Dvs@entry=3DVGET_USECOUNT) at /usr/src/sys/kern/vfs_s= ubr.c:3057 > #9 0xffffffff80c1c9b7 in cache_lookup (dvp=3Ddvp@entry=3D0xfffff802c= d02ac40, vpp=3Dvpp@entry=3D0xfffffe046b20ac30, cnp=3Dcnp@entry=3D0xfffffe04= 6b20ac58, tsp=3Dtsp@entry=3D0x0, ticksp=3Dticksp@entry=3D0x0) at /usr/src/s= ys/kern/vfs_cache.c:2086 > #10 0xffffffff80c2150c in vfs_cache_lookup (ap=3D) at = /usr/src/sys/kern/vfs_cache.c:3068 > #11 0xffffffff80c32c37 in VOP_LOOKUP (dvp=3D0xfffff802cd02ac40, vpp= =3D0xfffffe046b20ac30, cnp=3D0xfffffe046b20ac58) at ./vnode_if.h:69 > #12 vfs_lookup (ndp=3Dndp@entry=3D0xfffffe046b20abd8) at /usr/src/sys= /kern/vfs_lookup.c:1266 > #13 0xffffffff80c31ce1 in namei (ndp=3Dndp@entry=3D0xfffffe046b20abd8= ) at /usr/src/sys/kern/vfs_lookup.c:689 > #14 0xffffffff80c52090 in kern_statat (td=3D0xfffffe02fb1d8000, flag= =3D, fd=3D-100, path=3D0xa75b480e070 , pathseg=3Dpathseg@entry=3DUIO_USERSPACE, s= bp=3Dsbp@entry=3D0xfffffe046b20ad18) > at /usr/src/sys/kern/vfs_syscalls.c:2441 > #15 0xffffffff80c52797 in sys_fstatat (td=3D, uap=3D0xff= fffe02fb1d8400) at /usr/src/sys/kern/vfs_syscalls.c:2419 > #16 0xffffffff81049398 in syscallenter (td=3D) at /usr= /src/sys/amd64/amd64/../../kern/subr_syscall.c:190 > #17 amd64_syscall (td=3D0xfffffe02fb1d8000, traced=3D0) at /usr/src/s= ys/amd64/amd64/trap.c:1199 > #18 > > The lock it is trying to acquire in frame 5 belongs to another bash > process which is in the process of creating a fifo: > > #0 sched_switch (td=3Dtd@entry=3D0xfffffe046acd8e40, flags=3Dflags@e= ntry=3D259) at /usr/src/sys/kern/sched_ule.c:2299 > #1 0xffffffff80b5a0a3 in mi_switch (flags=3Dflags@entry=3D259) at /u= sr/src/sys/kern/kern_synch.c:550 > #2 0xffffffff80babcb4 in sleepq_switch (wchan=3D0xfffff8018acbf154, = pri=3D87) at /usr/src/sys/kern/subr_sleepqueue.c:609 > #3 0xffffffff80babb8c in sleepq_wait (wchan=3D, pri=3D<= unavailable>) at /usr/src/sys/kern/subr_sleepqueue.c:660 > #4 0xffffffff80b59606 in _sleep (ident=3Dident@entry=3D0xfffff8018ac= bf154, lock=3Dlock@entry=3D0xfffff8018acbf120, priority=3Dpriority@entry=3D= 87, wmesg=3D0xffffffff8223af0e "zfs teardown inactive", sbt=3Dsbt@entry=3D0= , pr=3Dpr@entry=3D0, flags=3D256) > at /usr/src/sys/kern/kern_synch.c:225 > #5 0xffffffff80b45dc0 in rms_rlock_fallback (rms=3D0xfffff8018acbf12= 0) at /usr/src/sys/kern/kern_rmlock.c:1015 > #6 0xffffffff80b45c93 in rms_rlock (rms=3D, rms@entry= =3D0xfffff8018acbf120) at /usr/src/sys/kern/kern_rmlock.c:1036 > #7 0xffffffff81fb147b in zfs_freebsd_reclaim (ap=3D) = at /usr/src/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vnops_os.c:5164 > #8 0xffffffff8111d245 in VOP_RECLAIM_APV (vop=3D0xffffffff822e71a0 <= zfs_vnodeops>, a=3Da@entry=3D0xfffffe0410f1c9c8) at vnode_if.c:2180 > #9 0xffffffff80c43569 in VOP_RECLAIM (vp=3D0xfffff802cdbaca80) at ./= vnode_if.h:1084 > #10 vgonel (vp=3Dvp@entry=3D0xfffff802cdbaca80) at /usr/src/sys/kern/= vfs_subr.c:4143 > #11 0xffffffff80c3ef61 in vtryrecycle (vp=3D0xfffff802cdbaca80) at /u= sr/src/sys/kern/vfs_subr.c:1693 > #12 vnlru_free_impl (count=3Dcount@entry=3D1, mnt_op=3Dmnt_op@entry= =3D0x0, mvp=3D0xfffff8010864da00) at /usr/src/sys/kern/vfs_subr.c:1344 > #13 0xffffffff80c49553 in vnlru_free_locked (count=3D1) at /usr/src/s= ys/kern/vfs_subr.c:1357 > #14 vn_alloc_hard (mp=3Dmp@entry=3D0x0) at /usr/src/sys/kern/vfs_subr= .c:1744 > #15 0xffffffff80c3f6f0 in vn_alloc (mp=3D0x0) at /usr/src/sys/amd64/i= nclude/atomic.h:375 > #16 getnewvnode_reserve () at /usr/src/sys/kern/vfs_subr.c:1888 > #17 0xffffffff81faa072 in zfs_create (dzp=3D0xfffff812200261d0, name= =3D0xfffff8011b8ac805 "sh-np.yPbxoo", vap=3D0xfffffe0410f1cc20, excl=3D, mode=3D, zpp=3Dzpp@entry=3D0xfffffe0410f1cbc8, = cr=3D0xfffff80140fb1100, flag=3D, vsecp=3D0x0, mnt_ns=3D0x0) > at /usr/src/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vnops_o= s.c:1146 > #18 0xffffffff81faea57 in zfs_freebsd_create (ap=3D0xfffffe0410f1cda0= ) at /usr/src/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vnops_os.c:4618 > #19 0xffffffff8111aa9a in VOP_MKNOD_APV (vop=3D0xffffffff822e71a0 , a=3Da@entry=3D0xfffffe0410f1cda0) at vnode_if.c:372 > #20 0xffffffff80c50207 in VOP_MKNOD (dvp=3D, cnp=3D0xfff= ffe0410f1cd50, vap=3D0xfffffe0410f1cc20, vpp=3D) at ./vnode_= if.h:188 > #21 kern_mkfifoat (td=3D0xfffffe046acd8e40, fd=3D-100, path=3D0x12772= f073500 , pathseg=3D= UIO_USERSPACE, mode=3D) at /usr/src/sys/kern/vfs_syscalls.c:= 1492 > #22 0xffffffff81049398 in syscallenter (td=3D) at /usr= /src/sys/amd64/amd64/../../kern/subr_syscall.c:190 > #23 amd64_syscall (td=3D0xfffffe046acd8e40, traced=3D0) at /usr/src/s= ys/amd64/amd64/trap.c:1199 > #24 > > Frame 7 is trying to acquire the ZFS teardown inactive lock, which is > held by a process which is performing a ZFS rollback and is waiting for > the transaction to sync: > > #0 sched_switch (td=3Dtd@entry=3D0xfffffe0422ef8560, flags=3Dflags@e= ntry=3D259) at /usr/src/sys/kern/sched_ule.c:2299 > #1 0xffffffff80b5a0a3 in mi_switch (flags=3Dflags@entry=3D259) at /u= sr/src/sys/kern/kern_synch.c:550 > #2 0xffffffff80babcb4 in sleepq_switch (wchan=3D0xfffff8011b83d540, = pri=3D0) at /usr/src/sys/kern/subr_sleepqueue.c:609 > #3 0xffffffff80babb8c in sleepq_wait (wchan=3D, wchan@e= ntry=3D0xfffff8011b83d540, pri=3D, pri@entry=3D0) at /usr/src/= sys/kern/subr_sleepqueue.c:660 > #4 0xffffffff80ad7f75 in _cv_wait (cvp=3Dcvp@entry=3D0xfffff8011b83d= 540, lock=3Dlock@entry=3D0xfffff8011b83d4d0) at /usr/src/sys/kern/kern_cond= var.c:146 > #5 0xffffffff820b42fb in txg_wait_synced_impl (dp=3Ddp@entry=3D0xfff= ff8011b83d000, txg=3D8585097, wait_sig=3Dwait_sig@entry=3D0) at /usr/src/sy= s/contrib/openzfs/module/zfs/txg.c:726 > #6 0xffffffff820b3cab in txg_wait_synced (dp=3D, dp@ent= ry=3D0xfffff8011b83d000, txg=3D) at /usr/src/sys/contrib/openz= fs/module/zfs/txg.c:736 > #7 0xffffffff8206d5b5 in dsl_sync_task_common (pool=3Dpool@entry=3D0= xfffffe0401d15000 "zroot/poudriere/jails/13amd64-default-ref/15", checkfunc= =3D, syncfunc=3D0xffffffff8203fbc0 , sigfunc=3Dsigfunc@entry=3D0x0, arg=3Darg@entry=3D0xfffffe02fb827a90, > blocks_modified=3Dblocks_modified@entry=3D1, space_check=3DZFS_SP= ACE_CHECK_RESERVED, early=3D0) at /usr/src/sys/contrib/openzfs/module/zfs/d= sl_synctask.c:93 > #8 0xffffffff8206d3c7 in dsl_sync_task (pool=3D, pool@e= ntry=3D0xfffffe0401d15000 "zroot/poudriere/jails/13amd64-default-ref/15", c= heckfunc=3D, syncfunc=3D, arg=3D, ar= g@entry=3D0xfffffe02fb827a90, blocks_modified=3D, > blocks_modified@entry=3D1, space_check=3D, space_che= ck@entry=3DZFS_SPACE_CHECK_RESERVED) at /usr/src/sys/contrib/openzfs/module= /zfs/dsl_synctask.c:132 > #9 0xffffffff8204075b in dsl_dataset_rollback (fsname=3D, fsname@entry=3D0xfffffe0401d15000 "zroot/poudriere/jails/13amd64-default= -ref/15", tosnap=3D, owner=3D, result=3Dresul= t@entry=3D0xfffff81c826a9ea0) > at /usr/src/sys/contrib/openzfs/module/zfs/dsl_dataset.c:3261 > #10 0xffffffff82168dd9 in zfs_ioc_rollback (fsname=3D0xfffffe0401d150= 00 "zroot/poudriere/jails/13amd64-default-ref/15", fsname@entry=3D, innvl=3D, innvl@entry= =3D, > outnvl=3D0xfffff81c826a9ea0, outnvl@entry=3D) at /usr/src/sys/contrib/openzfs/module/zfs/zfs= _ioctl.c:4405 > #11 0xffffffff82164522 in zfsdev_ioctl_common (vecnum=3Dvecnum@entry= =3D25, zc=3Dzc@entry=3D0xfffffe0401d15000, flag=3Dflag@entry=3D0) at /usr/s= rc/sys/contrib/openzfs/module/zfs/zfs_ioctl.c:7798 > #12 0xffffffff81f97fca in zfsdev_ioctl (dev=3D, zcmd= =3D, zcmd@entry=3D, arg=3D0xfffffe02fb827d50 "\017", arg@entry=3D, flag=3D, td=3D) > at /usr/src/sys/contrib/openzfs/module/os/freebsd/zfs/kmod_core.c= :168 > #13 0xffffffff809d6212 in devfs_ioctl (ap=3D0xfffffe02fb827c50) at /u= sr/src/sys/fs/devfs/devfs_vnops.c:935 > #14 0xffffffff80c585f2 in vn_ioctl (fp=3D0xfffff8052cdd80f0, com=3D, data=3D0xfffffe02fb827d50, active_cred=3D0xfffff80122ab1e00,= td=3D) at /usr/src/sys/kern/vfs_vnops.c:1704 > #15 0xffffffff809d68ee in devfs_ioctl_f (fp=3D, fp@entry= =3D, com=3D, c= om@entry=3D, data=3D, data@entry=3D, > cred=3D, cred@entry=3D, td=3D, td@entry=3D) at /usr/src/sys/fs/devfs/devfs_vnops.c:866 > #16 0xffffffff80bc57e6 in fo_ioctl (fp=3D0xfffff8052cdd80f0, com=3D32= 22821401, data=3D, active_cred=3D, td=3D0xfffffe0= 422ef8560) at /usr/src/sys/sys/file.h:367 > #17 kern_ioctl (td=3Dtd@entry=3D0xfffffe0422ef8560, fd=3D4, com=3Dcom= @entry=3D3222821401, data=3D, data@entry=3D0xfffffe02fb827d50 = "\017") at /usr/src/sys/kern/sys_generic.c:807 > #18 0xffffffff80bc54f2 in sys_ioctl (td=3D0xfffffe0422ef8560, uap=3D0= xfffffe0422ef8960) at /usr/src/sys/kern/sys_generic.c:715 > #19 0xffffffff81049398 in syscallenter (td=3D) at /usr= /src/sys/amd64/amd64/../../kern/subr_syscall.c:190 > #20 amd64_syscall (td=3D0xfffffe0422ef8560, traced=3D0) at /usr/src/s= ys/amd64/amd64/trap.c:1199 > #21 > > OpenZFS commits in the relevant range: > > commit e639e0d27cc863ba1b8de20e861e6b5d9b922a8e > Merge: 92c23f6d9c20 e61076683850 > Author: Martin Matuska > AuthorDate: Fri May 12 13:12:59 2023 +0200 > Commit: Martin Matuska > CommitDate: Fri May 12 13:13:33 2023 +0200 > > zfs: merge openzfs/zfs@e61076683 > > Notable upstream pull request merges: > #14744 Optimize check_filesystem() and process_error_log() > #14773 Allow zhack label repair to restore detached devices > #14794 zpool import -m also removing spare and cache when log d= evice > is missing > #14805 Simplify and optimize random_int_between() > #14813 Enable the head_errlog feature to remove errors > #14816 Fix two abd_gang_add_gang() issues > #14817 Verify block pointers before writing them out > #14819 Add dmu_tx_hold_append() interface > #14823 Remove single parent assertion from zio_nowait() > #14824 Plug memory leak in zfsdev_state > #14825 Block cloning dbuf fixes > #14828 Remove duplicate code in l2arc_evict() > #14837 Fixes in head_errlog feature with encryption > #14839 Prevent panic during concurrent snapshot rollback and zv= ol read > #14853 zil: Don't expect zio_shrink() to succeed > > Obtained from: OpenZFS > OpenZFS commit: e6107668385044718b0a73330ed6423650806473 > > commit 4d846d260e2b9a3d4d0a701462568268cbfe7a5b > Author: Warner Losh > AuthorDate: Wed May 10 09:40:58 2023 -0600 > Commit: Warner Losh > CommitDate: Fri May 12 10:44:03 2023 -0600 > > spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -Free= BSD > > The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier= . Catch > up to that fact and revert to their recommended match of BSD-2-Cl= ause. > > Discussed with: pfg > MFC After: 3 days > Sponsored by: Netflix > > commit c0a83fe074a375c66ca669bfe1f128fe12b9f377 > Merge: 634a770a5e16 ad0a554614b0 > Author: Martin Matuska > AuthorDate: Tue May 23 11:50:17 2023 +0200 > Commit: Martin Matuska > CommitDate: Tue May 23 11:51:52 2023 +0200 > > zfs: merge openzfs/zfs@ad0a55461 > > Notable upstream pull request merges: > #12355 Teach zpool scrub to scrub only blocks in error log > #14811 Refine special_small_blocks property validation > #14854 zil: Some micro-optimizations > #14855 zil: Free lwb_buf after write completion > #14860 Fixes for issues identified by recent Coverity defect re= ports > #14861 Probe vdevs before marking removed > #14873 Add the ability to uninitialize a zpool > #14875 Hold db_mtx when updating db_state > > Obtained from: OpenZFS > OpenZFS commit: ad0a554614b096698d9969340c4c593690042d5b > > commit 48f52d9179d5920750cef0c5d921db63de4d767d > Author: John Baldwin > AuthorDate: Thu May 25 07:11:38 2023 -0700 > Commit: John Baldwin > CommitDate: Thu May 25 07:11:38 2023 -0700 > > zfs: Fix build on 32-bit platforms after most recent import. > > unsigned long is not a uint64_t on 32-bit platforms. The zfs.4 > manpage documents this variable as a uint, and it is only compare= d > with other variables of type int, so uint_t makes more sense than > unsigned long. > > (I also wasn't sure if ULONG would work as a ZFS_MODULE_PARAM typ= e > on other OS's) > > commit 4e8d558c9d1cf3e7e424e3fb123b01979c3d57f2 > Merge: 5ca7f0294694 feff9dfed3df > Author: Martin Matuska > AuthorDate: Sat Jun 10 19:31:17 2023 +0200 > Commit: Martin Matuska > CommitDate: Sat Jun 10 19:31:17 2023 +0200 > > zfs: merge openzfs/zfs@feff9dfed > > Notable upstream pull request merges: > #14833 Update compatibility.d files > #14841 ZIL: Reduce scope of per-dataset zl_issuer_lock > #14863 zil: Add some more statistics > #14866 btree: Implement faster binary search algorithm > #14894 Fix inconsistent definition of zfs_scrub_error_blocks_pe= r_txg > #14892 Fix concurrent resilvers initiated at same time > #14903 Fix NULL pointer dereference when doing concurrent 'send= ' operations > #14910 ZIL: Allow to replay blocks of any size > #14939 Fix the L2ARC write size calculating logic > #14934 Introduce zfs_refcount_(add|remove)_few() > #14946 Improve l2arc reporting in arc_summary > #14953 Finally drop long disabled vdev cache > #14954 Fix the L2ARC write size calculating logic (2) > #14955 Use list_remove_head() where possible > #14959 ZIL: Fix race introduced by f63811f0721 > > Obtained from: OpenZFS > OpenZFS commit: feff9dfed3df1bbae5dd74959a6ad87d11f27ffb > > commit b7198dcfc03967cba191a373d99df47ee52d6e2a > Merge: 2c7279bae776 10e36e17612b > Author: Martin Matuska > AuthorDate: Fri Jun 16 23:12:27 2023 +0200 > Commit: Martin Matuska > CommitDate: Fri Jun 16 23:13:05 2023 +0200 > > zfs: merge openzfs/zfs@10e36e176 > > Notable upstream pull request merges: > #14948 Remove ARC/ZIO physdone callbacks > #14963 Store the L2ARC device ashift in the vdev label > #14970 Switch refcount tracking from lists to AVL-trees > #14981 Shorten arcstat_quiescence sleep time > > Obtained from: OpenZFS > OpenZFS commit: 10e36e17612ba9c634b140ae76847bb62b5be68f > > commit f190c36b5d45cbfadc922a69d79628c43cdda22f > Merge: 229d643c4dd5 8e8acabdcaeb > Author: Martin Matuska > AuthorDate: Sun Jun 25 10:31:19 2023 +0200 > Commit: Martin Matuska > CommitDate: Sun Jun 25 10:32:42 2023 +0200 > > zfs: merge openzfs/zfs@8e8acabdc > > Notable upstream pull request merges: > #14987 Fix memory leak in zil_parse() > > Obtained from: OpenZFS > OpenZFS commit: 8e8acabdcaeb831c777f71361722f4235b698a8d > > We can't ship 14.0 with this deadlock. > > DES > -- > Dag-Erling Sm=C3=B8rgrav - des@FreeBSD.org > From nobody Thu Aug 10 05:30:43 2023 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 4RLwWR2Hf5z4q6vJ for ; Thu, 10 Aug 2023 05:30:59 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-8.consmr.mail.gq1.yahoo.com (sonic307-8.consmr.mail.gq1.yahoo.com [98.137.64.32]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4RLwWP6Z4Dz3dBh for ; Thu, 10 Aug 2023 05:30:57 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b="B+VU/y86"; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1691645455; bh=GKPRjxKt5ErGmSbnhkel9wz6YNr2W5JYqzL8WtlOx3Y=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=B+VU/y86dbEgYR0ffbDZsRpl3S3J/sIyyF2KVtSSPy6021enahq+Y5uiGVXdegEoIXAqi5pFVqmUfNXiM9lTG6BAOitmtYPMYamzl3IPWmfrOkduMIURkltdU7M/s4gcxtKrVgUA2925Vg0cxbzFq5mp0JUGLGUBWtnxG6zihK8j/EHfW7QwKYLlx0yNxOjPhQFd/6TSITRhdYIiYKgEM4PI51/TbdFEFHLij7xXqSfANU6iGNtUIdfbvQKDAHVk9Zg67gsZnvkSVac8d1k3qj2VQPUfPlovCKTUF/uNhur9jT2xnPF5bLnabdAJtGJbKZg0v127/W1knFm4g/X6Zg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1691645455; bh=2oBD3vOH981CQTrDqL+agVGBXfQOeWpzPi41RX0QojK=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=H8I7g0xenQF4NFCaR7ivmqtahBPqNQAUAbFKMHncdWFqkm7tlONyWQBme60uIgrngVpAeXvXZFa1hqil06qbxEmMhujgwyb7T2Tco58QRNX1C7G6sSH28UuEpsCxM/TWWukrZzRforOWw524RXypfFA+P8/c7aTeA9pEvjq+51Ztw8h2h5gV3dyXM4J5FYQhYIG7qtO82zDdKIv2AfGYXe4jpdZBXBuvRaA3SOtw+/+F7V90GgWdij1p9Qxc2JaAntfL8i+NKObmr+13gKRLmQJMTeoSzRbCKW0fpL3dh2GYfqQvSxd7yaYyixZiWlY+Bti7vRpfVO3IIskzoch9jw== X-YMail-OSG: SrkqeMcVM1lmEE3S97sfpxMgNsM0rbBWr6M8Co1etYPXcJRprdi2JH9NOr524jG Bklo_3nqdL2oLxmYRdw5LKXyVW2zzTDCtwrcQ3GNqu0lv7OHMHCIXmO13lflj32bQkR3tku8feBL WxSxIT3KFeZvmHdWzo8f7qhamxyLD00meMkPfChVGejE0y5QW51KWUzAYgw_sMGA39kWhr77Up_E GV9bCshWHGQBRmWMj2_4k6GzJY6Q7GK_Pt61QoLKFLCNDvULzMmKnh7QHREY0JTYRjz67mG1O5hQ DtOWupR8aPds8PMAm3stgj7najA5BXQFJerbGAe_3rmCYclYzVnwzoVG6pvFdh_XCxLwxN_a2Kv6 iJYIILD2yQP7z.7Vx20V7NrMmZ.Y5s4xALNJlgJTv1Y_zr7gXcrk5FOSzCKKq853c_AEYMn.OQCR MboCC_GNh2ON2Tk4NB_hjqdEjjDEZxbc1j0libXNj50owNX4q1xrMv1wL4peweNJeKNkKRmxz6IH iQxrdfbloZUOHzncwIENHnjZpVTJ2DFzL59wpkUkSmyv6zs4xiFVRMWO7tx9Jo6Y843.uyQ6UPda zITVmLcyfcvTTZlKRZlA8oIk6mm0P0BzT31Rw6Ykm04cd0mRE4KKgd5NULuf53Sl1F2YGqJZeoEc xcOHhYbh62TDhbrNV3miE5K9DhOUGJEyoz9oNDIP7AsEtUVC_SEr6iBHo0Y5YqoMjpl9F4mrc9Ey x1K6m5u7jhXdKYqjdKN4fG_OvmKLe1JRbJpqJNUmAm67GmVrbZGwtWUAqNVtWsYLcY4ob68jddYW VZYYUSZ5kX37tIGMaYKuBrLd6oYptPUUVS4SibIjCSn7M3izI4t5tDPxRY13qtXFTn5YikRtJ0nl h0UGhB9j.xWGExzRXDecu71vB3Ml6cccKlFvPZ0zOD8fvF8ZyHACtGZpYrmbQ0KwwKoPHhUDHKPy A6kKgqL68eIadS_5XPFjucNGlTVuGHUbPK3tewtAYH6sDdxwAfI5Fo.9JjWseKSGSUVz_.QtatEq XhdZeUCDRhaDv7O0T7NNvUabgpQxqZfYhjzCMlX8T23pigGs2pLfaILzne9PpgkR41_2k5Xghx.N InZq1fRs7YPuh2H0Ut9SIiY5Q3RBUgqTreJtlZywIJZNYD1IU30hIvqdxo30HhWpapSovYACnP3n dsbxha6S9PGOrgbtidCE.fLUUsdAkZLFyY2.C130Ux0S6zACu5W_nSui3MWv.0y0vUQuWYZgV1kB SNJwebbRQS6lFQ_lZVdPbByZCqOAsUnmr4ocP6g.81iBwhX52lTU4dARlT0vqoU4zQTVhNAr7Fyd 60XfqNzugjA2224yOgHE9UxiIjpdTv0gGW4cWptshbJbih8ytqV59QjTjcPbJTmslLwo.dBbeqVw vzEliO_DZC3UIXmEnBOsatYvk0DDz4.Z.izwh7l1odG5oVhozWKCNRv4BM_fkKANtS.5Q3weW3qx iYDomI8yE6w0GE5HVeeQy3PV6S_v.8eO.C.vsxHVEP6bPX0VZOImjznPHlcf9mYaocmiqcrox3eV 3xhJd.UpeiF5mC13JBvoUt5T_Mo0475qw16KhLTCnc9KchrvdTI0tUucc3XXITaUhgVD58uboVRu Sr_QBIRx8oFhZ6wC4KdLlkmWKxQkg5R6hFscnR3826fa1.1tC7rXRgfFp.BlAHCF5i8J4uT2Q2fL DkxkS4dTCxR1bzieTU3khZhLi4lQaKgKkFWRFeK8EncuYouvF6BV4oJtpBz6jCrPqOZa9S4eNfMA VLBULsg2DfoeideLEXTocgCW0bltujIb5fbh4UsA3j_7Pw1mzB.hWyeBjhMIWkHIIxGBkVV8OD4p Kn7NWWPYCqpuWTFM7qmTKrSpmbNB9x9kHKf4IujLXqqdaEvV5PZA2F4nRz0sLtGuV9mO.UpUA5YF d6_b3eXmx8xW1.ozwRRjqD6CWhCqQwQA763hLMeyaFtkKLiEs23Y1CmMbLcedVsNKxuGNSjJzShd X_NRUgQXyh80wnXnB1kf0AvVt9rMFplXlJw999wJxcmKlLWPQJa81FxDx3FfqiUiWHtvuWZn.Aa6 IGQY4GZ5IhSUuSExFbsM9y1xxD.Vv5e8P3N5jsWrEWwjhldl70kM2aJ1jxYz.jtLM39d8sLkzfze 50tIxz6JRI542o_UkbWXhRirR.NCv6Qy8BTaBV3U3n9NrJGfYYU1fO2FdRtqRwKT1NjT92Epb80c pzbR7autM6MCMvy3iy4hjD7qXF08tvGOLSjQdwHiwbz.iL2w_Upla9UvhWUrJ3U1P21JSwa4mUxl E X-Sonic-MF: X-Sonic-ID: f8a41e83-fefa-4367-a584-0c7fa0e6f53e Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Thu, 10 Aug 2023 05:30:55 +0000 Received: by hermes--production-bf1-865889d799-x5klk (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID c62575e63d9df2848699472a89f2f259; Thu, 10 Aug 2023 05:30:51 +0000 (UTC) From: Mark Millard 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 16.0 \(3731.700.6\)) Subject: aarch64 (not armv7) kyua run on main [so: 14]: sys/net/if_lagg_test:status_stress got "Fatal data abort" panic Message-Id: <6F4285CB-6E3E-4A88-A830-8E54E68717ED@yahoo.com> Date: Wed, 9 Aug 2023 22:30:43 -0700 To: FreeBSD ARM List , Current FreeBSD X-Mailer: Apple Mail (2.3731.700.6) References: <6F4285CB-6E3E-4A88-A830-8E54E68717ED.ref@yahoo.com> X-Spamd-Result: default: False [-3.49 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.993]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ARC_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.32:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.32:from]; DKIM_TRACE(0.00)[yahoo.com:+]; TO_DN_ALL(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MID_RHS_MATCH_FROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2] X-Spamd-Bar: --- X-Rspamd-Queue-Id: 4RLwWP6Z4Dz3dBh The context is on a Windows Dev Kit 2023, using a bectl based boot/root = disk: # uname -apKU FreeBSD CA78C-WDK23-ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT aarch64 = 1400094 #9 main-n264643-0befc55cdf4b-dirty: Wed Aug 9 14:23:48 PDT 2023 = = root@CA78C-WDK23-ZFS:/usr/obj/BUILDs/main-CA78C-dbg-clang/usr/main-src/arm= 64.aarch64/sys/GENERIC-DBG-CA78C arm64 aarch64 1400094 1400094 I only do bugzailla submittals based on just my own builds as a means of last resort: I try to use official builds for such. The: main-n264491-8a5c836b51ce: Thu Aug 3 snapshot did not panic on the RPi4B that I tried it with. We will see for the next snapshot at some point. Both the non-debug and the debug kernels panic. I saw no evidence of the debug kernel reporting anything. Note the: 0xdeadc0dedeadc0de (2 examples) and: 0xfefefefefefefeff (1 example) that may have some significance. . . . sys/net/if_gif:basic -> passed [0.195s] sys/net/if_lagg_test:create -> passed [0.125s] sys/net/if_lagg_test:create_destroy_stress -> skipped: Skipping this = test because it easily panics the machine [0.022s] sys/net/if_lagg_test:lacp_linkstate_destroy_stress -> passed = [60.048s] sys/net/if_lagg_test:set_ether -> passed [0.090s] sys/net/if_lagg_test:status_stress -> =20 <6>lagg0: link state changed to DOWN Fatal data abort: x0: 0xffff000186c82858 (_DYNAMIC + 0x271e46b8) x1: 0x0000000000000001 x2: 0xdeadc0dedeadc0de x3: 0xffff0000005b68c0 (ifdead_ioctl + 0x0) x4: 0xffffa000a8ba305e x5: 0xffffa00023d932fa x6: 0x000000006767616c x7: 0x6e6d760070617401 x8: 0x000000000000030c x9: 0x0000000000210005 x10: 0x0000000000000800 x11: 0xfefefefefefefeff x12: 0x0000000000000008 x13: 0x0000000000000000 x14: 0x0000000000010000 x15: 0x0000000000000001 x16: 0x0000000000010000 x17: 0x0000000000000007 x18: 0xffff000186c82520 <6>ue0: link state changed to DOWN (_DYNAMIC + 0x271e4380) x19: 0xffff000186c82858 (_DYNAMIC + 0x271e46b8) x20: 0xffffa000a8ba3000 x21: 0xffffa000a8ba3058 x22: 0x000000000000000c x23: 0x0000000000000005 x24: 0x0000000000000000 x25: 0xffff000000c7a000 (keysw + 0xb8) x26: 0x0000000000000000 x27: 0xffff000000cf9000 (sdta_vfs_vop_vop_spare4_return1 + 0x18) x28: 0x0000000000000008 x29: 0xffff000186c82540 (_DYNAMIC + 0x271e43a0) sp: 0xffff000186c82520 lr: 0xffff0000006a0b50 (dump_iface + 0x2c0) elr: 0xffff0000006a124c (dump_sa + 0x1c) spsr: 0x0000000000400045 far: 0xdeadc0dedeadc0df esr: 0x0000000096000004 timeout stopping cpus panic: vm_fault failed: 0xffff0000006a124c error 1 cpuid =3D 2 time =3D 1691642123 KDB: stack backtrace: db_trace_self() at db_trace_self db_trace_self_wrapper() at db_trace_self_wrapper+0x30 vpanic() at vpanic+0x13c panic() at panic+0x44 data_abort() at data_abort+0x358 handle_el1h_sync() at handle_el1h_sync+0x14 --- exception, esr 0x96000004 dump_sa() at dump_sa+0x1c dump_iface() at dump_iface+0x2bc dump_cb() at dump_cb+0x18 if_foreach_sleep() at if_foreach_sleep+0x208 rtnl_handle_getlink() at rtnl_handle_getlink+0xec rtnl_handle_message() at rtnl_handle_message+0x19c nl_taskqueue_handler() at nl_taskqueue_handler+0x5f4 taskqueue_run_locked() at taskqueue_run_locked+0x1a4 taskqueue_thread_loop() at taskqueue_thread_loop+0xc8 fork_exit() at fork_exit+0x74 fork_trampoline() at fork_trampoline+0x14 This was from: # /usr/bin/kyua test -k /usr/tests/Kyuafile But the earlier part of the run is not needed to get the panic. Booting, logging in as root, and doing: # /usr/bin/kyua test -k /usr/tests/Kyuafile = sys/net/if_lagg_test:status_stress is sufficient to get the panic in my context. For reference for the RPi4B not getting the panic: Trying on an RPi4B with a somewhat older snapshot did not panic: # uname -apKU you have mail FreeBSD generic 14.0-CURRENT FreeBSD 14.0-CURRENT aarch64 1400093 #0 = main-n264491-8a5c836b51ce: Thu Aug 3 12:10:50 UTC 2023 = root@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC = arm64 aarch64 1400093 1400093 # /usr/bin/kyua test -k /usr/tests/Kyuafile = sys/net/if_lagg_test:status_stress sys/net/if_lagg_test:status_stress -> passed [60.371s] Results file id is usr_tests.20230804-151402-553517 Results saved to = /root/.kyua/store/results.usr_tests.20230804-151402-553517.db 1/1 passed (0 failed) =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu Aug 10 06:09:22 2023 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 4RLxMq01gmz4q9Nd for ; Thu, 10 Aug 2023 06:09:27 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (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 4RLxMp0rKKz4F4q for ; Thu, 10 Aug 2023 06:09:26 +0000 (UTC) (envelope-from guru@unixarea.de) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of guru@unixarea.de designates 178.254.4.101 as permitted sender) smtp.mailfrom=guru@unixarea.de; dmarc=none Received: from [188.174.49.81] (helo=localhost.unixarea.de) by ms-10.1blu.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qTyrL-00051R-H0 for freebsd-current@freebsd.org; Thu, 10 Aug 2023 08:09:23 +0200 Received: from localhost.my.domain (localhost [127.0.0.1]) by localhost.unixarea.de (8.16.1/8.14.9) with ESMTPS id 37A69MAa001636 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Thu, 10 Aug 2023 08:09:22 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.16.1/8.14.9/Submit) id 37A69MAt001635 for freebsd-current@freebsd.org; Thu, 10 Aug 2023 08:09:22 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Thu, 10 Aug 2023 08:09:22 +0200 From: Matthias Apitz To: freebsd-current@freebsd.org Subject: poudriere && --MAKE_ENV-- section Message-ID: Reply-To: Matthias Apitz 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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Operating-System: FreeBSD 13.0-CURRENT r368166 (amd64) X-message-flag: Mails containing HTML will not be read! Please send only plain text. X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 188.174.49.81 X-Spamd-Result: default: False [-1.40 / 15.00]; NEURAL_HAM_SHORT(-0.91)[-0.915]; NEURAL_HAM_MEDIUM(-0.74)[-0.742]; MID_RHS_NOT_FQDN(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:178.254.4.101]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_LONG(0.06)[0.058]; ASN(0.00)[asn:42730, ipnet:178.254.0.0/19, country:DE]; R_DKIM_NA(0.00)[]; DMARC_NA(0.00)[unixarea.de]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; HAS_XOIP(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_LAST(0.00)[]; REPLYTO_EQ_FROM(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; HAS_XAW(0.00)[]; HAS_REPLYTO(0.00)[guru@unixarea.de] X-Spamd-Bar: - X-Rspamd-Queue-Id: 4RLxMp0rKKz4F4q If I look into the log of a job run in poudriere, from where the section --MAKE_ENV-- OPENSSLBASE=/usr/local OPENSSLDIR=/usr/local/openssl ... --MAKE_ENV-- is pulled in? It is not (my) definition from the jail's make.conf. I have the problem, that a given port (lang/python27) does not compile with OPENSSLBASE=/usr/local ..., but with OPENSSLBASE=/usr ... and exactly this section changed and I do not get how. Thanks matthias -- Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub From nobody Thu Aug 10 09:38:03 2023 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 4RM20c0Mqtz4TtRx for ; Thu, 10 Aug 2023 09:38:08 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (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 4RM20b57mBz4bC0; Thu, 10 Aug 2023 09:38:07 +0000 (UTC) (envelope-from guru@unixarea.de) Authentication-Results: mx1.freebsd.org; none Received: from [132.174.172.2] (helo=pureos) by ms-10.1blu.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qU27J-0005Gm-9o; Thu, 10 Aug 2023 11:38:05 +0200 Date: Thu, 10 Aug 2023 11:38:03 +0200 From: Matthias Apitz To: Moin Rahman Cc: freebsd-current@freebsd.org Subject: Re: port lang/python27 does not build in 14.0-CURRENT w/ poudriere Message-ID: Reply-To: Matthias Apitz Mail-Followup-To: Moin Rahman , freebsd-current@freebsd.org References: <414B922C-C553-41D4-B519-E3B3B239B606@freebsd.org> <9A29A1BA-F957-40D9-96C6-062471BA14AF@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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9A29A1BA-F957-40D9-96C6-062471BA14AF@freebsd.org> X-Operating-System: FreeBSD 13.0-CURRENT r368166 (amd64) X-message-flag: Mails containing HTML will not be read! Please send only plain text. X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 132.174.172.2 X-Rspamd-Queue-Id: 4RM20b57mBz4bC0 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:42730, ipnet:178.254.0.0/19, country:DE] El día Wednesday, August 09, 2023 a las 06:04:16PM +0200, Moin Rahman escribió: > This perfectly builds on the latest HEAD without any problem as shared in my build log. I am not sure what is wrong at your end. Neither can I see any fallout on the clusters. > I've cc'ed freebsd-current@ I did two times the building of lang/python27 within poudriere on 14.0-CURRENT: =>> Building lang/python27 build started at Tue Aug 8 04:05:20 CEST 2023 port directory: /usr/ports/lang/python27=>> Building lang/python27 =>> Building lang/python27 build started at Thu Aug 10 06:33:53 CEST 2023 port directory: /usr/ports/lang/python27 The first failed, the one of today went fine. The main difference in the building log is: failing job: --MAKE_ENV-- OPENSSLBASE=/usr/local OPENSSLDIR=/usr/local/openssl OPENSSLINC=/usr/local/include OPENSSLLIB=/usr/local/lib OPENSSLRPATH=/usr/local/lib fine job: --MAKE_ENV-- OPENSSLBASE=/usr OPENSSLDIR=/etc/ssl OPENSSLINC=/usr/include OPENSSLLIB=/usr/lib ... I didn't changed anything in the poudriere config or port's options. The only thing I did between was yesterday evening a 'git pull' in /usr/ports. What could have triggered this change of the used SSL version? matthias -- Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub From nobody Thu Aug 10 09:50:31 2023 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 4RM2Gy6ydZz4Tv9v for ; Thu, 10 Aug 2023 09:50:34 +0000 (UTC) (envelope-from agh@riseup.net) Received: from mx0.riseup.net (mx0.riseup.net [198.252.153.6]) (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 "mx0.riseup.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RM2Gy10GHz4dSd; Thu, 10 Aug 2023 09:50:34 +0000 (UTC) (envelope-from agh@riseup.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=riseup.net header.s=squak header.b=KjLY4LFS; spf=pass (mx1.freebsd.org: domain of agh@riseup.net designates 198.252.153.6 as permitted sender) smtp.mailfrom=agh@riseup.net; dmarc=pass (policy=none) header.from=riseup.net Received: from fews01-sea.riseup.net (fews01-sea-pn.riseup.net [10.0.1.109]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx0.riseup.net (Postfix) with ESMTPS id 4RM2Gw2LBXz9s4y; Thu, 10 Aug 2023 09:50:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1691661032; bh=ezlQhZ6cMGc8QTjOtlvoBijmKt84/CyXGHzPAcC++3A=; h=Date:From:To:Subject:In-Reply-To:References:From; b=KjLY4LFSL5le8FqLfDdQ+cEDdlfW/dFrdosUi70vqEGMwahLj0UubkJ8XT8v5cEi2 zgV+qjbuunmVt2Q+/7K6M71QqPYOXu5FOhc+kEcH+H+Ebw1m75MyzL2Gzj82nIfoR6 0PCiEtlfH5zHB3g4haW8LcyUYjUCgl+YD2G6y2Cw= X-Riseup-User-ID: 5DCB5201699EB5F646EF1CA4D674586016F7AE32BD06B85483AA3E59FF12D445 Received: from [127.0.0.1] (localhost [127.0.0.1]) by fews01-sea.riseup.net (Postfix) with ESMTPSA id 4RM2Gw14NjzJq8b; Thu, 10 Aug 2023 09:50:32 +0000 (UTC) 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: Thu, 10 Aug 2023 09:50:31 +0000 From: Alastair Hogge To: Moin Rahman , freebsd-current@freebsd.org Subject: Re: port lang/python27 does not build in 14.0-CURRENT w/ poudriere In-Reply-To: References: <414B922C-C553-41D4-B519-E3B3B239B606@freebsd.org> <9A29A1BA-F957-40D9-96C6-062471BA14AF@freebsd.org> Message-ID: <87c58b62df16bd5cc31952d814bbe995@riseup.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spamd-Result: default: False [-4.06 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.98)[-0.984]; NEURAL_HAM_MEDIUM(-0.98)[-0.980]; DMARC_POLICY_ALLOW(-0.50)[riseup.net,none]; R_DKIM_ALLOW(-0.20)[riseup.net:s=squak]; R_SPF_ALLOW(-0.20)[+a:mx0.riseup.net]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[198.252.153.6:from]; TO_DN_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:16652, ipnet:198.252.153.0/24, country:US]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ARC_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; DWL_DNSWL_NONE(0.00)[riseup.net:dkim]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[riseup.net:+]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4RM2Gy10GHz4dSd On 2023-08-10 17:38, Matthias Apitz wrote: > El día Wednesday, August 09, 2023 a las 06:04:16PM +0200, Moin Rahman escribió: > >> This perfectly builds on the latest HEAD without any problem as shared in my build log. I am not sure what is wrong at your end. Neither can I see any fallout on the clusters. >> > > I've cc'ed freebsd-current@ > > I did two times the building of lang/python27 within poudriere on > 14.0-CURRENT: > > =>> Building lang/python27 > build started at Tue Aug 8 04:05:20 CEST 2023 > port directory: /usr/ports/lang/python27=>> Building lang/python27 > > =>> Building lang/python27 > build started at Thu Aug 10 06:33:53 CEST 2023 > port directory: /usr/ports/lang/python27 > > The first failed, the one of today went fine. The main difference in the > building log is: > > failing job: > --MAKE_ENV-- > OPENSSLBASE=/usr/local OPENSSLDIR=/usr/local/openssl OPENSSLINC=/usr/local/include OPENSSLLIB=/usr/local/lib OPENSSLRPATH=/usr/local/lib > > fine job: > --MAKE_ENV-- > OPENSSLBASE=/usr OPENSSLDIR=/etc/ssl OPENSSLINC=/usr/include OPENSSLLIB=/usr/lib > ... > > I didn't changed anything in the poudriere config or port's options. The > only thing I did between was yesterday evening a 'git pull' in > /usr/ports. > > What could have triggered this change of the used SSL version? Do you have the error from the failed build? I have the following patch in my tree to get Python-2.7 to build, tho I have not tested recently if it is still required: diff --git a/lang/python27/pkg-plist b/lang/python27/pkg-plist index 4d8dc5b06c81..a92192e6c9d6 100644 --- a/lang/python27/pkg-plist +++ b/lang/python27/pkg-plist @@ -1908,7 +1908,6 @@ lib/python2.7/lib-dynload/_curses.so lib/python2.7/lib-dynload/_curses_panel.so lib/python2.7/lib-dynload/_elementtree.so lib/python2.7/lib-dynload/_functools.so -lib/python2.7/lib-dynload/_hashlib.so lib/python2.7/lib-dynload/_heapq.so lib/python2.7/lib-dynload/_hotshot.so lib/python2.7/lib-dynload/_io.so There was some heavy OpenSSL work recently, and it maybe possible there is some fallout still from that? -- To health and anarchy, Alastair From nobody Thu Aug 10 10:13:52 2023 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 4RM2nw0h0Vz4Tws8 for ; Thu, 10 Aug 2023 10:13:56 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (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 4RM2nw08Zwz4hwF; Thu, 10 Aug 2023 10:13:56 +0000 (UTC) (envelope-from guru@unixarea.de) Authentication-Results: mx1.freebsd.org; none Received: from [132.174.172.2] (helo=pureos) by ms-10.1blu.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qU2fy-0007kB-7l; Thu, 10 Aug 2023 12:13:54 +0200 Date: Thu, 10 Aug 2023 12:13:52 +0200 From: Matthias Apitz To: Alastair Hogge Cc: Moin Rahman , freebsd-current@freebsd.org Subject: Re: port lang/python27 does not build in 14.0-CURRENT w/ poudriere Message-ID: Reply-To: Matthias Apitz Mail-Followup-To: Alastair Hogge , Moin Rahman , freebsd-current@freebsd.org References: <414B922C-C553-41D4-B519-E3B3B239B606@freebsd.org> <9A29A1BA-F957-40D9-96C6-062471BA14AF@freebsd.org> <87c58b62df16bd5cc31952d814bbe995@riseup.net> 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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87c58b62df16bd5cc31952d814bbe995@riseup.net> X-Operating-System: FreeBSD 13.0-CURRENT r368166 (amd64) X-message-flag: Mails containing HTML will not be read! Please send only plain text. X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 132.174.172.2 X-Rspamd-Queue-Id: 4RM2nw08Zwz4hwF X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:42730, ipnet:178.254.0.0/19, country:DE] El día jueves, agosto 10, 2023 a las 09:50:31 +0000, Alastair Hogge escribió: > On 2023-08-10 17:38, Matthias Apitz wrote: > > El día Wednesday, August 09, 2023 a las 06:04:16PM +0200, Moin Rahman escribió: > > > >> This perfectly builds on the latest HEAD without any problem as shared in my build log. I am not sure what is wrong at your end. Neither can I see any fallout on the clusters. > >> > > > > I've cc'ed freebsd-current@ > > > > I did two times the building of lang/python27 within poudriere on > > 14.0-CURRENT: > > > > =>> Building lang/python27 > > build started at Tue Aug 8 04:05:20 CEST 2023 > > port directory: /usr/ports/lang/python27=>> Building lang/python27 > > > > =>> Building lang/python27 > > build started at Thu Aug 10 06:33:53 CEST 2023 > > port directory: /usr/ports/lang/python27 > > > > The first failed, the one of today went fine. The main difference in the > > building log is: > > > > failing job: > > --MAKE_ENV-- > > OPENSSLBASE=/usr/local OPENSSLDIR=/usr/local/openssl OPENSSLINC=/usr/local/include OPENSSLLIB=/usr/local/lib OPENSSLRPATH=/usr/local/lib > > > > fine job: > > --MAKE_ENV-- > > OPENSSLBASE=/usr OPENSSLDIR=/etc/ssl OPENSSLINC=/usr/include OPENSSLLIB=/usr/lib > > ... > > > > I didn't changed anything in the poudriere config or port's options. The > > only thing I did between was yesterday evening a 'git pull' in > > /usr/ports. > > > > What could have triggered this change of the used SSL version? > > Do you have the error from the failed build? I have the following patch > in my tree to get Python-2.7 to build, tho I have not tested recently if > it is still required: The log of the failing job is here: http://www.unixarea.de/python27-2.7.18_2.log It has exactly the issue which your patch addresses: with OpenSSL from ports it can't build the shared object _hashlib.so. I can live with this for now (as the package was built now). But I wanted to understand, why and what was the change between August 8 and 10. matthias -- Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub From nobody Thu Aug 10 10:27:33 2023 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 4RM35k3h0rz4TxTg for ; Thu, 10 Aug 2023 10:27:38 +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 4RM35j4fQ1z4kl8; Thu, 10 Aug 2023 10:27:37 +0000 (UTC) (envelope-from pi@freebsd.org) Authentication-Results: mx1.freebsd.org; dkim=none; spf=softfail (mx1.freebsd.org: 2001:14f8:200::1 is neither permitted nor denied by domain of pi@freebsd.org) smtp.mailfrom=pi@freebsd.org; dmarc=none Received: from pi by home.opsec.eu with local (Exim 4.95 (FreeBSD)) (envelope-from ) id 1qU2tB-0007Yw-3o; Thu, 10 Aug 2023 12:27:33 +0200 Date: Thu, 10 Aug 2023 12:27:33 +0200 From: Kurt Jaeger To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= Cc: current@freebsd.org Subject: Re: ZFS deadlock in 14 Message-ID: <20230810102733.GB11506@home.opsec.eu> References: <86leeltqcb.fsf@ltc.des.no> 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: <86leeltqcb.fsf@ltc.des.no> X-Spamd-Result: default: False [-2.73 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; NEURAL_HAM_MEDIUM(-0.74)[-0.738]; ONCE_RECEIVED(0.10)[]; MIME_GOOD(-0.10)[text/plain]; FREEFALL_USER(0.00)[pi]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:12502, ipnet:2001:14f8::/32, country:DE]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_SOFTFAIL(0.00)[~all]; DMARC_NA(0.00)[freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[current@freebsd.org] X-Spamd-Bar: -- X-Rspamd-Queue-Id: 4RM35j4fQ1z4kl8 Hi! > At some point between 42d088299c (4 May) and f0c9703301 (26 June), a > deadlock was introduced in ZFS. It is still present as of 9c2823bae9 (4 > August) and is 100% reproducable just by starting poudriere bulk in a > 16-core VM and waiting a few hours until deadlkres kicks in. I have a amd based builder, 32 cores, run 437e1e37dfca from Thu Jul 27 01:26:39 CEST 2023 and do not see those crashes. zpool get feature@block_cloning zroot NAME PROPERTY VALUE SOURCE zroot feature@block_cloning enabled local -- pi@opsec.eu +49 171 3101372 Now what ? From nobody Thu Aug 10 11:34:39 2023 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 4RM4b836DRz4m7sd for ; Thu, 10 Aug 2023 11:34:44 +0000 (UTC) (envelope-from void@f-m.fm) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (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 4RM4b72N3Xz4tb4 for ; Thu, 10 Aug 2023 11:34:43 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm3 header.b=om5WVZaU; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=pDc34GvR; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 66.111.4.25 as permitted sender) smtp.mailfrom=void@f-m.fm; dmarc=pass (policy=none) header.from=f-m.fm Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 203B25C011D for ; Thu, 10 Aug 2023 07:34:42 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Thu, 10 Aug 2023 07:34:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-type:content-type:date:date:from:from:in-reply-to :message-id:mime-version:reply-to:sender:subject:subject:to:to; s=fm3; t=1691667282; x=1691753682; bh=Y/RAeqSp2sSdDID3cviwk2zzo ZWGYKy5+sjwv6Cv0Qw=; b=om5WVZaUF+4tFEqh5fRIBrksy/UTQUkop5Up4YRvw MGS3w2LHEdiAsc1be734eOgHrVdVyB6fvmltExY1mCgy8r0YJfvQ4ADngFKuF8Qn W5JSRw2j/B7HPCoHu5laVcYG7TGLel7Vu2Faz0oVa+PVprjjMuevJ/mn/gNz8+SR uy23FkcPPwDElzgh5c/FtrIqV60Gs/JjUavKiFjG3vafstcVESqYdsChK7POHL1Q nQnqclq+RywZwPG0VD9v99d11RrFwHZ0FiuMuKDhsEoboUyrdBN+6Zd9uZT9rtpu FD4HC/omQu8IdFgRJ55XLUso5TsvJht7+sfZFooCl2Fwg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:message-id :mime-version:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1691667282; x=1691753682; bh=Y/RAeqSp2sSdDID3cviwk2zzoZWGYKy5+sj wv6Cv0Qw=; b=pDc34GvR+nf1dopeug+4EXrynheBI9HvFKlUlF2HZ4Z1g8JUg0/ mYjEj5Ezxlf2udAbM6kAteGgqq48aStowAWBL6LekMxnnVmYiS+WrbbedmMrR3VZ 42eAEzSB7OKKZf2RHUBmfvAxqj/KXp2dd0LUB2/edMOsvjVan45OUml3EMR6LaC4 mezE1CT0J2jq98faQMxZrv5CQ9/fMK/v3vd0LRjxHtelHXJlGH/ip/lc9bwXypq8 VhLCpryCtAfyB1av2xCBR6Fn5D1WqmsNKTmb/OJjJktySCB+PkZDrUvD3gcOFlyB u5c4Q3IDFsgjX/IOevDlSi762QVml/FH09A== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrleeigdegudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfggtggusehttdertddttd dvnecuhfhrohhmpehvohhiugcuoehvohhiugesfhdqmhdrfhhmqeenucggtffrrghtthgv rhhnpeevudffiedvffffgffhgeefjeefffdtieetheetkeefhfdvfefgtedtueehgeffue enucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehvohhi ugesfhdqmhdrfhhm X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Thu, 10 Aug 2023 07:34:41 -0400 (EDT) Date: Thu, 10 Aug 2023 12:34:39 +0100 From: void To: freebsd-current@freebsd.org Subject: ifconfig: missing or corrupted regdomain database Message-ID: 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; format=flowed Content-Disposition: inline X-Spamd-Result: default: False [-3.60 / 15.00]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.91)[-0.910]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.25]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm3,messagingengine.com:s=fm3]; RWL_MAILSPIKE_GOOD(-0.10)[66.111.4.25:from]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.25:from]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_MEDIUM(0.01)[0.009]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_NONE(0.00)[]; FREEMAIL_FROM(0.00)[f-m.fm]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; RCVD_VIA_SMTP_AUTH(0.00)[] X-Spamd-Bar: --- X-Rspamd-Queue-Id: 4RM4b72N3Xz4tb4 Hello current@, I'm trying to set up atheros wireless on a desktop. The error in response to "ifconfig wlan0 up" is the expected info sans IP address with the added message of "ifconfig: missing or corrupted regdomain database" How can I fix this? System is amd64 built around 1020 UTC today 14.0-CURRENT amd64 1400094 #0 main-n264666 ty -- From nobody Thu Aug 10 12:14:42 2023 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 4RM5TJ57FGz4mB8p for ; Thu, 10 Aug 2023 12:14:44 +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 4RM5TH5Hwlz3F1K for ; Thu, 10 Aug 2023 12:14:43 +0000 (UTC) (envelope-from pi@freebsd.org) Authentication-Results: mx1.freebsd.org; dkim=none; spf=softfail (mx1.freebsd.org: 2001:14f8:200::1 is neither permitted nor denied by domain of pi@freebsd.org) smtp.mailfrom=pi@freebsd.org; dmarc=none Received: from pi by home.opsec.eu with local (Exim 4.95 (FreeBSD)) (envelope-from ) id 1qU4Ys-00083N-F2 for current@freebsd.org; Thu, 10 Aug 2023 14:14:42 +0200 Date: Thu, 10 Aug 2023 14:14:42 +0200 From: Kurt Jaeger To: current@freebsd.org Subject: Re: ZFS deadlock in 14 Message-ID: <20230810121442.GC11506@home.opsec.eu> References: <86leeltqcb.fsf@ltc.des.no> <20230810102733.GB11506@home.opsec.eu> 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: <20230810102733.GB11506@home.opsec.eu> X-Spamd-Result: default: False [-2.58 / 15.00]; NEURAL_HAM_LONG(-0.98)[-0.983]; NEURAL_HAM_SHORT(-0.96)[-0.961]; NEURAL_HAM_MEDIUM(-0.63)[-0.632]; MIME_GOOD(-0.10)[text/plain]; ONCE_RECEIVED(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[current@freebsd.org]; ASN(0.00)[asn:12502, ipnet:2001:14f8::/32, country:DE]; ARC_NA(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all:c]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[pi]; RCPT_COUNT_ONE(0.00)[1]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DMARC_NA(0.00)[freebsd.org]; TO_DN_NONE(0.00)[]; TO_DOM_EQ_FROM_DOM(0.00)[] X-Spamd-Bar: -- X-Rspamd-Queue-Id: 4RM5TH5Hwlz3F1K Hi! > > At some point between 42d088299c (4 May) and f0c9703301 (26 June), a > > deadlock was introduced in ZFS. It is still present as of 9c2823bae9 (4 > > August) and is 100% reproducable just by starting poudriere bulk in a > > 16-core VM and waiting a few hours until deadlkres kicks in. > > I have a amd based builder, 32 cores, run 437e1e37dfca from > Thu Jul 27 01:26:39 CEST 2023 and do not see those crashes. > > zpool get feature@block_cloning zroot > NAME PROPERTY VALUE SOURCE > zroot feature@block_cloning enabled local se@ told me about yet another tunable 8-) sysctl vfs.zfs.bclone_enabled vfs.zfs.bclone_enabled: 0 So while it's enabled in ZFS itself, it's not really active in my system. -- pi@opsec.eu +49 171 3101372 Now what ? From nobody Thu Aug 10 12:24:00 2023 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 4RM5hL05S9z4mBs9 for ; Thu, 10 Aug 2023 12:24:18 +0000 (UTC) (envelope-from george@fork.id.au) Received: from smtp.fork.id.au (smtp.fork.id.au [52.64.41.40]) (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 4RM5hG1TFSz3Ggv for ; Thu, 10 Aug 2023 12:24:14 +0000 (UTC) (envelope-from george@fork.id.au) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=fork.id.au header.s=mail header.b=EnuPPPTU; spf=pass (mx1.freebsd.org: domain of george@fork.id.au designates 52.64.41.40 as permitted sender) smtp.mailfrom=george@fork.id.au; dmarc=pass (policy=reject) header.from=fork.id.au Received: from smtp-internal.fork.id.au (unknown [127.0.0.31]) by smtp.fork.id.au (Postfix) with ESMTP id 0F98B3178E for ; Thu, 10 Aug 2023 12:24:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=fork.id.au; s=mail; t=1691670245; bh=O11uOdMVb/YtLlhlrP74tB7cVnZI7rZuq+hv4hlne7k=; h=Date:From:Subject:To; b=EnuPPPTUOzu4X+aiJXbhECz739Q1lwktV6ubfO+sbcjOHl78LejHRlDpuuxkEgOBT IZZIQCVrXfcMaPRa/QkwMa6SAhfujUGa2sDmUyUqsU1jF4JqWF1CG9om7HFkZotfY8 JHPi4oZqJKeqtlZKYh/060IBEv21QjoBiZK5sPbs= Received: from [192.168.1.22] (lfbn-mon-1-1060-205.w90-48.abo.wanadoo.fr [90.48.163.205]) (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 smtp-internal.fork.id.au (Postfix) with ESMTPSA id 6A8383172B for ; Thu, 10 Aug 2023 12:24:04 +0000 (UTC) Message-ID: <1a77457f-319a-1025-f969-3c294dcc7432@fork.id.au> Date: Thu, 10 Aug 2023 14:24:00 +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; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Content-Language: en-US From: George Abdelmalik Subject: The future for support of BeagleBone Black and its variants To: FreeBSD Current Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [-3.77 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.77)[-0.769]; DMARC_POLICY_ALLOW(-0.50)[fork.id.au,reject]; R_SPF_ALLOW(-0.20)[+ip4:52.64.41.40]; R_DKIM_ALLOW(-0.20)[fork.id.au:s=mail]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:16509, ipnet:52.64.0.0/17, country:US]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[fork.id.au:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[] X-Spamd-Bar: --- X-Rspamd-Queue-Id: 4RM5hG1TFSz3Ggv Hi all, For a long while now CURRENT has not been working on the BBB due to incompatible upstream changes in vendor DTS files. I know there are some patches available which at least get FreeBSD running but those have yet to be incorporated into the project's repository. This leaves me with the feeling that BBB support in FreeBSD is on the path to being dropped. Is there someone from the FreeBSD project that could speak directly to this? As a user it would be helpful to know if I should be searching of an alternate SBC platform or another OS for my projects. If it still remains the plan to keep supporting BBB into 14.0 and beyond then I'd like to know what work is missing to make that happen. I'm willing and able to help. Regards, George. From nobody Thu Aug 10 12:52:00 2023 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 4RM6JY24zQz4mDGK for ; Thu, 10 Aug 2023 12:52:13 +0000 (UTC) (envelope-from theraven@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 4RM6JY1j8kz3K7Y; Thu, 10 Aug 2023 12:52:13 +0000 (UTC) (envelope-from theraven@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1691671933; 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=9wRUwTffPlbuFft0DqcDQReTdxAxIYWdxBQl1FQDX5c=; b=T+PBDkEzYUCcJUBijNoguu/dOqZBWdA1azg/TMqfxtiq4fsfsbmWoUNk11KWZmvBDNzsAk Fg7KpPO2Sr7lkqzctKT1HGRjFUfcKLtMOx/ypPWjTc3wHgOhmYo8wA9JuAGE5L3psya3W6 aTgDnp61esXnYcZjgDhlfLkd+Z1ldFwdyq0/gEcssDmQSnhC7OdNkLZ72WGUqzgBqdxenf jVb7XzC8y+vChSQ9D2+st97yk1LoheG98963PlQxsqMhDWwB2ETUXBghHQalYQRyo1AuzO QdrI+xgHzYWXJbgOVaOvuf38hGgYImQsQj8QiCNm3OUKwdA8pomTCYB14GZzUQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1691671933; 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=9wRUwTffPlbuFft0DqcDQReTdxAxIYWdxBQl1FQDX5c=; b=ncXKsdrJ4yNxeN+mUNwIt95ZYZYioi7oZdiZzpUOf4Nc9qVut1rs9+jBRgspsWyN5LY7+k whQLFcaj2EMtb9UOhc2Z71g4uvaIRVeTKMyxYf2lmgo36t50faaOUbySVeSGDHUwj6GLcI 4TUGCxlIwADImA5Mltc+b1bcBXuuKHKmgnof52eah/xD0Zozg7H0zXbB3B1apft+L2PdLj EkZnRCV/cmq/0zwUM5YpdcluTFnlKI/vt7VHKN6S9NVaTfE8KXMGeMn2UbLDcxcCk0i1fa YJeWLCQw9PMQoWAVWRqlmnnw3LpisWjp76CeqAuamZiie2feL5GDTw9bvtRLBA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1691671933; a=rsa-sha256; cv=none; b=CS27RL97o55aGXGLGR8Gdjxr+xiR1qCyQamPqIu5XDs0Kko5s+jmatOb+C2txtT51W5ItI 1qZV3HPHWbPR3O0WiBz2nH5AAbZg6NviHqwZKiMU2vYemuvTagkwUuDd7bZVg0QQMLg+O/ uBHWU6In2D4yHrTQXu3JzVUVkCGeVbshoq70hQN9M/8aeFz7A/GhznoxcuytbiwVUMK250 VrLimaqLSdp5WmZTcBtPpNpH6mi0OLsF45rtZcqBfyqjOlZsUE6GonocGbiAPtPDvwsJKr xndJdpAu6ShAIqMhtI30lqys9IMRsn9QzSpW9d9zoKLFYdQpNE3TNLC+9fB2+Q== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from smtp.theravensnest.org (smtp.theravensnest.org [45.77.103.195]) (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) (Authenticated sender: theraven) by smtp.freebsd.org (Postfix) with ESMTPSA id 4RM6JY0mTwz349; Thu, 10 Aug 2023 12:52:13 +0000 (UTC) (envelope-from theraven@freebsd.org) Received: from smtpclient.apple (host86-141-212-56.range86-141.btcentralplus.com [86.141.212.56]) by smtp.theravensnest.org (Postfix) with ESMTPSA id 70EC089DA; Thu, 10 Aug 2023 13:52:12 +0100 (BST) Content-Type: multipart/alternative; boundary=Apple-Mail-714AA9CE-5F5E-4F8B-907E-06CC5AF7A157 Content-Transfer-Encoding: 7bit From: David Chisnall 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: The future for support of BeagleBone Black and its variants Date: Thu, 10 Aug 2023 13:52:00 +0100 Message-Id: References: <1a77457f-319a-1025-f969-3c294dcc7432@fork.id.au> Cc: FreeBSD Current In-Reply-To: <1a77457f-319a-1025-f969-3c294dcc7432@fork.id.au> To: George Abdelmalik X-Mailer: iPad Mail (20G75) --Apple-Mail-714AA9CE-5F5E-4F8B-907E-06CC5AF7A157 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, What are the changes to the DTS files? If there are problems with DTC handli= ng the new files, please can you raise issues here: https://github.com/david= chisnall/dtc/issues If there are problems with the kernel=E2=80=99s handling of the dtb, please i= gnore me. David > On 10 Aug 2023, at 13:24, George Abdelmalik wrote: >=20 > =EF=BB=BFHi all, >=20 > For a long while now CURRENT has not been working on the BBB due to incomp= atible upstream changes in vendor DTS files. I know there are some patches a= vailable which at least get FreeBSD running but those have yet to be incorpo= rated into the project's repository. >=20 > This leaves me with the feeling that BBB support in FreeBSD is on the path= to being dropped. Is there someone from the FreeBSD project that could spea= k directly to this? >=20 > As a user it would be helpful to know if I should be searching of an alter= nate SBC platform or another OS for my projects. >=20 > If it still remains the plan to keep supporting BBB into 14.0 and beyond t= hen I'd like to know what work is missing to make that happen. I'm willing a= nd able to help. >=20 > Regards, > George. >=20 >=20 >=20 --Apple-Mail-714AA9CE-5F5E-4F8B-907E-06CC5AF7A157 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi,=

What are the changes to th= e DTS files? If there are problems with DTC handling the new files, please c= an you raise issues here: https://github.com/davidchisnall/dtc/issues

If there are problems with the kernel=E2=80=99= s handling of the dtb, please ignore me.

David

On 10 Aug 2023, at 13:24, George Abdelmalik <george@fo= rk.id.au> wrote:

=EF=BB=BFHi all,

For a l= ong while now CURRENT has not been working on the BBB due to incompatible up= stream changes in vendor DTS files. I know there are some patches available w= hich at least get FreeBSD running but those have yet to be incorporated into= the project's repository.

This leaves me w= ith the feeling that BBB support in FreeBSD is on the path to being dropped.= Is there someone from the FreeBSD project that could speak directly to this= ?

As a user it would be helpful to know if I= should be searching of an alternate SBC platform or another OS for my proje= cts.

If it still remains the plan to keep s= upporting BBB into 14.0 and beyond then I'd like to know what work is missin= g to make that happen. I'm willing and able to help.
=
Regards,
George.

=

= --Apple-Mail-714AA9CE-5F5E-4F8B-907E-06CC5AF7A157-- From nobody Thu Aug 10 13:11:16 2023 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 4RM6kg4kg7z4mG9v for ; Thu, 10 Aug 2023 13:11:23 +0000 (UTC) (envelope-from george@fork.id.au) Received: from smtp.fork.id.au (smtp.fork.id.au [52.64.41.40]) (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 4RM6kg2ymDz3Lg4; Thu, 10 Aug 2023 13:11:23 +0000 (UTC) (envelope-from george@fork.id.au) Authentication-Results: mx1.freebsd.org; none Received: from smtp-internal.fork.id.au (unknown [127.0.0.31]) by smtp.fork.id.au (Postfix) with ESMTP id BB222317AE; Thu, 10 Aug 2023 13:11:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=fork.id.au; s=mail; t=1691673080; bh=scAztDX7y8K3V9C8RaoF29X6JgsTrfN1WOVHpvf1zn4=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=OuStokeO8sn/fLySSMBMBs+Wq0liJdoEBiPzcyjNy1BIYAbYPY5pW8NEsB+azbYlT L+ilzVqMo32QtXo9sz9le/CGbJXxIe8pp69Te49M1Al7FiPyO0vnoXnYOFboySiig7 ZMbO00YY2N8p25nanJn1SuQmqufOZAgGi5+JUc5o= Received: from [192.168.1.22] (lfbn-mon-1-1060-205.w90-48.abo.wanadoo.fr [90.48.163.205]) (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 smtp-internal.fork.id.au (Postfix) with ESMTPSA id BF0E8317AD; Thu, 10 Aug 2023 13:11:19 +0000 (UTC) Message-ID: <95f063b3-e122-cfa8-f9fd-9ca2365d663e@fork.id.au> Date: Thu, 10 Aug 2023 15:11:16 +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; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: The future for support of BeagleBone Black and its variants Content-Language: en-US To: David Chisnall Cc: FreeBSD Current References: <1a77457f-319a-1025-f969-3c294dcc7432@fork.id.au> From: George Abdelmalik In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4RM6kg2ymDz3Lg4 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:52.64.0.0/17, country:US] Hi David, The problems are kernel related. If I understand correctly it's in the area of clock definitions I think but I've not properly studied the patches. DTC is good. Regards, George. On 10/8/23 14:52, David Chisnall wrote: > Hi, > > What are the changes to the DTS files? If there are problems with DTC > handling the new files, please can you raise issues here: > https://github.com/davidchisnall/dtc/issues > > If there are problems with the kernel’s handling of the dtb, please > ignore me. > > David > >> On 10 Aug 2023, at 13:24, George Abdelmalik wrote: >> >> Hi all, >> >> For a long while now CURRENT has not been working on the BBB due to >> incompatible upstream changes in vendor DTS files. I know there are >> some patches available which at least get FreeBSD running but those >> have yet to be incorporated into the project's repository. >> >> This leaves me with the feeling that BBB support in FreeBSD is on the >> path to being dropped. Is there someone from the FreeBSD project that >> could speak directly to this? >> >> As a user it would be helpful to know if I should be searching of an >> alternate SBC platform or another OS for my projects. >> >> If it still remains the plan to keep supporting BBB into 14.0 and >> beyond then I'd like to know what work is missing to make that >> happen. I'm willing and able to help. >> >> Regards, >> George. >> >> >> From nobody Thu Aug 10 13:37:45 2023 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 4RM7KN4lkLz4mHWv for ; Thu, 10 Aug 2023 13:38:00 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta001.cacentral1.a.cloudfilter.net (omta001.cacentral1.a.cloudfilter.net [3.97.99.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RM7KN2MW8z3QDd; Thu, 10 Aug 2023 13:38:00 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; none Received: from shw-obgw-4004a.ext.cloudfilter.net ([10.228.9.227]) by cmsmtp with ESMTP id U4kDqzamILAoIU5rTqRBNG; Thu, 10 Aug 2023 13:37:59 +0000 Received: from spqr.komquats.com ([70.66.152.170]) by cmsmtp with ESMTPA id U5rQqhRT93fOSU5rSqpAm3; Thu, 10 Aug 2023 13:37:59 +0000 X-Authority-Analysis: v=2.4 cv=J8G5USrS c=1 sm=1 tr=0 ts=64d4e837 a=y8EK/9tc/U6QY+pUhnbtgQ==:117 a=y8EK/9tc/U6QY+pUhnbtgQ==:17 a=kj9zAlcOel0A:10 a=UttIx32zK-AA:10 a=NEAV23lmAAAA:8 a=SLG1KRGDAAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=_rsKTvRLQdO93uMEaR8A:9 a=CjuIK1q_8ugA:10 a=-TBaU1e9WpdkKBzYXnwo:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id 966118DD; Thu, 10 Aug 2023 06:37:50 -0700 (PDT) Received: by slippy.cwsent.com (Postfix, from userid 1000) id D0EC0178; Thu, 10 Aug 2023 06:37:45 -0700 (PDT) X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.8+dev Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Kevin Bowling cc: =?UTF-8?Q?Dag=2DErling_Sm=C3=B8rgrav?= , current@freebsd.org Subject: Re: ZFS deadlock in 14 In-reply-to: References: <86leeltqcb.fsf@ltc.des.no> Comments: In-reply-to Kevin Bowling message dated "Wed, 09 Aug 2023 20:33:40 -0700." 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 Date: Thu, 10 Aug 2023 06:37:45 -0700 Message-Id: <20230810133745.D0EC0178@slippy.cwsent.com> X-CMAE-Envelope: MS4xfPhlnOFhmSwysu1OIbouFG4xNsb6UTkI1ivVdZ13hOLF1B0IaCWrm8O6CrHRmR/xKQs9RjpDegRtUN8agYTs2q9hoyFCScm7IcnCl7zJrSovvlgIl42o 0meVif3D4Ld6onC4YCkilG74usitKAKfbNgSMBKhhW9pdLa4cuoxPzx40OSkAJOFkJg9RVxFWkdQzknkMTcOCqCJ5Afs7RcqoQTXGT3Yyvq6cEWY/33hJ3Nt 0rjDUUQxmJF4JEJD6eCWJckynYUkdWKNvnN/YJ+Ru3w= X-Rspamd-Queue-Id: 4RM7KN2MW8z3QDd X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US] In message , Kevin Bowling writes: > Possibly https://github.com/openzfs/zfs/commit/2cb992a99ccadb78d97049b40bd4= > 42eb4fdc549d > > On Tue, Aug 8, 2023 at 10:08=E2=80=AFAM Dag-Erling Sm=C3=B8rgrav sd.org> wrote: > > > > At some point between 42d088299c (4 May) and f0c9703301 (26 June), a > > deadlock was introduced in ZFS. It is still present as of 9c2823bae9 (4 > > August) and is 100% reproducable just by starting poudriere bulk in a > > 16-core VM and waiting a few hours until deadlkres kicks in. In the > > latest instance, deadlkres complained about a bash process: > > > > #0 sched_switch (td=3Dtd@entry=3D0xfffffe02fb1d8000, flags=3Dflags@e= > ntry=3D259) at /usr/src/sys/kern/sched_ule.c:2299 > > #1 0xffffffff80b5a0a3 in mi_switch (flags=3Dflags@entry=3D259) at /u= > sr/src/sys/kern/kern_synch.c:550 > > #2 0xffffffff80babcb4 in sleepq_switch (wchan=3D0xfffff818543a9e70, = > pri=3D64) at /usr/src/sys/kern/subr_sleepqueue.c:609 > > #3 0xffffffff80babb8c in sleepq_wait (wchan=3D, pri=3D<= > unavailable>) at /usr/src/sys/kern/subr_sleepqueue.c:660 > > #4 0xffffffff80b1c1b0 in sleeplk (lk=3Dlk@entry=3D0xfffff818543a9e70= > , flags=3Dflags@entry=3D2121728, ilk=3Dilk@entry=3D0x0, wmesg=3Dwmesg@entry= > =3D0xffffffff8222a054 "zfs", pri=3D, pri@entry=3D64, timo=3D= > timo@entry=3D6, queue=3D1) at /usr/src/sys/kern/kern_lock.c:310 > > #5 0xffffffff80b1a23f in lockmgr_slock_hard (lk=3D0xfffff818543a9e70= > , flags=3D2121728, ilk=3D, file=3D0xffffffff812544fb "/usr/s= > rc/sys/kern/vfs_subr.c", line=3D3057, lwa=3D0x0) at /usr/src/sys/kern/kern_= > lock.c:705 > > #6 0xffffffff80c59ec3 in VOP_LOCK1 (vp=3D0xfffff818543a9e00, flags= > =3D2105344, file=3D0xffffffff812544fb "/usr/src/sys/kern/vfs_subr.c", line= > =3D3057) at ./vnode_if.h:1120 > > #7 _vn_lock (vp=3Dvp@entry=3D0xfffff818543a9e00, flags=3D2105344, fi= > le=3D, line=3D, line@entry=3D3057) at /usr/src/sy= > s/kern/vfs_vnops.c:1815 > > #8 0xffffffff80c4173d in vget_finish (vp=3D0xfffff818543a9e00, flags= > =3D, vs=3Dvs@entry=3DVGET_USECOUNT) at /usr/src/sys/kern/vfs_s= > ubr.c:3057 > > #9 0xffffffff80c1c9b7 in cache_lookup (dvp=3Ddvp@entry=3D0xfffff802c= > d02ac40, vpp=3Dvpp@entry=3D0xfffffe046b20ac30, cnp=3Dcnp@entry=3D0xfffffe04= > 6b20ac58, tsp=3Dtsp@entry=3D0x0, ticksp=3Dticksp@entry=3D0x0) at /usr/src/s= > ys/kern/vfs_cache.c:2086 > > #10 0xffffffff80c2150c in vfs_cache_lookup (ap=3D) at = > /usr/src/sys/kern/vfs_cache.c:3068 > > #11 0xffffffff80c32c37 in VOP_LOOKUP (dvp=3D0xfffff802cd02ac40, vpp= > =3D0xfffffe046b20ac30, cnp=3D0xfffffe046b20ac58) at ./vnode_if.h:69 > > #12 vfs_lookup (ndp=3Dndp@entry=3D0xfffffe046b20abd8) at /usr/src/sys= > /kern/vfs_lookup.c:1266 > > #13 0xffffffff80c31ce1 in namei (ndp=3Dndp@entry=3D0xfffffe046b20abd8= > ) at /usr/src/sys/kern/vfs_lookup.c:689 > > #14 0xffffffff80c52090 in kern_statat (td=3D0xfffffe02fb1d8000, flag= > =3D, fd=3D-100, path=3D0xa75b480e070 emory at address 0xa75b480e070>, pathseg=3Dpathseg@entry=3DUIO_USERSPACE, s= > bp=3Dsbp@entry=3D0xfffffe046b20ad18) > > at /usr/src/sys/kern/vfs_syscalls.c:2441 > > #15 0xffffffff80c52797 in sys_fstatat (td=3D, uap=3D0xff= > fffe02fb1d8400) at /usr/src/sys/kern/vfs_syscalls.c:2419 > > #16 0xffffffff81049398 in syscallenter (td=3D) at /usr= > /src/sys/amd64/amd64/../../kern/subr_syscall.c:190 > > #17 amd64_syscall (td=3D0xfffffe02fb1d8000, traced=3D0) at /usr/src/s= > ys/amd64/amd64/trap.c:1199 > > #18 > > > > The lock it is trying to acquire in frame 5 belongs to another bash > > process which is in the process of creating a fifo: > > > > #0 sched_switch (td=3Dtd@entry=3D0xfffffe046acd8e40, flags=3Dflags@e= > ntry=3D259) at /usr/src/sys/kern/sched_ule.c:2299 > > #1 0xffffffff80b5a0a3 in mi_switch (flags=3Dflags@entry=3D259) at /u= > sr/src/sys/kern/kern_synch.c:550 > > #2 0xffffffff80babcb4 in sleepq_switch (wchan=3D0xfffff8018acbf154, = > pri=3D87) at /usr/src/sys/kern/subr_sleepqueue.c:609 > > #3 0xffffffff80babb8c in sleepq_wait (wchan=3D, pri=3D<= > unavailable>) at /usr/src/sys/kern/subr_sleepqueue.c:660 > > #4 0xffffffff80b59606 in _sleep (ident=3Dident@entry=3D0xfffff8018ac= > bf154, lock=3Dlock@entry=3D0xfffff8018acbf120, priority=3Dpriority@entry=3D= > 87, wmesg=3D0xffffffff8223af0e "zfs teardown inactive", sbt=3Dsbt@entry=3D0= > , pr=3Dpr@entry=3D0, flags=3D256) > > at /usr/src/sys/kern/kern_synch.c:225 > > #5 0xffffffff80b45dc0 in rms_rlock_fallback (rms=3D0xfffff8018acbf12= > 0) at /usr/src/sys/kern/kern_rmlock.c:1015 > > #6 0xffffffff80b45c93 in rms_rlock (rms=3D, rms@entry= > =3D0xfffff8018acbf120) at /usr/src/sys/kern/kern_rmlock.c:1036 > > #7 0xffffffff81fb147b in zfs_freebsd_reclaim (ap=3D) = > at /usr/src/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vnops_os.c:5164 > > #8 0xffffffff8111d245 in VOP_RECLAIM_APV (vop=3D0xffffffff822e71a0 <= > zfs_vnodeops>, a=3Da@entry=3D0xfffffe0410f1c9c8) at vnode_if.c:2180 > > #9 0xffffffff80c43569 in VOP_RECLAIM (vp=3D0xfffff802cdbaca80) at ./= > vnode_if.h:1084 > > #10 vgonel (vp=3Dvp@entry=3D0xfffff802cdbaca80) at /usr/src/sys/kern/= > vfs_subr.c:4143 > > #11 0xffffffff80c3ef61 in vtryrecycle (vp=3D0xfffff802cdbaca80) at /u= > sr/src/sys/kern/vfs_subr.c:1693 > > #12 vnlru_free_impl (count=3Dcount@entry=3D1, mnt_op=3Dmnt_op@entry= > =3D0x0, mvp=3D0xfffff8010864da00) at /usr/src/sys/kern/vfs_subr.c:1344 > > #13 0xffffffff80c49553 in vnlru_free_locked (count=3D1) at /usr/src/s= > ys/kern/vfs_subr.c:1357 > > #14 vn_alloc_hard (mp=3Dmp@entry=3D0x0) at /usr/src/sys/kern/vfs_subr= > .c:1744 > > #15 0xffffffff80c3f6f0 in vn_alloc (mp=3D0x0) at /usr/src/sys/amd64/i= > nclude/atomic.h:375 > > #16 getnewvnode_reserve () at /usr/src/sys/kern/vfs_subr.c:1888 > > #17 0xffffffff81faa072 in zfs_create (dzp=3D0xfffff812200261d0, name= > =3D0xfffff8011b8ac805 "sh-np.yPbxoo", vap=3D0xfffffe0410f1cc20, excl=3D imized out>, mode=3D, zpp=3Dzpp@entry=3D0xfffffe0410f1cbc8, = > cr=3D0xfffff80140fb1100, flag=3D, vsecp=3D0x0, mnt_ns=3D0x0) > > at /usr/src/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vnops_o= > s.c:1146 > > #18 0xffffffff81faea57 in zfs_freebsd_create (ap=3D0xfffffe0410f1cda0= > ) at /usr/src/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vnops_os.c:4618 > > #19 0xffffffff8111aa9a in VOP_MKNOD_APV (vop=3D0xffffffff822e71a0 s_vnodeops>, a=3Da@entry=3D0xfffffe0410f1cda0) at vnode_if.c:372 > > #20 0xffffffff80c50207 in VOP_MKNOD (dvp=3D, cnp=3D0xfff= > ffe0410f1cd50, vap=3D0xfffffe0410f1cc20, vpp=3D) at ./vnode_= > if.h:188 > > #21 kern_mkfifoat (td=3D0xfffffe046acd8e40, fd=3D-100, path=3D0x12772= > f073500 , pathseg=3D= > UIO_USERSPACE, mode=3D) at /usr/src/sys/kern/vfs_syscalls.c:= > 1492 > > #22 0xffffffff81049398 in syscallenter (td=3D) at /usr= > /src/sys/amd64/amd64/../../kern/subr_syscall.c:190 > > #23 amd64_> ys/amd64/amd64/trap.c:1199 > > #24 > > > > Frame 7 is trying to acquire the ZFS teardown inactive lock, which is > > held by a process which is performing a ZFS rollback and is waiting for > > the transaction to sync: > > > > #0 sched_switch (td=3Dtd@entry=3D0xfffffe0422ef8560, flags=3Dflags@e= > ntry=3D259) at /usr/src/sys/kern/sched_ule.c:2299 > > #1 0xffffffff80b5a0a3 in mi_switch (flags=3Dflags@entry=3D259) at /u= > sr/src/sys/kern/kern_synch.c:550 > > #2 0xffffffff80babcb4 in sleepq_switch (wchan=3D0xfffff8011b83d540, = > pri=3D0) at /usr/src/sys/kern/subr_sleepqueue.c:609 > > #3 0xffffffff80babb8c in sleepq_wait (wchan=3D, wchan@e= > ntry=3D0xfffff8011b83d540, pri=3D, pri@entry=3D0) at /usr/src/= > sys/kern/subr_sleepqueue.c:660 > > #4 0xffffffff80ad7f75 in _cv_wait (cvp=3Dcvp@entry=3D0xfffff8011b83d= > 540, lock=3Dlock@entry=3D0xfffff8011b83d4d0) at /usr/src/sys/kern/kern_cond= > var.c:146 > > #5 0xffffffff820b42fb in txg_wait_synced_impl (dp=3Ddp@entry=3D0xfff= > ff8011b83d000, txg=3D8585097, wait_sig=3Dwait_sig@entry=3D0) at /usr/src/sy= > s/contrib/openzfs/module/zfs/txg.c:726 > > #6 0xffffffff820b3cab in txg_wait_synced (dp=3D, dp@ent= > ry=3D0xfffff8011b83d000, txg=3D) at /usr/src/sys/contrib/openz= > fs/module/zfs/txg.c:736 > > #7 0xffffffff8206d5b5 in dsl_sync_task_common (pool=3Dpool@entry=3D0= > xfffffe0401d15000 "zroot/poudriere/jails/13amd64-default-ref/15", checkfunc= > =3D, syncfunc=3D0xffffffff8203fbc0 c>, sigfunc=3Dsigfunc@entry=3D0x0, arg=3Darg@entry=3D0xfffffe02fb827a90, > > blocks_modified=3Dblocks_modified@entry=3D1, space_check=3DZFS_SP= > ACE_CHECK_RESERVED, early=3D0) at /usr/src/sys/contrib/openzfs/module/zfs/d= > sl_synctask.c:93 > > #8 0xffffffff8206d3c7 in dsl_sync_task (pool=3D, pool@e= > ntry=3D0xfffffe0401d15000 "zroot/poudriere/jails/13amd64-default-ref/15", c= > heckfunc=3D, syncfunc=3D, arg=3D, ar= > g@entry=3D0xfffffe02fb827a90, blocks_modified=3D, > > blocks_modified@entry=3D1, space_check=3D, space_che= > ck@entry=3DZFS_SPACE_CHECK_RESERVED) at /usr/src/sys/contrib/openzfs/module= > /zfs/dsl_synctask.c:132 > > #9 0xffffffff8204075b in dsl_dataset_rollback (fsname=3D >, fsname@entry=3D0xfffffe0401d15000 "zroot/poudriere/jails/13amd64-default= > -ref/15", tosnap=3D, owner=3D, result=3Dresul= > t@entry=3D0xfffff81c826a9ea0) > > at /usr/src/sys/contrib/openzfs/module/zfs/dsl_dataset.c:3261 > > #10 0xffffffff82168dd9 in zfs_ioc_rollback (fsname=3D0xfffffe0401d150= > 00 "zroot/poudriere/jails/13amd64-default-ref/15", fsname@entry=3D ading variable: value is not available>, innvl=3D, innvl@entry= > =3D, > > outnvl=3D0xfffff81c826a9ea0, outnvl@entry=3D le: value is not available>) at /usr/src/sys/contrib/openzfs/module/zfs/zfs= > _ioctl.c:4405 > > #11 0xffffffff82164522 in zfsdev_ioctl_common (vecnum=3Dvecnum@entry= > =3D25, zc=3Dzc@entry=3D0xfffffe0401d15000, flag=3Dflag@entry=3D0) at /usr/s= > rc/sys/contrib/openzfs/module/zfs/zfs_ioctl.c:7798 > > #12 0xffffffff81f97fca in zfsdev_ioctl (dev=3D, zcmd= > =3D, zcmd@entry=3D ble>, arg=3D0xfffffe02fb827d50 "\017", arg@entry=3D value is not available>, flag=3D, td=3D) > > at /usr/src/sys/contrib/openzfs/module/os/freebsd/zfs/kmod_core.c= > :168 > > #13 0xffffffff809d6212 in devfs_ioctl (ap=3D0xfffffe02fb827c50) at /u= > sr/src/sys/fs/devfs/devfs_vnops.c:935 > > #14 0xffffffff80c585f2 in vn_ioctl (fp=3D0xfffff8052cdd80f0, com=3D ptimized out>, data=3D0xfffffe02fb827d50, active_cred=3D0xfffff80122ab1e00,= > td=3D) at /usr/src/sys/kern/vfs_vnops.c:1704 > > #15 0xffffffff809d68ee in devfs_ioctl_f (fp=3D, fp@entry= > =3D, com=3D, c= > om@entry=3D, data=3D lable>, data@entry=3D, > > cred=3D, cred@entry=3D is not available>, td=3D, td@entry=3D value is not available>) at /usr/src/sys/fs/devfs/devfs_vnops.c:866 > > #16 0xffffffff80bc57e6 in fo_ioctl (fp=3D0xfffff8052cdd80f0, com=3D32= > 22821401, data=3D, active_cred=3D, td=3D0xfffffe0= > 422ef8560) at /usr/src/sys/sys/file.h:367 > > #17 kern_ioctl (td=3Dtd@entry=3D0xfffffe0422ef8560, fd=3D4, com=3Dcom= > @entry=3D3222821401, data=3D, data@entry=3D0xfffffe02fb827d50 = > "\017") at /usr/src/sys/kern/sys_generic.c:807 > > #18 0xffffffff80bc54f2 in sys_ioctl (td=3D0xfffffe0422ef8560, uap=3D0= > xfffffe0422ef8960) at /usr/src/sys/kern/sys_generic.c:715 > > #19 0xffffffff81049398 in syscallenter (td=3D) at /usr= > /src/sys/amd64/amd64/../../kern/subr_syscall.c:190 > > #20 amd64_syscall (td=3D0xfffffe0422ef8560, traced=3D0) at /usr/src/s= > ys/amd64/amd64/trap.c:1199 [...] The backtrace looks different though it certainly smells like PR/271945. I've had similar to PR/271945 panics on an amd64 with a mirrored zpool with four vdevs running poudriere with AMD64 jails. My other amd64 with a mirrored zpool with two vdevs using i386 jails has no such issue. All other workloads are unaffected. On the affected machine running poudriere bulk with -J N:1 circumvents the issue. So far. There were two openzfs cherry-picks this morning. I intend to try them against a full bulk build later today. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=0 From nobody Thu Aug 10 14:08:26 2023 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 4RM80Y0rb3z4mKBy for ; Thu, 10 Aug 2023 14:08:29 +0000 (UTC) (envelope-from des@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 4RM80Y0MfJz3Tmv; Thu, 10 Aug 2023 14:08:29 +0000 (UTC) (envelope-from des@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1691676509; 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=Qk+7uPCHc3jt3RNJIh3h9DEgz1MS6mXD67njYjut0k8=; b=YSZGvsg1kLZAs6Y7ptu2O54KFAPBctTC8DWBF1IH3ThNomdiHz/ZDYAywNSNHZET6YQdA4 SHA1lmMMOzfQSnqt9Ucchw4A09o6osieyyBNwxM/kWcDMeS1wG/+76b3ZtHrVMrFOlw6zg riI6mvj5lZEEePQ35X/hX4ZnDyaKCysdfu+tfX3cZvReFPUOxU7DpakiaZeK52yxCzHXcH TYmi82us1jkoZjn6+wq8plrperUI11PXlQnbqZNQrP8rUT57FAP6VpO4Dyyt8UKKYK+ade XWK3ze96hGOr5HbImZtBIN5fY7Fh8nVyFxgK5BYMkcnoyISmyv+1LmIqoAr0Fw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1691676509; 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=Qk+7uPCHc3jt3RNJIh3h9DEgz1MS6mXD67njYjut0k8=; b=N7QDN93q9fo5EzKVQrSdtRTCYICWOK+seDkBr/x+kzECyJ8nL76r7c8ZGoIuEP4yRzb+BS 31iQPddxelkMIroh3WE46O5NWaSaDWuBO/eBPj2NtZVR5ZRoB5wEY3a3wSXwZhOrcuo17B 8weqqlbXsO1OSzwiEYPiLQYt1tiwx3AE0Ri235VM6m/5pHqosPJuugaX7Hpqc+bGmBW0WT 5Ea/QjRt/WVs3nwuoAkQW9NzTn+ATxCWWCNQeCNHt4OkUUfPkr+hzfmtf/VTeDlsKgUhIs gGMAbloUEt91OBmMPwPTcy4p8q7HsNWNFb/veve+BylhI84+HknSoorvFBUbWg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1691676509; a=rsa-sha256; cv=none; b=abWpMhxExVesFfagDVU9gFvy2GZeXT2Br5cgbRCm8kesoq+EuTlCI4MdPF3U2vMai7Qurq DCfUsQdlpAXJiW41NSBkuhsT7dvWUIHDb0JaNyplqzaSumLQFPxR9D1OomNr2f/rr0TLDt Cr8Ew9BrreiAxbgz+Y5hJFsBhDIPNiTrm4Mj0xkVV10v0orv4wKUFPriIgo8cWgtiYYKCW msSx19zKXosY2WJ2llaQU2Gvvyf/ijkf/h469l42dUDN+KGi5mSN1yD3bO+6tk1VIUUOiN pTjiaD6Z2A9np4VPANz1XIjAGXk4jz6gPSdH5/XUMfdzuPixTE2+niRDbW7v6A== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from ltc.des.no (unknown [IPv6:2001:4647:d671:0:36e8:94ff:feca:9834]) (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) (Authenticated sender: des) by smtp.freebsd.org (Postfix) with ESMTPSA id 4RM80X5pyFz3j4; Thu, 10 Aug 2023 14:08:28 +0000 (UTC) (envelope-from des@freebsd.org) Received: by ltc.des.no (Postfix, from userid 1001) id 88D591848F; Thu, 10 Aug 2023 16:08:26 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Tomoaki AOKI Cc: David Wolfskill , freebsd-current@freebsd.org Subject: Re: Has the update procedure changed? In-Reply-To: <20230810063214.1b694140e7c284e51154fe35@dec.sakura.ne.jp> (Tomoaki AOKI's message of "Thu, 10 Aug 2023 06:32:14 +0900") References: <7A0E604D-EF40-4F10-B597-F1F076507192@gmail.com> <20230809213822.950a3c337ec86c102dcbd235@dec.sakura.ne.jp> <20230810063214.1b694140e7c284e51154fe35@dec.sakura.ne.jp> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (berkeley-unix) Date: Thu, 10 Aug 2023 16:08:26 +0200 Message-ID: <86zg2zrnvp.fsf@ltc.des.no> 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=utf-8 Content-Transfer-Encoding: quoted-printable Tomoaki AOKI writes: > Yes. But if bsdinstall and freebsd-update automatically bootstrap > etcupdate if not yet done, newbies and casual users wouldn't be bitten. https://cgit.freebsd.org/src/commit/?id=3De9120a256075543376496fbd75949eed1= f13a887 DES --=20 Dag-Erling Sm=C3=B8rgrav - des@FreeBSD.org From nobody Thu Aug 10 20:46:56 2023 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 4RMJrP0K3Kz4q4Mt for ; Thu, 10 Aug 2023 20:47:01 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) (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 4RMJrN4rtqz4g85; Thu, 10 Aug 2023 20:47:00 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x102b.google.com with SMTP id 98e67ed59e1d1-26837895fbbso915145a91.3; Thu, 10 Aug 2023 13:47:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691700419; x=1692305219; h=to:references:message-id:cc:date:in-reply-to:from:subject :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ZpYeHuPgHCUecKemimri+cfioCtVjEHCc7mUg5khpDA=; b=IqhpyaZKNN2qa3fnhABuhSzAZecQbA/0qDhu1bESddJ+DAmi/Nr3cjv86kNXTzudrE HmbVSCT0/CGrkdRdeU1W+zopPucOx6/isKOmvrVKx9lv8fjY5AFE0OX4ED7YqleD5T85 pbICPkhM5AtmGdLB93zmgOJHXoQupymov+oWX8A/6lSVxA25j2ZfcYPcyWTXw8ohPfh+ jVJ9iLYymKclpZGjxUA4QEWqh+lXUm6TFwuwgMzo/eRh1+uqTedhbe9ZNBaNVMgbcd2J 8InUFqwkziS748K4HUH2FIcIjpTx35G/XBu4PDfyM4Ru2VpMY4drnbQClha1G9qkwX1T dtuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691700419; x=1692305219; h=to:references:message-id:cc:date:in-reply-to:from:subject :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ZpYeHuPgHCUecKemimri+cfioCtVjEHCc7mUg5khpDA=; b=Fub/+/fy2ErP3RTwh6Qa7xpq+Camrv110lL6M4e+q5AFpTz8blkTjRhHi3OZvEKAQ9 KFPRC5JmwhTEPd8AKevTM94y7TifnwXpJHfic6naPG3we7heMo7XDgfqko/0U57sJb7U rdp1x7hNm63ux+h9OGg8MUv8/8EBt96kj+4cDxkh90CN6FD9fBGRMjlOWQwQqVhW6J7X tYAJle0lkdEkg8UTP7z/SIrZSpUyV+drlq0RSv27ovf9zD+epSIVwZr/qDPd+6RHCNNq /jJZWE2W3N2AC0vJ7F6bg1qqKRv07a5fRSKg0RltDCXenZkeEDnCOOCaaaKFyYgOTMSe 9J2w== X-Gm-Message-State: AOJu0YzsLdPIwfoRbS8Pjtv9Yv+Q4Sj4/b9SWtCDgjvqP1yboc3gVvMQ HlHQJjBKsT0w5GDbz18xDi5VqF2KoLw= X-Google-Smtp-Source: AGHT+IHEyMlWMqQo8lrIa1Dbf3izkcqIwEAHY7iyNDYgdbemUhCD1OOoaEFuiwyS8S1Jr66llpIn2g== X-Received: by 2002:a17:90a:7bc4:b0:269:85d:2aef with SMTP id d4-20020a17090a7bc400b00269085d2aefmr3328359pjl.20.1691700418965; Thu, 10 Aug 2023 13:46:58 -0700 (PDT) Received: from smtpclient.apple (c-73-19-52-228.hsd1.wa.comcast.net. [73.19.52.228]) by smtp.gmail.com with ESMTPSA id 28-20020a17090a019c00b002636dfcc6f5sm2051662pjc.3.2023.08.10.13.46.57 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 Aug 2023 13:46:58 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_59BF3901-92F9-4E29-8D2B-5FA4C0CF7031"; protocol="application/pgp-signature"; micalg=pgp-sha256 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 16.0 \(3696.120.41.1.4\)) Subject: Re: port lang/python27 does not build in 14.0-CURRENT w/ poudriere From: Enji Cooper In-Reply-To: Date: Thu, 10 Aug 2023 13:46:56 -0700 Cc: Moin Rahman , freebsd-current@freebsd.org Message-Id: <5E811C16-5D72-44EC-A14B-06BB9FADB793@gmail.com> References: <414B922C-C553-41D4-B519-E3B3B239B606@freebsd.org> <9A29A1BA-F957-40D9-96C6-062471BA14AF@freebsd.org> To: Matthias Apitz X-Mailer: Apple Mail (2.3696.120.41.1.4) X-Rspamd-Queue-Id: 4RMJrN4rtqz4g85 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] --Apple-Mail=_59BF3901-92F9-4E29-8D2B-5FA4C0CF7031 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 10, 2023, at 2:38 AM, Matthias Apitz wrote: >=20 > El d=C3=ADa Wednesday, August 09, 2023 a las 06:04:16PM +0200, Moin = Rahman escribi=C3=B3: >=20 >> This perfectly builds on the latest HEAD without any problem as = shared in my build log. I am not sure what is wrong at your end. Neither = can I see any fallout on the clusters. >=20 > I've cc'ed freebsd-current@ >=20 > I did two times the building of lang/python27 within poudriere on > 14.0-CURRENT: >=20 > =3D>> Building lang/python27 > build started at Tue Aug 8 04:05:20 CEST 2023 > port directory: /usr/ports/lang/python27=3D>> Building lang/python27 >=20 > =3D>> Building lang/python27 > build started at Thu Aug 10 06:33:53 CEST 2023 > port directory: /usr/ports/lang/python27 >=20 > The first failed, the one of today went fine. The main difference in = the > building log is: >=20 > failing job: > --MAKE_ENV-- > OPENSSLBASE=3D/usr/local OPENSSLDIR=3D/usr/local/openssl = OPENSSLINC=3D/usr/local/include OPENSSLLIB=3D/usr/local/lib = OPENSSLRPATH=3D/usr/local/lib >=20 > fine job: > --MAKE_ENV-- > OPENSSLBASE=3D/usr OPENSSLDIR=3D/etc/ssl OPENSSLINC=3D/usr/include = OPENSSLLIB=3D/usr/lib > ... >=20 > I didn't changed anything in the poudriere config or port's options. = The > only thing I did between was yesterday evening a 'git pull' in > /usr/ports. >=20 > What could have triggered this change of the used SSL version? 1. lang/python27 is no longer supported upstream. 2. lang/python27=E2=80=99s modules and compatible third-party packages = won=E2=80=99t work with OpenSSL 3; they depend on OpenSSL 1.x specific = symbols/APIs. If you want to make lang/python27 work with OpenSSL 3, you=E2=80=99re = going to port the modules to OpenSSL 3 My question is: why are you doing this, given that it=E2=80=99s no = longer receiving upstream updates (functional or security)? Cheers, -Enji PS IIRC, there were lang/python27 forks out there that might be used as = inspiration for the OpenSSL 3 uplift, but again=E2=80=A6 I don=E2=80=99t = understand why effort is being spent making the two (Python 2 and = OpenSSL 3) work. --Apple-Mail=_59BF3901-92F9-4E29-8D2B-5FA4C0CF7031 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----- iQIzBAEBCAAdFiEEtvtxN6kOllEF3nmX5JFNMZeDGN4FAmTVTMAACgkQ5JFNMZeD GN7yxg//Qhf2aj7SLq/drYfgM6Z3BecSVpv0oLlHYTwLJJ5nuyuIObi+lcG+e1zr QY9v/2jc6PMjpsC2uKGI2oDgmBWGvmvEnoR8zWUinVksZzEP82Ln0JyBH/M9faCC 5NjNyuhh1/fnreFPIeuzoEeJ0Te1Nnwuoyo/2MRTsfWQ7rMXRjFt34RknI/QFlS1 RzJUyvGxe0wcN2yOGTme3ubPSzIkS8nLfSFaJhZ1T6gPbjn/dZGCNaE56SaumvDH +SAdc/i8tqkHH84uZgp7wb6rwfbWv0vN4gtUA/4xpuooh3lVCImH3SeeCIhdmN8n gNmOLjEcyTLJ2u7O6Ecv89r11zXvze9Mbdh2XJVMW2niKlySUJZsM4AoxQZyD4o/ 4fx0Aux9l9eF5vP5Xw0nj0p0Z29QG97hFnVS9nTOZX5Y5NNmHTMLL22u0eI4Tkwc QQQMPTmmxp69oMfrQO+QqeKyLc/vJJklLCBJ2LJKF4j2IUHjKYFVTY3zF7yfktL0 lOX/vNTyHwyt/7sBQLDA5CtR4xaJywhgVw2HXpQ/MpYL5Fe0Q90iHkjCnNgF37BF UW7qppapAsLWLlMDfnN7XvrDwPwwNBYGWUSXDWx2Pj91C+TQhIL1/i0HocKgvIDq AkTWe8lCxiC8Ox/uyCADLjSTRtwqzzqrmPgN5e87zG5rPn7Cfss= =u9hv -----END PGP SIGNATURE----- --Apple-Mail=_59BF3901-92F9-4E29-8D2B-5FA4C0CF7031-- From nobody Thu Aug 10 21:56:20 2023 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 4RMLNS5Mfjz4q8SK for ; Thu, 10 Aug 2023 21:56:24 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (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 4RMLNS3ggcz3JQT; Thu, 10 Aug 2023 21:56:24 +0000 (UTC) (envelope-from guru@unixarea.de) Authentication-Results: mx1.freebsd.org; none Received: from [188.174.49.81] (helo=localhost.unixarea.de) by ms-10.1blu.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qUDdl-0008JD-Ew; Thu, 10 Aug 2023 23:56:21 +0200 Received: from localhost.my.domain (localhost [127.0.0.1]) by localhost.unixarea.de (8.16.1/8.14.9) with ESMTPS id 37ALuKww020239 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 10 Aug 2023 23:56:20 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.16.1/8.14.9/Submit) id 37ALuKZI020238; Thu, 10 Aug 2023 23:56:20 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Thu, 10 Aug 2023 23:56:20 +0200 From: Matthias Apitz To: Enji Cooper Cc: Moin Rahman , freebsd-current@freebsd.org Subject: Re: port lang/python27 does not build in 14.0-CURRENT w/ poudriere Message-ID: Reply-To: Matthias Apitz Mail-Followup-To: Enji Cooper , Moin Rahman , freebsd-current@freebsd.org References: <414B922C-C553-41D4-B519-E3B3B239B606@freebsd.org> <9A29A1BA-F957-40D9-96C6-062471BA14AF@freebsd.org> <5E811C16-5D72-44EC-A14B-06BB9FADB793@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: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5E811C16-5D72-44EC-A14B-06BB9FADB793@gmail.com> X-Operating-System: FreeBSD 13.0-CURRENT r368166 (amd64) X-message-flag: Mails containing HTML will not be read! Please send only plain text. X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 188.174.49.81 X-Rspamd-Queue-Id: 4RMLNS3ggcz3JQT X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:42730, ipnet:178.254.0.0/19, country:DE] El día jueves, agosto 10, 2023 a las 01:46:56p. m. -0700, Enji Cooper escribió: > > > On Aug 10, 2023, at 2:38 AM, Matthias Apitz wrote: > > > > El día Wednesday, August 09, 2023 a las 06:04:16PM +0200, Moin Rahman escribió: > > > >> This perfectly builds on the latest HEAD without any problem as shared in my build log. I am not sure what is wrong at your end. Neither can I see any fallout on the clusters. > > > > I've cc'ed freebsd-current@ > > > > I did two times the building of lang/python27 within poudriere on > > 14.0-CURRENT: > > > > =>> Building lang/python27 > > build started at Tue Aug 8 04:05:20 CEST 2023 > > port directory: /usr/ports/lang/python27=>> Building lang/python27 > > > > =>> Building lang/python27 > > build started at Thu Aug 10 06:33:53 CEST 2023 > > port directory: /usr/ports/lang/python27 > > > > The first failed, the one of today went fine. The main difference in the > > building log is: > > > > failing job: > > --MAKE_ENV-- > > OPENSSLBASE=/usr/local OPENSSLDIR=/usr/local/openssl OPENSSLINC=/usr/local/include OPENSSLLIB=/usr/local/lib OPENSSLRPATH=/usr/local/lib > > > > fine job: > > --MAKE_ENV-- > > OPENSSLBASE=/usr OPENSSLDIR=/etc/ssl OPENSSLINC=/usr/include OPENSSLLIB=/usr/lib > > ... > > > > I didn't changed anything in the poudriere config or port's options. The > > only thing I did between was yesterday evening a 'git pull' in > > /usr/ports. > > > > What could have triggered this change of the used SSL version? > > 1. lang/python27 is no longer supported upstream. > 2. lang/python27’s modules and compatible third-party packages won’t work with OpenSSL 3; they depend on OpenSSL 1.x specific symbols/APIs. > > If you want to make lang/python27 work with OpenSSL 3, you’re going to port the modules to OpenSSL 3 > > My question is: why are you doing this, given that it’s no longer receiving upstream updates (functional or security)? Don't know if I can answer your questions. I'm building ports with poudriere and lang/python27 is pulled in from some other ports. The port lang/python27 itself is not on my list for poudriere: # grep python /usr/local/etc/poudriere-list databases/postgresql13-plpython lang/python3 matthias -- Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub From nobody Thu Aug 10 22:02:39 2023 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 4RMLWs0LXgz4q92y for ; Thu, 10 Aug 2023 22:02:49 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) (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 4RMLWr44M2z3KT1; Thu, 10 Aug 2023 22:02:48 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pf1-x433.google.com with SMTP id d2e1a72fcca58-686f0d66652so1247529b3a.2; Thu, 10 Aug 2023 15:02:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691704967; x=1692309767; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=CPUau7lXI6gcKj/ZTpTY7ADrB+bMV+jTBoX3V3g2bNA=; b=bkMoSrnHoOm/GcqyMEfCdoVDnrCmHO8HlP0aoU1+myEcqSDa2LhjpDYFixxL8//h1p eZpulcH1EE6ycF5aEdNQdDspmIGryh5IbN2kA7LmXYI4mLzbeysAlBpsJXShvTQYHLHP mEenn6zsZYHE5SUi8Uvn4qF+aoYCzkINFk1MqZIMSkadJ0AbgwoOMafSgIA2uVgfBixS H3yzMHnOVL6BqP44dLq06G/z+VwOjciR+UnQ7LTEsjYFyubmCMTAshU18J9UBAszIh0I kI43DGF8UTjC9NvNuavVl6AZx94RoneGX70rV0OpX4FqToyciAG67wasIInTQDImVSjA QOyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691704967; x=1692309767; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=CPUau7lXI6gcKj/ZTpTY7ADrB+bMV+jTBoX3V3g2bNA=; b=Rl0PcFHGk8ugkZ8Fi3zgXo+M9rZ1Dgr2uwUp+5hPA1NcPd134aLyAgPCXhXzNPQJj3 vo0kmkI2J9MUWEsxVkenUCM4A0CMCU3OsK0LhLoxn5x0dH1oyhEkOTGYh3k1ioNvNpIj g4pQfHyRue1tnOZwimBoSAwBo1DgHnzdjMli7/qdztKrRShaSoHShlhHrghPFy6dRHIX JTNQdu+3weYaMm2f6AkGmV146smqoEbDHAmehdePJXXwukDy0BSkUUujmejFecg4FQu7 1A/DNhrhea542eFQqMxenP8YggTYQBETqjE/JPebrMQLfN5gT4VeUydz52f8+vpqeDwY 3FrQ== X-Gm-Message-State: AOJu0Ywt33p/66yF1Fd15HfoMYTw5QzLPTXbcNxCR/n0RDxJYcIG+lAs +GwN89w1xT+ByHgYc8W4v0A= X-Google-Smtp-Source: AGHT+IGh2ZhRtM31hmJi0qB5jwFy2CZ9Q4M48ZwqFxOH3pbznGv2aO0hx1UE6z+dicQHBqxR5+Ndxw== X-Received: by 2002:a17:90b:1244:b0:268:977d:5253 with SMTP id gx4-20020a17090b124400b00268977d5253mr3385278pjb.8.1691704967320; Thu, 10 Aug 2023 15:02:47 -0700 (PDT) Received: from smtpclient.apple (c-73-19-52-228.hsd1.wa.comcast.net. [73.19.52.228]) by smtp.gmail.com with ESMTPSA id s3-20020a170902ea0300b001bb9b87ac95sm2267850plg.103.2023.08.10.15.02.41 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 Aug 2023 15:02:42 -0700 (PDT) From: Enji Cooper Message-Id: <2D0B1311-6E7C-4A34-970F-2BA9BFB9C34F@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_2BAA323B-E40D-430D-A5A1-C8AE8FA06A2D"; protocol="application/pgp-signature"; micalg=pgp-sha256 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 16.0 \(3696.120.41.1.4\)) Subject: Re: port lang/python27 does not build in 14.0-CURRENT w/ poudriere Date: Thu, 10 Aug 2023 15:02:39 -0700 In-Reply-To: Cc: Moin Rahman , freebsd-current@freebsd.org To: Matthias Apitz References: <414B922C-C553-41D4-B519-E3B3B239B606@freebsd.org> <9A29A1BA-F957-40D9-96C6-062471BA14AF@freebsd.org> <5E811C16-5D72-44EC-A14B-06BB9FADB793@gmail.com> X-Mailer: Apple Mail (2.3696.120.41.1.4) X-Rspamd-Queue-Id: 4RMLWr44M2z3KT1 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] --Apple-Mail=_2BAA323B-E40D-430D-A5A1-C8AE8FA06A2D Content-Type: multipart/alternative; boundary="Apple-Mail=_C94635CD-4204-4EF7-98BD-CC61480949A9" --Apple-Mail=_C94635CD-4204-4EF7-98BD-CC61480949A9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 10, 2023, at 2:56 PM, Matthias Apitz wrote: =E2=80=A6 > Don't know if I can answer your questions. I'm building ports with > poudriere and lang/python27 is pulled in from some other ports. The = port > lang/python27 itself is not on my list for poudriere: >=20 > # grep python /usr/local/etc/poudriere-list > databases/postgresql13-plpython > lang/python3 Hmm=E2=80=A6 All lang/python27 requiring ports should be marked BROKEN = and removed =E2=80=94 upstream stopped supporting 2.7 3.5 years ago = (04/01/2020) :/. Cheers, -Enji --Apple-Mail=_C94635CD-4204-4EF7-98BD-CC61480949A9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On = Aug 10, 2023, at 2:56 PM, Matthias Apitz <guru@unixarea.de> = wrote:

=E2=80=A6
Don't know if I can answer your = questions. I'm building ports with
poudriere and lang/python27 is pulled in from some other = ports. The port
lang/python27 itself is not on my list for = poudriere:

# grep python = /usr/local/etc/poudriere-list
databases/postgresql13-plpython
lang/python3

Hmm=E2=80=A6 All lang/python27 requiring = ports should be marked BROKEN and removed =E2=80=94 upstream stopped = supporting 2.7 3.5 years ago (04/01/2020) :/.
Cheers,
-Enji
= --Apple-Mail=_C94635CD-4204-4EF7-98BD-CC61480949A9-- --Apple-Mail=_2BAA323B-E40D-430D-A5A1-C8AE8FA06A2D 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----- iQIzBAEBCAAdFiEEtvtxN6kOllEF3nmX5JFNMZeDGN4FAmTVXoAACgkQ5JFNMZeD GN4Ytw/+M1hsq0CeeAmTdZQlrCoWrr2T0rngAmaXsyStiE6OjtoYdk63Qs4Hqw4K /CowQdYbjo3zTsFZytn5M3q9/n0qLo0MxsLUTCLwbvC2gjnCEnbMu9/7DCglIiSq /e5keNtc5EFfZUN1VW5bXIodFMO3yi9z34HO1pjYW3N5DW55Bl38K7P/ftFR01X3 X+Q5Ggl+tWLg1flrMhmyxHITY12pvq4i7xypO8YpBycHmHrknGDDiA74E9ITAaAR bi1Y7QeTxrYBZMCT7qADWzYIyn5EIxyIHKH+xv4rGtJRba7t4GFhFo5iIEz0KqNn SJm5FTzlqR4nbHmsxqdhp7H5BnVKBHn9F7bv+1ZTF4gURZrd4yk+TXF7eo/baMWO piAnEieXr1ZV5hKeGvOAFnsmyoSHJ2VSef+swFOmsbX/eJU6GMWdvoYF8Jqvv7N7 g3yuJsOzS+RKFLsO8tATSdaFWPj7pf75gQFGtOLi/PVbEk8PJaR9aBQ6cQGsHOna qyCypiM6ygLqA0/5aDSQeWY1DbzSJ9hWiSiZpDx1T9/D7uaaGOiwE447flKFolot sPjMqoxUtY5N+frl6JfDWqtERfY7ymaNnjjwMpsNI1m7cpQNgv6Ml0VT9d0C6so3 TEoHgPMEJzF5f1cykFWlmgY1rVP+HBSfqCdrEnFVJHdrql9qXsM= =Jhtf -----END PGP SIGNATURE----- --Apple-Mail=_2BAA323B-E40D-430D-A5A1-C8AE8FA06A2D-- From nobody Thu Aug 10 22:09:54 2023 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 4RMLh65QTKz4q9M7 for ; Thu, 10 Aug 2023 22:09:58 +0000 (UTC) (envelope-from vishwin@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 4RMLh64vY5z3Lgf; Thu, 10 Aug 2023 22:09:58 +0000 (UTC) (envelope-from vishwin@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1691705398; 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=YkPQBBTBDNjvqPrNB+GF3nj4RvCYYDGCGEHQkCsZDkk=; b=ZQufB7mzu/ylr7PSreerbKv1jinZ8Cd2SYItej+E8CtSi1bc7YuxYWzhnRACXfxLUmVObG gGstW+iaIewDwwf0JdTeTkGiakwssLg+9s3S5c4FtynJOaEFe/B2zCYwxI4TeTxA3jYWJf Y5tz6oKhc32R3W9Ep88aNwvcPnckRH9qV0swlH39yF1eg0y75yCgBNFjskWP2bwE+Yyug2 FzyNwWBKn3p9U9tZ6UF3zb2U8dUEYZIpfQTnzLTjpaXw4wW5knoOczp6vz99MgrSH+aAFP tiSyjazejXL6/AG7wYntPO9KXtfY1qQZWJwjiEqrTPmdUXQq9pFFmvKgAC+xsw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1691705398; 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=YkPQBBTBDNjvqPrNB+GF3nj4RvCYYDGCGEHQkCsZDkk=; b=OyOAj5G4938HP1yyIUTB0T3fPtWG3yP7BkLWe2LyW0IYQl0pbWwuu2Bz80fVRrpfxAs2u6 WPgzOc5YMoPAfipVERT+piRkhqNrrN/I70zJq8yHNZhMriG51ztAfGcPjBRAFa+ojstCdA bSWhYhLA3g5x0C8eeFdHxgTxznCL3u/bUn7a1PObmCGY/SAnQB5SXqMgDV4fBAgpQy/+pL pyXWUN/u7JDJi5hbjywMlTW7VLipPzm12lCT+/aySr5IwUiONZhfsJ/rklaquoRoELcKVq qYnnQpJe+sqfPBxVKfHkJ1DtQ7UIHmxJx5hc7hfv4ckSQb5Ouxl6aHy3zwgvXw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1691705398; a=rsa-sha256; cv=none; b=f4V7esuaXhGnwkLl0qu/k2/7I7RDzI9JxkKxGm7KNL3waevnnD9gkw1PY2GIliuX4C+yK6 dkAdH2HBtB1+Sa2zRL4vnXZrfo2mXnR0zM6A9Rb1yzQRvnrbkkGI6ValAHNIZ7KEmTM+Ro AIA66JMFe5jqsQZF0VxeYtNbLwBxtlUZLeyVEmrkikmA2gawjLktEUsH63oBkQ0tVrplbK aCB4RANLuo4Bckr4/3w0jyKLI5JtGGjCLD8hsR+GSxa35UM94ScQC759szLvS2xbs7Bc9q YIVdMJo6nil35IGttHt2p2qC5hrRFeO3rqJ0jGYWwr4U28JG2s+yYxKdvOfFXQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from [IPV6:2601:98a:d80:d0:56ee:75ff:fe50:69b5] (unknown [IPv6:2601:98a:d80:d0:56ee:75ff:fe50:69b5]) (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 did not present a certificate) (Authenticated sender: vishwin/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4RMLh62TbkzD3m; Thu, 10 Aug 2023 22:09:58 +0000 (UTC) (envelope-from vishwin@freebsd.org) Message-ID: <6222a6d8-5940-fd27-af8f-222ee9fdcdb4@freebsd.org> Date: Thu, 10 Aug 2023 18:09:54 -0400 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:102.0) Gecko/20100101 Thunderbird/102.14.0 To: Enji Cooper , Matthias Apitz Cc: Moin Rahman , freebsd-current@freebsd.org References: <414B922C-C553-41D4-B519-E3B3B239B606@freebsd.org> <9A29A1BA-F957-40D9-96C6-062471BA14AF@freebsd.org> <5E811C16-5D72-44EC-A14B-06BB9FADB793@gmail.com> <2D0B1311-6E7C-4A34-970F-2BA9BFB9C34F@gmail.com> Content-Language: en-GB From: Charlie Li Organization: FreeBSD Project Subject: Re: port lang/python27 does not build in 14.0-CURRENT w/ poudriere In-Reply-To: <2D0B1311-6E7C-4A34-970F-2BA9BFB9C34F@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------bJmr10tnzrq8Yw0wjM1DT6Op" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------bJmr10tnzrq8Yw0wjM1DT6Op Content-Type: multipart/mixed; boundary="------------HP1x01NFmO8FAHe4guLhuKPJ"; protected-headers="v1" From: Charlie Li To: Enji Cooper , Matthias Apitz Cc: Moin Rahman , freebsd-current@freebsd.org Message-ID: <6222a6d8-5940-fd27-af8f-222ee9fdcdb4@freebsd.org> Subject: Re: port lang/python27 does not build in 14.0-CURRENT w/ poudriere References: <414B922C-C553-41D4-B519-E3B3B239B606@freebsd.org> <9A29A1BA-F957-40D9-96C6-062471BA14AF@freebsd.org> <5E811C16-5D72-44EC-A14B-06BB9FADB793@gmail.com> <2D0B1311-6E7C-4A34-970F-2BA9BFB9C34F@gmail.com> In-Reply-To: <2D0B1311-6E7C-4A34-970F-2BA9BFB9C34F@gmail.com> --------------HP1x01NFmO8FAHe4guLhuKPJ Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 RW5qaSBDb29wZXIgd3JvdGU6DQo+IEhtbeKApiBBbGwgbGFuZy9weXRob24yNyByZXF1aXJp bmcgcG9ydHMgc2hvdWxkIGJlIG1hcmtlZCBCUk9LRU4gYW5kIA0KPiByZW1vdmVkIOKAlCB1 cHN0cmVhbSBzdG9wcGVkIHN1cHBvcnRpbmcgMi43IDMuNSB5ZWFycyBhZ28gKDA0LzAxLzIw MjApIDovLg0KV2UgY2FuJ3QgZW50aXJlbHkgZG8gdGhhdCB5ZXQuIFVuZm9ydHVuYXRlbHks IG1vaW5tb2luLCBvcmlnaW5hbCBtYWlsbWFuIA0KYW5kIHRoZSBDU00gZm9yIFVFRkktRURL MiAodXNlZCBpbiBiaHl2ZSkgc3RpbGwgc3RhdW5jaGx5IHJlcXVpcmUgdGhpcy4gDQpJdCB3 YXMgdGhlIGNhc2UgdGhhdCBDaHJvbXtlLGl1bX0gYW5kIHF0LXdlYmVuZ2luZSBzdGlsbCBo YWQgUHl0aG9uIDIgDQpidWlsZCBiaXRzIGJ1dCB0aGV5J3ZlIHNpbmNlIG1pZ3JhdGVkIG9m Zi4NCg0KLS0gDQpDaGFybGllIExpDQrigKZub3BlLCBzdGlsbCBkb24ndCBoYXZlIGFuIGV4 aXQgbGluZS4NCg0K --------------HP1x01NFmO8FAHe4guLhuKPJ-- --------------bJmr10tnzrq8Yw0wjM1DT6Op Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wnsEABYIACMWIQRTQA7vBfo8y1zE1rpnj5NgWEFcygUCZNVgMgUDAAAAAAAKCRBnj5NgWEFcyvbK AQD60hCEe9rNxV1Qc6pUqCdLod4hSG2WnP8vzPGCIslFjQEAhcpY99HSBBldYTHeUK6MZngBAbPe TpXZK+yCgFWHUwY= =X6LD -----END PGP SIGNATURE----- --------------bJmr10tnzrq8Yw0wjM1DT6Op-- From nobody Thu Aug 10 22:18:25 2023 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 4RMLt14RTHz4q9nl for ; Thu, 10 Aug 2023 22:18:33 +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 4RMLsz2C4Gz3NxK for ; Thu, 10 Aug 2023 22:18:31 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; dkim=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; dmarc=none Received: from kalamity.joker.local (123-1-88-210.area1b.commufa.jp [123.1.88.210]) (authenticated bits=0) by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 37AMIPlg039517; Fri, 11 Aug 2023 07:18:26 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Fri, 11 Aug 2023 07:18:25 +0900 From: Tomoaki AOKI To: "Jeffrey Bouquet" Cc: freebsd-current@freebsd.org Subject: Re: Has the update procedure changed? Message-Id: <20230811071825.cae3a7a94c7eca083af98d0c@dec.sakura.ne.jp> In-Reply-To: References: <20230810063214.1b694140e7c284e51154fe35@dec.sakura.ne.jp> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.2) 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-Spamd-Result: default: False [-0.50 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; AUTH_NA(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.998]; MV_CASE(0.50)[]; ONCE_RECEIVED(0.10)[]; MIME_GOOD(-0.10)[text/plain]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]; RCVD_COUNT_ONE(0.00)[1]; RCPT_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_SOME(0.00)[]; HAS_ORG_HEADER(0.00)[]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[sakura.ne.jp]; TO_DN_SOME(0.00)[]; R_SPF_NA(0.00)[no SPF record]; RCVD_TLS_LAST(0.00)[] X-Spamd-Bar: / X-Rspamd-Queue-Id: 4RMLsz2C4Gz3NxK On Thu, 10 Aug 2023 03:15:43 -0700 (PDT) "Jeffrey Bouquet" wrote: > On Thu, 10 Aug 2023 06:32:14 +0900, Tomoaki AOKI wrote: > > > On Wed, 9 Aug 2023 05:50:05 -0700 > > David Wolfskill wrote: > > > > > On Wed, Aug 09, 2023 at 09:38:22PM +0900, Tomoaki AOKI wrote: > > > > ... > > > > > > > > Please correct me if I'm missing something. > > > > I use source update for years and not using bsdinstall nor > > > > freebsd-update. > > > > > > > > Does bsdinstall (and/or freebsd-update) create the first current tree > > > > for etcupdate, if not yet exists? > > > > > > > > This would be most confusing and harmful point of etcupdate. > > > > When I first tried etcupdate, I didn't noticed that I needed > > > > `etcupdate extract -B` BEFORE UPDATING src tree. > > > > Without this, etcupdate cannot detect what should be updated, even if a > > > > plenty of updates are required. > > > > > > > > At the moment, I must use mergemaster, and after that, `etcupdate > > > > extract -B` for next run. > > > > > > > > I think bsdinstall can create current tree, which is turned over to old > > > > tree on actual run, for etcupdate. > > > > So do freebsd-update. It would be able to create current tree JUST > > > > BEFORE INSTALLING UPDATE. > > > > > > > > I was helped by mergemaster, but after it completely retires, features > > > > above should be mandatory. > > > > .... > > > > > > TL;DR: Please see the "Bootstrapping" section of etcupdate(8). > > > > I know. ;-) I'm using etcupdate when it first MFC'ed to latest stable > > branch ATM, and bitten at the first time. > > > > Anyone not familiar with etcupdate would bitten by forgotton > > bootstrapping. :-( > > > > > > > Details: I have been doing source-based updates of FreeBSD since around > > > 1999. As such, I used mergemaster for a long time, and got used to it. > > > > > > With the switch to git, the $FreeBSD$ lines in config files became ... > > > well, misleading noise. And since mergemaster tried to use them, that > > > didn't work very well. This provided the incentive I needed to switch > > > to etcupdate. > > > > > > And... yeah; there was a "learning curve." And the "bootstrapping" bit > > > is necessary. But it has worked well for me since. > > > > Yes. But if bsdinstall and freebsd-update automatically bootstrap > > etcupdate if not yet done, newbies and casual users wouldn't be bitten. > > > > For source-based update users like us, > > > > *Bootstrapping section of man page should be near the top, > > for example, betweem DESCRIPTION and MODES section, not inside > > EXAMPLES section. > > > > *Also documented in UPDATING (or new document for common instructions) > > and handbook. > > > > should be needed. > > etcupdate cannot extract old tree from already-updated src. > > So anyone forgotton bootstrapping is forced to roll back src for > > bootstrapping and roll forward again BEFORE installworld, once > > mergemaster dissapears. > > > > > > > > Peace, > > > david > > > -- > > > David H. Wolfskill david@catwhisker.org > > > Given Trump's claims about fairness in elections, his notion of a > > > "fair trial" is almost certainly at variance with objective reality. > > > > > > See https://www.catwhisker.org/~david/publickey.gpg for my public key. > > > > > > -- > > Tomoaki AOKI > > > Say 3/5 of FreeBSD installs have not used etcupdate yet, and for those they are > less likely to encounter problems [ at least in my experience ] because mergemaster > has always be intuitive, an either-or choice at each menu, near zero chance of > PBKAC, would it not make sense to keep mergemaster around slightly modified, > for instance, with a new section of code that would prepare the result for > "now the next time /etc is updated, use only etcupdate THIS WAY". alternately, > upgrade etcupdate to be VERY verbose in its threeway merge so that > 1... version A of file is in /etc, version B of file is in /var/???, desired version > of file is in /var/??? or /usr/src/??? user's and legacy items in the /etc > version are ... ; ... ; ... ' > menu a) leave this file alone, please edit it manually to >>>> > b) install ... file, you will edit it before reboot. > c).... > more of an intuitive mergemaster - menu alike. > ..... > My uses of etcupdate have left files clobbered, which I had to replace from > backup, and then continue to use mergemaster. I intend thus to keep a > copy of it seperate from the src tree for use forever, I'm old... des@ told me that newbies should not be bitten by etcupdate in another post. It's what I've missed when landed. But upgrading from old installation with freebsd-update is still unclear and so does source updating. For these, letting mergemaster warn for etcupdate seems to be a good idea. But asking "Do you want to use etcupdate next time? (y/N)" after successful merge (or resolved conflicts), and if answerd yes, running `etcupdate extract -B` would be better. And making etcupdate more verbose looks good to me, especially showing where the file was read from. Maybe it would be rare cases, but if former admin changed workdir from the default /var/db/etcupdate without noting, the next admin should surely suffers from it. Making etcupdate verbose should help them. -- Tomoaki AOKI From nobody Thu Aug 10 22:27:34 2023 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 4RMM4q3HfFz4qB47 for ; Thu, 10 Aug 2023 22:27:55 +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 4RMM4q0G0bz3Q6x; Thu, 10 Aug 2023 22:27:54 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; none Received: from kalamity.joker.local (123-1-88-210.area1b.commufa.jp [123.1.88.210]) (authenticated bits=0) by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 37AMRYg0040597; Fri, 11 Aug 2023 07:27:34 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Fri, 11 Aug 2023 07:27:34 +0900 From: Tomoaki AOKI To: Dag-Erling =?UTF-8?B?U23DuHJncmF2?= Cc: David Wolfskill , freebsd-current@freebsd.org Subject: Re: Has the update procedure changed? Message-Id: <20230811072734.e3adac011062e849c7c3b948@dec.sakura.ne.jp> In-Reply-To: <86zg2zrnvp.fsf@ltc.des.no> References: <7A0E604D-EF40-4F10-B597-F1F076507192@gmail.com> <20230809213822.950a3c337ec86c102dcbd235@dec.sakura.ne.jp> <20230810063214.1b694140e7c284e51154fe35@dec.sakura.ne.jp> <86zg2zrnvp.fsf@ltc.des.no> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.2) 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=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4RMM4q0G0bz3Q6x X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP] On Thu, 10 Aug 2023 16:08:26 +0200 Dag-Erling Smørgrav wrote: > Tomoaki AOKI writes: > > Yes. But if bsdinstall and freebsd-update automatically bootstrap > > etcupdate if not yet done, newbies and casual users wouldn't be bitten. > > https://cgit.freebsd.org/src/commit/?id=e9120a256075543376496fbd75949eed1f13a887 > > DES > -- > Dag-Erling Smørgrav - des@FreeBSD.org Oh, thanks! I've completely missed it when landed. This can help new installation using release tarballs (official or locally built) or upgrading with overwriting using said tarballs, but how does freebsd-update? I'm not enough familiar with how freebsd-update upgrades base. -- Tomoaki AOKI From nobody Thu Aug 10 23:00:45 2023 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 4RMMpp5hrdz4qDTw for ; Thu, 10 Aug 2023 23:00:50 +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 4RMMpn2BLjz3TPW for ; Thu, 10 Aug 2023 23:00:49 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; dkim=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; dmarc=none Received: from kalamity.joker.local (123-1-88-210.area1b.commufa.jp [123.1.88.210]) (authenticated bits=0) by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 37AN0kN5044737 for ; Fri, 11 Aug 2023 08:00:46 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Fri, 11 Aug 2023 08:00:45 +0900 From: Tomoaki AOKI To: freebsd-current@freebsd.org Subject: Re: port lang/python27 does not build in 14.0-CURRENT w/ poudriere Message-Id: <20230811080045.ce1eab46a48b3c86a0d4bf78@dec.sakura.ne.jp> In-Reply-To: <6222a6d8-5940-fd27-af8f-222ee9fdcdb4@freebsd.org> References: <414B922C-C553-41D4-B519-E3B3B239B606@freebsd.org> <9A29A1BA-F957-40D9-96C6-062471BA14AF@freebsd.org> <5E811C16-5D72-44EC-A14B-06BB9FADB793@gmail.com> <2D0B1311-6E7C-4A34-970F-2BA9BFB9C34F@gmail.com> <6222a6d8-5940-fd27-af8f-222ee9fdcdb4@freebsd.org> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.2) 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=UTF-8 Content-Transfer-Encoding: 8bit X-Spamd-Result: default: False [-1.48 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; NEURAL_HAM_LONG(-0.98)[-0.982]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; ONCE_RECEIVED(0.10)[]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; R_DKIM_NA(0.00)[]; HAS_ORG_HEADER(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; R_SPF_NA(0.00)[no SPF record]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; DMARC_NA(0.00)[sakura.ne.jp]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_VIA_SMTP_AUTH(0.00)[] X-Spamd-Bar: - X-Rspamd-Queue-Id: 4RMMpn2BLjz3TPW On Thu, 10 Aug 2023 18:09:54 -0400 Charlie Li wrote: > Enji Cooper wrote: > > Hmm… All lang/python27 requiring ports should be marked BROKEN and > > removed — upstream stopped supporting 2.7 3.5 years ago (04/01/2020) :/. > We can't entirely do that yet. Unfortunately, moinmoin, original mailman > and the CSM for UEFI-EDK2 (used in bhyve) still staunchly require this. > It was the case that Chrom{e,ium} and qt-webengine still had Python 2 > build bits but they've since migrated off. > > -- > Charlie Li > …nope, still don't have an exit line. Can lang/tauthon used instead of lang/python27? It's a fork of python27 and maintained (slowly) like [1]. I don't use python nor tauthon directly, though. I dislike languages killing backward compatibility... :-( I love C as even recent llvm/clang has an ability to compile K&R codes, if proper options are set. This is how ALL computer languages SHALL BE. [1] https://github.com/naftaliharris/tauthon/commit/52473e14e93366e02cf0b63b4c7fd952420e5ee3 -- Tomoaki AOKI From nobody Thu Aug 10 23:28:54 2023 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 4RMNRS1mvRz4Tjbn for ; Thu, 10 Aug 2023 23:29:08 +0000 (UTC) (envelope-from kevin.bowling@kev009.com) Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) (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 4RMNRS1LQFz3Wl1 for ; Thu, 10 Aug 2023 23:29:08 +0000 (UTC) (envelope-from kevin.bowling@kev009.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pf1-x42f.google.com with SMTP id d2e1a72fcca58-68783004143so1152795b3a.2 for ; Thu, 10 Aug 2023 16:29:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kev009.com; s=google; t=1691710147; x=1692314947; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=JcUrW896cluM/C5X4BPKGinAA0zD3iokYWrO1xzRjNQ=; b=ShyotWvi5oJ9maX/ra3lJFB/LNgOUrs4klQX7SVMx8UHZrmdUJwlDsNXdLoezRE3Vf 7VHakzZnjzaoJ5d6z0UQEaQgr8qrEllmJkdU1qm2Ka0Jo+HPboUGK5YwIYq4Yt1smWHd 4AqtIBrPLaduAOj3K/xZ+8cfZHTOPKxaIqw40= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691710147; x=1692314947; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=JcUrW896cluM/C5X4BPKGinAA0zD3iokYWrO1xzRjNQ=; b=EZmOj+AuXg/2OlwUChm/oZ1LbrFj6vOjQaVi9pN0A6WrzdpfYov35Zkf/RE4wrf1qZ mccHEsJ7KeMpsd0Zds6WPWyILXX9xq2hmfnCH6n0lc2vY71kUYweaOwmlN+jIvioYFxu oUlD5TCt4ZWKW7HaBRQRmB812HkLj9Mf/ZeQu+qIzRZwan5U0cWDmsqYAVhOwWtoWWrf yI8Um8t7KmDBvPoWyq5rJdrN/OU4XH0M1RN0aQKy6fTxh04F+jNgiS+ncJWqR2adZqXC /xLRYWqXw7Js1zqOAnfOtH97bipDzQ+qSTAquqaJQZ7STQXZHCvWZ9cRGMPCLDzurzhF 2WrA== X-Gm-Message-State: AOJu0YyQbuywtaw0LEjYqB096yx9e88lRSBxFqIY64RdZTKiLA2lwJeP CLVIOpebsacsh60BezV8rgx022vneOHblFykIxsswQ== X-Google-Smtp-Source: AGHT+IH4NbqU1QYNe3VKEY9KjxA9I93wQg+Vh9LEqD82DTKNCTZRfg+6Ecv583ZVc9Uf0qdcV36QY5K6hpuyv0dxfK0= X-Received: by 2002:a05:6a20:13d8:b0:140:2805:6cc8 with SMTP id ho24-20020a056a2013d800b0014028056cc8mr435051pzc.27.1691710146779; Thu, 10 Aug 2023 16:29:06 -0700 (PDT) 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: <86leeltqcb.fsf@ltc.des.no> <20230810133745.D0EC0178@slippy.cwsent.com> In-Reply-To: <20230810133745.D0EC0178@slippy.cwsent.com> From: Kevin Bowling Date: Thu, 10 Aug 2023 16:28:54 -0700 Message-ID: Subject: Re: ZFS deadlock in 14 To: Cy Schubert Cc: =?UTF-8?Q?Dag=2DErling_Sm=C3=B8rgrav?= , current@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4RMNRS1LQFz3Wl1 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] The two MFVs on head have improved/fixed stability with poudriere for me 48 core bare metal. On Thu, Aug 10, 2023 at 6:37=E2=80=AFAM Cy Schubert wrote: > > In message om> > , Kevin Bowling writes: > > Possibly https://github.com/openzfs/zfs/commit/2cb992a99ccadb78d97049b4= 0bd4=3D > > 42eb4fdc549d > > > > On Tue, Aug 8, 2023 at 10:08=3DE2=3D80=3DAFAM Dag-Erling Sm=3DC3=3DB8rg= rav > sd.org> wrote: > > > > > > At some point between 42d088299c (4 May) and f0c9703301 (26 June), a > > > deadlock was introduced in ZFS. It is still present as of 9c2823bae9= (4 > > > August) and is 100% reproducable just by starting poudriere bulk in a > > > 16-core VM and waiting a few hours until deadlkres kicks in. In the > > > latest instance, deadlkres complained about a bash process: > > > > > > #0 sched_switch (td=3D3Dtd@entry=3D3D0xfffffe02fb1d8000, flags= =3D3Dflags@e=3D > > ntry=3D3D259) at /usr/src/sys/kern/sched_ule.c:2299 > > > #1 0xffffffff80b5a0a3 in mi_switch (flags=3D3Dflags@entry=3D3D25= 9) at /u=3D > > sr/src/sys/kern/kern_synch.c:550 > > > #2 0xffffffff80babcb4 in sleepq_switch (wchan=3D3D0xfffff818543a= 9e70, =3D > > pri=3D3D64) at /usr/src/sys/kern/subr_sleepqueue.c:609 > > > #3 0xffffffff80babb8c in sleepq_wait (wchan=3D3D, p= ri=3D3D<=3D > > unavailable>) at /usr/src/sys/kern/subr_sleepqueue.c:660 > > > #4 0xffffffff80b1c1b0 in sleeplk (lk=3D3Dlk@entry=3D3D0xfffff818= 543a9e70=3D > > , flags=3D3Dflags@entry=3D3D2121728, ilk=3D3Dilk@entry=3D3D0x0, wmesg= =3D3Dwmesg@entry=3D > > =3D3D0xffffffff8222a054 "zfs", pri=3D3D, pri@entry=3D3D6= 4, timo=3D3D=3D > > timo@entry=3D3D6, queue=3D3D1) at /usr/src/sys/kern/kern_lock.c:310 > > > #5 0xffffffff80b1a23f in lockmgr_slock_hard (lk=3D3D0xfffff81854= 3a9e70=3D > > , flags=3D3D2121728, ilk=3D3D, file=3D3D0xffffffff812544= fb "/usr/s=3D > > rc/sys/kern/vfs_subr.c", line=3D3D3057, lwa=3D3D0x0) at /usr/src/sys/ke= rn/kern_=3D > > lock.c:705 > > > #6 0xffffffff80c59ec3 in VOP_LOCK1 (vp=3D3D0xfffff818543a9e00, f= lags=3D > > =3D3D2105344, file=3D3D0xffffffff812544fb "/usr/src/sys/kern/vfs_subr.c= ", line=3D > > =3D3D3057) at ./vnode_if.h:1120 > > > #7 _vn_lock (vp=3D3Dvp@entry=3D3D0xfffff818543a9e00, flags=3D3D2= 105344, fi=3D > > le=3D3D, line=3D3D, line@entry=3D3D3057) at /= usr/src/sy=3D > > s/kern/vfs_vnops.c:1815 > > > #8 0xffffffff80c4173d in vget_finish (vp=3D3D0xfffff818543a9e00,= flags=3D > > =3D3D, vs=3D3Dvs@entry=3D3DVGET_USECOUNT) at /usr/src/sys/= kern/vfs_s=3D > > ubr.c:3057 > > > #9 0xffffffff80c1c9b7 in cache_lookup (dvp=3D3Ddvp@entry=3D3D0xf= ffff802c=3D > > d02ac40, vpp=3D3Dvpp@entry=3D3D0xfffffe046b20ac30, cnp=3D3Dcnp@entry=3D= 3D0xfffffe04=3D > > 6b20ac58, tsp=3D3Dtsp@entry=3D3D0x0, ticksp=3D3Dticksp@entry=3D3D0x0) a= t /usr/src/s=3D > > ys/kern/vfs_cache.c:2086 > > > #10 0xffffffff80c2150c in vfs_cache_lookup (ap=3D3D) at =3D > > /usr/src/sys/kern/vfs_cache.c:3068 > > > #11 0xffffffff80c32c37 in VOP_LOOKUP (dvp=3D3D0xfffff802cd02ac40,= vpp=3D > > =3D3D0xfffffe046b20ac30, cnp=3D3D0xfffffe046b20ac58) at ./vnode_if.h:69 > > > #12 vfs_lookup (ndp=3D3Dndp@entry=3D3D0xfffffe046b20abd8) at /usr= /src/sys=3D > > /kern/vfs_lookup.c:1266 > > > #13 0xffffffff80c31ce1 in namei (ndp=3D3Dndp@entry=3D3D0xfffffe04= 6b20abd8=3D > > ) at /usr/src/sys/kern/vfs_lookup.c:689 > > > #14 0xffffffff80c52090 in kern_statat (td=3D3D0xfffffe02fb1d8000,= flag=3D > > =3D3D, fd=3D3D-100, path=3D3D0xa75b480e070 > emory at address 0xa75b480e070>, pathseg=3D3Dpathseg@entry=3D3DUIO_USER= SPACE, s=3D > > bp=3D3Dsbp@entry=3D3D0xfffffe046b20ad18) > > > at /usr/src/sys/kern/vfs_syscalls.c:2441 > > > #15 0xffffffff80c52797 in sys_fstatat (td=3D3D, uap= =3D3D0xff=3D > > fffe02fb1d8400) at /usr/src/sys/kern/vfs_syscalls.c:2419 > > > #16 0xffffffff81049398 in syscallenter (td=3D3D) a= t /usr=3D > > /src/sys/amd64/amd64/../../kern/subr_syscall.c:190 > > > #17 amd64_syscall (td=3D3D0xfffffe02fb1d8000, traced=3D3D0) at /u= sr/src/s=3D > > ys/amd64/amd64/trap.c:1199 > > > #18 > > > > > > The lock it is trying to acquire in frame 5 belongs to another bash > > > process which is in the process of creating a fifo: > > > > > > #0 sched_switch (td=3D3Dtd@entry=3D3D0xfffffe046acd8e40, flags= =3D3Dflags@e=3D > > ntry=3D3D259) at /usr/src/sys/kern/sched_ule.c:2299 > > > #1 0xffffffff80b5a0a3 in mi_switch (flags=3D3Dflags@entry=3D3D25= 9) at /u=3D > > sr/src/sys/kern/kern_synch.c:550 > > > #2 0xffffffff80babcb4 in sleepq_switch (wchan=3D3D0xfffff8018acb= f154, =3D > > pri=3D3D87) at /usr/src/sys/kern/subr_sleepqueue.c:609 > > > #3 0xffffffff80babb8c in sleepq_wait (wchan=3D3D, p= ri=3D3D<=3D > > unavailable>) at /usr/src/sys/kern/subr_sleepqueue.c:660 > > > #4 0xffffffff80b59606 in _sleep (ident=3D3Dident@entry=3D3D0xfff= ff8018ac=3D > > bf154, lock=3D3Dlock@entry=3D3D0xfffff8018acbf120, priority=3D3Dpriorit= y@entry=3D3D=3D > > 87, wmesg=3D3D0xffffffff8223af0e "zfs teardown inactive", sbt=3D3Dsbt@e= ntry=3D3D0=3D > > , pr=3D3Dpr@entry=3D3D0, flags=3D3D256) > > > at /usr/src/sys/kern/kern_synch.c:225 > > > #5 0xffffffff80b45dc0 in rms_rlock_fallback (rms=3D3D0xfffff8018= acbf12=3D > > 0) at /usr/src/sys/kern/kern_rmlock.c:1015 > > > #6 0xffffffff80b45c93 in rms_rlock (rms=3D3D, rms@e= ntry=3D > > =3D3D0xfffff8018acbf120) at /usr/src/sys/kern/kern_rmlock.c:1036 > > > #7 0xffffffff81fb147b in zfs_freebsd_reclaim (ap=3D3D) =3D > > at /usr/src/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vnops_os.c:51= 64 > > > #8 0xffffffff8111d245 in VOP_RECLAIM_APV (vop=3D3D0xffffffff822e= 71a0 <=3D > > zfs_vnodeops>, a=3D3Da@entry=3D3D0xfffffe0410f1c9c8) at vnode_if.c:2180 > > > #9 0xffffffff80c43569 in VOP_RECLAIM (vp=3D3D0xfffff802cdbaca80)= at ./=3D > > vnode_if.h:1084 > > > #10 vgonel (vp=3D3Dvp@entry=3D3D0xfffff802cdbaca80) at /usr/src/s= ys/kern/=3D > > vfs_subr.c:4143 > > > #11 0xffffffff80c3ef61 in vtryrecycle (vp=3D3D0xfffff802cdbaca80)= at /u=3D > > sr/src/sys/kern/vfs_subr.c:1693 > > > #12 vnlru_free_impl (count=3D3Dcount@entry=3D3D1, mnt_op=3D3Dmnt_= op@entry=3D > > =3D3D0x0, mvp=3D3D0xfffff8010864da00) at /usr/src/sys/kern/vfs_subr.c:1= 344 > > > #13 0xffffffff80c49553 in vnlru_free_locked (count=3D3D1) at /usr= /src/s=3D > > ys/kern/vfs_subr.c:1357 > > > #14 vn_alloc_hard (mp=3D3Dmp@entry=3D3D0x0) at /usr/src/sys/kern/= vfs_subr=3D > > .c:1744 > > > #15 0xffffffff80c3f6f0 in vn_alloc (mp=3D3D0x0) at /usr/src/sys/a= md64/i=3D > > nclude/atomic.h:375 > > > #16 getnewvnode_reserve () at /usr/src/sys/kern/vfs_subr.c:1888 > > > #17 0xffffffff81faa072 in zfs_create (dzp=3D3D0xfffff812200261d0,= name=3D > > =3D3D0xfffff8011b8ac805 "sh-np.yPbxoo", vap=3D3D0xfffffe0410f1cc20, exc= l=3D3D > imized out>, mode=3D3D, zpp=3D3Dzpp@entry=3D3D0xfffffe04= 10f1cbc8, =3D > > cr=3D3D0xfffff80140fb1100, flag=3D3D, vsecp=3D3D0x0, mnt= _ns=3D3D0x0) > > > at /usr/src/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vno= ps_o=3D > > s.c:1146 > > > #18 0xffffffff81faea57 in zfs_freebsd_create (ap=3D3D0xfffffe0410= f1cda0=3D > > ) at /usr/src/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vnops_os.c:= 4618 > > > #19 0xffffffff8111aa9a in VOP_MKNOD_APV (vop=3D3D0xffffffff822e71= a0 > s_vnodeops>, a=3D3Da@entry=3D3D0xfffffe0410f1cda0) at vnode_if.c:372 > > > #20 0xffffffff80c50207 in VOP_MKNOD (dvp=3D3D, cnp= =3D3D0xfff=3D > > ffe0410f1cd50, vap=3D3D0xfffffe0410f1cc20, vpp=3D3D) at = ./vnode_=3D > > if.h:188 > > > #21 kern_mkfifoat (td=3D3D0xfffffe046acd8e40, fd=3D3D-100, path= =3D3D0x12772=3D > > f073500 , pathse= g=3D3D=3D > > UIO_USERSPACE, mode=3D3D) at /usr/src/sys/kern/vfs_sysca= lls.c:=3D > > 1492 > > > #22 0xffffffff81049398 in syscallenter (td=3D3D) a= t /usr=3D > > /src/sys/amd64/amd64/../../kern/subr_syscall.c:190 > > > #23 amd64_ =E6=90=AC=EE=8A=80 syscall (td=3D3D0xfffffe046acd8e= 40, traced=3D3D0) at /usr/src/s=3D > > ys/amd64/amd64/trap.c:1199 > > > #24 > > > > > > Frame 7 is trying to acquire the ZFS teardown inactive lock, which is > > > held by a process which is performing a ZFS rollback and is waiting f= or > > > the transaction to sync: > > > > > > #0 sched_switch (td=3D3Dtd@entry=3D3D0xfffffe0422ef8560, flags= =3D3Dflags@e=3D > > ntry=3D3D259) at /usr/src/sys/kern/sched_ule.c:2299 > > > #1 0xffffffff80b5a0a3 in mi_switch (flags=3D3Dflags@entry=3D3D25= 9) at /u=3D > > sr/src/sys/kern/kern_synch.c:550 > > > #2 0xffffffff80babcb4 in sleepq_switch (wchan=3D3D0xfffff8011b83= d540, =3D > > pri=3D3D0) at /usr/src/sys/kern/subr_sleepqueue.c:609 > > > #3 0xffffffff80babb8c in sleepq_wait (wchan=3D3D, w= chan@e=3D > > ntry=3D3D0xfffff8011b83d540, pri=3D3D, pri@entry=3D3D0) at= /usr/src/=3D > > sys/kern/subr_sleepqueue.c:660 > > > #4 0xffffffff80ad7f75 in _cv_wait (cvp=3D3Dcvp@entry=3D3D0xfffff= 8011b83d=3D > > 540, lock=3D3Dlock@entry=3D3D0xfffff8011b83d4d0) at /usr/src/sys/kern/k= ern_cond=3D > > var.c:146 > > > #5 0xffffffff820b42fb in txg_wait_synced_impl (dp=3D3Ddp@entry= =3D3D0xfff=3D > > ff8011b83d000, txg=3D3D8585097, wait_sig=3D3Dwait_sig@entry=3D3D0) at /= usr/src/sy=3D > > s/contrib/openzfs/module/zfs/txg.c:726 > > > #6 0xffffffff820b3cab in txg_wait_synced (dp=3D3D, = dp@ent=3D > > ry=3D3D0xfffff8011b83d000, txg=3D3D) at /usr/src/sys/contr= ib/openz=3D > > fs/module/zfs/txg.c:736 > > > #7 0xffffffff8206d5b5 in dsl_sync_task_common (pool=3D3Dpool@ent= ry=3D3D0=3D > > xfffffe0401d15000 "zroot/poudriere/jails/13amd64-default-ref/15", check= func=3D > > =3D3D, syncfunc=3D3D0xffffffff8203fbc0 > c>, sigfunc=3D3Dsigfunc@entry=3D3D0x0, arg=3D3Darg@entry=3D3D0xfffffe02= fb827a90, > > > blocks_modified=3D3Dblocks_modified@entry=3D3D1, space_check= =3D3DZFS_SP=3D > > ACE_CHECK_RESERVED, early=3D3D0) at /usr/src/sys/contrib/openzfs/module= /zfs/d=3D > > sl_synctask.c:93 > > > #8 0xffffffff8206d3c7 in dsl_sync_task (pool=3D3D, = pool@e=3D > > ntry=3D3D0xfffffe0401d15000 "zroot/poudriere/jails/13amd64-default-ref/= 15", c=3D > > heckfunc=3D3D, syncfunc=3D3D, arg=3D3D, ar=3D > > g@entry=3D3D0xfffffe02fb827a90, blocks_modified=3D3D, > > > blocks_modified@entry=3D3D1, space_check=3D3D, s= pace_che=3D > > ck@entry=3D3DZFS_SPACE_CHECK_RESERVED) at /usr/src/sys/contrib/openzfs/= module=3D > > /zfs/dsl_synctask.c:132 > > > #9 0xffffffff8204075b in dsl_dataset_rollback (fsname=3D3D > >, fsname@entry=3D3D0xfffffe0401d15000 "zroot/poudriere/jails/13amd64-d= efault=3D > > -ref/15", tosnap=3D3D, owner=3D3D, result= =3D3Dresul=3D > > t@entry=3D3D0xfffff81c826a9ea0) > > > at /usr/src/sys/contrib/openzfs/module/zfs/dsl_dataset.c:3261 > > > #10 0xffffffff82168dd9 in zfs_ioc_rollback (fsname=3D3D0xfffffe04= 01d150=3D > > 00 "zroot/poudriere/jails/13amd64-default-ref/15", fsname@entry=3D3D > ading variable: value is not available>, innvl=3D3D, innvl= @entry=3D > > =3D3D, > > > outnvl=3D3D0xfffff81c826a9ea0, outnvl@entry=3D3D > le: value is not available>) at /usr/src/sys/contrib/openzfs/module/zfs= /zfs=3D > > _ioctl.c:4405 > > > #11 0xffffffff82164522 in zfsdev_ioctl_common (vecnum=3D3Dvecnum@= entry=3D > > =3D3D25, zc=3D3Dzc@entry=3D3D0xfffffe0401d15000, flag=3D3Dflag@entry=3D= 3D0) at /usr/s=3D > > rc/sys/contrib/openzfs/module/zfs/zfs_ioctl.c:7798 > > > #12 0xffffffff81f97fca in zfsdev_ioctl (dev=3D3D, = zcmd=3D > > =3D3D, zcmd@entry=3D3D > ble>, arg=3D3D0xfffffe02fb827d50 "\017", arg@entry=3D3D > value is not available>, flag=3D3D, td=3D3D) > > > at /usr/src/sys/contrib/openzfs/module/os/freebsd/zfs/kmod_co= re.c=3D > > :168 > > > #13 0xffffffff809d6212 in devfs_ioctl (ap=3D3D0xfffffe02fb827c50)= at /u=3D > > sr/src/sys/fs/devfs/devfs_vnops.c:935 > > > #14 0xffffffff80c585f2 in vn_ioctl (fp=3D3D0xfffff8052cdd80f0, co= m=3D3D > ptimized out>, data=3D3D0xfffffe02fb827d50, active_cred=3D3D0xfffff8012= 2ab1e00,=3D > > td=3D3D) at /usr/src/sys/kern/vfs_vnops.c:1704 > > > #15 0xffffffff809d68ee in devfs_ioctl_f (fp=3D3D, fp= @entry=3D > > =3D3D, com=3D3D, c=3D > > om@entry=3D3D, data=3D3= D > lable>, data@entry=3D3D= , > > > cred=3D3D, cred@entry=3D3D > is not available>, td=3D3D, td@entry=3D3D > value is not available>) at /usr/src/sys/fs/devfs/devfs_vnops.c:866 > > > #16 0xffffffff80bc57e6 in fo_ioctl (fp=3D3D0xfffff8052cdd80f0, co= m=3D3D32=3D > > 22821401, data=3D3D, active_cred=3D3D, td=3D3= D0xfffffe0=3D > > 422ef8560) at /usr/src/sys/sys/file.h:367 > > > #17 kern_ioctl (td=3D3Dtd@entry=3D3D0xfffffe0422ef8560, fd=3D3D4,= com=3D3Dcom=3D > > @entry=3D3D3222821401, data=3D3D, data@entry=3D3D0xfffffe0= 2fb827d50 =3D > > "\017") at /usr/src/sys/kern/sys_generic.c:807 > > > #18 0xffffffff80bc54f2 in sys_ioctl (td=3D3D0xfffffe0422ef8560, u= ap=3D3D0=3D > > xfffffe0422ef8960) at /usr/src/sys/kern/sys_generic.c:715 > > > #19 0xffffffff81049398 in syscallenter (td=3D3D) a= t /usr=3D > > /src/sys/amd64/amd64/../../kern/subr_syscall.c:190 > > > #20 amd64_syscall (td=3D3D0xfffffe0422ef8560, traced=3D3D0) at /u= sr/src/s=3D > > ys/amd64/amd64/trap.c:1199 > [...] > > The backtrace looks different though it certainly smells like PR/271945. > > I've had similar to PR/271945 panics on an amd64 with a mirrored zpool wi= th > four vdevs running poudriere with AMD64 jails. My other amd64 with a > mirrored zpool with two vdevs using i386 jails has no such issue. All oth= er > workloads are unaffected. > > On the affected machine running poudriere bulk with -J N:1 circumvents th= e > issue. So far. There were two openzfs cherry-picks this morning. I intend > to try them against a full bulk build later today. > > > -- > Cheers, > Cy Schubert > FreeBSD UNIX: Web: https://FreeBSD.org > NTP: Web: https://nwtime.org > > e^(i*pi)+1=3D0 > > From nobody Thu Aug 10 23:33:12 2023 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 4RMNXC1jcmz4Tk3D for ; Thu, 10 Aug 2023 23:33:15 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta002.cacentral1.a.cloudfilter.net (omta002.cacentral1.a.cloudfilter.net [3.97.99.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RMNXB6N97z3Xm8; Thu, 10 Aug 2023 23:33:14 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; none Received: from shw-obgw-4003a.ext.cloudfilter.net ([10.228.9.183]) by cmsmtp with ESMTP id U7giqt7Va6NwhUF9WqIxGs; Thu, 10 Aug 2023 23:33:14 +0000 Received: from spqr.komquats.com ([70.66.152.170]) by cmsmtp with ESMTPA id UF9UqgCwIcyvuUF9VqGenf; Thu, 10 Aug 2023 23:33:14 +0000 X-Authority-Analysis: v=2.4 cv=VbHkgXl9 c=1 sm=1 tr=0 ts=64d573ba a=y8EK/9tc/U6QY+pUhnbtgQ==:117 a=y8EK/9tc/U6QY+pUhnbtgQ==:17 a=kj9zAlcOel0A:10 a=UttIx32zK-AA:10 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=NEAV23lmAAAA:8 a=SLG1KRGDAAAA:8 a=wac4T8u11kAwLPASYywA:9 a=CjuIK1q_8ugA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=LK5xJRSDVpKd5WXXoEvA:22 a=-TBaU1e9WpdkKBzYXnwo:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id 42E97615; Thu, 10 Aug 2023 16:33:12 -0700 (PDT) Received: by slippy.cwsent.com (Postfix, from userid 1000) id 0E10AF4; Thu, 10 Aug 2023 16:33:12 -0700 (PDT) X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.8+dev Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Kevin Bowling cc: Cy Schubert , =?UTF-8?Q?Dag=2DErling_Sm=C3=B8rgrav?= , current@freebsd.org Subject: Re: ZFS deadlock in 14 In-reply-to: References: <86leeltqcb.fsf@ltc.des.no> <20230810133745.D0EC0178@slippy.cwsent.com> Comments: In-reply-to Kevin Bowling message dated "Thu, 10 Aug 2023 16:28:54 -0700." 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 Date: Thu, 10 Aug 2023 16:33:12 -0700 Message-Id: <20230810233312.0E10AF4@slippy.cwsent.com> X-CMAE-Envelope: MS4xfJqYYqY1+WHq5SDoaNuwNmrzL1cE8dWwAvmRhgMyLdd0ziKOP7OudfnUXlzA9ksm/YssF5Uj1QtQHWObmgEZLcVpunR/B0NywJP/8eUj0AKmFSoZ9Rbr xBMfpvCLNPpLeIsTSuGDBY6gbO4wkV837PK1c8f3COXiStRlfbZVjshwQ2wgzSEnQhmk0tXccj0c4pS4DGnOu8lVZgcciZ7A8Bf6iuhIJ97yH5oEb1BwaEP1 BHvXkYub2VRUP2A806dHXlfgzlKskvAdlfGJpAdkdN0= X-Rspamd-Queue-Id: 4RMNXB6N97z3Xm8 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US] I haven't experienced any problems (yet) either. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=0 In message , Kevin Bowling writes: > The two MFVs on head have improved/fixed stability with poudriere for > me 48 core bare metal. > > On Thu, Aug 10, 2023 at 6:37=E2=80=AFAM Cy Schubert com> wrote: > > > > In message l.c > > om> > > , Kevin Bowling writes: > > > Possibly https://github.com/openzfs/zfs/commit/2cb992a99ccadb78d97049b4= > 0bd4=3D > > > 42eb4fdc549d > > > > > > On Tue, Aug 8, 2023 at 10:08=3DE2=3D80=3DAFAM Dag-Erling Sm=3DC3=3DB8rg= > rav > > sd.org> wrote: > > > > > > > > At some point between 42d088299c (4 May) and f0c9703301 (26 June), a > > > > deadlock was introduced in ZFS. It is still present as of 9c2823bae9= > (4 > > > > August) and is 100% reproducable just by starting poudriere bulk in a > > > > 16-core VM and waiting a few hours until deadlkres kicks in. In the > > > > latest instance, deadlkres complained about a bash process: > > > > > > > > #0 sched_switch (td=3D3Dtd@entry=3D3D0xfffffe02fb1d8000, flags= > =3D3Dflags@e=3D > > > ntry=3D3D259) at /usr/src/sys/kern/sched_ule.c:2299 > > > > #1 0xffffffff80b5a0a3 in mi_switch (flags=3D3Dflags@entry=3D3D25= > 9) at /u=3D > > > sr/src/sys/kern/kern_synch.c:550 > > > > #2 0xffffffff80babcb4 in sleepq_switch (wchan=3D3D0xfffff818543a= > 9e70, =3D > > > pri=3D3D64) at /usr/src/sys/kern/subr_sleepqueue.c:609 > > > > #3 0xffffffff80babb8c in sleepq_wait (wchan=3D3D, p= > ri=3D3D<=3D > > > unavailable>) at /usr/src/sys/kern/subr_sleepqueue.c:660 > > > > #4 0xffffffff80b1c1b0 in sleeplk (lk=3D3Dlk@entry=3D3D0xfffff818= > 543a9e70=3D > > > , flags=3D3Dflags@entry=3D3D2121728, ilk=3D3Dilk@entry=3D3D0x0, wmesg= > =3D3Dwmesg@entry=3D > > > =3D3D0xffffffff8222a054 "zfs", pri=3D3D, pri@entry=3D3D6= > 4, timo=3D3D=3D > > > timo@entry=3D3D6, queue=3D3D1) at /usr/src/sys/kern/kern_lock.c:310 > > > > #5 0xffffffff80b1a23f in lockmgr_slock_hard (lk=3D3D0xfffff81854= > 3a9e70=3D > > > , flags=3D3D2121728, ilk=3D3D, file=3D3D0xffffffff812544= > fb "/usr/s=3D > > > rc/sys/kern/vfs_subr.c", line=3D3D3057, lwa=3D3D0x0) at /usr/src/sys/ke= > rn/kern_=3D > > > lock.c:705 > > > > #6 0xffffffff80c59ec3 in VOP_LOCK1 (vp=3D3D0xfffff818543a9e00, f= > lags=3D > > > =3D3D2105344, file=3D3D0xffffffff812544fb "/usr/src/sys/kern/vfs_subr.c= > ", line=3D > > > =3D3D3057) at ./vnode_if.h:1120 > > > > #7 _vn_lock (vp=3D3Dvp@entry=3D3D0xfffff818543a9e00, flags=3D3D2= > 105344, fi=3D > > > le=3D3D, line=3D3D, line@entry=3D3D3057) at /= > usr/src/sy=3D > > > s/kern/vfs_vnops.c:1815 > > > > #8 0xffffffff80c4173d in vget_finish (vp=3D3D0xfffff818543a9e00,= > flags=3D > > > =3D3D, vs=3D3Dvs@entry=3D3DVGET_USECOUNT) at /usr/src/sys/= > kern/vfs_s=3D > > > ubr.c:3057 > > > > #9 0xffffffff80c1c9b7 in cache_lookup (dvp=3D3Ddvp@entry=3D3D0xf= > ffff802c=3D > > > d02ac40, vpp=3D3Dvpp@entry=3D3D0xfffffe046b20ac30, cnp=3D3Dcnp@entry=3D= > 3D0xfffffe04=3D > > > 6b20ac58, tsp=3D3Dtsp@entry=3D3D0x0, ticksp=3D3Dticksp@entry=3D3D0x0) a= > t /usr/src/s=3D > > > ys/kern/vfs_cache.c:2086 > > > > #10 0xffffffff80c2150c in vfs_cache_lookup (ap=3D3D >) at =3D > > > /usr/src/sys/kern/vfs_cache.c:3068 > > > > #11 0xffffffff80c32c37 in VOP_LOOKUP (dvp=3D3D0xfffff802cd02ac40,= > vpp=3D > > > =3D3D0xfffffe046b20ac30, cnp=3D3D0xfffffe046b20ac58) at ./vnode_if.h:69 > > > > #12 vfs_lookup (ndp=3D3Dndp@entry=3D3D0xfffffe046b20abd8) at /usr= > /src/sys=3D > > > /kern/vfs_lookup.c:1266 > > > > #13 0xffffffff80c31ce1 in namei (ndp=3D3Dndp@entry=3D3D0xfffffe04= > 6b20abd8=3D > > > ) at /usr/src/sys/kern/vfs_lookup.c:689 > > > > #14 0xffffffff80c52090 in kern_statat (td=3D3D0xfffffe02fb1d8000,= > flag=3D > > > =3D3D, fd=3D3D-100, path=3D3D0xa75b480e070 t access m=3D > > > emory at address 0xa75b480e070>, pathseg=3D3Dpathseg@entry=3D3DUIO_USER= > SPACE, s=3D > > > bp=3D3Dsbp@entry=3D3D0xfffffe046b20ad18) > > > > at /usr/src/sys/kern/vfs_syscalls.c:2441 > > > > #15 0xffffffff80c52797 in sys_fstatat (td=3D3D, uap= > =3D3D0xff=3D > > > fffe02fb1d8400) at /usr/src/sys/kern/vfs_syscalls.c:2419 > > > > #16 0xffffffff81049398 in syscallenter (td=3D3D) a= > t /usr=3D > > > /src/sys/amd64/amd64/../../kern/subr_syscall.c:190 > > > > #17 amd64_syscall (td=3D3D0xfffffe02fb1d8000, traced=3D3D0) at /u= > sr/src/s=3D > > > ys/amd64/amd64/trap.c:1199 > > > > #18 > > > > > > > > The lock it is trying to acquire in frame 5 belongs to another bash > > > > process which is in the process of creating a fifo: > > > > > > > > #0 sched_switch (td=3D3Dtd@entry=3D3D0xfffffe046acd8e40, flags= > =3D3Dflags@e=3D > > > ntry=3D3D259) at /usr/src/sys/kern/sched_ule.c:2299 > > > > #1 0xffffffff80b5a0a3 in mi_switch (flags=3D3Dflags@entry=3D3D25= > 9) at /u=3D > > > sr/src/sys/kern/kern_synch.c:550 > > > > #2 0xffffffff80babcb4 in sleepq_switch (wchan=3D3D0xfffff8018acb= > f154, =3D > > > pri=3D3D87) at /usr/src/sys/kern/subr_sleepqueue.c:609 > > > > #3 0xffffffff80babb8c in sleepq_wait (wchan=3D3D, p= > ri=3D3D<=3D > > > unavailable>) at /usr/src/sys/kern/subr_sleepqueue.c:660 > > > > #4 0xffffffff80b59606 in _sleep (ident=3D3Dident@entry=3D3D0xfff= > ff8018ac=3D > > > bf154, lock=3D3Dlock@entry=3D3D0xfffff8018acbf120, priority=3D3Dpriorit= > y@entry=3D3D=3D > > > 87, wmesg=3D3D0xffffffff8223af0e "zfs teardown inactive", sbt=3D3Dsbt@e= > ntry=3D3D0=3D > > > , pr=3D3Dpr@entry=3D3D0, flags=3D3D256) > > > > at /usr/src/sys/kern/kern_synch.c:225 > > > > #5 0xffffffff80b45dc0 in rms_rlock_fallback (rms=3D3D0xfffff8018= > acbf12=3D > > > 0) at /usr/src/sys/kern/kern_rmlock.c:1015 > > > > #6 0xffffffff80b45c93 in rms_rlock (rms=3D3D, rms@e= > ntry=3D > > > =3D3D0xfffff8018acbf120) at /usr/src/sys/kern/kern_rmlock.c:1036 > > > > #7 0xffffffff81fb147b in zfs_freebsd_reclaim (ap=3D3D out>) =3D > > > at /usr/src/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vnops_os.c:51= > 64 > > > > #8 0xffffffff8111d245 in VOP_RECLAIM_APV (vop=3D3D0xffffffff822e= > 71a0 <=3D > > > zfs_vnodeops>, a=3D3Da@entry=3D3D0xfffffe0410f1c9c8) at vnode_if.c:2180 > > > > #9 0xffffffff80c43569 in VOP_RECLAIM (vp=3D3D0xfffff802cdbaca80)= > at ./=3D > > > vnode_if.h:1084 > > > > #10 vgonel (vp=3D3Dvp@entry=3D3D0xfffff802cdbaca80) at /usr/src/s= > ys/kern/=3D > > > vfs_subr.c:4143 > > > > #11 0xffffffff80c3ef61 in vtryrecycle (vp=3D3D0xfffff802cdbaca80)= > at /u=3D > > > sr/src/sys/kern/vfs_subr.c:1693 > > > > #12 vnlru_free_impl (count=3D3Dcount@entry=3D3D1, mnt_op=3D3Dmnt_= > op@entry=3D > > > =3D3D0x0, mvp=3D3D0xfffff8010864da00) at /usr/src/sys/kern/vfs_subr.c:1= > 344 > > > > #13 0xfffff> /src/s=3D > > > ys/kern/vfs_subr.c:1357 > > > > #14 vn_alloc_hard (mp=3D3Dmp@entry=3D3D0x0) at /usr/src/sys/kern/= > vfs_subr=3D > > > .c:1744 > > > > #15 0xffffffff80c3f6f0 in vn_alloc (mp=3D3D0x0) at /usr/src/sys/a= > md64/i=3D > > > nclude/atomic.h:375 > > > > #16 getnewvnode_reserve () at /usr/src/sys/kern/vfs_subr.c:1888 > > > > #17 0xffffffff81faa072 in zfs_create (dzp=3D3D0xfffff812200261d0,= > name=3D > > > =3D3D0xfffff8011b8ac805 "sh-np.yPbxoo", vap=3D3D0xfffffe0410f1cc20, exc= > l=3D3D > > imized out>, mode=3D3D, zpp=3D3Dzpp@entry=3D3D0xfffffe04= > 10f1cbc8, =3D > > > cr=3D3D0xfffff80140fb1100, flag=3D3D, vsecp=3D3D0x0, mnt= > _ns=3D3D0x0) > > > > at /usr/src/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vno= > ps_o=3D > > > s.c:1146 > > > > #18 0xffffffff81faea57 in zfs_freebsd_create (ap=3D3D0xfffffe0410= > f1cda0=3D > > > ) at /usr/src/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vnops_os.c:= > 4618 > > > > #19 0xffffffff8111aa9a in VOP_MKNOD_APV (vop=3D3D0xffffffff822e71= > a0 > > s_vnodeops>, a=3D3Da@entry=3D3D0xfffffe0410f1cda0) at vnode_if.c:372 > > > > #20 0xffffffff80c50207 in VOP_MKNOD (dvp=3D3D, cnp= > =3D3D0xfff=3D > > > ffe0410f1cd50, vap=3D3D0xfffffe0410f1cc20, vpp=3D3D) at = > ./vnode_=3D > > > if.h:188 > > > > #21 kern_mkfifoat (td=3D3D0xfffffe046acd8e40, fd=3D3D-100, path= > =3D3D0x12772=3D > > > f073500 , pathse= > g=3D3D=3D > > > UIO_USERSPACE, mode=3D3D) at /usr/src/sys/kern/vfs_sysca= > lls.c:=3D > > > 1492 > > > > #22 0xffffffff81049398 in syscallenter (td=3D3D) a= > t /usr=3D > > > /src/sys/amd64/amd64/../../kern/subr_syscall.c:190 > > > > #23 amd64_ =E6=90=AC=EE=8A=80 syscall (td=3D3D0xfffffe046acd8e= > 40, traced=3D3D0) at /usr/src/s=3D > > > ys/amd64/amd64/trap.c:1199 > > > > #24 > > > > > > > > Frame 7 is trying to acquire the ZFS teardown inactive lock, which is > > > > held by a process which is performing a ZFS rollback and is waiting f= > or > > > > the transaction to sync: > > > > > > > > #0 sched_switch (td=3D3Dtd@entry=3D3D0xfffffe0422ef8560, flags= > =3D3Dflags@e=3D > > > ntry=3D3D259) at /usr/src/sys/kern/sched_ule.c:2299 > > > > #1 0xffffffff80b5a0a3 in mi_switch (flags=3D3Dflags@entry=3D3D25= > 9) at /u=3D > > > sr/src/sys/kern/kern_synch.c:550 > > > > #2 0xffffffff80babcb4 in sleepq_switch (wchan=3D3D0xfffff8011b83= > d540, =3D > > > pri=3D3D0) at /usr/src/sys/kern/subr_sleepqueue.c:609 > > > > #3 0xffffffff80babb8c in sleepq_wait (wchan=3D3D, w= > chan@e=3D > > > ntry=3D3D0xfffff8011b83d540, pri=3D3D, pri@entry=3D3D0) at= > /usr/src/=3D > > > sys/kern/subr_sleepqueue.c:660 > > > > #4 0xffffffff80ad7f75 in _cv_wait (cvp=3D3Dcvp@entry=3D3D0xfffff= > 8011b83d=3D > > > 540, lock=3D3Dlock@entry=3D3D0xfffff8011b83d4d0) at /usr/src/sys/kern/k= > ern_cond=3D > > > var.c:146 > > > > #5 0xffffffff820b42fb in txg_wait_synced_impl (dp=3D3Ddp@entry= > =3D3D0xfff=3D > > > ff8011b83d000, txg=3D3D8585097, wait_sig=3D3Dwait_sig@entry=3D3D0) at /= > usr/src/sy=3D > > > s/contrib/openzfs/module/zfs/txg.c:726 > > > > #6 0xffffffff820b3cab in txg_wait_synced (dp=3D3D, = > dp@ent=3D > > > ry=3D3D0xfffff8011b83d000, txg=3D3D) at /usr/src/sys/contr= > ib/openz=3D > > > fs/module/zfs/txg.c:736 > > > > #7 0xffffffff8206d5b5 in dsl_sync_task_common (pool=3D3Dpool@ent= > ry=3D3D0=3D > > > xfffffe0401d15000 "zroot/poudriere/jails/13amd64-default-ref/15", check= > func=3D > > > =3D3D, syncfunc=3D3D0xffffffff8203fbc0 back_syn=3D > > > c>, sigfunc=3D3Dsigfunc@entry=3D3D0x0, arg=3D3Darg@entry=3D3D0xfffffe02= > fb827a90, > > > > blocks_modified=3D3Dblocks_modified@entry=3D3D1, space_check= > =3D3DZFS_SP=3D > > > ACE_CHECK_RESERVED, early=3D3D0) at /usr/src/sys/contrib/openzfs/module= > /zfs/d=3D > > > sl_synctask.c:93 > > > > #8 0xffffffff8206d3c7 in dsl_sync_task (pool=3D3D, = > pool@e=3D > > > ntry=3D3D0xfffffe0401d15000 "zroot/poudriere/jails/13amd64-default-ref/= > 15", c=3D > > > heckfunc=3D3D, syncfunc=3D3D, arg=3D3D lable>, ar=3D > > > g@entry=3D3D0xfffffe02fb827a90, blocks_modified=3D3D, > > > > blocks_modified@entry=3D3D1, space_check=3D3D, s= > pace_che=3D > > > ck@entry=3D3DZFS_SPACE_CHECK_RESERVED) at /usr/src/sys/contrib/openzfs/= > module=3D > > > /zfs/dsl_synctask.c:132 > > > > #9 0xffffffff8204075b in dsl_dataset_rollback (fsname=3D3D ilable=3D > > > >, fsname@entry=3D3D0xfffffe0401d15000 "zroot/poudriere/jails/13amd64-d= > efault=3D > > > -ref/15", tosnap=3D3D, owner=3D3D, result= > =3D3Dresul=3D > > > t@entry=3D3D0xfffff81c826a9ea0) > > > > at /usr/src/sys/contrib/openzfs/module/zfs/dsl_dataset.c:3261 > > > > #10 0xffffffff82168dd9 in zfs_ioc_rollback (fsname=3D3D0xfffffe04= > 01d150=3D > > > 00 "zroot/poudriere/jails/13amd64-default-ref/15", fsname@entry=3D3D ror re=3D > > > ading variable: value is not available>, innvl=3D3D, innvl= > @entry=3D > > > =3D3D, > > > > outnvl=3D3D0xfffff81c826a9ea0, outnvl@entry=3D3D g variab=3D > > > le: value is not available>) at /usr/src/sys/contrib/openzfs/module/zfs= > /zfs=3D > > > _ioctl.c:4405 > > > > #11 0xffffffff82164522 in zfsdev_ioctl_common (vecnum=3D3Dvecnum@= > entry=3D > > > =3D3D25, zc=3D3Dzc@entry=3D3D0xfffffe0401d15000, flag=3D3Dflag@entry=3D= > 3D0) at /usr/s=3D > > > rc/sys/contrib/openzfs/module/zfs/zfs_ioctl.c:7798 > > > > #12 0xffffffff81f97fca in zfsdev_ioctl (dev=3D3D, = > zcmd=3D > > > =3D3D, zcmd@entry=3D3D t availa=3D > > > ble>, arg=3D3D0xfffffe02fb827d50 "\017", arg@entry=3D3D ariable:=3D > > > value is not available>, flag=3D3D, td=3D3D ut>) > > > > at /usr/src/sys/contrib/openzfs/module/os/freebsd/zfs/kmod_co= > re.c=3D > > > :168 > > > > #13 0xffffffff809d6212 in devfs_ioctl (ap=3D3D0xfffffe02fb827c50)= > at /u=3D > > > sr/src/sys/fs/devfs/devfs_vnops.c:935 > > > > #14 0xffffffff80c585f2 in vn_ioctl (fp=3D3D0xfffff8052cdd80f0, co= > m=3D3D > > ptimized out>, data=3D3D0xfffffe02fb827d50, active_cred=3D3D0xfffff8012= > 2ab1e00,=3D > > > td=3D3D) at /usr/src/sys/kern/vfs_vnops.c:1704 > > > > #15 0xffffffff809d68ee in devfs_ioctl_f (fp=3D3D, fp= > @entry=3D > > > =3D3D, com=3D3D able>, c=3D > > > om@entry=3D3D, data=3D3= > D > > lable>, data@entry=3D3D= > , > > > > cred=3D3D, cred@entry=3D3D e: value=3D > > > is not available>, td=3D3D, td@entry=3D3D ariable:=3D > > > value is not available>) at /usr/src/sys/fs/devfs/devfs_vnops.c:866 > > > > #16 0xffffffff80bc57e6 in fo_ioctl (fp=3D3D0xfffff8052cdd80f0, co= > m=3D3D32=3D > > > 22821401, data=3D3D, active_cred=3D3D, td=3D3= > D0xfffffe0=3D > > > 422ef8560) at /usr/src/sys/sys/file.h:367 > > > > #17 kern_ioctl (td=3D3Dtd@entry=3D3D0xfffffe0422ef8560, fd=3D3D4,= > com=3D3Dcom=3D > > > @entry=3D3D3222821401, data=3D3D, data@entry=3D3D0xfffffe0= > 2fb827d50 =3D > > > "\017") at /usr/src/sys/kern/sys_generic.c:807 > > > > #18 0xffffffff80bc54f2 in sys_ioctl (td=3D3D0xfffffe0422ef8560, u= > ap=3D3D0=3D > > > xfffffe0422ef8960) at /usr/src/sys/kern/sys_generic.c:715 > > > > #19 0xffffffff81049398 in syscallenter (td=3D3D) a= > t /usr=3D > > > /src/sys/amd64/amd64/../../kern/subr_syscall.c:190 > > > > #20 amd64_syscall (td=3D3D0xfffffe0422ef8560, traced=3D3D0) at /u= > sr/src/s=3D > > > ys/amd64/amd64/trap.c:1199 > > [...] > > > > The backtrace looks different though it certainly smells like PR/271945. > > > > I've had similar to PR/271945 panics on an amd64 with a mirrored zpool wi= > th > > four vdevs running poudriere with AMD64 jails. My other amd64 with a > > mirrored zpool with two vdevs using i386 jails has no such issue. All oth= > er > > workloads are unaffected. > > > > On the affected machine running poudriere bulk with -J N:1 circumvents th= > e > > issue. So far. There were two openzfs cherry-picks this morning. I intend > > to try them against a full bulk build later today. > > > > > > -- > > Cheers, > > Cy Schubert > > FreeBSD UNIX: Web: https://FreeBSD.org > > NTP: Web: https://nwtime.org > > > > e^(i*pi)+1=3D0 > > > > From nobody Fri Aug 11 03:32:51 2023 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 4RMTrv6QKwz4m6Y2 for ; Fri, 11 Aug 2023 03:33:03 +0000 (UTC) (envelope-from kevin.bowling@kev009.com) Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0: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 4RMTrv4sQLz4Q0w for ; Fri, 11 Aug 2023 03:33:03 +0000 (UTC) (envelope-from kevin.bowling@kev009.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ot1-x32d.google.com with SMTP id 46e09a7af769-6bca857accbso1454667a34.0 for ; Thu, 10 Aug 2023 20:33:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kev009.com; s=google; t=1691724782; x=1692329582; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=YkE9yQjZhDpfgVc2U517Q296S99Fx0L+uB+Kj1GJKT4=; b=q0eNGSiG3lBYqsjhnW+3hkCpoEqKA6B5/nY5GfPhq4EJYPAC/Ivp4N+sqIm8pe7brE 3XX/s2DvAFp1DK82entUcX+hzryX6n4y4rXbCewqgwmmc6qBhcozYVGzamq6VeFpbrJY WYBzzsD1eImGrpgOuY4+O2wH3p0uo9A5tlSec= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691724782; x=1692329582; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=YkE9yQjZhDpfgVc2U517Q296S99Fx0L+uB+Kj1GJKT4=; b=cvnJp2FntvymhwnAEBwvwGb7eCl0lE6SiYeumRFC55Hsu/84mRDqUErMmE2uxcgSLB BlsaPNNPHg/sn+wiXOwiS1uTQQQm5Ehaqbjhw/DhFB+stUtOxV7oWsvW8Gh1OPIGQjew Mamtafcf6HdwqAbneogU4QL0/6bnoiPOKNxX6HPNLZjc5HROlq5NRoPxOGBlmVMYudWw AWxiqP28WmoUx6Or4g2sHgAlV2UvLwNt+7fxSus5oFj/sYzfgzv4+WVooMTDALLSm8s1 C4qnBThPuWnCSFPnZ3dr5hCsmTIYBeoBkBtpSLQ6Px1yeY6ugLMXA3uuN+mbYufifijE ndFg== X-Gm-Message-State: AOJu0YwxsRKfgDNbFJ2lcCv438QibT7QYQ2RTVibmGaNQl1xm7/sZTnO XT+qvEkWEt/zYsL7NrPgOnh3hUAHeBZwG2tXWGnJKQ== X-Google-Smtp-Source: AGHT+IHxyyucuw3BYazqcIDHVy2wty/rL1oGJL5aTQPxA5wODFI72FrYJ8q68T7Ob8Jb9Y0xSj+RDbG/bc04M0HS10E= X-Received: by 2002:a05:6870:5b9b:b0:1bb:68ce:382c with SMTP id em27-20020a0568705b9b00b001bb68ce382cmr730924oab.8.1691724782486; Thu, 10 Aug 2023 20:33:02 -0700 (PDT) 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: <86leeltqcb.fsf@ltc.des.no> <20230810133745.D0EC0178@slippy.cwsent.com> <20230810233312.0E10AF4@slippy.cwsent.com> In-Reply-To: <20230810233312.0E10AF4@slippy.cwsent.com> From: Kevin Bowling Date: Thu, 10 Aug 2023 20:32:51 -0700 Message-ID: Subject: Re: ZFS deadlock in 14 To: Cy Schubert Cc: =?UTF-8?Q?Dag=2DErling_Sm=C3=B8rgrav?= , current@freebsd.org Content-Type: multipart/alternative; boundary="000000000000b7db4b06029d5ea5" X-Rspamd-Queue-Id: 4RMTrv4sQLz4Q0w X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] --000000000000b7db4b06029d5ea5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Spoke too soon still seeing zfs lockups under heavy poudriere workload after the MFVs. Regression time matches what has been reported here. On Thu, Aug 10, 2023 at 4:33 PM Cy Schubert wrote: > I haven't experienced any problems (yet) either. > > > -- > Cheers, > Cy Schubert > FreeBSD UNIX: Web: https://FreeBSD.org > NTP: Web: https://nwtime.org > > e^(i*pi)+1=3D0 > > > In message > om> > , Kevin Bowling writes: > > The two MFVs on head have improved/fixed stability with poudriere for > > me 48 core bare metal. > > > > On Thu, Aug 10, 2023 at 6:37=3DE2=3D80=3DAFAM Cy Schubert > > com> wrote: > > > > > > In message > > l.c > > > om> > > > , Kevin Bowling writes: > > > > Possibly > https://github.com/openzfs/zfs/commit/2cb992a99ccadb78d97049b4=3D > > 0bd4=3D3D > > > > 42eb4fdc549d > > > > > > > > On Tue, Aug 8, 2023 at 10:08=3D3DE2=3D3D80=3D3DAFAM Dag-Erling > Sm=3D3DC3=3D3DB8rg=3D > > rav > > > sd.org> wrote: > > > > > > > > > > At some point between 42d088299c (4 May) and f0c9703301 (26 June)= , > a > > > > > deadlock was introduced in ZFS. It is still present as of > 9c2823bae9=3D > > (4 > > > > > August) and is 100% reproducable just by starting poudriere bulk > in a > > > > > 16-core VM and waiting a few hours until deadlkres kicks in. In > the > > > > > latest instance, deadlkres complained about a bash process: > > > > > > > > > > #0 sched_switch (td=3D3D3Dtd@entry=3D3D3D0xfffffe02fb1d8000, > flags=3D > > =3D3D3Dflags@e=3D3D > > > > ntry=3D3D3D259) at /usr/src/sys/kern/sched_ule.c:2299 > > > > > #1 0xffffffff80b5a0a3 in mi_switch (flags=3D3D3Dflags@entry > =3D3D3D25=3D > > 9) at /u=3D3D > > > > sr/src/sys/kern/kern_synch.c:550 > > > > > #2 0xffffffff80babcb4 in sleepq_switch > (wchan=3D3D3D0xfffff818543a=3D > > 9e70, =3D3D > > > > pri=3D3D3D64) at /usr/src/sys/kern/subr_sleepqueue.c:609 > > > > > #3 0xffffffff80babb8c in sleepq_wait > (wchan=3D3D3D, p=3D > > ri=3D3D3D<=3D3D > > > > unavailable>) at /usr/src/sys/kern/subr_sleepqueue.c:660 > > > > > #4 0xffffffff80b1c1b0 in sleeplk (lk=3D3D3Dlk@entry > =3D3D3D0xfffff818=3D > > 543a9e70=3D3D > > > > , flags=3D3D3Dflags@entry=3D3D3D2121728, ilk=3D3D3Dilk@entry=3D3D3D= 0x0, > wmesg=3D > > =3D3D3Dwmesg@entry=3D3D > > > > =3D3D3D0xffffffff8222a054 "zfs", pri=3D3D3D, pri@ent= ry > =3D3D3D6=3D > > 4, timo=3D3D3D=3D3D > > > > timo@entry=3D3D3D6, queue=3D3D3D1) at /usr/src/sys/kern/kern_lock.c= :310 > > > > > #5 0xffffffff80b1a23f in lockmgr_slock_hard > (lk=3D3D3D0xfffff81854=3D > > 3a9e70=3D3D > > > > , flags=3D3D3D2121728, ilk=3D3D3D, > file=3D3D3D0xffffffff812544=3D > > fb "/usr/s=3D3D > > > > rc/sys/kern/vfs_subr.c", line=3D3D3D3057, lwa=3D3D3D0x0) at > /usr/src/sys/ke=3D > > rn/kern_=3D3D > > > > lock.c:705 > > > > > #6 0xffffffff80c59ec3 in VOP_LOCK1 > (vp=3D3D3D0xfffff818543a9e00, f=3D > > lags=3D3D > > > > =3D3D3D2105344, file=3D3D3D0xffffffff812544fb > "/usr/src/sys/kern/vfs_subr.c=3D > > ", line=3D3D > > > > =3D3D3D3057) at ./vnode_if.h:1120 > > > > > #7 _vn_lock (vp=3D3D3Dvp@entry=3D3D3D0xfffff818543a9e00, > flags=3D3D3D2=3D > > 105344, fi=3D3D > > > > le=3D3D3D, line=3D3D3D, line@entry=3D3D3D= 3057) > at /=3D > > usr/src/sy=3D3D > > > > s/kern/vfs_vnops.c:1815 > > > > > #8 0xffffffff80c4173d in vget_finish > (vp=3D3D3D0xfffff818543a9e00,=3D > > flags=3D3D > > > > =3D3D3D, vs=3D3D3Dvs@entry=3D3D3DVGET_USECOUNT) at > /usr/src/sys/=3D > > kern/vfs_s=3D3D > > > > ubr.c:3057 > > > > > #9 0xffffffff80c1c9b7 in cache_lookup (dvp=3D3D3Ddvp@entry > =3D3D3D0xf=3D > > ffff802c=3D3D > > > > d02ac40, vpp=3D3D3Dvpp@entry=3D3D3D0xfffffe046b20ac30, cnp=3D3D3Dcn= p@entry > =3D3D=3D > > 3D0xfffffe04=3D3D > > > > 6b20ac58, tsp=3D3D3Dtsp@entry=3D3D3D0x0, ticksp=3D3D3Dticksp@entry= =3D3D3D0x0) > a=3D > > t /usr/src/s=3D3D > > > > ys/kern/vfs_cache.c:2086 > > > > > #10 0xffffffff80c2150c in vfs_cache_lookup (ap=3D3D3D out=3D > > >) at =3D3D > > > > /usr/src/sys/kern/vfs_cache.c:3068 > > > > > #11 0xffffffff80c32c37 in VOP_LOOKUP > (dvp=3D3D3D0xfffff802cd02ac40,=3D > > vpp=3D3D > > > > =3D3D3D0xfffffe046b20ac30, cnp=3D3D3D0xfffffe046b20ac58) at > ./vnode_if.h:69 > > > > > #12 vfs_lookup (ndp=3D3D3Dndp@entry=3D3D3D0xfffffe046b20abd8)= at > /usr=3D > > /src/sys=3D3D > > > > /kern/vfs_lookup.c:1266 > > > > > #13 0xffffffff80c31ce1 in namei (ndp=3D3D3Dndp@entry > =3D3D3D0xfffffe04=3D > > 6b20abd8=3D3D > > > > ) at /usr/src/sys/kern/vfs_lookup.c:689 > > > > > #14 0xffffffff80c52090 in kern_statat > (td=3D3D3D0xfffffe02fb1d8000,=3D > > flag=3D3D > > > > =3D3D3D, fd=3D3D3D-100, path=3D3D3D0xa75b480e070 Canno=3D > > t access m=3D3D > > > > emory at address 0xa75b480e070>, pathseg=3D3D3Dpathseg@entry > =3D3D3DUIO_USER=3D > > SPACE, s=3D3D > > > > bp=3D3D3Dsbp@entry=3D3D3D0xfffffe046b20ad18) > > > > > at /usr/src/sys/kern/vfs_syscalls.c:2441 > > > > > #15 0xffffffff80c52797 in sys_fstatat (td=3D3D3D= , > uap=3D > > =3D3D3D0xff=3D3D > > > > fffe02fb1d8400) at /usr/src/sys/kern/vfs_syscalls.c:2419 > > > > > #16 0xffffffff81049398 in syscallenter (td=3D3D3D out>) a=3D > > t /usr=3D3D > > > > /src/sys/amd64/amd64/../../kern/subr_syscall.c:190 > > > > > #17 amd64_syscall (td=3D3D3D0xfffffe02fb1d8000, traced=3D3D3D= 0) at > /u=3D > > sr/src/s=3D3D > > > > ys/amd64/amd64/trap.c:1199 > > > > > #18 > > > > > > > > > > The lock it is trying to acquire in frame 5 belongs to another ba= sh > > > > > process which is in the process of creating a fifo: > > > > > > > > > > #0 sched_switch (td=3D3D3Dtd@entry=3D3D3D0xfffffe046acd8e40, > flags=3D > > =3D3D3Dflags@e=3D3D > > > > ntry=3D3D3D259) at /usr/src/sys/kern/sched_ule.c:2299 > > > > > #1 0xffffffff80b5a0a3 in mi_switch (flags=3D3D3Dflags@entry > =3D3D3D25=3D > > 9) at /u=3D3D > > > > sr/src/sys/kern/kern_synch.c:550 > > > > > #2 0xffffffff80babcb4 in sleepq_switch > (wchan=3D3D3D0xfffff8018acb=3D > > f154, =3D3D > > > > pri=3D3D3D87) at /usr/src/sys/kern/subr_sleepqueue.c:609 > > > > > #3 0xffffffff80babb8c in sleepq_wait > (wchan=3D3D3D, p=3D > > ri=3D3D3D<=3D3D > > > > unavailable>) at /usr/src/sys/kern/subr_sleepqueue.c:660 > > > > > #4 0xffffffff80b59606 in _sleep (ident=3D3D3Dident@entry > =3D3D3D0xfff=3D > > ff8018ac=3D3D > > > > bf154, lock=3D3D3Dlock@entry=3D3D3D0xfffff8018acbf120, > priority=3D3D3Dpriorit=3D > > y@entry=3D3D3D=3D3D > > > > 87, wmesg=3D3D3D0xffffffff8223af0e "zfs teardown inactive", > sbt=3D3D3Dsbt@e=3D > > ntry=3D3D3D0=3D3D > > > > , pr=3D3D3Dpr@entry=3D3D3D0, flags=3D3D3D256) > > > > > at /usr/src/sys/kern/kern_synch.c:225 > > > > > #5 0xffffffff80b45dc0 in rms_rlock_fallback > (rms=3D3D3D0xfffff8018=3D > > acbf12=3D3D > > > > 0) at /usr/src/sys/kern/kern_rmlock.c:1015 > > > > > #6 0xffffffff80b45c93 in rms_rlock (rms=3D3D3D, > rms@e=3D > > ntry=3D3D > > > > =3D3D3D0xfffff8018acbf120) at /usr/src/sys/kern/kern_rmlock.c:1036 > > > > > #7 0xffffffff81fb147b in zfs_freebsd_reclaim > (ap=3D3D3D > out>) =3D3D > > > > at > /usr/src/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vnops_os.c:51=3D > > 64 > > > > > #8 0xffffffff8111d245 in VOP_RECLAIM_APV > (vop=3D3D3D0xffffffff822e=3D > > 71a0 <=3D3D > > > > zfs_vnodeops>, a=3D3D3Da@entry=3D3D3D0xfffffe0410f1c9c8) at > vnode_if.c:2180 > > > > > #9 0xffffffff80c43569 in VOP_RECLAIM > (vp=3D3D3D0xfffff802cdbaca80)=3D > > at ./=3D3D > > > > vnode_if.h:1084 > > > > > #10 vgonel (vp=3D3D3Dvp@entry=3D3D3D0xfffff802cdbaca80) at > /usr/src/s=3D > > ys/kern/=3D3D > > > > vfs_subr.c:4143 > > > > > #11 0xffffffff80c3ef61 in vtryrecycle > (vp=3D3D3D0xfffff802cdbaca80)=3D > > at /u=3D3D > > > > sr/src/sys/kern/vfs_subr.c:1693 > > > > > #12 vnlru_free_impl (count=3D3D3Dcount@entry=3D3D3D1, > mnt_op=3D3D3Dmnt_=3D > > op@entry=3D3D > > > > =3D3D3D0x0, mvp=3D3D3D0xfffff8010864da00) at > /usr/src/sys/kern/vfs_subr.c:1=3D > > 344 > > > > > #13 0xfffff =C3=A3=C2=B5=C2=B6=E2=80=93, fff80c49553 in vn= lru_free_locked > (count=3D3D3D1) at /usr=3D > > /src/s=3D3D > > > > ys/kern/vfs_subr.c:1357 > > > > > #14 vn_alloc_hard (mp=3D3D3Dmp@entry=3D3D3D0x0) at > /usr/src/sys/kern/=3D > > vfs_subr=3D3D > > > > .c:1744 > > > > > #15 0xffffffff80c3f6f0 in vn_alloc (mp=3D3D3D0x0) at > /usr/src/sys/a=3D > > md64/i=3D3D > > > > nclude/atomic.h:375 > > > > > #16 getnewvnode_reserve () at /usr/src/sys/kern/vfs_subr.c:18= 88 > > > > > #17 0xffffffff81faa072 in zfs_create > (dzp=3D3D3D0xfffff812200261d0,=3D > > name=3D3D > > > > =3D3D3D0xfffff8011b8ac805 "sh-np.yPbxoo", vap=3D3D3D0xfffffe0410f1c= c20, > exc=3D > > l=3D3D3D > > > imized out>, mode=3D3D3D, zpp=3D3D3Dzpp@entry > =3D3D3D0xfffffe04=3D > > 10f1cbc8, =3D3D > > > > cr=3D3D3D0xfffff80140fb1100, flag=3D3D3D, vsecp=3D3D= 3D0x0, > mnt=3D > > _ns=3D3D3D0x0) > > > > > at > /usr/src/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vno=3D > > ps_o=3D3D > > > > s.c:1146 > > > > > #18 0xffffffff81faea57 in zfs_freebsd_create > (ap=3D3D3D0xfffffe0410=3D > > f1cda0=3D3D > > > > ) at > /usr/src/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vnops_os.c:=3D > > 4618 > > > > > #19 0xffffffff8111aa9a in VOP_MKNOD_APV > (vop=3D3D3D0xffffffff822e71=3D > > a0 > > > s_vnodeops>, a=3D3D3Da@entry=3D3D3D0xfffffe0410f1cda0) at vnode_if.= c:372 > > > > > #20 0xffffffff80c50207 in VOP_MKNOD (dvp=3D3D3D, > cnp=3D > > =3D3D3D0xfff=3D3D > > > > ffe0410f1cd50, vap=3D3D3D0xfffffe0410f1cc20, vpp=3D3D3D) > at =3D > > ./vnode_=3D3D > > > > if.h:188 > > > > > #21 kern_mkfifoat (td=3D3D3D0xfffffe046acd8e40, fd=3D3D3D-100= , > path=3D > > =3D3D3D0x12772=3D3D > > > > f073500 , > pathse=3D > > g=3D3D3D=3D3D > > > > UIO_USERSPACE, mode=3D3D3D) at > /usr/src/sys/kern/vfs_sysca=3D > > lls.c:=3D3D > > > > 1492 > > > > > #22 0xffffffff81049398 in syscallenter (td=3D3D3D out>) a=3D > > t /usr=3D3D > > > > /src/sys/amd64/amd64/../../kern/subr_syscall.c:190 > > > > > #23 amd64_ =3DE6=3D90=3DAC=3DEE=3D8A=3D80 syscall > (td=3D3D3D0xfffffe046acd8e=3D > > 40, traced=3D3D3D0) at /usr/src/s=3D3D > > > > ys/amd64/amd64/trap.c:1199 > > > > > #24 > > > > > > > > > > Frame 7 is trying to acquire the ZFS teardown inactive lock, whic= h > is > > > > > held by a process which is performing a ZFS rollback and is > waiting f=3D > > or > > > > > the transaction to sync: > > > > > > > > > > #0 sched_switch (td=3D3D3Dtd@entry=3D3D3D0xfffffe0422ef8560, > flags=3D > > =3D3D3Dflags@e=3D3D > > > > ntry=3D3D3D259) at /usr/src/sys/kern/sched_ule.c:2299 > > > > > #1 0xffffffff80b5a0a3 in mi_switch (flags=3D3D3Dflags@entry > =3D3D3D25=3D > > 9) at /u=3D3D > > > > sr/src/sys/kern/kern_synch.c:550 > > > > > #2 0xffffffff80babcb4 in sleepq_switch > (wchan=3D3D3D0xfffff8011b83=3D > > d540, =3D3D > > > > pri=3D3D3D0) at /usr/src/sys/kern/subr_sleepqueue.c:609 > > > > > #3 0xffffffff80babb8c in sleepq_wait > (wchan=3D3D3D, w=3D > > chan@e=3D3D > > > > ntry=3D3D3D0xfffff8011b83d540, pri=3D3D3D, pri@entry= =3D3D3D0) > at=3D > > /usr/src/=3D3D > > > > sys/kern/subr_sleepqueue.c:660 > > > > > #4 0xffffffff80ad7f75 in _cv_wait (cvp=3D3D3Dcvp@entry > =3D3D3D0xfffff=3D > > 8011b83d=3D3D > > > > 540, lock=3D3D3Dlock@entry=3D3D3D0xfffff8011b83d4d0) at > /usr/src/sys/kern/k=3D > > ern_cond=3D3D > > > > var.c:146 > > > > > #5 0xffffffff820b42fb in txg_wait_synced_impl (dp=3D3D3Ddp@e= ntry > =3D > > =3D3D3D0xfff=3D3D > > > > ff8011b83d000, txg=3D3D3D8585097, wait_sig=3D3D3Dwait_sig@entry=3D3= D3D0) > at /=3D > > usr/src/sy=3D3D > > > > s/contrib/openzfs/module/zfs/txg.c:726 > > > > > #6 0xffffffff820b3cab in txg_wait_synced > (dp=3D3D3D, =3D > > dp@ent=3D3D > > > > ry=3D3D3D0xfffff8011b83d000, txg=3D3D3D) at > /usr/src/sys/contr=3D > > ib/openz=3D3D > > > > fs/module/zfs/txg.c:736 > > > > > #7 0xffffffff8206d5b5 in dsl_sync_task_common > (pool=3D3D3Dpool@ent=3D > > ry=3D3D3D0=3D3D > > > > xfffffe0401d15000 "zroot/poudriere/jails/13amd64-default-ref/15", > check=3D > > func=3D3D > > > > =3D3D3D, syncfunc=3D3D3D0xffffffff8203fbc0 > > back_syn=3D3D > > > > c>, sigfunc=3D3D3Dsigfunc@entry=3D3D3D0x0, arg=3D3D3Darg@entry > =3D3D3D0xfffffe02=3D > > fb827a90, > > > > > blocks_modified=3D3D3Dblocks_modified@entry=3D3D3D1, > space_check=3D > > =3D3D3DZFS_SP=3D3D > > > > ACE_CHECK_RESERVED, early=3D3D3D0) at > /usr/src/sys/contrib/openzfs/module=3D > > /zfs/d=3D3D > > > > sl_synctask.c:93 > > > > > #8 0xffffffff8206d3c7 in dsl_sync_task > (pool=3D3D3D, =3D > > pool@e=3D3D > > > > ntry=3D3D3D0xfffffe0401d15000 > "zroot/poudriere/jails/13amd64-default-ref/=3D > > 15", c=3D3D > > > > heckfunc=3D3D3D, syncfunc=3D3D3D, > arg=3D3D3D > lable>, ar=3D3D > > > > g@entry=3D3D3D0xfffffe02fb827a90, blocks_modified=3D3D3D, > > > > > blocks_modified@entry=3D3D3D1, > space_check=3D3D3D, s=3D > > pace_che=3D3D > > > > ck@entry=3D3D3DZFS_SPACE_CHECK_RESERVED) at > /usr/src/sys/contrib/openzfs/=3D > > module=3D3D > > > > /zfs/dsl_synctask.c:132 > > > > > #9 0xffffffff8204075b in dsl_dataset_rollback > (fsname=3D3D3D > ilable=3D3D > > > > >, fsname@entry=3D3D3D0xfffffe0401d15000 > "zroot/poudriere/jails/13amd64-d=3D > > efault=3D3D > > > > -ref/15", tosnap=3D3D3D, owner=3D3D3D= , > result=3D > > =3D3D3Dresul=3D3D > > > > t@entry=3D3D3D0xfffff81c826a9ea0) > > > > > at > /usr/src/sys/contrib/openzfs/module/zfs/dsl_dataset.c:3261 > > > > > #10 0xffffffff82168dd9 in zfs_ioc_rollback > (fsname=3D3D3D0xfffffe04=3D > > 01d150=3D3D > > > > 00 "zroot/poudriere/jails/13amd64-default-ref/15", fsname@entry > =3D3D3D > ror re=3D3D > > > > ading variable: value is not available>, innvl=3D3D3D, > innvl=3D > > @entry=3D3D > > > > =3D3D3D, > > > > > outnvl=3D3D3D0xfffff81c826a9ea0, outnvl@entry=3D3D3D readin=3D > > g variab=3D3D > > > > le: value is not available>) at > /usr/src/sys/contrib/openzfs/module/zfs=3D > > /zfs=3D3D > > > > _ioctl.c:4405 > > > > > #11 0xffffffff82164522 in zfsdev_ioctl_common > (vecnum=3D3D3Dvecnum@=3D > > entry=3D3D > > > > =3D3D3D25, zc=3D3D3Dzc@entry=3D3D3D0xfffffe0401d15000, flag=3D3D3Df= lag@entry > =3D3D=3D > > 3D0) at /usr/s=3D3D > > > > rc/sys/contrib/openzfs/module/zfs/zfs_ioctl.c:7798 > > > > > #12 0xffffffff81f97fca in zfsdev_ioctl (dev=3D3D3D out>, =3D > > zcmd=3D3D > > > > =3D3D3D, zcmd@entry=3D3D3D is no=3D > > t availa=3D3D > > > > ble>, arg=3D3D3D0xfffffe02fb827d50 "\017", arg@entry=3D3D3D reading v=3D > > ariable:=3D3D > > > > value is not available>, flag=3D3D3D, > td=3D3D3D > ut>) > > > > > at > /usr/src/sys/contrib/openzfs/module/os/freebsd/zfs/kmod_co=3D > > re.c=3D3D > > > > :168 > > > > > #13 0xffffffff809d6212 in devfs_ioctl > (ap=3D3D3D0xfffffe02fb827c50)=3D > > at /u=3D3D > > > > sr/src/sys/fs/devfs/devfs_vnops.c:935 > > > > > #14 0xffffffff80c585f2 in vn_ioctl (fp=3D3D3D0xfffff8052cdd80= f0, > co=3D > > m=3D3D3D > > > ptimized out>, data=3D3D3D0xfffffe02fb827d50, > active_cred=3D3D3D0xfffff8012=3D > > 2ab1e00,=3D3D > > > > td=3D3D3D) at /usr/src/sys/kern/vfs_vnops.c:1704 > > > > > #15 0xffffffff809d68ee in devfs_ioctl_f (fp=3D3D3D, > fp=3D > > @entry=3D3D > > > > =3D3D3D, > com=3D3D3D > able>, c=3D3D > > > > om@entry=3D3D3D, > data=3D3D3=3D > > D > > > lable>, data@entry=3D3D3D available>=3D > > , > > > > > cred=3D3D3D, cred@entry=3D3D3D variabl=3D > > e: value=3D3D > > > > is not available>, td=3D3D3D, td@entry=3D3D3D reading v=3D > > ariable:=3D3D > > > > value is not available>) at /usr/src/sys/fs/devfs/devfs_vnops.c:86= 6 > > > > > #16 0xffffffff80bc57e6 in fo_ioctl (fp=3D3D3D0xfffff8052cdd80= f0, > co=3D > > m=3D3D3D32=3D3D > > > > 22821401, data=3D3D3D, active_cred=3D3D3D= , > td=3D3D3=3D > > D0xfffffe0=3D3D > > > > 422ef8560) at /usr/src/sys/sys/file.h:367 > > > > > #17 kern_ioctl (td=3D3D3Dtd@entry=3D3D3D0xfffffe0422ef8560, > fd=3D3D3D4,=3D > > com=3D3D3Dcom=3D3D > > > > @entry=3D3D3D3222821401, data=3D3D3D, data@entry > =3D3D3D0xfffffe0=3D > > 2fb827d50 =3D3D > > > > "\017") at /usr/src/sys/kern/sys_generic.c:807 > > > > > #18 0xffffffff80bc54f2 in sys_ioctl > (td=3D3D3D0xfffffe0422ef8560, u=3D > > ap=3D3D3D0=3D3D > > > > xfffffe0422ef8960) at /usr/src/sys/kern/sys_generic.c:715 > > > > > #19 0xffffffff81049398 in syscallenter (td=3D3D3D out>) a=3D > > t /usr=3D3D > > > > /src/sys/amd64/amd64/../../kern/subr_syscall.c:190 > > > > > #20 amd64_syscall (td=3D3D3D0xfffffe0422ef8560, traced=3D3D3D= 0) at > /u=3D > > sr/src/s=3D3D > > > > ys/amd64/amd64/trap.c:1199 > > > [...] > > > > > > The backtrace looks different though it certainly smells like > PR/271945. > > > > > > I've had similar to PR/271945 panics on an amd64 with a mirrored zpoo= l > wi=3D > > th > > > four vdevs running poudriere with AMD64 jails. My other amd64 with a > > > mirrored zpool with two vdevs using i386 jails has no such issue. All > oth=3D > > er > > > workloads are unaffected. > > > > > > On the affected machine running poudriere bulk with -J N:1 circumvent= s > th=3D > > e > > > issue. So far. There were two openzfs cherry-picks this morning. I > intend > > > to try them against a full bulk build later today. > > > > > > > > > -- > > > Cheers, > > > Cy Schubert > > > FreeBSD UNIX: Web: https://FreeBSD.org > > > NTP: Web: https://nwtime.org > > > > > > e^(i*pi)+1=3D3D0 > > > > > > > > > --000000000000b7db4b06029d5ea5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Spoke too soon still seeing zfs lockups under heavy poudr= iere workload after the MFVs.=C2=A0 Regression time matches what has been r= eported here.

On Thu, Aug 10, 2023 at 4:33 PM Cy Schubert <Cy.Schubert@cschubert.com> wro= te:
I haven't experienced any problems (yet) = either.


--
Cheers,
Cy Schubert <Cy.Schubert@cschubert.com>
FreeBSD UNIX:=C2=A0 <cy@FreeBSD.org>=C2=A0 =C2=A0Web:=C2=A0 https://FreeB= SD.org
NTP:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<cy@nwtime.org>=C2=A0 =C2=A0 Web:=C2=A0 https://nwt= ime.org

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 e^(i*pi)+1=3D0


In message <CAK7dMtDJQtaai3_6VjEkwVwW5JN6e8v=3DkKTOPffp371xb=3DORUg@mail= .gmail.c
om>
, Kevin Bowling writes:
> The two MFVs on head have improved/fixed stability with poudriere for<= br> > me 48 core bare metal.
>
> On Thu, Aug 10, 2023 at 6:37=3DE2=3D80=3DAFAM Cy Schubert <Cy.Schub= ert@cschubert.=3D
> com> wrote:
> >
> > In message <CAK7dMtDJeuf8rjWbsNEZABUfeqpjUyCHzuOL9AAhKk93sy+PK= g@mail.gmai=3D
> l.c
> > om>
> > , Kevin Bowling writes:
> > > Possibly https://git= hub.com/openzfs/zfs/commit/2cb992a99ccadb78d97049b4=3D
> 0bd4=3D3D
> > > 42eb4fdc549d
> > >
> > > On Tue, Aug 8, 2023 at 10:08=3D3DE2=3D3D80=3D3DAFAM Dag-Erli= ng Sm=3D3DC3=3D3DB8rg=3D
> rav <des@freeb=3D3D
> > > sd.org> wrote:
> > > >
> > > > At some point between 42d088299c (4 May) and f0c9703301= (26 June), a
> > > > deadlock was introduced in ZFS.=C2=A0 It is still prese= nt as of 9c2823bae9=3D
>=C2=A0 (4
> > > > August) and is 100% reproducable just by starting poudr= iere bulk in a
> > > > 16-core VM and waiting a few hours until deadlkres kick= s in.=C2=A0 In the
> > > > latest instance, deadlkres complained about a bash proc= ess:
> > > >
> > > >=C2=A0 =C2=A0 =C2=A0#0=C2=A0 sched_switch (td=3D3D3Dtd@e= ntry=3D3D3D0xfffffe02fb1d8000, flags=3D
> =3D3D3Dflags@e=3D3D
> > > ntry=3D3D3D259) at /usr/src/sys/kern/sched_ule.c:2299
> > > >=C2=A0 =C2=A0 =C2=A0#1=C2=A0 0xffffffff80b5a0a3 in mi_sw= itch (flags=3D3D3Dflags@entry=3D3D3D25=3D
> 9) at /u=3D3D
> > > sr/src/sys/kern/kern_synch.c:550
> > > >=C2=A0 =C2=A0 =C2=A0#2=C2=A0 0xffffffff80babcb4 in sleep= q_switch (wchan=3D3D3D0xfffff818543a=3D
> 9e70, =3D3D
> > > pri=3D3D3D64) at /usr/src/sys/kern/subr_sleepqueue.c:609
> > > >=C2=A0 =C2=A0 =C2=A0#3=C2=A0 0xffffffff80babb8c in sleep= q_wait (wchan=3D3D3D<unavailable>, p=3D
> ri=3D3D3D<=3D3D
> > > unavailable>) at /usr/src/sys/kern/subr_sleepqueue.c:660<= br> > > > >=C2=A0 =C2=A0 =C2=A0#4=C2=A0 0xffffffff80b1c1b0 in sleep= lk (lk=3D3D3Dlk@entry=3D3D3D0xfffff818=3D
> 543a9e70=3D3D
> > > , flags=3D3D3Dflags@entry=3D3D3D2121728, ilk=3D3D3Dilk@entry= =3D3D3D0x0, wmesg=3D
> =3D3D3Dwmesg@entry=3D3D
> > > =3D3D3D0xffffffff8222a054 "zfs", pri=3D3D3D<opt= imized out>, pri@entry=3D3D3D6=3D
> 4, timo=3D3D3D=3D3D
> > > timo@entry=3D3D3D6, queue=3D3D3D1) at /usr/src/sys/kern/kern= _lock.c:310
> > > >=C2=A0 =C2=A0 =C2=A0#5=C2=A0 0xffffffff80b1a23f in lockm= gr_slock_hard (lk=3D3D3D0xfffff81854=3D
> 3a9e70=3D3D
> > > , flags=3D3D3D2121728, ilk=3D3D3D<optimized out>, file= =3D3D3D0xffffffff812544=3D
> fb "/usr/s=3D3D
> > > rc/sys/kern/vfs_subr.c", line=3D3D3D3057, lwa=3D3D3D0x0= ) at /usr/src/sys/ke=3D
> rn/kern_=3D3D
> > > lock.c:705
> > > >=C2=A0 =C2=A0 =C2=A0#6=C2=A0 0xffffffff80c59ec3 in VOP_L= OCK1 (vp=3D3D3D0xfffff818543a9e00, f=3D
> lags=3D3D
> > > =3D3D3D2105344, file=3D3D3D0xffffffff812544fb "/usr/src= /sys/kern/vfs_subr.c=3D
> ", line=3D3D
> > > =3D3D3D3057) at ./vnode_if.h:1120
> > > >=C2=A0 =C2=A0 =C2=A0#7=C2=A0 _vn_lock (vp=3D3D3Dvp@entry= =3D3D3D0xfffff818543a9e00, flags=3D3D3D2=3D
> 105344, fi=3D3D
> > > le=3D3D3D<unavailable>, line=3D3D3D<unavailable>= , line@entry=3D3D3D3057) at /=3D
> usr/src/sy=3D3D
> > > s/kern/vfs_vnops.c:1815
> > > >=C2=A0 =C2=A0 =C2=A0#8=C2=A0 0xffffffff80c4173d in vget_= finish (vp=3D3D3D0xfffff818543a9e00,=3D
>=C2=A0 flags=3D3D
> > > =3D3D3D<unavailable>, vs=3D3D3Dvs@entry=3D3D3DVGET_USE= COUNT) at /usr/src/sys/=3D
> kern/vfs_s=3D3D
> > > ubr.c:3057
> > > >=C2=A0 =C2=A0 =C2=A0#9=C2=A0 0xffffffff80c1c9b7 in cache= _lookup (dvp=3D3D3Ddvp@entry=3D3D3D0xf=3D
> ffff802c=3D3D
> > > d02ac40, vpp=3D3D3Dvpp@entry=3D3D3D0xfffffe046b20ac30, cnp= =3D3D3Dcnp@entry=3D3D=3D
> 3D0xfffffe04=3D3D
> > > 6b20ac58, tsp=3D3D3Dtsp@entry=3D3D3D0x0, ticksp=3D3D3Dticksp= @entry=3D3D3D0x0) a=3D
> t /usr/src/s=3D3D
> > > ys/kern/vfs_cache.c:2086
> > > >=C2=A0 =C2=A0 =C2=A0#10 0xffffffff80c2150c in vfs_cache_= lookup (ap=3D3D3D<optimized out=3D
> >) at =3D3D
> > > /usr/src/sys/kern/vfs_cache.c:3068
> > > >=C2=A0 =C2=A0 =C2=A0#11 0xffffffff80c32c37 in VOP_LOOKUP= (dvp=3D3D3D0xfffff802cd02ac40,=3D
>=C2=A0 vpp=3D3D
> > > =3D3D3D0xfffffe046b20ac30, cnp=3D3D3D0xfffffe046b20ac58) at = ./vnode_if.h:69
> > > >=C2=A0 =C2=A0 =C2=A0#12 vfs_lookup (ndp=3D3D3Dndp@entry= =3D3D3D0xfffffe046b20abd8) at /usr=3D
> /src/sys=3D3D
> > > /kern/vfs_lookup.c:1266
> > > >=C2=A0 =C2=A0 =C2=A0#13 0xffffffff80c31ce1 in namei (ndp= =3D3D3Dndp@entry=3D3D3D0xfffffe04=3D
> 6b20abd8=3D3D
> > > ) at /usr/src/sys/kern/vfs_lookup.c:689
> > > >=C2=A0 =C2=A0 =C2=A0#14 0xffffffff80c52090 in kern_stata= t (td=3D3D3D0xfffffe02fb1d8000,=3D
>=C2=A0 flag=3D3D
> > > =3D3D3D<optimized out>, fd=3D3D3D-100, path=3D3D3D0xa7= 5b480e070 <error: Canno=3D
> t access m=3D3D
> > > emory at address 0xa75b480e070>, pathseg=3D3D3Dpathseg@en= try=3D3D3DUIO_USER=3D
> SPACE, s=3D3D
> > > bp=3D3D3Dsbp@entry=3D3D3D0xfffffe046b20ad18)
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0at /usr/src/sys/kern/v= fs_syscalls.c:2441
> > > >=C2=A0 =C2=A0 =C2=A0#15 0xffffffff80c52797 in sys_fstata= t (td=3D3D3D<unavailable>, uap=3D
> =3D3D3D0xff=3D3D
> > > fffe02fb1d8400) at /usr/src/sys/kern/vfs_syscalls.c:2419
> > > >=C2=A0 =C2=A0 =C2=A0#16 0xffffffff81049398 in syscallent= er (td=3D3D3D<optimized out>) a=3D
> t /usr=3D3D
> > > /src/sys/amd64/amd64/../../kern/subr_syscall.c:190
> > > >=C2=A0 =C2=A0 =C2=A0#17 amd64_syscall (td=3D3D3D0xfffffe= 02fb1d8000, traced=3D3D3D0) at /u=3D
> sr/src/s=3D3D
> > > ys/amd64/amd64/trap.c:1199
> > > >=C2=A0 =C2=A0 =C2=A0#18 <signal handler called> > > > >
> > > > The lock it is trying to acquire in frame 5 belongs to = another bash
> > > > process which is in the process of creating a fifo:
> > > >
> > > >=C2=A0 =C2=A0 =C2=A0#0=C2=A0 sched_switch (td=3D3D3Dtd@e= ntry=3D3D3D0xfffffe046acd8e40, flags=3D
> =3D3D3Dflags@e=3D3D
> > > ntry=3D3D3D259) at /usr/src/sys/kern/sched_ule.c:2299
> > > >=C2=A0 =C2=A0 =C2=A0#1=C2=A0 0xffffffff80b5a0a3 in mi_sw= itch (flags=3D3D3Dflags@entry=3D3D3D25=3D
> 9) at /u=3D3D
> > > sr/src/sys/kern/kern_synch.c:550
> > > >=C2=A0 =C2=A0 =C2=A0#2=C2=A0 0xffffffff80babcb4 in sleep= q_switch (wchan=3D3D3D0xfffff8018acb=3D
> f154, =3D3D
> > > pri=3D3D3D87) at /usr/src/sys/kern/subr_sleepqueue.c:609
> > > >=C2=A0 =C2=A0 =C2=A0#3=C2=A0 0xffffffff80babb8c in sleep= q_wait (wchan=3D3D3D<unavailable>, p=3D
> ri=3D3D3D<=3D3D
> > > unavailable>) at /usr/src/sys/kern/subr_sleepqueue.c:660<= br> > > > >=C2=A0 =C2=A0 =C2=A0#4=C2=A0 0xffffffff80b59606 in _slee= p (ident=3D3D3Dident@entry=3D3D3D0xfff=3D
> ff8018ac=3D3D
> > > bf154, lock=3D3D3Dlock@entry=3D3D3D0xfffff8018acbf120, prior= ity=3D3D3Dpriorit=3D
> y@entry=3D3D3D=3D3D
> > > 87, wmesg=3D3D3D0xffffffff8223af0e "zfs teardown inacti= ve", sbt=3D3D3Dsbt@e=3D
> ntry=3D3D3D0=3D3D
> > > , pr=3D3D3Dpr@entry=3D3D3D0, flags=3D3D3D256)
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0at /usr/src/sys/kern/k= ern_synch.c:225
> > > >=C2=A0 =C2=A0 =C2=A0#5=C2=A0 0xffffffff80b45dc0 in rms_r= lock_fallback (rms=3D3D3D0xfffff8018=3D
> acbf12=3D3D
> > > 0) at /usr/src/sys/kern/kern_rmlock.c:1015
> > > >=C2=A0 =C2=A0 =C2=A0#6=C2=A0 0xffffffff80b45c93 in rms_r= lock (rms=3D3D3D<unavailable>, rms@e=3D
> ntry=3D3D
> > > =3D3D3D0xfffff8018acbf120) at /usr/src/sys/kern/kern_rmlock.= c:1036
> > > >=C2=A0 =C2=A0 =C2=A0#7=C2=A0 0xffffffff81fb147b in zfs_f= reebsd_reclaim (ap=3D3D3D<optimized =3D
> out>) =3D3D
> > > at /usr/src/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vn= ops_os.c:51=3D
> 64
> > > >=C2=A0 =C2=A0 =C2=A0#8=C2=A0 0xffffffff8111d245 in VOP_R= ECLAIM_APV (vop=3D3D3D0xffffffff822e=3D
> 71a0 <=3D3D
> > > zfs_vnodeops>, a=3D3D3Da@entry=3D3D3D0xfffffe0410f1c9c8) = at vnode_if.c:2180
> > > >=C2=A0 =C2=A0 =C2=A0#9=C2=A0 0xffffffff80c43569 in VOP_R= ECLAIM (vp=3D3D3D0xfffff802cdbaca80)=3D
>=C2=A0 at ./=3D3D
> > > vnode_if.h:1084
> > > >=C2=A0 =C2=A0 =C2=A0#10 vgonel (vp=3D3D3Dvp@entry=3D3D3D= 0xfffff802cdbaca80) at /usr/src/s=3D
> ys/kern/=3D3D
> > > vfs_subr.c:4143
> > > >=C2=A0 =C2=A0 =C2=A0#11 0xffffffff80c3ef61 in vtryrecycl= e (vp=3D3D3D0xfffff802cdbaca80)=3D
>=C2=A0 at /u=3D3D
> > > sr/src/sys/kern/vfs_subr.c:1693
> > > >=C2=A0 =C2=A0 =C2=A0#12 vnlru_free_impl (count=3D3D3Dcou= nt@entry=3D3D3D1, mnt_op=3D3D3Dmnt_=3D
> op@entry=3D3D
> > > =3D3D3D0x0, mvp=3D3D3D0xfffff8010864da00) at /usr/src/sys/ke= rn/vfs_subr.c:1=3D
> 344
> > > >=C2=A0 =C2=A0 =C2=A0#13 0xfffff =C3=A3=C2=B5=C2=B6=E2=80= =93,=C2=A0 =C2=A0 fff80c49553 in vnlru_free_locked (count=3D3D3D1) at /usr= =3D
> /src/s=3D3D
> > > ys/kern/vfs_subr.c:1357
> > > >=C2=A0 =C2=A0 =C2=A0#14 vn_alloc_hard (mp=3D3D3Dmp@entry= =3D3D3D0x0) at /usr/src/sys/kern/=3D
> vfs_subr=3D3D
> > > .c:1744
> > > >=C2=A0 =C2=A0 =C2=A0#15 0xffffffff80c3f6f0 in vn_alloc (= mp=3D3D3D0x0) at /usr/src/sys/a=3D
> md64/i=3D3D
> > > nclude/atomic.h:375
> > > >=C2=A0 =C2=A0 =C2=A0#16 getnewvnode_reserve () at /usr/s= rc/sys/kern/vfs_subr.c:1888
> > > >=C2=A0 =C2=A0 =C2=A0#17 0xffffffff81faa072 in zfs_create= (dzp=3D3D3D0xfffff812200261d0,=3D
>=C2=A0 name=3D3D
> > > =3D3D3D0xfffff8011b8ac805 "sh-np.yPbxoo", vap=3D3D= 3D0xfffffe0410f1cc20, exc=3D
> l=3D3D3D<opt=3D3D
> > > imized out>, mode=3D3D3D<optimized out>, zpp=3D3D3D= zpp@entry=3D3D3D0xfffffe04=3D
> 10f1cbc8, =3D3D
> > > cr=3D3D3D0xfffff80140fb1100, flag=3D3D3D<optimized out>= ;, vsecp=3D3D3D0x0, mnt=3D
> _ns=3D3D3D0x0)
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0at /usr/src/sys/contri= b/openzfs/module/os/freebsd/zfs/zfs_vno=3D
> ps_o=3D3D
> > > s.c:1146
> > > >=C2=A0 =C2=A0 =C2=A0#18 0xffffffff81faea57 in zfs_freebs= d_create (ap=3D3D3D0xfffffe0410=3D
> f1cda0=3D3D
> > > ) at /usr/src/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_= vnops_os.c:=3D
> 4618
> > > >=C2=A0 =C2=A0 =C2=A0#19 0xffffffff8111aa9a in VOP_MKNOD_= APV (vop=3D3D3D0xffffffff822e71=3D
> a0 <zf=3D3D
> > > s_vnodeops>, a=3D3D3Da@entry=3D3D3D0xfffffe0410f1cda0) at= vnode_if.c:372
> > > >=C2=A0 =C2=A0 =C2=A0#20 0xffffffff80c50207 in VOP_MKNOD = (dvp=3D3D3D<unavailable>, cnp=3D
> =3D3D3D0xfff=3D3D
> > > ffe0410f1cd50, vap=3D3D3D0xfffffe0410f1cc20, vpp=3D3D3D<o= ptimized out>) at =3D
> ./vnode_=3D3D
> > > if.h:188
> > > >=C2=A0 =C2=A0 =C2=A0#21 kern_mkfifoat (td=3D3D3D0xfffffe= 046acd8e40, fd=3D3D3D-100, path=3D
> =3D3D3D0x12772=3D3D
> > > f073500 <error: Cannot access memory at address 0x12772f0= 73500>, pathse=3D
> g=3D3D3D=3D3D
> > > UIO_USERSPACE, mode=3D3D3D<optimized out>) at /usr/src= /sys/kern/vfs_sysca=3D
> lls.c:=3D3D
> > > 1492
> > > >=C2=A0 =C2=A0 =C2=A0#22 0xffffffff81049398 in syscallent= er (td=3D3D3D<optimized out>) a=3D
> t /usr=3D3D
> > > /src/sys/amd64/amd64/../../kern/subr_syscall.c:190
> > > >=C2=A0 =C2=A0 =C2=A0#23 amd64_=C2=A0 =C2=A0 =3DE6=3D90= =3DAC=3DEE=3D8A=3D80 syscall (td=3D3D3D0xfffffe046acd8e=3D
> 40, traced=3D3D3D0) at /usr/src/s=3D3D
> > > ys/amd64/amd64/trap.c:1199
> > > >=C2=A0 =C2=A0 =C2=A0#24 <signal handler called> > > > >
> > > > Frame 7 is trying to acquire the ZFS teardown inactive = lock, which is
> > > > held by a process which is performing a ZFS rollback an= d is waiting f=3D
> or
> > > > the transaction to sync:
> > > >
> > > >=C2=A0 =C2=A0 =C2=A0#0=C2=A0 sched_switch (td=3D3D3Dtd@e= ntry=3D3D3D0xfffffe0422ef8560, flags=3D
> =3D3D3Dflags@e=3D3D
> > > ntry=3D3D3D259) at /usr/src/sys/kern/sched_ule.c:2299
> > > >=C2=A0 =C2=A0 =C2=A0#1=C2=A0 0xffffffff80b5a0a3 in mi_sw= itch (flags=3D3D3Dflags@entry=3D3D3D25=3D
> 9) at /u=3D3D
> > > sr/src/sys/kern/kern_synch.c:550
> > > >=C2=A0 =C2=A0 =C2=A0#2=C2=A0 0xffffffff80babcb4 in sleep= q_switch (wchan=3D3D3D0xfffff8011b83=3D
> d540, =3D3D
> > > pri=3D3D3D0) at /usr/src/sys/kern/subr_sleepqueue.c:609
> > > >=C2=A0 =C2=A0 =C2=A0#3=C2=A0 0xffffffff80babb8c in sleep= q_wait (wchan=3D3D3D<unavailable>, w=3D
> chan@e=3D3D
> > > ntry=3D3D3D0xfffff8011b83d540, pri=3D3D3D<unavailable>= , pri@entry=3D3D3D0) at=3D
>=C2=A0 /usr/src/=3D3D
> > > sys/kern/subr_sleepqueue.c:660
> > > >=C2=A0 =C2=A0 =C2=A0#4=C2=A0 0xffffffff80ad7f75 in _cv_w= ait (cvp=3D3D3Dcvp@entry=3D3D3D0xfffff=3D
> 8011b83d=3D3D
> > > 540, lock=3D3D3Dlock@entry=3D3D3D0xfffff8011b83d4d0) at /usr= /src/sys/kern/k=3D
> ern_cond=3D3D
> > > var.c:146
> > > >=C2=A0 =C2=A0 =C2=A0#5=C2=A0 0xffffffff820b42fb in txg_w= ait_synced_impl (dp=3D3D3Ddp@entry=3D
> =3D3D3D0xfff=3D3D
> > > ff8011b83d000, txg=3D3D3D8585097, wait_sig=3D3D3Dwait_sig@en= try=3D3D3D0) at /=3D
> usr/src/sy=3D3D
> > > s/contrib/openzfs/module/zfs/txg.c:726
> > > >=C2=A0 =C2=A0 =C2=A0#6=C2=A0 0xffffffff820b3cab in txg_w= ait_synced (dp=3D3D3D<unavailable>, =3D
> dp@ent=3D3D
> > > ry=3D3D3D0xfffff8011b83d000, txg=3D3D3D<unavailable>) = at /usr/src/sys/contr=3D
> ib/openz=3D3D
> > > fs/module/zfs/txg.c:736
> > > >=C2=A0 =C2=A0 =C2=A0#7=C2=A0 0xffffffff8206d5b5 in dsl_s= ync_task_common (pool=3D3D3Dpool@ent=3D
> ry=3D3D3D0=3D3D
> > > xfffffe0401d15000 "zroot/poudriere/jails/13amd64-defaul= t-ref/15", check=3D
> func=3D3D
> > > =3D3D3D<optimized out>, syncfunc=3D3D3D0xffffffff8203f= bc0 <dsl_dataset_roll=3D
> back_syn=3D3D
> > > c>, sigfunc=3D3D3Dsigfunc@entry=3D3D3D0x0, arg=3D3D3Darg@= entry=3D3D3D0xfffffe02=3D
> fb827a90,
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0blocks_modified=3D3D3D= blocks_modified@entry=3D3D3D1, space_check=3D
> =3D3D3DZFS_SP=3D3D
> > > ACE_CHECK_RESERVED, early=3D3D3D0) at /usr/src/sys/contrib/o= penzfs/module=3D
> /zfs/d=3D3D
> > > sl_synctask.c:93
> > > >=C2=A0 =C2=A0 =C2=A0#8=C2=A0 0xffffffff8206d3c7 in dsl_s= ync_task (pool=3D3D3D<unavailable>, =3D
> pool@e=3D3D
> > > ntry=3D3D3D0xfffffe0401d15000 "zroot/poudriere/jails/13= amd64-default-ref/=3D
> 15", c=3D3D
> > > heckfunc=3D3D3D<unavailable>, syncfunc=3D3D3D<unava= ilable>, arg=3D3D3D<unavai=3D
> lable>, ar=3D3D
> > > g@entry=3D3D3D0xfffffe02fb827a90, blocks_modified=3D3D3D<= unavailable>,
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0blocks_modified@entry= =3D3D3D1, space_check=3D3D3D<unavailable>, s=3D
> pace_che=3D3D
> > > ck@entry=3D3D3DZFS_SPACE_CHECK_RESERVED) at /usr/src/sys/con= trib/openzfs/=3D
> module=3D3D
> > > /zfs/dsl_synctask.c:132
> > > >=C2=A0 =C2=A0 =C2=A0#9=C2=A0 0xffffffff8204075b in dsl_d= ataset_rollback (fsname=3D3D3D<unava=3D
> ilable=3D3D
> > > >, fsname@entry=3D3D3D0xfffffe0401d15000 "zroot/poud= riere/jails/13amd64-d=3D
> efault=3D3D
> > > -ref/15", tosnap=3D3D3D<optimized out>, owner=3D3= D3D<optimized out>, result=3D
> =3D3D3Dresul=3D3D
> > > t@entry=3D3D3D0xfffff81c826a9ea0)
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0at /usr/src/sys/contri= b/openzfs/module/zfs/dsl_dataset.c:3261
> > > >=C2=A0 =C2=A0 =C2=A0#10 0xffffffff82168dd9 in zfs_ioc_ro= llback (fsname=3D3D3D0xfffffe04=3D
> 01d150=3D3D
> > > 00 "zroot/poudriere/jails/13amd64-default-ref/15",= fsname@entry=3D3D3D<er=3D
> ror re=3D3D
> > > ading variable: value is not available>, innvl=3D3D3D<= unavailable>, innvl=3D
> @entry=3D3D
> > > =3D3D3D<error reading variable: value is not available>= ;,
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0outnvl=3D3D3D0xfffff81= c826a9ea0, outnvl@entry=3D3D3D<error readin=3D
> g variab=3D3D
> > > le: value is not available>) at /usr/src/sys/contrib/open= zfs/module/zfs=3D
> /zfs=3D3D
> > > _ioctl.c:4405
> > > >=C2=A0 =C2=A0 =C2=A0#11 0xffffffff82164522 in zfsdev_ioc= tl_common (vecnum=3D3D3Dvecnum@=3D
> entry=3D3D
> > > =3D3D3D25, zc=3D3D3Dzc@entry=3D3D3D0xfffffe0401d15000, flag= =3D3D3Dflag@entry=3D3D=3D
> 3D0) at /usr/s=3D3D
> > > rc/sys/contrib/openzfs/module/zfs/zfs_ioctl.c:7798
> > > >=C2=A0 =C2=A0 =C2=A0#12 0xffffffff81f97fca in zfsdev_ioc= tl (dev=3D3D3D<optimized out>, =3D
> zcmd=3D3D
> > > =3D3D3D<unavailable>, zcmd@entry=3D3D3D<error readi= ng variable: value is no=3D
> t availa=3D3D
> > > ble>, arg=3D3D3D0xfffffe02fb827d50 "\017", arg@= entry=3D3D3D<error reading v=3D
> ariable:=3D3D
> > >=C2=A0 value is not available>, flag=3D3D3D<optimized o= ut>, td=3D3D3D<optimized o=3D
> ut>)
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0at /usr/src/sys/contri= b/openzfs/module/os/freebsd/zfs/kmod_co=3D
> re.c=3D3D
> > > :168
> > > >=C2=A0 =C2=A0 =C2=A0#13 0xffffffff809d6212 in devfs_ioct= l (ap=3D3D3D0xfffffe02fb827c50)=3D
>=C2=A0 at /u=3D3D
> > > sr/src/sys/fs/devfs/devfs_vnops.c:935
> > > >=C2=A0 =C2=A0 =C2=A0#14 0xffffffff80c585f2 in vn_ioctl (= fp=3D3D3D0xfffff8052cdd80f0, co=3D
> m=3D3D3D<o=3D3D
> > > ptimized out>, data=3D3D3D0xfffffe02fb827d50, active_cred= =3D3D3D0xfffff8012=3D
> 2ab1e00,=3D3D
> > >=C2=A0 td=3D3D3D<unavailable>) at /usr/src/sys/kern/vfs= _vnops.c:1704
> > > >=C2=A0 =C2=A0 =C2=A0#15 0xffffffff809d68ee in devfs_ioct= l_f (fp=3D3D3D<unavailable>, fp=3D
> @entry=3D3D
> > > =3D3D3D<error reading variable: value is not available>= ;, com=3D3D3D<unavail=3D
> able>, c=3D3D
> > > om@entry=3D3D3D<error reading variable: value is not avai= lable>, data=3D3D3=3D
> D<unavai=3D3D
> > > lable>, data@entry=3D3D3D<error reading variable: valu= e is not available>=3D
> ,
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0cred=3D3D3D<unavail= able>, cred@entry=3D3D3D<error reading variabl=3D
> e: value=3D3D
> > >=C2=A0 is not available>, td=3D3D3D<unavailable>, td= @entry=3D3D3D<error reading v=3D
> ariable:=3D3D
> > >=C2=A0 value is not available>) at /usr/src/sys/fs/devfs/d= evfs_vnops.c:866
> > > >=C2=A0 =C2=A0 =C2=A0#16 0xffffffff80bc57e6 in fo_ioctl (= fp=3D3D3D0xfffff8052cdd80f0, co=3D
> m=3D3D3D32=3D3D
> > > 22821401, data=3D3D3D<unavailable>, active_cred=3D3D3D= <unavailable>, td=3D3D3=3D
> D0xfffffe0=3D3D
> > > 422ef8560) at /usr/src/sys/sys/file.h:367
> > > >=C2=A0 =C2=A0 =C2=A0#17 kern_ioctl (td=3D3D3Dtd@entry=3D= 3D3D0xfffffe0422ef8560, fd=3D3D3D4,=3D
>=C2=A0 com=3D3D3Dcom=3D3D
> > > @entry=3D3D3D3222821401, data=3D3D3D<unavailable>, dat= a@entry=3D3D3D0xfffffe0=3D
> 2fb827d50 =3D3D
> > > "\017") at /usr/src/sys/kern/sys_generic.c:807
> > > >=C2=A0 =C2=A0 =C2=A0#18 0xffffffff80bc54f2 in sys_ioctl = (td=3D3D3D0xfffffe0422ef8560, u=3D
> ap=3D3D3D0=3D3D
> > > xfffffe0422ef8960) at /usr/src/sys/kern/sys_generic.c:715 > > > >=C2=A0 =C2=A0 =C2=A0#19 0xffffffff81049398 in syscallent= er (td=3D3D3D<optimized out>) a=3D
> t /usr=3D3D
> > > /src/sys/amd64/amd64/../../kern/subr_syscall.c:190
> > > >=C2=A0 =C2=A0 =C2=A0#20 amd64_syscall (td=3D3D3D0xfffffe= 0422ef8560, traced=3D3D3D0) at /u=3D
> sr/src/s=3D3D
> > > ys/amd64/amd64/trap.c:1199
> > [...]
> >
> > The backtrace looks different though it certainly smells like PR/= 271945.
> >
> > I've had similar to PR/271945 panics on an amd64 with a mirro= red zpool wi=3D
> th
> > four vdevs running poudriere with AMD64 jails. My other amd64 wit= h a
> > mirrored zpool with two vdevs using i386 jails has no such issue.= All oth=3D
> er
> > workloads are unaffected.
> >
> > On the affected machine running poudriere bulk with -J N:1 circum= vents th=3D
> e
> > issue. So far. There were two openzfs cherry-picks this morning. = I intend
> > to try them against a full bulk build later today.
> >
> >
> > --
> > Cheers,
> > Cy Schubert <Cy.Schubert@cschubert.com>
> > FreeBSD UNIX:=C2=A0 <cy@FreeBSD.org>=C2=A0 =C2=A0Web:=C2=A0= https= ://FreeBSD.org
> > NTP:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<cy@nwtime.org>=C2=A0 =C2=A0 Web:= =C2=A0 = https://nwtime.org
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0e^(i*pi)+1=3D3D0
> >
> >


--000000000000b7db4b06029d5ea5-- From nobody Fri Aug 11 05:37:43 2023 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 4RMXcm0lr9z4mH5k for ; Fri, 11 Aug 2023 05:37:44 +0000 (UTC) (envelope-from pstef@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) 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 4RMXcm0CYGz4c5p; Fri, 11 Aug 2023 05:37:44 +0000 (UTC) (envelope-from pstef@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1691732264; 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=0NhaRUfjZ5WVX9dS5OWPi10XwuTwaGIvFZKWYOA/Z8c=; b=c0sd2OHtePKjA3nEz2I0SBbozojpK7apLCJeG0AVgzxb3cJH9RF7jzD8nCJTSfetxIxkz7 MkOdpJyu8oHPBRfQ6LzgnIBoCWw48lFYVNvJcAOboS8bHvST120O5AfuO8ihar/INWTXTp SFPHzmvxtCio1UV3B7XwM7cA4njr2y16aoLhkpH25JUAJ1763U4GayTFpPsPYn2w7mYGVF WjdSKKDzCBAS8s1tatmVHDnujBKaP6d8unq8SVmH/DPcwRkHv1oLmu8ZhjUpylv/sbayvO ykI/xO15olo6VRQaLhvYe3Vbrya52Sh5ZPKJka8uZAEowHB9fK6EPSP4or4y1Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1691732264; 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=0NhaRUfjZ5WVX9dS5OWPi10XwuTwaGIvFZKWYOA/Z8c=; b=iefOCCU4Es6YlExHr3WP1BepCfA1cKEw4E7iRO0guH8RVZHqQrNaL2GOeJUje8VxQubau2 8Xz5QQTt4/jFRezjnDZbmDnXSPfe+omjbro/leCNvHAiG/E4BY7RV9VhL/VVhYgEouTAx0 BVlUAHsN09Wnkv//Rm/LE4TG3469ES7etf//4CrZNfh/aT0FFy9ywdau3jwNJ0lXwuPjoH Bxly9SQRcQ2jJfilvP2m9mN3IVJ1yHf7dbupiH6fNb73NDxbdMcSQyHxXbNQ4NgepnRO22 5yKgHvp7VRJzESUi1acIVTjsZsEX+dQLGQsLpFETNwFAoCJY62/M1lI3oyJZ2Q== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1691732264; a=rsa-sha256; cv=none; b=O8HHMRPGH1StP58B2Vvb8dq0WaChNOygA+kzU5ASCWzDHOtqxvveY4il5JM18opxNpXuq/ t4jBsVj+AjbO/7qKj4gT+oQW6b08EwBLC6CHUGS4gHfFTf4EtX/DcWnMGmlRjOMexawzKq aswIH8dR+bTuMA8fe8YHkpZEgK1W4R9nFbk8pqeK9cmRMd0AHztN1UyHEC4DLtZ/CD0sgT X7wTeaugHOU7Y2UXLCgNAwej4z7pcYVU2OIbi1TsjV7zicPcXs9o5vc2u/ovuImtBpQVRO 3zjd5rI6sr9Er71wwWn0V/hKfr+QeDEmIdeZ8TrLZLPWfKO8UpJXCw+r0LIxNA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: by freefall.freebsd.org (Postfix, from userid 1403) id CE4B816E7E; Fri, 11 Aug 2023 05:37:43 +0000 (UTC) Date: Fri, 11 Aug 2023 05:37:43 +0000 From: "Piotr P. Stefaniak" To: Jamie Landeg-Jones Cc: freebsd-current@freebsd.org Subject: Re: ps(1) bugs and problems Message-ID: References: <202307282307.36SN7b7v026284@donotpassgo.dyslexicfish.net> 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 Content-Disposition: inline In-Reply-To: I thought about this more and the change I proposed in https://reviews.freebsd.org/D41231 seems unnecessarily complicated, regardless of which characters will be chosen to denote going up and down the process tree. ps -D'^$' suggests there are possibly more characters to use and maybe even some kind of DSL is available. So a simpler option is to keep the new aspect of -d (that it traverses the tree down, even if ps is given a list of PIDs) and add a -D that would work the same, but the other direction. Piotr From nobody Fri Aug 11 05:54:54 2023 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 4RMY0g6Qhkz4mJ8V for ; Fri, 11 Aug 2023 05:54:59 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) (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 4RMY0f24wVz4fV4 for ; Fri, 11 Aug 2023 05:54:58 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20221208 header.b="bnO9b/hK"; spf=pass (mx1.freebsd.org: domain of grahamperrin@gmail.com designates 2a00:1450:4864:20::62b as permitted sender) smtp.mailfrom=grahamperrin@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ej1-x62b.google.com with SMTP id a640c23a62f3a-99c47ef365cso233944866b.0 for ; Thu, 10 Aug 2023 22:54:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691733296; x=1692338096; h=in-reply-to:subject:from:references:to:content-language:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to; bh=gjrmEUeO1zVXitdHLurEW4/F515qvxWUhO7do0I2QmY=; b=bnO9b/hKmABv3EOnKhVWBToTvvqyXhnRlgas1aOtFEzc49/w/E2ecgKchJA4jn+XWG /gC0KfvqLw0gyjQIrOHWgEsUl8Ubv98sqeX4L8L9QT7s9TGF/Z0qXwMzRHlPGmIi+a19 gJUiAS/8VTIUyYg8iod54hIPwDO6IhZKXurT9jeqyJq5wKmmb63ayKml/dBExvXYMngH fNrLlxRlYCnBuEKvLuv3fpTaShx/EkTq19mfWVNJzk9ry+fIjMmQ9hbNKttD8N9UBBpV 94KZcxim8khJpWrXRj8lJdjK9JCzK4s5tEZb735FufZOpMG+zeAE+khcCkDvh1WRoyQk fyqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691733296; x=1692338096; h=in-reply-to:subject:from:references:to:content-language:user-agent :mime-version:date:message-id:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=gjrmEUeO1zVXitdHLurEW4/F515qvxWUhO7do0I2QmY=; b=kUrUVDGFcKh2JDXocLujjwDahaW+m/LY+6soePv6ScC2NaP6EZy9/ITwx1EebduNH3 GautdPYR7utZDs2OL+1QdSM5ipR2TJyv6nJXteN7i4oTYgiFWa7imEsidysyFzdMMy6B GADfm9K9slOQt4rQQG8kB3EUjLXVJVQqlOAf+e3sfy3WwzWm07nGV0U8gMDhTS5rwinK n7fjy7q27kpX572M1GqRXpsRfZjlh6BDsGU/G/W+/tRua9uGc6f8Yx1bptn2NGOORses a4ESrpOR1R89OMp9ip7fXKkFH6kwVruFSiLQtzow4SJuS/G4N2+iZd9fKg5+78/9zv83 s+pQ== X-Gm-Message-State: AOJu0Yzap8ksVg1x7Ca3aSIoEcCHfWu0DZFcN0Qt6lpPqqPLTZYeUQrQ N9xwOsM5xlBe2QbnXVSAQ/eZ4RMP/oU= X-Google-Smtp-Source: AGHT+IFol7yHXaXkDCtmlmI8KKx3HtHmxeBkR8wE0vF5vgEz7TrMpa6nL4WyAShrwtuHq3iPRbqlhg== X-Received: by 2002:a17:906:8458:b0:99c:5710:674a with SMTP id e24-20020a170906845800b0099c5710674amr900672ejy.37.1691733296134; Thu, 10 Aug 2023 22:54:56 -0700 (PDT) Received: from [192.168.1.10] (80-42-66-93.dynamic.dsl.as9105.com. [80.42.66.93]) by smtp.gmail.com with ESMTPSA id re15-20020a170906d8cf00b0099cc402d3ddsm1777065ejb.202.2023.08.10.22.54.55 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Aug 2023 22:54:55 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------6ODKJDyWc63gam6XCLf6zy6O" Message-ID: <3092d00f-0066-2dc5-5c78-0d5df6f4dad7@gmail.com> Date: Fri, 11 Aug 2023 06:54:54 +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:102.0) Gecko/20100101 Thunderbird/102.14.0 Content-Language: en-US To: freebsd-current@freebsd.org References: <86leeltqcb.fsf@ltc.des.no> <20230810133745.D0EC0178@slippy.cwsent.com> <20230810233312.0E10AF4@slippy.cwsent.com> From: Graham Perrin Subject: Re: ZFS deadlock in 14 In-Reply-To: X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_LONG(-0.99)[-0.994]; NEURAL_HAM_MEDIUM(-0.99)[-0.987]; NEURAL_HAM_SHORT(-0.52)[-0.517]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20221208]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[grahamperrin]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62b:from]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; TO_DN_NONE(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-Spamd-Bar: --- X-Rspamd-Queue-Id: 4RMY0f24wVz4fV4 This is a multi-part message in MIME format. --------------6ODKJDyWc63gam6XCLf6zy6O Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 11/08/2023 04:32, Kevin Bowling wrote: > Spoke too soon still seeing zfs lockups Kevin, do you have a log device? (ZIL) > under heavy poudriere workload … Can you tell what was building when the problem occurred? For example, qutebrowser /usr/local/poudriere/data/logs/bulk/main-default/latest/index.html – where main is my main jail, and qutebrowser is readily compatible (browsers such as Chromium and Firefox are not). --------------6ODKJDyWc63gam6XCLf6zy6O Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

On 11/08/2023 04:32, Kevin Bowling wrote:

Spoke too soon still seeing zfs lockups

Kevin, do you have a log device? (ZIL)

under heavy poudriere workload …

Can you tell what was building when the problem occurred? For example,

qutebrowser /usr/local/poudriere/data/logs/bulk/main-default/latest/index.html

– where main is my main jail, and qutebrowser is readily compatible (browsers such as Chromium and Firefox are not).



--------------6ODKJDyWc63gam6XCLf6zy6O-- From nobody Fri Aug 11 11:32:02 2023 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 4RMhTZ5Yvwz4pxKZ for ; Fri, 11 Aug 2023 11:32:02 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [IPv6:2001:19f0:7400:8808:123::1]) by mx1.freebsd.org (Postfix) with ESMTP id 4RMhTZ3ylHz3c19; Fri, 11 Aug 2023 11:32:02 +0000 (UTC) (envelope-from jamie@catflap.org) Authentication-Results: mx1.freebsd.org; none X-Catflap-Envelope-From: Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [209.250.224.51]) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id 37BBW21D064899; Fri, 11 Aug 2023 12:32:02 +0100 (BST) (envelope-from jamie@donotpassgo.dyslexicfish.net) Received: (from jamie@localhost) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id 37BBW23A064898; Fri, 11 Aug 2023 12:32:02 +0100 (BST) (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <202308111132.37BBW23A064898@donotpassgo.dyslexicfish.net> Date: Fri, 11 Aug 2023 12:32:02 +0100 Organization: Dyslexic Fish To: pstef@FreeBSD.org, jamie@catflap.org Cc: freebsd-current@FreeBSD.org Subject: Re: ps(1) bugs and problems References: <202307282307.36SN7b7v026284@donotpassgo.dyslexicfish.net> In-Reply-To: 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 [209.250.224.51]); Fri, 11 Aug 2023 12:32:02 +0100 (BST) X-Rspamd-Queue-Id: 4RMhTZ3ylHz3c19 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:20473, ipnet:2001:19f0:7400::/38, country:US] "Piotr P. Stefaniak" wrote: > I thought about this more and the change I proposed in > https://reviews.freebsd.org/D41231 seems unnecessarily complicated, > regardless of which characters will be chosen to denote going up and > down the process tree. ps -D'^$' suggests there are possibly more > characters to use and maybe even some kind of DSL is available. > > So a simpler option is to keep the new aspect of -d (that it traverses > the tree down, even if ps is given a list of PIDs) and add a -D that > would work the same, but the other direction. That is indeed cleaner, and whilst the new "-D" option would cover the particular use case I mentioned, the old sorting method with arbitary, and specific PIDS is still useful. How about reverting '-d', and adding "-D" for descending, and "-A" for ascending? Cheers, Jamie From nobody Fri Aug 11 13:27:46 2023 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 4RMl393d4nz4Tp2c for ; Fri, 11 Aug 2023 13:27:49 +0000 (UTC) (envelope-from des@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 4RMl392rQFz4LH7; Fri, 11 Aug 2023 13:27:49 +0000 (UTC) (envelope-from des@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1691760469; 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=1R8fElIGElML3kFgtRFwT6PkzfnmaMnm/b2mITHLZ8A=; b=CpiBFgy6oYYkyR1S3Ocvkp33bNM9R1K6g+jtYJtsNahgpwiD0Bu1vxmkNnTAUxObsjUiJv tkAk5LcdpRp9PKEDAhmL94CsPf3qZByMzXR5K/MJHBXvjIURAPWT2TGnSvpeDte8+hC3j1 +wjWyJ0XiQd1Bgu4Q1OOVf+AI1D1B0sfbWomYa/5qdkNSeG9GDZmtDr3ohhIDUNtUP/84Q fAWIhvTF7C9kNfdIa/vw7K9ZUrkHLkvXBA0NBV0z+KzEO0REtHLcApQ+oSOgJalBSBF1zj nvOGdLTd8vNVn8zW5qhcAFmQdCBasofB0CDkei7qF13bFwGLip6gBpzNPl4oLg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1691760469; 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=1R8fElIGElML3kFgtRFwT6PkzfnmaMnm/b2mITHLZ8A=; b=Odc6IXx0NowO7yTKH/akT/i0rqP+1RpWvoMfkV9S75YxHtxm4MrlbIdDj4jkgqxz5UOmwI /I6iiokXKFpfpuKZYZJoBb0lAFWAb61c9Msp11OMjOrHrJ7t7bCFbTuCImgXxKc66Q27NQ dOSRJDdsPb+gGn1NTFgwiaKbZ5fIlrDy6IFyIS08XPdgIPso41A8DxS5y3ISiwg8LMy9RG SbpFVDaVge3t2kETSNt12brIh73EkVAonK85TCqSFe0ne1P/o2Hr0zMAw5ML2jzloTPu6K OhRSxYsyueLUo0CBaXI2mYmzeCIe750bnceUDPpGMlBZ/0DcrTqy3o5tippLyw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1691760469; a=rsa-sha256; cv=none; b=EK7qI95dVpHNCwG23J5vISr7yXOAzxGvU1KpXIBbEqR/ObvBewDlksDRmTBdqXzHFNwqQh iFXnfTpHljMnWcjC4+stJ9Bp5NvRxiEMx/1c0hlxeF7ttanSFSgAbhUo1MF3slvSoz/5M5 tmqn6s85MsgMvhWEX9U/c8U94AZLkFq4k8YWEUkTMwncNkW10cKNZGcakQpvKOJnf6HnJz +jHayetiwQV2N+cSd5kY577aDwFi+iPNuTWr7tUz53fN2HvLmXT/RFt8vojg8QlPyG+KcI HvNKVMuICLKBLMiSkQNnNL6wXfhdI8b7kYBwIs7PlN/9GpvRMnu835Jtw/EVQA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from ltc.des.no (unknown [IPv6:2001:4647:d671:0:36e8:94ff:feca:9834]) (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) (Authenticated sender: des) by smtp.freebsd.org (Postfix) with ESMTPSA id 4RMl3910fdzywj; Fri, 11 Aug 2023 13:27:49 +0000 (UTC) (envelope-from des@freebsd.org) Received: by ltc.des.no (Postfix, from userid 1001) id DEAD8186B7; Fri, 11 Aug 2023 15:27:46 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Tomoaki AOKI Cc: David Wolfskill , freebsd-current@freebsd.org Subject: Re: Has the update procedure changed? In-Reply-To: <20230811072734.e3adac011062e849c7c3b948@dec.sakura.ne.jp> (Tomoaki AOKI's message of "Fri, 11 Aug 2023 07:27:34 +0900") References: <7A0E604D-EF40-4F10-B597-F1F076507192@gmail.com> <20230809213822.950a3c337ec86c102dcbd235@dec.sakura.ne.jp> <20230810063214.1b694140e7c284e51154fe35@dec.sakura.ne.jp> <86zg2zrnvp.fsf@ltc.des.no> <20230811072734.e3adac011062e849c7c3b948@dec.sakura.ne.jp> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (berkeley-unix) Date: Fri, 11 Aug 2023 15:27:46 +0200 Message-ID: <86o7jdso8d.fsf@ltc.des.no> 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=utf-8 Content-Transfer-Encoding: quoted-printable Tomoaki AOKI writes: > This can help new installation using release tarballs (official or > locally built) or upgrading with overwriting using said tarballs, but > how does freebsd-update? freebsd-update uses the same release process. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@FreeBSD.org From nobody Fri Aug 11 15:18:52 2023 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 4RMnWk4TLdz4TxMw for ; Fri, 11 Aug 2023 15:19:14 +0000 (UTC) (envelope-from trashcan@ellael.org) Received: from mx1.enfer-du-nord.net (mx1.enfer-du-nord.net [91.121.41.56]) (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 4RMnWj2vspz4WQB for ; Fri, 11 Aug 2023 15:19:12 +0000 (UTC) (envelope-from trashcan@ellael.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ellael.org header.s=dkim header.b=P6ZdN8kw; spf=pass (mx1.freebsd.org: domain of trashcan@ellael.org designates 91.121.41.56 as permitted sender) smtp.mailfrom=trashcan@ellael.org; dmarc=pass (policy=quarantine) header.from=ellael.org Received: from smtpclient.apple (p5b2e5c3e.dip0.t-ipconnect.de [91.46.92.62]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.enfer-du-nord.net (Postfix) with ESMTPSA id 4RMnWW0gNbzn77 for ; Fri, 11 Aug 2023 17:19:03 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ellael.org; s=dkim; t=1691767143; 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=RdIlmtOZZ9jULe7wATct7vsRvAC3lksA30bldYs/qZk=; b=P6ZdN8kwxRr5yMN7l/nKT4iy6Viuq/ccVIQiXX35ORmccrzZ9eZwnkRSM7qPwo9gSQGwWN sWk8N6/WAI5GiGjO1hAGZ9IDPENnbE75u3s5LoW1QPLYjPHjzgGfzEU2EhDC5P/hxaYoeF HQvufhOnBXay1/VJqPSQN+ZGldc5+Bay3jSlv5gh1eKjm7VQ066SH4YUvshdOHp7GsZm3G 2Gn1lsUn+g9ltyA7aIIjcqCNx7PRhewRMPELwEr45iRhdWtOAqpfBqMCnZitPrvLJKo9ZW eRHwLXhFJ6zh5oOhhsDMmajLkYKXTHQCrr8XXBfa077jJxdW2wzzsbNdL9AXzw== From: Michael Grimm 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 16.0 \(3731.700.6\)) Subject: periodic daily produces ridiculously huge report files Message-Id: <60209E13-5019-4E2C-889A-E36B5FD6DDCE@ellael.org> Date: Fri, 11 Aug 2023 17:18:52 +0200 To: freebsd-current@freebsd.org X-Mailer: Apple Mail (2.3731.700.6) X-Spamd-Result: default: False [-3.39 / 15.00]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.99)[-0.991]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[ellael.org,quarantine]; R_DKIM_ALLOW(-0.20)[ellael.org:s=dkim]; R_SPF_ALLOW(-0.20)[+ip4:91.121.41.56]; MIME_GOOD(-0.10)[text/plain]; ONCE_RECEIVED(0.10)[]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_ALL(0.00)[]; ASN(0.00)[asn:16276, ipnet:91.121.0.0/16, country:FR]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[ellael.org:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[] X-Spamd-Bar: --- X-Rspamd-Queue-Id: 4RMnWj2vspz4WQB Hi, I recently upgraded from 13-STABLE to MAIN, now at FreeBSD 14.0-ALPHA1 = amd64 1400094 #12 main-n264689-580cadd6a5f0, a custom kernel compiled = *without* IPv6 (WITHOUT_INET6=3Dyes). Ever since either upgrading to MAIN or WITHOUT_INET6=3Dyes [1] I noticed = that periodic daily still runs in the morning failing to mail = ridiculously huge report files (>=3D 90 *GB*). [1] Can't remember when this started. I believe to have found the step in periodic daily causing these huge = files, but I do not know why: 1) I used to run default daily_status_network_netstat_flags=3D"-d -W" in = /etc/periodic.conf This normally produces an output like: MWN> netstat -i -d -W -n=20 Name Mtu Network Address Ipkts = Ierrs Idrop Opkts Oerrs Coll Drop vtnet0 1490 fa:16:3e:37:a7:35 963666 = 0 0 1145053 0 0 0 vtnet0 - 1.2.3.4/32 1.2.3.4 859598 = - - 1068898 - - - vtnet0 - 10.20.30.40/32 10.20.30.40 12176 = - - 0 - - - vtnet0 - 50.60.70.80/32 50.60.70.80 0 = - - 0 - - - vtnet0 - 100.100.100.10/32 100.100.100.10 5200 = - - 0 - - - vtnet1* 1500 fa:16:3e:58:c8:c9 0 = 0 0 0 0 0 0 lo0 16384 lo0 20 = 0 0 20 0 0 0 lo0 - - - - - - - - lo0 - - - - - - - - lo0 - 127.0.0.0/8 127.0.0.1 20 = - - 20 - - - bridge0 1490 58:9c:fc:00:61:18 186483 = 0 0 173172 0 0 0 bridge0 - 10.2.2.0/24 10.2.2.254 6625 = - - 6698 - - - bridge0 - 10.2.2.199/32 10.2.2.199 5198 = - - 0 - - - bridge0 - 10.2.2.220/32 10.2.2.220 363021 = - - 0 - - - ipsec0 1400 ipsec0 852284 = 0 0 1035859 0 0 0 ipsec0 - 10.2.2.0/24 10.2.2.250 391221 = - - 941898 - - - pflog0 33152 pflog0 0 = 0 0 49185 0 0 0 epair201a 1490 02:0a:28:51:b5:0a 33154 = 0 0 32531 0 0 0 epair203a 1490 02:0b:44:a0:f4:0a 2807 = 0 0 2567 0 0 0 epair2a 1490 02:22:d3:ae:82:0a 7635 = 0 0 5435 0 0 0 epair1a 1490 02:61:a8:aa:89:0a 142474 = 0 0 132256 0 0 0 epair6a 1490 02:b4:4a:c7:dd:0a 228 = 0 0 213 0 0 0 epair5a 1490 02:ba:52:8a:6d:0a 185 = 0 0 170 0 0 0 But pretty often "netstat -i -d -W -n" produces garbage like spaces or = "0". This fills /tmp pretty fast (luckily a compressed zfs filesystem) = and my mta still tries to mail in the morning. 2) I modified /etc/periodic.conf to = daily_status_network_netstat_flags=3D"-d -W -4" This produces an output like: MWN> netstat -i -d -W -n -4=20 Name Mtu Network Address Ipkts Ierrs = Idrop Opkts Oerrs Coll Drop vtnet0 - 1.2.3.4/32 1.2.3.4 859590 - = - 1068102 - - - =20 vtnet0 - 10.20.30.40/32 10.20.30.40 11592 - = - 0 - - - vtnet0 - 50.60.70.80/32 50.60.70.80 0 - = - 0 - - - vtnet0 - 100.100.100.10/32 100.100.100.10 5192 - = - 0 - - - =20 lo0 - 127.0.0.0/8 127.0.0.1 20 - = - 20 - - - bridge0 - 10.2.2.0/24 10.2.2.254 6623 - = - 6696 - - - bridge0 - 10.2.2.199/32 10.2.2.199 5196 - = - 0 - - - bridge0 - 10.2.2.220/32 10.2.2.220 363021 - = - 0 - - - ipsec0 - 10.2.2.0/24 10.2.2.250 391221 - = - 941898 - - - This fixed my issue with periodic daily. But I would like to know, if this has to do with WITHOUT_INET6=3Dyes or = FreeBSD 14? Or something different ... Did someone of you experiences equal behaviour of "netstat -i -d -W"? Anyone with WITHOUT_INET6=3Dyes willing to test this? Regards, Michael From nobody Fri Aug 11 18:03:18 2023 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 4RMs9S0TLlz4mFYM for ; Fri, 11 Aug 2023 18:03:40 +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 4RMs9R2qF2z3JHt; Fri, 11 Aug 2023 18:03:38 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; none Received: from kalamity.joker.local (123-1-88-210.area1b.commufa.jp [123.1.88.210]) (authenticated bits=0) by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 37BI3IWm086967; Sat, 12 Aug 2023 03:03:19 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Sat, 12 Aug 2023 03:03:18 +0900 From: Tomoaki AOKI To: Dag-Erling =?UTF-8?B?U23DuHJncmF2?= Cc: David Wolfskill , freebsd-current@freebsd.org Subject: Re: Has the update procedure changed? Message-Id: <20230812030318.96872ae31c199e9934db3324@dec.sakura.ne.jp> In-Reply-To: <86o7jdso8d.fsf@ltc.des.no> References: <7A0E604D-EF40-4F10-B597-F1F076507192@gmail.com> <20230809213822.950a3c337ec86c102dcbd235@dec.sakura.ne.jp> <20230810063214.1b694140e7c284e51154fe35@dec.sakura.ne.jp> <86zg2zrnvp.fsf@ltc.des.no> <20230811072734.e3adac011062e849c7c3b948@dec.sakura.ne.jp> <86o7jdso8d.fsf@ltc.des.no> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.2) 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=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4RMs9R2qF2z3JHt X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP] On Fri, 11 Aug 2023 15:27:46 +0200 Dag-Erling Smørgrav wrote: > Tomoaki AOKI writes: > > This can help new installation using release tarballs (official or > > locally built) or upgrading with overwriting using said tarballs, but > > how does freebsd-update? > > freebsd-update uses the same release process. > > DES > -- > Dag-Erling Smørgrav - des@FreeBSD.org Ah, thanks! So just anyone running through source update like us are possibly bitten. -- Tomoaki AOKI From nobody Fri Aug 11 19:03:47 2023 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 4RMtVy4xd6z4mK8L for ; Fri, 11 Aug 2023 19:03:54 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (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 4RMtVx1Y1fz3Nv4 for ; Fri, 11 Aug 2023 19:03:53 +0000 (UTC) (envelope-from guru@unixarea.de) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of guru@unixarea.de designates 178.254.4.101 as permitted sender) smtp.mailfrom=guru@unixarea.de; dmarc=none Received: from [80.187.83.70] (helo=localhost.unixarea.de) by ms-10.1blu.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qUXQL-0000yp-FV for freebsd-current@freebsd.org; Fri, 11 Aug 2023 21:03:49 +0200 Received: from localhost.my.domain (localhost [127.0.0.1]) by localhost.unixarea.de (8.16.1/8.14.9) with ESMTPS id 37BJ3lGe004168 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Fri, 11 Aug 2023 21:03:47 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.16.1/8.14.9/Submit) id 37BJ3lxQ004167 for freebsd-current@freebsd.org; Fri, 11 Aug 2023 21:03:47 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Fri, 11 Aug 2023 21:03:47 +0200 From: Matthias Apitz To: freebsd-current@freebsd.org Subject: problem with poudriere && port ftp/curl Message-ID: Reply-To: Matthias Apitz 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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Operating-System: FreeBSD 13.0-CURRENT r368166 (amd64) X-message-flag: Mails containing HTML will not be read! Please send only plain text. X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 80.187.83.70 X-Spamd-Result: default: False [-2.23 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.997]; MID_RHS_NOT_FQDN(0.50)[]; NEURAL_HAM_SHORT(-0.44)[-0.436]; R_SPF_ALLOW(-0.20)[+ip4:178.254.4.101]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[unixarea.de]; ASN(0.00)[asn:42730, ipnet:178.254.0.0/19, country:DE]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; R_DKIM_NA(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; HAS_XOIP(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_LAST(0.00)[]; REPLYTO_EQ_FROM(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; HAS_XAW(0.00)[]; HAS_REPLYTO(0.00)[guru@unixarea.de] X-Spamd-Bar: -- X-Rspamd-Queue-Id: 4RMtVx1Y1fz3Nv4 I have the following problem with poudriere on 14-CURRENT and ports from git head: every time when I start poudriere-bulk it removes a port already compile fine (and all its dependent ports) with the message: ... [00:00:40] Sanity checking the repository [00:00:40] Checking packages for incremental rebuild needs [00:00:43] Deleting curl-8.2.1.pkg: changed options [00:00:43] Pkg: +ALTSVC -BROTLI -CARES +CA_BUNDLE +COOKIES -CURL_DEBUG -DEBUG +DICT +DOCS +EXAMPLES +FTP -GNUTLS +GOPHER -GSSAPI_BASE -GSSAPI_HEIMDAL -GSSAPI_MIT +GSSAPI_NONE +HTTP +HTTP2 -IDN +IMAP +IPV6 -LDAP -LDAPS -LIBSSH +LIBSSH2 -MQTT +NTLM +OPENSSL +POP3 +PROXY +PSL -RTMP +RTSP -SMB +SMTP +STATIC +TELNET +TFTP +THREADED_RESOLVER +TLS_SRP -WEBSOCKET -WOLFSSL -ZSTD [00:00:43] New: +ALTSVC -BROTLI -CARES +CA_BUNDLE +COOKIES -CURL_DEBUG -DEBUG +DICT +DOCS +EXAMPLES +FTP -GNUTLS +GOPHER +GSSAPI_BASE -GSSAPI_HEIMDAL -GSSAPI_MIT -GSSAPI_NONE +HTTP +HTTP2 -IDN +IMAP +IPV6 -LDAP -LDAPS -LIBSSH +LIBSSH2 -MQTT +NTLM +OPENSSL +POP3 +PROXY +PSL -RTMP +RTSP -SMB +SMTP +STATIC +TELNET +TFTP +THREADED_RESOLVER +TLS_SRP -WEBSOCKET -WOLFSSL -ZSTD The difference seems to be +/-GSSAPI_BASE and +/-GSSAPI_NONE. I have not set anything about this in the port's options or jail's make.conf. What can I do to fix this? matthias -- Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub From nobody Fri Aug 11 20:53:12 2023 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 4RMwx91Qf4z4mSGk; Fri, 11 Aug 2023 20:53:17 +0000 (UTC) (envelope-from gjb@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 4RMwx90lGZz3WD3; Fri, 11 Aug 2023 20:53:17 +0000 (UTC) (envelope-from gjb@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1691787197; 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=qFIf+ePPwnJ++XIvuVlAi+9zv8v6xpYD5l/kvbkiYME=; b=FFOwDu2cC6yQSVdgPJ9bOdZjjv6VR8sk69K96nLGPse9eQYEAWQxcgx0wsIJoxTDpkJyPj mEDbW7WsglBW/kECpqtgyhB615WZbmju998njSx9hdKqSx/UIjFYpZqAE90cmmQCVUxHbf lNZffsNjK5Y9caOccdwdW7xobsP5vtpEqXLzp1MAz7ISfzWVZnZ/eBTvIZg59MeKThKUMa OZppuDszol5TwwjFcrD8N1b8VloefaYKfuLVniIAyFP41Hn7q5n5WlgNEtygna1y8GTgp3 Yq9qFHw2SBaD8Buk5DliuUcJ9YSoklFxNnDZDJ8EL28+4RtAxAo3OmGu0fUZNg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1691787197; 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=qFIf+ePPwnJ++XIvuVlAi+9zv8v6xpYD5l/kvbkiYME=; b=w7wbTYRtWbYMKMU0O75weI2q1aWi6sKN4BYDh/juMkpqyYOQNafpovaDQO08kA7RrFHhEr wBkl2cflju87QXCTBklgdplP6KfIVyY3U82CmyRF4YVaUr6tYv3tA2NhPW+OVUDN01zFNw ePctuNXjbQpbLGnyHFKHkt/kvlH3/Vy/NC+fXG+9VLZqcSCOizQygGc6l7CyCBZDYfoXZ+ QqwrK+ZntHO8+O0ZGkYmzJA44pzTfzDgY77oVQsZx5lepIO+ZfP6pyzpzeDAeb12nrNMIh 2I1DMCcSIgEWK20cDHLY6ZF6wA/3FTOpETNIAb+FSOTOH+Kt/x2CVel70MpmWg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1691787197; a=rsa-sha256; cv=none; b=JC3KPSeejH84ttllycfkA0JCBTucL5slYJXCW98WJqvRyAeuhF14y67dwMRPi0tAN4k6Gb kE9VFPyfozdw5M6yspu/igdmOogxDVD3IG5FNLtTWDHIuSWu7v19u68hLnEYTUDIAAYZuu ChDVZwEd79J6Ea4aeHsvKme1jWllWOlTPkEjkTaIC86ZKC1UldyNpW3gDN/uLumn8hbS+Z b/nhiHOM6BtoYYON701+0fU/ZEcybYyREjRDXumN+kqHUnvFVPxcsmTRhNVLn8BU/ZwPZ0 ROBnpFGXwA4JtFqXKFWbsIFc+vgLCf2fW2MDYGHlupWZA7zJMDQ/Pi+vF+2Nsg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id AF41B187FB; Fri, 11 Aug 2023 20:53:16 +0000 (UTC) (envelope-from gjb@freebsd.org) Date: Fri, 11 Aug 2023 20:53:12 +0000 From: Glen Barber To: freebsd-snapshots@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org Cc: FreeBSD Release Engineering Team Subject: New FreeBSD snapshots available: stable/14 (ALPHA1) (20230811 136fc495615f) Message-ID: <20230811205312.GF52318@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="3siQDZowHQqNOShm" Content-Disposition: inline --3siQDZowHQqNOShm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable New FreeBSD development branch installation ISOs and virtual machine disk images have been uploaded to the FreeBSD Project mirrors. As with any development branch, the installation snapshots are not intended for use on production systems. We do, however, encourage testing on non-production systems as much as possible. Please also consider installing the sysutils/panicmail port, which can help in providing FreeBSD developers the necessary information regarding system crashes. Checksums for the installation ISOs and the VM disk images follow at the end of this email. =3D=3D=3D Installation ISOs =3D=3D=3D Installation images are available for: o 14.0-ALPHA1 amd64 GENERIC o 14.0-ALPHA1 i386 GENERIC o 14.0-ALPHA1 powerpc GENERIC o 14.0-ALPHA1 powerpc64 GENERIC64 o 14.0-ALPHA1 powerpc64le GENERIC64LE o 14.0-ALPHA1 armv6 RPI-B o 14.0-ALPHA1 armv7 GENERICSD o 14.0-ALPHA1 aarch64 GENERIC o 14.0-ALPHA1 aarch64 RPI o 14.0-ALPHA1 aarch64 PINE64 o 14.0-ALPHA1 aarch64 PINE64-LTS o 14.0-ALPHA1 aarch64 PINEBOOK o 14.0-ALPHA1 aarch64 ROCK64 o 14.0-ALPHA1 aarch64 ROCKPRO64 o 14.0-ALPHA1 riscv64 GENERIC o 14.0-ALPHA1 riscv64 GENERICSD Note regarding arm/armv{6,7} images: For convenience for those without console access to the system, a freebsd user with a password of freebsd is available by default for ssh(1) access. Additionally, the root user password is set to root, which it is strongly recommended to change the password for both users after gaining access to the system. Snapshots may be downloaded from the corresponding architecture directory from: https://download.freebsd.org/snapshots/ISO-IMAGES/ Please be patient if your local mirror has not yet caught up with the changes. Problems, bug reports, or regression reports should be reported through the Bugzilla PR system or the appropriate mailing list such as -current@ or -stable@ . =3D=3D=3D Virtual Machine Disk Images =3D=3D=3D VM disk images are available for the following architectures: o 14.0-ALPHA1 amd64 o 14.0-ALPHA1 i386 o 14.0-ALPHA1 aarch64 o 14.0-ALPHA1 riscv64 o 14.0-ALPHA1 amd64 BASIC-CI Disk images may be downloaded from the following URL (or any of the FreeBSD Project mirrors): https://download.freebsd.org/snapshots/VM-IMAGES/ Images are available in the following disk image formats: ~ RAW ~ QCOW2 (qemu) ~ VMDK (qemu, VirtualBox, VMWare) ~ VHD (qemu, xen) The partition layout for UFS is: ~ 512k - freebsd-boot GPT partition type (bootfs GPT label) ~ 1GB - freebsd-swap GPT partition type (swapfs GPT label) ~ 24GB - freebsd-ufs GPT partition type (rootfs GPT label) Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI loader file is needed for qemu-system-aarch64 to be able to boot the virtual machine images. This is provided by the emulators/qemu port. To boot the VM image, run: % qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt =20 -bios /usr/local/share/qemu/edk2-aarch64-code.fd=20 -serial telnet::4444,server -nographic=20 -drive if=3Dnone,file=3DVMDISK,id=3Dhd0=20 -device virtio-blk-device,drive=3Dhd0=20 -device virtio-net-device,netdev=3Dnet0=20 -netdev user,id=3Dnet0 Be sure to replace "VMDISK" with the path to the virtual machine image. BASIC-CI images can be found at: https://download.freebsd.org/snapshots/CI-IMAGES/ =3D=3D=3D Amazon EC2 AMI Images =3D=3D=3D FreeBSD/amd64 UFS EC2 AMIs are available in the following regions: ap-south-2 region: ami-0ee95230becf80778 ap-south-1 region: ami-03ad9777ff8bc0b6e eu-south-1 region: ami-0fdfdb9f7c3a58c46 eu-south-2 region: ami-0ebed85d055e70b39 me-central-1 region: ami-02c67cb3a99d57d57 ca-central-1 region: ami-0d0bbdaefd0c0e181 eu-central-1 region: ami-0a80119c6edde9265 eu-central-2 region: ami-0a12f1c8e051dfae9 us-west-1 region: ami-0ea4f8fce960ef2c4 us-west-2 region: ami-09f3a6925f77e203e af-south-1 region: ami-0ef9719a1228e32a5 eu-north-1 region: ami-02e6c8bc0ce909cbe eu-west-3 region: ami-0aa3da21b9907069a eu-west-2 region: ami-092c172d577027092 eu-west-1 region: ami-04cd2017e63b5ebda ap-northeast-3 region: ami-077b46cc5d1c68523 ap-northeast-2 region: ami-00aafa3de31692805 me-south-1 region: ami-011ee7fb4001bf69f ap-northeast-1 region: ami-08ff003b6ff73de93 sa-east-1 region: ami-052f0128aed100b4a ap-east-1 region: ami-05bcf396a33918e60 ap-southeast-1 region: ami-0b56d17b45366f1bf ap-southeast-2 region: ami-01b1c6fd1bb35074d ap-southeast-3 region: ami-017073fdb4ae76333 us-east-1 region: ami-029e7b689f77cce2c us-east-2 region: ami-0047bb65a2d73065f FreeBSD/amd64 ZFS EC2 AMIs are available in the following regions: ap-south-2 region: ami-0d3f563d617979348 ap-south-1 region: ami-03f77404c21fb5a25 eu-south-1 region: ami-0731187e3d49f6795 eu-south-2 region: ami-068b99a06abbe9a85 me-central-1 region: ami-0904554cdebb1ddab ca-central-1 region: ami-0e96429bf976b35cb eu-central-1 region: ami-0cb9214edc051fc88 eu-central-2 region: ami-0c4e6aad76680d64d us-west-1 region: ami-0787e6281242abf6d us-west-2 region: ami-03cefc407842a342d af-south-1 region: ami-0c68744a09255cd6f eu-north-1 region: ami-03a8c5c6c975c21fe eu-west-3 region: ami-01628f4d91cd27838 eu-west-2 region: ami-048d52773d4c5951b eu-west-1 region: ami-08509c5c80c3f76de ap-northeast-3 region: ami-0f019caa2553e9e32 ap-northeast-2 region: ami-0530b6be4cc4aacb5 me-south-1 region: ami-0da15198205cfcbb5 ap-northeast-1 region: ami-085265d27a19ac1ed sa-east-1 region: ami-088793629d946492c ap-east-1 region: ami-08fb95cb26081ad70 ap-southeast-1 region: ami-0a93baf040c66ef6f =20 ap-southeast-2 region: ami-01930838e9e02af78 ap-southeast-3 region: ami-0782f3c0b864440cb us-east-1 region: ami-05797b4ce30086ec8 us-east-2 region: ami-09d9ba200a69fdf4b These AMI IDs can be retrieved from the Systems Manager Parameter Store in each region using the keys: /aws/service/freebsd/amd64/base/ufs/14.0/ALPHA1 /aws/service/freebsd/amd64/base/zfs/14.0/ALPHA1 FreeBSD/aarch64 UFS EC2 AMIs are available in the following regions: ap-south-2 region: ami-0ad26c712ed21703e ap-south-1 region: ami-0d78067468fd0bcb6 eu-south-1 region: ami-0cd527d17120c6a90 eu-south-2 region: ami-01e65abee965e2db3 me-central-1 region: ami-0b9681861b9588a8c ca-central-1 region: ami-04d70ff4e96cbabc4 eu-central-1 region: ami-0f73415dc20c6a31b eu-central-2 region: ami-01c7c57fe8abaf3c3 us-west-1 region: ami-0d2a710906f75e8fa us-west-2 region: ami-081d8d32425e7a28b af-south-1 region: ami-020d95d6e12d5228b eu-north-1 region: ami-0a2046fc7bc924564 eu-west-3 region: ami-0e0820c7749bfb908 eu-west-2 region: ami-0cbae742029679a9b eu-west-1 region: ami-0ad7c9aad58a8ac60 ap-northeast-3 region: ami-038711def088bcc40 ap-northeast-2 region: ami-00c433eb5dfe51112 me-south-1 region: ami-05b716323f0d55a7d ap-northeast-1 region: ami-022a84a4bfb0eb57d sa-east-1 region: ami-0822c15bb844d501e ap-east-1 region: ami-07a476ee87b72b1db ap-southeast-1 region: ami-0a2b7f01594d3ddb3 ap-southeast-2 region: ami-0ebaa7495854d4149 ap-southeast-3 region: ami-0514e4d6e0b84c914 us-east-1 region: ami-0ef708c0543ef4e6d us-east-2 region: ami-0e6e30278f31e5199 FreeBSD/aarch64 ZFS EC2 AMIs are available in the following regions: ap-south-2 region: ami-017996823c96c9035 ap-south-1 region: ami-0b8ec2a97a04cf114 eu-south-1 region: ami-0a88a8c75e26a2163 eu-south-2 region: ami-06089c0a441283ec2 me-central-1 region: ami-05ab9bd2e9caa5163 ca-central-1 region: ami-05e29a10630656ec5 eu-central-1 region: ami-0bbc32820ccd9eaf3 =20 eu-central-2 region: ami-05d6f8668eccef473 us-west-1 region: ami-0423b0ea5cb89d6db us-west-2 region: ami-09be1d7239500a0a4 af-south-1 region: ami-0582848dd402096ef eu-north-1 region: ami-0618b6ec751174e99 eu-west-3 region: ami-0a872817804a19b65 eu-west-2 region: ami-0c92d5475acf1b7d3 eu-west-1 region: ami-07570666ee48d199d ap-northeast-3 region: ami-0a3f1176c4b18e6aa ap-northeast-2 region: ami-0df2f3300043f8de5 me-south-1 region: ami-055b235d5a9509fea ap-northeast-1 region: ami-00b49714687388a53 sa-east-1 region: ami-0601e5e031c1a39c6 ap-east-1 region: ami-0ab9eadc1b93ccbb8 ap-southeast-1 region: ami-0448869593edac054 ap-southeast-2 region: ami-09599cff050b820db ap-southeast-3 region: ami-062bca65e04891708 us-east-1 region: ami-02a253c3b2fe8d11c us-east-2 region: ami-04424d02986e5e8fc These AMI IDs can be retrieved from the Systems Manager Parameter Store in each region using the keys: /aws/service/freebsd/arm64/base/ufs/14.0/ALPHA1 /aws/service/freebsd/arm64/base/zfs/14.0/ALPHA1 =3D=3D=3D Vagrant Images =3D=3D=3D FreeBSD/amd64 images are available on the Hashicorp Atlas site for the VMWare Desktop and VirtualBox providers, and can be installed by running: % vagrant init freebsd/FreeBSD-14.0-ALPHA1 % vagrant up =3D=3D ISO CHECKSUMS =3D=3D o 14.0-ALPHA1 amd64 GENERIC: SHA512 (FreeBSD-14.0-ALPHA1-amd64-20230811-136fc495615f-264678-bootonly.i= so) =3D b1f5b188c1ed61bc1210ac237dbfd8baabad94fc2b6f67a7f2f16f2c592404e05be= 5aee8a28e7f9facf9ae2ae3acec4695794d99a264b80bc3cf69da5f17c6d3 SHA512 (FreeBSD-14.0-ALPHA1-amd64-20230811-136fc495615f-264678-bootonly.i= so.xz) =3D 70c4bce755511e2da2f21c9c90344ffe56accdc8a0b416956e837055072027b8= 558478dd446a7080a43aaac32887635cd4dda451158e0b3cb417ee8320e14f96 SHA512 (FreeBSD-14.0-ALPHA1-amd64-20230811-136fc495615f-264678-disc1.iso)= =3D 7b9ec31a1e497b28b9df7f97ee7f55965892c0a2a8a1f44430bbf3a82d007c90a6f94f= fc9606d41d5e5c7123111a9b879521394857015922c35fef1804d30e06 SHA512 (FreeBSD-14.0-ALPHA1-amd64-20230811-136fc495615f-264678-disc1.iso.= xz) =3D 50506b103ed71e381d5dafcb7c9f3b157325fcd933b204bbd480376b8b1581ebe53= 86ce4e07385548b02a8ce2aa0e9ce46e91184f829a9254512ddabbd42a9eb SHA512 (FreeBSD-14.0-ALPHA1-amd64-20230811-136fc495615f-264678-memstick.i= mg) =3D e4b4207f3899b1ee117fb373057433977ca2c0afab3d7a957cbca3ce39d87b815ce= b0d05e33cc7155c6d2afc1a70f317fdbac2e8c7cb20d04114c2992132f69f SHA512 (FreeBSD-14.0-ALPHA1-amd64-20230811-136fc495615f-264678-memstick.i= mg.xz) =3D 10b9b03327a7442cf9eb02756d0ab7c938a7cd26ae428fba5a6e02df447e8eb5= da7950797f9ddf239d92b8b1e35df60220a25e3a3930363d1934e9442231fe27 SHA512 (FreeBSD-14.0-ALPHA1-amd64-20230811-136fc495615f-264678-mini-memst= ick.img) =3D 69b234060e55c673da711bb9db65744c0bfe70905e75318f2b19c35cfcd0f7= 241db92bb0f353f297a3ccfde118b455dcd34095d73a8b1e3bbf28602b33e01a1e SHA512 (FreeBSD-14.0-ALPHA1-amd64-20230811-136fc495615f-264678-mini-memst= ick.img.xz) =3D e2bc79200526924d6acd7403035f66c7851f6b3b30cd91de41f73e165dd= 234619436bf68b960030f2b7b3f1a2a52d8ec393ab220aec862ba75cea5439a253c18 SHA256 (FreeBSD-14.0-ALPHA1-amd64-20230811-136fc495615f-264678-bootonly.i= so) =3D 3d58d2960154db1b3193bb1382c522d084b5585fe7ba6200eeea3cdd1d58d7ee SHA256 (FreeBSD-14.0-ALPHA1-amd64-20230811-136fc495615f-264678-bootonly.i= so.xz) =3D 8283d2d9db2a84acd22084b39b8d3188f049fba68c58a27da61ff9b48233251f SHA256 (FreeBSD-14.0-ALPHA1-amd64-20230811-136fc495615f-264678-disc1.iso)= =3D 1644c9e5eb5e6ae663b61861fc9309580e3e01e3b4074577dd58415983851174 SHA256 (FreeBSD-14.0-ALPHA1-amd64-20230811-136fc495615f-264678-disc1.iso.= xz) =3D 5f8240af8219d94bc25607b0361fea2eed4b68ec8781b7b4fab34926895a115b SHA256 (FreeBSD-14.0-ALPHA1-amd64-20230811-136fc495615f-264678-memstick.i= mg) =3D 4be626eb03834051a5e14256d11a9c83eda3333e8411e121f2d16b49063ba496 SHA256 (FreeBSD-14.0-ALPHA1-amd64-20230811-136fc495615f-264678-memstick.i= mg.xz) =3D cf676d40e480c8f7cbd3aee0a4070233d9450069f1433a5ffa870ac0a5146aeb SHA256 (FreeBSD-14.0-ALPHA1-amd64-20230811-136fc495615f-264678-mini-memst= ick.img) =3D 4ff0911a1e51b0f6073cbdeecefde68f68182856532217db006a99789b8561= 33 SHA256 (FreeBSD-14.0-ALPHA1-amd64-20230811-136fc495615f-264678-mini-memst= ick.img.xz) =3D 0badb75b7c621e9270e87232b88789432080bad7de0edb4043093aa4eb9= df6c4 o 14.0-ALPHA1 i386 GENERIC: SHA512 (FreeBSD-14.0-ALPHA1-i386-20230811-136fc495615f-264678-bootonly.is= o) =3D 9aabbf8282551b0f51b3002df2adb4b0390cd602d92508fcd948e80b7478ff66e604= 5f5d3fda15fe715a9fe42905879f085ef08ef602f728e390dd7758136065 SHA512 (FreeBSD-14.0-ALPHA1-i386-20230811-136fc495615f-264678-bootonly.is= o.xz) =3D fb278cf84ad1016af8cf344be61ca5a22a8824d0f9ec831426c2f7c07c70b734a= 5c71e5f27c2fba6a351ea6ff97e8693d6e8d0364cb2918d1f5a1bfc200ed281 SHA512 (FreeBSD-14.0-ALPHA1-i386-20230811-136fc495615f-264678-disc1.iso) = =3D b2a3dd00dd46131ebafa2a5e0c830583cef71e41dbc252aee538abb7a70f1cb1e8dd373= 45d941c62b5eb72b3ec60e9f3217f013fdd3c123f211b2c952cf7ef8b SHA512 (FreeBSD-14.0-ALPHA1-i386-20230811-136fc495615f-264678-disc1.iso.x= z) =3D 1f921d3beab0145e771d2b2392035b4ba91189271a1db5f41638cea5fa57107b0cc0= 9f119aa3465beb3fab8eb67c05fd4e5e1e9e8f97bac5508cde8dd5efe70e SHA512 (FreeBSD-14.0-ALPHA1-i386-20230811-136fc495615f-264678-memstick.im= g) =3D fd97cedb2ca0a3abaa951cbe0c1655f75aa965323090e060fa8a62ea384c1f291268= 9bb94129a77dc810eb8559330628801d1f0a15f3ada8cb7cb9e84655c2d6 SHA512 (FreeBSD-14.0-ALPHA1-i386-20230811-136fc495615f-264678-memstick.im= g.xz) =3D a17de741e9d31e552f9848ff20714be43f7b55664e0a2d38f6f9749d12d9ac7b5= 08b0315a3cd28f7939f171ac89f563cc5f7aa38903fd84e0ba7e69a3e9d7161 SHA512 (FreeBSD-14.0-ALPHA1-i386-20230811-136fc495615f-264678-mini-memsti= ck.img) =3D 80133a394656354bc24fcea273757ac3f71710cb3f8f71e65bbc44262ce542d= 0171e145281d9c96d0a7643d7ef1cfa967e5d8a9d50db49380880444c8aa05de9 SHA512 (FreeBSD-14.0-ALPHA1-i386-20230811-136fc495615f-264678-mini-memsti= ck.img.xz) =3D 44c50b3a3602b15ee044b0c8d25f115a64d777dfd2471e0f6fe42fed2c4f= b400cce35205edea47be8609908d31bce782ac3d61e519df9e1d2387ceddff9954ce SHA256 (FreeBSD-14.0-ALPHA1-i386-20230811-136fc495615f-264678-bootonly.is= o) =3D 6f6488e4c3c24f029d6cba065c752959ab0e81213ea23fcf98030b9ba129758d SHA256 (FreeBSD-14.0-ALPHA1-i386-20230811-136fc495615f-264678-bootonly.is= o.xz) =3D f4641c530df76487b325c4b7f583fd15e2a75de2209f4b5e459a3217abe21f49 SHA256 (FreeBSD-14.0-ALPHA1-i386-20230811-136fc495615f-264678-disc1.iso) = =3D f1b3e0a1b8dd67fe7f1cd029edf2ed21c45ed2d9cbff5b8b4297bd2912abaeb5 SHA256 (FreeBSD-14.0-ALPHA1-i386-20230811-136fc495615f-264678-disc1.iso.x= z) =3D 4c6f094657ebddac4c37019f841703eae0cd95adf0a014994e64b65685e17f36 SHA256 (FreeBSD-14.0-ALPHA1-i386-20230811-136fc495615f-264678-memstick.im= g) =3D 5bd512aa0f72c6762761e08f8921887ee9774a4efc1471bc1bbae1b1a4d912a2 SHA256 (FreeBSD-14.0-ALPHA1-i386-20230811-136fc495615f-264678-memstick.im= g.xz) =3D c784a834bdbfeee9302fecc053a842faed1e30710171348201eb8630aea5591d SHA256 (FreeBSD-14.0-ALPHA1-i386-20230811-136fc495615f-264678-mini-memsti= ck.img) =3D da303d81a5acccab191d4ebc28e7edc98556a6f87eea6314f042608b174f4fa9 SHA256 (FreeBSD-14.0-ALPHA1-i386-20230811-136fc495615f-264678-mini-memsti= ck.img.xz) =3D b269166ba0a51170264c3fe6cf86ee25c9b9fb2c488616e411436955f1cd= 8622 o 14.0-ALPHA1 powerpc GENERIC: SHA512 (FreeBSD-14.0-ALPHA1-powerpc-20230811-136fc495615f-264678-bootonly= =2Eiso) =3D 74c6b2db934f841a4378cac84ace9502df7cbb69ff6187bfdd81764306562a3= 9bf5efa7007b121f4e952857026497977f7afe9cbd04deb8c08ccd98ef5297083 SHA512 (FreeBSD-14.0-ALPHA1-powerpc-20230811-136fc495615f-264678-bootonly= =2Eiso.xz) =3D 82c304ce6e90fcf91254c2ca06f6de25b6097541a0619ae8977b8bfa573c= 6b1e165e639bcb357d663bb384ea44e0e1edd6e7459812dbcbc6c2874d41269a250f SHA512 (FreeBSD-14.0-ALPHA1-powerpc-20230811-136fc495615f-264678-disc1.is= o) =3D 0d8247e1f3a9e9e0ff6b454cfcd9182ce7800ae44f1dc762a623745276131e869cf0= 1aee141ff74e2fc61fc07022356ad0e3ac640b84bf179194093312763a72 SHA512 (FreeBSD-14.0-ALPHA1-powerpc-20230811-136fc495615f-264678-disc1.is= o.xz) =3D 7332541a2518684659439a7888085afb66e10c4a5793ab5d664c7462db3893cb6= 4a045aa3b73e431ef8aca698e7b841245f60b531530298b7f0b9b7391874dd2 SHA256 (FreeBSD-14.0-ALPHA1-powerpc-20230811-136fc495615f-264678-bootonly= =2Eiso) =3D ee050be66c9e2d08f0d4d580c7a6ec8fd8fed0b645a228bd06da2149e2a3fe4e SHA256 (FreeBSD-14.0-ALPHA1-powerpc-20230811-136fc495615f-264678-bootonly= =2Eiso.xz) =3D 5e1707d728b149657c340109747853b61e47c3f72b711cca441f284d77fa= cceb SHA256 (FreeBSD-14.0-ALPHA1-powerpc-20230811-136fc495615f-264678-disc1.is= o) =3D b70c79ba3f0b01d5eff49f4a25d69bfc0dd3b90bc3b335df1ac5720b4084d75a SHA256 (FreeBSD-14.0-ALPHA1-powerpc-20230811-136fc495615f-264678-disc1.is= o.xz) =3D cbd591e912fc6a03b9c2e665612722cdcfde484ac135e05f4f97b6f01f1175ef o 14.0-ALPHA1 powerpc64 GENERIC64: SHA512 (FreeBSD-14.0-ALPHA1-powerpc-powerpc64-20230811-136fc495615f-26467= 8-bootonly.iso) =3D 2b998abdca1ccd628c6bfd3b873aa16c0fd708da9a0ed1041f80ac9= cf215975ddc83e40ed0d21d66a352c44cba6dcb0dfcc48928189354a0c9c776d51be26763 SHA512 (FreeBSD-14.0-ALPHA1-powerpc-powerpc64-20230811-136fc495615f-26467= 8-bootonly.iso.xz) =3D 97958dfe324a4c25d7ae49556c1b3acfd8f1d08ad5fa0e756440= 07c8dea75229e509b6d143eb9099841fb43c914c147b093544d2b1aa23e669219d34a3f4a130 SHA512 (FreeBSD-14.0-ALPHA1-powerpc-powerpc64-20230811-136fc495615f-26467= 8-disc1.iso) =3D f007405cc500d1fcd4d493eb8db6deb3d99e6c94312543cd11550b2a50= 26ad12482eacdf56a79dc701f59e68a0385fc2a11ecba3a333bb1db1a96656d7f31b5e SHA512 (FreeBSD-14.0-ALPHA1-powerpc-powerpc64-20230811-136fc495615f-26467= 8-disc1.iso.xz) =3D b10c3fcce9e1e3ad70d269ba35bbad092a50fffa98f64690a8c280b= 0fd4697fd665cc21a0e84c8780af325503f8935fff0a2d7aed1218dd2a575dc6cd2f8807a SHA256 (FreeBSD-14.0-ALPHA1-powerpc-powerpc64-20230811-136fc495615f-26467= 8-bootonly.iso) =3D 0f6d31bbd946d424dfb7a298832da58f62d7b3c9c1d6a9e285f06b6= e56bd4c6b SHA256 (FreeBSD-14.0-ALPHA1-powerpc-powerpc64-20230811-136fc495615f-26467= 8-bootonly.iso.xz) =3D bf69086c56f6db9bd9d9d0ec0c2acedef47aa3a4fa2411e4b56b= 89a2b801ce57 SHA256 (FreeBSD-14.0-ALPHA1-powerpc-powerpc64-20230811-136fc495615f-26467= 8-disc1.iso) =3D a8a407c6265d93953e60113b1ba33d44ab1b1a677e7002ce14fd54e1b6= c530c5 SHA256 (FreeBSD-14.0-ALPHA1-powerpc-powerpc64-20230811-136fc495615f-26467= 8-disc1.iso.xz) =3D 0490102d90386af5b951754c09c9f579c49b964a6401648d40ac301= ac084fe14 o 14.0-ALPHA1 powerpc64le GENERIC64LE: SHA512 (FreeBSD-14.0-ALPHA1-powerpc-powerpc64le-20230811-136fc495615f-264= 678-bootonly.iso) =3D cfcf40f298180ea45adc47ee5587060daa91dbe40c515ba61aad3= 42c11301fe702ca3f1e922fcee400e9ea36e8e09fd3150d92ca6207541241e311d4f7c81e4a SHA512 (FreeBSD-14.0-ALPHA1-powerpc-powerpc64le-20230811-136fc495615f-264= 678-bootonly.iso.xz) =3D 2b7e257149c8115e49f019cc2aa536983f89665d3b5b11d979= cfcc18c434cc37d893bd5594a90a123e6ba077803312474b2ad04a70c711ae43cb1bcc24c69= cc6 SHA512 (FreeBSD-14.0-ALPHA1-powerpc-powerpc64le-20230811-136fc495615f-264= 678-disc1.iso) =3D 75da0ab07f3a6de02bbdd3a7a14f138983607a82cdd04ff7bb8975fe= 7115fb67e6b9ff5f8d0dcf8bc21fc6fd267e229c7387a030977b504a2dfeeed6b56b5a98 SHA512 (FreeBSD-14.0-ALPHA1-powerpc-powerpc64le-20230811-136fc495615f-264= 678-disc1.iso.xz) =3D 2b5b836c37be37ed679b926d3cb646a0ed6d86e6bf8b983fd5e2c= b1eca5137cef7fe032a7e1217c60a5ab8915361cd89ed0e5dd3270951f6a306030952fca845 SHA256 (FreeBSD-14.0-ALPHA1-powerpc-powerpc64le-20230811-136fc495615f-264= 678-bootonly.iso) =3D befdb9040f14ff7d0e4086e1b7e9d01335d1ef4d775fda5e8bbed= 8daf419cee0 SHA256 (FreeBSD-14.0-ALPHA1-powerpc-powerpc64le-20230811-136fc495615f-264= 678-bootonly.iso.xz) =3D 3141ef9b99d43ac18256b19a087d52d09c1f29a83227033efb= e17dc5cbc7e7ce SHA256 (FreeBSD-14.0-ALPHA1-powerpc-powerpc64le-20230811-136fc495615f-264= 678-disc1.iso) =3D 86671ebab274f3ef5e539404a18ee4a172e7bf852b243a54cbe917eb= c4b137bb SHA256 (FreeBSD-14.0-ALPHA1-powerpc-powerpc64le-20230811-136fc495615f-264= 678-disc1.iso.xz) =3D 37f16f74507a5b56e01fc76f61b0b8b19cd39e0d59031243e4ddf= 0e502a9d783 o 14.0-ALPHA1 armv6 RPI-B: SHA512 (FreeBSD-14.0-ALPHA1-arm-armv6-RPI-B-20230811-136fc495615f-264678.= img.xz) =3D 52650316d7f9c9ae1746cff14d4b3f486b0811285655ad3412f2a1aa3f8345b= 1f7be48030ce485cadfcb4f78995da7d4b29799b41ffdc39068fb5e027c645074 SHA256 (FreeBSD-14.0-ALPHA1-arm-armv6-RPI-B-20230811-136fc495615f-264678.= img.xz) =3D e76da9f5c7b1668d8dd552d85a06b90eca99dceea89f9a2a29628c36daba1a20 o 14.0-ALPHA1 armv7 GENERICSD: SHA512 (FreeBSD-14.0-ALPHA1-arm-armv7-GENERICSD-20230811-136fc495615f-264= 678.img.xz) =3D 94257595926cb5dee075902975431337a59cf9fc5676642caf8ff646e08= 650590beb8052d131d1776ce16e0185d1b01635ae9ce2cc91c71c444ff828e64f5f2e SHA256 (FreeBSD-14.0-ALPHA1-arm-armv7-GENERICSD-20230811-136fc495615f-264= 678.img.xz) =3D e7a7ab2c34222d0e75b001c3b1e9dca4d3367430c2d7ead6f8b73bd4581= eb8fc o 14.0-ALPHA1 aarch64 GENERIC: SHA512 (FreeBSD-14.0-ALPHA1-arm64-aarch64-20230811-136fc495615f-264678-bo= otonly.iso) =3D b4e7c689fa88e2109974d0aacb605e0d07b9dbd9a192d95aa9ce1f01b1e= 02791cddd73de837d853c2bdb452e16ad44777354823308a13b8da60f21a44fb44517 SHA512 (FreeBSD-14.0-ALPHA1-arm64-aarch64-20230811-136fc495615f-264678-bo= otonly.iso.xz) =3D a6446dd880d261586816037419de18f55a419a95a8637255f593bf96= 354ae2c5b85eac4d999a18ff39b0f169f4855470a030c1436938eaca78b864999bbd6f5e SHA512 (FreeBSD-14.0-ALPHA1-arm64-aarch64-20230811-136fc495615f-264678-di= sc1.iso) =3D 9bff46b523fc167e671f3bbdd37f720169fc89c2d3a7519537bab314d2eef6= fc3fce80e4a8ee62bf0823f8a4ca0af4020eb355f0fc60518d825ccb23d8a9c655 SHA512 (FreeBSD-14.0-ALPHA1-arm64-aarch64-20230811-136fc495615f-264678-di= sc1.iso.xz) =3D 832a832e9da92818b8c1ab668fc0b9665a7b88ae2e6e10a27042a785947= 3326a76ebe7614ced62172b9bb3e64437fd52059b32245fcc903c7e09f48a91b65925 SHA512 (FreeBSD-14.0-ALPHA1-arm64-aarch64-20230811-136fc495615f-264678-me= mstick.img) =3D bc763cfbdf8013fb3a8dd4add37f2ab5cd1fb763abe4f7df4879c1d8e93= 750106efa4ae04f3990291bf813d59d9f75b4c367ef7eb5277152ab88d6fbf037f2e1 SHA512 (FreeBSD-14.0-ALPHA1-arm64-aarch64-20230811-136fc495615f-264678-me= mstick.img.xz) =3D 068c49ab89ecdc2803c64371badbb600bfb7458d205f36c15c653f10= 5f5a1d59e9a8e802fdaecf146d6f6cd51ace8525a1125a44d238aabd15eff9fa71cb9ec7 SHA512 (FreeBSD-14.0-ALPHA1-arm64-aarch64-20230811-136fc495615f-264678-mi= ni-memstick.img) =3D f27f3882cbb76af254da32b7a09dc7d362228cd11bd22fe0a0ea94= df031fb01f9baaf16271b260f0dbc71988131fcc0f1e6e547a99a6d7d12a7e2748fbd97b55 SHA512 (FreeBSD-14.0-ALPHA1-arm64-aarch64-20230811-136fc495615f-264678-mi= ni-memstick.img.xz) =3D 7532b1d71cfd02b684faada9394a24c875590fd473596d224ce= 0ca4b90b2a726d406a7be1e34817e531c864d3c5220ca137f7ff3e71336dd9a4911adf8e90e= 8e SHA256 (FreeBSD-14.0-ALPHA1-arm64-aarch64-20230811-136fc495615f-264678-bo= otonly.iso) =3D ac22ca5a8241d9ad880181905304d65506d1bb4f0fc5010aa7db00e5785= 545d5 SHA256 (FreeBSD-14.0-ALPHA1-arm64-aarch64-20230811-136fc495615f-264678-bo= otonly.iso.xz) =3D 66c24a929b818e2d1cb9dac1029074270760eb6c87fa02e129684626= f1957353 SHA256 (FreeBSD-14.0-ALPHA1-arm64-aarch64-20230811-136fc495615f-264678-di= sc1.iso) =3D ef1656974732af50d75ef4e1240ee92ba3a499f9b68e8d94945df37320d982= 97 SHA256 (FreeBSD-14.0-ALPHA1-arm64-aarch64-20230811-136fc495615f-264678-di= sc1.iso.xz) =3D 1c98c4d5554b75bd84f3dda5f4bb44cfcfaeb8fdd1803412cec6fea7437= 76dc2 SHA256 (FreeBSD-14.0-ALPHA1-arm64-aarch64-20230811-136fc495615f-264678-me= mstick.img) =3D d5b89559bf034f11dabcc96a14bda553702eb8c1a26b74f932759b5dc0e= 7d19a SHA256 (FreeBSD-14.0-ALPHA1-arm64-aarch64-20230811-136fc495615f-264678-me= mstick.img.xz) =3D 434ce1eece107adaec33231af852a9b2cd2cef75b74cd0c7f3d3e28f= aabea9b5 SHA256 (FreeBSD-14.0-ALPHA1-arm64-aarch64-20230811-136fc495615f-264678-mi= ni-memstick.img) =3D 7db5498f73f58f75adab66211429c05568c33991a15f6629e5a0d2= ac70df6d2b SHA256 (FreeBSD-14.0-ALPHA1-arm64-aarch64-20230811-136fc495615f-264678-mi= ni-memstick.img.xz) =3D 4e68fb820da19e6d7158f88e36958912db03f5f2ed17a9d90da= 92459e8f7d5f4 o 14.0-ALPHA1 aarch64 RPI: SHA512 (FreeBSD-14.0-ALPHA1-arm64-aarch64-RPI-20230811-136fc495615f-26467= 8.img.xz) =3D 9744ae7dfd6ef0b87bda18d62744d3509b7f895dd6f38e8d64e09d7e6ae50= 52e19b66ff3873bff3e04a382f12db9e5a24b2f03f90549545e5efd7131aa9ca217 SHA256 (FreeBSD-14.0-ALPHA1-arm64-aarch64-RPI-20230811-136fc495615f-26467= 8.img.xz) =3D 56fa6c647f859d90c4f0d6868bfcc647d7e30c3a5b34ec101cc35bb9c20a5= 435 o 14.0-ALPHA1 aarch64 PINE64: SHA512 (FreeBSD-14.0-ALPHA1-arm64-aarch64-PINE64-20230811-136fc495615f-26= 4678.img.xz) =3D a0af715dca8d109aa21c07148e38e3003448b160af0aa3dbf3d0a4aa97= dfc442ee59bbf0189cdc2cd5b2e8040444f7a7c4838db5362abaa881db7f1f40d6deb2 SHA256 (FreeBSD-14.0-ALPHA1-arm64-aarch64-PINE64-20230811-136fc495615f-26= 4678.img.xz) =3D e6da136beb13c4f61e5a66e70ab4c6e74a11a9eab23ca834fe40e1bc26= f6e07c o 14.0-ALPHA1 aarch64 PINE64-LTS: SHA512 (FreeBSD-14.0-ALPHA1-arm64-aarch64-PINE64-LTS-20230811-136fc495615= f-264678.img.xz) =3D 735517fc7536b0d049928979dabc1e72ffdc68af64c8955c27b92f= bbb0597913866dbf7deb324d5b4934243a66d3d7587ae39473116ea4171f37f7bafeb9e166 SHA256 (FreeBSD-14.0-ALPHA1-arm64-aarch64-PINE64-LTS-20230811-136fc495615= f-264678.img.xz) =3D 29addfd1c655a64f16d396f675c4187c8df709f6d1c7f8593950ed= 5679f02872 o 14.0-ALPHA1 aarch64 PINEBOOK: SHA512 (FreeBSD-14.0-ALPHA1-arm64-aarch64-PINEBOOK-20230811-136fc495615f-= 264678.img.xz) =3D 37282ebb5d4582c13990a1bec781fa047eb1cde506caf5b2f350104c= 1c0e7d645c2500e3f6d8ca639a2a45eb96e73b915b3fd18297cae858e508ed18f06589d6 SHA256 (FreeBSD-14.0-ALPHA1-arm64-aarch64-PINEBOOK-20230811-136fc495615f-= 264678.img.xz) =3D 5dc06e58a4b4c991a63b02878a8033f8cbb8b376e66bd0ae5f3a580f= f85a4ad2 o 14.0-ALPHA1 aarch64 ROCK64: SHA512 (FreeBSD-14.0-ALPHA1-arm64-aarch64-ROCK64-20230811-136fc495615f-26= 4678.img.xz) =3D 199df3d9075d6b32f85eabce1b0026cf3b51cd97356c62e4ca1f967ac0= b302318a6326ac496b6d5b1dd9526d608b01ca01480efeac6f20a1147b326026fc26ad SHA256 (FreeBSD-14.0-ALPHA1-arm64-aarch64-ROCK64-20230811-136fc495615f-26= 4678.img.xz) =3D 2b00e07cddecb3d54bfec44e0ed92c53ac8b656fa730b2ff56abef3bb0= 634e1e o 14.0-ALPHA1 aarch64 ROCKPRO64: SHA512 (FreeBSD-14.0-ALPHA1-arm64-aarch64-ROCKPRO64-20230811-136fc495615f= -264678.img.xz) =3D 6e0ae4cbe556b70efa1afdb23b66491c48b19b03ba873da18f60c0a= 0d580cc053344b528f603b677976d4a215f08252d8d508d8cb41439d4a3c29fda723b293d SHA256 (FreeBSD-14.0-ALPHA1-arm64-aarch64-ROCKPRO64-20230811-136fc495615f= -264678.img.xz) =3D 05e53b1c6b4485cf59fb0aa68fb29343a1dc5006e9e409908f763f5= 0ab52dbde o 14.0-ALPHA1 riscv64 GENERIC: SHA512 (FreeBSD-14.0-ALPHA1-riscv-riscv64-20230811-136fc495615f-264678-bo= otonly.iso) =3D 0b5fb72264f443f0e1ec58acc81a83c4ab31d27376639b61e67667da5a2= 5103f88a0f967c418d32164dcf7301668ab2391e3bbc263a381ddcde81db43275d509 SHA512 (FreeBSD-14.0-ALPHA1-riscv-riscv64-20230811-136fc495615f-264678-bo= otonly.iso.xz) =3D 3db696f95629382755578c8b8a84f7770a77f0794006d8bac6565a48= 4b8511b2c0204bf4b4e8b40da9dd454ba08e9b3fc4cbb69349049d12b24f985db925e89b SHA512 (FreeBSD-14.0-ALPHA1-riscv-riscv64-20230811-136fc495615f-264678-di= sc1.iso) =3D 139c1c7b892a0c3773407728de0cf2469fcea04dfa60b840090ca8dc58fa13= 2987a09c6d935ebf084914cf53bb25a55dbf14e4879c0e064013d568f0fdea47b3 SHA512 (FreeBSD-14.0-ALPHA1-riscv-riscv64-20230811-136fc495615f-264678-di= sc1.iso.xz) =3D 0ad2dbe902224e552812448e5956bc039c9d5dd472840996bb6fef2405f= 76b99e4d259a67cdc0853b5da117e664855fbc172ca73a2817ea15969cb4d74ba8f6c SHA512 (FreeBSD-14.0-ALPHA1-riscv-riscv64-20230811-136fc495615f-264678-me= mstick.img) =3D 2fa0be39473127fe1c607cb94da080aaf9a10d716387fab7e28b1d804cb= 61fc56c34ed9b10b806c9c97abed670bd54f5bf2f4a1f9f2d03c6a22cd364234e7320 SHA512 (FreeBSD-14.0-ALPHA1-riscv-riscv64-20230811-136fc495615f-264678-me= mstick.img.xz) =3D 5dd31ffcfcc148b70d91d1b81ec2f3a936edc5bc731600f9730a06b1= 7292f9f81bb7565c50d4a9b3374af446f7ec52d4a59233b803192f93e92dbce1295886d3 SHA512 (FreeBSD-14.0-ALPHA1-riscv-riscv64-20230811-136fc495615f-264678-mi= ni-memstick.img) =3D fe8fc8c2a28f46a38b4fcee51b2601c16597ca1651d073056ecf8e= a7c631931f8930e56a35ac9c10936bdf9feed1dd4fd854ff9757930006b6173d0f99a757cd SHA512 (FreeBSD-14.0-ALPHA1-riscv-riscv64-20230811-136fc495615f-264678-mi= ni-memstick.img.xz) =3D 60c566b032b18a8ab0e03cb041fca2012c80cf20fec92a42204= 0095a97ac0e0b5c60928c5f4e5bc6992d90d7f5dd3e26a957d42ca8e6ebe74bb35fcb10450c= 74 SHA256 (FreeBSD-14.0-ALPHA1-riscv-riscv64-20230811-136fc495615f-264678-bo= otonly.iso) =3D 299ad6f00ff01d1f5d9e1c9e0b013c6a7bb8f58373d82473ddc3bbd7bac= dbb95 SHA256 (FreeBSD-14.0-ALPHA1-riscv-riscv64-20230811-136fc495615f-264678-bo= otonly.iso.xz) =3D 9f020a3cb9a0b5c8fd610aedeb6078b33375197ffe6f786991f8feb5= 97f79f62 SHA256 (FreeBSD-14.0-ALPHA1-riscv-riscv64-20230811-136fc495615f-264678-di= sc1.iso) =3D 30ccf31bb7e55c2a2c01e272ff1e50adbbbd40ea082c317427cdef87971620= ca SHA256 (FreeBSD-14.0-ALPHA1-riscv-riscv64-20230811-136fc495615f-264678-di= sc1.iso.xz) =3D 564e79c0b155087c589355c978c1ab3030bbf51ee42bf80e38031fd7f2b= 35823 SHA256 (FreeBSD-14.0-ALPHA1-riscv-riscv64-20230811-136fc495615f-264678-me= mstick.img) =3D de5ee6c4e5f1f21f343e8a625c5abf344c433ad73702d914e52c8c00c0a= c7f91 SHA256 (FreeBSD-14.0-ALPHA1-riscv-riscv64-20230811-136fc495615f-264678-me= mstick.img.xz) =3D 500746a96c3270d67e5a637035bf0b3c6ee216fa789f5c8e030560ca= 283f8cc6 SHA256 (FreeBSD-14.0-ALPHA1-riscv-riscv64-20230811-136fc495615f-264678-mi= ni-memstick.img) =3D 45766b206a306448ac54b01c5618b1b8363a42e96b6b3e46c676e5= 97681e3c0d SHA256 (FreeBSD-14.0-ALPHA1-riscv-riscv64-20230811-136fc495615f-264678-mi= ni-memstick.img.xz) =3D 869db2f4ac965b2da44976129b47734f84cfc55f20deab3c5ff= 90699e5d0aedb o 14.0-ALPHA1 riscv64 GENERICSD: SHA512 (FreeBSD-14.0-ALPHA1-riscv-riscv64-GENERICSD-20230811-136fc495615f= -264678.img.xz) =3D 627a1fa65dc496524338dd768d05053cd1dc6a08f64a46d798078f7= adbb3d3842dce9df8933a3310695b506d02e48928f2f73c30e59d7d892e6d46e61225e591 SHA256 (FreeBSD-14.0-ALPHA1-riscv-riscv64-GENERICSD-20230811-136fc495615f= -264678.img.xz) =3D 440a20ca9b0e965bef9a23688a4d8d739dedd0a486f760a92432853= b5d958db8 =3D=3D VM IMAGE CHECKSUMS =3D=3D o 14.0-ALPHA1 amd64: SHA512 (FreeBSD-14.0-ALPHA1-amd64-20230811-136fc495615f-264678.qcow2.xz) = =3D db67eb7f2790bafdefb84d272ed188dcff109ab0d208938bc1dbcbb210ca115b8b29e01= 83669e8c5a508b74341092a6ce73a2e44b775098e58b8f115325fcf1f SHA512 (FreeBSD-14.0-ALPHA1-amd64-20230811-136fc495615f-264678.raw.xz) = =3D 43e0ce482f9ff7213bdc677cbba2124283f9d4a780448b73a1c4d27c08f51e0a12a76a0= c7665f000a3a1af46779a1eb07c8ae3abf9bdd7779a693e9941bfe349 SHA512 (FreeBSD-14.0-ALPHA1-amd64-20230811-136fc495615f-264678.vhd.xz) = =3D e22c8f09341abb71dd5786c2cb5ab4ac7875f8791c870053217df742b0ba63d710f1ef1= 1302d221d36983d04fd9cf289de5ecd7ea55c77104ed69af43da01bf5 SHA512 (FreeBSD-14.0-ALPHA1-amd64-20230811-136fc495615f-264678.vmdk.xz) = =3D 0f42f456521b4bc87e5fc13ec09bd1c5f36988fb33dd6158c4ae80f8b0e2049b9b38d62= 9795d9301f5f052a4574eadded59dc6aa9c9d19324afa05e1af1fdb47 SHA512 (FreeBSD-14.0-ALPHA1-amd64-ufs.qcow2.xz) =3D db67eb7f2790bafdefb84= d272ed188dcff109ab0d208938bc1dbcbb210ca115b8b29e0183669e8c5a508b74341092a6c= e73a2e44b775098e58b8f115325fcf1f SHA512 (FreeBSD-14.0-ALPHA1-amd64-ufs.raw.xz) =3D 43e0ce482f9ff7213bdc677= cbba2124283f9d4a780448b73a1c4d27c08f51e0a12a76a0c7665f000a3a1af46779a1eb07c= 8ae3abf9bdd7779a693e9941bfe349 SHA512 (FreeBSD-14.0-ALPHA1-amd64-ufs.vhd.xz) =3D e22c8f09341abb71dd5786c= 2cb5ab4ac7875f8791c870053217df742b0ba63d710f1ef11302d221d36983d04fd9cf289de= 5ecd7ea55c77104ed69af43da01bf5 SHA512 (FreeBSD-14.0-ALPHA1-amd64-ufs.vmdk.xz) =3D 0f42f456521b4bc87e5fc1= 3ec09bd1c5f36988fb33dd6158c4ae80f8b0e2049b9b38d629795d9301f5f052a4574eadded= 59dc6aa9c9d19324afa05e1af1fdb47 SHA512 (FreeBSD-14.0-ALPHA1-amd64-zfs.qcow2.xz) =3D ecc6ec6d90aaf1b9ceab1= c442415d827b14870c0bf1e3900f516ef8362ebfd4b38a44cc1ef9ef5aaa4b95701cae942fe= 18b6504ce5c58a8647b9f779562019eb SHA512 (FreeBSD-14.0-ALPHA1-amd64-zfs.raw.xz) =3D 9fe658d5c17b3d358f9810a= 97edfce9b6b1b109480398d136faa8a916357281bfba35fdab6abd2c0a1a5397c799d3acefe= 92f47bba56dd4333dfbbaf7b6d0731 SHA512 (FreeBSD-14.0-ALPHA1-amd64-zfs.vhd.xz) =3D 14fcbce876e3783928ab945= 4c1f9d4481968dae829ba7509a6cafc01fda761a34288866c659d26bd1e063cae618cb18b04= 9cb79e8b840b5deb55dd7567c4bdc4 SHA512 (FreeBSD-14.0-ALPHA1-amd64-zfs.vmdk.xz) =3D dd9f819739b8a78d113c9b= 0c41dfbce34a639c7bb383828d5ab1403dbb5da9ef452ba5211ea4ff00c667ec89b190ecfea= ddcab1af10973368795cbed6277cc05 SHA256 (FreeBSD-14.0-ALPHA1-amd64-20230811-136fc495615f-264678.qcow2.xz) = =3D 8c002b49ed7bbe552e0c8e9c212b6cd86bdcf0e6a458fe5f62c2472e40c79273 SHA256 (FreeBSD-14.0-ALPHA1-amd64-20230811-136fc495615f-264678.raw.xz) = =3D b46eecb57f4d0a0582eca5afb9040ea9696ae5cde2aedc129a116c5c69b1068c SHA256 (FreeBSD-14.0-ALPHA1-amd64-20230811-136fc495615f-264678.vhd.xz) = =3D f85d5c37d0295a8a2db65c029d3f72f85df9bf4ed1abb80f9f0c4db88e44a0e6 SHA256 (FreeBSD-14.0-ALPHA1-amd64-20230811-136fc495615f-264678.vmdk.xz) = =3D 8b572113c368d24233fcb6e0d896e4502f07ada0f89fa69b2e5d3c74dfbb4b6a SHA256 (FreeBSD-14.0-ALPHA1-amd64-ufs.qcow2.xz) =3D 8c002b49ed7bbe552e0c8= e9c212b6cd86bdcf0e6a458fe5f62c2472e40c79273 SHA256 (FreeBSD-14.0-ALPHA1-amd64-ufs.raw.xz) =3D b46eecb57f4d0a0582eca5a= fb9040ea9696ae5cde2aedc129a116c5c69b1068c SHA256 (FreeBSD-14.0-ALPHA1-amd64-ufs.vhd.xz) =3D f85d5c37d0295a8a2db65c0= 29d3f72f85df9bf4ed1abb80f9f0c4db88e44a0e6 SHA256 (FreeBSD-14.0-ALPHA1-amd64-ufs.vmdk.xz) =3D 8b572113c368d24233fcb6= e0d896e4502f07ada0f89fa69b2e5d3c74dfbb4b6a SHA256 (FreeBSD-14.0-ALPHA1-amd64-zfs.qcow2.xz) =3D c2c1216115c12437795b5= 9b0e83af1ee5ed3cc76e5268c8b788e00278a504689 SHA256 (FreeBSD-14.0-ALPHA1-amd64-zfs.raw.xz) =3D 492309dfdc8cd83568b4a30= 8fe40005eec7f6e49e72fd560912ac195f7b9332f SHA256 (FreeBSD-14.0-ALPHA1-amd64-zfs.vhd.xz) =3D 28abbdd7102aaed3e57364c= 1d229319b1707fb3632b4331e883785a8b9e5e05d SHA256 (FreeBSD-14.0-ALPHA1-amd64-zfs.vmdk.xz) =3D 43ccae858c9a240d9037bf= 6e4d4199a45d7bdc14bcd474fe254a135112bc533d o 14.0-ALPHA1 i386: SHA512 (FreeBSD-14.0-ALPHA1-i386-20230811-136fc495615f-264678.qcow2.xz) = =3D 3a186a5197e37e403692f34f1d75ff431ea73e6e4f3687bc96a2f1af488b49ca7ec19c0= 0dbaf309f91e7b1dc94e4b22e873ed891ae09ee4d84e8cbb66774ed60 SHA512 (FreeBSD-14.0-ALPHA1-i386-20230811-136fc495615f-264678.raw.xz) =3D= b898b99dfafc71fec94b7fa78e2376ef83c94530a7af0baededd713de6f987709f3b078a72= dc558773da1744336b0d702b25bb65085f2309e2866681b7e8ab32 SHA512 (FreeBSD-14.0-ALPHA1-i386-20230811-136fc495615f-264678.vhd.xz) =3D= 6c84c363daeff40efbd0eb0b8ea0bde7de0251b4a930aeb66ec55d4dff19a08b2829a56a91= 4b584ee58ae1e460d02355fae9f906f5356f26b4363d0d14ac291e SHA512 (FreeBSD-14.0-ALPHA1-i386-20230811-136fc495615f-264678.vmdk.xz) = =3D 587d9f47854ea68b937211c3aef0e669f69f839ce86c8647a6cf7bec21c1efb14c076f5= 94516dc41aee4c2732dafc4d6757c21d4c64f7e4b0515bb5bc9230799 SHA512 (FreeBSD-14.0-ALPHA1-i386-ufs.qcow2.xz) =3D 3a186a5197e37e403692f3= 4f1d75ff431ea73e6e4f3687bc96a2f1af488b49ca7ec19c00dbaf309f91e7b1dc94e4b22e8= 73ed891ae09ee4d84e8cbb66774ed60 SHA512 (FreeBSD-14.0-ALPHA1-i386-ufs.raw.xz) =3D b898b99dfafc71fec94b7fa7= 8e2376ef83c94530a7af0baededd713de6f987709f3b078a72dc558773da1744336b0d702b2= 5bb65085f2309e2866681b7e8ab32 SHA512 (FreeBSD-14.0-ALPHA1-i386-ufs.vhd.xz) =3D 6c84c363daeff40efbd0eb0b= 8ea0bde7de0251b4a930aeb66ec55d4dff19a08b2829a56a914b584ee58ae1e460d02355fae= 9f906f5356f26b4363d0d14ac291e SHA512 (FreeBSD-14.0-ALPHA1-i386-ufs.vmdk.xz) =3D 587d9f47854ea68b937211c= 3aef0e669f69f839ce86c8647a6cf7bec21c1efb14c076f594516dc41aee4c2732dafc4d675= 7c21d4c64f7e4b0515bb5bc9230799 SHA512 (FreeBSD-14.0-ALPHA1-i386-zfs.qcow2.xz) =3D 593357f31eccf964a5eb2b= f14deb9e5766a2336bfd5d068501abf5bc8d980a667315cfab99136595f3a4baceb592de6f9= ab5559908715653b0401e2293199961 SHA512 (FreeBSD-14.0-ALPHA1-i386-zfs.raw.xz) =3D d6a7c35c24b8fa5227a9f135= 09e9976384500b869ba099a190cc51a9d2777f812776bdb393cf67df5f62622ee97c2ff961a= 8212a00ce004fefddea2f9992895e SHA512 (FreeBSD-14.0-ALPHA1-i386-zfs.vhd.xz) =3D b9cf9652e7c87aedf3f31e95= 544f1397127ababfb3858c873570e5b008fb1b291296c772ed435926be32393584581aaf640= 3df5acca8df72515238d6375cf86b SHA512 (FreeBSD-14.0-ALPHA1-i386-zfs.vmdk.xz) =3D 30fef9586355b40d0f81142= eb5afc0040c55f12d96476e56613c3a2cb15c026489f14fe12ec43354cf9e775f262d625d0a= 38c797eed9955e6d71e40d03f17731 SHA256 (FreeBSD-14.0-ALPHA1-i386-20230811-136fc495615f-264678.qcow2.xz) = =3D 0dbfc9c5352cd477a364c2f76acd2b0ffb075e17037512d5eff3a45becbfc54d SHA256 (FreeBSD-14.0-ALPHA1-i386-20230811-136fc495615f-264678.raw.xz) =3D= 6609c9f7bf90ec95547906b12a2a7d2ad26368ed7d921ff0f4bbd2b5f2f58045 SHA256 (FreeBSD-14.0-ALPHA1-i386-20230811-136fc495615f-264678.vhd.xz) =3D= f6083f411346b0f57df7c9bc100d1453aad3aa31181019bdb541583f77222675 SHA256 (FreeBSD-14.0-ALPHA1-i386-20230811-136fc495615f-264678.vmdk.xz) = =3D 83be0959fe5e3e2291bb0edd5b3481b9365320d00844e3814b9224776a7ff9ec SHA256 (FreeBSD-14.0-ALPHA1-i386-ufs.qcow2.xz) =3D 0dbfc9c5352cd477a364c2= f76acd2b0ffb075e17037512d5eff3a45becbfc54d SHA256 (FreeBSD-14.0-ALPHA1-i386-ufs.raw.xz) =3D 6609c9f7bf90ec95547906b1= 2a2a7d2ad26368ed7d921ff0f4bbd2b5f2f58045 SHA256 (FreeBSD-14.0-ALPHA1-i386-ufs.vhd.xz) =3D f6083f411346b0f57df7c9bc= 100d1453aad3aa31181019bdb541583f77222675 SHA256 (FreeBSD-14.0-ALPHA1-i386-ufs.vmdk.xz) =3D 83be0959fe5e3e2291bb0ed= d5b3481b9365320d00844e3814b9224776a7ff9ec SHA256 (FreeBSD-14.0-ALPHA1-i386-zfs.qcow2.xz) =3D ca42e38353bd30cb43120a= f52cf5360e8ecac350ee50468458fb27de0e8b0aa4 SHA256 (FreeBSD-14.0-ALPHA1-i386-zfs.raw.xz) =3D 17d9fd5a7bcba5ec1582b592= 7f1ec4357c4dbe4c4928a89d04bc8254efbe47e4 SHA256 (FreeBSD-14.0-ALPHA1-i386-zfs.vhd.xz) =3D 1eb36fca0160ed78a5a90587= 34cd897a52650249ca3e19cb0df68895fad5363f SHA256 (FreeBSD-14.0-ALPHA1-i386-zfs.vmdk.xz) =3D e0a4a2d51931b7c4f1d36f8= adeb13d9a0731d2199d92188a4fbbf35a6f2eaea6 o 14.0-ALPHA1 aarch64: SHA512 (FreeBSD-14.0-ALPHA1-arm64-aarch64-20230811-136fc495615f-264678.qc= ow2.xz) =3D 01ea39e3ac63ec55edb897bfa729203dd2c3de15fb8f501712305218ac061f5= 18c9786db6fe9608a9bd4d447addd4be1c7948a7bd74ad4fc33b10e9ee02e0c26 SHA512 (FreeBSD-14.0-ALPHA1-arm64-aarch64-20230811-136fc495615f-264678.ra= w.xz) =3D 40cd8849602538ebfa7dc863fa278b8bbbd62cfc4b3d62e694bf836097dba28e2= b1f6afee1cf08176a46b7b0b2b0135e3315369406fdd080dca4406c4d759f11 SHA512 (FreeBSD-14.0-ALPHA1-arm64-aarch64-20230811-136fc495615f-264678.vh= d.xz) =3D 7edc468157344106172269ed373c8f5535de39c54ce9e67eff756a7bd76d36a0d= b1284bd439c982caf4e7bb78586f07ff9abf4af59941c9241c2125ae6d0eb74 SHA512 (FreeBSD-14.0-ALPHA1-arm64-aarch64-20230811-136fc495615f-264678.vm= dk.xz) =3D edd8ebf5f1247c36b31f142047e76e17c0bff6ba17c9ff54a71be8587337efa8= 03685807d202b37c2846b5cb5e79f0fd0c64f1707aac244a1fe60374758b7219 SHA512 (FreeBSD-14.0-ALPHA1-arm64-aarch64-ufs.qcow2.xz) =3D 01ea39e3ac63e= c55edb897bfa729203dd2c3de15fb8f501712305218ac061f518c9786db6fe9608a9bd4d447= addd4be1c7948a7bd74ad4fc33b10e9ee02e0c26 SHA512 (FreeBSD-14.0-ALPHA1-arm64-aarch64-ufs.raw.xz) =3D 40cd8849602538e= bfa7dc863fa278b8bbbd62cfc4b3d62e694bf836097dba28e2b1f6afee1cf08176a46b7b0b2= b0135e3315369406fdd080dca4406c4d759f11 SHA512 (FreeBSD-14.0-ALPHA1-arm64-aarch64-ufs.vhd.xz) =3D 7edc46815734410= 6172269ed373c8f5535de39c54ce9e67eff756a7bd76d36a0db1284bd439c982caf4e7bb785= 86f07ff9abf4af59941c9241c2125ae6d0eb74 SHA512 (FreeBSD-14.0-ALPHA1-arm64-aarch64-ufs.vmdk.xz) =3D edd8ebf5f1247c= 36b31f142047e76e17c0bff6ba17c9ff54a71be8587337efa803685807d202b37c2846b5cb5= e79f0fd0c64f1707aac244a1fe60374758b7219 SHA512 (FreeBSD-14.0-ALPHA1-arm64-aarch64-zfs.qcow2.xz) =3D 99e8f055d1541= 99f26e1b3432dbd7f4814b352914634b1bf527392ad7d12199c871b2d5c728cacdf5470a7eb= 07b7a71f39492ecb7d9bce714738a610b2ed0194 SHA512 (FreeBSD-14.0-ALPHA1-arm64-aarch64-zfs.raw.xz) =3D 1aea7c9741f3348= b735932b8409c13393942b1eb7a49bf0fbc2682719d97e985e76e5637a9745f0bb29617c809= ff7465090ae666b92ec8e22634026ddcafbade SHA512 (FreeBSD-14.0-ALPHA1-arm64-aarch64-zfs.vhd.xz) =3D aa3659c915ca5c0= b7ce11e7456b62849777dd6a8d9e4bb9656d799abf91991dd243c6a8d5a67252b206f781f61= f36db0a107eaf8534a97af57c1548fa2d5f92a SHA512 (FreeBSD-14.0-ALPHA1-arm64-aarch64-zfs.vmdk.xz) =3D d41dd6e489f4ee= a41904a83528ff947978788aa37a7a5f08f20be873ab7837c4e50dd3cb9782ce24a1c8d9b61= 3229e4c82db3d6bd28755a3661ad787dfd61896 SHA256 (FreeBSD-14.0-ALPHA1-arm64-aarch64-20230811-136fc495615f-264678.qc= ow2.xz) =3D 976066a1a8e9b315895f12b0b256724a47195e62091acee3b6c5fe02d44ec4f4 SHA256 (FreeBSD-14.0-ALPHA1-arm64-aarch64-20230811-136fc495615f-264678.ra= w.xz) =3D f27b70d2d65d8bbb9853861079e280236c7bcddb0cd1fd96ab7a185ca2a523ce SHA256 (FreeBSD-14.0-ALPHA1-arm64-aarch64-20230811-136fc495615f-264678.vh= d.xz) =3D 740208da9e15e0864121ae372df4bfeb54b1c7030c6fb5024109fb31595bc83b SHA256 (FreeBSD-14.0-ALPHA1-arm64-aarch64-20230811-136fc495615f-264678.vm= dk.xz) =3D 4573993ba11ccccdf3310576bfb3ec846a28d35a367447abd575a2c65b37f3e5 SHA256 (FreeBSD-14.0-ALPHA1-arm64-aarch64-ufs.qcow2.xz) =3D 976066a1a8e9b= 315895f12b0b256724a47195e62091acee3b6c5fe02d44ec4f4 SHA256 (FreeBSD-14.0-ALPHA1-arm64-aarch64-ufs.raw.xz) =3D f27b70d2d65d8bb= b9853861079e280236c7bcddb0cd1fd96ab7a185ca2a523ce SHA256 (FreeBSD-14.0-ALPHA1-arm64-aarch64-ufs.vhd.xz) =3D 740208da9e15e08= 64121ae372df4bfeb54b1c7030c6fb5024109fb31595bc83b SHA256 (FreeBSD-14.0-ALPHA1-arm64-aarch64-ufs.vmdk.xz) =3D 4573993ba11ccc= cdf3310576bfb3ec846a28d35a367447abd575a2c65b37f3e5 SHA256 (FreeBSD-14.0-ALPHA1-arm64-aarch64-zfs.qcow2.xz) =3D 1e16d452ec117= 5333805dd18adaa04ca34c34fa1398439c4cfc5ba767717487f SHA256 (FreeBSD-14.0-ALPHA1-arm64-aarch64-zfs.raw.xz) =3D bb8f62a7952a857= bd5130584bba61ee59bc134de5ea57158325d8ba9897a2425 SHA256 (FreeBSD-14.0-ALPHA1-arm64-aarch64-zfs.vhd.xz) =3D b5efaf509f35abd= 7e820fa70155a11b711d61c9b4cf2621b81e19b97ed34e8aa SHA256 (FreeBSD-14.0-ALPHA1-arm64-aarch64-zfs.vmdk.xz) =3D 332c6b0a704238= 6675fef330b1290f9e0270fce602770cc84eb202c688b383d4 o 14.0-ALPHA1 riscv64: SHA512 (FreeBSD-14.0-ALPHA1-riscv-riscv64-20230811-136fc495615f-264678.qc= ow2.xz) =3D 6a3eda00371624924e6ec5f3bd19e0417847bffdc911b0598ba3e497b99caea= fbfda7bcfc1f57a7bd0b7cfa03d8d08e475ab1c7c3a77db76ff0fe0c569f3dee5 SHA512 (FreeBSD-14.0-ALPHA1-riscv-riscv64-20230811-136fc495615f-264678.ra= w.xz) =3D 61a2383a67cf8a9b5f76ad74a7f3a969836633d112cd5ff7167a12e0668dd8f48= 202e3b28d7e8baaa7fae62f820620817129d53d08cc36bf8244f55803cca982 SHA512 (FreeBSD-14.0-ALPHA1-riscv-riscv64-20230811-136fc495615f-264678.vh= d.xz) =3D 53237991256bfa11cf1f616960a8a65b8535d9a123366133dc16883e1ba0a00fd= d2f2f523a147d42269bfdfc4603ed27d19c90c89073597c3b59b7a4b45b7129 SHA512 (FreeBSD-14.0-ALPHA1-riscv-riscv64-20230811-136fc495615f-264678.vm= dk.xz) =3D 8ad28f014dca23ddb29ac6cad383c97b7272df3abbe013371a12b289b09c7d09= 03d0852f1fca5dbb467ea4b413fba8a90a80f2d0998a5e90a7f6ac561c12af9c SHA512 (FreeBSD-14.0-ALPHA1-riscv-riscv64-ufs.qcow2.xz) =3D 6a3eda0037162= 4924e6ec5f3bd19e0417847bffdc911b0598ba3e497b99caeafbfda7bcfc1f57a7bd0b7cfa0= 3d8d08e475ab1c7c3a77db76ff0fe0c569f3dee5 SHA512 (FreeBSD-14.0-ALPHA1-riscv-riscv64-ufs.raw.xz) =3D 61a2383a67cf8a9= b5f76ad74a7f3a969836633d112cd5ff7167a12e0668dd8f48202e3b28d7e8baaa7fae62f82= 0620817129d53d08cc36bf8244f55803cca982 SHA512 (FreeBSD-14.0-ALPHA1-riscv-riscv64-ufs.vhd.xz) =3D 53237991256bfa1= 1cf1f616960a8a65b8535d9a123366133dc16883e1ba0a00fdd2f2f523a147d42269bfdfc46= 03ed27d19c90c89073597c3b59b7a4b45b7129 SHA512 (FreeBSD-14.0-ALPHA1-riscv-riscv64-ufs.vmdk.xz) =3D 8ad28f014dca23= ddb29ac6cad383c97b7272df3abbe013371a12b289b09c7d0903d0852f1fca5dbb467ea4b41= 3fba8a90a80f2d0998a5e90a7f6ac561c12af9c SHA512 (FreeBSD-14.0-ALPHA1-riscv-riscv64-zfs.qcow2.xz) =3D dc1c632d2872a= bb61b62ceb25d0dbc8a0877b72d77363acfd5f23b840c69b2403bd4554bab9c58ffcce1f92a= cc86be02ce6a169ac3e3d3603cfa9bfdc0a70510 SHA512 (FreeBSD-14.0-ALPHA1-riscv-riscv64-zfs.raw.xz) =3D dd29f4870b58cdc= 5f438c788f364293158eac6c1f4177a35cce247dff105306a936ce70871a6f05c8223d09467= c576e45d54a118dfc4f63e97a346bd299fec23 SHA512 (FreeBSD-14.0-ALPHA1-riscv-riscv64-zfs.vhd.xz) =3D f5146f20c44c678= a0651ba2d4ae413c7bc73052fcbc661158f9712a0537cafb5d2c909a90317de19cd2d776cdd= b218e7c4f5133975595e3c77f1b638bdae6668 SHA512 (FreeBSD-14.0-ALPHA1-riscv-riscv64-zfs.vmdk.xz) =3D f68e5ce8ba6247= a429352b4d08d7cafc0203858482a63a9ecb021542662064539822d714b9f0888854645cc5e= 1f073f9da23393ee31533ceece13a91bdb101e4 SHA256 (FreeBSD-14.0-ALPHA1-riscv-riscv64-20230811-136fc495615f-264678.qc= ow2.xz) =3D 828af49bfdc5435dbb46bc30332d2bf6ee774000d1f483ef3c01690cfbf26073 SHA256 (FreeBSD-14.0-ALPHA1-riscv-riscv64-20230811-136fc495615f-264678.ra= w.xz) =3D e45a426884b0a671fb2e17d4e91e0e75d89896effc42ca05e287d0661a2f784b SHA256 (FreeBSD-14.0-ALPHA1-riscv-riscv64-20230811-136fc495615f-264678.vh= d.xz) =3D aec733c39072afb35647b6262399b2dc3e26ff49b6448445eb6a146acc347edd SHA256 (FreeBSD-14.0-ALPHA1-riscv-riscv64-20230811-136fc495615f-264678.vm= dk.xz) =3D 570c6f877165a9006a1fba2f439dadc372b5d438d967ed8c79bc968d13f5104f SHA256 (FreeBSD-14.0-ALPHA1-riscv-riscv64-ufs.qcow2.xz) =3D 828af49bfdc54= 35dbb46bc30332d2bf6ee774000d1f483ef3c01690cfbf26073 SHA256 (FreeBSD-14.0-ALPHA1-riscv-riscv64-ufs.raw.xz) =3D e45a426884b0a67= 1fb2e17d4e91e0e75d89896effc42ca05e287d0661a2f784b SHA256 (FreeBSD-14.0-ALPHA1-riscv-riscv64-ufs.vhd.xz) =3D aec733c39072afb= 35647b6262399b2dc3e26ff49b6448445eb6a146acc347edd SHA256 (FreeBSD-14.0-ALPHA1-riscv-riscv64-ufs.vmdk.xz) =3D 570c6f877165a9= 006a1fba2f439dadc372b5d438d967ed8c79bc968d13f5104f SHA256 (FreeBSD-14.0-ALPHA1-riscv-riscv64-zfs.qcow2.xz) =3D 6b964eeb1b669= 49e62c4299c2aeb404ef25d98879008ca6750d477895b8e3919 SHA256 (FreeBSD-14.0-ALPHA1-riscv-riscv64-zfs.raw.xz) =3D c81df56af70ffca= ae59114721be169c919e157584d456473c4ed9431be73c282 SHA256 (FreeBSD-14.0-ALPHA1-riscv-riscv64-zfs.vhd.xz) =3D 7cde25771a991cc= 489161f1bafc661bc1154bdd441420908561321775a8ac393 SHA256 (FreeBSD-14.0-ALPHA1-riscv-riscv64-zfs.vmdk.xz) =3D d2da6d1beddefe= 80f6082bed2e36bbe9f89ef0e68e4b6bb93feaeb211821b759 o 14.0-ALPHA1 amd64 BASIC-CI: SHA512 (FreeBSD-14.0-ALPHA1-amd64-BASIC-CI-20230811-136fc495615f-264678.r= aw.xz) =3D 58e86a094b407bbe38e42cec30b654c11479b6d1ceae681524023a126d7af30a= e2409eb0b401b6693f4d3745edf4a10b112e4d3591bc9270a48cf587e8f98c5c SHA256 (FreeBSD-14.0-ALPHA1-amd64-BASIC-CI-20230811-136fc495615f-264678.r= aw.xz) =3D 9051590986cb08d04c85dbc92bdf45ae1897af36dbc7c646b5d2b2cc3b16ece1 Regards, Glen Please consider donating to help support my FreeBSD work: https://www.gofundme.com/f/gjbbsd https://paypal.me/gjbbsd Love FreeBSD? Support this and future releases with a donation to the FreeBSD Foundation! https://www.freebsdfoundation.org/donate/ --3siQDZowHQqNOShm Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEjRJAPC5sqwhs9k2jAxRYpUeP4pMFAmTWn7gACgkQAxRYpUeP 4pPA6hAAnA81eJiqVqNc5L/XDSc1P3Q16Ulp3pYh0sDtJFLzme9c6r12sNBTaE5p AIhMIamf/Bw4sRuGKxBwXPKNeznGT2KVsupmj99ZVXcvgG09exAc5kM6Xva5cLZn vi7iZ/HCbGhDdDNU+o3c49CsYbflpaYIyPyF6Tk7XHQECJ2Nk/FJtxiMClzhqzPe CgydwO6G8w0LX++u/IMYuA5+9SxuGnhL/2gvsWI/86E5wHc5aTPn/V8yVIXvrxtC GBvyk+O75Qbk5hf/9hac5CZ6sYt1ZxVhCXowgCp+nOZm+DKtMtMIjdIyoVpzgCXW k12KHBF3h3HrxyuvRRZdDrER+K9NC80IudnpfOOHGeR598jGXZ77jkEtrlyCC2Dd tlOS9WACkehRfINVDilZmbHbOgA77lB/+3SF3gl7IvVRBdPgUUxrp4wqhpHOuN8e rh17ZxwZC/KZ06MlDHbn7jtoiInt0O/O0uqUKNcw0z6wM1y0bsqT/Xygs1/93GkH O6XQBctlGB/X9mJ13c689+DkvVRvIu2c+k3Y1dIE+HNhaYdOa0th5icUyqVd8sPT ZdTr6LVSbKsxEjFVS9xU/JdQ5UyYYSnc+LkabMeMJMJtaLDqhcM2n4HjemPdntb6 nXY/IFMcgYxykm+NHAbZ6vpT4FRpJJ7iMsAELwFhdOf7o69kxmg= =hZmK -----END PGP SIGNATURE----- --3siQDZowHQqNOShm-- From nobody Fri Aug 11 21:59:45 2023 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 4RMyPx1X0Kz4pmj1 for ; Fri, 11 Aug 2023 21:59:49 +0000 (UTC) (envelope-from jbeich@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 4RMyPx0mr7z3dPn for ; Fri, 11 Aug 2023 21:59:49 +0000 (UTC) (envelope-from jbeich@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1691791189; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Z/t5zP4FRmhNB2n1Cw+xXbogeU49Uu4+D43UU5rGqQo=; b=Ok3oQs0wuebJjYV/Lh0qmX3MOWotcddjZtiiJwyb7JHIm50sU+NaMTKwm0W9AxKBZlkYnM XQhIApYO9lVoxqwKB4nMz2mi6+jIiRPoKqzv5w9JR1hoGZFoDdRkb/3zkpktsjExJMj0GP BmcRCXVmYKtvFZ0YgRUcq5UBFzbL07yHWF1muHkQujnf8AkHCruBrwi4HCw09586IdCbQ0 tXa4E3lg+9C5bxTFiCi20V5ucyIwnlUC0/hjg1nhsK2F0iyKFjyyWcMHrRkZFMCA6eBcVE G5bJxkTeGf6V+C+rxoiTj9RAdU0bOiS9DHcZTT9vMbjKJruT24YPUVtlTiFMaQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1691791189; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Z/t5zP4FRmhNB2n1Cw+xXbogeU49Uu4+D43UU5rGqQo=; b=EmujAcWlpXkuIgF+DXkHo5beNJW1dgJ1L9RKjug887bCCgJ/Qr5wijNEnSn0r2pyBxNJ0G zgK4+HjcAVOy+CsY2HuuWBbthpbTcq2HP9Zowqn2Fg0IdNlCpOUf/3PaUxU18gqcpPXELV bk2AR55YswJURuSmdo9AbpPpXJ6O7KxiYMnqXYccGxIdvYA9Ue4zoZlOsHZu18qxESCX/S /9FH9Rgf8VX4SjQ+/7vKrfMew+gWtrH4WPZrefGoCjOON6YrAaUnw8JWO38owQasCitg9o icDLBY4DN7Mxc5MecVYMU6DxB634W35KASii2Qva8HDoXHqkfkxND8AByOOcKw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1691791189; a=rsa-sha256; cv=none; b=LQYPQt3fPhjeluqfWaixH9TcCOSFkxjoxdHDWzGMvANF+ozHAClLIFw0wK8TmPFFDn7Z6T iT1v/RnC/6RTg5xVvTJMVawUCH2aRyHTm/PKC8z0ax86/W4C1baPN0aA7HEQuCeF6CAlke 7KAKfDoQbNHWqXAZfigETFruOB/tFeMxMR2T55qkIgwUlNT1FvxLz39qHD15VdkjBRPHqo OMeO56mlMLmBvz3VxWJa3o0HVYVv+1MZxasraWXoKca54UdinQ7f+qCt6gwhphOgQS8e/q XHIvnyeCkTNTZYQlHl2BhvZlLv+eRFfnsiC91QMoGpBHe5lN3cKaZh17/WzlRg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: by freefall.freebsd.org (Postfix, from userid 1354) id E78F818C11; Fri, 11 Aug 2023 21:59:48 +0000 (UTC) From: Jan Beich To: freebsd-current@freebsd.org Subject: Re: problem with poudriere && port ftp/curl In-Reply-To: (Matthias Apitz's message of "Fri, 11 Aug 2023 21:03:47 +0200") References: Date: Fri, 11 Aug 2023 23:59:45 +0200 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 Matthias Apitz writes: > I have the following problem with poudriere on 14-CURRENT and ports from > git head: every time when I start poudriere-bulk it removes a port > already compile fine (and all its dependent ports) with the message: > > ... > [00:00:40] Sanity checking the repository > [00:00:40] Checking packages for incremental rebuild needs > [00:00:43] Deleting curl-8.2.1.pkg: changed options > [00:00:43] Pkg: +ALTSVC -BROTLI -CARES +CA_BUNDLE +COOKIES -CURL_DEBUG > -DEBUG +DICT +DOCS +EXAMPLES +FTP -GNUTLS +GOPHER -GSSAPI_BASE > -GSSAPI_HEIMDAL -GSSAPI_MIT +GSSAPI_NONE +HTTP +HTTP2 -IDN +IMAP +IPV6 > -LDAP -LDAPS -LIBSSH +LIBSSH2 -MQTT +NTLM +OPENSSL +POP3 +PROXY +PSL > -RTMP +RTSP -SMB +SMTP +STATIC +TELNET +TFTP +THREADED_RESOLVER > +TLS_SRP -WEBSOCKET -WOLFSSL -ZSTD > [00:00:43] New: +ALTSVC -BROTLI -CARES +CA_BUNDLE +COOKIES -CURL_DEBUG > -DEBUG +DICT +DOCS +EXAMPLES +FTP -GNUTLS +GOPHER +GSSAPI_BASE > -GSSAPI_HEIMDAL -GSSAPI_MIT -GSSAPI_NONE +HTTP +HTTP2 -IDN +IMAP +IPV6 > -LDAP -LDAPS -LIBSSH +LIBSSH2 -MQTT +NTLM +OPENSSL +POP3 +PROXY +PSL > -RTMP +RTSP -SMB +SMTP +STATIC +TELNET +TFTP +THREADED_RESOLVER > +TLS_SRP -WEBSOCKET -WOLFSSL -ZSTD > > The difference seems to be +/-GSSAPI_BASE and +/-GSSAPI_NONE. > I have not set anything about > this in the port's options or jail's make.conf. > > What can I do to fix this? Maybe poudriere is confused by GSSAPI_${${SSL_DEFAULT} == base :?BASE :NONE} in OPTIONS_DEFAULT due ssl!=base in DEFAULT_VERSIONS via make.conf(5). Try filing a bug against ftp/curl. $ env -i __MAKE_CONF= PORT_DBDIR=/var/empty make -V '${OPTIONS_DEFAULT:M*GSS*}' GSSAPI_BASE $ env -i __MAKE_CONF= PORT_DBDIR=/var/empty DEFAULT_VERSIONS=ssl=openssl make -V '${OPTIONS_DEFAULT:M*GSS*}' GSSAPI_NONE See also https://cgit.freebsd.org/ports/diff/ftp/curl/Makefile?id=6d324c1f70c9 I can't reproduce on -CURRENT when only using base OpenSSL 3.0. From nobody Fri Aug 11 23:48:09 2023 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 4RN0q52KKQz4pwJS for ; Fri, 11 Aug 2023 23:48:17 +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 4RN0q362vnz4KRF; Fri, 11 Aug 2023 23:48:14 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; dkim=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; dmarc=none Received: from kalamity.joker.local (123-1-88-210.area1b.commufa.jp [123.1.88.210]) (authenticated bits=0) by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 37BNm9pY029666; Sat, 12 Aug 2023 08:48:09 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Sat, 12 Aug 2023 08:48:09 +0900 From: Tomoaki AOKI To: freebsd-current@freebsd.org Cc: ngie@FreeBSD.org Subject: Re: port lang/python27 does not build in 14.0-CURRENT w/ poudriere Message-Id: <20230812084809.26011cdb98127269cf3714d7@dec.sakura.ne.jp> In-Reply-To: References: <414B922C-C553-41D4-B519-E3B3B239B606@freebsd.org> <9A29A1BA-F957-40D9-96C6-062471BA14AF@freebsd.org> <5E811C16-5D72-44EC-A14B-06BB9FADB793@gmail.com> <2D0B1311-6E7C-4A34-970F-2BA9BFB9C34F@gmail.com> <6222a6d8-5940-fd27-af8f-222ee9fdcdb4@freebsd.org> <20230811080045.ce1eab46a48b3c86a0d4bf78@dec.sakura.ne.jp> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.2) 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=UTF-8 Content-Transfer-Encoding: 8bit X-Spamd-Result: default: False [1.56 / 15.00]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; NEURAL_HAM_SHORT(-0.97)[-0.967]; MV_CASE(0.50)[]; ONCE_RECEIVED(0.10)[]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_LONG(0.03)[0.029]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; MIME_TRACE(0.00)[0:+]; HAS_ORG_HEADER(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_NA(0.00)[no SPF record]; TO_DN_NONE(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DMARC_NA(0.00)[sakura.ne.jp]; RCVD_VIA_SMTP_AUTH(0.00)[] X-Spamd-Bar: + X-Rspamd-Queue-Id: 4RN0q362vnz4KRF Resent. Not yet sent from ML but later one was sent. Adding @freebsd.org address of Enji, as gmail does not accept mails from dec.sakura.ne.jp, which has neither DKIM functionality nor SPF record. On Thu, 10 Aug 2023 16:32:32 -0700 Enji Cooper wrote: > > On Aug 10, 2023, at 4:00 PM, Tomoaki AOKI wrote: > > > > On Thu, 10 Aug 2023 18:09:54 -0400 > > Charlie Li wrote: > > > >> Enji Cooper wrote: > >>> Hmm… All lang/python27 requiring ports should be marked BROKEN and > >>> removed — upstream stopped supporting 2.7 3.5 years ago (04/01/2020) :/. > >> We can't entirely do that yet. Unfortunately, moinmoin, original mailman > >> and the CSM for UEFI-EDK2 (used in bhyve) still staunchly require this. > >> It was the case that Chrom{e,ium} and qt-webengine still had Python 2 > >> build bits but they've since migrated off. > >> > >> -- > >> Charlie Li > >> …nope, still don't have an exit line. > > > > Can lang/tauthon used instead of lang/python27? > > It's a fork of python27 and maintained (slowly) like [1]. > > Lang/tauthon probably could be used instead. Even if original upstream is abandoned, maintained fork would better be allowed. If tauthon can be considered "well maintained", consumers of python27 which is enough compatible with tauthon can switch to tauthon and un-deprecated. > > I don't use python nor tauthon directly, though. > > I dislike languages killing backward compatibility... :-( > > > > I love C as even recent llvm/clang has an ability to compile K&R > > codes, if proper options are set. This is how ALL computer languages > > SHALL BE. > > The problem that python2 -> python3 was trying to solve was multifold: there were a variety of issues with the language, as defined in python2, which made the syntax changes going from 2 to 3 necessary. > > That being said, the whole “python2 is going away in 2020” was advertised well in advance (several years). If projects hadn’t done the work of getting off python2 by 2020, it’s their fault in not prioritizing that effort. > > The problem with packages like MoinMoin, etc, is that unless they’re completely isolated (vendor and provide all of their dependencies), they are likely developing pieces of software on vulnerable versions of third-party packages since many packages started yanking python2 support in the past couple years. Yanking python2 support allows third-party projects to be developed with more modern syntax niceties like the walrus operator, type hints, asyncio, etc. It’s not logical for pieces of software to not improve. > > Python is not C or Perl; the transition from 2 to 3 was particularly painful, but the changes were based on development that was over a decade in the making. If I'm the project owner of python, I would have been decided to abandon python and switch to different name because of backward incompatibility. But unfortunately, they didn't do so. If the software itself runs on python, I think you're completely right. It should be rewritten. But for softwares which uses python only on build time, staying on python27 should be allowed. In small projects, if the person who built the building environment retired from the project and noone else can understand / maintain the build system, the only selection is "stay there until someone who can construct new build environment pops in". This could happen here and there, unfortunately. For example, *Consider python27 and required py-* as bootstrapping tool. *Build python27 and required py-* everytime the port is built and cleanup afterwards, INSIDE PORTS WORKDIR. *python27 and required py-* are listed in distinfo of each port which requires python27 on build time only. would allow lang/python27 to be deleted, if possible. > > Cheers, > -Enji -- Tomoaki AOKI From nobody Sat Aug 12 00:11:54 2023 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 4RN1Lh3mLwz4pxtV for ; Sat, 12 Aug 2023 00:12:12 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-yb1-xb29.google.com (mail-yb1-xb29.google.com [IPv6:2607:f8b0:4864:20::b29]) (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 4RN1Lh1jSJz4MvK; Sat, 12 Aug 2023 00:12:12 +0000 (UTC) (envelope-from kob6558@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-yb1-xb29.google.com with SMTP id 3f1490d57ef6-d656d5e8265so1774615276.1; Fri, 11 Aug 2023 17:12:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691799131; x=1692403931; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=jyzNjgonHLRQeBEaPcFvdCYeJjaj+3okbdtgzZG+zfM=; b=GIF7LDJn+c1NdYfix2LILQUNNyzVQJgjUS6M4JUmjILoYki6kUOq6iUnaT6tgq5K/5 9wTCxNQFOWYgcpzW1pGO3U60C1bTNwQP19m7Cw7rhqDdcZmQ/59Sxo7sbVwesc40CQ8I WrQ7Xz1wTK3Sce55SXUZ8naWyXVxlx8GxqPLhG2nfwEUGpSinJSgejKK1unGaxv/xPuu WYChOz0DnlA8x8ih1/NKQbt4/azesW0C68JjQ0UkiSR3kB4gkoxET8AdisHvf7Jyg/7H 73AdObkj5bi7aANYWbiaIrSRwwYbwvKuyUtSe1xdsscb+a6aWvCJ5vxI1n4PvBKC2c4e GydQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691799131; x=1692403931; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=jyzNjgonHLRQeBEaPcFvdCYeJjaj+3okbdtgzZG+zfM=; b=jGxum/kjlKlGiqDshtEzUDGl1zuDIoJZFcGmK+baLtfEk1PO661AFZm2cOXLN5GWgi R3WaCDNTcQRZvBjZgIfg8lyzrolhWQaxidymh+IWor0kqOLQSwWZqnYZ7ll7bX3S5Xz/ ZR19aYUP+hcuvtc90o6fnWuuouJYQEGNpteltHq50O8iC7jM40tpZFN3X6HE7YONENHk IvGhaac0hGD5hy9WYPu1xPlXo6hM3+grmd+e1+n9Br0NJ0b2kErOTRRPhl0fS6YcNPeG +gQ/EQVrZtnbfXnXY+qJJdURJzOF91P0ZOpyO1Vxnd858iEdKCwFuxpoNzMLAdSQ2Ziq qcuw== X-Gm-Message-State: AOJu0Yx6zyU45H2EqlHZI0vecSayWX1PCCWfGbIOhLWUOsWPZBcZgH9F WC1nQB4vVoLqLrX5vv+1s2G2wW0AdHxwbvyXC3AUqWpP X-Google-Smtp-Source: AGHT+IG6zY6e2wu86lsByhbj9s3IlVWgYybSlu3+ImfVZZU+z0t9y9ZC2DEKeSuhX8d21Cx8AT0JXSgsL3dVTCFvqC0= X-Received: by 2002:a25:4251:0:b0:cfe:9981:2af3 with SMTP id p78-20020a254251000000b00cfe99812af3mr3222810yba.20.1691799130972; Fri, 11 Aug 2023 17:12:10 -0700 (PDT) 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: Kevin Oberman Date: Fri, 11 Aug 2023 17:11:54 -0700 Message-ID: Subject: Re: problem with poudriere && port ftp/curl To: Jan Beich Cc: freebsd-current@freebsd.org Content-Type: multipart/alternative; boundary="0000000000003ba9050602aeaeec" X-Rspamd-Queue-Id: 4RN1Lh1jSJz4MvK X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] --0000000000003ba9050602aeaeec Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Aug 11, 2023 at 3:00=E2=80=AFPM Jan Beich wrot= e: > Matthias Apitz writes: > > > I have the following problem with poudriere on 14-CURRENT and ports fro= m > > git head: every time when I start poudriere-bulk it removes a port > > already compile fine (and all its dependent ports) with the message: > > > > ... > > > The difference seems to be +/-GSSAPI_BASE and +/-GSSAPI_NONE. > > I have not set anything about > > this in the port's options or jail's make.conf. > > > > What can I do to fix this? > > Maybe poudriere is confused by GSSAPI_${${SSL_DEFAULT} =3D=3D base :?BASE > :NONE} > in OPTIONS_DEFAULT due ssl!=3Dbase in DEFAULT_VERSIONS via make.conf(5). > Try filing a bug against ftp/curl. > > $ env -i __MAKE_CONF=3D PORT_DBDIR=3D/var/empty make -V > '${OPTIONS_DEFAULT:M*GSS*}' > GSSAPI_BASE > $ env -i __MAKE_CONF=3D PORT_DBDIR=3D/var/empty DEFAULT_VERSIONS=3Dssl=3D= openssl > make -V '${OPTIONS_DEFAULT:M*GSS*}' > GSSAPI_NONE > > See also > https://cgit.freebsd.org/ports/diff/ftp/curl/Makefile?id=3D6d324c1f70c9 > > I can't reproduce on -CURRENT when only using base OpenSSL 3.0. > There are several ports with this problem. Since VirtualBox (and libvncserver) need openssl31, I now delete openssl31, upgrade ports as required, and then "package add /usr/ports/packages/All/openssl31-3.1.2.pkg" when finished. Just today I hit openldap-client trying to use openssl31 even though make.conf does not define it as default. Several other ports also don't honor the fairly new USES=3Dopenssl and, if they find an openssl installed, will use it. Since Aug. 1, I have had several other ports hit this issue. You really, really don't want ports using openssl31 unless you are sure that they or any port which they depend on are also using openssl31. If you get shareable libraries with conflicts, it is a pain to clean them up. Maybe a message to all committers that they need to be sure that OPENSSLBASE is not used without USES=3Dopenssl. (At least I believe that is the case.) --=20 Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkoberman@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 --0000000000003ba9050602aeaeec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Aug 11, 2023 at 3:00=E2= =80=AFPM Jan Beich <jbeich@freebsd= .org> wrote:
Matthias Apitz <guru@unixarea.de> writes:

> I have the following problem with poudriere on 14-CURRENT and ports fr= om
> git head: every time when I start poudriere-bulk it removes a port
> already compile fine (and all its dependent ports) with the message: >
> ...

> The difference seems to be +/-GSSAPI_BASE and +/-GSSAPI_NONE.
> I have not set anything about
> this in the port's options or jail's make.conf.
>
> What can I do to fix this?

Maybe poudriere is confused by GSSAPI_${${SSL_DEFAULT} =3D=3D base :?BASE := NONE}
in OPTIONS_DEFAULT due ssl!=3Dbase in DEFAULT_VERSIONS via make.conf(5). Try filing a bug against ftp/curl.

$ env -i __MAKE_CONF=3D PORT_DBDIR=3D/var/empty make -V '${OPTIONS_DEFA= ULT:M*GSS*}'
GSSAPI_BASE
$ env -i __MAKE_CONF=3D PORT_DBDIR=3D/var/empty DEFAULT_VERSIONS=3Dssl=3Dop= enssl make -V '${OPTIONS_DEFAULT:M*GSS*}'
GSSAPI_NONE

See also https://cgit.freebsd= .org/ports/diff/ftp/curl/Makefile?id=3D6d324c1f70c9

I can't reproduce on -CURRENT when only using base OpenSSL 3.0.
=C2=A0
There are several ports with this= problem. Since VirtualBox (and libvncserver) need openssl31, I now delete = openssl31, upgrade ports as required, and then "package add /usr/ports= /packages/All/openssl31-3.1.2.pkg" when finished.

<= /div>
Just today I hit openldap-client trying to use openssl31 eve= n though make.conf does not define it as default. Several other ports also = don't honor the fairly new USES=3Dopenssl and, if they find an openssl = installed, will use it. Since Aug. 1, I have had several other ports hit th= is issue. You really, really don't want ports using openssl31 unless yo= u are sure that they or any port which they depend on are also using openss= l31. If you get shareable libraries with conflicts, it is a pain to clean t= hem up. Maybe a message to all committers that they need to be sure that OP= ENSSLBASE is not used without USES=3Dopenssl. (At least I believe that is t= he case.)


--
Kevin= Oberman, Part time kid herder and retired Network Engineer
E-mail: rkoberman@gmail.com
--0000000000003ba9050602aeaeec-- From nobody Sat Aug 12 03:15:49 2023 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 4RN5Qb4Zzrz4qBsS; Sat, 12 Aug 2023 03:15:51 +0000 (UTC) (envelope-from gjb@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 4RN5Qb43Nqz4g0H; Sat, 12 Aug 2023 03:15:51 +0000 (UTC) (envelope-from gjb@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1691810151; 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=+xz9+xZfDbIy6LCsneJjlituod8xedspF2CJcl1qKbc=; b=VdgiptXF04SvFb+iFh/D7GUoHMuDlZWJWm8D/lGd5x+iShWdmbHwBxYFNrFlUHdTWdeWsp mqYNitbMJYgyW0vJOuvxXvPa0UWWFJ2hXAKlCJAs87q+EXCOukx4NLS4AqC5LiakM3vBvy eiXBcea9Za6YC1VHmRQeomYHXyrWK6s6c//op43OPw67aG7Aya1ZnGuiwGJ2c5vBJ8y5w9 uumX+iY5Hh3GSueOCdqIMrAKDEz9fsEIYSqi9KZE1A2bkrQT+V33RLxV+bZQuZ8UZo6h4e 5ysmX686YhDX+aG+mqFL04xvQAXX52fsFrzfpj+AAfqHo55IwM3BgyA3MO1ESw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1691810151; 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=+xz9+xZfDbIy6LCsneJjlituod8xedspF2CJcl1qKbc=; b=qQhdHxLzf8VbQ5ti+Mnt0tfpp47ZO986NYj1sgPbSRy7seRzCH8k9MFvnJIlDsSkPR3Vh3 BL2WpHHKmr8CDmMVulARUgAlC/oETGh5ttRGZ65zhKuSXEar7edCBHQjXl4ouOEYFBtJgV bTNDCLCggSfFiDDVyQiDuBxIy5aTRJyxptuALtRd5ts2/jf3EYu+3Gs72GDuu6lYamYNAA F+HUlqshqcr1i25tY2/x1FbCCybCiXR3xl3SXF5KOnSK4XYctSzXYMXc6A2lx7Ep7+gDwA BI8VAPfI43ujnYxNHVOLwjDijRA205JoE+lO7Y1AxrNWZKZjjley9oYCyG2Eyw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1691810151; a=rsa-sha256; cv=none; b=doBDMtDMSpTNUS5RVpigqWIAPBQLIEl3i7i6xjgb9pLpwgP/yxe1k84/vRXR345bq2mgHx UAon6VT3r6ZCqVvaG/xw74/L8Z9qcmvO1VPpMmtmmO8wepDzANBPrDJ8R2bQFRDYCiwO6g TMOZX/JLN8ucNKgK0ooiGh2SphhJC2W7kDiG4lLqcOewdW/JzQ4wAyHB1aL8BZmJTUcd+e /pQ+/NsLmb0DmDm6bwOM3FSVwp5mpkzDQDfZTNKvOlfwCkqbobEr3qzDD+zeS16zf8VqQS NHQPoZtbd5vIBr0Z1MTCoW/4EnwCWCqDVSvK3tm4lQYHt4W+i/pcNTzFK0LfSw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id 1F546198E9; Sat, 12 Aug 2023 03:15:51 +0000 (UTC) (envelope-from gjb@freebsd.org) Date: Sat, 12 Aug 2023 03:15:49 +0000 From: Glen Barber To: freebsd-snapshots@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org Cc: FreeBSD Release Engineering Team Subject: Re: New FreeBSD snapshots available: stable/14 (ALPHA1) (20230811 136fc495615f) Message-ID: <20230812031548.GA1219@FreeBSD.org> References: <20230811205312.GF52318@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="9/lmB/GmAksD4Nrg" Content-Disposition: inline In-Reply-To: <20230811205312.GF52318@FreeBSD.org> --9/lmB/GmAksD4Nrg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 11, 2023 at 08:53:12PM +0000, Glen Barber wrote: [...] > FreeBSD/aarch64 UFS EC2 AMIs are available in the following regions: >=20 [...] >=20 > FreeBSD/aarch64 ZFS EC2 AMIs are available in the following regions: >=20 [...] It was discovered that due to human error (my own) the arm64 are, as Colin put it very politely, are "lacking 'arminess'". So, unfortunately the arm64 AMIs for 14.0-ALPHA1 are incorrectly uploaded as amd64. But you will receive a message stating it is the incorrect architecture, which is better than passively failing. Apologies for the inconvenience. Glen --9/lmB/GmAksD4Nrg Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEjRJAPC5sqwhs9k2jAxRYpUeP4pMFAmTW+WQACgkQAxRYpUeP 4pOypw/+NbwFUrr9IiFv/72i3DSBJWFqFyI7j0deupyazJtG7ytlvY2UUPLiug25 GTB0NPFdinl9lGMRszd5xuA5tpQSa2ApeGrorIwCc3w43EADo3JiJhvlUi+jK+ka KiriiL4q0pONQWWuZJ0g8qLjk/CllorVa20/YS6In5C/wMPAZF3AaxnUT2ArzYD3 ZSsSc+KZvqBLMVXxTFVYOOGTiUqM2Tzf0LEu7eT33O5B0LHhqYRQKYHNlbrHbbZA OImduibhnnwyTrCzjyVfFGyzaCI/mugnRfbdsbKFrCUieWJIoDzzOvndN0n0KN+d BtVXVG3KnSCAOM4dxWuEU3tQPKi8EM4eOJ70iGCH90e1MjIklLUl4lC8gOygjuTt eEGk6wUTZeFywppVyLp9V/TQIo+eTB8YeoKzJaYm3cfhedtjqHhK4g9qZZwMOfLx F/5YCQzRas+JHs9PWclB8GCc9H4Xc2VCYu++taObUocjzcUQCbneln8FmoQA+l88 yJioFwZAhgM/UXkeSTMHiBfTC84a9MP+otgAYUMD940fkCqd5rvBCFpKA00xSBPl OTHDf9SXDVeh5nUh9Uve4G2mNhQicm8aJjYwiwHF4dWqa0jk9lDHTTnZPII2EsrK a6rsswGl573xIdEXdtSlnN498e98dW9LZrPui/vajhQUoeaBYGQ= =eRmZ -----END PGP SIGNATURE----- --9/lmB/GmAksD4Nrg-- From nobody Sat Aug 12 03:29:38 2023 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 4RN5kZ3LtXz4qCrL for ; Sat, 12 Aug 2023 03:29:42 +0000 (UTC) (envelope-from madis555@gmail.com) Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) (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 4RN5kX6gPwz3DvP; Sat, 12 Aug 2023 03:29:40 +0000 (UTC) (envelope-from madis555@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20221208 header.b=nwLwSw7r; spf=pass (mx1.freebsd.org: domain of madis555@gmail.com designates 2607:f8b0:4864:20::102d as permitted sender) smtp.mailfrom=madis555@gmail.com; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=hot.ee (policy=reject) Received: by mail-pj1-x102d.google.com with SMTP id 98e67ed59e1d1-26871992645so1786102a91.0; Fri, 11 Aug 2023 20:29:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691810979; x=1692415779; h=cc:to:subject:message-id:date:from:references:in-reply-to:sender :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ra8KDOIr+kVv7iKcrp8dKRSiEKL1AUr+wdL5Oujv5i0=; b=nwLwSw7rEdDrrW73v4Wrqpg/svRXz+6NAvKkc4I2rBceNRi0bjdPpQ5ow1jGG4wcTD bNQ2kd06vfHAa5aTL1RuyDOJCdYcXalfp/TSHG+GZc9XR2xqCFHkfWi8peY+rDGf9A2o Jpyz5Yu54r3pi7NIBizfmc4pCVjvrYPiVTlLSSeEvs/KsGr8TOuyzEi53jHQ3ViXBvhf JtjTCsMHArqRZ81fszO3mmPnPFhI5uSmis2Nw19cOE8g3d2K5r4l/gSuZuhjU2g1xn+h HKNY2LFfeD1dJrsv5X7FMkv/C3aVXo1gDRwfLcREUQBGYB/L5wXYKQLazJNd6FNODEts F/0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691810979; x=1692415779; h=cc:to:subject:message-id:date:from:references:in-reply-to:sender :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ra8KDOIr+kVv7iKcrp8dKRSiEKL1AUr+wdL5Oujv5i0=; b=ROhyQ+Nru3byvB3XncwjuJJA5qYULqca6e7PamF3cFbeJEqU1nbYsB6279n+SgjRPX DLajoxUW6dHtbP+237DEm3fSwUgj3fzpP4rxISN2kfVdywhu7DFagrRe+EY6LLl6SOjX 83MX8UgZy10Yjro/UJ60bcuZAzqEuOL5Qh5Zm2JVYbwM8q34kde7oDjleBm66+ZaLLg7 3WuSVDCxT5Oq1MGRavG0grI0yHmrbkAHs5jnil86wwPzd3gTCMYxZ/Bqmdvuus70jkbQ HZbUUQ0UZE+0vfGBydGn3DRuWikgC6OoxaAk/VKd6MpzTombO5KsZXTWhijnSvhHbmeO RDZw== X-Gm-Message-State: AOJu0YxACYO8C0dJi1TpK5aAtcKE2TJ6bZj+HoOtmuLFlt89qMcMKem7 6d0IE85szctEF8tAayQammUdzmfRkrfCCV9PnaA= X-Google-Smtp-Source: AGHT+IGCFzvzNP823L923tIO6H6kCtVtsiVmL+oOcDqKk+9ovpToI0h2CnwWzoinbgDBqOPGyccyAvaJsadoCYtEUVI= X-Received: by 2002:a17:90a:294e:b0:263:9816:fe0f with SMTP id x14-20020a17090a294e00b002639816fe0fmr3179720pjf.15.1691810978828; Fri, 11 Aug 2023 20:29:38 -0700 (PDT) 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:ac4:ac8a:0:b0:624:beb4:2d with HTTP; Fri, 11 Aug 2023 20:29:38 -0700 (PDT) In-Reply-To: <95f063b3-e122-cfa8-f9fd-9ca2365d663e@fork.id.au> References: <1a77457f-319a-1025-f969-3c294dcc7432@fork.id.au> <95f063b3-e122-cfa8-f9fd-9ca2365d663e@fork.id.au> From: Sulev-Madis Silber Date: Sat, 12 Aug 2023 06:29:38 +0300 X-Google-Sender-Auth: eRWtuKU5UcnGjpCCEkzboZ4q2so Message-ID: Subject: Re: The future for support of BeagleBone Black and its variants To: George Abdelmalik Cc: David Chisnall , FreeBSD Current Content-Type: multipart/alternative; boundary="0000000000006b9ac50602b1702c" X-Spamd-Result: default: False [-1.20 / 15.00]; DMARC_POLICY_REJECT(2.00)[hot.ee : SPF not aligned (relaxed), DKIM not aligned (relaxed),reject]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.996]; FORGED_SENDER(0.30)[madis555@hot.ee,madis555@gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20221208]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::102d:from]; TO_DN_ALL(0.00)[]; FROM_NEQ_ENVFROM(0.00)[madis555@hot.ee,madis555@gmail.com]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FREEMAIL_FROM(0.00)[hot.ee]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-Spamd-Bar: - X-Rspamd-Queue-Id: 4RN5kX6gPwz3DvP --0000000000006b9ac50602b1702c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable i wonder what's the latest point in repository that DOES work? my bbb runs current from year 2014, it does run well and off emmc. it's awfully crap compared to my h3 but i would still like to have something on it. when i started working with embedded hw again, i took that out of box too, expected to seamlessly run latest current on that still, only to found out that doesn't work... On Thursday, August 10, 2023, George Abdelmalik wrote: > Hi David, > > The problems are kernel related. If I understand correctly it's in the area of clock definitions I think but I've not properly studied the patches= . > > DTC is good. > > Regards, > George. > > > On 10/8/23 14:52, David Chisnall wrote: >> >> Hi, >> >> What are the changes to the DTS files? If there are problems with DTC handling the new files, please can you raise issues here: https://github.com/davidchisnall/dtc/issues >> >> If there are problems with the kernel=E2=80=99s handling of the dtb, ple= ase ignore me. >> >> David >> >>> On 10 Aug 2023, at 13:24, George Abdelmalik wrote: >>> >>> =EF=BB=BFHi all, >>> >>> For a long while now CURRENT has not been working on the BBB due to incompatible upstream changes in vendor DTS files. I know there are some patches available which at least get FreeBSD running but those have yet to be incorporated into the project's repository. >>> >>> This leaves me with the feeling that BBB support in FreeBSD is on the path to being dropped. Is there someone from the FreeBSD project that could speak directly to this? >>> >>> As a user it would be helpful to know if I should be searching of an alternate SBC platform or another OS for my projects. >>> >>> If it still remains the plan to keep supporting BBB into 14.0 and beyond then I'd like to know what work is missing to make that happen. I'm willing and able to help. >>> >>> Regards, >>> George. >>> >>> >>> > > --0000000000006b9ac50602b1702c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable i wonder what's the latest point in repository that DOES work? my bbb r= uns current from year 2014, it does run well and off emmc. it's awfully= crap compared to my h3 but i would still like to have something on it. whe= n i started working with embedded hw again, i took that out of box too, exp= ected to seamlessly run latest current on that still, only to found out tha= t doesn't work...

On Thursday, August 10, 2023, George Abdelmali= k <george@fork.id.au> wrote:=
> Hi David,
>
> The problems are kernel related. If I un= derstand correctly it's in the area of clock definitions I think but I&= #39;ve not properly studied the patches.
>
> DTC is good.
&g= t;
> Regards,
> George.
>
>
> On 10/8/23 14:5= 2, David Chisnall wrote:
>>
>> Hi,
>>
>>= ; What are the changes to the DTS files? If there are problems with DTC han= dling the new files, please can you raise issues here: https://github.com/davidchisnall/dtc/is= sues
>>
>> If there are problems with the kernel=E2= =80=99s handling of the dtb, please ignore me.
>>
>> Davi= d
>>
>>> On 10 Aug 2023, at 13:24, George Abdelmalik &= lt;george@fork.id.au> wrote:>>>
>>> =EF=BB=BFHi all,
>>>
>>&= gt; For a long while now CURRENT has not been working on the BBB due to inc= ompatible upstream changes in vendor DTS files. I know there are some patch= es available which at least get FreeBSD running but those have yet to be in= corporated into the project's repository.
>>>
>>&g= t; This leaves me with the feeling that BBB support in FreeBSD is on the pa= th to being dropped. Is there someone from the FreeBSD project that could s= peak directly to this?
>>>
>>> As a user it would b= e helpful to know if I should be searching of an alternate SBC platform or = another OS for my projects.
>>>
>>> If it still rem= ains the plan to keep supporting BBB into 14.0 and beyond then I'd like= to know what work is missing to make that happen. I'm willing and able= to help.
>>>
>>> Regards,
>>> George.<= br>>>>
>>>
>>>
>
> --0000000000006b9ac50602b1702c-- From nobody Sat Aug 12 04:55:40 2023 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 4RN7ds4zWZz4TnHD for ; Sat, 12 Aug 2023 04:55:45 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta001.cacentral1.a.cloudfilter.net (omta001.cacentral1.a.cloudfilter.net [3.97.99.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RN7dq5x6dz3NpK; Sat, 12 Aug 2023 04:55:43 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 3.97.99.32) smtp.mailfrom=cy.schubert@cschubert.com; dmarc=none Received: from shw-obgw-4004a.ext.cloudfilter.net ([10.228.9.227]) by cmsmtp with ESMTP id UQdOq0dPsLAoIUgf9qWRaa; Sat, 12 Aug 2023 04:55:43 +0000 Received: from spqr.komquats.com ([70.66.152.170]) by cmsmtp with ESMTPA id Ugf7qqs2e3fOSUgf8qsrZS; Sat, 12 Aug 2023 04:55:43 +0000 X-Authority-Analysis: v=2.4 cv=J8G5USrS c=1 sm=1 tr=0 ts=64d710cf a=y8EK/9tc/U6QY+pUhnbtgQ==:117 a=y8EK/9tc/U6QY+pUhnbtgQ==:17 a=kj9zAlcOel0A:10 a=UttIx32zK-AA:10 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=NEAV23lmAAAA:8 a=SLG1KRGDAAAA:8 a=YSBoMgAGpdedK1I-WFkA:9 a=G8qsWpk2SOyw_Jid:21 a=CjuIK1q_8ugA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=LK5xJRSDVpKd5WXXoEvA:22 a=-TBaU1e9WpdkKBzYXnwo:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id 31E6C955; Fri, 11 Aug 2023 21:55:41 -0700 (PDT) Received: by slippy.cwsent.com (Postfix, from userid 1000) id 118E5217; Fri, 11 Aug 2023 21:55:41 -0700 (PDT) X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.8+dev Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Cy Schubert cc: Kevin Bowling , =?UTF-8?Q?Dag=2DErling_Sm=C3=B8rgrav?= , current@freebsd.org Subject: Re: ZFS deadlock in 14 Comments: In-reply-to Cy Schubert message dated "Fri, 11 Aug 2023 20:41:29 -0700." 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 Date: Fri, 11 Aug 2023 21:55:40 -0700 Message-Id: <20230812045541.118E5217@slippy.cwsent.com> X-CMAE-Envelope: MS4xfB/nBsIrDvZdhPxg9pvW8hYre3o5ovZtdapNOLZ+uKZzTJNtO4SydKxQkf+8BuLNM+9MRYzrhKqBVM5UpY+LDvgOLWz/EX2Ma+h41wc6U81G9udZqXfD WXGVaIfXSVwgy/O1yPbwQyR2X0w5azqffujmrCeQNu8PwdHoJ/dU2n2AzKMXuKkg1RvgbKeocvWSdiynMLdGryImTf/+XYXtLF1dpCBw2DSaSGZoe85Czl84 LEAkvvGTALPgS71GLIUiOY98qVHmZXanG3BaZiezMAw= X-Spamd-Result: default: False [-0.65 / 15.00]; FAKE_REPLY(1.00)[]; AUTH_NA(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; NEURAL_HAM_LONG(-0.95)[-0.954]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[3.97.99.32:from]; RCPT_COUNT_THREE(0.00)[4]; DMARC_NA(0.00)[cschubert.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; BLOCKLISTDE_FAIL(0.00)[3.97.99.32:server fail]; REPLYTO_EQ_FROM(0.00)[]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; MLMMJ_DEST(0.00)[current@freebsd.org]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US]; R_SPF_NA(0.00)[no SPF record] X-Spamd-Bar: / X-Rspamd-Queue-Id: 4RN7dq5x6dz3NpK The poudriere build machine building amd64 packages also panicked. But with: Dumping 2577 out of 8122 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91 % __curthread () at /opt/src/git-src/sys/amd64/include/pcpu_aux.h:59 59 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct pcpu , (kgdb) #0 __curthread () at /opt/src/git-src/sys/amd64/include/pcpu_aux.h:5 9 #1 doadump (textdump=textdump@entry=1) at /opt/src/git-src/sys/kern/kern_shutdown.c:407 #2 0xffffffff806c10e0 in kern_reboot (howto=260) at /opt/src/git-src/sys/kern/kern_shutdown.c:528 #3 0xffffffff806c15df in vpanic ( fmt=0xffffffff80b6c5f5 "%s: possible deadlock detected for %p (%s), blocked for %d ticks\n", ap=ap@entry=0xfffffe008e698e90) at /opt/src/git-src/sys/kern/kern_shutdown.c:972 #4 0xffffffff806c1383 in panic (fmt=) at /opt/src/git-src/sys/kern/kern_shutdown.c:896 #5 0xffffffff8064a5ea in deadlkres () at /opt/src/git-src/sys/kern/kern_clock.c:201 #6 0xffffffff80677632 in fork_exit (callout=0xffffffff8064a2c0 , arg=0x0, frame=0xfffffe008e698f40) at /opt/src/git-src/sys/kern/kern_fork.c:1162 #7 (kgdb) This is consistent with PR/271945. Reducing -J to 1 or 5:1 circumvents this panic. This is certainly a different panic from the one experienced on the poudriere builder building i386 packages. Both machines run in amd64 mode. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=0 Cy Schubert writes: > This is new. Instead of affecting the machine with poudriere building amd64 > packages, it affected the other machine with poudriere building i386 > packages. This is new since the two recent ZFS patches. > > Don't get me wrong, the two new patches have resulted in I believe better > availability of the poudriere machine building amd64 packages. I doubt the > two patches caused this but they may have exposed this problem, probably > fixed by another patch or two. > > Sorry, there was no dump produced by this panic. I'll need to check the > config of this machine, swap is a gmirror, which it doesn't like to dump > to. Below are serial console messages captured by conserver. > > panic: vm_page_dequeue_deferred: page 0xfffffe00028fb0d0 has unexpected > queue state^M > cpuid = 3^M > time = 1691807572^M > KDB: stack backtrace:^M > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > 0xfffffe00c50bc600^M > vpanic() at vpanic+0x132/frame 0xfffffe00c50bc730^M > panic() at panic+0x43/frame 0xfffffe00c50bc790^M > vm_page_dequeue_deferred() at vm_page_dequeue_deferred+0xb2/frame > 0xfffffe00c50bc7a0^M > vm_page_free_prep() at vm_page_free_prep+0x11b/frame 0xfffffe00c50bc7c0^M > vm_page_free_toq() at vm_page_free_toq+0x12/frame 0xfffffe00c50bc7f0^M > vm_object_page_remove() at vm_object_page_remove+0xb6/frame > 0xfffffe00c50bc850^M > vn_pages_remove_valid() at vn_pages_remove_valid+0x48/frame > 0xfffffe00c50bc880^M > zfs_rezget() at zfs_rezget+0x35/frame 0xfffffe00c50bca60^M > zfs_resume_fs() at zfs_resume_fs+0x1c8/frame 0xfffffe00c50bcab0^M > zfs_ioc_rollback() at zfs_ioc_rollback+0x157/frame 0xfffffe00c50bcb00^M > zfsdev_ioctl_common() at zfsdev_ioctl_common+0x612/frame > 0xfffffe00c50bcbc0^M > zfsdev_ioctl() at zfsdev_ioctl+0x12a/frame 0xfffffe00c50bcbf0^M > devfs_ioctl() at devfs_ioctl+0xd2/frame 0xfffffe00c50bcc40^M > vn_ioctl() at vn_ioctl+0xc2/frame 0xfffffe00c50bccb0^M > devfs_ioctl_f() at devfs_ioctl_f+0x1e/frame 0xfffffe00c50bccd0^M > kern_ioctl() at kern_ioctl+0x286/frame 0xfffffe00c50bcd30^M > sys_ioctl() at sys_ioctl+0x152/frame 0xfffffe00c50bce00^M > amd64_syscall() at amd64_syscall+0x138/frame 0xfffffe00c50bcf30^M > fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe00c50bcf30^M > --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x20938296107a, rsp = > 0x209379aeee18, rbp = 0x209379aeee90 ---^M > Uptime: 42m33s^M > Automatic reboot in 15 seconds - press a key on the console to abort^M > Rebooting...^M > cpu_reset: Restarting BSP^M > cpu_reset_proxy: Stopped CPU 3^M > > > -- > Cheers, > Cy Schubert > FreeBSD UNIX: Web: https://FreeBSD.org > NTP: Web: https://nwtime.org > > e^(i*pi)+1=0 > > > Cy Schubert writes: > > I haven't experienced any problems (yet) either. > > > > > > -- > > Cheers, > > Cy Schubert > > FreeBSD UNIX: Web: https://FreeBSD.org > > NTP: Web: https://nwtime.org > > > > e^(i*pi)+1=0 > > > > > > In message c > > om> > > , Kevin Bowling writes: > > > The two MFVs on head have improved/fixed stability with poudriere for > > > me 48 core bare metal. > > > > > > On Thu, Aug 10, 2023 at 6:37=E2=80=AFAM Cy Schubert t. > > = > > > com> wrote: > > > > > > > > In message ai > > = > > > l.c > > > > om> > > > > , Kevin Bowling writes: > > > > > Possibly https://github.com/openzfs/zfs/commit/2cb992a99ccadb78d97049 > b4 > > = > > > 0bd4=3D > > > > > 42eb4fdc549d > > > > > > > > > > On Tue, Aug 8, 2023 at 10:08=3DE2=3D80=3DAFAM Dag-Erling Sm=3DC3=3DB8 > rg > > = > > > rav > > > > sd.org> wrote: > > > > > > > > > > > > At some point between 42d088299c (4 May) and f0c9703301 (26 June), > a > > > > > > deadlock was introduced in ZFS. It is still present as of 9c2823ba > e9 > > = > > > (4 > > > > > > August) and is 100% reproducable just by starting poudriere bulk in > a > > > > > > 16-core VM and waiting a few hours until deadlkres kicks in. In th > e > > > > > > latest instance, deadlkres complained about a bash process: > > > > > > > > > > > > #0 sched_switch (td=3D3Dtd@entry=3D3D0xfffffe02fb1d8000, flags > = > > > =3D3Dflags@e=3D > > > > > ntry=3D3D259) at /usr/src/sys/kern/sched_ule.c:2299 > > > > > > #1 0xffffffff80b5a0a3 in mi_switch (flags=3D3Dflags@entry=3D3D > 25 > > = > > > 9) at /u=3D > > > > > sr/src/sys/kern/kern_synch.c:550 > > > > > > #2 0xffffffff80babcb4 in sleepq_switch (wchan=3D3D0xfffff81854 > 3a > > = > > > 9e70, =3D > > > > > pri=3D3D64) at /usr/src/sys/kern/subr_sleepqueue.c:609 > > > > > > #3 0xffffffff80babb8c in sleepq_wait (wchan=3D3D, > p > > = > > > ri=3D3D<=3D > > > > > unavailable>) at /usr/src/sys/kern/subr_sleepqueue.c:660 > > > > > > #4 0xffffffff80b1c1b0 in sleeplk (lk=3D3Dlk@entry=3D3D0xfffff8 > 18 > > = > > > 543a9e70=3D > > > > > , flags=3D3Dflags@entry=3D3D2121728, ilk=3D3Dilk@entry=3D3D0x0, wmesg > = > > > =3D3Dwmesg@entry=3D > > > > > =3D3D0xffffffff8222a054 "zfs", pri=3D3D, pri@entry=3D3 > D6 > > = > > > 4, timo=3D3D=3D > > > > > timo@entry=3D3D6, queue=3D3D1) at /usr/src/sys/kern/kern_lock.c:310 > > > > > > #5 0xffffffff80b1a23f in lockmgr_slock_hard (lk=3D3D0xfffff818 > 54 > > = > > > 3a9e70=3D > > > > > , flags=3D3D2121728, ilk=3D3D, file=3D3D0xffffffff8125 > 44 > > = > > > fb "/usr/s=3D > > > > > rc/sys/kern/vfs_subr.c", line=3D3D3057, lwa=3D3D0x0) at /usr/src/sys/ > ke > > = > > > rn/kern_=3D > > > > > lock.c:705 > > > > > > #6 0xffffffff80c59ec3 in VOP_LOCK1 (vp=3D3D0xfffff818543a9e00, > f > > = > > > lags=3D > > > > > =3D3D2105344, file=3D3D0xffffffff812544fb "/usr/src/sys/kern/vfs_subr > .c > > = > > > ", line=3> > > > > =3D3D3057) at ./vnode_if.h:1120 > > > > > > #7 _vn_lock (vp=3D3Dvp@entry=3D3D0xfffff818543a9e00, flags=3D3 > D2 > > = > > > 105344, fi=3D > > > > > le=3D3D, line=3D3D, line@entry=3D3D3057) at > / > > = > > > usr/src/sy=3D > > > > > s/kern/vfs_vnops.c:1815 > > > > > > #8 0xffffffff80c4173d in vget_finish (vp=3D3D0xfffff818543a9e0 > 0, > > = > > > flags=3D > > > > > =3D3D, vs=3D3Dvs@entry=3D3DVGET_USECOUNT) at /usr/src/sy > s/ > > = > > > kern/vfs_s=3D > > > > > ubr.c:3057 > > > > > > #9 0xffffffff80c1c9b7 in cache_lookup (dvp=3D3Ddvp@entry=3D3D0 > xf > > = > > > ffff802c=3D > > > > > d02ac40, vpp=3D3Dvpp@entry=3D3D0xfffffe046b20ac30, cnp=3D3Dcnp@entry= > 3D > > = > > > 3D0xfffffe04=3D > > > > > 6b20ac58, tsp=3D3Dtsp@entry=3D3D0x0, ticksp=3D3Dticksp@entry=3D3D0x0) > a > > = > > > t /usr/src/s=3D > > > > > ys/kern/vfs_cache.c:2086 > > > > > > #10 0xffffffff80c2150c in vfs_cache_lookup (ap=3D3D ut > > = > > > >) at =3D > > > > > /usr/src/sys/kern/vfs_cache.c:3068 > > > > > > #11 0xffffffff80c32c37 in VOP_LOOKUP (dvp=3D3D0xfffff802cd02ac4 > 0, > > = > > > vpp=3D > > > > > =3D3D0xfffffe046b20ac30, cnp=3D3D0xfffffe046b20ac58) at ./vnode_if.h: > 69 > > > > > > #12 vfs_lookup (ndp=3D3Dndp@entry=3D3D0xfffffe046b20abd8) at /u > sr > > = > > > /src/sys=3D > > > > > /kern/vfs_lookup.c:1266 > > > > > > #13 0xffffffff80c31ce1 in namei (ndp=3D3Dndp@entry=3D3D0xfffffe > 04 > > = > > > 6b20abd8=3D > > > > > ) at /usr/src/sys/kern/vfs_lookup.c:689 > > > > > > #14 0xffffffff80c52090 in kern_statat (td=3D3D0xfffffe02fb1d800 > 0, > > = > > > flag=3D > > > > > =3D3D, fd=3D3D-100, path=3D3D0xa75b480e070 no > > = > > > t access m=3D > > > > > emory at address 0xa75b480e070>, pathseg=3D3Dpathseg@entry=3D3DUIO_US > ER > > = > > > SPACE, s=3D > > > > > bp=3D3Dsbp@entry=3D3D0xfffffe046b20ad18) > > > > > > at /usr/src/sys/kern/vfs_syscalls.c:2441 > > > > > > #15 0xffffffff80c52797 in sys_fstatat (td=3D3D, ua > p= > > > =3D3D0xff=3D > > > > > fffe02fb1d8400) at /usr/src/sys/kern/vfs_syscalls.c:2419 > > > > > > #16 0xffffffff From nobody Sat Aug 12 06:04:29 2023 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 4RN99K6TNnz4Tt8N for ; Sat, 12 Aug 2023 06:04:37 +0000 (UTC) (envelope-from SRS0=Nd7+=D5=klop.ws=ronald-lists@realworks.nl) Received: from smtp-relay-int-backup.realworks.nl (smtp-relay-int-backup.realworks.nl [87.255.56.188]) (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 4RN99J5rfWz3Tjy; Sat, 12 Aug 2023 06:04:36 +0000 (UTC) (envelope-from SRS0=Nd7+=D5=klop.ws=ronald-lists@realworks.nl) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=klop.ws header.s=rw2 header.b="WWC6/vsx"; spf=pass (mx1.freebsd.org: domain of "SRS0=Nd7+=D5=klop.ws=ronald-lists@realworks.nl" designates 87.255.56.188 as permitted sender) smtp.mailfrom="SRS0=Nd7+=D5=klop.ws=ronald-lists@realworks.nl"; dmarc=pass (policy=quarantine) header.from=klop.ws Received: from rwvirtual375.colo.realworks.nl (rwvirtual375.colo.realworks.nl [10.0.10.75]) by mailrelayint2.colo2.realworks.nl (Postfix) with ESMTP id 4RN9992gB0z2ynm; Sat, 12 Aug 2023 08:04:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1691820269; 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=JzlWz/UewCDVRv9oODYMK+tlVB0Zvoz5Xy9i/+Ooik0=; b=WWC6/vsxG4x5InZQXCHvdmoT5pezCPfe2tralJQ68CGmzOWvqkoDMJW9l3cFN4nvRcNAz/ tk6e2Wc1r1Nq3wemERIcOUCPZ0+c1AhQYsUp5X3tSttycC+Vbz9yVuXEXanYuFqa/CXQ5o W3CgiBgfV6pusJTXWLRkh9DjSjExC0nxzsI39D+j9RgUJaag9GuCOzUoDHxndEnTWFKc9n AAl3BcQKQqCVtip9uMZua3uPUtRuWvDgxD9t5OLFJH7nefIrZvzORWMrhoN7qadWk2zz25 QbHx19/YDzS1Inl9Aj0pKeBxsYdnnIEknHkTOKEI8PTUt0cWpyVYsh0m35e+9g== Received: from rwvirtual375.colo.realworks.nl (localhost [127.0.0.1]) by rwvirtual375.colo.realworks.nl (Postfix) with ESMTP id 4BE5640327; Sat, 12 Aug 2023 08:04:29 +0200 (CEST) Date: Sat, 12 Aug 2023 08:04:29 +0200 (CEST) From: Ronald Klop To: Ed Maste , freebsd-current@freebsd.org Message-ID: <1921364631.8151.1691820269255@localhost> Subject: ssh 9.4 fails to build 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_8150_2126601897.1691820268996" X-Mailer: Realworks (666.161) X-Originating-Host: from (84-105-120-103.cable.dynamic.v4.ziggo.nl [84.105.120.103]) by rwvirtual375 [10.0.10.75] with HTTP; Sat, 12 Aug 2023 08:04:29 +0200 Importance: Normal X-Priority: 3 (Normal) X-Originating-User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/116.0 X-Spamd-Result: default: False [-3.19 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.992]; DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine]; MID_RHS_NOT_FQDN(0.50)[]; FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=Nd7@realworks.nl]; R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2]; R_SPF_ALLOW(-0.20)[+ip4:87.255.56.128/26]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_TLS_LAST(0.00)[]; TAGGED_FROM(0.00)[=D5=klop.ws=ronald-lists]; ASN(0.00)[asn:38930, ipnet:87.255.32.0/19, country:NL]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCPT_COUNT_TWO(0.00)[2]; FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=Nd7@realworks.nl]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; HAS_X_PRIO_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; DKIM_TRACE(0.00)[klop.ws:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-Spamd-Bar: --- X-Rspamd-Queue-Id: 4RN99J5rfWz3Tjy ------=_Part_8150_2126601897.1691820268996 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, I get this error while building world. NB: I'm building with llvm15 from a pkg. But I don't think that should make a difference. ld.lld: error: undefined symbol: Fssh_lib_contains_symbol >>> referenced by ssh-pkcs11.c:1538 (/usr/src/crypto/openssh/ssh-pkcs11.c:1538) >>> ssh-pkcs11.o:(Fssh_pkcs11_add_provider) git reset --hard fixes the build for me. Regards, Ronald. ------=_Part_8150_2126601897.1691820268996 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi,

I get this error while building world.
NB: I'm building with llvm15 from a pkg. But I don't think that should make a difference. 
ld.lld: error: undefined symbol: Fssh_lib_contains_symbol
>>> referenced by ssh-pkcs11.c:1538 (/usr/src/crypto/openssh/ssh-pkcs11.c:1538)
>>>               ssh-pkcs11.o:(Fssh_pkcs11_add_provider)


git reset --hard <commit-before-ssh9.4-import> fixes the build for me.

Regards,

Ronald.
------=_Part_8150_2126601897.1691820268996-- From nobody Sat Aug 12 06:28:34 2023 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 4RN9jK1f5Bz4TvgL for ; Sat, 12 Aug 2023 06:28:53 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-23.consmr.mail.gq1.yahoo.com (sonic303-23.consmr.mail.gq1.yahoo.com [98.137.64.204]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 4RN9jH60C8z3XGs for ; Sat, 12 Aug 2023 06:28:51 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=LVpz742y; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.204 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1691821729; bh=75ZoEJxkm+aIrs+4LIg1/KI+rceG1d3ovHcDMiMvA4E=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=LVpz742yW4MSaY8GEEveyPHxBlLVIT8r6J8CI729zEBuI3sHopj9ecVG86w34M1koQd5vi8BdkYQe5a/upwURAe/Lk9CPEJYT1aK/VLcdpjsZbOkxHNltpZkVasTYgzsJgoUi0M7tm9M6OPkW9Q/dQIdrMZhOQRABLWAwvhneJVLcOUui2E6F4kFhcLBNY+B8kcq6yssX0CKs2PooebGDX6Bedgq4ZKEAwAVPt6L/PfrHWhI36sLVCaXYUfqJ18wSZaZYjHnAtqf6XgMY15M1bOjQ70wIac7+1/iX1iJfeosWs+1SrYuRhm4Ns/pEr/7BFJ2v4naTWTVKaikMvFyAg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1691821729; bh=PIHIXo/oZLRkk4az3Bc6qB9YZrUCjgLdupZPEh2hYYh=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=OW2We7YrIc8zJfs6Yt61y04qck5ywH+PaKP48QqEiuXWJ6nH0AgAKpX7fzSK8ZmwxZcREGP1RxIj5MEwS2rC8GmXahHFh5XpuePkEwnPbKfbTpAkLlXj9LGMoUgnPcRN8w+ZrtoJIC6lK3c/ja4OUNVCKeYE7aYLurSYrf3FXpYy5jaIOjcqcwY4d8cGXodhnO3fQ3Tb7+vxhzKFmNgCEtQIRGKit2X+r55BP+Y72LupVoRimKkCoTv6nsvnIaJj35B4gjcJXzFcBeXP44vwfDH82F4/yb0gaW5h5k++zpjNbvht/NH/FuvWRwjbeEqX5SINtUwa34bsWbroMKGEJg== X-YMail-OSG: vB2xmmoVM1nul.mt.wvyE3V2PV8Glj8gkwqVnjxgMTOGxNIz4fU2xuyKxpv1LRC 8gp4N4LR8EcOYnEhXTt54sf_kkAvQlbDr2cf6jLxW9XAsfMy_bZ35skzXgGA_zzVxMgqqqs6yYuG cWEDkdFivk9zPJMCl3Qtd94HpJKTuarWmT9FKkZzc_pRMOqGF4lOlui_rlEveuV7cnKzTBUqrOem jd9axmWMqAeGvO1elBr57ngg27jYSgUaljUUxfBIRZDFbThcI3c8dduhAK2NMlvsU4jsLqL3GSaf goAKkcypeJoBvI67dM0D7IGamt3d7.YFVUIRVfUP1zSaLxBhmNkmvew8VVSn9NYeXGU4BGwuUb0i oj8EQmNkbumgaiKHKVmf8GQQsnr_qrovJvbnWFGLEV9JFjO0PbgKKoj9ZnKQEoZB5f1Nb1TVJiHo _a4Qbyvf4HTU349CL5UVzY.2dE9SyVOrzDmabzS5xg3QtSlnibNg8R2Hzm0HIhSPM41GIW.gFxND HwpxIE8opcflxgMMb3BCrPlO4KBj6Sph9z_5sL9YTMG2_m0xl3sUcrG_9Jz4he7tMI04uNMecVRR fwUQAzFucTjde89hLNobXZaIfbthj.PwedfkvexE3XT1E7.0dLR92d8QROADJOxDcarlhE3nLfnp .5XepU1OCsg72W1YX4MC14avu2KgoCSqqJBAS7tK4MJoWdXueRNO87NrYjJKIaK.xsu4pFcXLMCm CLZvPGIc7C9oKVmWCz8opF7GcLuqRAo10BUsjxJ2lWLbCEXZ2BzSZj.zrgYVs2fy68.0qsahY3XW ezz7HalHsa0r.Jz0HJ9q480_9o6djfk2SsbLy3ganVnvG5_YrcHc4xjP7CXik.hZcvqo8jZSFsYx daIp2sZO3s9U865u0l8iFYPuKXPV9gmdEeBeu9VWvz2o5vFVzmIHCEuXyIjCaRp6DABqt48gt9E4 xZp2yb45fB_JCTf_VmWJXSfP9fSgD0gyB95WbpvDdiV5SCX6CIxyEc2PfobUQ01lyRSw9v8kN9t9 l3FMgzxB6rajeZLhN7ieW3fwNifQjpt0_fyhlQ_E.49eNk3Rsy.UDQ.Bw0Iv.kMqjVLC8JCltL73 kVO8DylMptI_JpZa3odBRfa2x8rDEjZMj0II5fgnLQ8DWsftwYrq9tp0PxA2a2plhm_GyyL9m7_x aKI2pJG76PWFGZ.Nkqq8qubJTnkUhC7eZXco8gwWrbibG5OZ_k4Fj_ITZRMrKHMJ2S4iHuZ4rjeA 3P_Y9yOjv0l3l781FzCMPUY94F2MDiG5_753kU_4MIc6LAOaAf3XBaLXOT6tbUXIx0oj085A6_KD 1QZrEzrIVDaMoafEQNklR8VAKaYmKkjIWP8JVMMefA3GmNKAeYk3FJDbXafsk0zOXjr2lzHL_MvJ RH3mPSI8gKF_nf3tNKbpXWqsrb37cmYly17URhi1tqdullWuFgI4nE87IHshtTHc1LPBekRDF3lP a.YGwQjh18UN2iqT0Kz1SYVBFUzH4YKcUkgxYuW_DQyt3dL48xgy9qVwSaTVziNPfGfcBLY7ZiQR YkZVDmQDoMUBZynWCD0JN.HlV_mNZtXPHx1x8MbV6SgioBVMyGykTIFkygqUFiMbgf1u5ymkuV0X 4kP1x3NgV7Jf.aOUA3PqeWVsrHeNRCncnobBJVaAchNCMASIBOo3Ke6CJ7zLLvEvY5dk24gpfT2A oToCaklXOEPYM9bEuSWCP_ojeZrN3PNAnRURx94ko3Q7wrcUvTl9P74nvKDUHt9NR2Kph53vlMQ1 0xXw.lZDNTLlpICYbnF6XpX2NEGcq4VDRwdXWkLjdmgDGumI7vuB4URXARdkl1oYiO.Ym8IrC6gI m838ExjeC_M6VNi7ivKGITP_kIKAYdViRj9BEdmM0vWjHZZMFoo1w0YmrMPcLkNWASF.o.rFYaxG W1l2U7Far6u0qIgKe.87jDA8j_AS8q8yVnWYoJaf0XAJKxoAf2uWW5.DVd1q3XHoqQvweow_QfCf VjCita49Y1zXzTIfhujOstwRdw_FoTb950Azqz8p3TJLV8VcztwmOWQn_cQ8xarWY3sRlSIlR4x8 zBSBlDzjSVQzm4yg.HkjLBh0N5RQ1.FIuOCOJ_.mZYct5yZ1lPkyHgsDbjydap3oGgRB.epgJFZn 53h6awcF5ygInn_KxU1ZA.Bja6sgwD1YroFT.Z6de3fTNnAIN_4TM2vcqR9dQoHV30lze1R9TEYq 1YROZQ3MTa6GmoDZF_Pb39xznvFlhQYiLM_qM4GqYKGK2ps4jQviY8x7efcMdBVuMdsHLo03ugzo p_Q-- X-Sonic-MF: X-Sonic-ID: c9c5a161-079a-439e-9da6-6da2a43fa9be Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Sat, 12 Aug 2023 06:28:49 +0000 Received: by hermes--production-bf1-865889d799-cgv22 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 66cb8044bfb0e03c664848d63b4d1502; Sat, 12 Aug 2023 06:28:46 +0000 (UTC) From: Mark Millard 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 16.0 \(3731.700.6\)) Subject: Re: aarch64 (not armv7) kyua run on main [so: 14]: sys/net/if_lagg_test:status_stress got "Fatal data abort" panic [14.0-ALPHA1 snapshot panic submitted to bugzilla] Date: Fri, 11 Aug 2023 23:28:34 -0700 References: <6F4285CB-6E3E-4A88-A830-8E54E68717ED@yahoo.com> To: FreeBSD ARM List , Current FreeBSD In-Reply-To: <6F4285CB-6E3E-4A88-A830-8E54E68717ED@yahoo.com> Message-Id: X-Mailer: Apple Mail (2.3731.700.6) X-Spamd-Result: default: False [-2.59 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_SHORT(-0.09)[-0.092]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ARC_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.204:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.204:from]; DKIM_TRACE(0.00)[yahoo.com:+]; TO_DN_ALL(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MID_RHS_MATCH_FROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2] X-Spamd-Bar: -- X-Rspamd-Queue-Id: 4RN9jH60C8z3XGs On Aug 9, 2023, at 22:30, Mark Millard wrote: > The context is on a Windows Dev Kit 2023, using a bectl based = boot/root disk: >=20 > # uname -apKU > FreeBSD CA78C-WDK23-ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT aarch64 = 1400094 #9 main-n264643-0befc55cdf4b-dirty: Wed Aug 9 14:23:48 PDT 2023 = = root@CA78C-WDK23-ZFS:/usr/obj/BUILDs/main-CA78C-dbg-clang/usr/main-src/arm= 64.aarch64/sys/GENERIC-DBG-CA78C arm64 aarch64 1400094 1400094 >=20 > I only do bugzailla submittals based on just my > own builds as a means of last resort: I try to > use official builds for such. The: >=20 > main-n264491-8a5c836b51ce: Thu Aug 3 >=20 > snapshot did not panic on the RPi4B that I > tried it with. We will see for the next > snapshot at some point. >=20 > Both the non-debug and the debug kernels panic. > I saw no evidence of the debug kernel reporting > anything. >=20 > Note the: >=20 > 0xdeadc0dedeadc0de (2 examples) > and: > 0xfefefefefefefeff (1 example) >=20 > that may have some significance. >=20 > . . . > sys/net/if_gif:basic -> passed [0.195s] > sys/net/if_lagg_test:create -> passed [0.125s] > sys/net/if_lagg_test:create_destroy_stress -> skipped: Skipping this = test because it easily panics the machine [0.022s] > sys/net/if_lagg_test:lacp_linkstate_destroy_stress -> passed = [60.048s] > sys/net/if_lagg_test:set_ether -> passed [0.090s] > sys/net/if_lagg_test:status_stress -> =20 >=20 > <6>lagg0: link state changed to DOWN > Fatal data abort: > x0: 0xffff000186c82858 (_DYNAMIC + 0x271e46b8) > x1: 0x0000000000000001 > x2: 0xdeadc0dedeadc0de > x3: 0xffff0000005b68c0 (ifdead_ioctl + 0x0) > x4: 0xffffa000a8ba305e > x5: 0xffffa00023d932fa > x6: 0x000000006767616c > x7: 0x6e6d760070617401 > x8: 0x000000000000030c > x9: 0x0000000000210005 > x10: 0x0000000000000800 > x11: 0xfefefefefefefeff > x12: 0x0000000000000008 > x13: 0x0000000000000000 > x14: 0x0000000000010000 > x15: 0x0000000000000001 > x16: 0x0000000000010000 > x17: 0x0000000000000007 > x18: 0xffff000186c82520 > <6>ue0: link state changed to DOWN > (_DYNAMIC + 0x271e4380) > x19: 0xffff000186c82858 (_DYNAMIC + 0x271e46b8) > x20: 0xffffa000a8ba3000 > x21: 0xffffa000a8ba3058 > x22: 0x000000000000000c > x23: 0x0000000000000005 > x24: 0x0000000000000000 > x25: 0xffff000000c7a000 (keysw + 0xb8) > x26: 0x0000000000000000 > x27: 0xffff000000cf9000 (sdta_vfs_vop_vop_spare4_return1 + 0x18) > x28: 0x0000000000000008 > x29: 0xffff000186c82540 (_DYNAMIC + 0x271e43a0) > sp: 0xffff000186c82520 > lr: 0xffff0000006a0b50 (dump_iface + 0x2c0) > elr: 0xffff0000006a124c (dump_sa + 0x1c) > spsr: 0x0000000000400045 > far: 0xdeadc0dedeadc0df > esr: 0x0000000096000004 > timeout stopping cpus > panic: vm_fault failed: 0xffff0000006a124c error 1 > cpuid =3D 2 > time =3D 1691642123 > KDB: stack backtrace: > db_trace_self() at db_trace_self > db_trace_self_wrapper() at db_trace_self_wrapper+0x30 > vpanic() at vpanic+0x13c > panic() at panic+0x44 > data_abort() at data_abort+0x358 > handle_el1h_sync() at handle_el1h_sync+0x14 > --- exception, esr 0x96000004 > dump_sa() at dump_sa+0x1c > dump_iface() at dump_iface+0x2bc > dump_cb() at dump_cb+0x18 > if_foreach_sleep() at if_foreach_sleep+0x208 > rtnl_handle_getlink() at rtnl_handle_getlink+0xec > rtnl_handle_message() at rtnl_handle_message+0x19c > nl_taskqueue_handler() at nl_taskqueue_handler+0x5f4 > taskqueue_run_locked() at taskqueue_run_locked+0x1a4 > taskqueue_thread_loop() at taskqueue_thread_loop+0xc8 > fork_exit() at fork_exit+0x74 > fork_trampoline() at fork_trampoline+0x14 >=20 > This was from: >=20 > # /usr/bin/kyua test -k /usr/tests/Kyuafile >=20 > But the earlier part of the run is not > needed to get the panic. Booting, logging > in as root, and doing: >=20 > # /usr/bin/kyua test -k /usr/tests/Kyuafile = sys/net/if_lagg_test:status_stress >=20 > is sufficient to get the panic in my context. >=20 >=20 > For reference for the RPi4B not getting the panic: >=20 > Trying on an RPi4B with a somewhat older snapshot did not panic: >=20 > # uname -apKU > you have mail > FreeBSD generic 14.0-CURRENT FreeBSD 14.0-CURRENT aarch64 1400093 #0 = main-n264491-8a5c836b51ce: Thu Aug 3 12:10:50 UTC 2023 = root@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC = arm64 aarch64 1400093 1400093 >=20 > # /usr/bin/kyua test -k /usr/tests/Kyuafile = sys/net/if_lagg_test:status_stress > sys/net/if_lagg_test:status_stress -> passed [60.371s] >=20 > Results file id is usr_tests.20230804-151402-553517 > Results saved to = /root/.kyua/store/results.usr_tests.20230804-151402-553517.db >=20 > 1/1 passed (0 failed) I replicated the panic via an 14.0-ALPHA1 snapshot dd'd to USB media then used to boot and operate a Windows Dev Kit 2023. See: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D273081 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Aug 12 08:30:28 2023 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 4RNDPk6dXpz4m94l for ; Sat, 12 Aug 2023 08:30:34 +0000 (UTC) (envelope-from garyj@gmx.de) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mout.gmx.net", Issuer "Telekom Security ServerID OV Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RNDPk2NMKz4Jdw; Sat, 12 Aug 2023 08:30:34 +0000 (UTC) (envelope-from garyj@gmx.de) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1691829029; x=1692433829; i=garyj@gmx.de; bh=WZFupQCSnoZ5yFgSJtXlu+cYj2DtTV03QIKoJuljIFs=; h=X-UI-Sender-Class:Date:From:To:Cc:Subject:In-Reply-To:References:Reply- To; b=S92fpM6oYxLXhGf7NVcsHWYTy+vXEwIY3AGIIZvxbHzjDfak+5SKuUz1O3qT5btMvNiMCly 2USqvVHqVP9NBIFj4Ogd5UTtlAMLS4YkutbQNiwVvzug6CTJYz+KMPhMTKhxQVgMzxRejPDTn KPTdRma/IZ/nlh57xw6fOlOOXHAcG8kzT+Io+1LRcBCxG+BJTDQ2No9m5pOONRaFgvILF6aoW IDSh/yDc12N6PVcB4r+8VLLciLz0Ww5ZYF4h5/68a997EpZYVfkLyeUwvSN2d1tmXlwL2Z9We 6Krqkp6XOAxhpSJYYbldPKElX5mbDL86aC4gu7GhFBL1Uh7XBgDQ== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from ernst.home ([91.2.50.110]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MBm1U-1qeghN2UeK-00C7ZE; Sat, 12 Aug 2023 10:30:29 +0200 Date: Sat, 12 Aug 2023 08:30:28 +0000 From: Gary Jennejohn To: Ronald Klop Cc: Ed Maste , freebsd-current@freebsd.org Subject: Re: ssh 9.4 fails to build Message-ID: <20230812103028.62b6eeb6@ernst.home> In-Reply-To: <1921364631.8151.1691820269255@localhost> References: <1921364631.8151.1691820269255@localhost> Reply-To: garyj@gmx.de X-Mailer: Claws Mail 3.19.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: quoted-printable X-Provags-ID: V03:K1:XDcOMK+Frv4UJ4aH/NQ4ChU5cuCGl5Eywj59B3oB7cmUFQhUZ07 0YwVqvwtvcGjTLR7waVju+JcKnFYS2YqKAwNw5zzThnf1Hg4RjdZuLpzBw43nHcFE4Vns2Z uqYUXo1pKJ1mVtvmKNJsMyJfpsuHmzaPWlO0c9tTa7+2QHUsaCbdNFLR78JdD2BfQAgNquv aceJgs9RVPIZlyFLGP2mA== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:U3Oz61kuiQk=;2jr9C8TgVzHj0vcZhmIirost5Vu o5YvyRWZWVqMtS6rIaLQeNRzSiQdxtwNKZTXOZ7uCA3o/uOuxkk00Aki4kmoZ6ZtIuDdlywLY aGcsJoeiGFuctPDdjVFLmtWFKJv5o1GLO4PEmK9Ci75UnPMSs65q/0CxUDOpbKOXPu/UekOnw rES04gH3teqkzNwT48J7wg89z1DVmA8ZCogkai2qx4j4vRkIu9lMVqY+EYPHYwSHUsIVUAIFq CimLwIq7U5T77B/ejJVYT3I3NNNxWKqVdRcBkE2057rIpVoCkV1gdzJ6IGUkVhvLvURfMgYcC pdofAtR5us/4Hbb3flXdsPwyCNpTDO13dPoyuF+9kRbzwxpCXw89gVIhDLQv0wqqzBGXobhAf p2xY95Q3EwzycBQ7rQfRmBeq1fzSf3XflRMiRXPa+bkAArGDMyYein/RsxIR557m6YZvGVyWk YIdcG2lji3YfJSxEDl+4vMoo/+azzq3zCjWYQ73NHRGUs4RnsYsoMvzJnMtubxheXzFteKXTc +qipjGwWAJrv8QHTAgY34hcdEU7tz0ZTDbRJNgbBLelzJpe6Ku2OL1adS44vSuAhmJ1a8Hpii LSOm6+UQTKGal4nrAz5E89xeh5rDHdJmvDDCv982O/p3Wx7dqPvjoIT9HFEW6iVput01O1Moj ZCoGPMD9c41txxGaMmNnVSL8h/k/f/BrT4bN06CA0M6jw1vimC57sxxyG7ke6/R1sOcQgBK0D flSEAGQDzEmYJ9OaheGc8oaFYL7TV07HtP6TEP8QTaKgPIzNytH6hYw0kdASqSfQByX+daT7l c0sgor4NNrcvZQvOfNc10ZB2CAiAuTnLf5KdOTFLuvlb4qy45QJNpwyWhFIVoszNI2aOAmNlA c4pPXhuYHPJrC+PqB1FuGxgpA3JUUMg8peBOWB1NAuHOwJUNUVg2Qu5Wd2D6fLzSkHJgUW7JR Au0huw== X-Rspamd-Queue-Id: 4RNDPk2NMKz4Jdw X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE] On Sat, 12 Aug 2023 08:04:29 +0200 (CEST) Ronald Klop wrote: > Hi, > > I get this error while building world. > NB: I'm building with llvm15 from a pkg. But I don't think that should m= ake a difference. > ld.lld: error: undefined symbol: Fssh_lib_contains_symbol > >>> referenced by ssh-pkcs11.c:1538 (/usr/src/crypto/openssh/ssh-pkcs11.= c:1538) > >>> ssh-pkcs11.o:(Fssh_pkcs11_add_provider) > > > git reset --hard fixes the build for me. > I just updated my current source tree and ran buildworld and ssh compiled without any errors. ./obj/usr/src/amd64.amd64/secure/usr.bin/ssh/ssh -V OpenSSH_9.4p1, OpenSSL 3.0.9 30 May 2023 But I'm using LLVM16. =2D- Gary Jennejohn From nobody Sat Aug 12 10:30:04 2023 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 4RNH3h5jCrz4mKRS for ; Sat, 12 Aug 2023 10:30:08 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (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 4RNH3h43NFz4WXR; Sat, 12 Aug 2023 10:30:08 +0000 (UTC) (envelope-from guru@unixarea.de) Authentication-Results: mx1.freebsd.org; none Received: from [188.174.59.170] (helo=localhost.unixarea.de) by ms-10.1blu.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qUlsj-0003BE-Mr; Sat, 12 Aug 2023 12:30:05 +0200 Received: from localhost.my.domain (localhost [127.0.0.1]) by localhost.unixarea.de (8.16.1/8.14.9) with ESMTPS id 37CAU4p9020770 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 12 Aug 2023 12:30:04 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.16.1/8.14.9/Submit) id 37CAU44N020769; Sat, 12 Aug 2023 12:30:04 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Sat, 12 Aug 2023 12:30:04 +0200 From: Matthias Apitz To: Jan Beich Cc: freebsd-current@freebsd.org Subject: Re: problem with poudriere && port ftp/curl Message-ID: Reply-To: Matthias Apitz Mail-Followup-To: Jan Beich , freebsd-current@freebsd.org 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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: FreeBSD 13.0-CURRENT r368166 (amd64) X-message-flag: Mails containing HTML will not be read! Please send only plain text. X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 188.174.59.170 X-Rspamd-Queue-Id: 4RNH3h43NFz4WXR X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:42730, ipnet:178.254.0.0/19, country:DE] El día viernes, agosto 11, 2023 a las 11:59:45p. m. +0200, Jan Beich escribió: > Matthias Apitz writes: > > > I have the following problem with poudriere on 14-CURRENT and ports from > > git head: every time when I start poudriere-bulk it removes a port > > already compile fine (and all its dependent ports) with the message: > > > > ... > > [00:00:40] Sanity checking the repository > > [00:00:40] Checking packages for incremental rebuild needs > > [00:00:43] Deleting curl-8.2.1.pkg: changed options > > [00:00:43] Pkg: +ALTSVC -BROTLI -CARES +CA_BUNDLE +COOKIES -CURL_DEBUG > > -DEBUG +DICT +DOCS +EXAMPLES +FTP -GNUTLS +GOPHER -GSSAPI_BASE > > -GSSAPI_HEIMDAL -GSSAPI_MIT +GSSAPI_NONE +HTTP +HTTP2 -IDN +IMAP +IPV6 > > -LDAP -LDAPS -LIBSSH +LIBSSH2 -MQTT +NTLM +OPENSSL +POP3 +PROXY +PSL > > -RTMP +RTSP -SMB +SMTP +STATIC +TELNET +TFTP +THREADED_RESOLVER > > +TLS_SRP -WEBSOCKET -WOLFSSL -ZSTD > > [00:00:43] New: +ALTSVC -BROTLI -CARES +CA_BUNDLE +COOKIES -CURL_DEBUG > > -DEBUG +DICT +DOCS +EXAMPLES +FTP -GNUTLS +GOPHER +GSSAPI_BASE > > -GSSAPI_HEIMDAL -GSSAPI_MIT -GSSAPI_NONE +HTTP +HTTP2 -IDN +IMAP +IPV6 > > -LDAP -LDAPS -LIBSSH +LIBSSH2 -MQTT +NTLM +OPENSSL +POP3 +PROXY +PSL > > -RTMP +RTSP -SMB +SMTP +STATIC +TELNET +TFTP +THREADED_RESOLVER > > +TLS_SRP -WEBSOCKET -WOLFSSL -ZSTD > > > > The difference seems to be +/-GSSAPI_BASE and +/-GSSAPI_NONE. > > I have not set anything about > > this in the port's options or jail's make.conf. > > > > What can I do to fix this? > > Maybe poudriere is confused by GSSAPI_${${SSL_DEFAULT} == base :?BASE :NONE} > in OPTIONS_DEFAULT due ssl!=base in DEFAULT_VERSIONS via make.conf(5). > Try filing a bug against ftp/curl. > > $ env -i __MAKE_CONF= PORT_DBDIR=/var/empty make -V '${OPTIONS_DEFAULT:M*GSS*}' > GSSAPI_BASE > $ env -i __MAKE_CONF= PORT_DBDIR=/var/empty DEFAULT_VERSIONS=ssl=openssl make -V '${OPTIONS_DEFAULT:M*GSS*}' > GSSAPI_NONE > > See also https://cgit.freebsd.org/ports/diff/ftp/curl/Makefile?id=6d324c1f70c9 > > I can't reproduce on -CURRENT when only using base OpenSSL 3.0. I ended up with creating the port's option file with # cd /usr/ports/ftp/curl # make config # mkdir /usr/local/etc/poudriere.d/140-CURRENT-options/ftp_curl # /var/db/ports/ftp_curl/options /usr/local/etc/poudriere.d/140-CURRENT-options/ftp_curl/options After this the port was not deleted anymore when starting poudriere. The file /usr/local/etc/poudriere.d/140-CURRENT-options/ftp_curl/options contains: # This file is auto-generated by 'make config'. # Options for curl-8.2.1 _OPTIONS_READ=curl-8.2.1 _FILE_COMPLETE_OPTIONS_LIST=ALTSVC BROTLI CA_BUNDLE COOKIES CURL_DEBUG DEBUG DOCS EXAMPLES IDN IPV6 NTLM PROXY PSL STATIC TLS_SRP ZSTD GSSAPI_BASE GSSAPI_HEIMDAL GSSAPI_MIT GSSAPI_NONE CARES THREADED_RESOLVER GNUTLS OPENSSL WOLFSSL DICT FTP GOPHER HTTP HTTP2 IMAP LDAP LDAPS LIBSSH LIBSSH2 MQTT POP3 RTMP RTSP SMB SMTP TELNET TFTP WEBSOCKET OPTIONS_FILE_SET+=ALTSVC OPTIONS_FILE_UNSET+=BROTLI OPTIONS_FILE_SET+=CA_BUNDLE OPTIONS_FILE_SET+=COOKIES OPTIONS_FILE_UNSET+=CURL_DEBUG OPTIONS_FILE_UNSET+=DEBUG OPTIONS_FILE_SET+=DOCS OPTIONS_FILE_SET+=EXAMPLES OPTIONS_FILE_UNSET+=IDN OPTIONS_FILE_SET+=IPV6 OPTIONS_FILE_SET+=NTLM OPTIONS_FILE_SET+=PROXY OPTIONS_FILE_UNSET+=PSL OPTIONS_FILE_SET+=STATIC OPTIONS_FILE_SET+=TLS_SRP OPTIONS_FILE_UNSET+=ZSTD OPTIONS_FILE_UNSET+=GSSAPI_BASE OPTIONS_FILE_UNSET+=GSSAPI_HEIMDAL OPTIONS_FILE_UNSET+=GSSAPI_MIT OPTIONS_FILE_SET+=GSSAPI_NONE OPTIONS_FILE_UNSET+=CARES OPTIONS_FILE_SET+=THREADED_RESOLVER OPTIONS_FILE_UNSET+=GNUTLS OPTIONS_FILE_SET+=OPENSSL OPTIONS_FILE_UNSET+=WOLFSSL OPTIONS_FILE_SET+=DICT OPTIONS_FILE_SET+=FTP OPTIONS_FILE_SET+=GOPHER OPTIONS_FILE_SET+=HTTP OPTIONS_FILE_SET+=HTTP2 OPTIONS_FILE_SET+=IMAP OPTIONS_FILE_UNSET+=LDAP OPTIONS_FILE_UNSET+=LDAPS OPTIONS_FILE_UNSET+=LIBSSH OPTIONS_FILE_UNSET+=LIBSSH2 OPTIONS_FILE_UNSET+=MQTT OPTIONS_FILE_SET+=POP3 OPTIONS_FILE_UNSET+=RTMP OPTIONS_FILE_SET+=RTSP OPTIONS_FILE_UNSET+=SMB OPTIONS_FILE_SET+=SMTP OPTIONS_FILE_SET+=TELNET OPTIONS_FILE_SET+=TFTP OPTIONS_FILE_UNSET+=WEBSOCKET -- Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub From nobody Sat Aug 12 13:33:36 2023 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 4RNM7T6SLqz4q2Nr for ; Sat, 12 Aug 2023 13:33:41 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (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 4RNM7S1wvTz4kmL for ; Sat, 12 Aug 2023 13:33:40 +0000 (UTC) (envelope-from guru@unixarea.de) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of guru@unixarea.de designates 178.254.4.101 as permitted sender) smtp.mailfrom=guru@unixarea.de; dmarc=none Received: from [188.174.59.170] (helo=localhost.unixarea.de) by ms-10.1blu.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qUokL-0002l4-U2 for freebsd-current@freebsd.org; Sat, 12 Aug 2023 15:33:38 +0200 Received: from localhost.my.domain (localhost [127.0.0.1]) by localhost.unixarea.de (8.16.1/8.14.9) with ESMTPS id 37CDXaQu033131 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Sat, 12 Aug 2023 15:33:36 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.16.1/8.14.9/Submit) id 37CDXaoh033130 for freebsd-current@freebsd.org; Sat, 12 Aug 2023 15:33:36 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Sat, 12 Aug 2023 15:33:36 +0200 From: Matthias Apitz To: freebsd-current@freebsd.org Subject: lang/gcc12 will not build on a host w/ 8 CPU and 16G mem Message-ID: Reply-To: Matthias Apitz 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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Operating-System: FreeBSD 13.0-CURRENT r368166 (amd64) X-message-flag: Mails containing HTML will not be read! Please send only plain text. X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 188.174.59.170 X-Spamd-Result: default: False [-2.71 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.91)[-0.914]; MID_RHS_NOT_FQDN(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:178.254.4.101]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[unixarea.de]; ASN(0.00)[asn:42730, ipnet:178.254.0.0/19, country:DE]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; R_DKIM_NA(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; HAS_XOIP(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_LAST(0.00)[]; REPLYTO_EQ_FROM(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; HAS_XAW(0.00)[]; HAS_REPLYTO(0.00)[guru@unixarea.de] X-Spamd-Bar: -- X-Rspamd-Queue-Id: 4RNM7S1wvTz4kmL I'm building on 14-CURRENT with poudriere. The server in question is a Dell R210 with 8x 3.30GHz CPU and 15.8 GB memory: Aug 11 19:03:21 jet kernel: CPU: Intel(R) Xeon(R) CPU E3-1230 V2 @ 3.30GHz (3292.74-MHz K8-class CPU) Aug 11 19:03:21 jet kernel: FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs Aug 11 19:03:21 jet kernel: avail memory = 16582250496 (15814 MB) I have set swap to 4GB + 10GB + 10GB: # swapctl -lh Device: Bytes Used: /dev/da0p3 4.0G 1.5G /dev/md9 10G 1.5G /dev/md10 10G 1.5G and poudriere does use ZFS. Despite of this relatively good equipped machine, lang/gcc12 can't be build. In /var/log/messages after some 3 hours of compiling as a single(!) job in poudriere: Aug 12 14:59:47 jet kernel: pid 57837 (lto1), jid 111, uid 65534, was killed: a thread waited too long to allocate a page and the job fails in poudriere with: ... xg++: fatal error: Killed signal terminated program lto1 compilation terminated. lto-wrapper: fatal error: /wrkdirs/usr/ports/lang/gcc12/work/.build/./prev-gcc/xg++ returned 1 exit status compilation terminated. /usr/local/bin/ld: error: lto-wrapper failed collect2: error: ld returned 1 exit status gmake[4]: *** [/wrkdirs/usr/ports/lang/gcc12/work/gcc-12.2.0/gcc/cp/Make-lang.in:136: cc1plus] Error 1 gmake[4]: *** Waiting for unfinished jobs.... What could I do? matthias -- Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub From nobody Sat Aug 12 13:38:32 2023 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 4RNMFP706hz4q2x3 for ; Sat, 12 Aug 2023 13:38:49 +0000 (UTC) (envelope-from developer@lorenzosalvadore.it) Received: from mail-4323.proton.ch (mail-4323.proton.ch [185.70.43.23]) (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 "protonmail.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RNMFP4pnfz4lyr for ; Sat, 12 Aug 2023 13:38:49 +0000 (UTC) (envelope-from developer@lorenzosalvadore.it) Authentication-Results: mx1.freebsd.org; none Date: Sat, 12 Aug 2023 13:38:32 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lorenzosalvadore.it; s=protonmail3; t=1691847525; x=1692106725; bh=SAG3a5oisb/yvpXThVVbPfZ63BWVtr2b1vgMtEDSQec=; h=Date:To:From:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=NEvgiV6428KH0Ax6VesGyAeIeqbGlmjEjczZrnwkdZhxNxTM1ZpAzl6w1akT0AWUJ yUPsH0SeezaPPDC9lLKafl2oCFnlAvYlPwb3PirfxGnxDv/j8+nVkZufRqMkDzCg/w o5f5p26slfEb806CUVZIqqbJMOZeX4qbompKRTsogS5bBEBUWrXIrkVnUs49LWqnax pnKZf4cYFTx3l0jtgz05Zzrdruu0pDMr2jr3Dfu0dtfNS30RUjR3qFugrY7ftvB8IY JoT+0uYrDsR4KSn4wnku1DZY+UfUcFMfcLRmDZzglWUHMSPfGBqRPV1BZyODqh3oYH FlWydHrWxCPIA== To: guru@unixarea.de, freebsd-current@freebsd.org From: Lorenzo Salvadore Subject: Re: lang/gcc12 will not build on a host w/ 8 CPU and 16G mem Message-ID: In-Reply-To: References: Feedback-ID: 53711648:user:proton 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="b1_oIDi8J7LpLYngMt6MKdmkHYL8F4PmsPY3PJhSL5tj60" X-Rspamd-Queue-Id: 4RNMFP4pnfz4lyr X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:62371, ipnet:185.70.43.0/24, country:CH] This is a multi-part message in MIME format. --b1_oIDi8J7LpLYngMt6MKdmkHYL8F4PmsPY3PJhSL5tj60 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SGVsbG8sIEkgYW0gdGhlIHBvcnQgbWFpbnRhaW5lci4KCkl0IGlzIGEgd2VsbCBrbm93biBpc3N1 ZSB1bmZvcnR1bmF0ZWx5LiBKdXN0IGRpc2FibGUgdGhlIExUT19CT09UU1RSQVAgb3B0aW9uIGFu ZCB0aGUgYnVpbGQgd2lsbCBzdWNjZWVkLgoKQ2hlZXJzLAoKTG9yZW56byBTYWx2YWRvcmUKClNl bnQgZnJvbSBQcm90b24gTWFpbCBtb2JpbGUKCi0tLS0tLS0tIE1lc3NhZ2dpbyBvcmlnaW5hbGUg LS0tLS0tLS0KSWwgMTIgQWdvIDIwMjMsIDE1OjMzLCBNYXR0aGlhcyBBcGl0eiBoYSBzY3JpdHRv OgoKPiBJJ20gYnVpbGRpbmcgb24gMTQtQ1VSUkVOVCB3aXRoIHBvdWRyaWVyZS4gVGhlIHNlcnZl ciBpbiBxdWVzdGlvbiBpcyBhIERlbGwgUjIxMCB3aXRoIDh4IDMuMzBHSHogQ1BVIGFuZCAxNS44 IEdCIG1lbW9yeTogQXVnIDExIDE5OjAzOjIxIGpldCBrZXJuZWw6IENQVTogSW50ZWwoUikgWGVv bihSKSBDUFUgRTMtMTIzMCBWMiBAIDMuMzBHSHogKDMyOTIuNzQtTUh6IEs4LWNsYXNzIENQVSkg QXVnIDExIDE5OjAzOjIxIGpldCBrZXJuZWw6IEZyZWVCU0QvU01QOiBNdWx0aXByb2Nlc3NvciBT eXN0ZW0gRGV0ZWN0ZWQ6IDggQ1BVcyBBdWcgMTEgMTk6MDM6MjEgamV0IGtlcm5lbDogYXZhaWwg bWVtb3J5ID0gMTY1ODIyNTA0OTYgKDE1ODE0IE1CKSBJIGhhdmUgc2V0IHN3YXAgdG8gNEdCICsg MTBHQiArIDEwR0I6ICMgc3dhcGN0bCAtbGggRGV2aWNlOiBCeXRlcyBVc2VkOiAvZGV2L2RhMHAz IDQuMEcgMS41RyAvZGV2L21kOSAxMEcgMS41RyAvZGV2L21kMTAgMTBHIDEuNUcgYW5kIHBvdWRy aWVyZSBkb2VzIHVzZSBaRlMuIERlc3BpdGUgb2YgdGhpcyByZWxhdGl2ZWx5IGdvb2QgZXF1aXBw ZWQgbWFjaGluZSwgbGFuZy9nY2MxMiBjYW4ndCBiZSBidWlsZC4gSW4gL3Zhci9sb2cvbWVzc2Fn ZXMgYWZ0ZXIgc29tZSAzIGhvdXJzIG9mIGNvbXBpbGluZyBhcyBhIHNpbmdsZSghKSBqb2IgaW4g cG91ZHJpZXJlOiBBdWcgMTIgMTQ6NTk6NDcgamV0IGtlcm5lbDogcGlkIDU3ODM3IChsdG8xKSwg amlkIDExMSwgdWlkIDY1NTM0LCB3YXMga2lsbGVkOiBhIHRocmVhZCB3YWl0ZWQgdG9vIGxvbmcg dG8gYWxsb2NhdGUgYSBwYWdlIGFuZCB0aGUgam9iIGZhaWxzIGluIHBvdWRyaWVyZSB3aXRoOiAu Li4geGcrKzogZmF0YWwgZXJyb3I6IEtpbGxlZCBzaWduYWwgdGVybWluYXRlZCBwcm9ncmFtIGx0 bzEgY29tcGlsYXRpb24gdGVybWluYXRlZC4gbHRvLXdyYXBwZXI6IGZhdGFsIGVycm9yOiAvd3Jr ZGlycy91c3IvcG9ydHMvbGFuZy9nY2MxMi93b3JrLy5idWlsZC8uL3ByZXYtZ2NjL3hnKysgcmV0 dXJuZWQgMSBleGl0IHN0YXR1cyBjb21waWxhdGlvbiB0ZXJtaW5hdGVkLiAvdXNyL2xvY2FsL2Jp bi9sZDogZXJyb3I6IGx0by13cmFwcGVyIGZhaWxlZCBjb2xsZWN0MjogZXJyb3I6IGxkIHJldHVy bmVkIDEgZXhpdCBzdGF0dXMgZ21ha2VbNF06ICoqKiBbL3dya2RpcnMvdXNyL3BvcnRzL2xhbmcv Z2NjMTIvd29yay9nY2MtMTIuMi4wL2djYy9jcC9NYWtlLWxhbmcuaW46MTM2OiBjYzFwbHVzXSBF cnJvciAxIGdtYWtlWzRdOiAqKiogV2FpdGluZyBmb3IgdW5maW5pc2hlZCBqb2JzLi4uLiBXaGF0 IGNvdWxkIEkgZG8/IG1hdHRoaWFzIC0tIE1hdHRoaWFzIEFwaXR6LCDinIkgZ3VydUB1bml4YXJl YS5kZSwgaHR0cDovL3d3dy51bml4YXJlYS5kZS8gKzQ5LTE3Ni0zODkwMjA0NSBQdWJsaWMgR251 UEcga2V5OiBodHRwOi8vd3d3LnVuaXhhcmVhLmRlL2tleS5wdWI= --b1_oIDi8J7LpLYngMt6MKdmkHYL8F4PmsPY3PJhSL5tj60 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 SGVsbG8sIEkgYW0gdGhlIHBvcnQgbWFpbnRhaW5lci48YnI+PGJyPkl0IGlzIGEgd2VsbCBrbm93 biBpc3N1ZSB1bmZvcnR1bmF0ZWx5LiBKdXN0IGRpc2FibGUgdGhlIExUT19CT09UU1RSQVAgb3B0 aW9uIGFuZCB0aGUgYnVpbGQgd2lsbCBzdWNjZWVkLjxicj48YnI+Q2hlZXJzLDxicj48YnI+TG9y ZW56byBTYWx2YWRvcmU8YnI+PGJyPjxicj5TZW50IGZyb20gUHJvdG9uIE1haWwgbW9iaWxlPGJy Pjxicj48YnI+PGJyPi0tLS0tLS0tIE1lc3NhZ2dpbyBvcmlnaW5hbGUgLS0tLS0tLS08YnI+SWwg MTIgQWdvIDIwMjMsIDE1OjMzLCBNYXR0aGlhcyBBcGl0eiA8IGd1cnVAdW5peGFyZWEuZGU+IGhh IHNjcml0dG86PGJsb2NrcXVvdGUgY2xhc3M9InByb3Rvbm1haWxfcXVvdGUiPjxicj5JJ20gYnVp bGRpbmcgb24gMTQtQ1VSUkVOVCB3aXRoIHBvdWRyaWVyZS4gVGhlIHNlcnZlciBpbiBxdWVzdGlv biBpcyBhDQpEZWxsIFIyMTAgd2l0aCA4eCAzLjMwR0h6IENQVSBhbmQgMTUuOCBHQiBtZW1vcnk6 DQoNCkF1ZyAxMSAxOTowMzoyMSBqZXQga2VybmVsOiBDUFU6IEludGVsKFIpIFhlb24oUikgQ1BV IEUzLTEyMzAgVjIgQCAzLjMwR0h6ICgzMjkyLjc0LU1IeiBLOC1jbGFzcyBDUFUpDQpBdWcgMTEg MTk6MDM6MjEgamV0IGtlcm5lbDogRnJlZUJTRC9TTVA6IE11bHRpcHJvY2Vzc29yIFN5c3RlbSBE ZXRlY3RlZDogOCBDUFVzDQpBdWcgMTEgMTk6MDM6MjEgamV0IGtlcm5lbDogYXZhaWwgbWVtb3J5 ID0gMTY1ODIyNTA0OTYgKDE1ODE0IE1CKQ0KDQpJIGhhdmUgc2V0IHN3YXAgdG8gNEdCICsgMTBH QiArIDEwR0I6DQoNCiMgc3dhcGN0bCAtbGgNCkRldmljZTogICAgICAgICAgICBCeXRlcyAgICAg IFVzZWQ6DQovZGV2L2RhMHAzICAgICAgICAgIDQuMEcgICAgICAgMS41Rw0KL2Rldi9tZDkgICAg ICAgICAgICAgMTBHICAgICAgIDEuNUcNCi9kZXYvbWQxMCAgICAgICAgICAgIDEwRyAgICAgICAx LjVHDQoNCmFuZCBwb3VkcmllcmUgZG9lcyB1c2UgWkZTLiBEZXNwaXRlIG9mIHRoaXMgcmVsYXRp dmVseSBnb29kIGVxdWlwcGVkDQptYWNoaW5lLCBsYW5nL2djYzEyIGNhbid0IGJlIGJ1aWxkLiBJ biAvdmFyL2xvZy9tZXNzYWdlcyBhZnRlciBzb21lIDMNCmhvdXJzIG9mIGNvbXBpbGluZyBhcyBh IHNpbmdsZSghKSBqb2IgaW4gcG91ZHJpZXJlOg0KDQpBdWcgMTIgMTQ6NTk6NDcgamV0IGtlcm5l bDogcGlkIDU3ODM3IChsdG8xKSwgamlkIDExMSwgdWlkIDY1NTM0LCB3YXMga2lsbGVkOiBhIHRo cmVhZCB3YWl0ZWQgdG9vIGxvbmcgdG8gYWxsb2NhdGUgYSBwYWdlDQoNCmFuZCB0aGUgam9iIGZh aWxzIGluIHBvdWRyaWVyZSB3aXRoOg0KDQouLi4NCnhnKys6IGZhdGFsIGVycm9yOiBLaWxsZWQg c2lnbmFsIHRlcm1pbmF0ZWQgcHJvZ3JhbSBsdG8xDQpjb21waWxhdGlvbiB0ZXJtaW5hdGVkLg0K bHRvLXdyYXBwZXI6IGZhdGFsIGVycm9yOiAvd3JrZGlycy91c3IvcG9ydHMvbGFuZy9nY2MxMi93 b3JrLy5idWlsZC8uL3ByZXYtZ2NjL3hnKysgcmV0dXJuZWQgMSBleGl0IHN0YXR1cw0KY29tcGls YXRpb24gdGVybWluYXRlZC4NCi91c3IvbG9jYWwvYmluL2xkOiBlcnJvcjogbHRvLXdyYXBwZXIg ZmFpbGVkDQpjb2xsZWN0MjogZXJyb3I6IGxkIHJldHVybmVkIDEgZXhpdCBzdGF0dXMNCmdtYWtl WzRdOiAqKiogWy93cmtkaXJzL3Vzci9wb3J0cy9sYW5nL2djYzEyL3dvcmsvZ2NjLTEyLjIuMC9n Y2MvY3AvTWFrZS1sYW5nLmluOjEzNjogY2MxcGx1c10gRXJyb3IgMQ0KZ21ha2VbNF06ICoqKiBX YWl0aW5nIGZvciB1bmZpbmlzaGVkIGpvYnMuLi4uDQoNCldoYXQgY291bGQgSSBkbz8NCg0KCW1h dHRoaWFzDQoNCi0tDQpNYXR0aGlhcyBBcGl0eiwg4pyJIGd1cnVAdW5peGFyZWEuZGUsIGh0dHA6 Ly93d3cudW5peGFyZWEuZGUvICs0OS0xNzYtMzg5MDIwNDUNClB1YmxpYyBHbnVQRyBrZXk6IGh0 dHA6Ly93d3cudW5peGFyZWEuZGUva2V5LnB1Yg0KDQo8L2Rpdj4= --b1_oIDi8J7LpLYngMt6MKdmkHYL8F4PmsPY3PJhSL5tj60-- From nobody Sat Aug 12 13:51:25 2023 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 4RNMX12QQJz4q3bd for ; Sat, 12 Aug 2023 13:51:29 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (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 4RNMX121zvz4nL4 for ; Sat, 12 Aug 2023 13:51:29 +0000 (UTC) (envelope-from guru@unixarea.de) Authentication-Results: mx1.freebsd.org; none Received: from [188.174.59.170] (helo=localhost.unixarea.de) by ms-10.1blu.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qUp1b-0002Qe-DZ; Sat, 12 Aug 2023 15:51:27 +0200 Received: from localhost.my.domain (localhost [127.0.0.1]) by localhost.unixarea.de (8.16.1/8.14.9) with ESMTPS id 37CDpQtL034363 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 12 Aug 2023 15:51:26 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.16.1/8.14.9/Submit) id 37CDpPMp034362; Sat, 12 Aug 2023 15:51:25 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Sat, 12 Aug 2023 15:51:25 +0200 From: Matthias Apitz To: Lorenzo Salvadore Cc: freebsd-current@freebsd.org Subject: Re: lang/gcc12 will not build on a host w/ 8 CPU and 16G mem Message-ID: Reply-To: Matthias Apitz Mail-Followup-To: Lorenzo Salvadore , freebsd-current@freebsd.org 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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: FreeBSD 13.0-CURRENT r368166 (amd64) X-message-flag: Mails containing HTML will not be read! Please send only plain text. X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 188.174.59.170 X-Rspamd-Queue-Id: 4RNMX121zvz4nL4 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:42730, ipnet:178.254.0.0/19, country:DE] El día sábado, agosto 12, 2023 a las 01:38:32p. m. +0000, Lorenzo Salvadore escribió: > Hello, I am the port maintainer. > > It is a well known issue unfortunately. Just disable the LTO_BOOTSTRAP option and the build will succeed. > > Cheers, > > Lorenzo Salvadore Lorenzo, Thanks for this FAST answer, much faster than I was able to describe my problem. matthias -- Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub From nobody Sat Aug 12 14:11:10 2023 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 4RNMyn2KHXz4q5V3 for ; Sat, 12 Aug 2023 14:11:13 +0000 (UTC) (envelope-from des@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 4RNMyn1WBlz4qGB for ; Sat, 12 Aug 2023 14:11:13 +0000 (UTC) (envelope-from des@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1691849473; 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=xG3BPEfyNnhwESgDQSm2/nn18H2zGVki3BIcpbUS/xw=; b=ucvEzo0i4cMJU3z6kE40He1YWp3cIuCb0+dATFZg4dTQjDn/GSTx32zvNfU+O7Ma4qmfow 1SmaTn8xYD9nvl/dwSGDr8k624wb1mFrFAbujqdfK07Mr2CM1yOSh67uDWoeZnjsEZRxPg H/ClEM+/6+dUkk0tOBqc3KrXS63j/Sz3EPQN97B1IzmMaveQ2J9yIU5jVHrRHfcFbwkI7z ozk+Z4xscrxEqC6mtr1XggVa8Ay+GX8AJjL/7OGJQoHA6ruSHhfzXYDo2ya8MB2wIze8CA lMJjtsX8SQDki9R8JQQgxVIQkzkFHRI+4+VisPzO0Kc7z9JZyPRelQJzF9X1DQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1691849473; 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=xG3BPEfyNnhwESgDQSm2/nn18H2zGVki3BIcpbUS/xw=; b=Isp/lzv81fv/GtyCIl/HAgxvSsGG5r2qRNSVYshKE63orRjjLvqPENAcb2t3ak2JjHUQba FUXaKccgraq4NPwoXMTqgSW6T+CzB6RVPFvpUPvfhMPUFjxNxu7r91DuNHqYCjYhpBuacy tREBiCQvM8lSNFNOim5Y4+rteahR+F6/Rp5V2oYffDUL2vtmGsxU+sjC6mzL5SAHkw+Wdq feYzy+G+OkYOUiPrE9PGLL2xsQ7brd9Z3HdHOCqrWXJLpUhxcGaUXlWC2r6qBXDwncDsfs pCIFj5/0DWpvBh8N8Z32iIV6pC3sLEfPUytiJvJxrrG0xdNcINEwVgZVvkWW/w== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1691849473; a=rsa-sha256; cv=none; b=T8Al2fQBuNnLcrDSNldkTTNQQhgz7hz09LLR2NppDc7frQaEZHsrsXuHYPJyntjWvh7beU DWX+cVvf6afdAulmcGngCDCFNkWJrp88ugfAmhjHQYjW1DnR51413+CjPVmz6drSXAAZT+ yr8l4L+XZ2G11UiIi4l9vGGT7SUd8A3ODb4beCRHub03uyTVTrRCb6o7KrShkY5T/NbQ/0 6iSQfT1RIltB/THz1LaFa7kIuqr3ojJgeGhQEZfLxpDm6fW603XNQjwFjAnaZCD1SYJXvX B6rDSGFc5pkQKEEMZHthnWV1vh18KWq5fdJDA9+nRWgih8a3poX9qUrAoEpurA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from ltc.des.no (unknown [IPv6:2001:4647:d671:0:36e8:94ff:feca:9834]) (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) (Authenticated sender: des) by smtp.freebsd.org (Postfix) with ESMTPSA id 4RNMym68zHzKB for ; Sat, 12 Aug 2023 14:11:12 +0000 (UTC) (envelope-from des@freebsd.org) Received: by ltc.des.no (Postfix, from userid 1001) id 5144C183CD; Sat, 12 Aug 2023 16:11:10 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: current@freebsd.org Subject: Re: ZFS deadlock in 14 In-Reply-To: <86leeltqcb.fsf@ltc.des.no> ("Dag-Erling =?utf-8?Q?Sm=C3=B8rg?= =?utf-8?Q?rav=22's?= message of "Tue, 08 Aug 2023 19:07:48 +0200") References: <86leeltqcb.fsf@ltc.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (berkeley-unix) Date: Sat, 12 Aug 2023 16:11:10 +0200 Message-ID: <86h6p4s64h.fsf@ltc.des.no> 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=utf-8 Content-Transfer-Encoding: quoted-printable Dag-Erling Sm=C3=B8rgrav writes: > At some point between 42d088299c (4 May) and f0c9703301 (26 June), a > deadlock was introduced in ZFS. Trying to narrow this range down, I did not get a deadlock with 4e8d558c9d1c (10 June) but I did with b7198dcfc039 (16 June), albeit after building ~1800 packages. This is surprising since we have a report of this or a very similar deadlock occurring with a kernel from 8 June (https://bugs.freebsd.org/271945). Perhaps I should try 4e8d558c9d1c again. Here's the complete kgdb session showing, once again, a zfs rollback stuck waiting for the txg to sync: Reading symbols from /boot/GENERIC/kernel... Reading symbols from /usr/lib/debug//boot/GENERIC/kernel.debug... =20=20=20=20 Unread portion of the kernel message buffer: panic: deadlres_td_sleep_q: possible deadlock detected for 0xfffffe0356= 7a01e0 (sh), blocked for 180242 ticks =20=20=20=20 cpuid =3D 17 time =3D 1691802362 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe021= 507ce00 vpanic() at vpanic+0x150/frame 0xfffffe021507ce50 panic() at panic+0x43/frame 0xfffffe021507ceb0 deadlkres() at deadlkres+0x350/frame 0xfffffe021507cef0 fork_exit() at fork_exit+0x80/frame 0xfffffe021507cf30 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe021507cf30 --- trap 0xdeadc0de, rip =3D 0xdeadc0dedeadc0de, rsp =3D 0xdeadc0dedead= c0de, rbp =3D 0xdeadc0dedeadc0de --- KDB: enter: panic =20=20=20=20 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:59 59 __asm("movq %%gs:%P1,%0" : "=3Dr" (td) : "n" (offsetof(struct pcpu, (kgdb) tid 0xfffffe03567a01e0 (kgdb) bt #0 sched_switch (td=3Dtd@entry=3D0xfffffe03567a01e0, flags=3Dflags@ent= ry=3D259) at /usr/src/sys/kern/sched_ule.c:2299 #1 0xffffffff80b5fbd4 in mi_switch (flags=3Dflags@entry=3D259) at /usr= /src/sys/kern/kern_synch.c:550 #2 0xffffffff80bb1257 in sleepq_switch (wchan=3D0xfffff80b139e4770, wc= han@entry=3D0xffffffff8113878f, pri=3Dpri@entry=3D64) at /usr/src/sys/kern/= subr_sleepqueue.c:609 #3 0xffffffff80bb112e in sleepq_wait (wchan=3D, pri=3D) at /usr/src/sys/kern/subr_sleepqueue.c:660 #4 0xffffffff80b21d6f in sleeplk (lk=3Dlk@entry=3D0xfffff80b139e4770, = flags=3Dflags@entry=3D2122752, ilk=3Dilk@entry=3D0x0, wmesg=3Dwmesg@entry= =3D0xffffffff8113878f "tmpfs", pri=3D, pri@entry=3D64, timo= =3Dtimo@entry=3D6, queue=3D1) at /usr/src/sys/kern/kern_lock.c:310 #5 0xffffffff80b1fd9f in lockmgr_slock_hard (lk=3D0xfffff80b139e4770, = flags=3D2122752, ilk=3D, file=3D0xffffffff81296919 "/usr/src= /sys/kern/vfs_lookup.c", line=3D1012, lwa=3D0x0) at /usr/src/sys/kern/kern_= lock.c:705 #6 0xffffffff80c5e444 in VOP_LOCK1 (vp=3D0xfffff80b139e4700, flags=3D2= 106368, file=3D0xffffffff81296919 "/usr/src/sys/kern/vfs_lookup.c", line=3D= 1012) at ./vnode_if.h:1120 #7 _vn_lock (vp=3D0xfffff80b139e4700, flags=3D2106368, file=3D, line=3D) at /usr/src/sys/kern/vfs_vnops.c:1808 #8 0xffffffff80c36eae in vfs_lookup (ndp=3Dndp@entry=3D0xfffffe03c63a6= bd8) at /usr/src/sys/kern/vfs_lookup.c:1010 #9 0xffffffff80c36291 in namei (ndp=3Dndp@entry=3D0xfffffe03c63a6bd8) = at /usr/src/sys/kern/vfs_lookup.c:689 #10 0xffffffff80c5681f in kern_statat (td=3D0xfffffe03567a01e0, td@entr= y=3D, flag=3D, fd=3D-100, path=3D0x1032a8685a15= , pathseg=3Dpathseg= @entry=3DUIO_USERSPACE, sbp=3Dsbp@entry=3D0xfffffe03c63a6d18) at /usr/src/sys/kern/vfs_syscalls.c:2441 #11 0xffffffff80c56f17 in sys_fstatat (td=3D, td@entry=3D<= error reading variable: value is not available>, uap=3D0xfffffe03567a05e0, = uap@entry=3D) at /usr/src/s= ys/kern/vfs_syscalls.c:2419 #12 0xffffffff8104d8e0 in syscallenter (td=3D) at /usr/s= rc/sys/amd64/amd64/../../kern/subr_syscall.c:190 #13 amd64_syscall (td=3D0xfffffe03567a01e0, traced=3D0) at /usr/src/sys= /amd64/amd64/trap.c:1199 #14 #15 0x0000103acaf3b03a in ?? () Backtrace stopped: Cannot access memory at address 0x103ac929af28 (kgdb) f 5 #5 0xffffffff80b1fd9f in lockmgr_slock_hard (lk=3D0xfffff80b139e4770, = flags=3D2122752, ilk=3D, file=3D0xffffffff81296919 "/usr/src= /sys/kern/vfs_lookup.c", line=3D1012, lwa=3D0x0) at /usr/src/sys/kern/kern_= lock.c:705 705 error =3D sleeplk(lk, flags, ilk, iwmesg, ipri, itimo, (kgdb) p (struct thread *)(lk->lk_lock & ~0x1f) $1 =3D (struct thread *) 0xfffffe02ddae0e40 (kgdb) tid 0xfffffe02ddae0e40 (kgdb) bt #0 sched_switch (td=3Dtd@entry=3D0xfffffe02ddae0e40, flags=3Dflags@ent= ry=3D259) at /usr/src/sys/kern/sched_ule.c:2299 #1 0xffffffff80b5fbd4 in mi_switch (flags=3Dflags@entry=3D259) at /usr= /src/sys/kern/kern_synch.c:550 #2 0xffffffff80bb1257 in sleepq_switch (wchan=3Dwchan@entry=3D0xfffff8= 1ab3c81154, pri=3D87, pri@entry=3D-1278734048) at /usr/src/sys/kern/subr_sl= eepqueue.c:609 #3 0xffffffff80bb112e in sleepq_wait (wchan=3D, pri=3D) at /usr/src/sys/kern/subr_sleepqueue.c:660 #4 0xffffffff80b5f11d in _sleep (ident=3D0xfffff81ab3c81154, lock=3D0x= fffff81ab3c81120, priority=3D87, wmesg=3D0xffffffff82239fba "zfs teardown i= nactive", sbt=3D0, pr=3D0, flags=3D256) at /usr/src/sys/kern/kern_synch.c:2= 25 #5 0xffffffff80b4b640 in rms_rlock_fallback (rms=3Drms@entry=3D0xfffff= 81ab3c81120) at /usr/src/sys/kern/kern_rmlock.c:1015 #6 0xffffffff80b4b51c in rms_rlock (rms=3D, rms@entry=3D0= xfffff81ab3c81120) at /usr/src/sys/kern/kern_rmlock.c:1036 #7 0xffffffff81faff5c in zfs_freebsd_reclaim (ap=3D) at= /usr/src/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vnops_os.c:5164 #8 0xffffffff811215e4 in VOP_RECLAIM_APV (vop=3D0xffffffff822e61a0 , a=3Da@entry=3D0xfffffe02fb2118a0) at vnode_if.c:2180 #9 0xffffffff80c47d54 in VOP_RECLAIM (vp=3D0xfffff80912340000) at ./vn= ode_if.h:1084 #10 vgonel (vp=3Dvp@entry=3D0xfffff80912340000) at /usr/src/sys/kern/vf= s_subr.c:4143 #11 0xffffffff80c436f2 in vtryrecycle (vp=3D0xfffff80912340000) at /usr= /src/sys/kern/vfs_subr.c:1693 #12 vnlru_free_impl (count=3Dcount@entry=3D1, mnt_op=3Dmnt_op@entry=3D0= x0, mvp=3D0xfffff8010945da00) at /usr/src/sys/kern/vfs_subr.c:1344 #13 0xffffffff80c4dd83 in vnlru_free_locked (count=3D1) at /usr/src/sys= /kern/vfs_subr.c:1357 #14 vn_alloc_hard (mp=3Dmp@entry=3D0xfffffe0314140000) at /usr/src/sys/= kern/vfs_subr.c:1744 #15 0xffffffff80c43db1 in vn_alloc (mp=3D0xfffffe0314140000) at /usr/sr= c/sys/amd64/include/atomic.h:375 #16 getnewvnode (tag=3D0xffffffff8113878f "tmpfs", mp=3D0xfffffe0314140= 000, vops=3D0xffffffff816b7a70 , vpp=3Dvpp@entry=3D0= xfffffe02fb211a30) at /usr/src/sys/kern/vfs_subr.c:1810 #17 0xffffffff80a7b27c in tmpfs_alloc_vp (mp=3D0xfffffe0314140000, node= =3Dnode@entry=3D0xfffff81924deabc8, lkflag=3Dlkflag@entry=3D524288, vpp=3D0= xfffffe02fb211cf0) at /usr/src/sys/fs/tmpfs/tmpfs_subr.c:1027 #18 0xffffffff80a7b985 in tmpfs_alloc_file (dvp=3Ddvp@entry=3D0xfffff80= b139e4700, vpp=3D, vpp@entry=3D0xfffffe02fb211cf0, vap=3D, cnp=3Dcnp@entry=3D0xfffffe02fb211d18, target=3Dtarget@entry=3D0= x0) at /usr/src/sys/fs/tmpfs/tmpfs_subr.c:1203 #19 0xffffffff80a74d28 in tmpfs_create (v=3D) at /usr/sr= c/sys/fs/tmpfs/tmpfs_vnops.c:271 #20 0xffffffff8111eb99 in VOP_CREATE_APV (vop=3D0xffffffff816b7a70 , a=3Da@entry=3D0xfffffe02fb211be0) at vnode_if.c:244 #21 0xffffffff80c5d94c in VOP_CREATE (dvp=3D, vpp=3D0xffff= fe02fb211cf0, cnp=3D0xfffffe02fb211d18, vap=3D0xfffffe02fb211b20) at ./vnod= e_if.h:133 #22 vn_open_cred (ndp=3Dndp@entry=3D0xfffffe02fb211c98, flagp=3Dflagp@e= ntry=3D0xfffffe02fb211da4, cmode=3Dcmode@entry=3D420, vn_open_flags=3Dvn_op= en_flags@entry=3D16, cred=3D0xfffff8010978bc00, fp=3D0xfffff804f42cff00) at= /usr/src/sys/kern/vfs_vnops.c:287 #23 0xffffffff80c53f43 in kern_openat (td=3D0xfffffe02ddae0e40, td@entr= y=3D, fd=3Dfd@entry=3D-100, path=3D0x8222f799b , pathseg=3Dpathseg@entry=3DUIO_USERSP= ACE, flags=3D1538, mode=3D) at /usr/src/sys/kern/vfs_syscalls.c:1167 #24 0xffffffff80c53cad in sys_open (td=3Dtd@entry=3D, uap= =3Duap@entry=3D) at /usr/src/sys/kern/vfs_syscalls.c:1095 #25 0xffffffff82b18365 in filemon_wrapper_open (td=3D, td@= entry=3D, uap=3D, uap@entry=3D) at /usr/s= rc/sys/dev/filemon/filemon_wrapper.c:220 #26 0xffffffff8104d8e0 in syscallenter (td=3D) at /usr/s= rc/sys/amd64/amd64/../../kern/subr_syscall.c:190 #27 amd64_syscall (td=3D0xfffffe02ddae0e40, traced=3D0) at /usr/src/sys= /amd64/amd64/trap.c:1199 #28 #29 0x0000000829c8227a in ?? () Backtrace stopped: Cannot access memory at address 0x8222f6868 (kgdb) f 7 #7 0xffffffff81faff5c in zfs_freebsd_reclaim (ap=3D) at= /usr/src/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vnops_os.c:5164 5164 ZFS_TEARDOWN_INACTIVE_ENTER_READ(zfsvfs); (kgdb) p zp->z_zfsvfs->z_teardown_inactive_lock->owner $2 =3D (struct thread *) 0xfffffe0314249020 (kgdb) tid 0xfffffe0314249020 (kgdb) bt #0 sched_switch (td=3Dtd@entry=3D0xfffffe0314249020, flags=3Dflags@ent= ry=3D259) at /usr/src/sys/kern/sched_ule.c:2299 #1 0xffffffff80b5fbd4 in mi_switch (flags=3Dflags@entry=3D259) at /usr= /src/sys/kern/kern_synch.c:550 #2 0xffffffff80bb1257 in sleepq_switch (wchan=3Dwchan@entry=3D0xfffff8= 0108fe1540, pri=3D0, pri@entry=3D150869200) at /usr/src/sys/kern/subr_sleep= queue.c:609 #3 0xffffffff80bb112e in sleepq_wait (wchan=3D, wchan@ent= ry=3D0xfffff80108fe1540, pri=3D, pri@entry=3D0) at /usr/src/sy= s/kern/subr_sleepqueue.c:660 #4 0xffffffff80ade224 in _cv_wait (cvp=3D0xfffff80108fe1540, lock=3D0x= fffff80108fe14d0) at /usr/src/sys/kern/kern_condvar.c:146 #5 0xffffffff820b383b in txg_wait_synced_impl (dp=3D0xfffff80108fe1000= , txg=3D8751529, txg@entry=3D0, wait_sig=3Dwait_sig@entry=3D0) at /usr/src/= sys/contrib/openzfs/module/zfs/txg.c:726 #6 0xffffffff820b31eb in txg_wait_synced (dp=3D, txg=3D, txg@entry=3D0) at /usr/src/sys/contrib/openzfs/module/zfs/txg.= c:736 #7 0xffffffff81fa5fc5 in zfsvfs_teardown (zfsvfs=3D0xfffff81ab3c81000,= unmounting=3Dunmounting@entry=3D0) at /usr/src/sys/contrib/openzfs/module/= os/freebsd/zfs/zfs_vfsops.c:1661 #8 0xffffffff81fa5db9 in zfs_suspend_fs (zfsvfs=3D) at /u= sr/src/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vfsops.c:1954 #9 0xffffffff821680ff in zfs_ioc_rollback (fsname=3D0xfffffe0301913000= "zroot-default-ref/03", fsname@entry=3D, innvl=3D, innvl@entry=3D,=20 outnvl=3D0xfffff81601748640, outnvl@entry=3D) at /usr/src/sys/contrib/openzfs/module/zfs/zfs_i= octl.c:4401 #10 0xffffffff82163836 in zfsdev_ioctl_common (vecnum=3Dvecnum@entry=3D= 25, zc=3Dzc@entry=3D0xfffffe0301913000, flag=3Dflag@entry=3D0) at /usr/src/= sys/contrib/openzfs/module/zfs/zfs_ioctl.c:7798 #11 0xffffffff81f969aa in zfsdev_ioctl (dev=3D, zcmd=3D<= unavailable>, zcmd@entry=3D= , arg=3D0xfffffe02fd546d50 "\017", arg@entry=3D, flag=3D, td=3D) at /usr/src/sys/contrib/openzfs/module/os/freebsd/zfs/kmod_core.c:1= 68 #12 0xffffffff809dc9cc in devfs_ioctl (ap=3D0xfffffe02fd546c40) at /usr= /src/sys/fs/devfs/devfs_vnops.c:935 #13 0xffffffff80c5cac0 in vn_ioctl (fp=3D0xfffff81e9207f0a0, com=3D, data=3D0xfffffe02fd546d50, active_cred=3D0xfffff8026a65a900, t= d=3D) at /usr/src/sys/kern/vfs_vnops.c:1697 #14 0xffffffff809dd07e in devfs_ioctl_f (fp=3D, fp@entry= =3D, com=3D, c= om@entry=3D, data=3D, data@entry=3D,=20 cred=3D, cred@entry=3D, td=3D, td@entry=3D) at /usr/src/sys/fs/devfs/devfs_vnops.c:866 #15 0xffffffff80bca1ce in fo_ioctl (fp=3D0xfffff81e9207f0a0, com=3D3222= 821401, data=3D, active_cred=3D, td=3D) at /usr/src/sys/sys/file.h:367 #16 kern_ioctl (td=3Dtd@entry=3D0xfffffe0314249020, fd=3D, com=3Dcom@entry=3D3222821401, data=3D, data@entry=3D0xfffff= e02fd546d50 "\017") at /usr/src/sys/kern/sys_generic.c:807 #17 0xffffffff80bc9f64 in sys_ioctl (td=3D0xfffffe0314249020, td@entry= =3D, uap=3D0xfffffe03142494= 20, uap@entry=3D) at /usr/s= rc/sys/kern/sys_generic.c:715 #18 0xffffffff8104d8e0 in syscallenter (td=3D) at /usr/s= rc/sys/amd64/amd64/../../kern/subr_syscall.c:190 #19 amd64_syscall (td=3D0xfffffe0314249020, traced=3D0) at /usr/src/sys= /amd64/amd64/trap.c:1199 #20 #21 0x000005c8e125953a in ?? () Backtrace stopped: Cannot access memory at address 0x5c8d89c8018 DES --=20 Dag-Erling Sm=C3=B8rgrav - des@FreeBSD.org From nobody Sat Aug 12 15:49:13 2023 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 4RNQ8M1Zgnz4qCD6 for ; Sat, 12 Aug 2023 15:49:39 +0000 (UTC) (envelope-from trashcan@ellael.org) Received: from mx2.enfer-du-nord.net (mx2.enfer-du-nord.net [135.125.211.209]) (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 4RNQ8L0cm2z3GM4 for ; Sat, 12 Aug 2023 15:49:37 +0000 (UTC) (envelope-from trashcan@ellael.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ellael.org header.s=dkim header.b=kuVWOk1x; spf=pass (mx1.freebsd.org: domain of trashcan@ellael.org designates 135.125.211.209 as permitted sender) smtp.mailfrom=trashcan@ellael.org; dmarc=pass (policy=quarantine) header.from=ellael.org Received: from smtpclient.apple (p5b2e5de5.dip0.t-ipconnect.de [91.46.93.229]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx2.enfer-du-nord.net (Postfix) with ESMTPSA id 4RNQ84271NzFjX for ; Sat, 12 Aug 2023 17:49:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ellael.org; s=dkim; t=1691855364; 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=PCbiVPT56yh6HeDA6FW70e0etvnc4o9wGP8lxwPjX9k=; b=kuVWOk1xv7Pu1tlkzF3Aw5WfCKKpO4tOKmTaxNeqLxyk/fp//Gxl9uQNwat+PcT83SXGhr 9jMoLMzmLGS7JPZyLwngR86VazNm726NkKOjfpnOhGh+A7/SbVYrhi4ltbpl+jAjEHsyXP 35WaymveGlwiWkFgtsP2cJuSPsIdfWjkdA0E6z8oateryaP8Yusq1UYOqS4lU9WuIS6JQ7 DVv/950C3R3gV1P26udlvCSMBE7F7/u6JE9drkALInaXeDH3tsQCJD2fW7WtigVK726nz3 nY/TKqFrXFKttqt1rhmdHZsMfL3d7Fa+dE5c/7LDn8mvA6JLxDfP55iefszRlw== From: Michael Grimm 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 16.0 \(3731.700.6\)) Subject: Re: periodic daily produces ridiculously huge report files Date: Sat, 12 Aug 2023 17:49:13 +0200 References: <60209E13-5019-4E2C-889A-E36B5FD6DDCE@ellael.org> To: freebsd-current@freebsd.org In-Reply-To: <60209E13-5019-4E2C-889A-E36B5FD6DDCE@ellael.org> Message-Id: X-Mailer: Apple Mail (2.3731.700.6) X-Spamd-Result: default: False [-3.38 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.998]; NEURAL_HAM_SHORT(-0.98)[-0.983]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[ellael.org,quarantine]; R_DKIM_ALLOW(-0.20)[ellael.org:s=dkim]; R_SPF_ALLOW(-0.20)[+ip4:135.125.211.209]; MIME_GOOD(-0.10)[text/plain]; ONCE_RECEIVED(0.10)[]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_ALL(0.00)[]; ASN(0.00)[asn:16276, ipnet:135.125.128.0/17, country:FR]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[ellael.org:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[] X-Spamd-Bar: --- X-Rspamd-Queue-Id: 4RNQ8L0cm2z3GM4 Michael Grimm wrote > Ever since either upgrading to MAIN or WITHOUT_INET6=3Dyes [1] I = noticed that periodic daily still runs in the morning failing to mail = ridiculously huge report files (>=3D 90 *GB*). >=20 > [1] Can't remember when this started. FTR: It started with WITHOUT_INET6=3Dyes. Recompiling world and kernel = including IPv6 support brings "netstat -i -d -W -n" back to normal = behavior. No more of netstat producing producing huge amounts of = garbage.=20 > But I would like to know, if this has to do with WITHOUT_INET6=3Dyes = or FreeBSD 14? > Or something different ... >=20 > Did someone of you experiences equal behaviour of "netstat -i -d -W"? > Anyone with WITHOUT_INET6=3Dyes willing to test this? Anyone? Regards, Michael From nobody Sat Aug 12 17:05:35 2023 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 4RNRrK69nTz4qHfr for ; Sat, 12 Aug 2023 17:05:53 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-yb1-xb2b.google.com (mail-yb1-xb2b.google.com [IPv6:2607:f8b0:4864:20::b2b]) (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 4RNRrK148Mz3Q6H for ; Sat, 12 Aug 2023 17:05:53 +0000 (UTC) (envelope-from kob6558@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20221208 header.b=SF4yG2Qb; spf=pass (mx1.freebsd.org: domain of kob6558@gmail.com designates 2607:f8b0:4864:20::b2b as permitted sender) smtp.mailfrom=kob6558@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-yb1-xb2b.google.com with SMTP id 3f1490d57ef6-d62b9bd5b03so2769867276.1 for ; Sat, 12 Aug 2023 10:05:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691859952; x=1692464752; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=+231Dz7sKPM0ZhqrOZIIf369cup096meUcwAQ5ubV3U=; b=SF4yG2QboBxzWCgiLqlSkIYRCQYm/X7eh4ZOiGz/WlkWLFrcDTPEem9JXD4ZL9Wha8 z+xKqULAakPhNVPddXpAJW3Ohw6p0gtEQVACWmwUukXWrMdEjp1vn7Y1zN8loeuknzIn PYhJVTFuNC48ykxvBsOeYIL1t7hN89nqwJGQ2CwAUcyqkyRig1DQ7SLmo80GFebm+Plw vX+UacZC63FoIhP4tIY6HZRsdDmpn1RT/WM8clzcmmOO9adNXoF7QdMqP5pol2zXNGlt gR5K9xixsJU6M4VW+0FMMKTH9D8i6Gr2oYn8obHgjI70x0yV8z1PfSXk/kHn0ZtwQsuh e7zA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691859952; x=1692464752; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=+231Dz7sKPM0ZhqrOZIIf369cup096meUcwAQ5ubV3U=; b=gvHYxiN4Y1xfkTFkTWztUMfe8TBzHSNZaWrW6ps2W6MTz2t9YZmq21P9kWNjoVxXdY tSmB++KrC/HVyaGAOlNsq9R9Hr4phJpXxCk0JQ97If9etio4+unc+SrcdEE267vJzXBS or6Y/GfgdpscPtN04hhmwSRzWcnYvgFOCxH7w3NMVzdN9q7tk14PRoY7E5bs4HRGuyVR ABOcdCf/b8FoeUhzvZOTlLZYVuHRWNh/oNQTglubYLF/FcpiOUgraT03YO9Ry6m4pn5L YP0l2FslUvtMpOEw3NUZ8gWcctHWYq1vnMpL3INxEkjGX039uU9qs+Xxls3fm0OSM11U 8eHQ== X-Gm-Message-State: AOJu0Ywj/T6Xf7rosWrlGaRhJUYemSNUpdI66GHoUZoGJYA8lgIn3GdA 60XE6KXgAjHhpixS3eRe2UxTACSZNg7d8U4qcgNLMLGd8So= X-Google-Smtp-Source: AGHT+IF3L22TMdXzlcCmgpSv4jf//MjMB1ormIuG8VEMg+3BkH3m/SRbsmRT+7KBiT5tOBNRA3j/3e61FazdGxC9T1w= X-Received: by 2002:a25:fc21:0:b0:c15:c55d:c26e with SMTP id v33-20020a25fc21000000b00c15c55dc26emr5503785ybd.54.1691859951839; Sat, 12 Aug 2023 10:05:51 -0700 (PDT) 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: <59cbcfe2-cd53-69d8-65d6-7a79e656f494@FreeBSD.org> <1f968af1-1c57-9a09-7e01-145a5262e27f@FreeBSD.org> <20230806181238.858f58e25dfd0f99269cfe53@dec.sakura.ne.jp> <20230808063735.e8e1d3ede370a18f200a6f48@dec.sakura.ne.jp> <20230808224612.c3889d6e20b6fc980f5278cc@dec.sakura.ne.jp> <20230808235635.744e0e1c6a72face7fdf6a9b@dec.sakura.ne.jp> <4f0fbb44-eebe-aa8f-f958-dcd678936fe1@protected-networks.net> In-Reply-To: <4f0fbb44-eebe-aa8f-f958-dcd678936fe1@protected-networks.net> From: Kevin Oberman Date: Sat, 12 Aug 2023 10:05:35 -0700 Message-ID: Subject: Re: [Intel AlderLake] Read&Write files to FAT32 or UFS partition cause data corrupt due to P-Core&E-Core To: Michael Butler Cc: freebsd-current@freebsd.org Content-Type: multipart/alternative; boundary="000000000000706d570602bcd762" X-Spamd-Result: default: False [-3.61 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; NEURAL_HAM_LONG(-0.91)[-0.913]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FORGED_SENDER(0.30)[rkoberman@gmail.com,kob6558@gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20221208]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; ARC_NA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::b2b:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; FROM_NEQ_ENVFROM(0.00)[rkoberman@gmail.com,kob6558@gmail.com]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_ONE(0.00)[1]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_TLS_LAST(0.00)[] X-Spamd-Bar: --- X-Rspamd-Queue-Id: 4RNRrK148Mz3Q6H --000000000000706d570602bcd762 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Aug 8, 2023 at 10:50=E2=80=AFAM Michael Butler wrote: > On 8/8/23 10:56, Tomoaki AOKI wrote: > > On Tue, 8 Aug 2023 17:02:32 +0300 > > Konstantin Belousov wrote: > > [ .. snip .. ] > > >> The workaround is switched on automatically, when kernel detects 'smal= l > cores' > >> reported by CPUID. > > > > If I read the code correctly, vm.pmap.pcid_invlpg_workaround > > (precicely, the corresponding variable) is set to non-zero when the > > workaround is enabled. Not sure it was detected correctly at the > > original reporter's environment, but forcibly setting the tunable to 1 > > didn't reported to help sufficiently. > > Currently, only setting tunable vm.pmap.pcid_enabled to 0 could help. > > I'm seeing similar stability problems on an N95-based device. This too > is an Alderlake-N device with only E-cores although I'm running it with > a compilation with CPUTYPE=3Dtremont .. from an older, verbose start-up .= . > > PPIM 0: PA=3D0x4000000000, VA=3D0xffffffff82710000, size=3D0x1d5000, mode= =3D0x1 > pmap: large map 8 PML4 slots (4096 GB) > VT(efifb): resolution 800x600 > Preloaded elf kernel "/boot/kernel.new/kernel" at 0xffffffff8234e000. > Preloaded boot_entropy_cache "/boot/entropy" at 0xffffffff82357d08. > Preloaded cpu_microcode "/boot/firmware/intel-ucode.bin" at > 0xffffffff82357d60. > Preloaded hostuuid "/etc/hostid" at 0xffffffff82357dc0. > Preloaded TSLOG data "TSLOG" at 0xffffffff82357e10. > CPU: Intel(R) N95 (1689.60-MHz K8-class CPU) > Origin=3D"GenuineIntel" Id=3D0xb06e0 Family=3D0x6 Model=3D0xbe Ste= pping=3D0 > > > Features=3D0xbfebfbff > > > Features2=3D0x7ffafbbf > AMD Features=3D0x2c100800 > AMD Features2=3D0x121 > Structured Extended > > Features=3D0x239ca7eb > Structured Extended > > Features2=3D0x98c007bc > Structured Extended > > Features3=3D0xfc184410 > XSAVE Features=3D0xf > IA32_ARCH_CAPS=3D0x180fd6b > VT-x: Basic Features=3D0x3da0500 > Pin-Based Controls=3D0xff > Primary Processor > > Controls=3D0xfffbfffe > Secondary Processor > > Controls=3D0x75d7fff > Exit Controls=3D0x3da0500 > Entry Controls=3D0x3da0500 > EPT Features=3D0x6f34141 > VPID Features=3D0xf01 > TSC: P-state invariant, performance statistics > 64-Byte prefetching > L2 cache: 2048 kbytes, 16-way associative, 64 bytes/line > real memory =3D 17179869184 (16384 MB) > Physical memory chunk(s): > 0x0000000000010000 - 0x000000000009dfff, 581632 bytes (142 pages) > 0x000000000009f000 - 0x000000000009ffff, 4096 bytes (1 pages) > 0x0000000000100000 - 0x000000005fffffff, 1609564160 bytes (392960 pages) > 0x0000000062401000 - 0x000000007264dfff, 270848000 bytes (66125 pages) > 0x0000000075fff000 - 0x0000000075ffffff, 4096 bytes (1 pages) > 0x0000000100001000 - 0x0000000462497fff, 14533881856 bytes (3548311 pages= ) > 0x000000047fa00000 - 0x000000047fb68fff, 1478656 bytes (361 pages) > avail memory =3D 16363008000 (15604 MB) > CPU microcode: updated from 0xc to 0x10 > MADT: Found CPU APIC ID 0 ACPI ID 0: enabled > SMP: Added CPU 0 (AP) > MADT: Found CPU APIC ID 2 ACPI ID 1: enabled > SMP: Added CPU 2 (AP) > MADT: Found CPU APIC ID 4 ACPI ID 2: enabled > SMP: Added CPU 4 (AP) > MADT: Found CPU APIC ID 6 ACPI ID 3: enabled > SMP: Added CPU 6 (AP) > > On start-up, vm.pmap.pcid_invlpg_workaround=3D1 but seemingly random > faults still occurred under load, for example, 'make buildworld'. > Apparent misreads of source-files resulting in syntax errors were the > most common symptom. Compilation reattempts (mostly) succeed. > > Initially, I put this down to an inadequate power-supply but setting > vm.pmap.pcid_enabled=3D0 seems to have stabilised it. > > I guess there's another dragon in there .. :-( > > Michae > Just to add another report (in the wrong mail list as it is also on a system running 13.2), I have a very similar system from a different manufacturer with the same Alder Lake processor. I will note that the SSD interface is SATA, not nvme. I was getting crashes and corrupt file systems, especially when installing large ports and using rsync to backup the system. I see many, almost identical systems on Amazon that use the same form factor CPU, SSD, RAM, etc, probably all using the same motherboard from a single manufacturer. There are going to be more issues as these boxes are generally <$225 US. (Mine was a bit more expensive to get a VGA connector for my ancient monitor. I had not tried the tuneable, but largely resolved the issue by installing a 250 MB hard drive and putting the system there. In the couple of months since I did this I have had two crashes, both when doing a full backup with rsync. This leads me to think that there is some sort of race triggering this that is minimized by the slow disc speed of spinning rust. I am considering moving the system back to the SSD with vm.pmap.pcid_enabled=3D0. If so, the failure should be very quick as I neve= r could keep the system up long enough to get the system into production. --=20 Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkoberman@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 --000000000000706d570602bcd762 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Aug 8, 2023 at 10:50=E2= =80=AFAM Michael Butler <i= mb@protected-networks.net> wrote:
On 8/8/23 10:56, Tomo= aki AOKI wrote:
> On Tue, 8 Aug 2023 17:02:32 +0300
> Konstantin Belousov <kostikbel@gmail.com> wrote:

=C2=A0 [ .. snip .. ]

>> The workaround is switched on automatically, when kernel detects &= #39;small cores'
>> reported by CPUID.
>
> If I read the code correctly, vm.pmap.pcid_invlpg_workaround
> (precicely, the corresponding variable) is set to non-zero when the > workaround is enabled. Not sure it was detected correctly at the
> original reporter's environment, but forcibly setting the tunable = to 1
> didn't reported to help sufficiently.
> Currently, only setting tunable vm.pmap.pcid_enabled to 0 could help.<= br>
I'm seeing similar stability problems on an N95-based device. This too =
is an Alderlake-N device with only E-cores although I'm running it with=
a compilation with CPUTYPE=3Dtremont .. from an older, verbose start-up ..<= br>
PPIM 0: PA=3D0x4000000000, VA=3D0xffffffff82710000, size=3D0x1d5000, mode= =3D0x1
pmap: large map 8 PML4 slots (4096 GB)
VT(efifb): resolution 800x600
Preloaded elf kernel "/boot/kernel.new/kernel" at 0xffffffff8234e= 000.
Preloaded boot_entropy_cache "/boot/entropy" at 0xffffffff82357d0= 8.
Preloaded cpu_microcode "/boot/firmware/intel-ucode.bin" at
0xffffffff82357d60.
Preloaded hostuuid "/etc/hostid" at 0xffffffff82357dc0.
Preloaded TSLOG data "TSLOG" at 0xffffffff82357e10.
CPU: Intel(R) N95 (1689.60-MHz K8-class CPU)
=C2=A0 =C2=A0Origin=3D"GenuineIntel"=C2=A0 Id=3D0xb06e0=C2=A0 Fam= ily=3D0x6=C2=A0 Model=3D0xbe=C2=A0 Stepping=3D0

Features=3D0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,P= GE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE><= br>
Features2=3D0x7ffafbbf<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE= 3,SDBG,FMA,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AES= NI,XSAVE,OSXSAVE,AVX,F16C,RDRAND>
=C2=A0 =C2=A0AMD Features=3D0x2c100800<SYSCALL,NX,Page1GB,RDTSCP,LM><= br> =C2=A0 =C2=A0AMD Features2=3D0x121<LAHF,ABM,Prefetch>
=C2=A0 =C2=A0Structured Extended
Features=3D0x239ca7eb<FSGSBASE,TSCADJ,BMI1,AVX2,FDPEXC,SMEP,BMI2,ERMS,IN= VPCID,NFPUSG,PQE,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,PROCTRACE,SHA>
=C2=A0 =C2=A0Structured Extended
Features2=3D0x98c007bc<UMIP,PKU,OSPKE,WAITPKG,GFNI,VAES,VPCLMULQDQ,RDPID= ,MOVDIRI,MOVDIR64B>
=C2=A0 =C2=A0Structured Extended
Features3=3D0xfc184410<FSRM,MD_CLEAR,IBT,IBPB,STIBP,L1DFL,ARCH_CAP,CORE_= CAP,SSBD>
=C2=A0 =C2=A0XSAVE Features=3D0xf<XSAVEOPT,XSAVEC,XINUSE,XSAVES>
=C2=A0 =C2=A0IA32_ARCH_CAPS=3D0x180fd6b<RDCL_NO,IBRS_ALL,SKIP_L1DFL_VME,= MDS_NO,TAA_NO>
=C2=A0 =C2=A0VT-x: Basic Features=3D0x3da0500<SMM,INS/OUTS,TRUE>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Pin-Based Controls=3D0xff<ExtINT,NMI,V= NMI,PreTmr,PostIntr>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Primary Processor
Controls=3D0xfffbfffe<INTWIN,TSCOff,HLT,INVLPG,MWAIT,RDPMC,RDTSC,CR3-LD,= CR3-ST,CR8-LD,CR8-ST,TPR,NMIWIN,MOV-DR,IO,IOmap,MTF,MSRmap,MONITOR,PAUSE>= ;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Secondary Processor
Controls=3D0x75d7fff<APIC,EPT,DT,RDTSCP,x2APIC,VPID,WBINVD,UG,APIC-reg,V= ID,PAUSE-loop,RDRAND,INVPCID,VMFUNC,VMCS,XSAVES>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Exit Controls=3D0x3da0500<PAT-LD,EFER-= SV,PTMR-SV>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Entry Controls=3D0x3da0500
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0EPT Features=3D0x6f34141<XO,PW4,UC,WB,= 2M,1G,INVEPT,AD,single,all>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0VPID Features=3D0xf01<INVVPID,individu= al,single,all,single-globals>
=C2=A0 =C2=A0TSC: P-state invariant, performance statistics
64-Byte prefetching
L2 cache: 2048 kbytes, 16-way associative, 64 bytes/line
real memory=C2=A0 =3D 17179869184 (16384 MB)
Physical memory chunk(s):
0x0000000000010000 - 0x000000000009dfff, 581632 bytes (142 pages)
0x000000000009f000 - 0x000000000009ffff, 4096 bytes (1 pages)
0x0000000000100000 - 0x000000005fffffff, 1609564160 bytes (392960 pages) 0x0000000062401000 - 0x000000007264dfff, 270848000 bytes (66125 pages)
0x0000000075fff000 - 0x0000000075ffffff, 4096 bytes (1 pages)
0x0000000100001000 - 0x0000000462497fff, 14533881856 bytes (3548311 pages)<= br> 0x000000047fa00000 - 0x000000047fb68fff, 1478656 bytes (361 pages)
avail memory =3D 16363008000 (15604 MB)
CPU microcode: updated from 0xc to 0x10
MADT: Found CPU APIC ID 0 ACPI ID 0: enabled
SMP: Added CPU 0 (AP)
MADT: Found CPU APIC ID 2 ACPI ID 1: enabled
SMP: Added CPU 2 (AP)
MADT: Found CPU APIC ID 4 ACPI ID 2: enabled
SMP: Added CPU 4 (AP)
MADT: Found CPU APIC ID 6 ACPI ID 3: enabled
SMP: Added CPU 6 (AP)

On start-up, vm.pmap.pcid_invlpg_workaround=3D1 but seemingly random
faults still occurred under load, for example, 'make buildworld'. <= br> Apparent misreads of source-files resulting in syntax errors were the
most common symptom. Compilation reattempts (mostly) succeed.

Initially, I put this down to an inadequate power-supply but setting
vm.pmap.pcid_enabled=3D0 seems to have stabilised it.

I guess there's another dragon in there .. :-(

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Michae

Just to add another report (= in the wrong mail list as it is also on a system running 13.2), I have a ve= ry similar system from a different manufacturer with the same Alder Lake pr= ocessor. I will note that the SSD interface is SATA, not nvme. I was gettin= g crashes and corrupt file systems, especially when installing large ports = and using rsync to backup the system. I see many, almost identical systems = on Amazon that use the same form factor CPU, SSD, RAM, etc, probably all us= ing the same motherboard from a single manufacturer. There are going to be = more issues as these boxes are generally <$225 US. (Mine was a bit more = expensive to get a VGA connector for my ancient monitor.

I had not tried the tuneable, but largely resolved th= e issue by installing a 250 MB hard drive and putting the system there. In = the couple of months since I did this I have had two crashes, both when doi= ng a full backup with rsync. This leads me to think that there is some sort= of race triggering this that is minimized by the slow disc speed of spinni= ng rust.

I am considering moving the= system back to the SSD with vm.pmap.pcid_enabled=3D0. If so, the failure s= hould be very quick as I never could keep the system up long enough to get = the system into production.
--
Kev= in Oberman, Part time kid herder and retired Network Engineer
E-mail: rkoberman@gmail.com<= /a>
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683=
--000000000000706d570602bcd762-- From nobody Sat Aug 12 17:08:53 2023 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 4RNRx62Cfgz4qJ6W; Sat, 12 Aug 2023 17:10:02 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta002.cacentral1.a.cloudfilter.net (omta002.cacentral1.a.cloudfilter.net [3.97.99.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RNRx55qG2z3Rgt; Sat, 12 Aug 2023 17:10:01 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; none Received: from shw-obgw-4004a.ext.cloudfilter.net ([10.228.9.227]) by cmsmtp with ESMTP id UqZGqvEXh6NwhUs7kqMxpt; Sat, 12 Aug 2023 17:10:00 +0000 Received: from spqr.komquats.com ([70.66.152.170]) by cmsmtp with ESMTPA id Us7jqt6yE3fOSUs7kqtY71; Sat, 12 Aug 2023 17:10:00 +0000 X-Authority-Analysis: v=2.4 cv=J8G5USrS c=1 sm=1 tr=0 ts=64d7bce8 a=y8EK/9tc/U6QY+pUhnbtgQ==:117 a=y8EK/9tc/U6QY+pUhnbtgQ==:17 a=IkcTkHD0fZMA:10 a=UttIx32zK-AA:10 a=6I5d2MoRAAAA:8 a=YxBL1-UpAAAA:8 a=EkcXrb_YAAAA:8 a=fQWtEyl-p239-_sfO9UA:9 a=QEXdDO2ut3YA:10 a=IjZwj45LgO3ly-622nXo:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from [127.0.0.1] (unknown [192.168.0.252]) by spqr.komquats.com (Postfix) with ESMTPSA id CED0028A; Sat, 12 Aug 2023 10:09:58 -0700 (PDT) Date: Sat, 12 Aug 2023 10:08:53 -0700 From: Cy Schubert To: freebsd-current@freebsd.org, =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , current@freebsd.org Subject: Re: ZFS deadlock in 14 In-Reply-To: <86h6p4s64h.fsf@ltc.des.no> References: <86leeltqcb.fsf@ltc.des.no> <86h6p4s64h.fsf@ltc.des.no> Message-ID: <6CB02436-1FD6-43C9-BB77-925A7443D8B8@cschubert.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: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-CMAE-Envelope: MS4xfDSFH7e2T/w2PdR38WcHI70vOq/a1OVQx1XMUW4ePbOWSbG9iMlbfaB6TnZo613w39zMGbYW3r2u8xkLFzfQq7XVS9CQdonS/aIIg/+Z8V78X226iA+6 YX2cULl3BzzOKpQMG3kgqt7+UxRu1ou/bCxllPG6AIU346Tyqgjzmjb4O6PaQLcHaqBhapgzpWtoQOutxUhekzaOOrQxtGqUu/84kVOB5axN+D5jSvAzVtPu J0nJKZ12b3nckG6HNf4uZzgrGl96+8I104Tp2pO6GtY= X-Rspamd-Queue-Id: 4RNRx55qG2z3Rgt X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US] On August 12, 2023 7:11:10 AM PDT, "Dag-Erling Sm=C3=B8rgrav" wrote: >Dag-Erling Sm=C3=B8rgrav writes: >> At some point between 42d088299c (4 May) and f0c9703301 (26 June), a >> deadlock was introduced in ZFS=2E > >Trying to narrow this range down, I did not get a deadlock with >4e8d558c9d1c (10 June) but I did with b7198dcfc039 (16 June), albeit >after building ~1800 packages=2E This is surprising since we have a >report of this or a very similar deadlock occurring with a kernel from 8 >June (https://bugs=2Efreebsd=2Eorg/271945)=2E Perhaps I should try >4e8d558c9d1c again=2E > >Here's the complete kgdb session showing, once again, a zfs rollback >stuck waiting for the txg to sync: > > Reading symbols from /boot/GENERIC/kernel=2E=2E=2E > Reading symbols from /usr/lib/debug//boot/GENERIC/kernel=2Edebug=2E= =2E=2E > =20 > Unread portion of the kernel message buffer: > panic: deadlres_td_sleep_q: possible deadlock detected for 0xfffffe03= 567a01e0 (sh), blocked for 180242 ticks > =20 > cpuid =3D 17 > time =3D 1691802362 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0= 21507ce00 > vpanic() at vpanic+0x150/frame 0xfffffe021507ce50 > panic() at panic+0x43/frame 0xfffffe021507ceb0 > deadlkres() at deadlkres+0x350/frame 0xfffffe021507cef0 > fork_exit() at fork_exit+0x80/frame 0xfffffe021507cf30 > fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe021507cf30 > --- trap 0xdeadc0de, rip =3D 0xdeadc0dedeadc0de, rsp =3D 0xdeadc0dede= adc0de, rbp =3D 0xdeadc0dedeadc0de --- > KDB: enter: panic > =20 > __curthread () at /usr/src/sys/amd64/include/pcpu_aux=2Eh:59 > 59 __asm("movq %%gs:%P1,%0" : "=3Dr" (td) : "n" (offsetof(struct pcp= u, > (kgdb) tid 0xfffffe03567a01e0 > (kgdb) bt > #0 sched_switch (td=3Dtd@entry=3D0xfffffe03567a01e0, flags=3Dflags@e= ntry=3D259) at /usr/src/sys/kern/sched_ule=2Ec:2299 > #1 0xffffffff80b5fbd4 in mi_switch (flags=3Dflags@entry=3D259) at /u= sr/src/sys/kern/kern_synch=2Ec:550 > #2 0xffffffff80bb1257 in sleepq_switch (wchan=3D0xfffff80b139e4770, = wchan@entry=3D0xffffffff8113878f, pri=3Dpri@entry=3D64) at /usr/src/sys/ker= n/subr_sleepqueue=2Ec:609 > #3 0xffffffff80bb112e in sleepq_wait (wchan=3D, pri=3D<= unavailable>) at /usr/src/sys/kern/subr_sleepqueue=2Ec:660 > #4 0xffffffff80b21d6f in sleeplk (lk=3Dlk@entry=3D0xfffff80b139e4770= , flags=3Dflags@entry=3D2122752, ilk=3Dilk@entry=3D0x0, wmesg=3Dwmesg@entry= =3D0xffffffff8113878f "tmpfs", pri=3D, pri@entry=3D64, timo= =3Dtimo@entry=3D6, queue=3D1) at /usr/src/sys/kern/kern_lock=2Ec:310 > #5 0xffffffff80b1fd9f in lockmgr_slock_hard (lk=3D0xfffff80b139e4770= , flags=3D2122752, ilk=3D, file=3D0xffffffff81296919 "/usr/s= rc/sys/kern/vfs_lookup=2Ec", line=3D1012, lwa=3D0x0) at /usr/src/sys/kern/k= ern_lock=2Ec:705 > #6 0xffffffff80c5e444 in VOP_LOCK1 (vp=3D0xfffff80b139e4700, flags= =3D2106368, file=3D0xffffffff81296919 "/usr/src/sys/kern/vfs_lookup=2Ec", l= ine=3D1012) at =2E/vnode_if=2Eh:1120 > #7 _vn_lock (vp=3D0xfffff80b139e4700, flags=3D2106368, file=3D, line=3D) at /usr/src/sys/kern/vfs_vnops=2Ec:1808 > #8 0xffffffff80c36eae in vfs_lookup (ndp=3Dndp@entry=3D0xfffffe03c63= a6bd8) at /usr/src/sys/kern/vfs_lookup=2Ec:1010 > #9 0xffffffff80c36291 in namei (ndp=3Dndp@entry=3D0xfffffe03c63a6bd8= ) at /usr/src/sys/kern/vfs_lookup=2Ec:689 > #10 0xffffffff80c5681f in kern_statat (td=3D0xfffffe03567a01e0, td@en= try=3D, flag=3D, fd=3D-100, path=3D0x1032a8685a= 15 , pathseg=3Dpaths= eg@entry=3DUIO_USERSPACE, sbp=3Dsbp@entry=3D0xfffffe03c63a6d18) > at /usr/src/sys/kern/vfs_syscalls=2Ec:2441 > #11 0xffffffff80c56f17 in sys_fstatat (td=3D, td@entry= =3D, uap=3D0xfffffe03567a05= e0, uap@entry=3D) at /usr/s= rc/sys/kern/vfs_syscalls=2Ec:2419 > #12 0xffffffff8104d8e0 in syscallenter (td=3D) at /usr= /src/sys/amd64/amd64/=2E=2E/=2E=2E/kern/subr_syscall=2Ec:190 > #13 amd64_syscall (td=3D0xfffffe03567a01e0, traced=3D0) at /usr/src/s= ys/amd64/amd64/trap=2Ec:1199 > #14 > #15 0x0000103acaf3b03a in ?? () > Backtrace stopped: Cannot access memory at address 0x103ac929af28 > (kgdb) f 5 > #5 0xffffffff80b1fd9f in lockmgr_slock_hard (lk=3D0xfffff80b139e4770= , flags=3D2122752, ilk=3D, file=3D0xffffffff81296919 "/usr/s= rc/sys/kern/vfs_lookup=2Ec", line=3D1012, lwa=3D0x0) at /usr/src/sys/kern/k= ern_lock=2Ec:705 > 705 error =3D sleeplk(lk, flags, ilk, iwmesg, ipri, itimo, > (kgdb) p (struct thread *)(lk->lk_lock & ~0x1f) > $1 =3D (struct thread *) 0xfffffe02ddae0e40 > (kgdb) tid 0xfffffe02ddae0e40 > (kgdb) bt > #0 sched_switch (td=3Dtd@entry=3D0xfffffe02ddae0e40, flags=3Dflags@e= ntry=3D259) at /usr/src/sys/kern/sched_ule=2Ec:2299 > #1 0xffffffff80b5fbd4 in mi_switch (flags=3Dflags@entry=3D259) at /u= sr/src/sys/kern/kern_synch=2Ec:550 > #2 0xffffffff80bb1257 in sleepq_switch (wchan=3Dwchan@entry=3D0xffff= f81ab3c81154, pri=3D87, pri@entry=3D-1278734048) at /usr/src/sys/kern/subr_= sleepqueue=2Ec:609 > #3 0xffffffff80bb112e in sleepq_wait (wchan=3D, pri=3D<= unavailable>) at /usr/src/sys/kern/subr_sleepqueue=2Ec:660 > #4 0xffffffff80b5f11d in _sleep (ident=3D0xfffff81ab3c81154, lock=3D= 0xfffff81ab3c81120, priority=3D87, wmesg=3D0xffffffff82239fba "zfs teardown= inactive", sbt=3D0, pr=3D0, flags=3D256) at /usr/src/sys/kern/kern_synch= =2Ec:225 > #5 0xffffffff80b4b640 in rms_rlock_fallback (rms=3Drms@entry=3D0xfff= ff81ab3c81120) at /usr/src/sys/kern/kern_rmlock=2Ec:1015 > #6 0xffffffff80b4b51c in rms_rlock (rms=3D, rms@entry= =3D0xfffff81ab3c81120) at /usr/src/sys/kern/kern_rmlock=2Ec:1036 > #7 0xffffffff81faff5c in zfs_freebsd_reclaim (ap=3D) = at /usr/src/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vnops_os=2Ec:5164 > #8 0xffffffff811215e4 in VOP_RECLAIM_APV (vop=3D0xffffffff822e61a0 <= zfs_vnodeops>, a=3Da@entry=3D0xfffffe02fb2118a0) at vnode_if=2Ec:2180 > #9 0xffffffff80c47d54 in VOP_RECLAIM (vp=3D0xfffff80912340000) at = =2E/vnode_if=2Eh:1084 > #10 vgonel (vp=3Dvp@entry=3D0xfffff80912340000) at /usr/src/sys/kern/= vfs_subr=2Ec:4143 > #11 0xffffffff80c436f2 in vtryrecycle (vp=3D0xfffff80912340000) at /u= sr/src/sys/kern/vfs_subr=2Ec:1693 > #12 vnlru_free_impl (count=3Dcount@entry=3D1, mnt_op=3Dmnt_op@entry= =3D0x0, mvp=3D0xfffff8010945da00) at /usr/src/sys/kern/vfs_subr=2Ec:1344 > #13 0xffffffff80c4dd83 in vnlru_free_locked (count=3D1) at /usr/src/s= ys/kern/vfs_subr=2Ec:1357 > #14 vn_alloc_hard (mp=3Dmp@entry=3D0xfffffe0314140000) at /usr/src/sy= s/kern/vfs_subr=2Ec:1744 > #15 0xffffffff80c43db1 in vn_alloc (mp=3D0xfffffe0314140000) at /usr/= src/sys/amd64/include/atomic=2Eh:375 > #16 getnewvnode (tag=3D0xffffffff8113878f "tmpfs", mp=3D0xfffffe03141= 40000, vops=3D0xffffffff816b7a70 , vpp=3Dvpp@entry= =3D0xfffffe02fb211a30) at /usr/src/sys/kern/vfs_subr=2Ec:1810 > #17 0xffffffff80a7b27c in tmpfs_alloc_vp (mp=3D0xfffffe0314140000, no= de=3Dnode@entry=3D0xfffff81924deabc8, lkflag=3Dlkflag@entry=3D524288, vpp= =3D0xfffffe02fb211cf0) at /usr/src/sys/fs/tmpfs/tmpfs_subr=2Ec:1027 > #18 0xffffffff80a7b985 in tmpfs_alloc_file (dvp=3Ddvp@entry=3D0xfffff= 80b139e4700, vpp=3D, vpp@entry=3D0xfffffe02fb211cf0, vap=3D, cnp=3Dcnp@entry=3D0xfffffe02fb211d18, target=3Dtarget@entry= =3D0x0) at /usr/src/sys/fs/tmpfs/tmpfs_subr=2Ec:1203 > #19 0xffffffff80a74d28 in tmpfs_create (v=3D) at /usr/= src/sys/fs/tmpfs/tmpfs_vnops=2Ec:271 > #20 0xffffffff8111eb99 in VOP_CREATE_APV (vop=3D0xffffffff816b7a70 , a=3Da@entry=3D0xfffffe02fb211be0) at vnode_if=2Ec:24= 4 > #21 0xffffffff80c5d94c in VOP_CREATE (dvp=3D, vpp=3D0xff= fffe02fb211cf0, cnp=3D0xfffffe02fb211d18, vap=3D0xfffffe02fb211b20) at =2E/= vnode_if=2Eh:133 > #22 vn_open_cred (ndp=3Dndp@entry=3D0xfffffe02fb211c98, flagp=3Dflagp= @entry=3D0xfffffe02fb211da4, cmode=3Dcmode@entry=3D420, vn_open_flags=3Dvn_= open_flags@entry=3D16, cred=3D0xfffff8010978bc00, fp=3D0xfffff804f42cff00) = at /usr/src/sys/kern/vfs_vnops=2Ec:287 > #23 0xffffffff80c53f43 in kern_openat (td=3D0xfffffe02ddae0e40, td@en= try=3D, fd=3Dfd@entry=3D-100, path=3D0x8222f799b , pathseg=3Dpathseg@entry=3DUIO_USER= SPACE, flags=3D1538, mode=3D) > at /usr/src/sys/kern/vfs_syscalls=2Ec:1167 > #24 0xffffffff80c53cad in sys_open (td=3Dtd@entry=3D, ua= p=3Duap@entry=3D) at /usr/src/sys/kern/vfs_syscalls=2Ec:1095 > #25 0xffffffff82b18365 in filemon_wrapper_open (td=3D, t= d@entry=3D, uap=3D, uap@entry=3D) at /usr= /src/sys/dev/filemon/filemon_wrapper=2Ec:220 > #26 0xffffffff8104d8e0 in syscallenter (td=3D) at /usr= /src/sys/amd64/amd64/=2E=2E/=2E=2E/kern/subr_syscall=2Ec:190 > #27 amd64_syscall (td=3D0xfffffe02ddae0e40, traced=3D0) at /usr/src/s= ys/amd64/amd64/trap=2Ec:1199 > #28 > #29 0x0000000829c8227a in ?? () > Backtrace stopped: Cannot access memory at address 0x8222f6868 > (kgdb) f 7 > #7 0xffffffff81faff5c in zfs_freebsd_reclaim (ap=3D) = at /usr/src/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vnops_os=2Ec:5164 > 5164 ZFS_TEARDOWN_INACTIVE_ENTER_READ(zfsvfs); > (kgdb) p zp->z_zfsvfs->z_teardown_inactive_lock->owner > $2 =3D (struct thread *) 0xfffffe0314249020 > (kgdb) tid 0xfffffe0314249020 > (kgdb) bt > #0 sched_switch (td=3Dtd@entry=3D0xfffffe0314249020, flags=3Dflags@e= ntry=3D259) at /usr/src/sys/kern/sched_ule=2Ec:2299 > #1 0xffffffff80b5fbd4 in mi_switch (flags=3Dflags@entry=3D259) at /u= sr/src/sys/kern/kern_synch=2Ec:550 > #2 0xffffffff80bb1257 in sleepq_switch (wchan=3Dwchan@entry=3D0xffff= f80108fe1540, pri=3D0, pri@entry=3D150869200) at /usr/src/sys/kern/subr_sle= epqueue=2Ec:609 > #3 0xffffffff80bb112e in sleepq_wait (wchan=3D, wchan@e= ntry=3D0xfffff80108fe1540, pri=3D, pri@entry=3D0) at /usr/src/= sys/kern/subr_sleepqueue=2Ec:660 > #4 0xffffffff80ade224 in _cv_wait (cvp=3D0xfffff80108fe1540, lock=3D= 0xfffff80108fe14d0) at /usr/src/sys/kern/kern_condvar=2Ec:146 > #5 0xffffffff820b383b in txg_wait_synced_impl (dp=3D0xfffff80108fe10= 00, txg=3D8751529, txg@entry=3D0, wait_sig=3Dwait_sig@entry=3D0) at /usr/sr= c/sys/contrib/openzfs/module/zfs/txg=2Ec:726 > #6 0xffffffff820b31eb in txg_wait_synced (dp=3D, txg=3D= , txg@entry=3D0) at /usr/src/sys/contrib/openzfs/module/zfs/tx= g=2Ec:736 > #7 0xffffffff81fa5fc5 in zfsvfs_teardown (zfsvfs=3D0xfffff81ab3c8100= 0, unmounting=3Dunmounting@entry=3D0) at /usr/src/sys/contrib/openzfs/modul= e/os/freebsd/zfs/zfs_vfsops=2Ec:1661 > #8 0xffffffff81fa5db9 in zfs_suspend_fs (zfsvfs=3D) at = /usr/src/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vfsops=2Ec:1954 > #9 0xffffffff821680ff in zfs_ioc_rollback (fsname=3D0xfffffe03019130= 00 "zroot-default-ref/03", fsname@entry=3D, innvl=3D, innvl@entry=3D,=20 > outnvl=3D0xfffff81601748640, outnvl@entry=3D) at /usr/src/sys/contrib/openzfs/module/zfs/zfs= _ioctl=2Ec:4401 > #10 0xffffffff82163836 in zfsdev_ioctl_common (vecnum=3Dvecnum@entry= =3D25, zc=3Dzc@entry=3D0xfffffe0301913000, flag=3Dflag@entry=3D0) at /usr/s= rc/sys/contrib/openzfs/module/zfs/zfs_ioctl=2Ec:7798 > #11 0xffffffff81f969aa in zfsdev_ioctl (dev=3D, zcmd= =3D, zcmd@entry=3D, arg=3D0xfffffe02fd546d50 "\017", arg@entry=3D, flag=3D, td=3D) > at /usr/src/sys/contrib/openzfs/module/os/freebsd/zfs/kmod_core= =2Ec:168 > #12 0xffffffff809dc9cc in devfs_ioctl (ap=3D0xfffffe02fd546c40) at /u= sr/src/sys/fs/devfs/devfs_vnops=2Ec:935 > #13 0xffffffff80c5cac0 in vn_ioctl (fp=3D0xfffff81e9207f0a0, com=3D, data=3D0xfffffe02fd546d50, active_cred=3D0xfffff8026a65a900,= td=3D) at /usr/src/sys/kern/vfs_vnops=2Ec:1697 > #14 0xffffffff809dd07e in devfs_ioctl_f (fp=3D, fp@entry= =3D, com=3D, c= om@entry=3D, data=3D, data@entry=3D,=20 > cred=3D, cred@entry=3D, td=3D, td@entry=3D) at /usr/src/sys/fs/devfs/devfs_vnops=2Ec:866 > #15 0xffffffff80bca1ce in fo_ioctl (fp=3D0xfffff81e9207f0a0, com=3D32= 22821401, data=3D, active_cred=3D, td=3D) at /usr/src/sys/sys/file=2Eh:367 > #16 kern_ioctl (td=3Dtd@entry=3D0xfffffe0314249020, fd=3D, com=3Dcom@entry=3D3222821401, data=3D, data@entry=3D0xfff= ffe02fd546d50 "\017") at /usr/src/sys/kern/sys_generic=2Ec:807 > #17 0xffffffff80bc9f64 in sys_ioctl (td=3D0xfffffe0314249020, td@entr= y=3D, uap=3D0xfffffe0314249= 420, uap@entry=3D) at /usr/= src/sys/kern/sys_generic=2Ec:715 > #18 0xffffffff8104d8e0 in syscallenter (td=3D) at /usr= /src/sys/amd64/amd64/=2E=2E/=2E=2E/kern/subr_syscall=2Ec:190 > #19 amd64_syscall (td=3D0xfffffe0314249020, traced=3D0) at /usr/src/s= ys/amd64/amd64/trap=2Ec:1199 > #20 > #21 0x000005c8e125953a in ?? () > Backtrace stopped: Cannot access memory at address 0x5c8d89c8018 > >DES Yes, this is the same panic my poudriere builder building amd64 packages g= ets=2E The poudeiere builder, also running on amd64, building i386 packages= gets a different panic=2E I'm on my phone and don't have a keyboard to loo= k up the PR number=2E --=20 Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD=2Eorg NTP: Web: https://nwtime=2Eorg e^(i*pi)+1=3D0 Pardon the typos=2E Small keyboard in use=2E From nobody Sat Aug 12 17:08:53 2023 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 4RNRx62Cfgz4qJ6W; Sat, 12 Aug 2023 17:10:02 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta002.cacentral1.a.cloudfilter.net (omta002.cacentral1.a.cloudfilter.net [3.97.99.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RNRx55qG2z3Rgt; Sat, 12 Aug 2023 17:10:01 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; none Received: from shw-obgw-4004a.ext.cloudfilter.net ([10.228.9.227]) by cmsmtp with ESMTP id UqZGqvEXh6NwhUs7kqMxpt; Sat, 12 Aug 2023 17:10:00 +0000 Received: from spqr.komquats.com ([70.66.152.170]) by cmsmtp with ESMTPA id Us7jqt6yE3fOSUs7kqtY71; Sat, 12 Aug 2023 17:10:00 +0000 X-Authority-Analysis: v=2.4 cv=J8G5USrS c=1 sm=1 tr=0 ts=64d7bce8 a=y8EK/9tc/U6QY+pUhnbtgQ==:117 a=y8EK/9tc/U6QY+pUhnbtgQ==:17 a=IkcTkHD0fZMA:10 a=UttIx32zK-AA:10 a=6I5d2MoRAAAA:8 a=YxBL1-UpAAAA:8 a=EkcXrb_YAAAA:8 a=fQWtEyl-p239-_sfO9UA:9 a=QEXdDO2ut3YA:10 a=IjZwj45LgO3ly-622nXo:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from [127.0.0.1] (unknown [192.168.0.252]) by spqr.komquats.com (Postfix) with ESMTPSA id CED0028A; Sat, 12 Aug 2023 10:09:58 -0700 (PDT) Date: Sat, 12 Aug 2023 10:08:53 -0700 From: Cy Schubert To: freebsd-current@freebsd.org, =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , current@freebsd.org Subject: Re: ZFS deadlock in 14 In-Reply-To: <86h6p4s64h.fsf@ltc.des.no> References: <86leeltqcb.fsf@ltc.des.no> <86h6p4s64h.fsf@ltc.des.no> Message-ID: <6CB02436-1FD6-43C9-BB77-925A7443D8B8@cschubert.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: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-CMAE-Envelope: MS4xfDSFH7e2T/w2PdR38WcHI70vOq/a1OVQx1XMUW4ePbOWSbG9iMlbfaB6TnZo613w39zMGbYW3r2u8xkLFzfQq7XVS9CQdonS/aIIg/+Z8V78X226iA+6 YX2cULl3BzzOKpQMG3kgqt7+UxRu1ou/bCxllPG6AIU346Tyqgjzmjb4O6PaQLcHaqBhapgzpWtoQOutxUhekzaOOrQxtGqUu/84kVOB5axN+D5jSvAzVtPu J0nJKZ12b3nckG6HNf4uZzgrGl96+8I104Tp2pO6GtY= X-Rspamd-Queue-Id: 4RNRx55qG2z3Rgt X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US] On August 12, 2023 7:11:10 AM PDT, "Dag-Erling Sm=C3=B8rgrav" wrote: >Dag-Erling Sm=C3=B8rgrav writes: >> At some point between 42d088299c (4 May) and f0c9703301 (26 June), a >> deadlock was introduced in ZFS=2E > >Trying to narrow this range down, I did not get a deadlock with >4e8d558c9d1c (10 June) but I did with b7198dcfc039 (16 June), albeit >after building ~1800 packages=2E This is surprising since we have a >report of this or a very similar deadlock occurring with a kernel from 8 >June (https://bugs=2Efreebsd=2Eorg/271945)=2E Perhaps I should try >4e8d558c9d1c again=2E > >Here's the complete kgdb session showing, once again, a zfs rollback >stuck waiting for the txg to sync: > > Reading symbols from /boot/GENERIC/kernel=2E=2E=2E > Reading symbols from /usr/lib/debug//boot/GENERIC/kernel=2Edebug=2E= =2E=2E > =20 > Unread portion of the kernel message buffer: > panic: deadlres_td_sleep_q: possible deadlock detected for 0xfffffe03= 567a01e0 (sh), blocked for 180242 ticks > =20 > cpuid =3D 17 > time =3D 1691802362 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0= 21507ce00 > vpanic() at vpanic+0x150/frame 0xfffffe021507ce50 > panic() at panic+0x43/frame 0xfffffe021507ceb0 > deadlkres() at deadlkres+0x350/frame 0xfffffe021507cef0 > fork_exit() at fork_exit+0x80/frame 0xfffffe021507cf30 > fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe021507cf30 > --- trap 0xdeadc0de, rip =3D 0xdeadc0dedeadc0de, rsp =3D 0xdeadc0dede= adc0de, rbp =3D 0xdeadc0dedeadc0de --- > KDB: enter: panic > =20 > __curthread () at /usr/src/sys/amd64/include/pcpu_aux=2Eh:59 > 59 __asm("movq %%gs:%P1,%0" : "=3Dr" (td) : "n" (offsetof(struct pcp= u, > (kgdb) tid 0xfffffe03567a01e0 > (kgdb) bt > #0 sched_switch (td=3Dtd@entry=3D0xfffffe03567a01e0, flags=3Dflags@e= ntry=3D259) at /usr/src/sys/kern/sched_ule=2Ec:2299 > #1 0xffffffff80b5fbd4 in mi_switch (flags=3Dflags@entry=3D259) at /u= sr/src/sys/kern/kern_synch=2Ec:550 > #2 0xffffffff80bb1257 in sleepq_switch (wchan=3D0xfffff80b139e4770, = wchan@entry=3D0xffffffff8113878f, pri=3Dpri@entry=3D64) at /usr/src/sys/ker= n/subr_sleepqueue=2Ec:609 > #3 0xffffffff80bb112e in sleepq_wait (wchan=3D, pri=3D<= unavailable>) at /usr/src/sys/kern/subr_sleepqueue=2Ec:660 > #4 0xffffffff80b21d6f in sleeplk (lk=3Dlk@entry=3D0xfffff80b139e4770= , flags=3Dflags@entry=3D2122752, ilk=3Dilk@entry=3D0x0, wmesg=3Dwmesg@entry= =3D0xffffffff8113878f "tmpfs", pri=3D, pri@entry=3D64, timo= =3Dtimo@entry=3D6, queue=3D1) at /usr/src/sys/kern/kern_lock=2Ec:310 > #5 0xffffffff80b1fd9f in lockmgr_slock_hard (lk=3D0xfffff80b139e4770= , flags=3D2122752, ilk=3D, file=3D0xffffffff81296919 "/usr/s= rc/sys/kern/vfs_lookup=2Ec", line=3D1012, lwa=3D0x0) at /usr/src/sys/kern/k= ern_lock=2Ec:705 > #6 0xffffffff80c5e444 in VOP_LOCK1 (vp=3D0xfffff80b139e4700, flags= =3D2106368, file=3D0xffffffff81296919 "/usr/src/sys/kern/vfs_lookup=2Ec", l= ine=3D1012) at =2E/vnode_if=2Eh:1120 > #7 _vn_lock (vp=3D0xfffff80b139e4700, flags=3D2106368, file=3D, line=3D) at /usr/src/sys/kern/vfs_vnops=2Ec:1808 > #8 0xffffffff80c36eae in vfs_lookup (ndp=3Dndp@entry=3D0xfffffe03c63= a6bd8) at /usr/src/sys/kern/vfs_lookup=2Ec:1010 > #9 0xffffffff80c36291 in namei (ndp=3Dndp@entry=3D0xfffffe03c63a6bd8= ) at /usr/src/sys/kern/vfs_lookup=2Ec:689 > #10 0xffffffff80c5681f in kern_statat (td=3D0xfffffe03567a01e0, td@en= try=3D, flag=3D, fd=3D-100, path=3D0x1032a8685a= 15 , pathseg=3Dpaths= eg@entry=3DUIO_USERSPACE, sbp=3Dsbp@entry=3D0xfffffe03c63a6d18) > at /usr/src/sys/kern/vfs_syscalls=2Ec:2441 > #11 0xffffffff80c56f17 in sys_fstatat (td=3D, td@entry= =3D, uap=3D0xfffffe03567a05= e0, uap@entry=3D) at /usr/s= rc/sys/kern/vfs_syscalls=2Ec:2419 > #12 0xffffffff8104d8e0 in syscallenter (td=3D) at /usr= /src/sys/amd64/amd64/=2E=2E/=2E=2E/kern/subr_syscall=2Ec:190 > #13 amd64_syscall (td=3D0xfffffe03567a01e0, traced=3D0) at /usr/src/s= ys/amd64/amd64/trap=2Ec:1199 > #14 > #15 0x0000103acaf3b03a in ?? () > Backtrace stopped: Cannot access memory at address 0x103ac929af28 > (kgdb) f 5 > #5 0xffffffff80b1fd9f in lockmgr_slock_hard (lk=3D0xfffff80b139e4770= , flags=3D2122752, ilk=3D, file=3D0xffffffff81296919 "/usr/s= rc/sys/kern/vfs_lookup=2Ec", line=3D1012, lwa=3D0x0) at /usr/src/sys/kern/k= ern_lock=2Ec:705 > 705 error =3D sleeplk(lk, flags, ilk, iwmesg, ipri, itimo, > (kgdb) p (struct thread *)(lk->lk_lock & ~0x1f) > $1 =3D (struct thread *) 0xfffffe02ddae0e40 > (kgdb) tid 0xfffffe02ddae0e40 > (kgdb) bt > #0 sched_switch (td=3Dtd@entry=3D0xfffffe02ddae0e40, flags=3Dflags@e= ntry=3D259) at /usr/src/sys/kern/sched_ule=2Ec:2299 > #1 0xffffffff80b5fbd4 in mi_switch (flags=3Dflags@entry=3D259) at /u= sr/src/sys/kern/kern_synch=2Ec:550 > #2 0xffffffff80bb1257 in sleepq_switch (wchan=3Dwchan@entry=3D0xffff= f81ab3c81154, pri=3D87, pri@entry=3D-1278734048) at /usr/src/sys/kern/subr_= sleepqueue=2Ec:609 > #3 0xffffffff80bb112e in sleepq_wait (wchan=3D, pri=3D<= unavailable>) at /usr/src/sys/kern/subr_sleepqueue=2Ec:660 > #4 0xffffffff80b5f11d in _sleep (ident=3D0xfffff81ab3c81154, lock=3D= 0xfffff81ab3c81120, priority=3D87, wmesg=3D0xffffffff82239fba "zfs teardown= inactive", sbt=3D0, pr=3D0, flags=3D256) at /usr/src/sys/kern/kern_synch= =2Ec:225 > #5 0xffffffff80b4b640 in rms_rlock_fallback (rms=3Drms@entry=3D0xfff= ff81ab3c81120) at /usr/src/sys/kern/kern_rmlock=2Ec:1015 > #6 0xffffffff80b4b51c in rms_rlock (rms=3D, rms@entry= =3D0xfffff81ab3c81120) at /usr/src/sys/kern/kern_rmlock=2Ec:1036 > #7 0xffffffff81faff5c in zfs_freebsd_reclaim (ap=3D) = at /usr/src/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vnops_os=2Ec:5164 > #8 0xffffffff811215e4 in VOP_RECLAIM_APV (vop=3D0xffffffff822e61a0 <= zfs_vnodeops>, a=3Da@entry=3D0xfffffe02fb2118a0) at vnode_if=2Ec:2180 > #9 0xffffffff80c47d54 in VOP_RECLAIM (vp=3D0xfffff80912340000) at = =2E/vnode_if=2Eh:1084 > #10 vgonel (vp=3Dvp@entry=3D0xfffff80912340000) at /usr/src/sys/kern/= vfs_subr=2Ec:4143 > #11 0xffffffff80c436f2 in vtryrecycle (vp=3D0xfffff80912340000) at /u= sr/src/sys/kern/vfs_subr=2Ec:1693 > #12 vnlru_free_impl (count=3Dcount@entry=3D1, mnt_op=3Dmnt_op@entry= =3D0x0, mvp=3D0xfffff8010945da00) at /usr/src/sys/kern/vfs_subr=2Ec:1344 > #13 0xffffffff80c4dd83 in vnlru_free_locked (count=3D1) at /usr/src/s= ys/kern/vfs_subr=2Ec:1357 > #14 vn_alloc_hard (mp=3Dmp@entry=3D0xfffffe0314140000) at /usr/src/sy= s/kern/vfs_subr=2Ec:1744 > #15 0xffffffff80c43db1 in vn_alloc (mp=3D0xfffffe0314140000) at /usr/= src/sys/amd64/include/atomic=2Eh:375 > #16 getnewvnode (tag=3D0xffffffff8113878f "tmpfs", mp=3D0xfffffe03141= 40000, vops=3D0xffffffff816b7a70 , vpp=3Dvpp@entry= =3D0xfffffe02fb211a30) at /usr/src/sys/kern/vfs_subr=2Ec:1810 > #17 0xffffffff80a7b27c in tmpfs_alloc_vp (mp=3D0xfffffe0314140000, no= de=3Dnode@entry=3D0xfffff81924deabc8, lkflag=3Dlkflag@entry=3D524288, vpp= =3D0xfffffe02fb211cf0) at /usr/src/sys/fs/tmpfs/tmpfs_subr=2Ec:1027 > #18 0xffffffff80a7b985 in tmpfs_alloc_file (dvp=3Ddvp@entry=3D0xfffff= 80b139e4700, vpp=3D, vpp@entry=3D0xfffffe02fb211cf0, vap=3D, cnp=3Dcnp@entry=3D0xfffffe02fb211d18, target=3Dtarget@entry= =3D0x0) at /usr/src/sys/fs/tmpfs/tmpfs_subr=2Ec:1203 > #19 0xffffffff80a74d28 in tmpfs_create (v=3D) at /usr/= src/sys/fs/tmpfs/tmpfs_vnops=2Ec:271 > #20 0xffffffff8111eb99 in VOP_CREATE_APV (vop=3D0xffffffff816b7a70 , a=3Da@entry=3D0xfffffe02fb211be0) at vnode_if=2Ec:24= 4 > #21 0xffffffff80c5d94c in VOP_CREATE (dvp=3D, vpp=3D0xff= fffe02fb211cf0, cnp=3D0xfffffe02fb211d18, vap=3D0xfffffe02fb211b20) at =2E/= vnode_if=2Eh:133 > #22 vn_open_cred (ndp=3Dndp@entry=3D0xfffffe02fb211c98, flagp=3Dflagp= @entry=3D0xfffffe02fb211da4, cmode=3Dcmode@entry=3D420, vn_open_flags=3Dvn_= open_flags@entry=3D16, cred=3D0xfffff8010978bc00, fp=3D0xfffff804f42cff00) = at /usr/src/sys/kern/vfs_vnops=2Ec:287 > #23 0xffffffff80c53f43 in kern_openat (td=3D0xfffffe02ddae0e40, td@en= try=3D, fd=3Dfd@entry=3D-100, path=3D0x8222f799b , pathseg=3Dpathseg@entry=3DUIO_USER= SPACE, flags=3D1538, mode=3D) > at /usr/src/sys/kern/vfs_syscalls=2Ec:1167 > #24 0xffffffff80c53cad in sys_open (td=3Dtd@entry=3D, ua= p=3Duap@entry=3D) at /usr/src/sys/kern/vfs_syscalls=2Ec:1095 > #25 0xffffffff82b18365 in filemon_wrapper_open (td=3D, t= d@entry=3D, uap=3D, uap@entry=3D) at /usr= /src/sys/dev/filemon/filemon_wrapper=2Ec:220 > #26 0xffffffff8104d8e0 in syscallenter (td=3D) at /usr= /src/sys/amd64/amd64/=2E=2E/=2E=2E/kern/subr_syscall=2Ec:190 > #27 amd64_syscall (td=3D0xfffffe02ddae0e40, traced=3D0) at /usr/src/s= ys/amd64/amd64/trap=2Ec:1199 > #28 > #29 0x0000000829c8227a in ?? () > Backtrace stopped: Cannot access memory at address 0x8222f6868 > (kgdb) f 7 > #7 0xffffffff81faff5c in zfs_freebsd_reclaim (ap=3D) = at /usr/src/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vnops_os=2Ec:5164 > 5164 ZFS_TEARDOWN_INACTIVE_ENTER_READ(zfsvfs); > (kgdb) p zp->z_zfsvfs->z_teardown_inactive_lock->owner > $2 =3D (struct thread *) 0xfffffe0314249020 > (kgdb) tid 0xfffffe0314249020 > (kgdb) bt > #0 sched_switch (td=3Dtd@entry=3D0xfffffe0314249020, flags=3Dflags@e= ntry=3D259) at /usr/src/sys/kern/sched_ule=2Ec:2299 > #1 0xffffffff80b5fbd4 in mi_switch (flags=3Dflags@entry=3D259) at /u= sr/src/sys/kern/kern_synch=2Ec:550 > #2 0xffffffff80bb1257 in sleepq_switch (wchan=3Dwchan@entry=3D0xffff= f80108fe1540, pri=3D0, pri@entry=3D150869200) at /usr/src/sys/kern/subr_sle= epqueue=2Ec:609 > #3 0xffffffff80bb112e in sleepq_wait (wchan=3D, wchan@e= ntry=3D0xfffff80108fe1540, pri=3D, pri@entry=3D0) at /usr/src/= sys/kern/subr_sleepqueue=2Ec:660 > #4 0xffffffff80ade224 in _cv_wait (cvp=3D0xfffff80108fe1540, lock=3D= 0xfffff80108fe14d0) at /usr/src/sys/kern/kern_condvar=2Ec:146 > #5 0xffffffff820b383b in txg_wait_synced_impl (dp=3D0xfffff80108fe10= 00, txg=3D8751529, txg@entry=3D0, wait_sig=3Dwait_sig@entry=3D0) at /usr/sr= c/sys/contrib/openzfs/module/zfs/txg=2Ec:726 > #6 0xffffffff820b31eb in txg_wait_synced (dp=3D, txg=3D= , txg@entry=3D0) at /usr/src/sys/contrib/openzfs/module/zfs/tx= g=2Ec:736 > #7 0xffffffff81fa5fc5 in zfsvfs_teardown (zfsvfs=3D0xfffff81ab3c8100= 0, unmounting=3Dunmounting@entry=3D0) at /usr/src/sys/contrib/openzfs/modul= e/os/freebsd/zfs/zfs_vfsops=2Ec:1661 > #8 0xffffffff81fa5db9 in zfs_suspend_fs (zfsvfs=3D) at = /usr/src/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vfsops=2Ec:1954 > #9 0xffffffff821680ff in zfs_ioc_rollback (fsname=3D0xfffffe03019130= 00 "zroot-default-ref/03", fsname@entry=3D, innvl=3D, innvl@entry=3D,=20 > outnvl=3D0xfffff81601748640, outnvl@entry=3D) at /usr/src/sys/contrib/openzfs/module/zfs/zfs= _ioctl=2Ec:4401 > #10 0xffffffff82163836 in zfsdev_ioctl_common (vecnum=3Dvecnum@entry= =3D25, zc=3Dzc@entry=3D0xfffffe0301913000, flag=3Dflag@entry=3D0) at /usr/s= rc/sys/contrib/openzfs/module/zfs/zfs_ioctl=2Ec:7798 > #11 0xffffffff81f969aa in zfsdev_ioctl (dev=3D, zcmd= =3D, zcmd@entry=3D, arg=3D0xfffffe02fd546d50 "\017", arg@entry=3D, flag=3D, td=3D) > at /usr/src/sys/contrib/openzfs/module/os/freebsd/zfs/kmod_core= =2Ec:168 > #12 0xffffffff809dc9cc in devfs_ioctl (ap=3D0xfffffe02fd546c40) at /u= sr/src/sys/fs/devfs/devfs_vnops=2Ec:935 > #13 0xffffffff80c5cac0 in vn_ioctl (fp=3D0xfffff81e9207f0a0, com=3D, data=3D0xfffffe02fd546d50, active_cred=3D0xfffff8026a65a900,= td=3D) at /usr/src/sys/kern/vfs_vnops=2Ec:1697 > #14 0xffffffff809dd07e in devfs_ioctl_f (fp=3D, fp@entry= =3D, com=3D, c= om@entry=3D, data=3D, data@entry=3D,=20 > cred=3D, cred@entry=3D, td=3D, td@entry=3D) at /usr/src/sys/fs/devfs/devfs_vnops=2Ec:866 > #15 0xffffffff80bca1ce in fo_ioctl (fp=3D0xfffff81e9207f0a0, com=3D32= 22821401, data=3D, active_cred=3D, td=3D) at /usr/src/sys/sys/file=2Eh:367 > #16 kern_ioctl (td=3Dtd@entry=3D0xfffffe0314249020, fd=3D, com=3Dcom@entry=3D3222821401, data=3D, data@entry=3D0xfff= ffe02fd546d50 "\017") at /usr/src/sys/kern/sys_generic=2Ec:807 > #17 0xffffffff80bc9f64 in sys_ioctl (td=3D0xfffffe0314249020, td@entr= y=3D, uap=3D0xfffffe0314249= 420, uap@entry=3D) at /usr/= src/sys/kern/sys_generic=2Ec:715 > #18 0xffffffff8104d8e0 in syscallenter (td=3D) at /usr= /src/sys/amd64/amd64/=2E=2E/=2E=2E/kern/subr_syscall=2Ec:190 > #19 amd64_syscall (td=3D0xfffffe0314249020, traced=3D0) at /usr/src/s= ys/amd64/amd64/trap=2Ec:1199 > #20 > #21 0x000005c8e125953a in ?? () > Backtrace stopped: Cannot access memory at address 0x5c8d89c8018 > >DES Yes, this is the same panic my poudriere builder building amd64 packages g= ets=2E The poudeiere builder, also running on amd64, building i386 packages= gets a different panic=2E I'm on my phone and don't have a keyboard to loo= k up the PR number=2E --=20 Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD=2Eorg NTP: Web: https://nwtime=2Eorg e^(i*pi)+1=3D0 Pardon the typos=2E Small keyboard in use=2E From nobody Sat Aug 12 17:21:24 2023 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 4RNSBY6b1fz4qJlk for ; Sat, 12 Aug 2023 17:21:41 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-54.consmr.mail.gq1.yahoo.com (sonic316-54.consmr.mail.gq1.yahoo.com [98.137.69.30]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 4RNSBX4fn7z3VgB for ; Sat, 12 Aug 2023 17:21:40 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=Mlx5suIO; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.30 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1691860897; bh=DaUNhq15fBQu/anWFfJH7MUY/g5mVVi7QxJpp0AxxZ4=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=Mlx5suIOZqHQrhH7a+Mq3f2eBMDnIwmwzFiIHBUK9R1oqQ4U1KvVtvzNY5HPSJdm+6cR3X6jhtnwgUUTBWwiHIo8BFVi5qtOE1YDmPZ0wlq67BbsGQjyl5TuTIcrrH7VRBzhuoHr0wvAuBcOuSfEYZ63/FebCZJiZyoaVV2CuzLk95uo6asn8SlL2bp3tXD/0ABzdxtnbDFv3a7arTl8MO0ImeGHRX8UmMEybIRzwgIs5I/scsNZDEd1C2jZe6ttAR1XKREKL2YPovSzwFDgGWmXGrm0fb2d/EllGjl0tuJYXNP616AEJviYwMu2A3yvGw1oAsybbr9xogTWnJc7yw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1691860897; bh=PNofTUcTAX3TtHpfVPJWXjkog3IzR1nFGryPjds1zNl=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=JSHl8Xy8WQEMeGFg692Rb4r4j2WQt9rKA2KpxHFSroUYV2s/6EcLprXrRdaUBLB7fc1fZYMy/3rZHs44fxvVrwJ4pWZnihuvJgNDhjVkrc4ApefQXtrCX08bZx3M2A7opRueGPNMaL8+AK66l6IiU0vw2pVdz1fAMKJ1N1TfDW8n98ndM3WcDH+gLoOZ6xnWLzFIfPOU8hTlVAhDQjy6tGeffOGxeQfcj/q1JLAorQFw7NcXXWbtOrsTVp2rGuvtTXf3OcSIBSSLuzd0SRyakWo/5683at8ViC6xfXqKVqPrSoWUyqLL7MLwrHGyavficxALNRL+xQOvf1qQu6avTA== X-YMail-OSG: falZLhwVM1lKsa2mB8z8Vtcim5aQf8F7OawArBfXRBFEjabo2wPqPdckJmsiSBC 7KwbjBSmF9m_ASAYsPrrWxUH0US4XA2yTvMmd4bBXoCLeDjJfE7Xj7AibJTiEp4U306HTOcl2lyG YelWkpaen.cB5G.eRdGftmgHyqKQ6vhgREBqolZbmsVYCaQoXBeF36TOlFuw8nEdCwRKD7hlMkLt yJ0bEjyVbfmB4rsHkpV2B.qOpeZM2_CgTe1CBJCSCS_8F4qDHR7qOFDI6XUGBkSpp0WlyQC1i0uB Wa0Qo0FlJH65fyf_ikbcgjzV.fQFfXKHiKzhOXDT.u6xEB4C3bSGLrZ2EdqvRFZSlHX1Lg2kvzhF jySYFnE06Xp0J8eBBJMi4l6LoNRi9a9hCxZCySJojcQjY6gMWTqaDCTb3qYGrPkmzxq7LbhkxCy2 Km0Dhg.vELXZdWOi4H7dsMTcG_XpvZXl.9jZdIixqd.0OAMJbUIdi15MW.Ue64jzO5iUF.b82OSg BeaVIpVjYTADRATbu3nH2uggTpLYDA3EnK8IV7gNwHwJ3S5hE7zMrs31sxulwwugYPyxMv0abzZo 8PbQuNkfuUqeELPMM7TrAj5my3e6LsNgIgyrib7nxS.YY9GB2IWwW9Owq_A4OTK0XDXQqfhZE7er 9jb1MGf0Npcg2OnqoeKljuSdyQe_H_EDmmPhaqsnzWAh6NaRWl2AgaGA6PuMXSN6InGN3u7ANPJ3 9C8eXkXRKwITkrFCHJPITNEu.UTTZwZOVquOJa_nAZXDkwNpJABE8c6lMlMlexxIPfn2PPrnekre AKcx5ro0Fy85SFHL659lGFNPumRdHgCPY9gwFijfXQnVbckjIP7AE.Eu2hsB9oR4hcVwG.B6KvNl VzD1OlZH15YCDvNK3jxrw5ojB5oIElK2F1lF0Pmidrv6AVMcaMw7U_Es2wfyfdwGneyM8pdeSGlt 7pfI3UTchA7W20Yc7UP_0Seaugpfzhsh_A54KB3XE0rC.cYS32Mb8hCdWa2tuHpe1X3DMBfL8RDi hNettQQqGm45ptLOalLFgAtbV.5691JTQvvyva7RfnmAjLyj.iHPZ6.KI7b4PsqpFy8p0gXIo0.6 DzsM38pb_0EJ3o6zsO9qKKvPPK7cBKsztR1JEYQHhBwvFUhyYrRmraBrlfcKEsrpgy6SzT6OMVkh Hyy4WzhjqSpk7P8f3wVPzEWuDhRWvyy0xqu9OTJzkKl2lpKq18QaFXj88bq4VLYWQDQKVXcoyhD6 8MPwPpATFSeTLESUr.sGswNfZl3dFVY4APMFR_q58JOfVQk_m2N6UyvN.0_Dqk4qpJjdB.cPL4ed 5OJ7JbeaX1UIPGDXz3LuRjXsBL51sKvKj_XUKuLnUAOLXPQo9R7gxY.jamX4X_wH95lf2mrK9pkL VFrF_qGVmLK0A9sSPRW_Rzol3bgBMgy0hJVVc7F0jzP_nHqEAR.JI.Ty41NiXRyVz.C3JWmWR18q 0qYf_fGxB2Ud2ebk7bPnFVTG_OC2q8T.sEVRX1fIFL0F9dl66sVl0q12O0vMpIJ9UwpBoPr2gXJo ZlbRNijzDlvqysTkGeWraoe7QPC9ct9NQ4LKFBFw.QN3Y.vbDgQuZbm_PZh2WgIJDLJsv4NoaIXE GndHxQjx52wV5ZUKbF_dFJCfrHLF_Ti1JBinECAb.5O4GvCgG5nbg0e4bBUHv5YKzBgYbemGUj5T .kVsDu3ZA3yEKCmAuUZ9CXHFHqEHgYMN4agMyNtgW6kNNEcCS1TODK0qyli4lLliHGIWHgpki40O OPNm2gH9XiaL9v57coUUmHBGK89r1txpYvdxYip1gzF5uWkviE2420ie.a9UZkSMhwZRPMj6BXIg U_U9UJD8lbwBTIxkC9343eGczjFZXCBktaV3xIMBkQch_6FaHpxsC59rseZZgpbcVaoHMotAnkRW 14Uy0Re5qcmjlS0qB.vswnwcoDwiL9wlqDq.cMeRo5P2aY_.vXJEP3RhzHVxZMyt43i9Uco9E.K6 PcCv9hqi3JwihsmGRSEpnZ1zgQv60Yhw5QWA1eEiOpXKm3rTGXBTFEmt9RHsszi9tHVRmGLts8h8 jEQZMBOCDwOYC5wwv6cVMamtXxaS2dt1K0dS5qnakBxzntm1G6Hk4xr.N2eQggEUfLFEB4829J52 YVEs4UUoGQwNDQL05p0CjNYHaS4UBNyZ5zBgFQmuy6tJCeZaKMtjovUuR_7W2ml0XAYV3pRWVkQk pmWMMtHgXGXf_uw05pIBI.vVO9UHzSCTFh1exa_xhDbcaXsnBaCiMbdQDfvU- X-Sonic-MF: X-Sonic-ID: 2e873839-2b43-478b-a2a6-843ccabaa229 Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Sat, 12 Aug 2023 17:21:37 +0000 Received: by hermes--production-gq1-6b7c87dcf5-m4lb7 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 7e97a256e5128104df56616dac66a5a3; Sat, 12 Aug 2023 17:21:34 +0000 (UTC) From: Mark Millard 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 16.0 \(3731.700.6\)) Subject: 14.0-APLHA1 snapshot use of kyua: An odd backtrace that appeared on the aarch64 console (and logs) Message-Id: Date: Sat, 12 Aug 2023 10:21:24 -0700 To: Current FreeBSD X-Mailer: Apple Mail (2.3731.700.6) References: X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.30:from]; RCPT_COUNT_ONE(0.00)[1]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.30:from]; DKIM_TRACE(0.00)[yahoo.com:+]; TO_DN_ALL(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_COUNT_TWO(0.00)[2] X-Spamd-Bar: --- X-Rspamd-Queue-Id: 4RNSBX4fn7z3VgB I ran the block of zfs tests on a snapshot 14.0-APLHA1 install used to boot and operate a Windows Dev Ket 2023. I just noticed a non-panic/non-crash backtrace had been output to the console (and related logs): . . . GEOM: md0: the primary GPT table is corrupt or invalid. GEOM: md0: using the secondary instead -- recovery strongly advised. GEOM: md1: the primary GPT table is corrupt or invalid. GEOM: md1: using the secondary instead -- recovery strongly advised. GEOM: md2: the primary GPT table is corrupt or invalid. GEOM: md2: using the secondary instead -- recovery strongly advised. GEOM: md3: the primary GPT table is corrupt or invalid. GEOM: md3: using the secondary instead -- recovery strongly advised. got error -2 on name 1 on op 3 KDB: stack backtrace: db_trace_self() at db_trace_self db_trace_self_wrapper() at db_trace_self_wrapper+0x30 zfs_lookup_internal() at zfs_lookup_internal+0xb8 zfs_rename() at zfs_rename+0x128 zfs_replay_rename() at zfs_replay_rename+0xa4 zil_replay_log_record() at zil_replay_log_record+0x1b0 zil_parse() at zil_parse+0x360 zil_replay() at zil_replay+0xdc zfsvfs_setup() at zfsvfs_setup+0x1fc $x.0() at $x.0+0x6b0 vfs_domount_first() at vfs_domount_first+0x24c vfs_domount() at vfs_domount+0x2cc vfs_donmount() at vfs_donmount+0x844 sys_nmount() at sys_nmount+0x60 do_el0_sync() at do_el0_sync+0x520 handle_el0_sync() at handle_el0_sync+0x44 --- exception, esr 0x56000000 GEOM_NOP: Device md0.nop created. GEOM_NOP: Device md1.nop created. GEOM_NOP: Device md2.nop created. GEOM_NOP: Device md3.nop created. GEOM_NOP: Device md4.nop created. GEOM_NOP: Device md5.nop created. GEOM_NOP: Device md0.nop removed. GEOM_NOP: Device md1.nop removed. GEOM_NOP: Device md2.nop removed. GEOM_NOP: Device md3.nop removed. GEOM_NOP: Device md4.nop removed. GEOM_NOP: Device md5.nop removed. . . . For reference . . . I had set up md0 .. md5, each 1g swap backed, and, in /etc/kyua/kyua.conf , had used: test_suites.FreeBSD.disks =3D '/dev/md0 /dev/md1 /dev/md2 /dev/md3 = /dev/md4 /dev/md5' (I the future I'll use file backed that are larger.) Note: After dropping a copy of the extra files from the rpi-arm64 snapshots's msdosfs into the rock64 installation's msdosfs, the rock64 snapshot install on the USB media then can boot and operate every aarch64 system I have access to. (It is something I've done for a long time.) The rock64 having an unusually large area for u-boot related dd'ing could serve well for dd'ing various alternatives and testing them: overlapping the other file systems is unlikely. Such can be handy for having a uniform testing environment. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Aug 12 20:32:53 2023 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 4RNXRb3RMYz4Tksk for ; Sat, 12 Aug 2023 20:33:15 +0000 (UTC) (envelope-from otis@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 4RNXRb2hPcz4JBd for ; Sat, 12 Aug 2023 20:33:15 +0000 (UTC) (envelope-from otis@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1691872395; 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=9MxOoFTqESV4mV9xPSSv3+ajgIgTRn00gRQr6thooho=; b=dUuRbvO497RFob1+NlrB/KbyiIUyy8it2xQTrwtTUb0eNK1YSNDEbIA/oNJBi5fJLiFOz3 rNgwoO2Ufs6zmL+m2VXWfTlD+orcE7XsV0llqi/Xi1aiCYSZ+NNeis+cQ/dHZ39Besazgn SxAaV2Pt2+Ld+aCLREcrBuVnnCUNI+p+okQ2mf2fLm7RXmSnDUCuDS9NAC2RMab8XRhSqV UsF5IkZkz1LCkIqh4VZb2GzsKf8dzq48BU2SX3zibSXDVCz3pvJNlXtWbVJuiUQ9JElQMn gEyFjmmdU2OoF0X5tLbCWmeCUZ2nAso/qkYUelYnVdunQRP8ZnGZe4Ah1HXc/Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1691872395; 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=9MxOoFTqESV4mV9xPSSv3+ajgIgTRn00gRQr6thooho=; b=TjsvETnG/FKxIdIO8+q0J8VoVlS3Kkrie6ilpJFqFbu0LaKnRvgBUTN2+msxoVaD6/7wUI ar3VeF5E796iD6H3hyMDHnmkS9+BpgMjbHHrfqWislCD81F/wUQLP8DZ1ncffyyp9jd3SV G3vJMjJuxB1pJZyG+8lf2z/O1W0o0qbR5BL3QSyyIuVfMZw+9080TLaeeD9jbHspve+Imp lgb7bnf3y4h5X5LQz6+S3DGSRbq9tg+f5WRudwqkFJV3M/DRF0DF/DfmZzxgQS3SE8dVwo HWDLnk36opygcf+Rp9nS0H6qt8BC6Xc4o7ugMt+QbffX4XqAZZXffoO/V48a8A== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1691872395; a=rsa-sha256; cv=none; b=GPz1Ja8g4y4+uiMfzkE4qTBL695+uDH6uDKH7AmH2/6hv0NRTTRm0SU4D4EKMj/gjDTJj3 60Ib9XDN1vIuuXun/QJ8077kvIU1T1vlgcaat9rvzMb8uAnAm2RuEa6RuzdlyFm/GQ2Ii8 FBLbBXVVwKKJaVGC0yaPSoD45ohHFuosI1SEYCvdapF1PCS9t0uCJYO2DRN2L0rSuhW0D5 CXgmXsTrN7KA8vVxzqYZxkVyYw+A61KCwlB5zj8AYNexNIHJbMzKxHmGTmtmwp9wF16Srh pld9IqHsW2vHruvcgc6MPjTa1EUVzGaHqJId5CBq1PNKZ4nmPhk8R2HozRD1xw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from ns2.wilbury.net (ns2.wilbury.net [92.60.51.55]) (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 ECDSA (P-256) client-digest SHA256) (Client CN "svc.wilbury.net", Issuer "R3" (verified OK)) (Authenticated sender: otis) by smtp.freebsd.org (Postfix) with ESMTPSA id 4RNXRb12dXz5Dd for ; Sat, 12 Aug 2023 20:33:15 +0000 (UTC) (envelope-from otis@FreeBSD.org) Received: from smtpclient.apple (host-88-132-63-63.prtelecom.hu [88.132.63.63]) (Authenticated sender: juraj@lutter.sk) by svc.wilbury.net (Postfix) with ESMTPSA id 71F3B61FAB for ; Sat, 12 Aug 2023 22:33:12 +0200 (CEST) From: Juraj Lutter Content-Type: text/plain; charset=utf-8 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 16.0 \(3731.700.6\)) Subject: Error crosscompiling 14.0-ALPHA1 on amd64 for arm64.aarch64 Message-Id: <68CBFC44-9C0A-43D1-A0C2-530207E0762F@FreeBSD.org> Date: Sat, 12 Aug 2023 22:32:53 +0200 To: FreeBSD CURRENT X-Mailer: Apple Mail (2.3731.700.6) Hi, recent 14.0-ALPHA1 sources is giving an error: Building = /usr/obj/usr/src/arm64.aarch64/obj-lib32/lib/libssp_nonshared/libssp_nonsh= ared.o Building = /usr/obj/usr/src/arm64.aarch64/obj-lib32/lib/libgcc_eh/int_util.o error: unable to create target: 'No available targets are compatible = with triple "armv7-unknown-freebsd14.0-gnueabihf"' 1 error generated. error: unable to create target: 'No available targets are compatible = with triple "armv7-unknown-freebsd14.0-gnueabihf"' *** [libssp_nonshared.o] Error code 1 Commandline: make -j`sysctl -n hw.ncpu` WITH_META_MODE=3D1 TARGET=3Darm64 = TARGET_ARCH=3Daarch64 buildworld buildkernel The build runs in clean objdir, src git hash = 220427da0e9b2c1d8e964120becc17eb7524e46f Host runs 14.0-CURRENT 28d2e3b5dedf Am I missing something obvious? Thanks. =E2=80=94 Juraj Lutter otis@FreeBSD.org From nobody Sat Aug 12 20:32:53 2023 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 4RNXRj3k9Zz4Tkwp for ; Sat, 12 Aug 2023 20:33:21 +0000 (UTC) (envelope-from otis@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 4RNXRj3Fyfz4Jd1 for ; Sat, 12 Aug 2023 20:33:21 +0000 (UTC) (envelope-from otis@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1691872401; 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=9MxOoFTqESV4mV9xPSSv3+ajgIgTRn00gRQr6thooho=; b=sMFQPxDOSNJ4h3bO79hK6U5McNq6jb8ie/qJtsYic2wqXLB62JtqqisOQNHZgK/oOk7jqz PM740HESvW5nPaclaD4+Ngrly2/YlmTTl+D6os56XiG1t3foUK90zMJosLAryFLXlp++P5 pCM0TO2OWXfhBs49AHAdfmQcJvn/M1GYwTyOrmB+7LCYYg5Tf/0Uw9m2bCBJW392LQK2Ez 2W7kmdeYYGD5k3X6gdv3wqWbY9om/Vgkl4QOioE2RhRvChbl/SvyR6YGfjrEReKcTFkYzW LvUwbQFmnYdvszoQq8rgT9w1rFlJfIu9MzRMBJM02oPPsewAkOVZiCR+nQRJ1g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1691872401; 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=9MxOoFTqESV4mV9xPSSv3+ajgIgTRn00gRQr6thooho=; b=daU1y7vBIU1dCzLUkJnqjlD81tLOLkidwOjV2Ha4hxj7CorrX4tkD7B/kFbmn7bEG9wZOE Jo95MFwenlVmOJIQXSiUBDcc5pySnRyoy5BbxeUkCKTtH7tCrKJtcxYWaEwSsdS6+9JZk0 qhUaBLJ3fZ321p5PtkEIkgE5lcZ6J24KzQzQgA5aB/rQffg9ALKiuzS3kAsd90BvpSlRfk uu1G3vix4ykwCbnvKOoq8OlVm2ykM2/taDjRGR9wNHHaE9z9RflXwREbViJNmAWLSSDD6G O4QBfODJVsoY6nE0Nods5n1uKZQ+HeGWjiQtBaUo+EZG+IXTrLasu9qxC+9z5A== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1691872401; a=rsa-sha256; cv=none; b=tSds+31/4hWoTHR7yokrqpGvOFq95uursOD4Bz7fhPlaubjq5txK4FaCLgCULGx5pnueWB T3+c1+97yBvNTHDqV0nYJ07mOYIDgM90Sq7ypkDDMU8yD3545iY9KU6U871YugtKQjGb6Z 95YR88O0WxNX7mUqatW+up/0c7oLoG6tnCnyaki+T85XkiiIWqMf/NIMx7bqiIaVeIvgod BFGpjMnB9nH41DBnOHMSOgWLKwShgiZPeNo6bOtgUBZtNvECeN8dkib7ARPj92UI0B5jih /FIAizX3mlprSgh22r0tXAwcp1TUseaCq/pvottpYsBx9+6p0lDro2q1Oremuw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from ns2.wilbury.net (ns2.wilbury.net [IPv6:2a01:b200:0:1:f816:3eff:fecd:13e6]) (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 ECDSA (P-256) client-digest SHA256) (Client CN "svc.wilbury.net", Issuer "R3" (verified OK)) (Authenticated sender: otis) by smtp.freebsd.org (Postfix) with ESMTPSA id 4RNXRj1jtLz6QM for ; Sat, 12 Aug 2023 20:33:21 +0000 (UTC) (envelope-from otis@FreeBSD.org) Received: from smtpclient.apple (host-88-132-63-63.prtelecom.hu [88.132.63.63]) (Authenticated sender: juraj@lutter.sk) by svc.wilbury.net (Postfix) with ESMTPSA id 2363D61F91 for ; Sat, 12 Aug 2023 22:33:12 +0200 (CEST) From: Juraj Lutter Content-Type: text/plain; charset=utf-8 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 16.0 \(3731.700.6\)) Subject: Error crosscompiling 14.0-ALPHA1 on amd64 for arm64.aarch64 Message-Id: <68CBFC44-9C0A-43D1-A0C2-530207E0762F@FreeBSD.org> Date: Sat, 12 Aug 2023 22:32:53 +0200 To: FreeBSD CURRENT X-Mailer: Apple Mail (2.3731.700.6) Hi, recent 14.0-ALPHA1 sources is giving an error: Building = /usr/obj/usr/src/arm64.aarch64/obj-lib32/lib/libssp_nonshared/libssp_nonsh= ared.o Building = /usr/obj/usr/src/arm64.aarch64/obj-lib32/lib/libgcc_eh/int_util.o error: unable to create target: 'No available targets are compatible = with triple "armv7-unknown-freebsd14.0-gnueabihf"' 1 error generated. error: unable to create target: 'No available targets are compatible = with triple "armv7-unknown-freebsd14.0-gnueabihf"' *** [libssp_nonshared.o] Error code 1 Commandline: make -j`sysctl -n hw.ncpu` WITH_META_MODE=3D1 TARGET=3Darm64 = TARGET_ARCH=3Daarch64 buildworld buildkernel The build runs in clean objdir, src git hash = 220427da0e9b2c1d8e964120becc17eb7524e46f Host runs 14.0-CURRENT 28d2e3b5dedf Am I missing something obvious? Thanks. =E2=80=94 Juraj Lutter otis@FreeBSD.org From nobody Sat Aug 12 22:17:39 2023 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 4RNZmD0Bj5z4TsZx for ; Sat, 12 Aug 2023 22:17:48 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail2.karels.net (mail2.karels.net [3.19.118.201]) (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 "freebsd", Issuer "freebsd" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RNZmB6wzCz4VXx; Sat, 12 Aug 2023 22:17:46 +0000 (UTC) (envelope-from mike@karels.net) Authentication-Results: mx1.freebsd.org; none Received: from mail2.karels.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by mail2.karels.net (8.17.1/8.17.1) with ESMTP id 37CMHeFZ031900; Sat, 12 Aug 2023 17:17:40 -0500 (CDT) (envelope-from mike@karels.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=karels.net; s=mail2; t=1691878660; bh=gePiVqPTqdw+4MVMqHVil5aKfSnUppyKGCDf7D0q9oY=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=Qy48r5TyGNMGIf602IV46Xlc8IaB7PRbS/GriEhf7+w3xEmIdqUo39Gdvk+nJ/vvJ MJ5PiIegwi7SfKFZG0eM4n3jvWQEGx6iXblYgfDCvhIc7beEvTIV+MriRkMZ3OkEs0 CX/5ApGC6nX3pMhhCdOOUdTSxC1sVjYrabIz7wHKWwxS+b/GJ6G/dbMFqi4TLAQjeP P+eAZrk7A+r4L80OuW4h8h1VagKQoGk9rUpMqg3eIK4/lmx1XJvhJlN4YHmm2Qs53P GfFLJuFlxKQiDfKmIvc8BD7PQD4aOaGOMg0p+sLLNYmuPl/ZOUrd43LAK6Juk5YtOh IO/CmITa80oUQ== Received: from [10.0.2.130] ([73.62.165.147]) by mail2.karels.net with ESMTPSA id L+tRGAQF2GSafAAAs/W3XQ (envelope-from ); Sat, 12 Aug 2023 17:17:40 -0500 From: Mike Karels To: Juraj Lutter Cc: FreeBSD CURRENT Subject: Re: Error crosscompiling 14.0-ALPHA1 on amd64 for arm64.aarch64 Date: Sat, 12 Aug 2023 17:17:39 -0500 X-Mailer: MailMate (1.14r5964) Message-ID: <0FA5C2F2-6639-4522-AA29-537F596A5F81@karels.net> In-Reply-To: <68CBFC44-9C0A-43D1-A0C2-530207E0762F@FreeBSD.org> References: <68CBFC44-9C0A-43D1-A0C2-530207E0762F@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=UTF-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4RNZmB6wzCz4VXx X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:3.16.0.0/14, country:US] On 12 Aug 2023, at 15:32, Juraj Lutter wrote: > Hi, > > recent 14.0-ALPHA1 sources is giving an error: > > Building /usr/obj/usr/src/arm64.aarch64/obj-lib32/lib/libssp_nonshared/= libssp_nonshared.o > Building /usr/obj/usr/src/arm64.aarch64/obj-lib32/lib/libgcc_eh/int_uti= l.o > error: unable to create target: 'No available targets are compatible wi= th triple "armv7-unknown-freebsd14.0-gnueabihf"' > 1 error generated. > error: unable to create target: 'No available targets are compatible wi= th triple "armv7-unknown-freebsd14.0-gnueabihf"' > *** [libssp_nonshared.o] Error code 1 > > Commandline: > make -j`sysctl -n hw.ncpu` WITH_META_MODE=3D1 TARGET=3Darm64 TARGET_ARC= H=3Daarch64 buildworld buildkernel > > The build runs in clean objdir, src git hash 220427da0e9b2c1d8e964120be= cc17eb7524e46f > > Host runs 14.0-CURRENT 28d2e3b5dedf > > Am I missing something obvious? > Thanks. Did the buildworld start out by building a cross-compiler? Have you tried without meta mode? With a clean objdir, I don't see how it would matter, but I'm not sure I've tried it. The ALPHA1 builds seem to have worked, but I think they run on arm64. Mike > =E2=80=94 > Juraj Lutter > otis@FreeBSD.org From nobody Sat Aug 12 22:25:48 2023 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 4RNZxw54wJz4TtTD for ; Sat, 12 Aug 2023 22:26:12 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-20.consmr.mail.gq1.yahoo.com (sonic314-20.consmr.mail.gq1.yahoo.com [98.137.69.83]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4RNZxp56nGz4XMM for ; Sat, 12 Aug 2023 22:26:06 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=N0k+Lfos; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1691879164; bh=zhCWP0FgAk+Y4gvFDd/9xE+8VbvsIOwwZQ28LsDL6J0=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=N0k+Lfos4M2oxA5ToHUuwMG1WrDi0li9W88NkaHJb0CUetnVRGTiWwFqYuGGIgXaPJSqZEsGTJFN/5PwpaRlbeapCT/F2q+Wh4np6ZB5uaWfCy0DINuxfBMXxrTKAnh9UYfRb2RHuw/Ts6FTKHRLHwWDy/EZAxD1dterE7LHJTyYGJmslQIRWFt4FF0Dwvp7XQZK2DRy/M/EzSK31fBctt8Y25nKb5u8KhxCgl3LwLdrcv7sVRtVhqdza74xytqG33fyk63k4ITY0DT9NzHKpXOGkkuJdoNR3uq4OyW6XEdkqGak7nIDe+IpNIdoYEGCsyha+DpXA/v+Sk6mtKg5uA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1691879164; bh=t7qSu8NQECWvwpNLgC1RrT0veShxlTwcp0Pl6u9oAEX=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=RnPTMKUz5z7N8uoZuOYYlXzuqAZ0OSuMqkxTZ48iuXKNfF9VMZPLjnzXgjXmSoKPY+AIV5RKR9exdQvZMXzhP+dKYM5Grw0+hf5vYD6bkJfGTKWE06QUb+ZyUdojgbhdhsZ/FXCFq1jDVJ/B+HZrwlwAASXT6446nRbwcMYHcfVERpsoj9fR7idzTc5yHXjB9rvCUnubn6mD6l83UGgHwEGK/NWM2H7opJyzU81XvXQVHX34ZMtB3uBpGRgZ9+RPAnCR6zengDF0nQLnF6xTlzb4IiTiSNxIZ+YxwUXfTuUDZmHUAVbvhTPU3CQgq1ZKqlkdGUkJacui332wZ33KtA== X-YMail-OSG: UXg61okVM1m2c5sMNZ0waRkt2Lf1uVu40A.NfESESkms5j1_T6PUrl4AEu0mSKR wAblclcJDflo.xpGHUYwqdJhNqIGyKAdvA9aT_niELuHVSCHPMNitcE1ebL3O2n2BJxZO7mMC8ir Y6j7XuLaxGPQ6YgkHLEOKPt2GSklsW_nbDgmqgKxMc2_Ki1HgPKBmSha80SLBOiwds9gwTdZ.pca lwPp4YJAkCowFdOWOxJB2ZNjlyF4GOAABGoyvgKsjq_iaeQnoAV.MBPsnTWZ3orwmBYIjskr1EOl aYqjQ5Lh.81hkvTOHSqE_8_NIhzltHPDrDu3kAR3dbXeOXh5zDTuOzwg7pBQjG8NeNH2siONxx4u kw9710HWBkFr2kv3F91hhSXXBAKpYSFFAXrbpM.._Y2c1.RlZkQJr3.2Jnr1BAwfzs0F2TeRihan rYvu1RCJ58cxRlNYlh1GEAEvySMWAOCCgc9vaPnD_mmKlrgHHXjmP8FR_6BhTaR7GnQIIqByd2QV PLIGlmgUClGjKYuwTIaDZtFrmZ1K_PwG90U6cKeQ61BWY8LZQBO7087sH6qoixY1S9jdFpspPx8e ehkdXm3Vlf.DfjVjaFNw.70r_Uw5gVZPhXSe.vlI9hH6hJZEug.hfsD6Zqr_uzEBzRlf5.mwxtRn 3x9XrvEXMJIlPANhWivOFCvXX9OHp_ry2JH24IUX3weWBsT_ujA2lts5imr.ltQGA1QnasceUEUK Gqob3_s9PNO5bqGwW4tr12xXarmHYyUaHc8q8ToSlJSaWRN3ZqzcX.ppsr7AEttSfIHr5q2DyWWf zGxaJ4QEFXp2RhBW1Dwq7QJ.lYAFPgbiba337H9Xz2dp4UhZfRXH3.dFXCzTPEqv2DhJKyQUvX68 FSIDfEdJWH1OdyFq3WJYLZMQjPGfhicmzcOlGKGFtoMP9cJNECRYCJioMUzlYbOLOPyJVJctOWY_ Zq4mTlANwspwFC0Lxygm2EHQOmJOggpHUp2iXvDiZyLhaBSjdHKSaHtvf0M.wdmz8J.goV_H2T0M AtDxDaSHLyRhFxmHbLqwLjLV7Hz5rHkzyOjV9Vg7kZfG88XVTPDrLRGplAvZK7jwwOvMs_pVNbxL 3M_c6KRZNIsfNq4BUEqsGEtYM4EAv37SSOpaiOYn7V5SW.J2yGWsxLfi7mZVUXDuVp.PCRtfeEr_ 4WRZU8PTOw5g.xVlyq5wjWB6KLphYtYjWKDVMuOkoBwLAaicj2utZtg81J2zsrz8GdHU47KBOfKr evqiZEu2Lr47._Yjv7JoTb4_kWcOXK_sQlH2_YWewwuIwI0Yk9yXlONhPq_tunFVUqdmQKpEbxew pabMtEzxuWYylaIltlJvu0pWcIbQoo_JrSYkenDkipszKV3F2bTwJql_3_tUeejdVbEScKaJmH21 eK_c.YTQTnWhiptillwOPirp30wiCbm2BCGhonJJUMPExb0rgcxtcD7VVDWShHsr6TMY55GgRbyh CqoFj.DHZxdbFICaKYgKgSWpnnNXXA7wQKR5QlO_U0npmYIrnV3WQoyLeIfWrvsHhwsE5IX4ib7D zjBG43_R9TRC_YoMD5B5pUfXg6C4eIRc1BX79D4Ct6M3E1U.NObe.QSmOh0nhNOZXZ0SWYPCAwsk tUtyQHS3PdQOeIWr3klfdkwCQIDRKy3yoEC1vjK55ASWly_ADs1qizA4J.91Ycw2MURwy_TylU5a cxAO.99di6lQugHx8_.RDyePjf2lAyQVlvHR4igxcNgouf2I5TV0zqPYRMMW234dljhA9Kurf44e Esb71t.DrcjmJmbC96eHuGuf48K6nhx_CgX6AOb71ZEk4Ub_VdyJ3Ux5RQTprU2edjqn4a741DBr 4PZ78uMAbZBvVM00FjMS_V1JDJxgzKcAVE8FsyaQPRJD2aXGrB4nj6y6I7Ut1Vr7blc9L47gidy. ZwC7ZpS11_Z4MMRRNkacVCDRRo8orJwjypQ8YoRMVV8skrLildw34Pfdl4AmF79z33SknFRlRD.J AesGzdxyidKt.Z5wvW8z2O8FKPWrbJIp9kmcpc81efAmv98fQLMXQ2Q9qiFH2E6t4rpwyHrBvZC6 YrOeeY6yImi13kzykeCItlvg._VDtdChVLl4z1ZT2DZ7ydNdDbyME2YxxrbOzu1PmuZGp3cWRAQO MBMfZqPmLMsnYlI0T4mCjJ.fq.Nq7gc8kksT.xsLrWF3ysva77yAnGNx6_u1jGh.GtpMg77sGrCD IAuWVpHYVNhx0K3njFLlYYke_OvYa_ErWDUt5G01i0haKZoAIQ12G0_zSEfztu9nUAIz3wHJ_LNM - X-Sonic-MF: X-Sonic-ID: 2548be59-581c-451d-9fce-41c01d593fad Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Sat, 12 Aug 2023 22:26:04 +0000 Received: by hermes--production-bf1-865889d799-cgv22 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 12e9e4d3a69910ace1f8aae4e4573347; Sat, 12 Aug 2023 22:26:00 +0000 (UTC) From: Mark Millard 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 16.0 \(3731.700.6\)) Subject: RE: Error crosscompiling 14.0-ALPHA1 on amd64 for arm64.aarch64 Message-Id: <3F662034-1836-43DE-9B52-5769A9DB497D@yahoo.com> Date: Sat, 12 Aug 2023 15:25:48 -0700 To: Juraj Lutter , Current FreeBSD X-Mailer: Apple Mail (2.3731.700.6) References: <3F662034-1836-43DE-9B52-5769A9DB497D.ref@yahoo.com> X-Spamd-Result: default: False [-3.43 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.93)[-0.927]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; ARC_NA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.83:from]; BLOCKLISTDE_FAIL(0.00)[98.137.69.83:query timed out]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.83:from]; DKIM_TRACE(0.00)[yahoo.com:+]; TO_DN_ALL(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MID_RHS_MATCH_FROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2] X-Spamd-Bar: --- X-Rspamd-Queue-Id: 4RNZxp56nGz4XMM Juraj Lutter wrote on Date: Sat, 12 Aug 2023 20:32:53 UTC : > recent 14.0-ALPHA1 sources is giving an error: >=20 > Building = /usr/obj/usr/src/arm64.aarch64/obj-lib32/lib/libssp_nonshared/libssp_nonsh= ared.o > Building = /usr/obj/usr/src/arm64.aarch64/obj-lib32/lib/libgcc_eh/int_util.o > error: unable to create target: 'No available targets are compatible = with triple "armv7-unknown-freebsd14.0-gnueabihf"' > 1 error generated. > error: unable to create target: 'No available targets are compatible = with triple "armv7-unknown-freebsd14.0-gnueabihf"' > *** [libssp_nonshared.o] Error code 1 >=20 > Commandline: > make -j`sysctl -n hw.ncpu` WITH_META_MODE=3D1 TARGET=3Darm64 = TARGET_ARCH=3Daarch64 buildworld buildkernel >=20 > The build runs in clean objdir, src git hash = 220427da0e9b2c1d8e964120becc17eb7524e46f >=20 > Host runs 14.0-CURRENT 28d2e3b5dedf >=20 > Am I missing something obvious? The likes of https://ci.freebsd.org/job/FreeBSD-main-aarch64-build/ are built on amd64 via cross building. Those builds have been and are still working. A log file from the recent one shows the actual cc command it used for /usr/src/lib/libssp_nonshared/libssp_nonshared.c : cc -march=3Darmv7 -m32 -target armv7-unknown-freebsd14.0-gnueabihf = -DCOMPAT_LIBCOMPAT=3D\"32\" -DCOMPAT_libcompat=3D\"32\" -DCOMPAT_LIB32 = --sysroot=3D/usr/obj/usr/src/arm64.aarch64/tmp = -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin = -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/lib32 -O2 -pipe -fno-common = -fPIC -g -gz=3Dzlib -MD -MF.depend.libssp_nonshared.o = -MTlibssp_nonshared.o -std=3Dgnu99 -Wno-format-zero-length = -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k = -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes = -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch = -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts = -Wnested-externs -Wold-style-definition -Wno-pointer-sign -Wdate-time = -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body = -Wno-string-plus-int -Wno-unused-const-variable = -Wno-error=3Dunused-but-set-parameter -Qunused-arguments -c = /usr/src/lib/libssp_nonshared/libssp_nonshared.c -o libssp_nonshared.o But you have not provided anything to compare with for finding = differences. Simillarly for: /usr/src/contrib/llvm-project/compiler-rt/lib/builtins/int_util.c (but needing some output splicing to form the whole line as one) there = is: cc -march=3Darmv7 -m32 -target armv7-unknown-freebsd14.0-gnueabihf = -DCOMPAT_LIBCOMPAT=3D\"32\" -DCOMPAT_libcompat=3D\"32\" -DCOMPAT_LIB32 = --sysroot=3D/usr/obj/usr/src/arm64.aarch64/tmp = -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin = -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/lib32 -fpic -fvisibility=3Dhidden= -DVISIBILITY_HIDDEN -O2 -pipe -fno-common = -I/usr/src/contrib/llvm-project/libunwind/include = -D_LIBUNWIND_IS_NATIVE_ONLY -D_LIBUNWIND_USE_FRAME_HEADER_CACHE = -I/usr/src/lib/msun/src -g -gz=3Dzlib -MD -MF.depend.int_util.o = -MTint_util.o -std=3Dgnu99 -Wno-format-zero-length -Wsystem-headers = -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign = -Wdate-time -Wno-empty-body -Wno-string-plus-int = -Wno-unused-const-variable -Wno-error=3Dunused-but-set-parameter = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality = -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef = -Wno-address-of-packed-member -Wno-switch -Wno-switch-enum = -Wno-knr-promoted-parameter -Qunused-arguments -fno-exceptions = -funwind-tables -c = /usr/src/contrib/llvm-project/compiler-rt/lib/builtins/int_util.c -o = int_util.o Did your build's commands have the expected "-march=3Darmv7"? "-m32"? = And so on. You might want to show the exact commands and failure notice = together. =3D=3D=3D Mark Millard marklmi at yahoo.com