From nobody Mon Apr 22 07:26:59 2024 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 4VNH0V4jFlz5JX3L for ; Mon, 22 Apr 2024 07:28:10 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from mailgate.Leidinger.net (bastille.leidinger.net [89.238.82.207]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) client-signature ECDSA (P-256)) (Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4VNH0T447xz42nl; Mon, 22 Apr 2024 07:28:09 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=leidinger.net header.s=outgoing-alex header.b=JxK6fpeW; dmarc=pass (policy=quarantine) header.from=leidinger.net; spf=pass (mx1.freebsd.org: domain of Alexander@Leidinger.net designates 89.238.82.207 as permitted sender) smtp.mailfrom=Alexander@Leidinger.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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1713770883; 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=JaavZIfjWoswCOebioIfSRSPUZmuhUyj5LQ4CwllYrA=; b=JxK6fpeWrWNjPva9rgBdUN6dzWeqUp8alOU14KzkCpffYh9sISCkAXv33444bL+/D0ZnsD B+S29EwT7e4733ANPQBbA2EFUMMzBfkaPlfpuAK4Bn1bi3zfKqKQvXXr4mJqncI/hyHcR7 TRjMNxZcyBK6f7fxU3x8OSnUPhDMwi+ge0uCh0WJ32sFmQBZ4hfXDcTXRen1P6BZL5pUvZ 2HWZWcJpthIceAYl707A8rIJphn0SPHtaYsCkb7QNfmSrhmg7/MU+1N1MXRMnrjXNL/82z 71Xf+2jEl4sIGJmb1zhayPuVW5doQLjFEoGal93cZzkYxlfN/IW4zsy+N+eCXA== Date: Mon, 22 Apr 2024 09:26:59 +0200 From: Alexander Leidinger To: Current , Gleb Smirnoff Subject: Strange network/socket anomalies since about a month Message-ID: <1fe609f252e7fae6d746530d5035ec0e@Leidinger.net> Organization: No organization, this is a private message. Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=_7dd48bd00c899144edc585f9aeab7121"; micalg=pgp-sha256 X-Spamd-Bar: ------ X-Spamd-Result: default: False [-6.05 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.95)[-0.952]; DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine]; R_SPF_ALLOW(-0.20)[+mx:c]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex]; ARC_NA(0.00)[]; ASN(0.00)[asn:34240, ipnet:89.238.64.0/18, country:DE]; MIME_TRACE(0.00)[0:+,1:+,2:~]; HAS_ORG_HEADER(0.00)[]; MISSING_XM_UA(0.00)[]; DKIM_TRACE(0.00)[leidinger.net:+]; RCPT_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_ZERO(0.00)[0]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MLMMJ_DEST(0.00)[current@freebsd.org]; TO_DN_ALL(0.00)[]; HAS_ATTACHMENT(0.00)[] X-Rspamd-Queue-Id: 4VNH0T447xz42nl This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --=_7dd48bd00c899144edc585f9aeab7121 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Hi, I see a higher failure rate of socket/network related stuff since a while. Those failures are transient. Directly executing the same thing again may or may not result in success/failure. I'm not able to reproduce this at will. Sometimes they show up. Examples: - poudriere runs with the sccache overlay (like ccache but also works for rust) sometimes fail to create the communication socket and as such the build fails. I have 3 different poudriere bulk runs after each other in my build script, and when the first one fails, the second and third still run. If the first fails due to the sccache issue, the second and 3rd may or may not fail. Sometimes the first fails and the rest is ok. Sometimes all fail, and if I then run one by hand it works (the script does the same as the manual run, the script is simply a "for type in A B C; do; poudriere bulk -O sccache -j $type -f ${type}.pkglist; done" which I execute from the same shell, and the script doesn't do env-sanityzing). - A webmail interface (inet / local net -> nginx (rev-proxy) -> nginx (webmail service) -> php -> imap) sees intermittent issues sometimes. Opening the same email directly again afterwards normally works. I've also seen transient issues with pgp signing (webmail interface -> gnupg / gpg-agent on the server), simply hitting send again after a failure works fine. Gleb, could this be related to the socket stuff you did 2 weeks ago? My world is from 2024-04-17-112537. I do notice this since at least then, but I'm not sure if they where there before that and I simply didn't notice them. They are surely "new recently", that amount of issues I haven's seen in January. The last two updates of current I did before the last one where on 2024-03-31-120210 and 2024-04-08-112551. I could also imagine that some memory related transient failure could cause this, but with >3 GB free I do not expect this. Important here may be that I have https://reviews.freebsd.org/D40575 in my tree, which is memory related, but it's only a metric to quantify memory fragmentation. Any ideas how to track this down more easily than running the entire poudriere in ktrace (e.g. a hint/script which dtrace probes to use)? Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_7dd48bd00c899144edc585f9aeab7121 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc; size=833 Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmYmEWAACgkQEg2wmwP4 2IamTg/+KQX6CTzmj/ORdtu6Ur6rzN4+SjidDAYMorx/90bPIDH2Gvq4FVQEf1F1 jj0Ygoo2CjxWzUtDL0DS173X1ricd8oooUnkx3EGIYps/BChplXitb9RJ+hftP2r Q2psnLylvT6qu3RozuF8nNjDaXl9corIHxV18jWZ5VkjND1Y37Cp7rMirBY7EhpZ iXkcmmhg7zV7f1QGRsW57W+n5+AC0thE2pvpSZejG7DbV0GHBJ9QG7SAdHdJs5Hn HuKrRszJdSRGzoEVMPFsBKDs+9wvordjUvKgux1beNZE+wYUMvOSkTLiiYgmvAZC NlBPgfBOBL0oNYiMl8iDwzdf1GkiI7TH1LNbCvn04bRqHndjJNif02He0IGneyGF MKGMA/bLLoCF6w39KXv+R2qsQ/chB11U64Oj/S3cEYSpxTWNZQbyGyyqNzfU/uyX r3bldFZZEYpR9wNO+I/ob6T/0QcvpOjarTVpDUsYEjArnTvzv7KYqitGRXpX1PTC +UKRZW9UNDLV4Wt00qB3DWPueis/p4LripYVcUGdjtdQ+X89Q9AOjNKGC6nODsA0 xHZgJfOL4u0riSHbuRefdbQCDdFLHPpA1r8+mq/eRmVW++ejlIFXoyqTiNhsjaVw 5daL+wu2uAms3NhKdfvuX/WG+TPnrvEhPwlA0hhzQWPlHL4LpUQ= =msAU -----END PGP SIGNATURE----- --=_7dd48bd00c899144edc585f9aeab7121-- From nobody Mon Apr 22 08:00:50 2024 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 4VNHkG6KG3z5JZNq for ; Mon, 22 Apr 2024 08:00:54 +0000 (UTC) (envelope-from glebius@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 4VNHkG5Y3Mz467Q; Mon, 22 Apr 2024 08:00:54 +0000 (UTC) (envelope-from glebius@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1713772854; 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=KoyRMhhJ25tAhMKIfXOqVvURBd/lRCIv++GOONRmZJ0=; b=n5G/WOU3snqRZBWg3pOb/9nKjaDBqmwUEXrsU22blSqaw1oOQa8lFhVab6Erq6mFfGzdPb htZM/t8BLewNh1oGaSmivBxpViKMf1Zp1QegRA73Y/JvTY/xmEVGukmTNJRilm2Rt8cB77 cFblWhl5yHNUY/8dKW9yoln2LwxioRqQW8xYo9xpdGsAsKFELwTvqUbminvCJoa9y8KAEG cfIlBe+EirXHAABbFqRvg2kkglsC5zx1De8JV6BivetUFnZD33DcS79Wo1iwARALFeZn6T BG3gPwIXM0LksILt0FStQrdmVVgT8Sht5OyAZzAVThFnfbQOOYWj3DZkRE+JiA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1713772854; a=rsa-sha256; cv=none; b=yN5IytYZ6L+5c/vOzV6Gmn0EdoJOVXYMZdDETroroMrczwgjfnW5LTIwku2MuYa/4rkRff uNkrKJ0/5T/oS2XvinVCquWF2rkeTULZUxUVrQu9ayt7OujSwkfOzVhopNeaZlL1oLaN6i hIrweB4X7BAVXP3GgVAVllfEAsaXhfE4mHsq8wVaTZW/p64g0o+h1TnSeaWwrx3eBxj7Ia /pWwl/HALDkfXWeKcbTpKjRuUWgCGexWolXDekcjo1W4RffeTXkpafE6DzIkLBqJkN3zQ3 7wEC1Gxf7b9iEOgmE6H/SQIUtF+BV0trqmIKAljYEDDePvKgXcJ/e2mbRfsovw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1713772854; 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=KoyRMhhJ25tAhMKIfXOqVvURBd/lRCIv++GOONRmZJ0=; b=aFVLBRVEFO/5yXunX0xNm6XetEPD4WZ4mGqZQRaeNZ3QcybHXnv+0F0z3o6M5IwiYik6hA 3uihzcRpYVRDF2ffjT3cJarph/pjbX2VuMBPDRguSYE5+b8i188cD1J6RTXhqGNIZDgz0B s/J7hEo27atIk3BRThAQcabwCIUIPKW3P1ghiynhYRyYuhkMsNe25gDQUj/aH4DKzZY33u sDOk95A0S1VZP8u/7Z7fnUm60ofQmKdz6Xws1wcIbiManDxrORZS4DO0Q/yc3wSMb3lXqv 3M2Zurdlqk2CaLQ9bNu8p3IFUo7kmnV+9lplRqFKUCR54mgHl2UPvXvd7/+e6Q== Received: from cell.glebi.us (glebi.us [162.251.186.162]) (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: glebius) by smtp.freebsd.org (Postfix) with ESMTPSA id 4VNHkG1z3qz1CmJ; Mon, 22 Apr 2024 08:00:53 +0000 (UTC) (envelope-from glebius@freebsd.org) Date: Mon, 22 Apr 2024 01:00:50 -0700 From: Gleb Smirnoff To: freebsd-current@freebsd.org, src-committers@freebsd.org Subject: April 2024 stabilization week Message-ID: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi FreeBSD/main users & developers: This is an automated email to inform you that the April 2024 stabilization week started with FreeBSD/main at main-n269602-dd03eafacba9, which was tagged as main-stabweek-2024-Apr. The tag main-stabweek-2024-Apr has been published at https://github.com/glebius/FreeBSD/tags. Those who want to participate in the stabilization week are encouraged to update to the above revision/tag and test their systems. Developers are encouraged to avoid pushing new features to FreeBSD/main, but focus on bugfixes instead. The stabilization week runs up to Friday 18:00 UTC, but if there is consensus that any regressions discovered by participants have been fixed, it will end early. Once that happens, the advisory freeze of FreeBSD/main branch is thawed. -- Gleb Smirnoff From nobody Mon Apr 22 15:35:16 2024 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 4VNTps6D84z5HKnj for ; Mon, 22 Apr 2024 15:35:33 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.ipv6.vt.edu [IPv6:2001:468:c80:a103:2:5000:5555:5555]) (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 4VNTps4Npcz3wwx; Mon, 22 Apr 2024 15:35:33 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Authentication-Results: mx1.freebsd.org; none Received: from smtpclient.apple (unknown [IPv6:2607:b400:24:0:1013:38ba:f6f4:cc9d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id 50FCB47885; Mon, 22 Apr 2024 11:35:27 -0400 (EDT) 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 \(3774.500.171.1.1\)) Subject: Re: Strange network/socket anomalies since about a month From: Paul Mather In-Reply-To: <1fe609f252e7fae6d746530d5035ec0e@Leidinger.net> Date: Mon, 22 Apr 2024 11:35:16 -0400 Cc: Current , Gleb Smirnoff Content-Transfer-Encoding: quoted-printable Message-Id: <55E45C9C-1878-4FAD-B46A-0EA1FFCCAE1D@gromit.dlib.vt.edu> References: <1fe609f252e7fae6d746530d5035ec0e@Leidinger.net> To: Alexander Leidinger X-Mailer: Apple Mail (2.3774.500.171.1.1) 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:1312, ipnet:2001:468:c80::/48, country:US] X-Rspamd-Queue-Id: 4VNTps4Npcz3wwx On Apr 22, 2024, at 3:26=E2=80=AFAM, Alexander Leidinger = wrote: > Hi, >=20 > I see a higher failure rate of socket/network related stuff since a = while. Those failures are transient. Directly executing the same thing = again may or may not result in success/failure. I'm not able to = reproduce this at will. Sometimes they show up. >=20 > Examples: > - poudriere runs with the sccache overlay (like ccache but also works = for rust) sometimes fail to create the communication socket and as such = the build fails. I have 3 different poudriere bulk runs after each other = in my build script, and when the first one fails, the second and third = still run. If the first fails due to the sccache issue, the second and = 3rd may or may not fail. Sometimes the first fails and the rest is ok. = Sometimes all fail, and if I then run one by hand it works (the script = does the same as the manual run, the script is simply a "for type in A B = C; do; poudriere bulk -O sccache -j $type -f ${type}.pkglist; done" = which I execute from the same shell, and the script doesn't do = env-sanityzing). > - A webmail interface (inet / local net -> nginx (rev-proxy) -> nginx = (webmail service) -> php -> imap) sees intermittent issues sometimes. = Opening the same email directly again afterwards normally works. I've = also seen transient issues with pgp signing (webmail interface -> gnupg = / gpg-agent on the server), simply hitting send again after a failure = works fine. >=20 > Gleb, could this be related to the socket stuff you did 2 weeks ago? = My world is from 2024-04-17-112537. I do notice this since at least = then, but I'm not sure if they where there before that and I simply = didn't notice them. They are surely "new recently", that amount of = issues I haven's seen in January. The last two updates of current I did = before the last one where on 2024-03-31-120210 and 2024-04-08-112551. >=20 > I could also imagine that some memory related transient failure could = cause this, but with >3 GB free I do not expect this. Important here may = be that I have https://reviews.freebsd.org/D40575 in my tree, which is = memory related, but it's only a metric to quantify memory fragmentation. >=20 > Any ideas how to track this down more easily than running the entire = poudriere in ktrace (e.g. a hint/script which dtrace probes to use)? No answers, I'm afraid, just a "me too." I have the same problem as you describe when using = ports-mgmt/sccache-overlay when building packages with Poudriere. In my = case, I'm using FreeBSD 14-STABLE (stable/14-13952fbca). I actually stopped using ports-mgmt/sccache-overlay because it got to = the point where it didn't work more often than it did. Then, a few = months ago, I decided to start using it again on a whim and it worked = reliably for me. Then, starting a few weeks ago, it has reverted to the = behaviour you describe above. It is not as bad right now as it got when = I quit using it. Now, sometimes it will fail, but it will succeed when = re-running a "poudriere bulk" run. I'd love it to go back to when it was working 100% of the time. Cheers, Paul. From nobody Mon Apr 22 16:12:49 2024 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 4VNVfC633Zz5HPBl for ; Mon, 22 Apr 2024 16:13:07 +0000 (UTC) (envelope-from glebius@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 4VNVfC4TM3z47G3; Mon, 22 Apr 2024 16:13:07 +0000 (UTC) (envelope-from glebius@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1713802387; 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=YY3dC++mwrwwmO+turu6fdwVxxIBSyNkib5wloCJ+2o=; b=aw+N8xneC+8gtyjs+5Wir9zb22LRfIUTrluUIWxZGqBn3POAyICtbVg00ek4gBG4FB82Bf TDkEML/3+iAtO8/xScgeMYDYyt4zC2fYY14cLhErlB3IuQJ3ae+2fZDBjkijqHc9quuEMR exDKvKmP39Zk3ESyLQls2r46I+B1jZ64LH8SWVQHoYK1VZmWPktjQSnR7cZpgPYWWlnxkm +RJuulwlpVSRujlmQx7SNYQLS8KvwsZhPSaoZCjzsYuisxwlBEDLq/VQTXAz55uU/Eym4a UEA1EQ9zoW0wb/d+8o0CdObZTdnfnNk+xmPlN/4mxRNqUXspdwCb0dbulM91dA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1713802387; a=rsa-sha256; cv=none; b=UakxYu9DYBPNmHJjgsBZTmLA7MvC/GGKJPB+B97RyvlCEwSXrRhAJnLCFvNMVSDmsDvAWJ NEwlrzlh+BmZ7KfocC/dDlxCPPe99xdoKunt1BJ3bB5eodlPRJXOzq8DwY18OBzgKEIRPV MG2q1+FEEVTcyUR6NKPkh5VD39/1+5O7JNyRoYqj+F+zNR0NBRLi1V7G0iM0ZBjECDzHeO 4sI/jqfSHVfrn+hv1r9b376vxkyjflqDnJ9ncfNiUZ4eWnuAl9OPWLYwdqS1hcVGSOO0tf rfPhhZWN+rd6yFrXZ62VEivuI4yEoM2BbFoGrqWpuzsJTBIeGfxtlcEDn1bORg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1713802387; 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=YY3dC++mwrwwmO+turu6fdwVxxIBSyNkib5wloCJ+2o=; b=CO6xBHwgjvrQZHmZkrDDPMkdTcV4EFwFbdMwAxeMJALMU/7J/cuZL20sl639lboB2/X2GZ 7F+o1rWlsM8lXK+jgjCBplZ+25qYUdGVw/yzUGp60oJU2B3PN3TWYEajGI3bBJp7H2fu0+ GfJhF8G9W2R/RmpC7Xa/F4XTVlxmvnvvS4C6qWoHG2Dw/LOy+GKKTIGjnReniahkCufpNE JLKc8p5D/95lqHFZX5Y+z17fHx2CWqQ6YNiHYOO6Anl87s3dnDATii2m6Ehsp+aBtMH9og B+RWnxGxv8DPjSMVACBu3BsLtagXioqo/d4yjYMQIDN2ef36cESCvZteYxoyfg== Received: from cell.glebi.us (unknown [162.251.186.162]) (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: glebius) by smtp.freebsd.org (Postfix) with ESMTPSA id 4VNVfC18nTz1NPf; Mon, 22 Apr 2024 16:13:07 +0000 (UTC) (envelope-from glebius@freebsd.org) Date: Mon, 22 Apr 2024 09:12:49 -0700 From: Gleb Smirnoff To: Alexander Leidinger Cc: Current Subject: Re: Strange network/socket anomalies since about a month Message-ID: References: <1fe609f252e7fae6d746530d5035ec0e@Leidinger.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 Content-Disposition: inline In-Reply-To: <1fe609f252e7fae6d746530d5035ec0e@Leidinger.net> Alexander, On Mon, Apr 22, 2024 at 09:26:59AM +0200, Alexander Leidinger wrote: A> I see a higher failure rate of socket/network related stuff since a while. A> Those failures are transient. Directly executing the same thing again may A> or may not result in success/failure. I'm not able to reproduce this at A> will. Sometimes they show up. A> A> Examples: A> - poudriere runs with the sccache overlay (like ccache but also works for A> rust) sometimes fail to create the communication socket and as such the A> build fails. I have 3 different poudriere bulk runs after each other in my A> build script, and when the first one fails, the second and third still run. A> If the first fails due to the sccache issue, the second and 3rd may or may A> not fail. Sometimes the first fails and the rest is ok. Sometimes all fail, A> and if I then run one by hand it works (the script does the same as the A> manual run, the script is simply a "for type in A B C; do; poudriere bulk A> -O sccache -j $type -f ${type}.pkglist; done" which I execute from the A> same shell, and the script doesn't do env-sanityzing). A> - A webmail interface (inet / local net -> nginx (rev-proxy) -> nginx A> (webmail service) -> php -> imap) sees intermittent issues sometimes. A> Opening the same email directly again afterwards normally works. I've also A> seen transient issues with pgp signing (webmail interface -> gnupg / A> gpg-agent on the server), simply hitting send again after a failure works A> fine. A> A> Gleb, could this be related to the socket stuff you did 2 weeks ago? My A> world is from 2024-04-17-112537. I do notice this since at least then, but A> I'm not sure if they where there before that and I simply didn't notice A> them. They are surely "new recently", that amount of issues I haven's seen A> in January. The last two updates of current I did before the last one where A> on 2024-03-31-120210 and 2024-04-08-112551. The stuff I pushed 2 weeks ago was a large rewrite of unix/stream, but that was reverted as it appears needs more work wrt to aio(4), nfs/rpc and also appeared that sendfile(2) over unix(4) has some non-zero use. There were several preparatory commits that were not reverted and one of them had a bug. The bug manifested itself as failure to send(2) zero bytes over unix/stream. It was fixed with e6a4b57239dafc6c944473326891d46d966c0264. Can you please check you have this revision? Other than that there are no known bugs left. A> I could also imagine that some memory related transient failure could cause A> this, but with >3 GB free I do not expect this. Important here may be that A> I have https://reviews.freebsd.org/D40575 in my tree, which is memory A> related, but it's only a metric to quantify memory fragmentation. A> A> Any ideas how to track this down more easily than running the entire A> poudriere in ktrace (e.g. a hint/script which dtrace probes to use)? I don't have any better idea than ktrace over failing application. Yep, I understand that poudriere will produce a lot. But first we need to determine what syscall fails and on what type of socket. After that we can scope down to using dtrace on very particular functions. -- Gleb Smirnoff From nobody Tue Apr 23 06:08:10 2024 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 4VNsB10zzfz5JXK1 for ; Tue, 23 Apr 2024 06:08:25 +0000 (UTC) (envelope-from hiroo@oikumene.net) Received: from barleycorn.oikumene.net (tk2-231-25124.vs.sakura.ne.jp [160.16.110.128]) (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 4VNs9z4tZcz4rBL; Tue, 23 Apr 2024 06:08:22 +0000 (UTC) (envelope-from hiroo@oikumene.net) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hiroo@oikumene.net designates 160.16.110.128 as permitted sender) smtp.mailfrom=hiroo@oikumene.net Received: from nowhere.oikumene.ukehi.net (KD059129091046.ppp-bb.dion.ne.jp [59.129.91.46]) by barleycorn.oikumene.net (Postfix) with ESMTPSA id 866DF61F8E; Tue, 23 Apr 2024 15:08:12 +0900 (JST) Received: from nowhere.oikumene.ukehi.net ([IPv6:240f:3f:802f:2:82c1:6eff:fef8:b41e]) by nowhere.oikumene.ukehi.net (8.18.1/8.18.1) with ESMTP id 43N68Anj044938; Tue, 23 Apr 2024 15:08:11 +0900 (JST) (envelope-from hiroo@oikumene.net) X-Authentication-Warning: nowhere.oikumene.ukehi.net: Host [IPv6:240f:3f:802f:2:82c1:6eff:fef8:b41e] claimed to be nowhere.oikumene.ukehi.net Date: Tue, 23 Apr 2024 15:08:10 +0900 From: Hiroo Ono To: Dimitry Andric Cc: freebsd-current Subject: Re: llvm and Undefined symbols: ___truncsfbf2 problem Message-ID: <20240423150810.6e00b654@nowhere.oikumene.ukehi.net> In-Reply-To: References: <20240411220735.069cb283@nowhere.oikumene.ukehi.net> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.41; amd64-portbld-freebsd14.0) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.17 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.87)[-0.871]; R_SPF_ALLOW(-0.20)[+ip4:160.16.110.128]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_TWO(0.00)[2]; HAS_XAW(0.00)[]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:9370, ipnet:160.16.0.0/17, country:JP]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[oikumene.net]; RCVD_COUNT_TWO(0.00)[2]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_TRACE(0.00)[0:+] X-Rspamd-Queue-Id: 4VNs9z4tZcz4rBL Thank you. I updated my current to recent current and confirmed that julia 1.11.0 beta1 builds and runs with the system clang (18.1.4). On Thu, 18 Apr 2024 00:36:28 +0200 Dimitry Andric wrote: > On 11 Apr 2024, at 15:07, Hiroo Ono wrote: > > > > Hello, > > > > I am trying to update the lang/julia port to 1.11.0 (currently > > still in beta 1). I seem to ran across this problem initially > > reported on MacOS. https://github.com/JuliaLang/julia/issues/52067 > > > > The llvm team seems to have patched this problem only for Darwin. > > https://github.com/llvm/llvm-project/pull/84192 > > > > I think the solution is also needed for FreeBSD, but should I > > report it directly to llvm team or report here or to FreeBSD > > bugzilla and ask toolchain maintainer of FreeBSD to report > > upstream? > > The __bf16 type is only available on some architectures, and only > supported by relatively recent compiler versions, in combination with > some runtime support (i.e. compiler-rt or libgcc). > > Approximately: it is available on aarch64, amd64, arm (with fp), i386 > (with sse2) and riscv. And it is supported by clang 15 and later > (though not for riscv, which requires clang 18), and gcc 13 and later. > > However, the runtime support in FreeBSD was only added with the recent > merge of llvm 18. The necessary library functions (truncdfbf2 and > truncsfbf2) are now in compiler-rt. > > -Dimitry > > From nobody Tue Apr 23 17:46:50 2024 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 4VP8gy1NcKz5HjWc for ; Tue, 23 Apr 2024 17:46:54 +0000 (UTC) (envelope-from glebius@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 4VP8gx744Fz4MY8; Tue, 23 Apr 2024 17:46:53 +0000 (UTC) (envelope-from glebius@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1713894414; 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=an57/xSOCahY5nzqAsxUawBWUrejpEcRKW++wC4Hzww=; b=Bizmn4P30lPbo+jMyL5omOrGxUV+SUZUOG/bYCB/9tnu4x13uD/R+LNe9PW1jhG969T0t2 HRBdgmCZtEnxn+X858h5EVfxilaO803NLi6udcy1swVZQrz1mj9kSAkCbVLFXtP1+1vxd+ OAeeyb+Frabi4RhonnIuwnVv/g+WkSmm/ajc3F55OTwtYeR/425mmGdYwgRpiLk3slz3Ar 96G5WBVw3uQc0VK0RUTb69LEzz60tbl1Va9hBarjPGZQItLXnBu5ysq6jhwHTfuiKaCNYs GUvG2ljMzCBRMv2LG1/nZllHqL8VzX3uYtlofFmrWZIifwAW0ftKJ1/qbzwLCg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1713894414; a=rsa-sha256; cv=none; b=pdHHJJ2rQAk5YAptjbp5WFHF+Lj8whraOSQZji18UJ0J/gujxUMC30Xk1KjE96/Pd7oxBb S3vQiF9/3UyyFeUvVtzjbzS/ETkeXdo1l98ppIt0OjQyiNICKA1ozPQ7DTVFNcNVkgj1DI k4e+oEcTgC85wA2Gu9ajxvuQhB8O4VPGoKYR4O7b5dQhAPnnX9t75LBGLReZ0NtYhuFhQl GvLQinkAqVzvw1AaHbWzWMQ1oxvdIJJGpcbp4hZ+Jh0+rSSovuntzNiNtBzsbfCwmLg71K 7dcUCQQwbvTeccEEC7si3EhYUig9cmkS/CVN4wUOZGEEl/3T9I2NpoQh4v8woA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1713894414; 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=an57/xSOCahY5nzqAsxUawBWUrejpEcRKW++wC4Hzww=; b=Hun++snSvWw76HDPpRigxtbWoSoGcC/DKRwApWwHC6/a/FG0t2RwTwGcBiTZhqpc0OBt56 ap5jQ9ghYg6t94vOWE5xtT0RlcI7+fcezBTAfgaphEnl1KSrhm2LZ+Th1y46FSXLOoLqIQ zM4eHsdJt+VMFg5J6kB95MNGKA840OC5/F3WQsdioNzCVlyc7anwGW7bdq+BW/yAdIIFrv v9ybO7heotMNixdwx0x9nxe7Adrk3v9wjtAGe35/1sL81wdhCUFXx5z8qgGjtGbmHATZ6O UQR+6amthTl7qAp0aPh3XEAnflgg1Hs5YVReoOs17/KAk0wpDSSkY7LnKn0f0Q== Received: from cell.glebi.us (glebi.us [162.251.186.162]) (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: glebius) by smtp.freebsd.org (Postfix) with ESMTPSA id 4VP8gx2f3pzh3v; Tue, 23 Apr 2024 17:46:53 +0000 (UTC) (envelope-from glebius@freebsd.org) Date: Tue, 23 Apr 2024 10:46:50 -0700 From: Gleb Smirnoff To: freebsd-current@freebsd.org, src-committers@freebsd.org Cc: mav@freebsd.org, mm@freebsd.org Subject: Re: April 2024 stabilization week 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: Hi FreeBSD/main users & developers, On Mon, Apr 22, 2024 at 01:00:50AM -0700, Gleb Smirnoff wrote: T> This is an automated email to inform you that the April 2024 stabilization week T> started with FreeBSD/main at main-n269602-dd03eafacba9, which was tagged as T> main-stabweek-2024-Apr. T> T> The tag main-stabweek-2024-Apr has been published at T> https://github.com/glebius/FreeBSD/tags. Those who want to participate T> in the stabilization week are encouraged to update to the above T> revision/tag and test their systems. * Netflix testing didn't discover any stability issues with main-n269602-dd03eafacba9. We are still running the performance test, but preliminary results are that everything is fine. * My personal desktop/server experience with the tag neither has any problems. Feel free to reply with your reports if you participated in the testing, too. In bugzilla we have this submission, which looks important: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278494 I want to hear from Alexander and Martin before thawing the advisory freeze. Don't want to declare the tag good if some ZFS systems fail to boot after upgrade. -- Gleb Smirnoff From nobody Tue Apr 23 18:12:41 2024 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 4VP9G00vBTz5Hlhg for ; Tue, 23 Apr 2024 18:12:56 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-25.consmr.mail.gq1.yahoo.com (sonic303-25.consmr.mail.gq1.yahoo.com [98.137.64.206]) (using TLSv1.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 4VP9Fz11Dcz4QZR for ; Tue, 23 Apr 2024 18:12:55 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=IMX0ikFl; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1713895972; bh=1QqVoW/HiKSeOBT+tGewaznvWF8ocoPAP3ViORmWLOo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=IMX0ikFlYOAguGtgcKcE+wvUZmEuahoeR2xsHOuizRlvXc/ctgP/U+cJfZzC6kKcbgkHXuHxct3YviNsV7kiYpz/N5U0r/0/Izay1E0zsT+7lGyu1j5XZu7P4SSSGQCwlBDUrxfkfYRo70jsEqijH4qiXDSzWg1mXdzzYPrKyif0cWuXh0Uac6WZ6N3TMcJQ3jtYYsADojVkalpVuUKmeqDySOnCv4+2/ubE5udiSD9HBwMPi/XNTnRHCK+vLf1EWrEbw29o09LKRy3Wa1vUgWT9ZPO3SoaQYRt7qL4Dm6MhvbaPPiQZ5BXJGsU3/5+rVmIdkiNaixM9hnUa7A/niQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1713895972; bh=ieV6L+satb/q/TnDDvFzVzLBitXZn7885zdtpGmqirx=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=N7i0woH2CvyFEahezpYvAGKMlJH77ynUavqNAl84W/ypXa/WYuKb849+PhjjUtSjuiGpwgQ8oVDJs6ZJDbZlWr9h/rYI6WPO85JEbBn5+USW89CWdQn5ElopkYwWFRI0d9LdkSgLEtl/Rn5hLQzz4P0SiOEFxA6BuevoQSBft6gokoREw44+C+pTD6b9lYYC13SUBCeN/+z/hoA3IQgyu2c6EwBl8/ETJVIo1Q7LoN6kQ9SL4WJYrHPEdsZPuHOEVETZTY1MDgO7SYrlGQIRM9QbpLsKW+MuvbytqzAM8wRE/u981HfLpprPM9Z6IU1aNeuMpeyRuTqgL7UpPkcxJA== X-YMail-OSG: wpWMcKIVM1mU98TGke1h6tEkVvzwjeIIeR5Ia5ter4zRpTsApNqBDVZk5Z0BMal tRCHJsWmDFzvEUp1r0UEQnmo2Xx_pOIeuE8SZ3UZOBZDu5jWzp7RwMHKaI4xrX5ZDw333VluArYK L.a6NkbVl3mFCrONRQoDwyHjfbYxjIaxktCNf5If_IfRHOrdlKfrsPqZ8CHcKxvN.7y_zKdMrTrT 2S7OzArWPz5QO4Bn3WNCHqiVMq0BwYtbb2pZ0yN7d_yUwxMaOiNUcq7d3TOD46FIwGQhddH4rlM1 .YO.A_gUMvNOeQeiZNmMhVfjvsEmtFaVt_xgZ4qh6nL8xcPhQFyeihDG2F_gIyhtreTDOPMd3y5J 88y4EE09plyBS8a1WNmgwQH_Wr0lVq_nHNhoorkOXKTG9jkc7F_rPOvqJMk.AlEqObn7umJ25sYQ Z9kr70sXsJZkX6HjH9mufGVa2UPwTN611snsJQzUaU5WUZxPK7lsNVoVYWnSk5Zv0fO3EDkN1L0P seoHYTRK8AGHvlrKFdpHRwzPxwREeiKWeThtLNwhUPsOSP1WcjQWo2afp_MM15fJr5sOjkhl__iD .xn1fpv84Yx5kf8V87ocPCE7YB_cCF6TwYTCl01YsFtQ2mhSh2v7LmwkIH_JqsKK309CGEAMFSue rEcfTgvJ08.Mi3yL72EjpjizK_Ufe9gANx85W7FyI9kw3DYwH_ioRLWQ0fIEyxCYnx2mgJroZfh5 VEZGK48t_pQ37VxnxHK3mqLiPGciZ3EXSNdo7TxwnVwv_mP0SU0IWEt7jDnNk0R9k87MU3HaVAb6 Ypof1MyNydqXn9jim6kvjKKNMTa1WRVsepLf4_QlWnS0zFXJeae913zfsIbHP52HF1pG3jpz2ZgK zy6T4miJXgn1vgJOCAcN_AYxQmEQn__aOe2zuD2aU_8_ODjOxCRkhP2vrEdXDaFhh1mcQR2gKOmG 1bLWKcfKAYfg528bJu9WeWSzWNv1WGhpt3yJsyrgKDUeML6qpjay1e35LCLhH9LwVtSpRfbvToU6 JOcsDKqAIhr8Pa9fo72mklB78YoV4s_g8y6qS41fvlAJZpRraOJgHmplZYazuz72NRWJ2pE0e16G 0eev_iQrgkqJcgizkO0J1J6NbtES4UbCZMSmm0vr4PEHzuZQEMbywnWLrhKIX2t2DH9Yt5YyKi.e CihHtvb0bsMhTpTZ1Kn_uu26hYwuuwFYL35_sgUK_.QCNtGk6poCf3OHX_iRZWkbqN8.mguNgPTo rMa8GxkgffXweB0nApcr26WaVYoBB5THGuAF442LswDegfQJKrSc6IET.8pFDOf_M8tr2qy27efl S0KuTELp0Id9XTvS068xOROqWEga.rF9xw.MPcLz48Px.GcHNTXMoMYlQfDjaf6LDi77b1mN10xh yUSy4AQQ4yKDDuuT5VM_it2iMkq6MyXEQ3mXuNRyRL8AS3iS4N_Qt3EIsyLAkPlne2s6TmEO.egb .n6uMlvQW_bcUj4HyU_KXluRqrlR2B0TzpbqvLLKBWZjL1fWwZstGL52HGStC0LnD91vUt3KLiGS wKRxi2qWxdHsI.XlRm30Nt.ZDIEWYW_AlnsXiCb1jN6jswJV5oygwGoRI.LScRUXKwk5J3TBXACp D6MW5cZN4KXSkvU95bfC4pb4ge_KI2pphE9UGZFqpanEq_69Nd3q_Jv.vGy36xz5Pq2Mt5cJVKMm qt2nBxvPr1kBvW6aK_G2SAM.KhTuUw6qmCddksdACHlfi6t8JfNn.vQAjghFtX47wVMovmhwSbWg r9PXeEIpOa.rS.oeP823_rDi0k5MqZfU_Cezq0_GyEEvFJweQm8E9oc4LQFEDv79b.VN7ib8qAdp Ztdyjg6JUvzUdBxtaE0TczcvGmwdf6htPYOYjL7Q4.giWla.n_htDBgfRgbldjEkrtIDFIHJkyRk i1NUbgXyyxsZmuEhncaFt28ktB1F7O9UxFBv4QU5wG2VYNDQFGcU4wTtn5DtZLpaObXTqYVY.nRS 3cl5ldzbz2V7no2NQFRrDR6R06S.PQpeE5UD21oqjF4qfJdSPb1GUHwYipPqnCsBps_Pwkq.I.GL Lt3If9N0SpL7SFMu1MfgHphXnml07gTxxfbeH0IH0fyaOx4SvIIxSdl00LMJxAX4370_JdmiS.y8 N0NTzdHzD52mxQiWkEQc3SZNo4jBCe8YyBGFtTVDz_8W8pFKMcmFgPho0V7Czu9ito72VGEh2GqZ xC2OddXiqb41VmmY6NnDglF3WrtYoT6LanmwaNC_HwAkD0fnnhsVh02ZE8BSGOjDwz.6cuNABGmo 8fw-- X-Sonic-MF: X-Sonic-ID: 8c57b3ee-a20e-4a95-931f-22bf8d8c308d Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Tue, 23 Apr 2024 18:12:52 +0000 Received: by hermes--production-gq1-59c575df44-84j4c (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID aa3330d5a1e179b51ac22932175f011f; Tue, 23 Apr 2024 18:12:51 +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 \(3774.500.171.1.1\)) Subject: Re: pkg server for current/arm64 stopped ? [main-armv7 on ampere2, elapsed so far: 651:21:56] From: Mark Millard In-Reply-To: Date: Tue, 23 Apr 2024 11:12:41 -0700 Cc: void , FreeBSD Mailing List , Current FreeBSD Content-Transfer-Encoding: quoted-printable Message-Id: References: <03736C90-EE54-47B3-AEA7-ED1AC0343B4B.ref@yahoo.com> <03736C90-EE54-47B3-AEA7-ED1AC0343B4B@yahoo.com> To: Philip Paeps X-Mailer: Apple Mail (2.3774.500.171.1.1) X-Spamd-Bar: --- 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_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_CC(0.00)[f-m.fm,freebsd.org]; TO_DN_ALL(0.00)[]; ARC_NA(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; DKIM_TRACE(0.00)[yahoo.com:+]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.206:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.206:from]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[] X-Rspamd-Queue-Id: 4VP9Fz11Dcz4QZR On Apr 19, 2024, at 07:16, Philip Paeps wrote: > On 2024-04-18 23:02:30 (+0800), Mark Millard wrote: >=20 >> void wrote on >> Date: Thu, 18 Apr 2024 14:08:36 UTC : >>=20 >>> Not sure where to post this.. >>>=20 >>> The last bulk build for arm64 appears to have happened around >>> mid-March on ampere2. Is it broken? >>=20 >> main-armv7 building is broken and the last completed build >> was the one started on Mon, 19 Feb 2024 12:32:10 GMT. It >> gets stuck making no progress until manually forced to stop, >> which leads to huge elapsed times for the incomplete builds: >>=20 >> pd5512ae7b8c6_s75464941dc 34472 12282 (+9196) 107 (+77) 4753 = (+2247) 1390 (+529) 15940 parallel_build: Fri, 22 Mar 2024 11:05:01 GMT = 651:21:56 >>=20 >> p43e3af5f5763_sf5f08e41aa 19809 5919 (+3126) 137 (+100) 5363 = (+2741) 1395 (+522) 6995 parallel_build: Wed, 28 Feb 2024 15:46:14 GMT = 359:42:14 ampere2 >>=20 >> ampere2 alternates between trying to build main-arm64 and main-armv7, = so main-armv7 being stuck blocks main-arm64 from building. >>=20 >> One can see that all 13 job ID's show over 570 hours: >>=20 >> = http://ampere2.nyi.freebsd.org/build.html?mastername=3Dmain-armv7-default&= build=3Dpd5512ae7b8c6_s75464941dc >>=20 >> It is not random which packages are building when this happens. = Compare: >>=20 >> = http://ampere2.nyi.freebsd.org/build.html?mastername=3Dmain-armv7-default&= build=3Dp43e3af5f5763_sf5f08e41aa >>=20 >> By contrast, the 19 Feb 2024 from-scratch (full) build worked: >>=20 >> = http://ampere2.nyi.freebsd.org/build.html?mastername=3Dmain-armv7-default&= build=3Dpe9c9c73181b5_sbd45bbe440 >>=20 >> My guess is that FreeBSD has something that broken after bd45bbe440 >> that was broken as of f5f08e41aa and was still broken at 75464941dc . >=20 > I'll kill the build on ampere2 again. Thanks for the nudge. >=20 > We don't really have good monitoring for this. Also: builds should = time out after 36 hours. The fact that this one does not is a bug in = itself. >=20 > Philip [hat: clusteradm] I'll note that I've never managed to replicate the problem for building for armv7 on aarch64. But my context never has the likes of: QUOTE Host OSVERSION: 1500006 Jail OSVERSION: 1500015 . . . !!! Jail is newer than host. (Jail: 1500015, Host: 1500006) !!! !!! This is not supported. !!! !!! Host kernel must be same or newer than jail. !!! !!! Expect build failures. !!! END QUOTE but always has the two OSVERSION's the same, such as: Host OSVERSION: 1500015 Jail OSVERSION: 1500015 or, recently, Host OSVERSION: 1500018 Jail OSVERSION: 1500018 My bulk runs do go through the sequence where the hangups have repeated for main-armv7 on ampere2. I wonder what would happen if "Host OSVERSION" was updated (modernized) to match the modern "Jail OSVERSION" that would be used? =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Apr 24 00:37:05 2024 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 4VPKnJ0d8Xz5JPW3 for ; Wed, 24 Apr 2024 00:37:08 +0000 (UTC) (envelope-from glebius@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 4VPKnJ04QRz42gy; Wed, 24 Apr 2024 00:37:08 +0000 (UTC) (envelope-from glebius@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1713919028; 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=oBEXz0h5yK5KhmR9iW+mK3TwzdgOoeQ2dDqHcxMd3Vo=; b=OxgwnkwYIvbH21dsIrDIFDu+VVKkomSicHXXjK5SOAQLE/fWeaP42zzHgavEtyGB1mCPJY Tw1fiP1kGeoSK7wDGtzowi7ByYbjJZhe0mQpVthkDuOsuZbKQG4WJuuxjf4cHLS/h+hJKe niuWbB4DwyG7ggT1RRMZ3vNaTOl1t++lSRAXguyHpCnFKqs5BCV0ptBwnnLzw4GUAAGiBP 6134plE25kEDKsTWF6ab4SCh4S25IOlubkkk589VsVaOWhLPhj8ekVudfO4gZRFYfPQPGu dzqSKwiZJT941yBQQmQPGoEYeKLKuLYmxxifdRWuloOoOfvue38cjxWMpfoIAQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1713919028; a=rsa-sha256; cv=none; b=MYA1CuLUQEHBdO2qLVwaFn5GWQuzIbYv7MDNz35kAqc7sX5QDDUDGXwJ7KY7czAYne7E8k MN8jLaTDFBY8BUzZkwd3LG6hASh9xuO6vQD92pmIGfAkfmM4Yg/0lc2D9fcjuUsc81yZM4 6SVGs33KlykrSf1r4NIEJKmYBky2Y3G8RCZg7mqxSPC3y3th0LZ45PA7Yx3B5DAd5u7X1f zkiCVei9u+zOfZikINwilfiN9dz9XVsJpZrbSHHvB5CrGo74/W3CFIdVuh0YbcXpVB/A30 eEbM4WywOKsIWfNFo/EAcjjU6LACJqIaAIWpGr5VlKHkyvKGYCivBnnymbGdnQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1713919028; 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=oBEXz0h5yK5KhmR9iW+mK3TwzdgOoeQ2dDqHcxMd3Vo=; b=kCZ/BW2xQsw3J8oUelgyFFH+4u+VAOixbzCrgyPkCnx/jCJF4jFl31ZIjD9ALMJyme2kSZ n+9VnYsl8FNZRfHZoTK2NgoaGaMx0au0ielHnRv3j4WM6WvDq+UG1IBSRzUse9XKykTxVu UoEkjLacm3ph0YdpU1COHcU+RcwI42FxsgcHmuxXjNwAfn4JI8V5hMYBogYV0UfV4AaRtr qg1SF9S9nBVNUE9NXTtoTRrTi6hsr2pD9vQ1x8043zyfgY3ddwpWTrGFySq1N8S1S1GfM1 LotuHu+x1OweADHAoMYBaXw2L18igR2hBvR5aCtOXOhinNqfNKBlGZpr7uqeOw== Received: from cell.glebi.us (glebi.us [162.251.186.162]) (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: glebius) by smtp.freebsd.org (Postfix) with ESMTPSA id 4VPKnH2t1gz14GV; Wed, 24 Apr 2024 00:37:07 +0000 (UTC) (envelope-from glebius@freebsd.org) Date: Tue, 23 Apr 2024 17:37:05 -0700 From: Gleb Smirnoff To: freebsd-current@freebsd.org, src-committers@freebsd.org Cc: mav@freebsd.org, mm@freebsd.org Subject: Re: April 2024 stabilization week 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: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="t9ZbrcKzmf+wQKaG" Content-Disposition: inline In-Reply-To: --t9ZbrcKzmf+wQKaG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi FreeBSD/main users & developers, this stabilization week [likely final] status update: * Netflix testing didn't discover any stability issues with main-n269602-dd03eafacba9. * Netflix testing didn't discover any substantial performance degradations. The data is still being analyzed though. * A regression with ZFS reported in=20 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D278494 has been addressed by ZFS 9f83eec03904b18e052fbe2c66542bd47254cf57. * An old (more than a month old) regression has been identified with accept_filter(9). Fixed by a8acc2bf5699556946dda2a37589d3c3bd9762c6. Since FreeBSD/main has been pushed with several non-documentation, non-a- trivial-bugfix commits during the days of the stabilization week, I can't guarantee that the above testing results are applicable to the current stat= e of FreeBSD/main. That's why I created a temporary cherry-picking branch stabweek-2024-Apr that is published at https://github.com/glebius/FreeBSD.g= it. Users of FreeBSD/main are adviced with the following choices: - Pull up FreeBSD/main up to a8acc2bf5699556946dda2a37589d3c3bd9762c6 and u= se it as your stabilization point. There is tiny risk of untested changes added recently. - Pull stabweek-2024-Apr from https://github.com/glebius/FreeBSD.git. - Craft stabweek-2024-Apr yourself: # git checkout -b stabweek-2024-Apr dd03eafacba962c9dcec929c3ed9d63e7c43d= a3a # git cherry-pick -x --strategy=3Dsubtree -Xsubtree=3Dsys/contrib/openzfs= 9f83eec03904b18e052fbe2c66542bd47254cf57 # git cherry-pick -x a8acc2bf5699556946dda2a37589d3c3bd9762c6 I'm planning to end the advisory freeze on the main branch Wednesday morning at 8:00 UTC, unless somebody opposes that with a valid reason, e.g. a regression that I missed. --=20 Gleb Smirnoff --t9ZbrcKzmf+wQKaG Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQT+rgtjiRzq3LbQ3Nn+/1jAXQXMIgUCZihUJQAKCRD+/1jAXQXM IkZNAP9Ol3kzq5VWcHQP8/NxxEKjGTUdhMUDdzZfWiMFQvJOIAEA1tgZvynpVTaH o3qPb5oDtme9Sv9GOyysLsc9uyomgQk= =+zKg -----END PGP SIGNATURE----- --t9ZbrcKzmf+wQKaG-- From nobody Wed Apr 24 04:30:41 2024 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 4VPQyt2nx1z5JkjC; Wed, 24 Apr 2024 04:30:46 +0000 (UTC) (envelope-from philip@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 4VPQyt1kdBz4Pct; Wed, 24 Apr 2024 04:30:46 +0000 (UTC) (envelope-from philip@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1713933046; 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=jl8lMIN+aSxpWOmEo+9MvQAC+650q4O3M1+hwPe2JGk=; b=NzpWMljv8EkQ6/XpG7glRgZ1V5sVNa/PZybbm9bpBnFgxhSFcBQ/8rAp+yW+JDLcEU+eGo Bz99H/G2tdNU5jxBytiAn5jBkTdnD/OmgX+h156Vk88BO9ZtBIQuaVf7Xez6XfSItfo8Us /Tzm8BAZmTc5bdf7JZMOUzklz1OvJ+YcUByNeQiuQV/l9x3lRoTiQkCei+dH7r/44SrNSu n5z4sUSe/TDw4JtHkgUWyELah0kfv6x4yCObIRKVYUaMIE2t2d7Dr4RVqXtykVTpyKw1FC Gd1g2RB/cqP6JuPG2xVFw78X97CKetnbH+ExpfuukhJECsXyfj4sfdjSVFaV7Q== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1713933046; a=rsa-sha256; cv=none; b=sNI6GWzejqZvE3n71N+F5Q4d3KrVzQzVF1/gNKqa5bUrMVxYVzHfsxLoeH29cnzR2L9VA4 MEYmzd1OgMRL2l2oPU3o/awdQs9mtIVBAa7/pQbYHNHm5/t0kJ+kETbuBTahGgBGS585P9 jq4WBwY1a5kEP35YWA4tpmA/vBQX9NADLrsRylgAHTjEunwpxDqB1FxSVSJyMsebPvecKz 0JPWIzkn5xWa7eWjKhML8TzIaugju5kAFCKOAsKvQlf/y3UZVLQBDI4KHsVV5pLQHtSj+T tjDC5FBY+nhII0Vv5lPRi63YH7BakAtNmr9Tz9kgxuwerMeBTUPFf42GvrrfoA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1713933046; 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=jl8lMIN+aSxpWOmEo+9MvQAC+650q4O3M1+hwPe2JGk=; b=XqfFyoz566N59sbM4V5wkAqjDrM2uYSaLWAvedtcY4lim1Yd7dUEeLwSrwCy4/NaIT2r0g S6htHn/QrnIqODNtIj41YARV77cure4O+wxF7o4Z8IcVV5CRT+8fSDFdZFBLIIpAvQ2+Fq cMEG8m+GtyJK656s8K5+Wfi5TJgImKrtccCbBnuRub8myx3gQ8QXJFQe73dilWNiYuLEIK 0CszhRV8ZCri0XgpklfUADWWJOCbkboeNSh3EzKmyQRwHVDut6NCe1O77XOrY5lxCSUOSA fAxJKdON2g0xssxDrgEX+jD2+NCvtWa8Sk28eM54baLBqnLYPujGy1sk8Cz9xw== Received: from fauth1-smtp.messagingengine.com (fauth1-smtp.messagingengine.com [103.168.172.200]) (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: philip/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4VPQyt12Scz18G6; Wed, 24 Apr 2024 04:30:46 +0000 (UTC) (envelope-from philip@freebsd.org) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailfauth.nyi.internal (Postfix) with ESMTP id F2B401200043; Wed, 24 Apr 2024 00:30:45 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Wed, 24 Apr 2024 00:30:45 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrudelvddgjeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffokfgjfhggtgfgsehtqhhmtdertddtnecuhfhrohhmpefrhhhi lhhiphcurfgrvghpshcuoehphhhilhhiphesfhhrvggvsghsugdrohhrgheqnecuggftrf grthhtvghrnhepjedukeffgfffkeejfffgfefgledthefhffeggeevgeevhedvheegtddu vdetkeeinecuffhomhgrihhnpehfrhgvvggsshgurdhorhhgnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepphhhihhlihhpodhmvghsmhhtphgr uhhthhhpvghrshhonhgrlhhithihqdduudeiiedviedvgeekqddvfeehudektddtkedqph hhihhlihhppeepfhhrvggvsghsugdrohhrghesthhrohhusghlvgdrihhs X-ME-Proxy: Feedback-ID: ia691475d:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 24 Apr 2024 00:30:43 -0400 (EDT) From: Philip Paeps To: Mark Millard Cc: void , FreeBSD Mailing List , Current FreeBSD Subject: Re: pkg server for current/arm64 stopped ? [main-armv7 on ampere2, elapsed so far: 651:21:56] Date: Wed, 24 Apr 2024 12:30:41 +0800 X-Mailer: MailMate (1.14r6028) Message-ID: <6958AD93-6EDD-4D08-B446-63A9999D200A@freebsd.org> In-Reply-To: References: <03736C90-EE54-47B3-AEA7-ED1AC0343B4B.ref@yahoo.com> <03736C90-EE54-47B3-AEA7-ED1AC0343B4B@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; format=flowed Content-Transfer-Encoding: quoted-printable On 2024-04-24 02:12:41 (+0800), Mark Millard wrote: > On Apr 19, 2024, at 07:16, Philip Paeps wrote: > >> On 2024-04-18 23:02:30 (+0800), Mark Millard wrote: >> >>> void wrote on >>> Date: Thu, 18 Apr 2024 14:08:36 UTC : >>> >>>> Not sure where to post this.. >>>> >>>> The last bulk build for arm64 appears to have happened around >>>> mid-March on ampere2. Is it broken? >>> >>> main-armv7 building is broken and the last completed build >>> was the one started on Mon, 19 Feb 2024 12:32:10 GMT. It >>> gets stuck making no progress until manually forced to stop, >>> which leads to huge elapsed times for the incomplete builds: >>> >>> pd5512ae7b8c6_s75464941dc 34472 12282 (+9196) 107 (+77) 4753 = >>> (+2247) 1390 (+529) 15940 parallel_build: Fri, 22 Mar 2024 11:05:01 = >>> GMT 651:21:56 >>> >>> p43e3af5f5763_sf5f08e41aa 19809 5919 (+3126) 137 (+100) 5363 = >>> (+2741) 1395 (+522) 6995 parallel_build: Wed, 28 Feb 2024 15:46:14 = >>> GMT 359:42:14 ampere2 >>> >>> ampere2 alternates between trying to build main-arm64 and = >>> main-armv7, so main-armv7 being stuck blocks main-arm64 from = >>> building. >>> >>> One can see that all 13 job ID's show over 570 hours: >>> >>> http://ampere2.nyi.freebsd.org/build.html?mastername=3Dmain-armv7-def= ault&build=3Dpd5512ae7b8c6_s75464941dc >>> >>> It is not random which packages are building when this happens. = >>> Compare: >>> >>> http://ampere2.nyi.freebsd.org/build.html?mastername=3Dmain-armv7-def= ault&build=3Dp43e3af5f5763_sf5f08e41aa >>> >>> By contrast, the 19 Feb 2024 from-scratch (full) build worked: >>> >>> http://ampere2.nyi.freebsd.org/build.html?mastername=3Dmain-armv7-def= ault&build=3Dpe9c9c73181b5_sbd45bbe440 >>> >>> My guess is that FreeBSD has something that broken after bd45bbe440 >>> that was broken as of f5f08e41aa and was still broken at 75464941dc = >>> . >> >> I'll kill the build on ampere2 again. Thanks for the nudge. >> >> We don't really have good monitoring for this. Also: builds should = >> time out after 36 hours. The fact that this one does not is a bug in = >> itself. >> >> Philip [hat: clusteradm] > > I'll note that I've never managed to replicate the problem for > building for armv7 on aarch64. But my context never has the > likes of: > > QUOTE > Host OSVERSION: 1500006 > Jail OSVERSION: 1500015 > . . . > !!! Jail is newer than host. (Jail: 1500015, Host: 1500006) !!! > !!! This is not supported. !!! > !!! Host kernel must be same or newer than jail. !!! > !!! Expect build failures. !!! > END QUOTE > > but always has the two OSVERSION's the same, such as: > > Host OSVERSION: 1500015 > Jail OSVERSION: 1500015 > > or, recently, > > Host OSVERSION: 1500018 > Jail OSVERSION: 1500018 > > My bulk runs do go through the sequence where the hangups > have repeated for main-armv7 on ampere2. > > I wonder what would happen if "Host OSVERSION" was updated > (modernized) to match the modern "Jail OSVERSION" that would > be used? The package builders are due for a regular refresh to newer -CURRENT = dogfood. I'll do the aarch64 builders first this time. I've set /root/stop-builds on them. I'll upgrade them when they go = idle. Or I'll kill them if they take much longer to build what they're = building. It annoys me that they do not stop building after 36 hours, = like they're supposed to. They're currently running: n266879-6abee52e0d79 2023-12-09 01:06:28 jlduran strfmon: Silence = scan-build warning Our current clusteradm build is: n269399-bbc6e6c5ec8c 2024-04-14 03:12:36 sigsys daemon: fix -R to = enable supervision mode I may do a new build while waiting for them to go idle: - quarterly 140arm64 1b931669de11 parallel_build 28776 15299 33 588 = 985 0 11871 3D:01:08:29 = https://pkg-status.freebsd.org/ampere1/build.html?mastername=3D140arm64-q= uarterly&build=3D1b931669de11 - default main-arm64 p1c7a816cd0ad_s1bd4f769caf parallel_build 34528 = 19888 65 669 980 0 12926 4D:00:52:21 = https://pkg-status.freebsd.org/ampere2/build.html?mastername=3Dmain-arm64= -default&build=3Dp1c7a816cd0ad_s1bd4f769caf - default 140releng-armv7 2910ff97e727 parallel_build 34543 14826 60 = 5539 1397 0 12721 1D:09:35:28 = https://pkg-status.freebsd.org/ampere3/build.html?mastername=3D140releng-= armv7-default&build=3D2910ff97e727 Philip From nobody Wed Apr 24 07:54:43 2024 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 4VPWVK0wdsz5K2x1 for ; Wed, 24 Apr 2024 07:54:49 +0000 (UTC) (envelope-from urtp5@yandex.ru) Received: from forward400a.mail.yandex.net (forward400a.mail.yandex.net [IPv6:2a02:6b8:c0e:500:1:45:d181:db01]) (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 4VPWVJ2Mbvz4ldJ for ; Wed, 24 Apr 2024 07:54:48 +0000 (UTC) (envelope-from urtp5@yandex.ru) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yandex.ru header.s=mail header.b=sEXwljg8; dmarc=pass (policy=none) header.from=yandex.ru; spf=pass (mx1.freebsd.org: domain of urtp5@yandex.ru designates 2a02:6b8:c0e:500:1:45:d181:db01 as permitted sender) smtp.mailfrom=urtp5@yandex.ru Received: from mail-nwsmtp-mxback-production-main-798.vla.yp-c.yandex.net (mail-nwsmtp-mxback-production-main-798.vla.yp-c.yandex.net [IPv6:2a02:6b8:c15:2884:0:640:4164:0]) by forward400a.mail.yandex.net (Yandex) with ESMTPS id 337A66E627 for ; Wed, 24 Apr 2024 10:54:44 +0300 (MSK) Received: from mail.yandex.ru (2a02:6b8:c18:4601:0:640:4d35:0 [2a02:6b8:c18:4601:0:640:4d35:0]) by mail-nwsmtp-mxback-production-main-798.vla.yp-c.yandex.net (mxback/Yandex) with HTTP id gsFrYW4cCKo0-KT8A8TUF; Wed, 24 Apr 2024 10:54:43 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1713945283; bh=7uXMtZ1J5em/k+aLNx77e42IoS0iyK8VziGgIc8qLEo=; h=Message-Id:Date:Subject:To:From; b=sEXwljg8QlsAsCiGj2CvM2gkYEH5+8VBBRksXmV6Y1ATwsOdMGOEAqn8MPIPl2qpX zodv1VIJ19j1HagtKUtDNGXV8X/ez76RF66A74JZ8wFjBCgRusoJPpS5ZPOgbxijqh jqhJEZx4qxWu89DKFRROeMv9S8yKdwT01ZtbnAnU= Received: by fttg4r4wmjvthz4h.vla.yp-c.yandex.net with HTTP; Wed, 24 Apr 2024 10:54:43 +0300 From: USER BSD To: "freebsd-current@FreeBSD.org" Subject: Kernel linking error on -CURRENT List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Wed, 24 Apr 2024 11:54:43 +0400 Message-Id: <450021713944839@mail.yandex.ru> Content-Transfer-Encoding: base64 Content-Type: text/html; charset=utf-8 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.40 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.80)[-0.795]; DMARC_POLICY_ALLOW(-0.50)[yandex.ru,none]; R_SPF_ALLOW(-0.20)[+ip6:2a02:6b8:c00::/40]; MIME_HTML_ONLY(0.20)[]; R_DKIM_ALLOW(-0.20)[yandex.ru:s=mail]; MIME_BASE64_TEXT(0.10)[]; ASN(0.00)[asn:13238, ipnet:2a02:6b8::/32, country:RU]; MIME_TRACE(0.00)[0:~]; RCPT_COUNT_ONE(0.00)[1]; FREEMAIL_ENVFROM(0.00)[yandex.ru]; FREEMAIL_FROM(0.00)[yandex.ru]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; TO_DN_EQ_ADDR_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yandex.ru:dkim]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[yandex.ru:+] X-Rspamd-Queue-Id: 4VPWVJ2Mbvz4ldJ PGRpdj5IaSwgRnJlZUJTRCBDb21tdW5pdHkhPC9kaXY+PGRpdj7CoDwvZGl2PjxkaXY+SSBoYXZl IGEgdGVhY2ggd2l0aCBGcmVlQlNEIGFuZCB1c2UgLUNVUlJFTlQgb24gbXkgdGVzdCBtYWNoaW5l LjwvZGl2PjxkaXY+QW5kIHNvbWUgZGF5cyBhZ28gYWZ0ZXI8L2Rpdj48ZGl2Pi0gZ2l0IHB1bGw8 L2Rpdj48ZGl2Pi0gbWFrZSBidWlsZHdvcmxkPC9kaXY+PGRpdj4tIG1ha2UgYnVpbGRrZXJuZWw8 L2Rpdj48ZGl2PsKgPC9kaXY+PGRpdj48ZGl2PlRoZXJlIGlzIC9ldGMvc3JjLmNvbmYgYW5kIEJT RFNFUlYgYmVsb3csIHdoYXQgY2FuIGNhdXNlIHRoYXQgZXJyb3I/PC9kaXY+PGRpdj5UaGFua3Mg Zm9yIGhlbHAhPC9kaXY+PGRpdj7CoDwvZGl2PjwvZGl2PjxkaXY+a2VybmVsIGJ1aWxkaW5nIGZh aWxlZCB3aXRoIHN1Y2ggbWVzc2FnZXM6PC9kaXY+PGRpdj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwvZGl2 PjxkaXY+PGRpdj4tLS0gZm9yY2UtZHluYW1pYy1oYWNrLnBpY28gLS0tPC9kaXY+PGRpdj5jYyAt dGFyZ2V0IHg4Nl82NC11bmtub3duLWZyZWVic2QxNS4wIC0tc3lzcm9vdD0vdXNyL29iai91c3Iv c3JjL2FtZDY0LmFtZDY0L3RtcCAtQi91c3Ivb2JqL3Vzci9zcmMvYW1kNjQuYW1kNjQvdG1wL3Vz ci9iaW7CoCAtc2hhcmVkIC1PMiAtcGlwZSAtZm5vLXN0cmljdC1hbGlhc2luZyAtbWFyY2g9bmF0 aXZlwqAgLW5vc3RkaW5jwqAgLUkuIC1JL3Vzci9zcmMvc3lzIC1JL3U8L2Rpdj48ZGl2PnNyL3Ny Yy9zeXMvY29udHJpYi9jay9pbmNsdWRlIC1JL3Vzci9zcmMvc3lzL2NvbnRyaWIvbGliZmR0IC1E X0tFUk5FTCAtREhBVkVfS0VSTkVMX09QVElPTl9IRUFERVJTIC1pbmNsdWRlIG9wdF9nbG9iYWwu aCAtZm5vLWNvbW1vbsKgwqDCoCAtTUTCoCAtTUYuZGVwZW5kLmZvcmNlLWR5bmFtaWMtaGFjay5w aWNvIC1NVGZvcmNlLWR5bmFtaWMtaGFjay5waWNvIC1mZGVidWctcHI8L2Rpdj48ZGl2PmVmaXgt bWFwPS4vbWFjaGluZT0vdXNyL3NyYy9zeXMvYW1kNjQvaW5jbHVkZSAtZmRlYnVnLXByZWZpeC1t YXA9Li94ODY9L3Vzci9zcmMvc3lzL3g4Ni9pbmNsdWRlIC1mZGVidWctcHJlZml4LW1hcD0uL2kz ODY9L3Vzci9zcmMvc3lzL2kzODYvaW5jbHVkZSAtbWNtb2RlbD1rZXJuZWwgLW1uby1yZWQtem9u ZSAtbW5vLW1teCAtbW5vLXNzZSAtbXNvZnQtZmxvYXTCoCAtZm48L2Rpdj48ZGl2Pm8tYXN5bmNo cm9ub3VzLXVud2luZC10YWJsZXMgLWZmcmVlc3RhbmRpbmcgLWZ3cmFwdiAtV2FsbCAtV3N0cmlj dC1wcm90b3R5cGVzIC1XbWlzc2luZy1wcm90b3R5cGVzIC1XcG9pbnRlci1hcml0aCAtV2Nhc3Qt cXVhbCAtV3VuZGVmIC1Xbm8tcG9pbnRlci1zaWduIC1EX19wcmludGZfXz1fX2ZyZWVic2Rfa3By aW50Zl9fIC1XbWlzc2luZy1pbmNsdWRlLWRpcnMgLWZkaTwvZGl2PjxkaXY+YWdub3N0aWNzLXNo b3ctb3B0aW9uIC1Xbm8tdW5rbm93bi1wcmFnbWFzIC1Xc3dpdGNoIC1Xbm8tZXJyb3I9dGF1dG9s b2dpY2FsLWNvbXBhcmUgLVduby1lcnJvcj1lbXB0eS1ib2R5IC1Xbm8tZXJyb3I9cGFyZW50aGVz ZXMtZXF1YWxpdHkgLVduby1lcnJvcj11bnVzZWQtZnVuY3Rpb24gLVduby1lcnJvcj1wb2ludGVy LXNpZ24gLVduby1lcnJvcj1zaGlmdC1uZWdhdGl2PC9kaXY+PGRpdj5lLXZhbHVlIC1Xbm8tYWRk cmVzcy1vZi1wYWNrZWQtbWVtYmVyIC1Xbm8tZm9ybWF0LXplcm8tbGVuZ3RowqDCoCAtbW5vLWFl cyAtbW5vLWF2eMKgIC1zdGQ9Z251OTkgLW5vc3RkbGliwqAgZm9yY2UtZHluYW1pYy1oYWNrLmMg LW8gZm9yY2UtZHluYW1pYy1oYWNrLnBpY288L2Rpdj48ZGl2Pi0tLSB2ZXJzLmMgLS0tPC9kaXY+ PGRpdj5NQUtFPSJtYWtlIiBzaCAvdXNyL3NyYy9zeXMvY29uZi9uZXd2ZXJzLnNowqAgQlNEU0VS VjwvZGl2PjxkaXY+LS0tIHZlcnMubyAtLS08L2Rpdj48ZGl2PmNjIC10YXJnZXQgeDg2XzY0LXVu a25vd24tZnJlZWJzZDE1LjAgLS1zeXNyb290PS91c3Ivb2JqL3Vzci9zcmMvYW1kNjQuYW1kNjQv dG1wIC1CL3Vzci9vYmovdXNyL3NyYy9hbWQ2NC5hbWQ2NC90bXAvdXNyL2JpbiAtYyAtTzIgLXBp cGUgLWZuby1zdHJpY3QtYWxpYXNpbmcgLW1hcmNoPW5hdGl2ZcKgIC1ub3N0ZGluY8KgIC1JLiAt SS91c3Ivc3JjL3N5cyAtSS91c3Ivc3JjPC9kaXY+PGRpdj4vc3lzL2NvbnRyaWIvY2svaW5jbHVk ZSAtSS91c3Ivc3JjL3N5cy9jb250cmliL2xpYmZkdCAtRF9LRVJORUwgLURIQVZFX0tFUk5FTF9P UFRJT05fSEVBREVSUyAtaW5jbHVkZSBvcHRfZ2xvYmFsLmggLWZuby1jb21tb27CoMKgwqDCoCAt ZmRlYnVnLXByZWZpeC1tYXA9Li9tYWNoaW5lPS91c3Ivc3JjL3N5cy9hbWQ2NC9pbmNsdWRlIC1m ZGVidWctcHJlZml4LW1hcD0uL3g4Nj0vPC9kaXY+PGRpdj51c3Ivc3JjL3N5cy94ODYvaW5jbHVk ZSAtZmRlYnVnLXByZWZpeC1tYXA9Li9pMzg2PS91c3Ivc3JjL3N5cy9pMzg2L2luY2x1ZGUgLW1j bW9kZWw9a2VybmVsIC1tbm8tcmVkLXpvbmUgLW1uby1tbXggLW1uby1zc2UgLW1zb2Z0LWZsb2F0 wqAgLWZuby1hc3luY2hyb25vdXMtdW53aW5kLXRhYmxlcyAtZmZyZWVzdGFuZGluZyAtZndyYXB2 IC1XYWxsIC1Xc3RyaWN0LXByb3RvPC9kaXY+PGRpdj50eXBlcyAtV21pc3NpbmctcHJvdG90eXBl cyAtV3BvaW50ZXItYXJpdGggLVdjYXN0LXF1YWwgLVd1bmRlZiAtV25vLXBvaW50ZXItc2lnbiAt RF9fcHJpbnRmX189X19mcmVlYnNkX2twcmludGZfXyAtV21pc3NpbmctaW5jbHVkZS1kaXJzIC1m ZGlhZ25vc3RpY3Mtc2hvdy1vcHRpb24gLVduby11bmtub3duLXByYWdtYXMgLVdzd2l0Y2ggLVdu by1lcnJvcj10YXV0b2xvZ2k8L2Rpdj48ZGl2PmNhbC1jb21wYXJlIC1Xbm8tZXJyb3I9ZW1wdHkt Ym9keSAtV25vLWVycm9yPXBhcmVudGhlc2VzLWVxdWFsaXR5IC1Xbm8tZXJyb3I9dW51c2VkLWZ1 bmN0aW9uIC1Xbm8tZXJyb3I9cG9pbnRlci1zaWduIC1Xbm8tZXJyb3I9c2hpZnQtbmVnYXRpdmUt dmFsdWUgLVduby1hZGRyZXNzLW9mLXBhY2tlZC1tZW1iZXIgLVduby1mb3JtYXQtemVyby1sZW5n dGjCoMKgIC1tbm8tYWVzPC9kaXY+PGRpdj7CoC1tbm8tYXZ4wqAgLXN0ZD1nbnU5OSAtV2Vycm9y IHZlcnMuYzwvZGl2PjxkaXY+LS0tIGtlcm5lbCAtLS08L2Rpdj48ZGl2Pmxpbmtpbmcga2VybmVs PC9kaXY+PGRpdj5sZDogZXJyb3I6IHVuZGVmaW5lZCBzeW1ib2w6IGt0cmNhcGZhaWw8L2Rpdj48 ZGl2PiZndDsmZ3Q7Jmd0OyByZWZlcmVuY2VkIGJ5IHZmc19sb29rdXAuYzwvZGl2PjxkaXY+Jmd0 OyZndDsmZ3Q7wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB2ZnNfbG9va3VwLm86KG5hbWVp KTwvZGl2PjxkaXY+Jmd0OyZndDsmZ3Q7IHJlZmVyZW5jZWQgYnkgdmZzX2xvb2t1cC5jPC9kaXY+ PGRpdj4mZ3Q7Jmd0OyZndDvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHZmc19sb29rdXAu bzoobmFtZWlfc2V0dXApPC9kaXY+PGRpdj4mZ3Q7Jmd0OyZndDsgcmVmZXJlbmNlZCBieSB2ZnNf bG9va3VwLmM8L2Rpdj48ZGl2PiZndDsmZ3Q7Jmd0O8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqAgdmZzX2xvb2t1cC5vOih2ZnNfbG9va3VwKTwvZGl2PjxkaXY+Jmd0OyZndDsmZ3Q7IHJlZmVy ZW5jZWQgMyBtb3JlIHRpbWVzPC9kaXY+PGRpdj4qKiogW2tlcm5lbF0gRXJyb3IgY29kZSAxPC9k aXY+PGRpdj7CoDwvZGl2PjxkaXY+bWFrZVsyXTogc3RvcHBlZCBpbiAvdXNyL29iai91c3Ivc3Jj L2FtZDY0LmFtZDY0L3N5cy9CU0RTRVJWPC9kaXY+PGRpdj5tYWtlWzJdOiAxIGVycm9yPC9kaXY+ PGRpdj7CoDwvZGl2PjxkaXY+bWFrZVsyXTogc3RvcHBlZCBpbiAvdXNyL29iai91c3Ivc3JjL2Ft ZDY0LmFtZDY0L3N5cy9CU0RTRVJWPC9kaXY+PGRpdj7CoMKgwqDCoCAxMDk4LjI3IHJlYWzCoMKg wqDCoMKgIDIwMDIuMTcgdXNlcsKgwqDCoMKgwqDCoCAxNzYuMjYgc3lzPC9kaXY+PGRpdj7CoDwv ZGl2PjxkaXY+bWFrZVsxXTogc3RvcHBlZCBpbiAvdXNyL3NyYzwvZGl2PjxkaXY+wqA8L2Rpdj48 ZGl2Pm1ha2U6IHN0b3BwZWQgaW4gL3Vzci9zcmM8L2Rpdj48ZGl2PsKgPC9kaXY+PGRpdj4tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLTwvZGl2PjxkaXY+wqA8L2Rpdj48ZGl2Pi9ldGMvc3JjLmNvbmY8 L2Rpdj48ZGl2Pj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTwvZGl2Pjxk aXY+PGRpdj5XSVRIT1VUX0FQTT15ZXM8L2Rpdj48ZGl2PldJVEhPVVRfQVNTRVJUX0RFQlVHPXll czwvZGl2PjxkaXY+V0lUSE9VVF9BVVRIUEY9eWVzPC9kaXY+PGRpdj5XSVRIT1VUX0JIWVZFPXll czwvZGl2PjxkaXY+V0lUSE9VVF9CTEFDS0xJU1Q9eWVzPC9kaXY+PGRpdj5XSVRIT1VUX0JMVUVU T09USD15ZXM8L2Rpdj48ZGl2PldJVEhPVVRfQ0NEPXllczwvZGl2PjxkaXY+V0lUSE9VVF9DWEdC RVRPT0w9eWVzPC9kaXY+PGRpdj5XSVRIT1VUX0RFQlVHX0ZJTEVTPXllczwvZGl2PjxkaXY+V0lU SE9VVF9EVFJBQ0U9eWVzPC9kaXY+PGRpdj5XSVRIT1VUX0ZMT1BQWT15ZXM8L2Rpdj48ZGl2PldJ VEhPVVRfR09PR0xFVEVTVD15ZXM8L2Rpdj48ZGl2PldJVEhPVVRfSEFTVD15ZXM8L2Rpdj48ZGl2 PldJVEhPVVRfSFRNTD15ZXM8L2Rpdj48ZGl2PldJVEhPVVRfSFlQRVJWPXllczwvZGl2PjxkaXY+ V0lUSE9VVF9JTkVUNj15ZXM8L2Rpdj48ZGl2PldJVEhPVVRfSVBGSUxURVI9eWVzPC9kaXY+PGRp dj5XSVRIT1VUX0lTQ1NJPXllczwvZGl2PjxkaXY+V0lUSE9VVF9LRFVNUD15ZXM8L2Rpdj48ZGl2 PldJVEhPVVRfS0VSTkVMX1NZTUJPTFM9eWVzPC9kaXY+PGRpdj5XSVRIX01BTExPQ19QUk9EVUNU SU9OPXllczwvZGl2PjxkaXY+V0lUSE9VVF9NTFg1VE9PTD15ZXM8L2Rpdj48ZGl2PldJVEhPVVRf TlZNRT15ZXM8L2Rpdj48ZGl2PldJVEhPVVRfT0ZFRD15ZXM8L2Rpdj48ZGl2PldJVEhPVVRfUEY9 eWVzPC9kaXY+PGRpdj5XSVRIT1VUX1BUSFJFQURTX0FTU0VSVElPTlM9eWVzPC9kaXY+PGRpdj5X SVRIT1VUX1JBRElVU19TVVBQT1JUPXllczwvZGl2PjxkaXY+V0lUSE9VVF9SRUxSTz15ZXM8L2Rp dj48ZGl2PldJVEhPVVRfU1NQPXllczwvZGl2PjxkaXY+V0lUSE9VVF9XQVJOUz15ZXM8L2Rpdj48 ZGl2PldJVEhPVVRfV0VSUk9SPXllczwvZGl2PjxkaXY+V0lUSE9VVF9URVNUUz15ZXM8L2Rpdj48 ZGl2PldJVEhPVVRfV0lSRUxFU1M9eWVzPC9kaXY+PGRpdj7CoDwvZGl2PjxkaXY+QlNEU0VSVjwv ZGl2PjxkaXY+PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PC9kaXY+PGRp dj48ZGl2PmNwdcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBIQU1NRVI8L2Rpdj48ZGl2PmlkZW50 wqDCoMKgwqDCoMKgwqDCoMKgwqAgQlNEU0VSVjwvZGl2PjxkaXY+ZGV2aWNlwqDCoMKgwqDCoMKg wqDCoMKgIGFtZHRlbXA8L2Rpdj48ZGl2Pm9wdGlvbnPCoMKgwqDCoMKgwqDCoMKgIFNDSEVEX1VM RcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgIyBVTEUgc2NoZWR1bGVyPC9kaXY+PGRpdj5v cHRpb25zwqDCoMKgwqDCoMKgwqDCoCBQUkVFTVBUSU9OwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqAgIyBFbmFibGUga2VybmVsIHRocmVhZCBwcmVlbXB0aW9uPC9kaXY+PGRpdj5vcHRpb25zwqDC oMKgwqDCoMKgwqDCoCBWSU1BR0XCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgICMg U3Vic3lzdGVtIHZpcnR1YWxpemF0aW9uLCBlLmcuIFZORVQ8L2Rpdj48ZGl2Pm9wdGlvbnPCoMKg wqDCoMKgwqDCoMKgIElORVTCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAj IEludGVyTkVUd29ya2luZzwvZGl2PjxkaXY+b3B0aW9uc8KgwqDCoMKgwqDCoMKgwqAgVENQX09G RkxPQUTCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgIyBUQ1Agb2ZmbG9hZDwvZGl2PjxkaXY+b3B0 aW9uc8KgwqDCoMKgwqDCoMKgwqAgVENQX0JMQUNLQk9YwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAj IEVuaGFuY2VkIFRDUCBldmVudCBsb2dnaW5nPC9kaXY+PGRpdj5vcHRpb25zwqDCoMKgwqDCoMKg wqDCoCBUQ1BfSEhPT0vCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgICMgaGhvb2soOSkgZnJh bWV3b3JrIGZvciBUQ1A8L2Rpdj48ZGl2Pm9wdGlvbnPCoMKgwqDCoMKgwqDCoMKgIFRDUF9SRkM3 NDEzwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgICMgVENQIEZhc3QgT3BlbjwvZGl2PjxkaXY+b3B0 aW9uc8KgwqDCoMKgwqDCoMKgwqAgS0VSTl9UTFPCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqAgIyBUTFMgdHJhbnNtaXQgJmFtcDsgcmVjZWl2ZSBvZmZsb2FkPC9kaXY+PGRpdj5vcHRpb25z wqDCoMKgwqDCoMKgwqDCoCBGRlPCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgICMgQmVya2VsZXkgRmFzdCBGaWxlc3lzdGVtPC9kaXY+PGRpdj5vcHRpb25zwqDCoMKgwqDC oMKgwqDCoCBTT0ZUVVBEQVRFU8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAjIEVuYWJsZSBGRlMg c29mdCB1cGRhdGVzIHN1cHBvcnQ8L2Rpdj48ZGl2Pm9wdGlvbnPCoMKgwqDCoMKgwqDCoMKgIE1E X1JPT1TCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAjIE1EIGlzIGEgcG90ZW50aWFs IHJvb3QgZGV2aWNlPC9kaXY+PGRpdj5vcHRpb25zwqDCoMKgwqDCoMKgwqDCoCBNU0RPU0ZTwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgIyBNU0RPUyBGaWxlc3lzdGVtPC9kaXY+PGRp dj5vcHRpb25zwqDCoMKgwqDCoMKgwqDCoCBQUk9DRlPCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgICMgUHJvY2VzcyBmaWxlc3lzdGVtIChyZXF1aXJlcyBQU0VVRE9GUyk8L2Rpdj48 ZGl2Pm9wdGlvbnPCoMKgwqDCoMKgwqDCoMKgIFBTRVVET0ZTwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgICMgUHNldWRvLWZpbGVzeXN0ZW0gZnJhbWV3b3JrPC9kaXY+PGRpdj5vcHRpb25z wqDCoMKgwqDCoMKgwqDCoCBUTVBGU8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oCAjIEVmZmljaWVudCBtZW1vcnkgZmlsZXN5c3RlbTwvZGl2PjxkaXY+b3B0aW9uc8KgwqDCoMKg wqDCoMKgwqAgR0VPTV9MQUJFTMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgICMgUHJvdmlkZXMg bGFiZWxpemF0aW9uPC9kaXY+PGRpdj5vcHRpb25zwqDCoMKgwqDCoMKgwqDCoCBFRklSVMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAjIEVGSSBSdW50aW1lIFNlcnZpY2VzIHN1 cHBvcnQ8L2Rpdj48ZGl2Pm9wdGlvbnPCoMKgwqDCoMKgwqDCoMKgIENPTVBBVF9GUkVFQlNEMzLC oMKgwqDCoMKgwqDCoCAjIENvbXBhdGlibGUgd2l0aCBpMzg2IGJpbmFyaWVzPC9kaXY+PGRpdj5v cHRpb25zwqDCoMKgwqDCoMKgwqDCoCBDT01QQVRfRlJFRUJTRDExwqDCoMKgwqDCoMKgwqAgIyBD b21wYXRpYmxlIHdpdGggRnJlZUJTRDExPC9kaXY+PGRpdj5vcHRpb25zwqDCoMKgwqDCoMKgwqDC oCBDT01QQVRfRlJFRUJTRDEywqDCoMKgwqDCoMKgwqAgIyBDb21wYXRpYmxlIHdpdGggRnJlZUJT RDEyPC9kaXY+PGRpdj5vcHRpb25zwqDCoMKgwqDCoMKgwqDCoCBDT01QQVRfRlJFRUJTRDEzwqDC oMKgwqDCoMKgwqAgIyBDb21wYXRpYmxlIHdpdGggRnJlZUJTRDEzPC9kaXY+PGRpdj5vcHRpb25z wqDCoMKgwqDCoMKgwqDCoCBDT01QQVRfRlJFRUJTRDE0PC9kaXY+PGRpdj5vcHRpb25zwqDCoMKg wqDCoMKgwqDCoCBTQ1NJX0RFTEFZPTUwMDDCoMKgwqDCoMKgwqDCoMKgICMgRGVsYXkgKGluIG1z KSBiZWZvcmUgcHJvYmluZyBTQ1NJPC9kaXY+PGRpdj5vcHRpb25zwqDCoMKgwqDCoMKgwqDCoCBT WVNWU0hNwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgIyBTWVNWLXN0eWxlIHNoYXJl ZCBtZW1vcnk8L2Rpdj48ZGl2Pm9wdGlvbnPCoMKgwqDCoMKgwqDCoMKgIFNZU1ZNU0fCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAjIFNZU1Ytc3R5bGUgbWVzc2FnZSBxdWV1ZXM8L2Rp dj48ZGl2Pm9wdGlvbnPCoMKgwqDCoMKgwqDCoMKgIFNZU1ZTRU3CoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoCAjIFNZU1Ytc3R5bGUgc2VtYXBob3JlczwvZGl2PjxkaXY+b3B0aW9uc8Kg wqDCoMKgwqDCoMKgwqAgX0tQT1NJWF9QUklPUklUWV9TQ0hFRFVMSU5HICMgUE9TSVggUDEwMDNf MUIgcmVhbC10aW1lIGV4dGVuc2lvbnM8L2Rpdj48ZGl2Pm9wdGlvbnPCoMKgwqDCoMKgwqDCoMKg IFBSSU5URl9CVUZSX1NJWkU9MTI4wqDCoMKgICMgUHJldmVudCBwcmludGYgb3V0cHV0IGJlaW5n IGludGVyc3BlcnNlZC48L2Rpdj48ZGl2Pm9wdGlvbnPCoMKgwqDCoMKgwqDCoMKgIEtCRF9JTlNU QUxMX0NERVbCoMKgwqDCoMKgwqDCoCAjIGluc3RhbGwgYSBDREVWIGVudHJ5IGluIC9kZXY8L2Rp dj48ZGl2Pm9wdGlvbnPCoMKgwqDCoMKgwqDCoMKgIENBUEFCSUxJVFlfTU9ERcKgwqDCoMKgwqDC oMKgwqAgIyBDYXBzaWN1bSBjYXBhYmlsaXR5IG1vZGU8L2Rpdj48ZGl2Pm9wdGlvbnPCoMKgwqDC oMKgwqDCoMKgIENBUEFCSUxJVElFU8KgwqDCoMKgwqDCoMKgwqDCoMKgwqAgIyBDYXBzaWN1bSBj YXBhYmlsaXRpZXM8L2Rpdj48ZGl2Pm9wdGlvbnPCoMKgwqDCoMKgwqDCoMKgIElOQ0xVREVfQ09O RklHX0ZJTEXCoMKgwqDCoCAjIEluY2x1ZGUgdGhpcyBmaWxlIGluIGtlcm5lbDwvZGl2PjxkaXY+ b3B0aW9uc8KgwqDCoMKgwqDCoMKgwqAgU01QwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoCAjIFN5bW1ldHJpYyBNdWx0aVByb2Nlc3NvciBLZXJuZWw8L2Rpdj48ZGl2Pm9w dGlvbnPCoMKgwqDCoMKgwqDCoMKgIEVBUkxZX0FQX1NUQVJUVVA8L2Rpdj48ZGl2PmRldmljZcKg wqDCoMKgwqDCoMKgwqDCoCBjcHVmcmVxPC9kaXY+PGRpdj5kZXZpY2XCoMKgwqDCoMKgwqDCoMKg wqAgYWNwaTwvZGl2PjxkaXY+ZGV2aWNlwqDCoMKgwqDCoMKgwqDCoMKgIHNtYmlvczwvZGl2Pjxk aXY+b3B0aW9uc8KgwqDCoMKgwqDCoMKgwqAgSU9NTVU8L2Rpdj48ZGl2PmRldmljZcKgwqDCoMKg wqDCoMKgwqDCoCBwY2k8L2Rpdj48ZGl2Pm9wdGlvbnPCoMKgwqDCoMKgwqDCoMKgIENPTVBBVF9M SU5VWEtQSTwvZGl2PjxkaXY+ZGV2aWNlwqDCoMKgwqDCoMKgwqDCoMKgIGFoY2nCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAjIEFIQ0ktY29tcGF0aWJsZSBTQVRBIGNvbnRy b2xsZXJzPC9kaXY+PGRpdj5kZXZpY2XCoMKgwqDCoMKgwqDCoMKgwqAgc2NidXPCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgIyBTQ1NJIGJ1cyAocmVxdWlyZWQgZm9yIEFUQS9T Q1NJKTwvZGl2PjxkaXY+ZGV2aWNlwqDCoMKgwqDCoMKgwqDCoMKgIGRhwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgICMgRGlyZWN0IEFjY2VzcyAoZGlza3MpPC9kaXY+ PGRpdj5kZXZpY2XCoMKgwqDCoMKgwqDCoMKgwqAgcGFzc8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgICMgUGFzc3Rocm91Z2ggZGV2aWNlIChkaXJlY3QgQVRBL1NDU0kgYWNj ZXNzKTwvZGl2PjxkaXY+ZGV2aWNlwqDCoMKgwqDCoMKgwqDCoMKgIGF0a2JkY8KgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgIyBBVCBrZXlib2FyZCBjb250cm9sbGVyPC9kaXY+PGRp dj5kZXZpY2XCoMKgwqDCoMKgwqDCoMKgwqAgYXRrYmTCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqAgIyBBVCBrZXlib2FyZDwvZGl2PjxkaXY+ZGV2aWNlwqDCoMKgwqDCoMKgwqDC oMKgIGtiZG11eMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgIyBrZXlib2FyZCBt dWx0aXBsZXhlcjwvZGl2PjxkaXY+ZGV2aWNlwqDCoMKgwqDCoMKgwqDCoMKgIHZnYcKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgIyBWR0EgdmlkZW8gY2FyZCBkcml2ZXI8 L2Rpdj48ZGl2PmRldmljZcKgwqDCoMKgwqDCoMKgwqDCoCBzcGxhc2jCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgICMgU3BsYXNoIHNjcmVlbiBhbmQgc2NyZWVuIHNhdmVyIHN1cHBv cnQ8L2Rpdj48ZGl2PmRldmljZcKgwqDCoMKgwqDCoMKgwqDCoCB2dDwvZGl2PjxkaXY+ZGV2aWNl wqDCoMKgwqDCoMKgwqDCoMKgIHZ0X3ZnYTwvZGl2PjxkaXY+ZGV2aWNlwqDCoMKgwqDCoMKgwqDC oMKgIHZ0X2VmaWZiPC9kaXY+PGRpdj48ZGl2PmRldmljZcKgwqDCoMKgwqDCoMKgwqDCoCB2dF92 YmVmYjwvZGl2PjxkaXY+ZGV2aWNlwqDCoMKgwqDCoMKgwqDCoMKgIGFncMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgIyBzdXBwb3J0IHNldmVyYWwgQUdQIGNoaXBzZXRz PC9kaXY+PGRpdj5kZXZpY2XCoMKgwqDCoMKgwqDCoMKgwqAgdWFydMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgICMgR2VuZXJpYyBVQVJUIGRyaXZlcjwvZGl2PjxkaXY+ZGV2 aWNlwqDCoMKgwqDCoMKgwqDCoMKgIGlmbGliPC9kaXY+PGRpdj5kZXZpY2XCoMKgwqDCoMKgwqDC oMKgwqAgbWlpYnVzwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAjIE1JSSBidXMg c3VwcG9ydDwvZGl2PjxkaXY+ZGV2aWNlwqDCoMKgwqDCoMKgwqDCoMKgIHJlwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgICMgUmVhbFRlayA4MTM5QysvODE2OS84MTY5 Uy84MTEwUzwvZGl2PjxkaXY+ZGV2aWNlwqDCoMKgwqDCoMKgwqDCoMKgIGNyeXB0b8KgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgIyBjb3JlIGNyeXB0byBzdXBwb3J0PC9kaXY+PGRp dj5kZXZpY2XCoMKgwqDCoMKgwqDCoMKgwqAgYWVzbmnCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqAgIyBBRVMtTkkgT3BlbkNyeXB0byBtb2R1bGU8L2Rpdj48ZGl2PmRldmljZcKg wqDCoMKgwqDCoMKgwqDCoCBsb29wwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqAgIyBOZXR3b3JrIGxvb3BiYWNrPC9kaXY+PGRpdj5kZXZpY2XCoMKgwqDCoMKgwqDCoMKgwqAg ZXRoZXLCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgIyBFdGhlcm5ldCBzdXBw b3J0PC9kaXY+PGRpdj5kZXZpY2XCoMKgwqDCoMKgwqDCoMKgwqAgdmxhbsKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgICMgODAyLjFRIFZMQU4gc3VwcG9ydDwvZGl2PjxkaXY+ ZGV2aWNlwqDCoMKgwqDCoMKgwqDCoMKgIHR1bnRhcMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqAgIyBQYWNrZXQgdHVubmVsLjwvZGl2PjxkaXY+ZGV2aWNlwqDCoMKgwqDCoMKgwqDC oMKgIG1kwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgICMgTWVtb3J5 ICJkaXNrcyI8L2Rpdj48ZGl2PmRldmljZcKgwqDCoMKgwqDCoMKgwqDCoCBnaWbCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgICMgSVB2NiBhbmQgSVB2NCB0dW5uZWxpbmc8 L2Rpdj48ZGl2PmRldmljZcKgwqDCoMKgwqDCoMKgwqDCoCBmaXJtd2FyZcKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoCAjIGZpcm13YXJlIGFzc2lzdCBtb2R1bGU8L2Rpdj48ZGl2PmRldmlj ZcKgwqDCoMKgwqDCoMKgwqDCoCB4esKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoCAjIGx6bWEgZGVjb21wcmVzc2lvbjwvZGl2PjxkaXY+ZGV2aWNlwqDCoMKgwqDCoMKg wqDCoMKgIGJwZsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgIyBCZXJr ZWxleSBwYWNrZXQgZmlsdGVyPC9kaXY+PGRpdj5vcHRpb25zwqDCoMKgwqDCoMKgwqDCoCBVU0Jf REVCVUfCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgICMgZW5hYmxlIGRlYnVnIG1zZ3M8L2Rp dj48ZGl2PmRldmljZcKgwqDCoMKgwqDCoMKgwqDCoCBlaGNpwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqAgIyBFSENJIFBDSS0mZ3Q7VVNCIGludGVyZmFjZSAoVVNCIDIuMCk8 L2Rpdj48ZGl2PmRldmljZcKgwqDCoMKgwqDCoMKgwqDCoCB4aGNpwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqAgIyBYSENJIFBDSS0mZ3Q7VVNCIGludGVyZmFjZSAoVVNCIDMu MCk8L2Rpdj48ZGl2PmRldmljZcKgwqDCoMKgwqDCoMKgwqDCoCB1c2LCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgICMgVVNCIEJ1cyAocmVxdWlyZWQpPC9kaXY+PGRpdj5k ZXZpY2XCoMKgwqDCoMKgwqDCoMKgwqAgdWtiZMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgICMgS2V5Ym9hcmQ8L2Rpdj48ZGl2PmRldmljZcKgwqDCoMKgwqDCoMKgwqDCoCBu ZXRtYXDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgICMgbmV0bWFwKDQpIHN1cHBv cnQ8L2Rpdj48ZGl2Pm9wdGlvbnPCoMKgwqDCoMKgwqDCoMKgIEVWREVWX1NVUFBPUlTCoMKgwqDC oMKgwqDCoMKgwqDCoCAjIGV2ZGV2IHN1cHBvcnQgaW4gbGVnYWN5IGRyaXZlcnM8L2Rpdj48ZGl2 PmRldmljZcKgwqDCoMKgwqDCoMKgwqDCoCBldmRldsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoCAjIGlucHV0IGV2ZW50IGRldmljZSBzdXBwb3J0PC9kaXY+PGRpdj5kZXZpY2XC oMKgwqDCoMKgwqDCoMKgwqAgdWlucHV0wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oCAjIGluc3RhbGwgL2Rldi91aW5wdXQgY2RldjwvZGl2PjxkaXY+b3B0aW9uc8KgwqDCoMKgwqDC oMKgwqAgSElEX0RFQlVHwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAjIGVuYWJsZSBkZWJ1 ZyBtc2dzPC9kaXY+PGRpdj5kZXZpY2XCoMKgwqDCoMKgwqDCoMKgwqAgaGlkwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAjIEdlbmVyaWMgSElEIHN1cHBvcnQ8L2Rpdj48 ZGl2Pm9wdGlvbnPCoMKgwqDCoMKgwqDCoMKgIElJQ0hJRF9TQU1QTElOR8KgwqDCoMKgwqDCoMKg wqAgIyBXb3JrYXJvdW5kIG1pc3NpbmcgR1BJTyBJTlRSIHN1cHBvcnQ8L2Rpdj48ZGl2PsKgPC9k aXY+PGRpdj7CoDwvZGl2PjwvZGl2PjxkaXY+wqA8L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj4= From nobody Wed Apr 24 08:12:39 2024 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 4VPWv449pCz5K4Cn for ; Wed, 24 Apr 2024 08:12:48 +0000 (UTC) (envelope-from urtp5@yandex.ru) Received: from forward401a.mail.yandex.net (forward401a.mail.yandex.net [IPv6:2a02:6b8:c0e:500:1:45:d181:db02]) (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 4VPWv33kY7z4nKj for ; Wed, 24 Apr 2024 08:12:47 +0000 (UTC) (envelope-from urtp5@yandex.ru) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yandex.ru header.s=mail header.b=f8xyf7je; dmarc=pass (policy=none) header.from=yandex.ru; spf=pass (mx1.freebsd.org: domain of urtp5@yandex.ru designates 2a02:6b8:c0e:500:1:45:d181:db02 as permitted sender) smtp.mailfrom=urtp5@yandex.ru Received: from mail-nwsmtp-smtp-production-main-18.vla.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-18.vla.yp-c.yandex.net [IPv6:2a02:6b8:c0d:3621:0:640:20a5:0]) by forward401a.mail.yandex.net (Yandex) with ESMTPS id 78E6A68B10 for ; Wed, 24 Apr 2024 11:12:44 +0300 (MSK) Received: by mail-nwsmtp-smtp-production-main-18.vla.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id dCGJ9iSXoGk0-94uKo9mq; Wed, 24 Apr 2024 11:12:44 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1713946364; bh=7vh/mWqnpYzIpg+lVHHPAzaQf3bIQMMgo3YYO8YkQCs=; h=Subject:From:To:Date:Message-ID; b=f8xyf7jeJJLIYropPtu4VbkFMnVyh8qj6c4+1DcB/E/Tp+C52WtGw69SDVvxOKq/X Eq0VDuZbDry7nNN1ybHuDRRTbz+j9jTR4ODmitK9h0dcqPY5jpgAGiFQu6ixizqB1w tfMT+1pznDWtEbRmHZBeEvgq84TRkSEP0W0/7JKI= Message-ID: <3a18f625-1441-414b-adb4-6321687f9fa7@yandex.ru> Date: Wed, 24 Apr 2024 13:12:39 +0500 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: ru To: freebsd-current@freebsd.org From: BSD USER Subject: TXT Kernel linking failed on -CURRENT Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.85 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.86)[-0.856]; DMARC_POLICY_ALLOW(-0.50)[yandex.ru,none]; R_DKIM_ALLOW(-0.20)[yandex.ru:s=mail]; R_SPF_ALLOW(-0.20)[+ip6:2a02:6b8:c00::/40]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; FREEMAIL_FROM(0.00)[yandex.ru]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_ALL(0.00)[]; ASN(0.00)[asn:13238, ipnet:2a02:6b8::/32, country:RU]; FREEMAIL_ENVFROM(0.00)[yandex.ru]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yandex.ru:+]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; DWL_DNSWL_NONE(0.00)[yandex.ru:dkim] X-Rspamd-Queue-Id: 4VPWv33kY7z4nKj Sorry for HTML-trash from previous mail :) Hi, FreeBSD Community! I have a teach with FreeBSD and use -CURRENT on my test machine. And some days ago after - git pull - make buildworld - make buildkernel There is /etc/src.conf and BSDSERV below, what can cause that error? Thanks for help! My /usr/src state is: ------------------------------------------------------------------------  git log -n 1 commit a0d7d68a2dd818ce84e37e1ff20c8849cda6d853 (HEAD -> main, origin/main, origin/HEAD) Author: Cy Schubert kernel building failed with such messages: -------------------------------------------------------------------------- --- force-dynamic-hack.pico --- cc -target x86_64-unknown-freebsd15.0 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin  -shared -O2 -pipe -fno-strict-aliasing -march=native  -nostdinc  -I. -I/usr/src/sys -I/u sr/src/sys/contrib/ck/include -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common    -MD  -MF.depend.force-dynamic-hack.pico -MTforce-dynamic-hack.pico -fdebug-pr efix-map=./machine=/usr/src/sys/amd64/include -fdebug-prefix-map=./x86=/usr/src/sys/x86/include -fdebug-prefix-map=./i386=/usr/src/sys/i386/include -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fn o-asynchronous-unwind-tables -ffreestanding -fwrapv -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdi agnostics-show-option -Wno-unknown-pragmas -Wswitch -Wno-error=tautological-compare -Wno-error=empty-body -Wno-error=parentheses-equality -Wno-error=unused-function -Wno-error=pointer-sign -Wno-error=shift-negativ e-value -Wno-address-of-packed-member -Wno-format-zero-length   -mno-aes -mno-avx  -std=gnu99 -nostdlib  force-dynamic-hack.c -o force-dynamic-hack.pico --- vers.c --- MAKE="make" sh /usr/src/sys/conf/newvers.sh  BSDSERV --- vers.o --- cc -target x86_64-unknown-freebsd15.0 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -c -O2 -pipe -fno-strict-aliasing -march=native  -nostdinc  -I. -I/usr/src/sys -I/usr/src /sys/contrib/ck/include -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -fdebug-prefix-map=./machine=/usr/src/sys/amd64/include -fdebug-prefix-map=./x86=/ usr/src/sys/x86/include -fdebug-prefix-map=./i386=/usr/src/sys/i386/include -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -Wall -Wstrict-proto types -Wmissing-prototypes -Wpointer-arith -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wswitch -Wno-error=tautologi cal-compare -Wno-error=empty-body -Wno-error=parentheses-equality -Wno-error=unused-function -Wno-error=pointer-sign -Wno-error=shift-negative-value -Wno-address-of-packed-member -Wno-format-zero-length -mno-aes  -mno-avx  -std=gnu99 -Werror vers.c --- kernel --- linking kernel ld: error: undefined symbol: ktrcapfail >>> referenced by vfs_lookup.c >>>               vfs_lookup.o:(namei) >>> referenced by vfs_lookup.c >>>               vfs_lookup.o:(namei_setup) >>> referenced by vfs_lookup.c >>>               vfs_lookup.o:(vfs_lookup) >>> referenced 3 more times *** [kernel] Error code 1 make[2]: stopped in /usr/obj/usr/src/amd64.amd64/sys/BSDSERV make[2]: 1 error make[2]: stopped in /usr/obj/usr/src/amd64.amd64/sys/BSDSERV      1098.27 real      2002.17 user       176.26 sys make[1]: stopped in /usr/src make: stopped in /usr/src -------------------------------------------------------------------------------- /etc/src.conf ======================================= WITHOUT_APM=yes WITHOUT_ASSERT_DEBUG=yes WITHOUT_AUTHPF=yes WITHOUT_BHYVE=yes WITHOUT_BLACKLIST=yes WITHOUT_BLUETOOTH=yes WITHOUT_CCD=yes WITHOUT_CXGBETOOL=yes WITHOUT_DEBUG_FILES=yes WITHOUT_DTRACE=yes WITHOUT_FLOPPY=yes WITHOUT_GOOGLETEST=yes WITHOUT_HAST=yes WITHOUT_HTML=yes WITHOUT_HYPERV=yes WITHOUT_INET6=yes WITHOUT_IPFILTER=yes WITHOUT_ISCSI=yes WITHOUT_KDUMP=yes WITHOUT_KERNEL_SYMBOLS=yes WITH_MALLOC_PRODUCTION=yes WITHOUT_MLX5TOOL=yes WITHOUT_NVME=yes WITHOUT_OFED=yes WITHOUT_PF=yes WITHOUT_PTHREADS_ASSERTIONS=yes WITHOUT_RADIUS_SUPPORT=yes WITHOUT_RELRO=yes WITHOUT_SSP=yes WITHOUT_WARNS=yes WITHOUT_WERROR=yes WITHOUT_TESTS=yes WITHOUT_WIRELESS=yes BSDSERV ======================================= cpu             HAMMER ident           BSDSERV device          amdtemp options         SCHED_ULE               # ULE scheduler options         PREEMPTION              # Enable kernel thread preemption options         VIMAGE                  # Subsystem virtualization, e.g. VNET options         INET                    # InterNETworking options         TCP_OFFLOAD             # TCP offload options         TCP_BLACKBOX            # Enhanced TCP event logging options         TCP_HHOOK               # hhook(9) framework for TCP options         TCP_RFC7413             # TCP Fast Open options         KERN_TLS                # TLS transmit & receive offload options         FFS                     # Berkeley Fast Filesystem options         SOFTUPDATES             # Enable FFS soft updates support options         MD_ROOT                 # MD is a potential root device options         MSDOSFS                 # MSDOS Filesystem options         PROCFS                  # Process filesystem (requires PSEUDOFS) options         PSEUDOFS                # Pseudo-filesystem framework options         TMPFS                   # Efficient memory filesystem options         GEOM_LABEL              # Provides labelization options         EFIRT                   # EFI Runtime Services support options         COMPAT_FREEBSD32        # Compatible with i386 binaries options         COMPAT_FREEBSD11        # Compatible with FreeBSD11 options         COMPAT_FREEBSD12        # Compatible with FreeBSD12 options         COMPAT_FREEBSD13        # Compatible with FreeBSD13 options         COMPAT_FREEBSD14 options         SCSI_DELAY=5000         # Delay (in ms) before probing SCSI options         SYSVSHM                 # SYSV-style shared memory options         SYSVMSG                 # SYSV-style message queues options         SYSVSEM                 # SYSV-style semaphores options         _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options         PRINTF_BUFR_SIZE=128    # Prevent printf output being interspersed. options         KBD_INSTALL_CDEV        # install a CDEV entry in /dev options         CAPABILITY_MODE         # Capsicum capability mode options         CAPABILITIES            # Capsicum capabilities options         INCLUDE_CONFIG_FILE     # Include this file in kernel options         SMP                     # Symmetric MultiProcessor Kernel options         EARLY_AP_STARTUP device          cpufreq device          acpi device          smbios options         IOMMU device          pci options         COMPAT_LINUXKPI device          ahci                    # AHCI-compatible SATA controllers device          scbus                   # SCSI bus (required for ATA/SCSI) device          da                      # Direct Access (disks) device          pass                    # Passthrough device (direct ATA/SCSI access) device          atkbdc                  # AT keyboard controller device          atkbd                   # AT keyboard device          kbdmux                  # keyboard multiplexer device          vga                     # VGA video card driver device          splash                  # Splash screen and screen saver support device          vt device          vt_vga device          vt_efifb device          vt_vbefb device          agp                     # support several AGP chipsets device          uart                    # Generic UART driver device          iflib device          miibus                  # MII bus support device          re                      # RealTek 8139C+/8169/8169S/8110S device          crypto                  # core crypto support device          aesni                   # AES-NI OpenCrypto module device          loop                    # Network loopback device          ether                   # Ethernet support device          vlan                    # 802.1Q VLAN support device          tuntap                  # Packet tunnel. device          md                      # Memory "disks" device          gif                     # IPv6 and IPv4 tunneling device          firmware                # firmware assist module device          xz                      # lzma decompression device          bpf                     # Berkeley packet filter options         USB_DEBUG               # enable debug msgs device          ehci                    # EHCI PCI->USB interface (USB 2.0) device          xhci                    # XHCI PCI->USB interface (USB 3.0) device          usb                     # USB Bus (required) device          ukbd                    # Keyboard device          netmap                  # netmap(4) support options         EVDEV_SUPPORT           # evdev support in legacy drivers device          evdev                   # input event device support device          uinput                  # install /dev/uinput cdev options         HID_DEBUG               # enable debug msgs device          hid                     # Generic HID support options         IICHID_SAMPLING         # Workaround missing GPIO INTR support From nobody Wed Apr 24 10:01:26 2024 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 4VPZK01bG7z5H15Y for ; Wed, 24 Apr 2024 10:01:56 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from mailgate.Leidinger.net (bastille.leidinger.net [89.238.82.207]) (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 "mailgate.leidinger.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4VPZJy5qCcz3xpy; Wed, 24 Apr 2024 10:01:54 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=leidinger.net header.s=outgoing-alex header.b=M7R0PTU9; dmarc=pass (policy=quarantine) header.from=leidinger.net; spf=pass (mx1.freebsd.org: domain of Alexander@Leidinger.net designates 89.238.82.207 as permitted sender) smtp.mailfrom=Alexander@Leidinger.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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1713952903; 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=7r3pYm7X6yddKr+A2ixM1Cxvgy9UdRWKB4M+ex3laIk=; b=M7R0PTU9oAwM9McgESpQVrWJAUe/V61TBgBDpRebjdualu5kB4wI9LZd7qICTGOJ+9HCJ4 qFShq/ni0yHXQw+aZQg1jKy261WGhFr7UcdrQmrIJhwUJR2b3bFG5khKk/vAf0drlQas5k ULRrECf5jYbkgcM3xg3JaJ/4ni19LoQnn5rzBs0Bugu9dyey1/QFT/EoP3ACxIyOEyIwZ6 YqyHboCD3a+lAv6a/do9yoTEYI/YGYP8GDY7JLawLUYQc7hxPK2W+9C89zZfDJm5K2zaud jeVZvbElFojtJYuaORy/ziFfxcepWZLD6re6goFtAasJ+6KKH2NLagRuUHPQHw== Date: Wed, 24 Apr 2024 12:01:26 +0200 From: Alexander Leidinger To: Gleb Smirnoff Cc: Current Subject: Re: Strange network/socket anomalies since about a month In-Reply-To: References: <1fe609f252e7fae6d746530d5035ec0e@Leidinger.net> Message-ID: Organization: No organization, this is a private message. Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=_6b985b0e8816937697b536ffdd21ad4a"; micalg=pgp-sha256 X-Spamd-Bar: ------ X-Spamd-Result: default: False [-6.05 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.95)[-0.953]; DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine]; R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; R_SPF_ALLOW(-0.20)[+mx]; ARC_NA(0.00)[]; ASN(0.00)[asn:34240, ipnet:89.238.64.0/18, country:DE]; MIME_TRACE(0.00)[0:+,1:+,2:~]; HAS_ORG_HEADER(0.00)[]; MISSING_XM_UA(0.00)[]; DKIM_TRACE(0.00)[leidinger.net:+]; MID_RHS_MATCH_FROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_ZERO(0.00)[0]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MLMMJ_DEST(0.00)[current@freebsd.org]; TO_DN_ALL(0.00)[]; HAS_ATTACHMENT(0.00)[] X-Rspamd-Queue-Id: 4VPZJy5qCcz3xpy This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --=_6b985b0e8816937697b536ffdd21ad4a Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Am 2024-04-22 18:12, schrieb Gleb Smirnoff: > There were several preparatory commits that were not reverted and one > of them > had a bug. The bug manifested itself as failure to send(2) zero bytes > over > unix/stream. It was fixed with > e6a4b57239dafc6c944473326891d46d966c0264. Can > you please check you have this revision? Other than that there are no > known > bugs left. Yes, I have this fix in my running kernel. > A> Any ideas how to track this down more easily than running the entire > A> poudriere in ktrace (e.g. a hint/script which dtrace probes to use)? > > I don't have any better idea than ktrace over failing application. > Yep, I > understand that poudriere will produce a lot. But first we need to > determine Yes, it does. 4.4 GB just for the start of poudriere until the first package build fails due to a failed sccache start (luckily in the first builder, but I had at least 2 builders automatically spin up by poudriere at the time when I validated the failure in the logs and disabled the tracing). > what syscall fails and on what type of socket. After that we can scope > down to > using dtrace on very particular functions. I'm not sure I manage to find the cause of the failure... the only thing which remotely looks like an issue is "Resource temporarily unavailable", but this is from the process which waits for the server to have started: ---snip--- 58406 sccache 1713947887.504834367 RET __sysctl 0 58406 sccache 1713947887.505521884 CALL rfork(0x80000000<>2147483648) 58406 sccache 1713947887.505757777 CAP system call not allowed: rfork 58406 sccache 1713947887.505774176 RET rfork 58426/0xe43a 58406 sccache 1713947887.507304865 CALL compat11.kevent(0x3,0x371d360f89e8,0x2,0x371d360f89e8,0x2,0) 58406 sccache 1713947887.507657906 STRU struct freebsd11_kevent[] = { { ident=11, filter=EVFILT_READ, flags=0x61, fflags=0, data=0, udata=0x0 } { ident=11, filter=EVFILT_WRITE, flags=0x61, fflags=0, data=0, udata=0x0 } } 58406 sccache 1713947887.507689980 STRU struct freebsd11_kevent[] = { { ident=11, filter=EVFILT_READ, flags=0x4000, fflags=0, data=0, udata=0x0 } { ident=11, filter=EVFILT_WRITE, flags=0x4000, fflags=0, data=0, udata=0x0 } } 58406 sccache 1713947887.507977155 RET compat11.kevent 2 58406 sccache 1713947887.508015751 CALL write(0x5,0x371515685bcc,0x1) 58406 sccache 1713947887.508086434 GIO fd 5 wrote 1 byte 0x0000 01 |.| 58406 sccache 1713947887.508145930 RET write 1 58406 sccache 1713947887.508183140 CALL compat11.kevent(0x7,0,0,0x5a5689ab0c40,0x400,0) 58406 sccache 1713947887.508396614 STRU struct freebsd11_kevent[] = { } 58406 sccache 1713947887.508156537 STRU struct freebsd11_kevent[] = { { ident=4, filter=EVFILT_READ, flags=0x60, fflags=0, data=0x1, udata=0xffffffffffffffff } } 58406 sccache 1713947887.508530888 RET compat11.kevent 1 58406 sccache 1713947887.508563736 CALL read(0x4,0x371d3a2887c0,0x80) 58406 sccache 1713947887.508729102 GIO fd 4 read 1 byte 0x0000 01 |.| 58406 sccache 1713947887.508967661 RET read 1 58406 sccache 1713947887.508996753 CALL read(0x4,0x371d3a2887c0,0x80) 58406 sccache 1713947887.509028311 RET read -1 errno 35 Resource temporarily unavailable 58406 sccache 1713947887.509068838 CALL compat11.kevent(0x3,0,0,0x5a5689a97540,0x400,0x371d3a2887c8) ... 58406 sccache 1713947897.514352552 CALL _umtx_op(0x5a5689a3d290,0x10,0x7fffffff,0,0) 58406 sccache 1713947897.514383653 RET _umtx_op 0 58406 sccache 1713947897.514421273 CALL write(0x5,0x371515685bcc,0x1) 58406 sccache 1713947897.515050967 STRU struct freebsd11_kevent[] = { { ident=4, filter=EVFILT_READ, flags=0x60, fflags=0, data=0x1, udata=0xffffffffffffffff } } 58406 sccache 1713947897.515146151 RET compat11.kevent 1 58406 sccache 1713947897.515178978 CALL read(0x4,0x371d3a2887c0,0x80) 58406 sccache 1713947897.515368070 GIO fd 4 read 1 byte 0x0000 01 |.| 58406 sccache 1713947897.515396600 RET read 1 58406 sccache 1713947897.515426523 CALL read(0x4,0x371d3a2887c0,0x80) 58406 sccache 1713947897.515457073 RET read -1 errno 35 Resource temporarily unavailable 58406 sccache 1713947897.515004494 GIO fd 5 wrote 1 byte 0x0000 01 |.| ---snip--- https://www.leidinger.net/test/sccache.tar.bz2 contains the parts of the trace of the sccache processes (in case someone wants to have a look). The poudriere run had several builders in parallel, at least 2 were running at that point in time. What the overlay does is to startup (sccache --start-server) the sccache server process (forks to return back on the command line) which creates a file system socket, and then it queries the stats (sccache --show-stats). So some of the traces in the tarball are the server start (those with "Timed out waiting for server startup" are maybe the processes which fork to start the server and wait for it to be started), some are the stat-query, and some seem to be a successful start in another poudriere-builder (those with a successful /root/.ccache/sccache/5/4/ access look like from a successful start in another jail). Maybe there is also a --stop-server from poudriere somewhere. What I noticed (except that printing the new CAP stuff for non-CAP enabled processes by default is disturbing) is, that compat11 stuff is called (seems the rust ecosystem is not keeping up with our speed of development...). Not sure if it matters here that some compat stuff is called. Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_6b985b0e8816937697b536ffdd21ad4a Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc; size=833 Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmYo2IQACgkQEg2wmwP4 2IbLtRAAnQduZ2y4IiSCZmbfWHVePBv4ZX8tAjezWkMig6tpM3qPmpqBBEDrpsNJ l2mNMNPEeUpx7ThU4pNqBvVkYUkHGrXpI/w/i4xHO5cj/tOHANkRlQnf9WZWEqKM muvYsCz5ACvduiqYBkP2Z/Y+BD2ZoYljt7ALVUenlqGvmdWyCtDPXVP7/4ZqCCAS gveuWUY6ClX9AKxDTh46HjY1Nx3fiM8iNtP4ZTciHrXt++wmTJoPGODMxJeP0/Vd DvRTXM/zqeDKzQAhOcaa9CFoVXGq81WGgTSLU8NBHCS5Z/jClp3eiCfTtunL2Cn3 TQpvQEg2Vqz/eLWEn16d1OuMtd4PcY7aQSkMnyoVRPcg2Vu3I6rO/G74AGYdpKER btfIgpovbtBMz/TOF4gzBni+TsPpmWGjzXppbyRjKB7/Yw4vT3fUvtjMBMe7Iflt CERjAM9DVwaAx22xLPYhxaSoKe/dW7efYRVzshXTHRfr6rpt6w97OxG82C8DMJcd RAnqt2Gz62tVpjKrvyYtzeOpiOPV4u3MYmttebSjWPiNR7MAGPQISeq1pF9a7zK3 IVFVGru0ptCOKtdAEk0MMa647WbRCX1V2+fpsFiuk7qxyIZ6HvqGhNxU7LmmMeI/ q0dqRQm3952Rm5SwllDouPMC77Gmnd5rJYrR/Mh3vQakIS2SbY0= =Ql0c -----END PGP SIGNATURE----- --=_6b985b0e8816937697b536ffdd21ad4a-- From nobody Wed Apr 24 17:27:52 2024 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 4VPmCZ0kbHz5J23V for ; Wed, 24 Apr 2024 17:27:54 +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 4VPmCZ0Dfkz4s93; Wed, 24 Apr 2024 17:27:54 +0000 (UTC) (envelope-from des@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1713979674; 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=CXA024cezQfzYywH5h0Zacqy2qHYBCNtdMXWegrUoKM=; b=WbdsN6I0Ce12HhvjfGn138cunHTytJouido+65h1Y0ryPGnTujWtb21oeuK7cZFDI5xhN3 V39W9vX5akTgt/VgWwxMh9GRvqjI9gvmwpYQRLgnVxuuxmu1irQ0XPR5IqS0B32R3g8hzN vfJ8oZNYyHQxI66UWK9OUaqAVDWG7uPvOL6d7MowbZXGD2BIiBI2PHdCffbQCpnSwhyl/h 4/j4LZ6/2mUekUx6m+Tlqzz8vGd2XuJhm7CzvVT6w4DZsmFPl+1SDwzVtjsbbIaVxr/6qh pyqUdY4o5UZ8LZNqxH1oikTkGtcl+pDVyoWSYrsMKaNb92Sik7NqcJ2gYhhu1A== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1713979674; a=rsa-sha256; cv=none; b=B+HiGPGyqAeQQjgaIR4FXneIA37yTH5mZColjO5CQ9SFK4I9kcNTSavENNJm4YmJ/aB7+1 O/pMZaggw/yuNVUijMXi9tY/8ZoVzSJ4p+8r6fy5mnGaEwL82cIBWlTxj6kNqADt/udyOY Jrhjq5QaT51AfAgcDL9rWyzscl1vEyai0aVQDSyZHvSkKHCG5PlfFoJxzwazpJpsnSsUMT tYiGrs9XotOCfVW4mA00Of0yLKqa8mBN5rypablmbgiPCqNvMQK5A9s718e7cuit1/by4m 8A20YjIKZFTHhWXWUm+TDKTxEiuinBneARFzj3g/jNXUuA0fJkbBE80zc2Nd3w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1713979674; 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=CXA024cezQfzYywH5h0Zacqy2qHYBCNtdMXWegrUoKM=; b=jpdDT0W/pCPsx4exCXTKwoGb6fO5o8pk4ma3D8gHC6HTuD8bfIfD1nODzbHfkqnUViCLd5 MT7R+S9zlts72AKysIRP7PCIlSF3vIEKNBFnOQQ7UZdIfOJuRSsLr5xe+BGPoPulH3Wark LGEhfrJxCI2Gk2Pkli9/gdMdeHcxJ0zp4tIs0odaz6IR/N2A73+tiul7XxOEzdYm7jbgjG LdsBslWT6mWKIqxoBvT7WFhpEW4wLQjw6y8/267MpDTpRA8oE+SKSxk/F3A0VaZX2YBgQK c+Gt5UdPypfjWZdlmXYqA2JyOnpehYemLWLlpzWg6BNH7R24znIuianD0M7jwg== Received: from ltc.des.dev (2a02-8428-0993-f001-922e-16ff-fef1-acef.rev.sfr.net [IPv6:2a02:8428:993:f001:922e:16ff:fef1:acef]) (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 4VPmCY6CVJz1P1Q; Wed, 24 Apr 2024 17:27:53 +0000 (UTC) (envelope-from des@freebsd.org) Received: by ltc.des.dev (Postfix, from userid 1001) id 2FB491F2A8; Wed, 24 Apr 2024 19:27:52 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Alexander Leidinger Cc: Gleb Smirnoff , Current Subject: Re: Strange network/socket anomalies since about a month In-Reply-To: (Alexander Leidinger's message of "Wed, 24 Apr 2024 12:01:26 +0200") References: <1fe609f252e7fae6d746530d5035ec0e@Leidinger.net> User-Agent: Gnus/5.13 (Gnus v5.13) Date: Wed, 24 Apr 2024 19:27:52 +0200 Message-ID: <868r127js7.fsf@ltc.des.dev> 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 Alexander Leidinger writes: > Gleb Smirnoff writes: > > I don't have any better idea than ktrace over failing application. > > Yep, I understand that poudriere will produce a lot. > Yes, it does. 4.4 GB just for the start of poudriere until the first > package build fails due to a failed sccache start [...] Using `ktrace -tcnpstuy` instead of just `ktrace` should greatly reduce the size of the trace file. (remind me to modify ktrace and kdump so this can be written as `-t-i` or `-tI` instead...) DES --=20 Dag-Erling Sm=C3=B8rgrav - des@FreeBSD.org From nobody Wed Apr 24 19:09:29 2024 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 4VPpT44Yltz5J9Zt for ; Wed, 24 Apr 2024 19:09:44 +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 4VPpT35mVvz47fj for ; Wed, 24 Apr 2024 19:09:43 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 43OJ9UHm050555; Wed, 24 Apr 2024 22:09:33 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 43OJ9UHm050555 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 43OJ9TTD050554; Wed, 24 Apr 2024 22:09:29 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 24 Apr 2024 22:09:29 +0300 From: Konstantin Belousov To: BSD USER Cc: freebsd-current@freebsd.org Subject: Re: TXT Kernel linking failed on -CURRENT Message-ID: References: <3a18f625-1441-414b-adb4-6321687f9fa7@yandex.ru> 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: <3a18f625-1441-414b-adb4-6321687f9fa7@yandex.ru> 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-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] X-Rspamd-Queue-Id: 4VPpT35mVvz47fj On Wed, Apr 24, 2024 at 01:12:39PM +0500, BSD USER wrote: > linking kernel > ld: error: undefined symbol: ktrcapfail > >>> referenced by vfs_lookup.c > >>>               vfs_lookup.o:(namei) > >>> referenced by vfs_lookup.c > >>>               vfs_lookup.o:(namei_setup) > >>> referenced by vfs_lookup.c > >>>               vfs_lookup.o:(vfs_lookup) > >>> referenced 3 more times > *** [kernel] Error code 1 Try https://reviews.freebsd.org/D44931 From nobody Thu Apr 25 19:17:47 2024 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 4VQQck6b2Tz5JMjx for ; Thu, 25 Apr 2024 19:18:30 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp6.goneo.de (smtp6.goneo.de [IPv6:2001:1640:5::8:31]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4VQQcj0r9Lz4fgs for ; Thu, 25 Apr 2024 19:18:28 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=walstatt-de.de header.s=DKIM001 header.b=cMBIAq8j; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd@walstatt-de.de designates 2001:1640:5::8:31 as permitted sender) smtp.mailfrom=freebsd@walstatt-de.de Received: from hub1.goneo.de (hub1.goneo.de [IPv6:2001:1640:5::8:52]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by smtp6.goneo.de (Postfix) with ESMTPS id 0903A240A82 for ; Thu, 25 Apr 2024 21:18:20 +0200 (CEST) Received: from hub1.goneo.de (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPS id 1DCA22400D5 for ; Thu, 25 Apr 2024 21:18:15 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1714072695; 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=JmaJlVd1EKcoM6xM1L9kt/7XgCEmxkA8zDF9QcK39jE=; b=cMBIAq8juUmDHIeaSohgJ2E98P7TZgF2nJUtxDtc7gzkAcTPdaz/8jP0JpExOKe86ckN1Q 8LzjtLtTCyX5Yg1Mt/upFDo05OcVnmWrGf6NFdVvlGeNrc+ODs6Z0FHYxxH/5Kq+vPKn9O 2gDYba3zHiag8d9bFJnQiQtji8yCGaztowUVBUSvX438e9/FjSnVdtNtiaHp81y9fXUb6M sUBJlVeyBbZzp0a6sNPZoVZvlA27ztlME3SAa90uR1ydxEh8fDZiH+CqucPCgrp4Nw+023 0poa7cuGLIWk9YC8wXDOl6c3rrRU1BVMYhov0lxBsE2E5ANiPe/kbMuLKoZn8w== Received: from thor.intern.walstatt.dynvpn.de (dynamic-077-191-152-126.77.191.pool.telefonica.de [77.191.152.126]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPSA id D7D58240036 for ; Thu, 25 Apr 2024 21:18:14 +0200 (CEST) Date: Thu, 25 Apr 2024 21:17:47 +0200 From: FreeBSD User To: FreeBSD CURRENT Subject: serial/ulscom: response timeout using pySerial/esptool.py Message-ID: <20240425211814.539cccb7@thor.intern.walstatt.dynvpn.de> Organization: walstatt-de.de List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-UID: dbf9e4 X-Rspamd-UID: 206b7b X-Spamd-Bar: --- 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)[-1.000]; R_DKIM_ALLOW(-0.20)[walstatt-de.de:s=DKIM001]; R_SPF_ALLOW(-0.20)[+ip6:2001:1640:5::8:0/112]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_ONE(0.00)[1]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_ORG_HEADER(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:25394, ipnet:2001:1640::/32, country:DE]; MISSING_XM_UA(0.00)[]; RCVD_TLS_ALL(0.00)[]; DMARC_NA(0.00)[walstatt-de.de]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[walstatt-de.de:+] X-Rspamd-Queue-Id: 4VQQcj0r9Lz4fgs Hello, Host: 15.0-CURRENT FreeBSD 15.0-CURRENT #36 main-n269703-54c3aa02e926: Thu Apr 25 18:48:56 CEST 2024 amd64 or 14-STABLE recently compiled (dmesg/uname not at hand). Hardware: oldish Z77Pro 4 based Asrock mainboard, a Lenovo T560 notebook, Fujitsu Esprimo Q5XX (simple desktop, Pentium Gold) or an oldish Fujitsu Celsius 7XX workstation, 6 core Haswell XEON. Phenomenon: a couple of weeks now I try to connect to several Xtensa ESP32 dev boards (ESP32-WROOM32 with CP2101 or CP2104 UART) via comms/py-esptool (doesn't matter whether it is tho port's py39-esptool 4.5 or the latest py-esptool 4.7.0, doesn't matter whether pkg package or self compiled on CURRENT and 14-STABLE, on all hardware platforms same result). Attaching the ESP devel module via Micro USB cable (several type, differnt vendors tried ...) show dmesg: [...] ugen0.4: at usbus0 uslcom0 on uhub3 uslcom0: on usbus0 [...] When trying to connect to the ESP32 via below shown command (--trace not every time issued), I get no connection: [ohartmann]: esptool.py --trace --chip esp32 --baud 115200 --port /dev/cuaU1 flash_id esptool.py v4.7.0 Loaded custom configuration from /pool/home/ohartmann/esptool.cfg Serial port /dev/cuaU1 Connecting...TRACE +0.000 command op=0x08 data len=36 wait_response=1 timeout=0.100 data= 0707122055555555 5555555555555555 | ... UUUUUUUUUUUU 5555555555555555 5555555555555555 | UUUUUUUUUUUUUUUU 55555555 | UUUU TRACE +0.000 Write 46 bytes: c000082400000000 0007071220555555 | ...$........ UUU 5555555555555555 5555555555555555 | UUUUUUUUUUUUUUUU 5555555555555555 5555555555c0 | UUUUUUUUUUUUU. TRACE +0.102 No serial data received. .TRACE +0.052 command op=0x08 data len=36 wait_response=1 timeout=0.100 data= 0707122055555555 5555555555555555 | ... UUUUUUUUUUUU 5555555555555555 5555555555555555 | UUUUUUUUUUUUUUUU 55555555 | UUUU TRACE +0.000 Write 46 bytes: c000082400000000 0007071220555555 | ...$........ UUU 5555555555555555 5555555555555555 | UUUUUUUUUUUUUUUU 5555555555555555 5555555555c0 | UUUUUUUUUUUUU. TRACE +0.107 No serial data received. .TRACE +0.054 command op=0x08 data len=36 wait_response=1 timeout=0.100 data= 0707122055555555 5555555555555555 | ... UUUUUUUUUUUU 5555555555555555 5555555555555555 | UUUUUUUUUUUUUUUU 55555555 | UUUU TRACE +0.000 Write 46 bytes: c000082400000000 0007071220555555 | ...$........ UUU 5555555555555555 5555555555555555 | UUUUUUUUUUUUUUUU 5555555555555555 5555555555c0 | UUUUUUUUUUUUU. TRACE +0.107 No serial data received. .TRACE +0.054 command op=0x08 data len=36 wait_response=1 timeout=0.100 data= 0707122055555555 5555555555555555 | ... UUUUUUUUUUUU 5555555555555555 5555555555555555 | UUUUUUUUUUUUUUUU 55555555 | UUUU TRACE +0.000 Write 46 bytes: c000082400000000 0007071220555555 | ...$........ UUU 5555555555555555 5555555555555555 | UUUUUUUUUUUUUUUU 5555555555555555 5555555555c0 | UUUUUUUUUUUUU. A serial exception error occurred: device reports readiness to read but returned no data (device disconnected or multiple access on port?) Note: This error originates from pySerial. It is likely not a problem with esptool, but with the hardware connection or drivers. For troubleshooting steps visit: https://docs.espressif.com/projects/esptool/en/latest/troubleshooting.html [...] Whatever baud rate issued, in most cases on all tested OS versions and almost all hardware platforms except the Fujistu Celsius 7XX (2015 model) I do not get any connection! And it get more weird: To avoid out-of-sync-software I recompiled everything via "portmaster -df comms/py-pyserial comms/py-esptool" and after that, everything was fine, the connection was made, I got results out of the chip. Seconds later same problems. I exchanged cablings, exchanged the ESP32 model and vendor. Invariants are 14-STABLE, daily compiled, CURRENT. daily compiled. On my private box (old Z77 based IvyBridge ASRock crap), a couple of Lenovo T560 running 14-STABLE and several Fujitsu Esprimo Q5XX boxes there is always this weird error message, but in very rare cases I get connection. Only exception: the Fujsitus Celsius 7XX workstation (14-STABLE, last complied today noon). No matter what ESP32, no matter what vendor, no matter what cablin used: connection is established at any BAUD rate issued at any time. Not one single failure as shown above in any session (I checked several tenth times)! Now I'm out of ideas and I suspect the CP210X ulscom serial driver to have trouble with most onboard serial chipsets. Can anyone help me track down this issue? Is there anything I could have missed? I drives me nuts ... Thanks in advance, Oliver -- O. Hartmann From nobody Thu Apr 25 19:51:21 2024 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 4VQRLw6fTLz5JQbq for ; Thu, 25 Apr 2024 19:51:36 +0000 (UTC) (envelope-from tomek@cedro.info) 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 4VQRLw2jpwz4ljh for ; Thu, 25 Apr 2024 19:51:36 +0000 (UTC) (envelope-from tomek@cedro.info) Authentication-Results: mx1.freebsd.org; none Received: by mail-yb1-xb2d.google.com with SMTP id 3f1490d57ef6-de59daab3f3so692976276.3 for ; Thu, 25 Apr 2024 12:51:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cedro.info; s=google; t=1714074694; x=1714679494; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=WuLax9rSIl/5/E7gv/Z7Rs6mcofqfKZUB7kQyBBVobU=; b=UMs9ROQ5kJg8u0SN6UKNfTyMset6WQm/mF0ndM1HDYVtgeO6K8vA3PqUo08gVRzzDH zAWL4zFNZ90EpsOe2Oy6t6mc4VBpHilk/r/GGsrCrhnx/dRWEzxJKFZP4UoquROJpv7R fCbDmgx5wHG9wRx9qgXoiUZ+G24qdXFEzUppHHrWv6FYqwqrYDpfmrmN/AAhALKSKjpN daxN9iGJICAe5bzQicT9qyIqvMDG3pR4HzJvTrimZgeg/qG0JVeZrdWCvekRtJF8xOab mhk+7/szO35/lyRVy7TCyApxqoZ7Zt9+Ad+G1LssQ4y4ggLBdaPR9f1V9JHClzz5AMrZ kqXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714074694; x=1714679494; 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=WuLax9rSIl/5/E7gv/Z7Rs6mcofqfKZUB7kQyBBVobU=; b=CIR0I2rWObRMOh/3wbO/Ec8yGUeJANKA1RD+GVR/oWG5zPO0kKy2kkQvltgu8RfMmj 6PP4HOFjNVk4uiTRv3hN5bsMWZH9LH0SydGIrKCQup1okebl9K+uqxNBGpXhiYMgpVS0 JtgIm1hI9zNRaCUCqEhz/1xuQ5RUq9SowFM1iMiuBiwK69zWeBOEgVb6nM7BWR1e3r3t abfywlakD7qooYqa0hYtcGo3e88o4yGGp1htzcR3eC6ABQ5kiajuqrYgqmbb1976jWP1 Ev4xYC60IwyRu30y+UB65bOg9LDMBVYk1ZEylmHXO5/VItvSWi1hx4IBLd2BUeVJ9b+j X8Jg== X-Gm-Message-State: AOJu0YzsU/Sy/Zyu3zS7Cwv77jTyxv9MRD8ZeJgjalHFD4jGnbCmokwf 9VJFoqPr4zHu7fg2c9V427mfEG3ssR7/7b5R1PhIPe8GgW71juYoc4lc4iUYrp6XmnDwgIsQ60o = X-Google-Smtp-Source: AGHT+IF3T/JBug8PXZb/XnW1z9ZKyr8eednzwazNfyzJgKCQrfqPLYuJPbOj0QED9IRYL029mxT3XA== X-Received: by 2002:a25:84c3:0:b0:dcc:79ab:e51a with SMTP id x3-20020a2584c3000000b00dcc79abe51amr706022ybm.57.1714074694535; Thu, 25 Apr 2024 12:51:34 -0700 (PDT) Received: from mail-yb1-f170.google.com (mail-yb1-f170.google.com. [209.85.219.170]) by smtp.gmail.com with ESMTPSA id v69-20020a25c548000000b00dcf27be1d1bsm3944101ybe.28.2024.04.25.12.51.33 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 25 Apr 2024 12:51:34 -0700 (PDT) Received: by mail-yb1-f170.google.com with SMTP id 3f1490d57ef6-de59daab3f3so692964276.3 for ; Thu, 25 Apr 2024 12:51:33 -0700 (PDT) X-Received: by 2002:a25:df48:0:b0:de5:49a4:8a9d with SMTP id w69-20020a25df48000000b00de549a48a9dmr722238ybg.39.1714074693632; Thu, 25 Apr 2024 12:51:33 -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: <20240425211814.539cccb7@thor.intern.walstatt.dynvpn.de> In-Reply-To: <20240425211814.539cccb7@thor.intern.walstatt.dynvpn.de> From: Tomek CEDRO Date: Thu, 25 Apr 2024 21:51:21 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: serial/ulscom: response timeout using pySerial/esptool.py To: FreeBSD User Cc: FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" 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] X-Rspamd-Queue-Id: 4VQRLw2jpwz4ljh CP2102 are pretty good ones and never let me down :-) Is your UART connection to ESP32 working correctly? Can you see the boot message and whatever happens next in terminal (cu / minicom)? Are RX TX pins not swapped? Power supply okay? Are boards generic devkits of custom hardware? ESP32 in addition to RX TX needs two control lines Reset and Boot that will switch the chip to bootloader / flashing mode. Most USB-to-UART use RTS/CTS lines for that. Are you sure these lines are available on your board and connected to the target correctly? Do you have Reset and Boot buttons on the board so you could trigger bootloader by hand (hold Boot, press and release Reset, device will be in bootloader upload mode, retry esptool flashing now). You can also play with the buttons with active terminal attached (i.e. minicom) to see if they work as expected. Minicom serial terminal is pretty cool as it allows you to watch UART behavior on adapter (un)plug. In minicom you can also enable/disable hardware flow control lines (Ctrl+A O -> Serial Port Setup -> (F) Hardware Flow Control). You can switch that easily and watch the target behavior. If this is the problem you may want to use stty (1) to enable/disable hardware flow control on the port. Can you try with another board? ESP32 has fuses that may permanently disable and/or mess up some hardware features. -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From nobody Thu Apr 25 21:05:07 2024 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 4VQT0B2P1hz5JYW7 for ; Thu, 25 Apr 2024 21:05:30 +0000 (UTC) (envelope-from thj@freebsd.org) Received: from fout5-smtp.messagingengine.com (fout5-smtp.messagingengine.com [103.168.172.148]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4VQT095V8Zz4tXn for ; Thu, 25 Apr 2024 21:05:29 +0000 (UTC) (envelope-from thj@freebsd.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=messagingengine.com header.s=fm3 header.b="E xahpJd"; dmarc=fail reason="No valid SPF, DKIM not aligned (relaxed)" header.from=freebsd.org (policy=none); spf=softfail (mx1.freebsd.org: 103.168.172.148 is neither permitted nor denied by domain of thj@freebsd.org) smtp.mailfrom=thj@freebsd.org Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailfout.nyi.internal (Postfix) with ESMTP id 5CA451380252 for ; Thu, 25 Apr 2024 17:05:28 -0400 (EDT) Received: from imap47 ([10.202.2.97]) by compute3.internal (MEProxy); Thu, 25 Apr 2024 17:05:28 -0400 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:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1714079128; x= 1714165528; bh=g/uaF1VEJQDpcuMUrDQ66xIC2QBwAZSxR94n2Kd9DPk=; b=E xahpJdVogY9KdERnfQuvsYrY78fiLxnDgYWwJ0IS/UL5rc1YmyNLmCUWC6RDXdTQ i57ZiimOuYnv0KGMyMXKrpBSbZeb0TzlUFpCit2m6+Eupbb749FQRQdBATXOWzCt eHotehiXv4HEiyZ1q9ZFT6Z9DaFmFPtcMFr9xcMa/hTaWjqGKX+ZgugqDIs03edS 8AxsMn4/hVsIfx28iJhXv1vGMQXXcqQ8WzkNzAy5Jyflg531zso5VXcTcvlw2wst kGL8iZnMc7GP4+3om9kjnGoqw4wzk7BADkpybw4fP0Bc9VUhYU90LtHTKItyvJsL veoHvM2HYixJ6bF0BN7aA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrudeljedgudehkecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgse htqhertderreejnecuhfhrohhmpedfvfhomhculfhonhgvshdfuceothhhjhesfhhrvggv sghsugdrohhrgheqnecuggftrfgrthhtvghrnhepgffhteevieetkeehheelteefkefggf ehheejheelteeutdevfedulefgfedvhfffnecuffhomhgrihhnpegvshhprhgvshhsihhf rdgtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh epthhhjhesfhhrvggvsghsugdrohhrgh X-ME-Proxy: Feedback-ID: ib75146ab:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 0A26BA60078; Thu, 25 Apr 2024 17:05:27 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.11.0-alpha0-386-g4cb8e397f9-fm-20240415.001-g4cb8e397 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 Message-Id: In-Reply-To: <20240425211814.539cccb7@thor.intern.walstatt.dynvpn.de> References: <20240425211814.539cccb7@thor.intern.walstatt.dynvpn.de> Date: Thu, 25 Apr 2024 22:05:07 +0100 From: "Tom Jones" To: freebsd-current@freebsd.org Subject: Re: serial/ulscom: response timeout using pySerial/esptool.py Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.25 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.96)[-0.965]; R_DKIM_ALLOW(-0.20)[messagingengine.com:s=fm3]; RCVD_IN_DNSWL_LOW(-0.10)[103.168.172.148:from]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : No valid SPF, DKIM not aligned (relaxed),none]; XM_UA_NO_VERSION(0.01)[]; MIME_TRACE(0.00)[0:+]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim]; FREEFALL_USER(0.00)[thj]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:209242, ipnet:103.168.172.0/24, country:US]; FROM_HAS_DN(0.00)[]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; R_SPF_SOFTFAIL(0.00)[~all:c]; FROM_EQ_ENVFROM(0.00)[]; TO_DOM_EQ_FROM_DOM(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[messagingengine.com:+] X-Rspamd-Queue-Id: 4VQT095V8Zz4tXn Can you isolate out the extraneous stuff and loop tx and rx on a CP2101 = board and send bytes through?=20 I did a bunch of development on an esp8266 board in the last few weeks a= nd had no issues, but I=E2=80=99ve no idea if it were the same usb seria= l chip.=20 I=E2=80=99ll have a dig around and see if I have something matching=20 On Thu, Apr 25, 2024, at 20:17, FreeBSD User wrote: > Hello, > > Host: 15.0-CURRENT FreeBSD 15.0-CURRENT #36 main-n269703-54c3aa02e926:=20 > Thu Apr 25 18:48:56 > CEST 2024 amd64 or 14-STABLE recently compiled (dmesg/uname not at=20 > hand). > > Hardware: oldish Z77Pro 4 based Asrock mainboard, a Lenovo T560=20 > notebook, Fujitsu Esprimo Q5XX > (simple desktop, Pentium Gold) or an oldish Fujitsu Celsius 7XX=20 > workstation, 6 core Haswell > XEON. > > Phenomenon: a couple of weeks now I try to connect to several Xtensa=20 > ESP32 dev boards > (ESP32-WROOM32 with CP2101 or CP2104 UART) via comms/py-esptool=20 > (doesn't matter whether it is > tho port's py39-esptool 4.5 or the latest py-esptool 4.7.0, doesn't=20 > matter whether pkg package > or self compiled on CURRENT and 14-STABLE, on all hardware platforms=20 > same result). > > Attaching the ESP devel module via Micro USB cable (several type,=20 > differnt vendors tried ...) > show > > dmesg: > [...] > ugen0.4: at usbus0 > uslcom0 on uhub3 > uslcom0: rev 1.10/1.00, addr 4> > on usbus0 > [...] > > When trying to connect to the ESP32 via below shown command (--trace=20 > not every time issued), I > get no connection: > > [ohartmann]: esptool.py --trace --chip esp32 --baud 115200 --port=20 > /dev/cuaU1 flash_id > esptool.py v4.7.0 > Loaded custom configuration from /pool/home/ohartmann/esptool.cfg > Serial port /dev/cuaU1 > Connecting...TRACE +0.000 command op=3D0x08 data len=3D36 wait_respons= e=3D1=20 > timeout=3D0.100 data=3D > 0707122055555555 5555555555555555 | ... UUUUUUUUUUUU > 5555555555555555 5555555555555555 | UUUUUUUUUUUUUUUU > 55555555 | UUUU > TRACE +0.000 Write 46 bytes:=20 > c000082400000000 0007071220555555 | ...$........ UUU > 5555555555555555 5555555555555555 | UUUUUUUUUUUUUUUU > 5555555555555555 5555555555c0 | UUUUUUUUUUUUU. > TRACE +0.102 No serial data received. > TRACE +0.052 command op=3D0x08 data len=3D36 wait_response=3D1 timeout= =3D0.100=20 > data=3D > 0707122055555555 5555555555555555 | ... UUUUUUUUUUUU > 5555555555555555 5555555555555555 | UUUUUUUUUUUUUUUU > 55555555 | UUUU > TRACE +0.000 Write 46 bytes:=20 > c000082400000000 0007071220555555 | ...$........ UUU > 5555555555555555 5555555555555555 | UUUUUUUUUUUUUUUU > 5555555555555555 5555555555c0 | UUUUUUUUUUUUU. > TRACE +0.107 No serial data received. > TRACE +0.054 command op=3D0x08 data len=3D36 wait_response=3D1 timeout= =3D0.100=20 > data=3D > 0707122055555555 5555555555555555 | ... UUUUUUUUUUUU > 5555555555555555 5555555555555555 | UUUUUUUUUUUUUUUU > 55555555 | UUUU > TRACE +0.000 Write 46 bytes:=20 > c000082400000000 0007071220555555 | ...$........ UUU > 5555555555555555 5555555555555555 | UUUUUUUUUUUUUUUU > 5555555555555555 5555555555c0 | UUUUUUUUUUUUU. > TRACE +0.107 No serial data received. > TRACE +0.054 command op=3D0x08 data len=3D36 wait_response=3D1 timeout= =3D0.100=20 > data=3D > 0707122055555555 5555555555555555 | ... UUUUUUUUUUUU > 5555555555555555 5555555555555555 | UUUUUUUUUUUUUUUU > 55555555 | UUUU > TRACE +0.000 Write 46 bytes:=20 > c000082400000000 0007071220555555 | ...$........ UUU > 5555555555555555 5555555555555555 | UUUUUUUUUUUUUUUU > 5555555555555555 5555555555c0 | UUUUUUUUUUUUU. > > > A serial exception error occurred: device reports readiness to read bu= t=20 > returned no data > (device disconnected or multiple access on port?) Note: This error=20 > originates from pySerial. > It is likely not a problem with esptool, but with the hardware=20 > connection or drivers. For > troubleshooting steps visit: > https://docs.espressif.com/projects/esptool/en/latest/troubleshooting.= html > [...] > > > Whatever baud rate issued, in most cases on all tested OS versions and=20 > almost all hardware > platforms except the Fujistu Celsius 7XX (2015 model) I do not get any=20 > connection! And it get > more weird: To avoid out-of-sync-software I recompiled everything via=20 > "portmaster -df > comms/py-pyserial comms/py-esptool" and after that, everything was=20 > fine, the connection was > made, I got results out of the chip. Seconds later same problems. > > I exchanged cablings, exchanged the ESP32 model and vendor. Invariants=20 > are 14-STABLE, daily > compiled, CURRENT. daily compiled. On my private box (old Z77 based=20 > IvyBridge ASRock crap), a > couple of Lenovo T560 running 14-STABLE and several Fujitsu Esprimo=20 > Q5XX boxes there is always > this weird error message, but in very rare cases I get connection. > > Only exception: the Fujsitus Celsius 7XX workstation (14-STABLE, last=20 > complied today noon). No > matter what ESP32, no matter what vendor, no matter what cablin used:=20 > connection is established > at any BAUD rate issued at any time. Not one single failure as shown=20 > above in any session (I > checked several tenth times)! > > Now I'm out of ideas and I suspect the CP210X ulscom serial driver to=20 > have trouble with most > onboard serial chipsets. > > Can anyone help me track down this issue? Is there anything I could ha= ve missed? > > I drives me nuts ... > > Thanks in advance, > > Oliver > >=20 > --=20 > O. Hartmann --=20 - Tom From nobody Fri Apr 26 02:49:23 2024 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 4VQcdC67V3z5HNYb for ; Fri, 26 Apr 2024 02:49:35 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0: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 4VQcdB5llJz4TWy for ; Fri, 26 Apr 2024 02:49:34 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=VCFc6ecd; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2607:f8b0:4864:20::52d as permitted sender) smtp.mailfrom=rick.macklem@gmail.com Received: by mail-pg1-x52d.google.com with SMTP id 41be03b00d2f7-5bdbe2de25fso1256655a12.3 for ; Thu, 25 Apr 2024 19:49:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1714099773; x=1714704573; darn=freebsd.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=YKvYoW1nBY1SWrg8dQT23zzYW1+uO3OJ2Zvwa0bobfA=; b=VCFc6ecd/0YYZd37Mz03uZPdleDiFzVK6brO6g5Bw2pL3bwyteRrwebNkzv1R0BwH7 TWOwHvISMfPCya+I8QgI225ipMxgqjhElIYjBCGS3CuUt5scqgdIKN0cDqKQEDlk6aSz A07TWpswrR/LgU79IyYIWNSWjvhCfDC6noLMZElS0EGxKD06pcNcjyr53PyNUtyLPQZw y79fyyTJ/JhN3/H9JJC674pmveI2+jV9f7ByjUj8linKwmoQ5bsXDQgp9XGYkpkk6GOT /eolMMiFC2rZyB8P2SO9Oi/10Sq3+6SBd7VnB9i+/ikY6CTUwBUvaf8Rlfaoag8v31nb A5XA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714099773; x=1714704573; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=YKvYoW1nBY1SWrg8dQT23zzYW1+uO3OJ2Zvwa0bobfA=; b=ieI9Syl/mqtdtWuTHwUYyAU+7INyzGC7znOtrgXGNQunKcvS7wEYxlgxcd9AwkNXF6 /FYuu0PNdAzJWjbhhE43/UUUH1y9eFMnhvmkOVXgcLlh543P9XA0kZjhUr33Tw0Zj1zE s7FHLv6bRcca2R7p96fKkyJCwuCpwD39IterydKprJCaMAdLnUH0u5e67DKiRqkFpeDe daUJTFXBUZiJrUNwm7wCKQQ3jMwfr9heSKWPqMwVenjcBZLyzmP2NPCIcGCLI8bEJrte uQTNCRJSEWP60U4p2JDqBYQJKlMjLB4Fn9ips8GYnRlIG+ny+qOgk+Z8rdDgIP3VbGil Itkg== X-Gm-Message-State: AOJu0Ywnab5uRt1arRoTICpNX06pkKSxAt3A2DMPkop9zFNjGVAIaBmO znnoxpn6V/YcnopjyX4HxZZpHnTTZDF31yt5NUm8Y8NOcZc3a0WUf5S1bIlEyYagjKEsudGTzgb E6yS/aA5YopnXIFj+fp806ihZaJtG X-Google-Smtp-Source: AGHT+IFcac8hcN5I/X2eAzIDb4eWylahfLDpC7RM5gyfGetBkyx8q6GT3xzy5KX2t6Yzk/sA9xuFzanaV2wgyFKqmjI= X-Received: by 2002:a05:6a21:3a43:b0:1a9:3e7a:b0fc with SMTP id zu3-20020a056a213a4300b001a93e7ab0fcmr1953972pzb.51.1714099772734; Thu, 25 Apr 2024 19:49:32 -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: Rick Macklem Date: Thu, 25 Apr 2024 19:49:23 -0700 Message-ID: Subject: mysterious setting of B_DIRECT? To: FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.99 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.993]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_ONE(0.00)[1]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_ALL(0.00)[]; MISSING_XM_UA(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; TAGGED_FROM(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::52d:from] X-Rspamd-Queue-Id: 4VQcdB5llJz4TWy Hi, This week I have been doing active testing as a part of an IETF bakeathon for NFSv4. During the week I had a NFSv4 client crash. On the surface, it is straightforward, in that it called ncl_doio_directwrite() and the field called b_caller1 was NULL. Now, here's the weird part... ncl_doio_directwrite() should never be called because B_DIRECT should never be set. (The only place B_DIRECT gets set in the code is never currently executed.) I have a patch that clears out the "never to be executed" code and this seems to avoid the patch, since with the patch, ncl_doio_directwrite() no longer exists. What I cannot figure out is how B_DIRECT got set? I can note that UFS was under heavy load when the client crashed, but I cannot see how a UFS "struct buf" would become a NFS "struct buf" without b_flags being set to 0. Anyone have any ideas? rick From nobody Fri Apr 26 03:09:34 2024 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 4VQd4X3nHlz5HQ7j for ; Fri, 26 Apr 2024 03:09:48 +0000 (UTC) (envelope-from kib@freebsd.org) 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 4VQd4W50nsz4XQ2 for ; Fri, 26 Apr 2024 03:09:47 +0000 (UTC) (envelope-from kib@freebsd.org) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=freebsd.org (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kib@freebsd.org) smtp.mailfrom=kib@freebsd.org Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 43Q39YV8027056; Fri, 26 Apr 2024 06:09:37 +0300 (EEST) (envelope-from kib@freebsd.org) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 43Q39YV8027056 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 43Q39Y7r027055; Fri, 26 Apr 2024 06:09:34 +0300 (EEST) (envelope-from kib@freebsd.org) X-Authentication-Warning: tom.home: kostik set sender to kib@freebsd.org using -f Date: Fri, 26 Apr 2024 06:09:34 +0300 From: Konstantin Belousov To: Rick Macklem Cc: FreeBSD CURRENT Subject: Re: mysterious setting of B_DIRECT? Message-ID: References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=4.0.0 X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on tom.home X-Spamd-Bar: - X-Spamd-Result: default: False [-2.00 / 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)[-0.996]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : No valid SPF, No valid DKIM,none]; HAS_XAW(0.00)[]; ARC_NA(0.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; MISSING_XM_UA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; FREEFALL_USER(0.00)[kib]; TAGGED_RCPT(0.00)[]; R_DKIM_NA(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; R_SPF_SOFTFAIL(0.00)[~all:c]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_TLS_LAST(0.00)[] X-Rspamd-Queue-Id: 4VQd4W50nsz4XQ2 On Thu, Apr 25, 2024 at 07:49:23PM -0700, Rick Macklem wrote: > Hi, > > This week I have been doing active testing as a part of an IETF > bakeathon for NFSv4. During the week I had a NFSv4 client > crash. On the surface, it is straightforward, in that it called > ncl_doio_directwrite() and the field called b_caller1 was NULL. > > Now, here's the weird part... > ncl_doio_directwrite() should never be called because B_DIRECT > should never be set. (The only place B_DIRECT gets set in the code > is never currently executed.) Do you mean the place in nfs_directio_write()? And the fact that IO_SYNC is always set. > > I have a patch that clears out the "never to be executed" code and > this seems to avoid the patch, since with the patch, ncl_doio_directwrite() > no longer exists. > > What I cannot figure out is how B_DIRECT got set? > I can note that UFS was under heavy load when the client crashed, > but I cannot see how a UFS "struct buf" would become a NFS "struct buf" > without b_flags being set to 0. There are also vfs_bio_brelse()/vfs_bio_setflags() functions which can set B_DIRECT. On the other hand, they are not used by nfs client. What was the overall state of the buffer with the B_DIRECT flag? Which vnode it was assigned to? From nobody Fri Apr 26 03:51:55 2024 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 4VQf1L6kz1z5HldK for ; Fri, 26 Apr 2024 03:52:06 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-pf1-x431.google.com (mail-pf1-x431.google.com [IPv6:2607:f8b0:4864:20::431]) (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 4VQf1L1z8Cz4ckS; Fri, 26 Apr 2024 03:52:06 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pf1-x431.google.com with SMTP id d2e1a72fcca58-6ed0e9ccca1so1643215b3a.0; Thu, 25 Apr 2024 20:52:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1714103525; x=1714708325; darn=freebsd.org; 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=u4hDkyQQil4QJrg0rGEBWy7PxibZtKbVtRkkWsbPRwM=; b=O85L34Zz+LsihciuJQ0GXboD3YZNaD5LHT6i1bH2WYYTHORm072hHEmjbEvddEIXB5 f72eZMu1vhb6mCFQKtPvMTqUywo3dAoFpDDR7ILWsJiQV+QGSdV68q5Ac2B2JV1nXLbr m19sEi7lx9M/VqUjxZqV2f4WuNjVPgtedhbYulCwpLTley5pMXz7AEm70Zw7KigLCyXY HP3MEl2+ycqx+GcAQwCzofptmbyo2NprMFXdjBL6rYx+Lc+tRDQ3kOLohkB9y4tBcGzq G4SPOFFcagoY9BnMzABkKo9ecel5D7s3qQwHQincO20b7UZDBkJO0A9iV0WT11+JPaLl qpdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714103525; x=1714708325; 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=u4hDkyQQil4QJrg0rGEBWy7PxibZtKbVtRkkWsbPRwM=; b=vO1LtxhzmkeWvUl5d37QRteZKagMWG/QNOfZnhxD95YmC0/bwaYD6ryiGhVF6VAIzW 2fS6KYL+XyteKqywoQ+HhjxrV/Yz6QI1/tZJ2ac/c1vOyUyKsKbYQPmpERpphmolGseg gfyFeCU+2JzsDWMM3ePpcqFjGl/338QQLAqBzTfz6Tkg9umrqdN66cyXTMEJtWvUTFiO MNvbKC2r9Nt5j1pcgz0muSNfTQMVd9WUEbBpldEqx8qs27OsY2fWWSUpLfcZlLIlfAu9 ueIEZBxQErxkVu6kqMO26MYRfZJUY0pO2ZLJ4EVvmGS1rQiuOR+T3UXPt5JhliJG4j68 14Eg== X-Gm-Message-State: AOJu0YybepFozNSGN1DFC1JyRuWGLvYdqXRRE1AuBIgDFAo5LIA67tat Ga1pWU/XGac2ZztlX/ZE6LsBEDNMMbbJ6PdH+vvyyHWzdSWXWOx9LG8V1NpVwD5Ikaud/FUq3BC R5DvO+kjOQBPMJpcKnASFuhHR5lP9 X-Google-Smtp-Source: AGHT+IESScytHrWAAeyX+/XlhVTtohF9SGTvn1qJ5nNhgczK/SZ/PXDftQoQyoAvkHNHhCz1pwqwUfBWRs1TEj2yVcQ= X-Received: by 2002:a05:6a20:8783:b0:1a6:b689:8c29 with SMTP id g3-20020a056a20878300b001a6b6898c29mr1265145pzf.61.1714103524584; Thu, 25 Apr 2024 20:52:04 -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: Rick Macklem Date: Thu, 25 Apr 2024 20:51:55 -0700 Message-ID: Subject: Re: mysterious setting of B_DIRECT? To: Konstantin Belousov Cc: FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4VQf1L1z8Cz4ckS On Thu, Apr 25, 2024 at 8:09=E2=80=AFPM Konstantin Belousov wrote: > > On Thu, Apr 25, 2024 at 07:49:23PM -0700, Rick Macklem wrote: > > Hi, > > > > This week I have been doing active testing as a part of an IETF > > bakeathon for NFSv4. During the week I had a NFSv4 client > > crash. On the surface, it is straightforward, in that it called > > ncl_doio_directwrite() and the field called b_caller1 was NULL. > > > > Now, here's the weird part... > > ncl_doio_directwrite() should never be called because B_DIRECT > > should never be set. (The only place B_DIRECT gets set in the code > > is never currently executed.) > Do you mean the place in nfs_directio_write()? And the fact that > IO_SYNC is always set. Yes. > > > > > I have a patch that clears out the "never to be executed" code and > > this seems to avoid the patch, since with the patch, ncl_doio_directwri= te() > > no longer exists. > > > > What I cannot figure out is how B_DIRECT got set? > > I can note that UFS was under heavy load when the client crashed, > > but I cannot see how a UFS "struct buf" would become a NFS "struct buf" > > without b_flags being set to 0. > > There are also vfs_bio_brelse()/vfs_bio_setflags() functions which can > set B_DIRECT. On the other hand, they are not used by nfs client. Yes, again. > > What was the overall state of the buffer with the B_DIRECT flag? Which > vnode it was assigned to? Unfortunately I was in a hurry and didn't get more info. And, since I have never seen this crash before, I doubt I'll be able to reproduce it. Thanks, rick From nobody Fri Apr 26 03:54:48 2024 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 4VQf4j4XWHz5HlRr for ; Fri, 26 Apr 2024 03:55:01 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) (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 4VQf4g5NMcz4dv1; Fri, 26 Apr 2024 03:54:59 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b="P2Ni/QK9"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2607:f8b0:4864:20::529 as permitted sender) smtp.mailfrom=rick.macklem@gmail.com Received: by mail-pg1-x529.google.com with SMTP id 41be03b00d2f7-5bdbe2de25fso1288187a12.3; Thu, 25 Apr 2024 20:54:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1714103698; x=1714708498; darn=freebsd.org; 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=86u60VKFb3IeAn4rEu2lsP300cn28bVv1LXnzRBlL0s=; b=P2Ni/QK9UKPv+FUNjhEsaazZIeYTDZnnkTzBIZC+o8HfgwgpBzbH3z6X/iuS9c9d/O Pse8yOcrnrIMR1PfukU0Yjz1ocCLsmPzKj/2ExoFp0JfxzEGQ6/2l+pNQvOnoDgvJ9HU SF3xTjtIvhlDaFFrGDWBms6fH4HD9dZqqwx3sjSsoKol9QiT0mzzwpom5JVzzKTuOkkB qvQ8lEcmjeISuaGUxkDf+DzqRRppJzajV3FgHcNi7zVnz/scB2OPwnop/fyhSQnmjExi CFy2PCnaBzNATM+LENyoH4Y9DXmBRB3hd/N9FXYY7VFQ4PDkEZbcsfJOJz+OAcjKK1hD BkJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714103698; x=1714708498; 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=86u60VKFb3IeAn4rEu2lsP300cn28bVv1LXnzRBlL0s=; b=hizb85ri33fg5NqZyj//y1u8631+asQQLH4W3/27Wn4cwSEBzpzyAJsPxR6G2GcSHa SP4qN+yDELByAn2G1sq47V41AID/nFS++bmsW4/0GK67pse/GWBVD1oMi/877ddNaoEo Tw3dFsUL1YwQDUCfFnn0soJIDEty7Dnp+EIpTK9q+N2hOdEg6HHxvPnchB+eQn61sEjC Wt6ty3CFLvVJeFlbNQmtcWFXrF7zLSfRHJhuG82Bx363t4ZZ8f1epesu8znUQXbSjbUn iq2WKt6Yr/eYzdG2IS7zyRFunh3s5WWN+fTAG50R3Spkrg/kqpxu04kpeHzZnB9gJ4kY jxeA== X-Gm-Message-State: AOJu0YzMNYzhLutNwCY3ebKPbZHq4ujUPaBJ9/Qn2knFazgSHkJX6qDA FcCgMhncbnTUZkyIgnxZ+K+xQN4KYGNIPHtjXys6V1HCigeJe5Q6O5FCPq2YVtq3KvjRxPEGvds t3pGoZP+zLSK7jf/gJgJm1YWaLcWV X-Google-Smtp-Source: AGHT+IGX4r6/r4Ozson+07nG2T1vU4CVecLDl7rICePmsCj6x779eKhriR+vATOsig1sPCWkAetZm/IOnkudMUI6hNU= X-Received: by 2002:a05:6a21:6816:b0:1a8:e79a:2b0a with SMTP id wr22-20020a056a21681600b001a8e79a2b0amr1761200pzb.0.1714103698018; Thu, 25 Apr 2024 20:54: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: In-Reply-To: From: Rick Macklem Date: Thu, 25 Apr 2024 20:54:48 -0700 Message-ID: Subject: Re: mysterious setting of B_DIRECT? To: Konstantin Belousov Cc: FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.99 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.995]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ARC_NA(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; TAGGED_FROM(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MISSING_XM_UA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::529:from] X-Rspamd-Queue-Id: 4VQf4g5NMcz4dv1 On Thu, Apr 25, 2024 at 8:51=E2=80=AFPM Rick Macklem wrote: > > On Thu, Apr 25, 2024 at 8:09=E2=80=AFPM Konstantin Belousov wrote: > > > > On Thu, Apr 25, 2024 at 07:49:23PM -0700, Rick Macklem wrote: > > > Hi, > > > > > > This week I have been doing active testing as a part of an IETF > > > bakeathon for NFSv4. During the week I had a NFSv4 client > > > crash. On the surface, it is straightforward, in that it called > > > ncl_doio_directwrite() and the field called b_caller1 was NULL. > > > > > > Now, here's the weird part... > > > ncl_doio_directwrite() should never be called because B_DIRECT > > > should never be set. (The only place B_DIRECT gets set in the code > > > is never currently executed.) > > Do you mean the place in nfs_directio_write()? And the fact that > > IO_SYNC is always set. > Yes. > > > > > > > > > I have a patch that clears out the "never to be executed" code and > > > this seems to avoid the patch, since with the patch, ncl_doio_directw= rite() > > > no longer exists. > > > > > > What I cannot figure out is how B_DIRECT got set? > > > I can note that UFS was under heavy load when the client crashed, > > > but I cannot see how a UFS "struct buf" would become a NFS "struct bu= f" > > > without b_flags being set to 0. > > > > There are also vfs_bio_brelse()/vfs_bio_setflags() functions which can > > set B_DIRECT. On the other hand, they are not used by nfs client. > Yes, again. > > > > > What was the overall state of the buffer with the B_DIRECT flag? Which > > vnode it was assigned to? > Unfortunately I was in a hurry and didn't get more info. > And, since I have never seen this crash before, I doubt I'll be able > to reproduce it. Oh, and I will put the cleanup patch on phabricator. I didn't see the crash again during a few days of testing with the patch. This makes sense, since it get= s rid of ncl_doio_directwrite(). > > Thanks, rick