From nobody Mon Nov 4 06:05:13 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 4XhgtP2jM3z5cGBR for ; Mon, 04 Nov 2024 06:05:17 +0000 (UTC) (envelope-from avg@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 "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4XhgtP2Df5z4l8N for ; Mon, 4 Nov 2024 06:05:17 +0000 (UTC) (envelope-from avg@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1730700317; 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:autocrypt:autocrypt; bh=tj1w4xNVLJmVJbO8uY7M8d/GOK9z8a6IwQ5+ntqLJic=; b=Vn1jvZ0KQk+uEWiaAIzGGgbTm2JggD++EKJGt5NT8tzSJPN0x9BzgWNcrERCIuBgzL1yrz +D9wPjsMh7nxiaPH8msKAXUiOZn8hruGIIJ2LNxdjZQmWGAt3VvfPBH6o5SLMyWiEoSjnX qP0sAo4SWHF2cCduFhL8UsbIAK0cjFzcIoJZfEPizNeUBUs7soLqIZjndVgAtO1lGi091z D7yRvKSg88Khu2prm9PYlz4meL8jqMq5bGvh+wkETdYubl5iwE6vGftJv8gxcJfRJHdxLp uUpgQ2afSij0+tNh+8QIh+PA3d/8tte0RHnIzWqLJofGFmyVMUnYVI0jnivzcg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1730700317; 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:autocrypt:autocrypt; bh=tj1w4xNVLJmVJbO8uY7M8d/GOK9z8a6IwQ5+ntqLJic=; b=AA6SWIjHXqJxoT7H0CNs2Y9XB9Cv4/sGLupUmiFdBcqELK64qaUUvDA+FeQiVepUpvaf16 UPIUk0/PQet6wJWUOyELqTMKO0cQaEzhm+62ErgPilG6MU+mEw1PzWlR4ZFPSivjhk5KgR 42nkoVnqJwO8Z6XkB0oykF2+D3g+zfBPQXZteofys2EapvthWRsGZTavGUjTb98DMwrf5s 6HRSq2XKNN+RHVs5w/FkxF15YFev9/51IYOryHsI6J9urKj/lYNqakuMdZJq+w6rnqNNGU 2Oy2/XIln/EwPiuG073riI1k8LW9dfOHDHs8viwjLw4ZlEzAYj548QznQ4bv1g== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1730700317; a=rsa-sha256; cv=none; b=pTJF/jzCYc6Y7mbhEVlAGV909XKbJ7uu3rOOa48oXWKLmrlMxAT4OMLNh4dXL8J1GqcEh3 shs1c3vXa2i4wMEe0G6O6x4d8YNYCc4+gb5A0XM7NiP/mi6HZ+9Kqm2k15uMaaHheKSFcA PDHoKISUGgXW/2hXNkzMy97VlvmPEtssWxh2XZiAPN6NmC+AXI8Bzj4hAMqgxxJ4YjZKT9 eEFLfvdPPvDXwPumJkVq8IX3HJDmq99lpBozVFlORAtWCzv2HKy/FDuNhoWqHyESC8xLVX GPYRII29AEtD2YRNoCBRfQtW0MnhwUOInQK6rJ3YJPdWY00rC6kVD5nNvHsPPg== Received: from [192.168.0.88] (unknown [93.188.39.137]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: avg/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4XhgtP0CD8zQD0 for ; Mon, 4 Nov 2024 06:05:16 +0000 (UTC) (envelope-from avg@FreeBSD.org) Message-ID: <297bdeca-ef39-4382-9e20-3ee1d0880bd8@FreeBSD.org> Date: Mon, 4 Nov 2024 08:05:13 +0200 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: FreeBSD Current From: Andriy Gapon Subject: userland is active during late shutdown or even panic? Autocrypt: addr=avg@FreeBSD.org; keydata= xsDNBGcKrHEBDADRvwQOK0b/yo4ys5cs6bOQMhEh4xtfbaZ/CU00cpPgUip3sOZCdrtMWlRC g25z97prxE9pKueZi+HXDhIPpa9xl14ghqF4oYScuJ1i18HyiOH2y5Q3Vv/TtFiSzicd3EAu QgS3jVidpgDSPDdj2Yz3UxYpZ+PuFl6nOnvCvqOFcjUlzKCyPaiN2b86l1Nscmhnc+zQ/faB erUOEFEDQbWMA5YfXi8HrbeR16hfRfGt7E0aMDlIj9FIPIq71UWMN9CimPgs4+rbNr1MAlLa z4GxSDhVYZEY5rqtCzr+PLXboRQWnaUwXl0/biw9enf17NHdYv1SNAFTX2eC4dZ3qBVI74dS PgNprm+PMfz+6Hhs/dAv+Nan5nVhg3EFIjYTiy0MnjMSq8uI0v0ykpAGAcJJ5xl6d23aLxgN 6f0z6pJRCO0hGPgU7UzvFD0MxJxmbzqdT1R51KDan1oD41b+tjl2LMBuCDCoB0U44Pu0zLdp xMfFTxCXtwIYKIUxwd28jwMAEQEAAc0eQW5kcml5IEdhcG9uIDxhdmdARnJlZUJTRC5vcmc+ wsENBBMBCAA3FiEEmXvSmjiQFHPVOpLnzDOt5NLj67sFAmcKrHEFCQeEzgACGwMECwkIBwUV CAkKCwUWAgMBAAAKCRDMM63k0uPru5tSDACFK15LLbq89RSQ6QMnjiIm1t/wYJyumb519MHu Dhzxx1lbr8oghf0RHtF6kYRLQPaW2VdToi74pRobd3CN4bhZKDLSL6WfTn17RfavDjL6Njwp KBo30CkOeYKWq1mDmo0xEoQj8cc7ybEZnus+YScZOpj8Ti4EFwhRt6SHer7YDb161IHKL8m4 MsCxpFSGEjbKj8Iul3Ri/fTOO8w14ivcuEEQIvJt4/+4YV5Az8G23wKzL/3aJ7SOT3oYGmR9 atBTmVO3DlODjM+rZLegd8SfLSPTcBTHspWE5duemIzZbEX3BP77r3Qx4Fo5Tkit3bG1XVar yPQato+sFGFEGifdE9USBQoAoOaaeZevwAWjDU0TIuCT0CUe0sKtQuNP4LRq0n9EEHOXBu9a CfdMhFUSkAZnuE7miSVwgPvoVNJ1stA37EXLN/sVsWik7wslTQ5vF81VpdGFiwoQPOe2XEKh ogcwGSnXbwv1gD4x+Gz/7Y+kFyr1NY+4/nSaeXVcS2fOwM0EZwqscgEMAMQTe6ypAmQe/TFO HqKD2hfFKdksTptKi6uEh8xIwct8G/0FBldDWXo9eu8CGr/ZrDg0/bAwJxbaLRQCMH19Gq2Y hLvZ1QK5GQJVzZKcqfxbF2LiDUTs6WkdOBIhGpdDy7p1xFrvqCGCtNFYHuGYm067EozibBSF BWAPstKu2FQuVHZNMOfs7p3OIz3Yfqu9woXDeg3/8G2qVQJINe+8EwXKlhgh4CyDbq7nAZoA kIu1SE9z9u3WI5mcNy/0dFmVUsFxBqRC3ewbvzie8tKyZ9yFOlaZPT0Y4nRBXQTI3mLZ8zQ8 mtrWK5OOmrJ02kdeO9RBXe+OMaUUWMf92ZIoBFb4HP6N+B+4N1y1OwULousfl7JRoYxA4MRL ls7E2sSoJvrEBTJB3Pc34xu8rsJ1A5V3NgN6djX8yEZYpTRkcmrBeWy/ofDqZPVqneAx0LRm eldDS9msXDW4KXODyPZ+9unvmHAcoH0xaBYaSH44CDZDQDg4LNcmbOvuu1TEXBJhjQARAQAB wsD8BBgBCAAmFiEEmXvSmjiQFHPVOpLnzDOt5NLj67sFAmcKrHMFCQeEzgACGwwACgkQzDOt 5NLj67sUCAv5AXqgWnYN9EblapMbZjkiqL8pZQ0GNqh+Pg9FwbyULxjtRTO6rD4D0IxizByb ef+neeUNyYlagt5nfKMysEr0SU/gHKCi8vyTF/63ukMrGUNGmJJxrndl5ZYKC6j6eX7twrZF L1Uvlmn6FnQ22red5kHO93fDjG4zaDIZvHfwj7kzjZ4tpC7Byinf88s14mdZeScc0PnU2hj4 UGYju/wg2FF4YxaZYhcmdTiRYY0Wx85XSMZv19pnn78sadEuRvfRd4JTmw++j1xGXeqQGWzz /CTG5/Ex9GAkQ02hZbmi236byDXoet4G8TEyOph9QFVkV9bNd0jQZaFZPGEj4PSPUYGAF7s5 xJaNGgctC3aZ7WjEv1FBoo44XCU4xcjJ1wZQUrHxRhx6TW0Jtcl0U9qfKFW30TSPo6RyiXuj X4ltWKAtjoXB8nUmEJckaz7IRu2b4pXDeazZuz5JBygUs10yJjDxh2vFQZo0KaBAPx9MZlPn gpPTjT15L8xGftEjQXF6 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Has anyone here noticed weird behavior where userland on can be alive and well during quite late shutdown phases? First, I noticed this report on FreeBSD forums. Initially, I didn't find it believable, but the poster provided quite strong evidence and details. https://forums.freebsd.org/threads/zombie-kernel-reporting-its-own-crash-via-network.95217/ Then recently, I first hand experienced a similar thing during a normal reboot of a system. Here is console output from an ssh session connected to a host name 'ryth': ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 29759/usr/home/avg pts/1:[0]:ryth#18:28>poweroff ; exit Shutdown NOW! poweroff: [pid 14930] *** FINAL System shutdown message from root@ryth *** System going down IMMEDIATELY System shutdown time has arrived [root shell exited, but user shell is still active on ryth] 28923/usr/home/avg pts/1:[0]:ryth-18:28>tail -30 /var/log/messages [snip] Nov 3 18:28:25 ryth shutdown[14930]: power-down by root: Nov 3 18:28:25 ryth ntpd[2088]: ntpd exiting on signal 15 (Terminated) Nov 3 18:28:25 ryth upsmon[1989]: upsmon parent: read Nov 3 18:28:25 ryth kernel: . Nov 3 18:28:26 ryth kernel: , 1739. Nov 3 18:28:26 ryth kernel: Waiting (max 60 seconds) for system process `vnlru' to stop... done Nov 3 18:28:26 ryth kernel: Waiting (max 60 seconds) for system process `syncer' to stop... Nov 3 18:28:26 ryth kernel: Syncing disks, vnodes remaining... 0 Nov 3 18:28:27 ryth kernel: 0 28924/usr/home/avg pts/1:[0]:ryth-18:28> [finally ssh (slogin) gets disconnected] Connection to 192.168.0.77 closed by remote host. Connection to 192.168.0.77 closed. zsh: exit 255 slogin ryth ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ It was a weird feeling seeing "Syncing disks, vnodes remaining..." in messages. -- Andriy Gapon From nobody Wed Nov 6 08:37:38 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 4Xjz9L6VNYz5cJcJ for ; Wed, 06 Nov 2024 08:37:42 +0000 (UTC) (envelope-from joh.hendriks@gmail.com) Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Xjz9L0lQwz4TYh for ; Wed, 6 Nov 2024 08:37:42 +0000 (UTC) (envelope-from joh.hendriks@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=BkBPlRaf; spf=pass (mx1.freebsd.org: domain of joh.hendriks@gmail.com designates 2a00:1450:4864:20::634 as permitted sender) smtp.mailfrom=joh.hendriks@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ej1-x634.google.com with SMTP id a640c23a62f3a-a9a6acac4c3so1016108766b.0 for ; Wed, 06 Nov 2024 00:37:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1730882260; x=1731487060; darn=freebsd.org; h=content-transfer-encoding:subject:from:to:content-language :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=kfypVyFVVUVds/fA3dFWTc3/AbFNBTlbfHcPH6OkMd0=; b=BkBPlRafx7LlgFWZxndpFh8T5NnPbheru/Mv9xwvO0UF82uIefT6RPBfu9zkrv1JQ9 voJLLinkNbbwDLY3pYc9Cg4kTxKbC92THkC+gfb8qedEa0y6aFrPC/RaW7nmiBKQceDH BvCpVMl4mb4i921LFfeVk6ehsvfM53WG7Hg2h8QIrIFlgDXEjQsEVsWATNoKp8UcJfu1 nUYEB9b9CFozqveoX5qRdBWywsh8LgnxBx2oY2o9QQgLVXUeOSqT5d5gd53TdFN8T1JA dPSswT1sd4IzSx4+nGgnwFJsjFOIy2vWiB8TerIy/RZ04kmzgkVN2gQWH7NTYmfDDC0e E7BA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730882260; x=1731487060; h=content-transfer-encoding:subject:from:to:content-language :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=kfypVyFVVUVds/fA3dFWTc3/AbFNBTlbfHcPH6OkMd0=; b=TiU3kTHRo6Yv3onAuBu0bi/npnRlLcm7TmZL3xQdJ7TY7zBwIzXRvEqVF6STj25HhY 0deyLMXNEpDcC/FsKvxz3lroSmmOCmBE5zagM+cxLDM48SQip39US7qL1hypva6fopc8 Wj0QvYqZupadILJ70BrlBnrzDlHgncM/sVJ3XmdTe/upWWZV2w/ZCDj2gU/Ch8glI/tn MzzaaYNctQBl6gbw+qwxhjHnoRegrVw21/c8iVxZMT7FZ4wbutbmGS7uf0m+Up0DDJYA OH+lfbeUJnnM9L+cgNsiB7Pi42hH0OE52T7J4Try61KmN4mTgDcfCCetkR2KTLh9M7Oo MU2g== X-Gm-Message-State: AOJu0Yyv/kMEs0A2bsWex/qVOUYiE3oHawGYEAlUCZJwztkrXk0EAHt1 6O7pWqf5qTMmWW3KsahjKes8wt72yfHafGydkDAcLhKFfSses/yws3e6yQ== X-Google-Smtp-Source: AGHT+IGSPz7Cors0cMRNaIzhiGzgPSnQfE5SODrPwGNiKNG7Qv/zZoc71eILj4XLfGKA6UgzghPMzg== X-Received: by 2002:a17:907:7e8b:b0:a8d:2faf:d33d with SMTP id a640c23a62f3a-a9de5d6f1ecmr3951804966b.9.1730882259989; Wed, 06 Nov 2024 00:37:39 -0800 (PST) Received: from ?IPV6:2001:9a8:26e:0:184e:38f8:6c69:e622? ([2001:9a8:26e:0:184e:38f8:6c69:e622]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a9eb16d9d68sm244903766b.72.2024.11.06.00.37.39 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 Nov 2024 00:37:39 -0800 (PST) Message-ID: Date: Wed, 6 Nov 2024 09:37:38 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: FreeBSD Current From: Johan Hendriks Subject: BRT copying feature Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [-3.79 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.80)[-0.796]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; 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]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; TAGGED_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::634:from] X-Rspamd-Queue-Id: 4Xjz9L0lQwz4TYh X-Spamd-Bar: --- I installed the latest 14.2 Beta and i noticed that on the root pool the BRT copying feature is enabled on the pool. I know i need to set vfs.zfs.bclone_enabled=1 to really make us of it. But i do not want this on my root pool but i do want to use it on my storage pool. I can not disable this feature on the root pool as it is a feature that can only be set at creation time. Is there a way to use this feature only on selected pools? regards, Johan Hendriks From nobody Wed Nov 6 11:40:44 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 4Xk3Fs6z80z5cTSX for ; Wed, 06 Nov 2024 11:41:53 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:313::1:5]) (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 "E6" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Xk3Fr6kJGz4ndS for ; Wed, 6 Nov 2024 11:41:52 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=leidinger.net header.s=outgoing-alex header.b=QN7EYCfy; spf=pass (mx1.freebsd.org: domain of Alexander@Leidinger.net designates 2a00:1828:2000:313::1:5 as permitted sender) smtp.mailfrom=Alexander@Leidinger.net; dmarc=pass (policy=quarantine) header.from=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=1730893304; 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=dSV+bOlAtH6WmUfXYKtIMktZQb0AInJGAdKaFliwBg4=; b=QN7EYCfyEpBvWxoEdSaVCE+EzVGUbX3uROcDDigjaoA2FOVSB+2RKDlWKthxAF1hFaU9Ic quy03CehwFMkcxOmKk51njz3ebkTodfesA8/g4YF05xlJZoMu51hIZbCbFdJs9w/rn5yrA 2FR8mraTuBJuk9g5xNCp2Xwb3XGV8e+Vadlmj1nefjZJwD6yzZh/xKu/zrOboGkwhtWKOd 4ExZDfGyUCV1/fd4ztqNcLM2JBSr7y0TmGOZ5II1ub33QZFL60rthsP73+8nS0TFxmnbyY Cr+GBMr+6F+MTRMA/q85fw1k/tyvzQ8SGjLe2LZIQFBsRfw6n4jN6EtJybc8Lg== Date: Wed, 06 Nov 2024 12:40:44 +0100 From: Alexander Leidinger To: Warner Losh Cc: Current FreeBSD Subject: Re: No valid device tree blob found! In-Reply-To: References: <8cf9adb0e7ca6340460c695ffd64a0df@Leidinger.net> <896b9ce404ffcb126dcdd6008583b117@Leidinger.net> Message-ID: Organization: No organization, this is a private message. Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=_e277f5c271432920d6c950fa8c55c57b"; micalg=pgp-sha256 X-Spamd-Result: default: False [-6.02 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.92)[-0.919]; DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex]; MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain]; ARC_NA(0.00)[]; ASN(0.00)[asn:34240, ipnet:2a00:1828::/32, country:DE]; HAS_ORG_HEADER(0.00)[]; SUBJECT_ENDS_EXCLAIM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~]; DKIM_TRACE(0.00)[leidinger.net:+]; MID_RHS_MATCH_FROM(0.00)[]; MISSING_XM_UA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_ZERO(0.00)[0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; HAS_ATTACHMENT(0.00)[] X-Rspamd-Queue-Id: 4Xk3Fr6kJGz4ndS X-Spamd-Bar: ------ This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --=_e277f5c271432920d6c950fa8c55c57b Content-Type: multipart/alternative; boundary="=_10124cbb036f15e80b76e9b0def799e4" --=_10124cbb036f15e80b76e9b0def799e4 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8; format=flowed Am 2024-11-02 17:08, schrieb Warner Losh: > On Sat, Nov 2, 2024, 10:03 AM Alexander Leidinger > wrote: > >> Am 2024-10-30 22:11, schrieb Alexander Leidinger: >> >>> WARNING! Trying to fire up the kernel, but no device tree blob found! >> >> For anyone interested, I opened >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282493 for this. > > Yea. This is a hang or a bad console. The warning is lame and > misleading. > > Can you bisect? Found it. # git bisect bad c87b3f0006be9ac5813f1ff636f18c9b4a41b08e is the first bad commit commit c87b3f0006be9ac5813f1ff636f18c9b4a41b08e (HEAD) Author: Warner Losh Date: Mon Oct 14 15:58:10 2024 -0600 uart: uart_getenv: check for NULL class last, not first This allows one to specify dt:XXXX when the default class isn't compiled into the kernel. It's not an error to not have a class until we're done parsing the spec, so defer checking until then. Sponsored by: Netflix Reviewed by: adrian, andrew, markj Differential Revision: https://reviews.freebsd.org/D47078 sys/dev/uart/uart_subr.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) -current as of today without this change boots just fine on the Ampere system in the Oracle cloud. Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_10124cbb036f15e80b76e9b0def799e4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Am 2024-11-02 17:08, schrieb Warner Losh:



On Sat, Nov 2, 2024, 10:03=E2=80= =AFAM Alexander Leidinger <Alexander@leidinger.net> wrote:
Am 2024-10-30 22:11, schrieb Alexa= nder Leidinger:

> WARNING! Trying to fire up the kernel, but = no device tree blob found!

For anyone interested, I opened
https://bugs.freebsd.org/bugzill= a/show_bug.cgi?id=3D282493 for this.
 
Yea. This is a hang or a bad console. The warning is lame= and misleading.
 
Can you bisect?

Found it.

# git bisect bad
c87b3f0006be9ac5813f= 1ff636f18c9b4a41b08e is the first bad commit
commit c87b3f0006be9ac581= 3f1ff636f18c9b4a41b08e (HEAD)
Author: Warner Losh <imp@FreeBSD.org&= gt;
Date:   Mon Oct 14 15:58:10 2024 -0600

    uart: uart_getenv: check for= NULL class last, not first

    This allows one to specify d= t:XXXX when the default class isn't compiled
    into the ke= rnel. It's not an error to not have a class until we're done
  &n= bsp; parsing the spec, so defer checking until then.

    Sponsored by:     =       Netflix
    Reviewed by:     =        adrian, andrew, markj
    Differe= ntial Revision:  https://reviews.freebsd.org/D47078

 sys/dev/uart/uart_subr.c | 14 ++++++= +-------
 1 file changed, 7 insertions(+), 7 deletions(-)

-current as of today without this change boots just fine on the Ampere s= ystem in the Oracle cloud.

Bye,
Alexander.

--=_10124cbb036f15e80b76e9b0def799e4-- --=_e277f5c271432920d6c950fa8c55c57b Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc; size=833 Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmcrVcwACgkQEg2wmwP4 2IbOYg/9GTUrOb/+HuNYpItCnbpobhNJCH5uTQBaqOxqWC02OpvBYwZnNdaUEyLK Xa7IGRuAh2IC5ufQ862sfukNTUJUR5xt1A+O9vTr60v1feI9XfgiYor+CkDQoJP9 cfYJ07jiGKRpMNuZ8ykUI3BFfDzve8TzMfK/h+zkzr5xneooomO+Z2cznMetfjxK VZ7i1ikIo4Dla8ZHl23/BCp+bPHA2XCNizvVQXDQlxUiVNLS0G6LASYKIWUSuprN 5HvIrPr51DSehXJ6/qVnBXJkcEv8XM0Gws7601fnuYUeKAIOZBJfnZiY3dxx39Gt yq/d11rD+tp27YP8CY14P1vCIou61GvI1zHmwwi29ezSKobaH08AScCp6EUVcJEk DuP3z2z7jH0hpDhsNGLmlhU2imfezdx/AQu/YWNcEWpgk48wV15x6/TMCZmZMYzu 9cpXcEGHF8dsnShZy4vDQgeNIiXiD6pjbS4lNLg00KM6ocEgOhUQ8+bxOeLbB66H CmS2zVBZV/aWJUNJ5iDhqQfkFHzvmI9SBicyK/9fIiCXjYFcSqPpuonxE8GKoSA3 m3gg1tVq4xST4Zk5dVZFdDtd4tW03XZ+97qu43J4sd0BkmWtdTFfRlRFMlLwt09Q u5VPkuQRbwLf0miOFhPm0AV7b/7F3P4hBOdTv2jWPstU+VSSDXM= =Nh3/ -----END PGP SIGNATURE----- --=_e277f5c271432920d6c950fa8c55c57b-- From nobody Wed Nov 6 11:46:26 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 4Xk3ML5lmlz5cTTK for ; Wed, 06 Nov 2024 11:46:38 +0000 (UTC) (envelope-from cardiforia@gmail.com) Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com [IPv6:2607:f8b0:4864:20::b31]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Xk3MK6wynz4q4v for ; Wed, 6 Nov 2024 11:46:37 +0000 (UTC) (envelope-from cardiforia@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=EaZbQm38; spf=pass (mx1.freebsd.org: domain of cardiforia@gmail.com designates 2607:f8b0:4864:20::b31 as permitted sender) smtp.mailfrom=cardiforia@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-yb1-xb31.google.com with SMTP id 3f1490d57ef6-e2e2baf1087so6134337276.2 for ; Wed, 06 Nov 2024 03:46:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1730893597; x=1731498397; darn=freebsd.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=LcUIH9QkoICle/xBIfxmsmCjPqX2bx55b5eY2FJR6EE=; b=EaZbQm38hPgWyY6mS/1hokKiRGuefze/FdNcRReeLqw0ORR4jA27P4UTMzBoMcnY6x 2IWPuuL8QoY4C969EjEcsAS7a4tHKTgBYe8QpVmXpdX20zO/yBfvCkkZMZ6oHxN+rNOa 26A5a5mkyUsLkRwDeVpLgcgc8LsbBWhuYrnWOEDUaP8lWNJX9pRho2+vnqnyApWdvwpf pXFoUEWqQFRo3EYFpN2GhRrWPl3CD/D5o/2kZLxKz7V9LyGIA5vsiE8tJTd7ThJtC1yp WsA/60arkjLSTDBuo0upoamoQgTn3JxNx14zYG8wADJ78CdTzPNUhBtMgjCU6A5ivtWe 2GrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730893597; x=1731498397; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=LcUIH9QkoICle/xBIfxmsmCjPqX2bx55b5eY2FJR6EE=; b=bUUvdoGlpXfDHUNkEbc51eCwDsAO1tGlV6G7DxPeZq63B4c3SY6/rubqVld2eAq2yl wDPQPClLG5ds7535rjburOuxIsNNa8yCvB1eCcByK14Fh/2dyzKbTk7X14Y5zg/bwceO 5dEMeSbkYAn9hN9wuuXhOsZG6GddpOQsHyqJ7t7krQFVaN81EOO1qjux/+2X+sL3mpUb 0rzPW+vdBk4Efipw7tFryOI3xDVqj6iNGLJ2rEd0ZQ+EUs4V9VP9bvnKsWahjTUB3rmU Hfa1RxmktKRVs8MGqA+ZTFqZ84dXHNZmfrq1vqgnhqfz1eD6BOz27s+FpoQD0hDiGjL+ h81Q== X-Gm-Message-State: AOJu0YyFgHQhpV2/HTIxzO06zYLvDJO094bQodYxSM4s/9yKPGtS6yI4 gNCP8uV/sxqrWW6DzIQjz6BQkPxpQlBa27U4Ul4FOMhES8vFevMYzZbryH1CeiHVwR0qSWIapgg j/R7//uWPmr5q6kbI0cpyEqkuz6M29w== X-Google-Smtp-Source: AGHT+IEmhCw6aTZQ6K8MtcCG6XYjYHsBJ/zV6y1/ca9T1fvboCh5BERYg4TJsl9Xkc6YqygxJ8YqI7QLzeGgljiLh48= X-Received: by 2002:a05:690c:4b0b:b0:6e9:ea86:9667 with SMTP id 00721157ae682-6ea64a8d450mr203626457b3.9.1730893597123; Wed, 06 Nov 2024 03:46:37 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 From: Ventsislav Nikolov Date: Wed, 6 Nov 2024 13:46:26 +0200 Message-ID: Subject: UNSUBSCRIBE To: FreeBSD Current Content-Type: multipart/alternative; boundary="000000000000003cb806263d12f3" X-Spamd-Result: default: False [-2.63 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.98)[-0.975]; SUBJ_ALL_CAPS(0.83)[11]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.48)[-0.483]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ARC_NA(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MISSING_XM_UA(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; MID_RHS_MATCH_FROMTLD(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::b31:from] X-Rspamd-Queue-Id: 4Xk3MK6wynz4q4v X-Spamd-Bar: -- --000000000000003cb806263d12f3 Content-Type: text/plain; charset="UTF-8" --000000000000003cb806263d12f3 Content-Type: text/html; charset="UTF-8"

--000000000000003cb806263d12f3-- From nobody Wed Nov 6 12:15:54 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 4Xk4194DyJz5cWH0 for ; Wed, 06 Nov 2024 12:15:57 +0000 (UTC) (envelope-from SRS0=MPrW=SB=klop.ws=ronald-lists@realworks.nl) Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24]) (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 4Xk4182lTbz4skx for ; Wed, 6 Nov 2024 12:15:56 +0000 (UTC) (envelope-from SRS0=MPrW=SB=klop.ws=ronald-lists@realworks.nl) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=klop.ws header.s=rw2 header.b=sNdEIq3Q; spf=pass (mx1.freebsd.org: domain of "SRS0=MPrW=SB=klop.ws=ronald-lists@realworks.nl" designates 194.109.157.24 as permitted sender) smtp.mailfrom="SRS0=MPrW=SB=klop.ws=ronald-lists@realworks.nl"; dmarc=pass (policy=quarantine) header.from=klop.ws Date: Wed, 6 Nov 2024 13:15:54 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1730895354; 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=Lw89htaQI4Q3EGfPukMWCpxtXCFrlYwSV3FeO92sKHw=; b=sNdEIq3Qr3WyH1QiACSBXktQAUVJbqvAtkemtsHF0/PaLzwb7gKGJKim473ZrERRH4Tptk DSE8cb6cv5c3q5lPEW/O4qgbANoqUAN4UtDSOBqmt9eOaF7czDhSU5pq44dEMJ2TjU/Ap1 r9fpCwiJGkSOrwIqQHtSZvsiZiPeU3Z0/PUp3hkjVdrcYPhx6IoaxoakRgoiweVxNMh67m A4hLlUhpnFfLguBDjogp/YLIGFRzZXYpZQ63dXXoZQC1kAAmb60jNf+zWDdniIufK3IB3q AgRTVXMLIgc5BLPyrjPeiNh3MTFxtveQeitVwnK/lvdpxz9NpFAvGDw24m8PoQ== From: Ronald Klop To: Johan Hendriks Cc: FreeBSD Current Message-ID: <1568966692.4590.1730895354064@localhost> In-Reply-To: References: Subject: Re: BRT copying feature List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4589_1152485676.1730895354061" X-Mailer: Realworks (726.77) Importance: Normal X-Priority: 3 (Normal) X-Spamd-Result: default: False [-3.18 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.98)[-0.983]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine]; FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=MPrW=SB=klop.ws=ronald-lists@realworks.nl]; R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24]; R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ARC_NA(0.00)[]; TAGGED_RCPT(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL]; RCVD_COUNT_ZERO(0.00)[0]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[194.109.157.24:from]; FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=MPrW=SB=klop.ws=ronald-lists@realworks.nl]; FROM_HAS_DN(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; HAS_X_PRIO_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; DKIM_TRACE(0.00)[klop.ws:+] X-Rspamd-Queue-Id: 4Xk4182lTbz4skx X-Spamd-Bar: --- ------=_Part_4589_1152485676.1730895354061 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, When you create a new pool you can use something like this: zpool create -o feature@block_cloning=disabled ... I tried setting this on an existing pool. That gave me an error. # zpool set feature@block_cloning=disabled zdata4 cannot set property for 'zdata4': property 'feature@block_cloning' can only be set to 'disabled' at creation time So to install a new 14.2 system you need to do some manual work to create the root pool with the options you prefer. Regards, Ronald. Van: Johan Hendriks Datum: woensdag, 6 november 2024 09:37 Aan: FreeBSD Current Onderwerp: BRT copying feature > > I installed the latest 14.2 Beta and i noticed that on the root pool the BRT copying feature is enabled on the pool. > I know i need to set vfs.zfs.bclone_enabled=1 to really make us of it. But i do not want this on my root pool but i do want to use it on my storage pool. > I can not disable this feature on the root pool as it is a feature that can only be set at creation time. > > Is there a way to use this feature only on selected pools? > > regards, > Johan Hendriks > > > > > ------=_Part_4589_1152485676.1730895354061 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi,

When you create a new pool you can use something like this:
zpool create -o feature@block_cloning=disabled ...

I tried setting this on an existing pool. That gave me an error.
# zpool set feature@block_cloning=disabled zdata4
cannot set property for 'zdata4': property 'feature@block_cloning' can only be set to 'disabled' at creation time

So to install a new 14.2 system you need to do some manual work to create the root pool with the options you prefer.

Regards,
Ronald.

 

Van: Johan Hendriks <joh.hendriks@gmail.com>
Datum: woensdag, 6 november 2024 09:37
Aan: FreeBSD Current <freebsd-current@freebsd.org>
Onderwerp: BRT copying feature

I installed the latest 14.2 Beta and i noticed that on the root pool the BRT copying feature is enabled on the pool.
I know i need to set vfs.zfs.bclone_enabled=1 to really make us of it. But i do not want this on my root pool but i do want to use it on my storage pool.
I can not disable this feature on the root pool as it is a feature that can only be set at creation time.

Is there a way to use this feature only on selected pools?

regards,
Johan Hendriks

 

  ------=_Part_4589_1152485676.1730895354061-- From nobody Wed Nov 6 23:54: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 4XkMWc4S4fz5c1gF for ; Wed, 06 Nov 2024 23:54:52 +0000 (UTC) (envelope-from rodrigo@osorio.me) Received: from smtp.osorio.me (mvd.osorio.me [37.187.111.94]) by mx1.freebsd.org (Postfix) with ESMTP id 4XkMWb6Yhrz4Psq for ; Wed, 6 Nov 2024 23:54:51 +0000 (UTC) (envelope-from rodrigo@osorio.me) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of rodrigo@osorio.me designates 37.187.111.94 as permitted sender) smtp.mailfrom=rodrigo@osorio.me; dmarc=none Received: from [192.168.1.39] (lfbn-idf1-1-971-net.w86-238.abo.wanadoo.fr [86.238.50.0]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384) (No client certificate requested) by smtp.osorio.me (Postfix) with ESMTPSA id 2E900B0B68 for ; Wed, 06 Nov 2024 23:55:15 +0000 (UTC) Message-ID: <5d403c6f-760b-43c4-b595-49d2e421278c@osorio.me> Date: Thu, 7 Nov 2024 00:54:47 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: freebsd-current@freebsd.org Content-Language: en-US From: Rodrigo Osorio Subject: USB massive disconnections with FreeBSD 15.0-CURRENT Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Result: default: False [-1.27 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_SPAM_SHORT(0.82)[0.818]; R_SPF_ALLOW(-0.20)[+ip4:37.187.111.94]; RCVD_NO_TLS_LAST(0.10)[]; ONCE_RECEIVED(0.10)[]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:16276, ipnet:37.187.0.0/16, country:FR]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_ONE(0.00)[1]; FREEFALL_USER(0.00)[rodrigo]; R_DKIM_NA(0.00)[]; ARC_NA(0.00)[]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DMARC_NA(0.00)[osorio.me]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FROM_HAS_DN(0.00)[] X-Rspamd-Queue-Id: 4XkMWb6Yhrz4Psq X-Spamd-Bar: - Hi, Just t report that since last week after my last FreeBSD upgrade to main-n273400-5e5e4e1cf0c3, I start having USB issues with all the devices disconnecting, no way to have them back and usbconfig becoming unresponsive. The system works, I can still use the laptop keyboard to do some tests, try to reset the USB stack and finally reboot. I attach part of the log messages uname -a FreeBSD defiant 15.0-CURRENT FreeBSD 15.0-CURRENT main-n273400-5e5e4e1cf0c3 GENERIC amd64 Nov  6 15:23:27 defiant dhclient[10922]: New Routers (em0): 192.168.66.1 Nov  6 18:30:15 defiant kernel: drmn0: [drm] *ERROR* Timed out waiting for DSB workload completion. Nov  6 18:30:21 defiant kernel: em0: link state changed to DOWN Nov  6 18:30:32 defiant acpi[12261]: suspend at 20241106 18:30:32 Nov  6 21:22:54 defiant kernel: uhub0: at usbus1, port 1, addr 1 (disconnected) Nov  6 21:22:54 defiant kernel: ugen1.2: at usbus1 (disconnected) Nov  6 21:22:54 defiant kernel: ugen1.7: at usbus1 (disconnected) Nov  6 21:22:54 defiant kernel: uhub3: at uhub0, port 3, addr 6 (disconnected) Nov  6 21:22:54 defiant kernel: ugen1.8: at usbus1 (disconnected) Nov  6 21:22:54 defiant kernel: usbhid0: at uhub3, port 1, addr 7 (disconnected) Nov  6 21:22:54 defiant kernel: hms0: detached Nov  6 21:22:54 defiant kernel: hidbus0: detached Nov  6 21:22:54 defiant kernel: usbhid0: detached Nov  6 21:22:54 defiant kernel: ugen1.9: at usbus1 (disconnected) Nov  6 21:22:54 defiant kernel: usbhid1: at uhub3, port 2, addr 8 (disconnected) Nov  6 21:22:54 defiant kernel: hkbd0: detached Nov  6 21:22:54 defiant kernel: hidbus1: detached Nov  6 21:22:54 defiant kernel: usbhid1: detached Nov  6 21:22:54 defiant kernel: uhub3: detached Nov  6 21:22:54 defiant kernel: ugen1.3: at usbus1 (disconnected) Nov  6 21:22:54 defiant kernel: ugen1.4: at usbus1 (disconnected) Nov  6 21:22:54 defiant kernel: ugen1.5: at usbus1 (disconnected) Nov  6 21:22:54 defiant kernel: ugen1.6: at usbus1 (disconnected) Nov  6 21:22:54 defiant kernel: uhub2: at uhub0, port 13, addr 5 (disconnected) Nov  6 21:22:54 defiant kernel: uhub2: detached Nov  6 21:22:54 defiant kernel: uhub0: detached Nov  6 21:22:54 defiant kernel: uhub1: at usbus0, port 1, addr 1 (disconnected) Nov  6 21:22:54 defiant kernel: uhub1: detached Nov  6 21:22:54 defiant kernel: vgapci0: child drmn0 requested pci_set_powerstate Nov  6 21:22:54 defiant kernel: pci0: failed to set ACPI power state D3 on \_SB_.PC00.GFX0: AE_BAD_PARAMETER Nov  6 21:22:54 defiant kernel: acpi0: cleared fixed power button status Nov  6 21:22:54 defiant kernel: vgapci0: child drmn0 requested pci_set_powerstate Nov  6 21:22:54 defiant kernel: vgapci0: child drmn0 requested pci_enable_io Nov  6 21:22:54 defiant syslogd: last message repeated 1 times Nov  6 21:22:54 defiant kernel: nvme0: resubmitting queued i/o Nov  6 21:22:54 defiant kernel: nvme0: WRITE sqid:1 cid:0 nsid:1 lba:132600288 len:8 Nov  6 21:22:54 defiant kernel: nvme0: WRITE sqid:1 cid:0 nsid:1 lba:296994328 len:16 Nov  6 21:22:54 defiant kernel: nvme0: done resubmitting i/o Nov  6 21:22:54 defiant kernel: uhub0 on usbus1 Nov  6 21:22:54 defiant kernel: uhub0: on usbus1 Nov  6 21:22:54 defiant kernel: uhub1 on usbus0 Nov  6 21:22:54 defiant kernel: uhub1: on usbus0 Nov  6 21:22:54 defiant kernel: uhub1: 4 ports with 4 removable, self powered Nov  6 21:22:54 defiant kernel: uhub0: 16 ports with 16 removable, self powered Nov  6 21:22:54 defiant kernel: ugen1.2: at usbus1 Nov  6 21:22:54 defiant kernel: sdhci_pci0-slot0: Reset 0x1 never completed. Nov  6 21:22:54 defiant kernel: sdhci_pci0-slot0: ============== REGISTER DUMP ============== Nov  6 21:22:54 defiant kernel: sdhci_pci0-slot0: Sys addr: 0xffffffff | Version:  0x0000ffff Nov  6 21:22:54 defiant kernel: sdhci_pci0-slot0: Blk size: 0x0000ffff | Blk cnt:  0x0000ffff Nov  6 21:22:54 defiant kernel: sdhci_pci0-slot0: Argument: 0xffffffff | Trn mode: 0x0000ffff Nov  6 21:22:54 defiant kernel: sdhci_pci0-slot0: Present: 0xffffffff | Host ctl: 0x000000ff Nov  6 21:22:54 defiant kernel: sdhci_pci0-slot0: Power: 0x000000ff | Blk gap:  0x000000ff Nov  6 21:22:54 defiant kernel: sdhci_pci0-slot0: Wake-up: 0x000000ff | Clock:    0x0000ffff Nov  6 21:22:54 defiant kernel: sdhci_pci0-slot0: Timeout: 0x000000ff | Int stat: 0xffffffff Nov  6 21:22:54 defiant kernel: sdhci_pci0-slot0: Int enab: 0xffffffff | Sig enab: 0xffffffff Nov  6 21:22:54 defiant kernel: sdhci_pci0-slot0: AC12 err: 0x0000ffff | Host ctl2:0x0000ffff Nov  6 21:22:54 defiant kernel: sdhci_pci0-slot0: Caps: 0xffffffff | Caps2:    0xffffffff Nov  6 21:22:54 defiant kernel: sdhci_pci0-slot0: Max curr: 0xffffffff | ADMA err: 0x000000ff Nov  6 21:22:54 defiant kernel: sdhci_pci0-slot0: ADMA addr:0xffffffff | Slot int: 0x0000ffff Nov  6 21:22:54 defiant kernel: sdhci_pci0-slot0: =========================================== Nov  6 21:22:54 defiant kernel: sdhci_pci0: detached Nov  6 21:22:54 defiant kernel: ugen1.3: at usbus1 Nov  6 21:22:54 defiant webcamd[12308]: Webcamd is already running for ugen1.2.0 Nov  6 21:22:54 defiant webcamd[12328]: Webcamd is already running for ugen1.2.0 Nov  6 21:22:54 defiant webcamd[12348]: Webcamd is already running for ugen1.2.0 Nov  6 21:22:55 defiant kernel: ugen1.4: at usbus1 Nov  6 21:22:55 defiant acpi[12509]: resumed at 20241106 21:22:55 Nov  6 21:22:55 defiant power_profile[12563]: changed to 'economy' Nov  6 21:22:56 defiant webcamd[12593]: webcamd: Cannot find USB device Nov  6 21:23:23 defiant kernel: ugen1.5: at usbus1 Nov  6 21:23:23 defiant kernel: uhub2 on uhub0 Nov  6 21:23:23 defiant kernel: uhub2: on usbus1 Nov  6 21:23:23 defiant kernel: uhub2: 4 ports with 4 removable, self powered Nov  6 21:23:24 defiant kernel: ugen1.6: at usbus1 Nov  6 21:23:24 defiant kernel: uhub3 on uhub0 Nov  6 21:23:24 defiant kernel: uhub3: on usbus1 Nov  6 21:23:24 defiant kernel: uhub3: 4 ports with 4 removable, self powered Nov  6 21:23:25 defiant kernel: ugen1.7: at usbus1 Nov  6 21:23:25 defiant kernel: uhub4 on uhub3 Nov  6 21:23:25 defiant kernel: uhub4: on usbus1 Nov  6 21:23:26 defiant kernel: uhub4: 4 ports with 4 removable, self powered Nov  6 21:23:27 defiant kernel: usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage device AI210 Mass Storage (0x23a9:0xef18) Nov  6 21:23:27 defiant kernel: usb_msc_auto_quirk: UQ_MSC_NO_PREVENT_ALLOW set for USB mass storage device AI210 Mass Storage (0x23a9:0xef18) Nov  6 21:23:27 defiant kernel: usb_msc_auto_quirk: UQ_MSC_NO_SYNC_CACHE set for USB mass storage device AI210 Mass Storage (0x23a9:0xef18) Nov  6 21:23:27 defiant kernel: ugen1.8: at usbus1 Nov  6 21:23:27 defiant kernel: umass0 on uhub4 Nov  6 21:23:27 defiant kernel: umass0: on usbus1 Nov  6 21:23:27 defiant kernel: umass0:  SCSI over Bulk-Only; quirks = 0xc100 Nov  6 21:23:27 defiant kernel: umass0:1:0: Attached to scbus1 Nov  6 21:23:27 defiant kernel: da0 at umass-sim0 bus 0 scbus1 target 0 lun 0 Nov  6 21:23:27 defiant kernel: da0: Removable Direct Access SPC-2 SCSI device Nov  6 21:23:27 defiant kernel: da0: 40.000MB/s transfers Nov  6 21:23:27 defiant kernel: da0: 7696MB (15761504 512 byte sectors) Nov  6 21:23:27 defiant kernel: da0: quirks=0x2 Nov  6 21:23:27 defiant kernel: ugen1.9: at usbus1 Nov  6 21:23:27 defiant kernel: usbhid0 on uhub3 Nov  6 21:23:27 defiant kernel: usbhid0: on usbus1 Nov  6 21:23:27 defiant kernel: hidbus0: on usbhid0 Nov  6 21:23:27 defiant kernel: hkbd0: on hidbus0 Nov  6 21:23:27 defiant kernel: kbd2 at hkbd0 Nov  6 21:23:27 defiant kernel: usbhid1 on uhub3 Nov  6 21:23:27 defiant kernel: usbhid1: on usbus1 Nov  6 21:23:27 defiant kernel: hidbus1: on usbhid1 Nov  6 21:23:27 defiant kernel: hms0: on hidbus1 Nov  6 21:23:27 defiant kernel: hms0: 16 buttons and [XYWH] coordinates ID=2 Nov  6 21:23:27 defiant kernel: hcons0: on hidbus1 Nov  6 21:23:27 defiant kernel: hsctrl0: on hidbus1 Nov  6 21:23:28 defiant kernel: ugen1.10: at usbus1 Nov  6 21:23:28 defiant kernel: usbhid2 on uhub3 Nov  6 21:23:28 defiant kernel: usbhid2: on usbus1 Nov  6 21:23:28 defiant kernel: hidbus2: on usbhid2 Nov  6 21:23:28 defiant kernel: hms1: on hidbus2 Nov  6 21:23:28 defiant kernel: hms1: 3 buttons and [XYW] coordinates ID=1 Nov  6 21:23:28 defiant kernel: ugen1.11: at usbus1 Nov  6 21:23:28 defiant kernel: usbhid3 on uhub3 Nov  6 21:23:28 defiant kernel: usbhid3: on usbus1 Nov  6 21:23:28 defiant kernel: hidbus3: on usbhid3 Nov  6 21:23:28 defiant kernel: hkbd1: on hidbus3 Nov  6 21:23:28 defiant kernel: kbd3 at hkbd1 Nov  6 21:23:28 defiant kernel: usbhid4 on uhub3 Nov  6 21:23:29 defiant kernel: usbhid4: on usbus1 Nov  6 21:23:29 defiant kernel: hidbus4: on usbhid4 Nov  6 21:23:29 defiant kernel: usbhid5 on uhub3 Nov  6 21:23:29 defiant kernel: usbhid5: on usbus1 Nov  6 21:23:29 defiant kernel: hidbus5: on usbhid5 Nov  6 21:23:29 defiant kernel: hsctrl1: on hidbus5 Nov  6 21:23:29 defiant kernel: hcons1: on hidbus5 Nov  6 21:23:29 defiant kernel: hkbd2: on hidbus5 Nov  6 21:23:29 defiant kernel: kbd4 at hkbd2 Nov  6 21:24:01 defiant power_profile[12877]: changed to 'performance' Nov  6 21:24:40 defiant kernel: em0: link state changed to UP Nov  6 21:24:41 defiant dhclient[12925]: New IP Address (em0): 192.168.1.39 Nov  6 21:24:41 defiant dhclient[12929]: New Subnet Mask (em0): 255.255.255.0 Nov  6 21:24:41 defiant dhclient[12933]: New Broadcast Address (em0): 192.168.1.255 Nov  6 21:24:41 defiant dhclient[12937]: New Routers (em0): 192.168.1.1 Nov  6 21:25:15 defiant kernel: ugen1.10: at usbus1 (disconnected) Nov  6 21:25:15 defiant kernel: usbhid2: at uhub3, port 3, addr 9 (disconnected) Nov  6 21:25:15 defiant kernel: hms1: detached Nov  6 21:25:15 defiant kernel: hidbus2: detached Nov  6 21:25:15 defiant kernel: usbhid2: detached Nov  6 21:25:16 defiant kernel: ugen1.10: at usbus1 Nov  6 21:25:16 defiant kernel: usbhid2 on uhub3 Nov  6 21:25:16 defiant kernel: usbhid2: on usbus1 Nov  6 21:25:16 defiant kernel: hidbus2: on usbhid2 Nov  6 21:25:16 defiant kernel: hms1: on hidbus2 Nov  6 21:25:16 defiant kernel: hms1: 3 buttons and [XYW] coordinates ID=1 Nov  6 21:25:19 defiant kernel: ugen1.12: at usbus1 Nov  6 21:25:30 defiant kernel: drmn0: [drm] *ERROR* mismatch in avi infoframe Nov  6 21:25:30 defiant kernel: drmn0: [drm] *ERROR* expected: Nov  6 21:25:30 defiant kernel: drmn0: HDMI infoframe: Auxiliary Video Information (AVI), version 2, length 13 Nov  6 21:25:30 defiant kernel: drmn0:     colorspace: RGB Nov  6 21:25:30 defiant kernel: drmn0:     scan mode: Underscan Nov  6 21:25:30 defiant kernel: drmn0:     colorimetry: No Data Nov  6 21:25:30 defiant kernel: drmn0:     picture aspect: 16:9 Nov  6 21:25:30 defiant kernel: drmn0:     active aspect: Same as Picture Nov  6 21:25:30 defiant kernel: drmn0:     itc: No Data Nov  6 21:25:30 defiant kernel: drmn0:     extended colorimetry: xvYCC 601 Nov  6 21:25:30 defiant kernel: drmn0:     quantization range: Default Nov  6 21:25:30 defiant kernel: drmn0:     nups: Horizontally Scaled Nov  6 21:25:30 defiant kernel: drmn0:     video code: 0 Nov  6 21:25:30 defiant kernel: drmn0:     ycc quantization range: Invalid Nov  6 21:25:30 defiant kernel: drmn0:     hdmi content type: Graphics Nov  6 21:25:30 defiant kernel: drmn0:     pixel repeat: 0 Nov  6 21:25:30 defiant kernel: drmn0:     bar top 0, bottom 0, left 0, right 0 Nov  6 21:25:30 defiant kernel: drmn0: [drm] *ERROR* found: Nov  6 21:25:30 defiant kernel: drmn0: HDMI infoframe: Auxiliary Video Information (AVI), version 2, length 13 Nov  6 21:25:30 defiant kernel: drmn0:     colorspace: RGB Nov  6 21:25:30 defiant kernel: drmn0:     scan mode: Underscan Nov  6 21:25:30 defiant kernel: drmn0:     colorimetry: No Data Nov  6 21:25:30 defiant kernel: drmn0:     picture aspect: 16:9 Nov  6 21:25:30 defiant kernel: drmn0:     active aspect: Same as Picture Nov  6 21:25:30 defiant kernel: drmn0:     itc: No Data Nov  6 21:25:30 defiant kernel: drmn0:     extended colorimetry: xvYCC 601 Nov  6 21:25:30 defiant kernel: drmn0:     quantization range: Default Nov  6 21:25:30 defiant kernel: drmn0:     nups: Horizontally Scaled Nov  6 21:25:30 defiant kernel: drmn0:     video code: 0 Nov  6 21:25:30 defiant kernel: drmn0:     ycc quantization range: Limited Nov  6 21:25:30 defiant kernel: drmn0:     hdmi content type: Graphics Nov  6 21:25:30 defiant kernel: drmn0:     pixel repeat: 0 Nov  6 21:25:30 defiant kernel: drmn0:     bar top 0, bottom 0, left 0, right 0 Nov  6 21:25:30 defiant kernel: pipe state doesn't match! Nov  6 21:27:36 defiant reboot[13101]: rebooted by rodrigo From nobody Thu Nov 7 09:42:09 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 4XkcYW46TGz5cd7G for ; Thu, 07 Nov 2024 09:42:23 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic302-21.consmr.mail.gq1.yahoo.com (sonic302-21.consmr.mail.gq1.yahoo.com [98.137.68.147]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4XkcYV56rJz4GJW for ; Thu, 7 Nov 2024 09:42:22 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=lTGVcvy9; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1730972540; bh=hWGT67kAH9fHRhPcymILSCmUKNuD+bohbPgX1Mipp/c=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=lTGVcvy9/+DD7TnvIhDmLV0PlLgjnLFxBm8PLYq1K5ano7CWKLOLMbadz4Bbizq5FDroujdGz2TTTjtq2GO1QJbRaFpO864G9StEStTW2Z/EAdA2iu4w0A85k5TFiRYbmVpAwQIKaOBCIeNQx46bbCRzUTDJHIRNOmFG71fOM9W1sl79E9Kv7snNj8QjtHrgA0UWYec7v6ICRo4CCmFNvL+kmMuukBnLKixdWfa+CmIpEPYhupexFzPo0/txHNk3u9r5z6Jf8GCDYnJwMMJ0I8lyzxFMTB721K2tiZtxKRnAdHkuPJ/iQahx1huGo8nXKcwEcF2l53Hu3QUWolsLCA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1730972540; bh=2xYbDJR0XlX08kxJwf5zsXOdsQ6zluRD+UKsVDLXaCI=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=j56vltQA6TLGQLg4AoJRAiIXzfktXNcqkVkYvgDk4XBITmReQ83vuUMjHA+VSKpx6YcsP5NtVfJXafd5lsFQSBmz2KZFDebNp7O4JD4PH+wGSHdMTuNMHPzvgyhu7ke1XxjQAXAoiRKoAL7RG3GvJPFRDZzhYzb8RcRII2Y+jjGfZTh4nObJouurYWHvD+2nca3xM3wI5dkUbecD+3Is4ygkxdpAPQS1PQdSXHJK1VcNy2yjPYfwEZRbX0QntBqH7djpl7XcuAN+T3P4unOjFc7Oopm52P7G09YV8RgHPtmJMvncziL566a9CKpNApOo1i1isL8F2+TCNYkQj9YJyA== X-YMail-OSG: jQmMCXsVM1lx8rnz_C4.4TrYLqY199JkmKruVm27u6_VWQyFJ.XsAK_Dv6QCO3J oKUy3v65ecZ0Z6bWLUmyhsqUHj3TDbeDlwXtaSNgWSgggyvOOWti7_9PSWt5FFTRDVfm8nfJU1pj SVumPIQVEqZdmps6r9Z.eX9X4ZXFaFiT7S227SH3.I6FeKtUuAkfKOgD.yjEE1.umSz0RjQJE05p 1A6wNi33E5tjj6Ho02b_SfW3zXxPHRGeNiITmoAGa96qfF2cBn0UO83bbQsQyRKWoGxkNYq0Ma0M _Urt8MGfqISko1Jsj1EMHirOIzqOZcR1im3gbY1iKvP5h1wqvrmc2RZAxfzCjiV9sTs71m_wGZyd QcEczewdwAy4190DujnMpO2TXp122JryN7bw3NbRrEB8qNmw9IqTDfYfmS2nrXM.ZpqKTmfYJzVR w3eqaHrA8z5lppkOME0RvquQbCV7lw8tErVQGNoPtg005f956ykodRHDYfOtXdOtqUw6Ly_Qhno5 JYYSecHSZQE4lNrRSTYgq4cboi_.cmn3.FTgzqI01QW28FS4Gt64G5EwsW_O0sDDCaKwUPpHQq_T HzI3hBIvwTHX1tYKns8wv0Gob5HtGMTZ7AYdskyPYuRXwV53Dhj_UpEUbZfPNAyXWqBFen9a39EO _s7ctW2GFydf09ihFCIvAks.KsMCoWk1gbNqXchDb_thOT.Fc_Vjhntv00SZWiL5K2d36nv918pJ Y3mhiP9E5dRbEWRGHfB9enkD3rSHPGDxEFu2e_tW3JrwrN6Afh851WUIqfrONjpoX5u2LgfEB.iv 1Od27XlWbkoGExFUehmKCzhBtj1kUATBMufgwwZji.DRgshZb8e9Axcz6bfXByASIntSsqw4qPTF GmoPGcUaQQ7aQQnMaklVwBdbW_ypE1Mh4vftW9p4XhFwKdG3nihwzKkg2PxH9POni9mn9xURmr1u j.XDIDkzyRPTCcbuvBmR3rS5G2NWJDGnI5E9qaeJhm3bfLpubvbm2wPr6NKGYqA9Kjk4K7PXeYbP UuL0187vNM8wsYIviEiIAaHAd5_GX47DZEl1VUOY0DjBPVsIvizhqq4.pGQFM4KpBgYjfQxto5wB RodlujTwfKooZiDhhmONaM3J30COACCn1.D5Ga6yF.RuODb67_OGdETNHLV7h1_gZk0tnri9asIK eUial1oCyPbI0oUbOapztzdx4KxpAnLNPu_6eGR8wfxJ0Vg5KkHScq93cFA9u_mu7F9Xk8XEHjdk q8n_iXUqtBfHPd134rp7By23sQ3Zh1s2DOT6EvEQbctL71EH4Iw0RnPCDMVxT579H5L1X9m3uDTb lsk97tMx3of8qA4TfCsHfxbuJ5Won9G_PcXhX033Ecjqn85Ge522MPhfeTn2Zo4cjqP3NoXO7eQA 49MYroobyJHySZbMjfNGsJeNVuJQp0BvxKHB6_gk6OeqczwOd.73Zquo5oxiAXC2qhWGglYbZzef wTlO9nwYNZYZCimZHiSacQ6LsURxUucMZ05_boFCPkIYnHxbKr_KVJEbKX25FzZFFlFxGRtOwUoD aKx2iAr7H1KSX2TeucGeZOP.Y9qk8Q7gW9Fr3wdR2Icc5iVMeADhpWk0qlcQguDyPGwXWjveoKl1 .lEcLwhy4b06qcrJ1I0cdNo_GmffcQfdeVHd1SFn7XKiSo.oRSGDneRC9PsiaGgFjyH.7TiJZMBP f3P0lcIZBGHBsJ0XousLPsROE1LM3M8o1eOEl0Q57DKinUG2Bw1rfhIsnNVNdRVifOgnnbP4M7wb Dg47_gl37wN1O0dUBwJ_ZXPOHo4.e7Z8EzCVYdjyt3C6FHp801pXTGk5pTU4Gq2qmqjcaDQfCE8q CsAfKa.KgIRcHQfC427Nz_p_yhyOfwnyh7pHzWGYsmJ7XeJxyHFwNdI.M9ZykcA5ySPYINoC4Nvl 5uEjlnxkoBSO8hbcy.S2qO_DNayrkc7ljhwLfnZtb7JFMVxI8HsLfKEEeei8s0jGpRdnd4rTYePB _9.SJRN92YrtuhefK.dxHaNnz_Ii.dmmjZhjmGyN1zBu1VQWe2n9vOWY.teEqUXRIGVB3BOvaf3d CSWeeRmkjjVPIrUyzqlsc9gaCofmYF71UWH8MyhOpx5j0V_ELCrfdptjHfnUdBb_CNRMlJgn8rxT mWPaxSn.RiGYE0E56pM3HIxXy8aW0LGaIo.NwXTR._w7F06RtM.1sQ3U9IJHAHZKa6uSRA3rlsIJ WLBPSFCsBw4XW2YkDL1CZoQfSNfyqTDl89y48TlJnarD5dIMKz6kCUVgz0GzzVhrq_vtSfoCRSih 52XX1lw0- X-Sonic-MF: X-Sonic-ID: 4e4ab4d0-80d2-49ef-8b96-17e76715c877 Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.gq1.yahoo.com with HTTP; Thu, 7 Nov 2024 09:42:20 +0000 Received: by hermes--production-gq1-5dd4b47f46-dvwsq (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID d50dd29a4ceedb4c7a7efd4e438d1b88; Thu, 07 Nov 2024 09:42:19 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51\)) Subject: Official armv7 PkgBase kernel-NODEBUG installation's USB2 boot gets "Fatal kernel mode data abort: 'Alignment Fault' on write" very early, at least on an OrangePi+ 2ed Message-Id: Date: Thu, 7 Nov 2024 01:42:09 -0800 To: FreeBSD ARM List , Current FreeBSD X-Mailer: Apple Mail (2.3776.700.51) References: X-Spamd-Result: default: False [-3.58 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.58)[-0.579]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.147:from]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.147:from] X-Rspamd-Queue-Id: 4XkcYV56rJz4GJW X-Spamd-Bar: --- Note: Unfortunately, the panics here are too early for a dump device to be available. Context started PkgBase upgrade from: # uname -apKU FreeBSD OPiP2E-RPi2v1p1 15.0-CURRENT FreeBSD 15.0-CURRENT = main-n272821-37798b1d5dd1 GENERIC-NODEBUG arm armv7 1500025 1500025 Installed packages to be UPGRADED: FreeBSD-dtb: 15.snap20241009161500 -> 15.snap20241028121139 = [base] FreeBSD-kernel-generic: 15.snap20241011221604 -> = 15.snap20241106134422 [base] FreeBSD-kernel-generic-dbg: 15.snap20241011221604 -> = 15.snap20241106134422 [base] FreeBSD-kernel-generic-mmccam: 15.snap20241011221604 -> = 15.snap20241106134422 [base] FreeBSD-kernel-generic-mmccam-dbg: 15.snap20241011221604 -> = 15.snap20241106134422 [base] FreeBSD-kernel-generic-nodebug: 15.snap20241011221604 -> = 15.snap20241106134422 [base] FreeBSD-kernel-generic-nodebug-dbg: 15.snap20241011221604 -> = 15.snap20241106134422 [base] FreeBSD-src-sys: 15.snap20241011221604 -> 15.snap20241106160110 = [base] (Those were installed but the FreeBSD-dtb had linux 6.4 dtb files, not the 6.8 ones. 6.8 ones from a personal build were copied to where they need to be. I've separately reported the 6.4 vs. 6.8 issue.) # ~/pkgbase-snapshot-list.sh Via pkg-static info -C -x '^FreeBSD-' . . . 1 FreeBSD-*-15.snap20241106160110 6 FreeBSD-*-15.snap20241106134422 1 FreeBSD-*-15.snap20241028121139 3 FreeBSD-*-15.snap20241011221604 2 FreeBSD-*-15.snap20241011210446 38 FreeBSD-*-15.snap20241011182434 4 FreeBSD-*-15.snap20241011073851 5 FreeBSD-*-15.snap20241010141501 1 FreeBSD-*-15.snap20241010120743 296 FreeBSD-*-15.snap20241009161500 Instead via /var/cache/pkg/*.snap*.pkg . . . 1 FreeBSD-*-15.snap20241106160110 6 FreeBSD-*-15.snap20241106134422 1 FreeBSD-*-15.snap20241028121139 10 FreeBSD-*-15.snap20241011221604 2 FreeBSD-*-15.snap20241011210446 38 FreeBSD-*-15.snap20241011182434 4 FreeBSD-*-15.snap20241011073851 5 FreeBSD-*-15.snap20241010141501 1 FreeBSD-*-15.snap20241010120743 297 FreeBSD-*-15.snap20241009161500 The failure (kernel-GENERIC-NODEBUG): . . . Root mount waiting for: usbus3 CAM Fatal kernel mode data abort: 'Alignment Fault' on write trapframe: 0xc6c9ac10 FSR=3D00000801, FAR=3Ddb23209b, spsr=3D20000013 r0 =3Ddb232080, r1 =3D00000000, r2 =3D00000006, r3 =3D00000024 r4 =3Ddb19e280, r5 =3D00000000, r6 =3D00000001, r7 =3D00000006 r8 =3Dc6c9ad20, r9 =3Dc0b7973c, r10=3Dc092074c, r11=3Dc6c9acb8 r12=3D00000000, ssp=3Dc6c9aca0, slr=3Dc01b01d8, pc =3Dc01aff88 panic: Fatal abort cpuid =3D 1 time =3D 3 KDB: stack backtrace: db_trace_self() at db_trace_self pc =3D 0xc0667004 lr =3D 0xc0078630 = (db_trace_self_wrapper+0x30) sp =3D 0xc6c9a9c8 fp =3D 0xc6c9aae0 db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc =3D 0xc0078630 lr =3D 0xc0328db8 (vpanic+0x140) sp =3D 0xc6c9aae8 fp =3D 0xc6c9ab08 r4 =3D 0x00000100 r5 =3D 0x00000000 r6 =3D 0xc084d1f1 r7 =3D 0xc0b69a94 vpanic() at vpanic+0x140 pc =3D 0xc0328db8 lr =3D 0xc0328c78 (vpanic) sp =3D 0xc6c9ab10 fp =3D 0xc6c9ab14 r4 =3D 0xc6c9ac10 r5 =3D 0x00000013 r6 =3D 0xdb23209b r7 =3D 0x00000001 r8 =3D 0x00000801 r9 =3D 0x00000013 r10 =3D 0xdb23209b vpanic() at vpanic pc =3D 0xc0328c78 lr =3D 0xc068c8e8 (abort_align) sp =3D 0xc6c9ab1c fp =3D 0xc6c9ab48 r4 =3D 0x00000001 r5 =3D 0x00000801 r6 =3D 0x00000013 r7 =3D 0xdb23209b r8 =3D 0xc6c9ab14 r9 =3D 0xc0328c78 r10 =3D 0xc6c9ab1c abort_align() at abort_align pc =3D 0xc068c8e8 lr =3D 0xc068c958 (abort_align+0x70) sp =3D 0xc6c9ab50 fp =3D 0xc6c9ab68 r4 =3D 0xc6d21c00 r10 =3D 0xdb23209b abort_align() at abort_align+0x70 pc =3D 0xc068c958 lr =3D 0xc068c5e0 (abort_handler+0x430) sp =3D 0xc6c9ab70 fp =3D 0xc6c9ac08 r4 =3D 0x00000000 r10 =3D 0xdb23209b abort_handler() at abort_handler+0x430 pc =3D 0xc068c5e0 lr =3D 0xc0669868 (exception_exit) sp =3D 0xc6c9ac10 fp =3D 0xc6c9acb8 r4 =3D 0xdb19e280 r5 =3D 0x00000000 r6 =3D 0x00000001 r7 =3D 0x00000006 r8 =3D 0xc6c9ad20 r9 =3D 0xc0b7973c r10 =3D 0xc092074c exception_exit() at exception_exit pc =3D 0xc0669868 lr =3D 0xc01b01d8 (usb_msc_auto_quirk+0xfc) sp =3D 0xc6c9aca0 fp =3D 0xc6c9acb8 r0 =3D 0xdb232080 r1 =3D 0x00000000 r2 =3D 0x00000006 r3 =3D 0x00000024 r4 =3D 0xdb19e280 r5 =3D 0x00000000 r6 =3D 0x00000001 r7 =3D 0x00000006 r8 =3D 0xc6c9ad20 r9 =3D 0xc0b7973c r10 =3D 0xc092074c r12 =3D 0x00000000 bbb_command_start() at bbb_command_start+0x4c pc =3D 0xc01aff88 lr =3D 0xc01b01d8 (usb_msc_auto_quirk+0xfc) sp =3D 0xc6c9acc0 fp =3D 0xc6c9acf8 r4 =3D 0xdb16d800 r5 =3D 0xdb19e280 r6 =3D 0x00000001 r10 =3D 0xc092074c usb_msc_auto_quirk() at usb_msc_auto_quirk+0xfc pc =3D 0xc01b01d8 lr =3D 0xc01a4bd8 (usb_alloc_device+0x9c4) sp =3D 0xc6c9ad00 fp =3D 0xc6c9ad68 r4 =3D 0x00000000 r5 =3D 0x00000001 r6 =3D 0x00000000 r7 =3D 0x00000002 r8 =3D 0xdb16d800 r9 =3D 0xda241c78 r10 =3D 0x000003ee usb_alloc_device() at usb_alloc_device+0x9c4 pc =3D 0xc01a4bd8 lr =3D 0xc01ad16c (uhub_explore+0x494) sp =3D 0xc6c9ad70 fp =3D 0xc6c9adc0 r4 =3D 0x00000000 r5 =3D 0x00000000 r6 =3D 0xdb16e800 r7 =3D 0x00000000 r8 =3D 0xdb18c200 r9 =3D 0x00000001 r10 =3D 0x00000000 uhub_explore() at uhub_explore+0x494 pc =3D 0xc01ad16c lr =3D 0xc0198654 (usb_bus_explore+0x1d4) sp =3D 0xc6c9adc8 fp =3D 0xc6c9add8 r4 =3D 0xda241c78 r5 =3D 0xdb16e800 r6 =3D 0x00000000 r7 =3D 0xda241d6c r8 =3D 0xc09b0b5f r9 =3D 0x00000001 r10 =3D 0xda241d1c usb_bus_explore() at usb_bus_explore+0x1d4 pc =3D 0xc0198654 lr =3D 0xc01b22d0 (usb_process+0x124) sp =3D 0xc6c9ade0 fp =3D 0xc6c9ae10 r4 =3D 0xda241d0c r5 =3D 0xda241d14 usb_process() at usb_process+0x124 pc =3D 0xc01b22d0 lr =3D 0xc02da4f0 (fork_exit+0xb0) sp =3D 0xc6c9ae18 fp =3D 0xc6c9ae38 r4 =3D 0xc6c9ae40 r5 =3D 0xc6d21c00 r6 =3D 0xc6d08740 r7 =3D 0xda241d0c r8 =3D 0xc01b21ac r9 =3D 0x00000000 r10 =3D 0x00000000 fork_exit() at fork_exit+0xb0 pc =3D 0xc02da4f0 lr =3D 0xc06697fc (swi_exit) sp =3D 0xc6c9ae40 fp =3D 0x00000000 r4 =3D 0xc01b21ac r5 =3D 0xda241d0c r6 =3D 0x00000000 r7 =3D 0x00000000 r8 =3D 0x00000000 r10 =3D 0x00000000 swi_exit() at swi_exit pc =3D 0xc06697fc lr =3D 0xc06697fc (swi_exit) sp =3D 0xc6c9ae40 fp =3D 0x00000000 KDB: enter: panic [ thread pid 14 tid 100069 ] Stopped at kdb_enter+0x54: ldrb r15, [r15, r15, ror r15]! db>=20 Looking at bbb_command_start() 's pc: # llvm-addr2line -e /boot/kernel.GENERIC-NODEBUG/kernel 0xc01aff88 /home/pkgbuild/worktrees/main/sys/dev/usb/usb_msctest.c:554 What leads to that line is: = /*------------------------------------------------------------------------= * * bbb_command_start - execute a SCSI command synchronously =20 * =20 * Return values * 0: Success * Else: Failure = *------------------------------------------------------------------------*= / static int bbb_command_start(struct bbb_transfer *sc, uint8_t dir, uint8_t lun, =20= void *data_ptr, size_t data_len, void *cmd_ptr, size_t cmd_len, usb_timeout_t data_timeout) { sc->lun =3D lun; sc->dir =3D data_len ? dir : DIR_NONE; sc->data_ptr =3D data_ptr; sc->data_len =3D data_len; sc->data_rem =3D data_len; sc->data_timeout =3D (data_timeout + USB_MS_HZ); sc->actlen =3D 0; sc->error =3D 0; sc->cmd_len =3D cmd_len; memset(&sc->cbw->CBWCDB, 0, sizeof(sc->cbw->CBWCDB)); The memset line is line 554 of sys/dev/usb/usb_msctest.c . I'll note that attempting to use the WITNESS variant of the kernel ( /boot/kernel/ ) gets a different, even earlier failure: . . . VT: init without driver. panic: acquiring blockable sleep lock with spinlock or critical section = held (sleep mutex) pmap @ = /home/pkgbuild/worktrees/main/sys/arm/arm/pmap-v6.c:6455 cpuid =3D 0 time =3D 1 KDB: stack backtrace: Fatal kernel mode data abort: 'Translation Fault (L1)' on read trapframe: 0xc0f14568 FSR=3D00000005, FAR=3Ddb7fcfb1, spsr=3D200001d3 r0 =3Dc0f1465c, r1 =3D00000001, r2 =3Ddb7fcfae, r3 =3D1b000a4e r4 =3Dc07fc55c, r5 =3D8fce1b89, r6 =3D00006f3e, r7 =3D81000000 r8 =3Dc07c4b6c, r9 =3Dc094ace8, r10=3Dc09741d8, r11=3Dc0f14618 r12=3Dc0f146c4, ssp=3Dc0f145fc, slr=3Dc0601428, pc =3Dc062686c panic: Fatal abort cpuid =3D 0 time =3D 1 KDB: stack backtrace: Fatal kernel mode data abort: 'Translation Fault (L1)' on read trapframe: 0xc0f141f0 FSR=3D00000005, FAR=3Ddb7fcfb1, spsr=3D200001d3 r0 =3Dc0f142e4, r1 =3D00000001, r2 =3Ddb7fcfae, r3 =3D1b000a4e r4 =3Dc07fc55c, r5 =3D8fce1b89, r6 =3D00006f3e, r7 =3D81000000 r8 =3Dc07c4b6c, r9 =3Dc094ace8, r10=3Dc09741d8, r11=3Dc0f142a0 r12=3Dc0f1434c, ssp=3Dc0f14284, slr=3Dc0601428, pc =3Dc062686c panic: Fatal abort cpuid =3D 0 time =3D 1 KDB: stack backtrace: Fatal kernel mode data abort: 'Translation Fault (L1)' on read trapframe: 0xc0f13e78 FSR=3D00000005, FAR=3Ddb7fcfb1, spsr=3D200001d3 r0 =3Dc0f13f6c, r1 =3D00000001, r2 =3Ddb7fcfae, r3 =3D1b000a4e r4 =3Dc07fc55c, r5 =3D8fce1b89, r6 =3D00006f3e, r7 =3D81000000 r8 =3Dc07c4b6c, r9 =3Dc094ace8, r10=3Dc09741d8, r11=3Dc0f13f28 r12=3Dc0f13fd4, ssp=3Dc0f13f0c, slr=3Dc0601428, pc =3Dc062686c panic: Fatal abort cpuid =3D 0 time =3D 1 KDB: stack backtrace: Fatal kernel mode data abort: 'Translation Fault (L1)' on read trapframe: 0xc0f13b00 FSR=3D00000005, FAR=3Ddb7fcfb1, spsr=3D200001d3 r0 =3Dc0f13bf4, r1 =3D00000001, r2 =3Ddb7fcfae, r3 =3D1b000a4e r4 =3Dc07fc55c, r5 =3D8fce1b89, r6 =3D00006f3e, r7 =3D81000000 r8 =3Dc07c4b6c, r9 =3Dc094ace8, r10=3Dc09741d8, r11=3Dc0f13bb0 r12=3Dc0f13c5c, ssp=3Dc0f13b94, slr=3Dc0601428, pc =3Dc062686c panic: Fatal abort cpuid =3D 0 time =3D 1 KDB: stack backtrace: Fatal kernel mode data abort: 'Translation Fault (L1)' on read trapframe: 0xc0f13788 FSR=3D00000005, FAR=3Ddb7fcfb1, spsr=3D200001d3 r0 =3Dc0f1387c, r1 =3D00000001, r2 =3Ddb7fcfae, r3 =3D1b000a4e r4 =3Dc07fc55c, r5 =3D8fce1b89, r6 =3D00006f3e, r7 =3D81000000 r8 =3Dc07c4b6c, r9 =3Dc094ace8, r10=3Dc09741d8, r11=3Dc0f13838 r12=3Dc0f138e4, ssp=3Dc0f1381c, slr=3Dc0601428, pc =3Dc062686c . . . Looking: # llvm-addr2line -e /boot/kernel.GENERIC-NODEBUG/kernel 0xc062686c /home/pkgbuild/worktrees/main/sys/vm/uma_core.c:5676 static int sysctl_handle_uma_zone_frees(SYSCTL_HANDLER_ARGS) { uma_zone_t zone =3D arg1; uint64_t cur; =20 cur =3D uma_zone_get_frees(zone); return (sysctl_handle_64(oidp, &cur, 0, req)); } The "return" line is 5676 of sys/vm/uma_core.c . Also, for what leads up to: /home/pkgbuild/worktrees/main/sys/arm/arm/pmap-v6.c:6455 /* =20 * The implementation of pmap_fault() uses IN_RANGE2() macro which * depends on the fact that given range size is a power of 2. */ CTASSERT(powerof2(NB_IN_PT1)); CTASSERT(powerof2(PT2MAP_SIZE)); =20 #define IN_RANGE2(addr, start, size) \ ((vm_offset_t)(start) =3D=3D ((vm_offset_t)(addr) & ~((size) - 1))) =20 /* * Handle access and R/W emulation faults. */ int pmap_fault(pmap_t pmap, vm_offset_t far, uint32_t fsr, int idx, bool = usermode) { pt1_entry_t *pte1p, pte1; pt2_entry_t *pte2p, pte2; =20 if (pmap =3D=3D NULL) pmap =3D kernel_pmap; =20 /* * In kernel, we should never get abort with FAR which is in = range of * pmap->pm_pt1 or PT2MAP address spaces. If it happens, stop = here * and print out a useful abort message and even get to the = debugger * otherwise it likely ends with never ending loop of aborts. */ =20 if (__predict_false(IN_RANGE2(far, pmap->pm_pt1, NB_IN_PT1))) { /* * All L1 tables should always be mapped and present. * However, we check only current one herein. For user = mode, =20 * only permission abort from malicious user is not = fatal. * And alignment abort as it may have higher priority. */ if (!usermode || (idx !=3D FAULT_ALIGN && idx !=3D = FAULT_PERM_L2)) { CTR4(KTR_PMAP, "%s: pmap %#x pm_pt1 %#x far = %#x", __func__, pmap, pmap->pm_pt1, far); panic("%s: pm_pt1 abort", __func__); } return (KERN_INVALID_ADDRESS); }=20 if (__predict_false(IN_RANGE2(far, PT2MAP, PT2MAP_SIZE))) { /* * PT2MAP should be always mapped and present in current * L1 table. However, only existing L2 tables are mapped * in PT2MAP. For user mode, only L2 translation abort = and * permission abort from malicious user is not fatal. * And alignment abort as it may have higher priority. */ if (!usermode || (idx !=3D FAULT_ALIGN && idx !=3D FAULT_TRAN_L2 && idx !=3D FAULT_PERM_L2)) { CTR4(KTR_PMAP, "%s: pmap %#x PT2MAP %#x far = %#x", __func__, pmap, PT2MAP, far); panic("%s: PT2MAP abort", __func__); } return (KERN_INVALID_ADDRESS); } /* * A pmap lock is used below for handling of access and R/W = emulation * aborts. They were handled by atomic operations before so some * analysis of new situation is needed to answer the following = question: * Is it safe to use the lock even for these aborts? * * There may happen two cases in general: * * (1) Aborts while the pmap lock is locked already - this = should not * happen as pmap lock is not recursive. However, under pmap = lock only * internal kernel data should be accessed and such data should = be * mapped with A bit set and NM bit cleared. If double abort = happens, * then a mapping of data which has caused it must be fixed. = Further, * all new mappings are always made with A bit set and the bit = can be * cleared only on managed mappings. * * (2) Aborts while another lock(s) is/are locked - this already = can * happen. However, there is no difference here if it's either = access or * R/W emulation abort, or if it's some other abort. */ PMAP_LOCK(pmap); That "PMAP_LOCK(pmap);" line is line 6455 of sys/arm/arm/pmap-v6.c . FYI: Running the prior kernel.GENERIC-NODEBUG/ ( called kernel.GENERIC-NODEBUG.good/ ) continues to operate normally. I do not have the older PkgBase kernel/ around to try, unfortunately. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu Nov 7 10:43:49 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 4XkdwW6CZxz5chBZ for ; Thu, 07 Nov 2024 10:43:55 +0000 (UTC) (envelope-from joh.hendriks@gmail.com) Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4XkdwW1c1nz4Nr5 for ; Thu, 7 Nov 2024 10:43:55 +0000 (UTC) (envelope-from joh.hendriks@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x631.google.com with SMTP id a640c23a62f3a-a9a977d6cc7so48298566b.3 for ; Thu, 07 Nov 2024 02:43:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1730976234; x=1731581034; darn=freebsd.org; h=in-reply-to:from:content-language:references:cc:to:subject :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=smwKy7kzI1IHtLO0sXy6cgEH9G8/4h7Wbu3I22M0JaI=; b=ctEawXykRLi0ccejIUYheGgnEhVpxdu7Tz/Cph8oClT+e4U2Z7AmjxxNOJGCHcN4G5 jLjSCo5IpglJhr9IVYlSPah1xMG6WahojcqeV+IT1YH72rwzPhfvsPo+W+ksfybEVSq8 YaRNUhEJFCBklQZHuIy/8xSoObrzoreYI+FXHqSXk5V2WL14ncdzD4E3+hOOECl+ilQu k5jvGPxoxevMSHSrpiEWZLv6KUeofYOKqaOWkny1kllymnLjvosCK1xJbcRtZ6i33sN6 eIeb4SI6QTAFBGkzew2s3/QjzEwm0V6zp2j0m/0t/Hi2BSSkeBypiKnrjhybLOP38ani d2+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730976234; x=1731581034; h=in-reply-to:from:content-language:references:cc:to:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=smwKy7kzI1IHtLO0sXy6cgEH9G8/4h7Wbu3I22M0JaI=; b=HyM0xDKm0YJJZj1QnXH+ylpeOiiwbv2iOgW4AKaly4s6wl6wG9JMqNAg96Smm7bFyl 0mDeOuJIV+gNPaQbXq3zXkCHQbIZhlmnfBAVJ8Oi0gCh+5E1m0vzqelEtD8qNKO3Dh8s 0ceMIxZ7ybh/R2bZiNiiReq7XlBcrP9YkKhVyTjXtB++E1TkM6tig5eGjYdrFEPPHu+L 70MXdHmT4sufu0QuyNDPrVosx4pYK7LmSg4PqN5JQmMFs5YW1r3XcjfS5mPvKZ1dmwXm bsUUyBfGzUfqQS2tYg9RcEx2v1MUmyKWCla6rlKJxm2EEuKbRATix5kMxXAKmkOvH4hz vYXw== X-Gm-Message-State: AOJu0Yx8GaJaV+25hEIWODBtaDifVWfYQDOyB7TBhBGzwYxIdGWBSCj8 Ou4skiYNabklsd32ykSGWr7tV6+m8jBG0qHrlOavCyopRYL38HAU X-Google-Smtp-Source: AGHT+IFAdha4oymUl3Sl3kc5er0NE6OsgmOhOvIcmS5CMKKrsG0uBXaWnwSBsAGhVUNtxYO0ltOMag== X-Received: by 2002:aa7:ce1a:0:b0:5cb:bebb:38d8 with SMTP id 4fb4d7f45d1cf-5ceb9263166mr22206117a12.14.1730976233345; Thu, 07 Nov 2024 02:43:53 -0800 (PST) Received: from ?IPV6:2001:1c04:1337:b400:f1cd:e88f:7af0:a4ca? (2001-1c04-1337-b400-f1cd-e88f-7af0-a4ca.cable.dynamic.v6.ziggo.nl. [2001:1c04:1337:b400:f1cd:e88f:7af0:a4ca]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5cf03b5c91esm638443a12.4.2024.11.07.02.43.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 Nov 2024 02:43:52 -0800 (PST) Content-Type: multipart/alternative; boundary="------------aGlgdLZPdcpFJ8ka1Dz1ceR9" Message-ID: <97788ab0-db70-4413-8b18-f9d95f1d120f@gmail.com> Date: Thu, 7 Nov 2024 11:43:49 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: BRT copying feature To: Ronald Klop Cc: FreeBSD Current References: <1568966692.4590.1730895354064@localhost> Content-Language: en-US From: Johan Hendriks In-Reply-To: <1568966692.4590.1730895354064@localhost> 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:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4XkdwW1c1nz4Nr5 X-Spamd-Bar: ---- This is a multi-part message in MIME format. --------------aGlgdLZPdcpFJ8ka1Dz1ceR9 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 06/11/2024 13:15, Ronald Klop wrote: > Hi, > > When you create a new pool you can use something like this: > zpool create -o feature@block_cloning=disabled ... > > I tried setting this on an existing pool. That gave me an error. > # zpool set feature@block_cloning=disabled zdata4 > cannot set property for 'zdata4': property 'feature@block_cloning' can > only be set to 'disabled' at creation time > > So to install a new 14.2 system you need to do some manual work to > create the root pool with the options you prefer. > > Regards, > Ronald. > > *Van:* Johan Hendriks > *Datum:* woensdag, 6 november 2024 09:37 > *Aan:* FreeBSD Current > *Onderwerp:* BRT copying feature > > I installed the latest 14.2 Beta and i noticed that on the root > pool the BRT copying feature is enabled on the pool. > I know i need to set vfs.zfs.bclone_enabled=1 to really make us of > it. But i do not want this on my root pool but i do want to use it > on my storage pool. > I can not disable this feature on the root pool as it is a feature > that can only be set at creation time. > > Is there a way to use this feature only on selected pools? > > regards, > Johan Hendriks > > ------------------------------------------------------------------------ > > I think that it would be nice if the installer has the option to set a feature like this to off. Is it easy to break out of the installer, create the pool before hand and use that pool? Regards, Johan. --------------aGlgdLZPdcpFJ8ka1Dz1ceR9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit


On 06/11/2024 13:15, Ronald Klop wrote:
Hi,

When you create a new pool you can use something like this:
zpool create -o feature@block_cloning=disabled ...

I tried setting this on an existing pool. That gave me an error.
# zpool set feature@block_cloning=disabled zdata4
cannot set property for 'zdata4': property 'feature@block_cloning' can only be set to 'disabled' at creation time

So to install a new 14.2 system you need to do some manual work to create the root pool with the options you prefer.

Regards,
Ronald.

 

Van: Johan Hendriks <joh.hendriks@gmail.com>
Datum: woensdag, 6 november 2024 09:37
Aan: FreeBSD Current <freebsd-current@freebsd.org>
Onderwerp: BRT copying feature

I installed the latest 14.2 Beta and i noticed that on the root pool the BRT copying feature is enabled on the pool.
I know i need to set vfs.zfs.bclone_enabled=1 to really make us of it. But i do not want this on my root pool but i do want to use it on my storage pool.
I can not disable this feature on the root pool as it is a feature that can only be set at creation time.

Is there a way to use this feature only on selected pools?

regards,
Johan Hendriks

 

I think that it would be nice if the installer has the option to set a feature like this to off. Is it easy to break out of the installer, create the pool before hand and use that pool?

Regards,
Johan.
--------------aGlgdLZPdcpFJ8ka1Dz1ceR9-- From nobody Thu Nov 7 11:56: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 4XkgWs46z1z5clsw for ; Thu, 07 Nov 2024 11:56:09 +0000 (UTC) (envelope-from SRS0=3Qya=SC=klop.ws=ronald-lists@realworks.nl) Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24]) (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 4XkgWr0rr8z4ZYS for ; Thu, 7 Nov 2024 11:56:08 +0000 (UTC) (envelope-from SRS0=3Qya=SC=klop.ws=ronald-lists@realworks.nl) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=klop.ws header.s=rw2 header.b=kj5gfJql; spf=pass (mx1.freebsd.org: domain of "SRS0=3Qya=SC=klop.ws=ronald-lists@realworks.nl" designates 194.109.157.24 as permitted sender) smtp.mailfrom="SRS0=3Qya=SC=klop.ws=ronald-lists@realworks.nl"; dmarc=pass (policy=quarantine) header.from=klop.ws Date: Thu, 7 Nov 2024 12:56:05 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1730980566; 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=3qx/n2KK8lMteduRhKoRoS619FWWG5kjoZxXdrR57Ts=; b=kj5gfJqlcTNZwxrvsYIyFY5qkZsEsKrd4/T1fb10bYh99Oq/RYGXUMVVY1+8gGCFFhUVzY 1ngTgw482GbXpGf1U/kY2EKOpdv/w3pRp5OTycd3vqVDQT2hXmKZjK/bM0rs9/2fy7fpHd CzGmmlwSAmKyC1a41IIxE+njO2w85wh/FcunWCoXWbgcDglabXHmzhA3DSn9ebS+rjN61E DZpVFtx8aLX9ritxzbwVijaN3FAcaCc+sqOqMVx+Et5N/IBQoH26TdA9dYagHQlSEpmlJs cTSU8rYLF3HAA1SUivLSlDCFqdHoz4Y/2dkR1VEU06UDanuViUTYA7yoYWAKRA== From: Ronald Klop To: Johan Hendriks Cc: FreeBSD Current Message-ID: <982644351.5078.1730980565800@localhost> In-Reply-To: <97788ab0-db70-4413-8b18-f9d95f1d120f@gmail.com> References: <1568966692.4590.1730895354064@localhost> <97788ab0-db70-4413-8b18-f9d95f1d120f@gmail.com> Subject: Re: BRT copying feature List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_5077_1230615848.1730980565765" X-Mailer: Realworks (727.78) Importance: Normal X-Priority: 3 (Normal) X-Spamd-Result: default: False [-3.19 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.992]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine]; FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=3Qya=SC=klop.ws=ronald-lists@realworks.nl]; R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24]; R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ARC_NA(0.00)[]; TAGGED_RCPT(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL]; RCVD_COUNT_ZERO(0.00)[0]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[194.109.157.24:from]; FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=3Qya=SC=klop.ws=ronald-lists@realworks.nl]; FROM_HAS_DN(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; HAS_X_PRIO_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; DKIM_TRACE(0.00)[klop.ws:+] X-Rspamd-Queue-Id: 4XkgWr0rr8z4ZYS X-Spamd-Bar: --- ------=_Part_5077_1230615848.1730980565765 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable =20 Van: Johan Hendriks Datum: donderdag, 7 november 2024 11:43 Aan: Ronald Klop CC: FreeBSD Current Onderwerp: Re: BRT copying feature >=20 > =20 >=20 > On 06/11/2024 13:15, Ronald Klop wrote: >> Hi, >>=20 >> When you create a new pool you can use something like this: >> zpool create -o feature@block_cloning=3Ddisabled ... >>=20 >> I tried setting this on an existing pool. That gave me an error. >> # zpool set feature@block_cloning=3Ddisabled zdata4 >> cannot set property for 'zdata4': property 'feature@block_cloning' can o= nly be set to 'disabled' at creation time >>=20 >> So to install a new 14.2 system you need to do some manual work to creat= e the root pool with the options you prefer. >>=20 >> Regards, >> Ronald. >>=20 >> =20 >> Van: Johan Hendriks >> Datum: woensdag, 6 november 2024 09:37 >> Aan: FreeBSD Current >> Onderwerp: BRT copying feature >>>=20 >>> I installed the latest 14.2 Beta and i noticed that on the root pool th= e BRT copying feature is enabled on the pool. >>> I know i need to set vfs.zfs.bclone_enabled=3D1 to really make us of it= . But i do not want this on my root pool but i do want to use it on my stor= age pool. >>> I can not disable this feature on the root pool as it is a feature that= can only be set at creation time. >>>=20 >>> Is there a way to use this feature only on selected pools? >>>=20 >>> regards, >>> Johan Hendriks >>>=20 >>> =20 >>>=20 >>>=20 >>>=20 > I think that it would be nice if the installer has the option to set a fe= ature like this to off. Is it easy to break out of the installer, create th= e pool before hand and use that pool? >=20 > Regards, > Johan. Hi Johan, The installer gives me the option to partition manually (which does not giv= e me the option you are looking for) or open a shell which gives you all th= e power you need. =20 =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=A4Partitioning=E2=94=9C=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=90 =E2=94=82 How would you like to partition your disk? =E2=94=82 =E2=94=82 =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=90 =E2=94=82 =E2=94=82 =E2=94=82Auto (ZFS) Guided Root-on-ZFS =E2=94=82 = =E2=94=82 =E2=94=82 =E2=94=82Auto (UFS) Guided UFS Disk Setup =E2=94=82 = =E2=94=82 =E2=94=82 =E2=94=82Manual Manual Disk Setup (experts) =E2=94=82 = =E2=94=82 =E2=94=82 =E2=94=82Shell Open a shell and partition by hand=E2=94=82 = =E2=94=82 =E2=94=82 =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=98 =E2=94=82 =E2=94=9C=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=A4 =E2=94=82 [ OK ] [Cancel] =E2=94=82 =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=98 I can't say if you will find it easy or not. Good luck! Regards, Ronald. =20 ------=_Part_5077_1230615848.1730980565765 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable  

Van: Johan Hendriks <joh.hendriks@gmail.com>
Datum: donderdag, 7 november 2024 11:43
Aan: Ronald Klop <ronald-lists@klop.ws>
CC: FreeBSD Current <freebsd-current@freebsd.org> Onderwerp: Re: BRT copying feature

 

On 06/11/2024 13:15, Ronald Klop wrote:
Hi,

When you create a new pool you can use something like this:
zpool create -o feature@block_cloning=3Ddisabled ...

I tried setting this on an existing pool. That gave me an error.
# zpool set feature@block_cloning=3Ddisabled zdata4
cannot set property for 'zdata4': property 'feature@block_cloning' can only= be set to 'disabled' at creation time

So to install a new 14.2 system you need to do some manual work to create t= he root pool with the options you prefer.

Regards,
Ronald.

 

Van: Johan Hendriks <joh.hendriks@gmail.com> Datum: woensdag, 6 november 2024 09:37
Aan: FreeBSD Current <freebsd-current@freebsd.org&g= t;
Onderwerp: BRT copying feature

I installed the latest 14.2 Beta = and i noticed that on the root pool the BRT copying feature is enabled on t= he pool.
I know i need to set vfs.zfs.bclone_enabled=3D1 to really make us of it. Bu= t i do not want this on my root pool but i do want to use it on my storage = pool.
I can not disable this feature on the root pool as it is a feature that can= only be set at creation time.

Is there a way to use this feature only on selected pools?

regards,
Johan Hendriks

 
I think that it would be nice if the installer has the option to set a feat= ure like this to off. Is it easy to break out of the installer, create the = pool before hand and use that pool?

Regards,
Johan.


Hi Johan,

The installer gives me the option to partition manually (which does not giv= e me the option you are looking for) or open a shell which gives you all th= e power you need.
  
=E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=
=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=
=E2=94=80=E2=94=80=E2=94=A4Partitioning=E2=94=9C=E2=94=80=E2=94=80=E2=94=80=
=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=
=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=90
=E2=94=82 How would you like to partition your disk?      =E2=94=82
=E2=94=82 =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=
=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=
=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=
=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=
=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=
=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=90 =E2=94=82
=E2=94=82 =E2=94=82Auto (ZFS) Guided Root-on-ZFS                =E2=94=82 =
=E2=94=82
=E2=94=82 =E2=94=82Auto (UFS) Guided UFS Disk Setup             =E2=94=82 =
=E2=94=82
=E2=94=82 =E2=94=82Manual     Manual Disk Setup (experts)       =E2=94=82 =
=E2=94=82
=E2=94=82 =E2=94=82Shell      Open a shell and partition by hand=E2=94=82 =
=E2=94=82
=E2=94=82 =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=
=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=
=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=
=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=
=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=
=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=98 =E2=94=82
=E2=94=9C=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=
=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=
=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=
=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=
=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=
=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=
=E2=94=A4
=E2=94=82              [  OK  ]     [Cancel]              =E2=94=82
=E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=
=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=
=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=
=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=
=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=
=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=
=E2=94=98

I can't say if you will find it easy or not.
Good luck!

Regards,
Ronald.
  ------=_Part_5077_1230615848.1730980565765-- From nobody Thu Nov 7 15:31:14 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 4XkmJ470sfz5c0Zn for ; Thu, 07 Nov 2024 15:31:16 +0000 (UTC) (envelope-from SRS0=3Qya=SC=klop.ws=ronald-lists@realworks.nl) Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24]) (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 4XkmJ41QCyz40P6 for ; Thu, 7 Nov 2024 15:31:16 +0000 (UTC) (envelope-from SRS0=3Qya=SC=klop.ws=ronald-lists@realworks.nl) Authentication-Results: mx1.freebsd.org; none Date: Thu, 7 Nov 2024 16:31:14 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1730993474; 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=qOtVBwmsNvG2ZTV8rNmZNfBIhKt0nnIKXBWQWX7mMW8=; b=tNvALI2ry2GudPdR+9lxRHKu+cKO0q/6eiY5tXXp21yUkQWB/uUY7nxAF382IZoET63ouW YHHlQnEXvm3XSRwZ4jbr9V/xu51gQ2aj0fP3JQTvtgLH43AkKKWil8VP+UnC7y9v4aoAPr 47NPYSTNmH4B+oN+rimSsD0nhCInCGypLDEOMmHzEIy3+Wlg/+HCkh885V7NPwWd8oGnfW /JStONhUyYPAz6GQ7DubfrnGWiojST7ZtDgD2gCxoq2gGpPaZG+C/i8B1TkI4zSuWajtbZ 3YS3YQmXZq7C14b40gZHQ/LkeRPiew9uHOVHwV+oVUS5SCZCeq5eczLx0Fs8OA== From: Ronald Klop To: Ronald Klop Cc: Johan Hendriks , FreeBSD Current Message-ID: <2016215695.9786.1730993474125@localhost> In-Reply-To: <982644351.5078.1730980565800@localhost> References: <1568966692.4590.1730895354064@localhost> <97788ab0-db70-4413-8b18-f9d95f1d120f@gmail.com> <982644351.5078.1730980565800@localhost> Subject: Re: BRT copying feature List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_9785_1491214597.1730993473984" X-Mailer: Realworks (727.78) Importance: Normal X-Priority: 3 (Normal) 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_RCPT(0.00)[]; ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL] X-Rspamd-Queue-Id: 4XkmJ41QCyz40P6 X-Spamd-Bar: ---- ------=_Part_9785_1491214597.1730993473984 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, Another option is this. The installer /usr/sbin/bsdinstall uses a script called /usr/libexec/bsdinstall/zfsboot. Zfsboot defines this: # # Default options to use when creating zroot pool # : ${ZFSBOOT_POOL_CREATE_OPTIONS:=-O compress=lz4 -O atime=off} You can set this environment variabele to your liking before starting bsdinstall. ZFSBOOT_POOL_CREATE_OPTIONS="-O compress=lz4 -O atime=off -o feature@block_cloning=disabled" bsdinstall If you are booting from an USB stick installer you can also change the zfsboot script on the USB stick and restart the installer. NB: don't confuse the option with ZFSBOOT_BOOT_POOL_CREATE_OPTIONS. Regards, Ronald. Van: Ronald Klop Datum: donderdag, 7 november 2024 12:56 Aan: Johan Hendriks CC: FreeBSD Current Onderwerp: Re: BRT copying feature > > > Van: Johan Hendriks > Datum: donderdag, 7 november 2024 11:43 > Aan: Ronald Klop > CC: FreeBSD Current > Onderwerp: Re: BRT copying feature >> >> >> >> On 06/11/2024 13:15, Ronald Klop wrote: >>> Hi, >>> >>> When you create a new pool you can use something like this: >>> zpool create -o feature@block_cloning=disabled ... >>> >>> I tried setting this on an existing pool. That gave me an error. >>> # zpool set feature@block_cloning=disabled zdata4 >>> cannot set property for 'zdata4': property 'feature@block_cloning' can only be set to 'disabled' at creation time >>> >>> So to install a new 14.2 system you need to do some manual work to create the root pool with the options you prefer. >>> >>> Regards, >>> Ronald. >>> >>> >>> Van: Johan Hendriks >>> Datum: woensdag, 6 november 2024 09:37 >>> Aan: FreeBSD Current >>> Onderwerp: BRT copying feature >>>> >>>> I installed the latest 14.2 Beta and i noticed that on the root pool the BRT copying feature is enabled on the pool. >>>> I know i need to set vfs.zfs.bclone_enabled=1 to really make us of it. But i do not want this on my root pool but i do want to use it on my storage pool. >>>> I can not disable this feature on the root pool as it is a feature that can only be set at creation time. >>>> >>>> Is there a way to use this feature only on selected pools? >>>> >>>> regards, >>>> Johan Hendriks >>>> >>>> >>>> >>>> >>>> >> I think that it would be nice if the installer has the option to set a feature like this to off. Is it easy to break out of the installer, create the pool before hand and use that pool? >> >> Regards, >> Johan. > > > Hi Johan, > > The installer gives me the option to partition manually (which does not give me the option you are looking for) or open a shell which gives you all the power you need. > > Partitioning > How would you like to partition your disk? > > Auto (ZFS) Guided Root-on-ZFS > Auto (UFS) Guided UFS Disk Setup > Manual Manual Disk Setup (experts) > Shell Open a shell and partition by hand > > > [ OK ] [Cancel] > > > I can't say if you will find it easy or not. > Good luck! > > Regards, > Ronald. > ------=_Part_9785_1491214597.1730993473984 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi,

Another option is this.

The installer /usr/sbin/bsdinstall uses a script called /usr/libexec/bsdinstall/zfsboot. Zfsboot defines this:

#
# Default options to use when creating zroot pool
#
: ${ZFSBOOT_POOL_CREATE_OPTIONS:=-O compress=lz4 -O atime=off}

You can set this environment variabele to your liking before starting bsdinstall.

ZFSBOOT_POOL_CREATE_OPTIONS="-O compress=lz4 -O atime=off -o feature@block_cloning=disabled" bsdinstall

If you are booting from an USB stick installer you can also change the zfsboot script on the USB stick and restart the installer.

NB: don't confuse the option with ZFSBOOT_BOOT_POOL_CREATE_OPTIONS.

Regards,
Ronald.

 

Van: Ronald Klop <ronald-lists@klop.ws>
Datum: donderdag, 7 november 2024 12:56
Aan: Johan Hendriks <joh.hendriks@gmail.com>
CC: FreeBSD Current <freebsd-current@freebsd.org>
Onderwerp: Re: BRT copying feature

 

Van: Johan Hendriks <joh.hendriks@gmail.com>
Datum: donderdag, 7 november 2024 11:43
Aan: Ronald Klop <ronald-lists@klop.ws>
CC: FreeBSD Current <freebsd-current@freebsd.org>
Onderwerp: Re: BRT copying feature

 

On 06/11/2024 13:15, Ronald Klop wrote:
Hi,

When you create a new pool you can use something like this:
zpool create -o feature@block_cloning=disabled ...

I tried setting this on an existing pool. That gave me an error.
# zpool set feature@block_cloning=disabled zdata4
cannot set property for 'zdata4': property 'feature@block_cloning' can only be set to 'disabled' at creation time

So to install a new 14.2 system you need to do some manual work to create the root pool with the options you prefer.

Regards,
Ronald.

 

Van: Johan Hendriks <joh.hendriks@gmail.com>
Datum: woensdag, 6 november 2024 09:37
Aan: FreeBSD Current <freebsd-current@freebsd.org>
Onderwerp: BRT copying feature

I installed the latest 14.2 Beta and i noticed that on the root pool the BRT copying feature is enabled on the pool.
I know i need to set vfs.zfs.bclone_enabled=1 to really make us of it. But i do not want this on my root pool but i do want to use it on my storage pool.
I can not disable this feature on the root pool as it is a feature that can only be set at creation time.

Is there a way to use this feature only on selected pools?

regards,
Johan Hendriks

 
I think that it would be nice if the installer has the option to set a feature like this to off. Is it easy to break out of the installer, create the pool before hand and use that pool?

Regards,
Johan.


Hi Johan,

The installer gives me the option to partition manually (which does not give me the option you are looking for) or open a shell which gives you all the power you need.
  
Partitioning
 How would you like to partition your disk?      
  
 Auto (ZFS) Guided Root-on-ZFS                 
 Auto (UFS) Guided UFS Disk Setup              
 Manual     Manual Disk Setup (experts)        
 Shell      Open a shell and partition by hand 
  

              [  OK  ]     [Cancel]

I can't say if you will find it easy or not.
Good luck!

Regards,
Ronald.
 

  ------=_Part_9785_1491214597.1730993473984-- From nobody Thu Nov 7 15:34:30 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 4XkmMp6Q5nz5c13p; Thu, 07 Nov 2024 15:34:30 +0000 (UTC) (envelope-from salvadore@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4XkmMp64ZFz41v8; Thu, 7 Nov 2024 15:34:30 +0000 (UTC) (envelope-from salvadore@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1730993670; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=W41+ABVanZQDmGPHTklXSUH1KDiO99Zjs0mv+16I6js=; b=FWRM3OpK4XR3pHi9jE9ZYE6blEPD0hHgRWQZjtX+ubGaU0jLOD07VnE2E/tiKtCsv0ucJq 8gTJlHQBhC2wqCZgcZvAFYJESg5fNl29uI1TzI3gmXKMHyD3SlJjAA37kb9v77Bjs5h1i8 Y3LCUZNjTHqCcw50jhD4BXBe1zs2ALtCAdt7gDBGW0M5wr91IZ9CqmQigH142zjCrpX7cO XTZxy2DLnl3UTfwaySXetS//emM5cKs4NTip+fiQ/HW3xRyxAZQ88gyxZ2hyQFL4Atd+68 9O9ewoqJkU2lMVRcXQz9PqxglWDIJdDPV7gT62Oan1EXi0ZTpSsPN1SwDhKWOg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1730993670; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=W41+ABVanZQDmGPHTklXSUH1KDiO99Zjs0mv+16I6js=; b=SV5g6ZfPORctNvJE7HD+8r5JQ/n9pWkwkk+QvooNLnVLa+UUwmQOXCYo4WJ3X//pXd7H57 0cDRHFlO3P7ys0MTFIltDyOdqys/ifAXzQyJyHRarIfi16s8R0n42BaiUYLCOC+FJnKwlA +TAxZKtbLaR+FOh2t74o4RCwqk4WC4IUdefIEwdavgGNNQjSoKPMVGbKXIdHMtLime8fbJ 0N7YwIGtNx8pitt0vyzq7kGuTZDte6mgtTR+lV48/OnC9nxyAQzy82iuD0skrDkUQMLuB8 OyH9cCiQl/2gOTYgYsgHpA5wMr2wUGch/DFTPuPHXdPJB3ciLGLVEBD8E9f23g== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1730993670; a=rsa-sha256; cv=none; b=Wvgbu56wk1kQio9/NBDbeKF8xvJgcntCCN/0H8monCfVOJm1aeBM6evCKUpK7npGhnF6xw Tzkq4opPW6Gbj8kbyfP91p50aPd1wmiMdFUBMcDmGT+xpO/+/0SMjXD9UqVM6b1Pqt/lDj veV0j6T+Srs0jsHwx/hKqUwByjnVy38EmBawoHNqpJPEgDvnN7ZpUteISGffDYBqBsyN1r NfTVWInwrBIJwOiIJsJLKuc9HZZCxMWhVLwnIOyP+J2Op4qz4JRAFggPaTfNzBnNAtHOii qwPDyL1WvGPc65Z0EPVcIyYgAIdmejH/wpcIHzPgmL/4t+C6M1ALaoF+L97GkQ== Received: by freefall.freebsd.org (Postfix, from userid 1472) id C529C77AE; Thu, 07 Nov 2024 15:34:30 +0000 (UTC) Date: Thu, 7 Nov 2024 15:34:30 +0000 From: Lorenzo Salvadore To: freebsd-hackers@freebsd.org Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: FreeBSD Status Report - Third Quarter 2024 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=utf-8 Content-Disposition: inline; filename="report.txt" Content-Transfer-Encoding: 8bit FreeBSD Status Report Third Quarter 2024 Here is the third 2024 status report, with 32 entries. Unfortunately we are late this quarter, just like last quarter. As our readers know, many FreeBSD contributors are volunteers, so it is natural that less important deadlines like the status reports ones are not always met. Indeed, if you are not a FreeBSD contributor yet, please consider joining us: you could help lighten someone’s burden while learning new skills, working side by side with developers all over the world. Have a nice read. Lorenzo Salvadore, on behalf of the Status Team. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ A rendered version of this report is available here: https://www.freebsd.org/status/report-2024-07-2024-09/ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Table of Contents • FreeBSD Team Reports □ FreeBSD Core Team □ FreeBSD Foundation □ FreeBSD Release Engineering Team □ Continuous Integration □ Ports Collection □ Bugmeister Team □ FreeBSD Samba Team • Projects □ Audio Stack Improvements □ A bhyve management GUI written in Freepascal/Lazarus □ Changes to dhclient to speed up the FreeBSD boot process □ Capsicum and Bhyve Code Audit □ Endpoint-Independent NAT □ Kyua Jail Support □ Linux Source Compatibility Wiki page • Userland □ Service jails — Automatic jailing of rc.d services □ Userspace UFS Driver (fuse-ufs) • Kernel □ FreeBSD V4L2 & kernel USB Video Class driver □ mac_do(4), setcred(2), mdo(1) □ Scheduling Priorities: 256-queue Runqueues Sub-Project □ Wireless Update □ VirtIO Sockets and AF_VSOCK support • Architectures □ Pinephone Pro Support □ SIMD enhancements for aarch64 • Cloud □ FreeBSD on Microsoft HyperV and Azure □ FreeBSD on EC2 □ OpenStack on FreeBSD • Documentation □ Documentation Engineering Team □ FreeBSD Wiki □ The FreeBSD Russian Documentation Project • Ports □ GCC on FreeBSD □ Freepascal and Lazarus on FreeBSD aarch64 • Third Party Projects □ Containers and FreeBSD: Pot, Potluck and Potman ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FreeBSD Team Reports Entries from the various official and semi-official teams, as found in the Administration Page. FreeBSD Core Team Contact: FreeBSD Core Team The FreeBSD Core Team is the governing body of FreeBSD. Core welcomes René Ladan (rene@) as their new secretary. Liaisons Core selected new liaisons for the various teams among themselves: • bugmeister: glebius • ci: olivier • clusteradm: mat • doceng: lwhsu • foundation: hrs • portmgr: tcberner • re: dch • secteam: allanjude • srcmgr: glebius DevSummit 202409 • The Core Team was almost fully present at EuroBSDCon 2024 in Dublin. The following people were present: allanjude, dch, glebius, hrs, lwhsu, mat, olivier, rene • Slides are available at https://wiki.freebsd.org/DevSummit/202409 • Core met with the FreeBSD Foundation to have their periodic meeting and take the change to do it in face-to-face. Topics included improving alignment and communications between the two groups and the community. New support timeline for FreeBSD releases • Core approves the proposal by re@ to reduce the support timeline for FreeBSD releases from five to four years, after which the release is supported on a best-effort basis. This proposal is also backed by portmgr and secteam. srcmgr • Core helped in forming a new srcmgr team. Their charter is not fully set in stone yet, it can be adjusted if needed in 6-12 months from now. • Nominations for new src commit bits should from now on be sent to srcmgr@ instead of core@ • A lurker program is suggested to keep an influx of new members. • Core announced srcmgr during DevSummit 202409 and sent a follow-up to developers@ on September 29. Commit bits • Core welcomes Igor Ostapenko (igoro) as a new src committer. • Core extended the text that the grim reaper script sends to include ways on how to get commit bits of developers re-activated. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FreeBSD Foundation Links: FreeBSD Foundation URL: https://freebsdfoundation.org/ Technology Roadmap URL: https://freebsdfoundation.org/blog/technology-roadmap/ Donate URL: https://freebsdfoundation.org/donate/ Foundation Partnership Program URL: https://freebsdfoundation.org/our-donors/freebsd-foundation-partnership-program/ FreeBSD Journal URL: https://freebsdfoundation.org/journal/ Foundation Events URL: https://freebsdfoundation.org/our-work/events/ Contact: Deb Goodkin The FreeBSD Foundation is a 501(c)(3) non-profit organization dedicated to supporting and promoting the FreeBSD Project and worldwide community, and helping to advance the state of FreeBSD. We do this in both technical and non-technical ways. We are 100% supported by donations from individuals and corporations and those investments help us fund the: • Software development projects to implement features and functionality in FreeBSD • Sponsor and organize conferences and developer summits to provide collaborative opportunities and promote FreeBSD • Purchase and support of hardware to improve and maintain FreeBSD infrastructure • Resources to improve security, quality assurance, and continuous integration efforts • Materials and staff needed to promote, educate, and advocate for FreeBSD • Collaboration between commercial vendors and FreeBSD developers • Representation of the FreeBSD Project in executing contracts, license agreements, and other legal arrangements that require a recognized legal entity Even though the summer months tend to be slower, we accomplished a lot of work and you will see that in our Q3 report! Some highlights include raising over $135,000 from individual donors, and kicking off two major projects. First, thanks to a large investment from the Sovereign Tech Fund, we will be doing even more to improve our infrastructure. Second, thanks to a large investment by Quantum Leap Research and the Foundation, we will be working to accelerate a FreeBSD on Modern Laptops project. We also continued work on the Alpha-Omega funded project, hired a userland software developer, and opened a job position for a solutions specialist. As you will see below, spreading the word about FreeBSD through advocacy and community is still an important part of our mission. Over the summer, we sponsored EuroBSDCon, and the upcoming FreeBSD and OpenZFS Summits, and provided travel grants to around eight FreeBSD contributors to attend EuroBSDCon. Our advocacy team was busy producing content that promotes the benefits and strengths of FreeBSD, why companies are using FreeBSD, and why you should use FreeBSD if you care about security. We also promoted work within the Project and Foundation on social media. During EuroBSDCon, Foundation and Core Team members met to discuss Core’s questions as they navigate what they want to accomplish during their term. We identified 2 key areas to work on in the near term: 1. Financial reporting transparency - Break out operating system improvements spending in our quarterly reports. We are working with our accountant so that starting in 2025, we can report how much we are spending on certain projects and key areas, like laptop, enterprise, security…​ In the meantime, we will add notes to our financial reports that document which projects are included in the OS Improvement expense category. We are aware that we have not posted financials this year. Our accounting team is introducing us to improved reporting, while integrating our books into a new accounting system. 2. The projects we are funding are not mentioned on the Project’s website. We document these on our website, because we want to show our donors where their financial contributions are being spent. We recognize that we need to also add documentation about these projects on FreeBSD.org, so we will investigate how to better connect our software development work with the Project. We are funding a lot of software development work to advance, improve, and keep FreeBSD secure. We received funding for some of this work, but most of it is being funded by your donations and our investments. Our purpose is to focus on the long-term sustainability of FreeBSD. To do this, we need more companies stepping in to help fund our efforts. Our investments will only carry on this work for a year or two at most. If your company relies on FreeBSD, please consider giving a financial contribution so we can ensure it stays the secure, reliable, and innovative platform you depend on. Not sure how to go about asking? Please reach out. We can help you navigate the process. Please go here to make a donation: https://freebsdfoundation.org/donate/. To find out more about our Partnership Program, go here: https://freebsdfoundation.org/our-donors/freebsd-foundation-partnership-program/. OS Improvements During the third quarter of 2024, 263 src, 37 ports, and 11 doc tree commits identified The FreeBSD Foundation as a sponsor. Several members of the FreeBSD Foundation’s development team attended the FreeBSD Developer Summit in Dublin, Ireland prior to EuroBSDCon 2024. You can watch a video of the Hello From the Foundation talk to open the Summit, when: • Deb Goodkin introduced the FreeBSD Foundation • Joe Mingrone introduced members of the development team and said a few words about FreeBSD’s 2024 Google Summer Code campaign • Ed Maste described some of the current or recently completed Foundation development projects. Alice Sowerby, who recently began supporting the Foundation in Technical Program Management role, gave a talk to introduce the CHAOSS (Community Health Analytics for Open Source Software) project and how to start collecting and working with community health metrics. The Foundation, along with new funding and investment partners, is currently supporting four major projects. • The first, partially funded by Alpha-Omega, is to improve FreeBSD security. As part of this effort, the Foundation enlisted Synacktiv to run a code audit on two significant subsystems: bhyve and Capsicum. For details, refer to the dedicated Capsicum and Bhyve Code Audit report entry. • The second project, jointly funded by AMD and the Foundation, is to develop an AMD IOMMU driver for FreeBSD. The impetus for the project was to better support large core AMD systems. However, the driver will be useful in different scenarios when interrupt remapping is required. The work is nearing completion, and developer Konstantin Belousov is testing the driver on some of AMD’s large-core-count systems before committing. • The third project, backed by an investment from the Sovereign Tech Fund, is to improve FreeBSD through five key sub-projects: □ Zero Trust Builds: Enhance tooling and processes □ CI/CD Automation: Streamline software delivery and operations □ Reduce Technical Debt: Implement tools and processes to keep technical debt low □ Security Controls: Modernize and extend security artifacts, including the FreeBSD Ports and Package Collection, to assist with regulatory compliance □ SBOM Improvements: Enhance and implement new tooling and processes for FreeBSD SBOM To reduce technical debt, we have partnered with Bitergia to analyze and assess our open Bugzilla bugs. By implementing improved issue management processes and establishing open-source tooling for the long term, our goal is to achieve and sustain a manageable bug backlog. The remaining four sub-projects will begin in 2025. • The fourth project, which will be funded by both the Foundation and Quantum Leap Research, is to improve FreeBSD laptop usability. We have begun (or will soon start) supporting developers working in the following areas: □ Enhanced wireless chipset support: Expanding chipset compatibility to ensure reliable wireless connectivity and support for newer wireless standards. □ Power management: Implementing modern power-saving states (such as s2idle and s0ix) to improve battery life and energy efficiency. □ Graphics enhancements: Improving support for Intel and AMD graphics by integrating the latest DRM drivers. □ Audio improvements: Enhancing audio routing, headphone switching, and digital microphone (DMIC) functionality for a more user-friendly multimedia experience. □ Laptop-specific hardware features: Addressing specialty buttons, touchpad gestures, and other unique hardware components found in modern laptops. FreeBSD completed our 20th consecutive year participating in Google Summer of Code. The 11 projects for this summer are now complete; nine passed. The Foundation has been providing project management support for the FreeBSD Open Container Initiative (OCI) Working Group, with Alice Sowerby hosting the bi-weekly meeting, and running the recent Podman on FreeBSD testing project. The OCI develops open industry standards for cloud native container formats and runtimes, ensuring platform consistency. The FreeBSD OCI Working Group is defining these standards for FreeBSD, with implementations using jails and potentially lightweight VMs with bhyve. Refer to the Foundation’s OCI Container Support Project page for details. In other Foundation news: • Isaac Freund joined the Foundation’s development team as a Userland Developer. As the lead developer of the River Wayland Compositor and a member of the Core Zig Team, we are excited about the experience Isaac will be bringing to FreeBSD. • Alfonso Sabato Siciliano is working on a Vision Accessibility Subsystem for blind, low-vision, and color blind users. New features will include a Braille refreshable display framework, a communication channel for the virtual terminal console, a speech synthesizer, high-contrast TUI utilities, and an accessibility book to document assistive technologies available on FreeBSD. • Tom Jones, completed his work with RGNets to port the Vector Packet Processor (VPP), a layer 2-4 multi-platform network stack in userspace, to FreeBSD. You can read about Tom’s next project to support full-cone NAT for FreeBSD firewalls in his Endpoint-Independent NAT report entry. • Christos Margiolis continued to improve FreeBSD’s audio stack and provide audio developers with useful tools and frameworks to facilitate sound development on FreeBSD. Refer to the Audio Stack Improvements entry for the latest news. • Olivier Certner has two entries in this report. You can read about his latest work in the Scheduling Priorities: 256-queue Runqueues Sub-Project and mac_do(4), setcred(2), mdo(1) report entries. • Bjoern Zeeb continued to improve wireless networking on FreeBSD. You can read the latest news in Bjoern’s Wireless Update entry. • Philip Paeps continued work on a contract to modernize the FreeBSD cluster. • Chih-Hsin Chang has continued work to port OpenStack components so that the cloud computing platform can be run on FreeBSD hosts. Refer to the OpenStack on FreeBSD entry for the latest information. • Other members of the Foundation’s technology team contributed to FreeBSD development efforts. For example: □ Mitchell Horne committed work for RISC-V, including adding support for the Supervisor-mode: Page-Based Memory Types (Svpbmt) extension □ Ed Maste removed the deprecated mergemaster tool in favor of etcupdate (8) for updating files not managed by install world □ Joe Mingrone updated our base libpcap and tcpdump(1) □ Li-Wen Hsu kept our Jenkins port tracking the latest upstream versions with a number of port updates. Continuous Integration and Workflow Improvement As part of our continued support of the FreeBSD Project, the Foundation supports a full-time staff member dedicated to improving the Project’s continuous integration system and test infrastructure. Advocacy During the third quarter of 2024, we continued growing our efforts to drive awareness, advocate for the project, highlight users, and bring educational content to the FreeBSD community. Below are some of those efforts. • Presented at the EuroBSDcon 2024 FreeBSD Developer Summit. Slides and the Live stream are now available. • Attended and exhibited at EuroBSDCon 2024. The Foundation was again a Silver Sponsor. • Finalized our Bronze Sponsorship of the OpenZFS User and Developer Summit • Began planning the Fall 2024 FreeBSD Summit taking place November 7-8, 2024 in San Jose, CA. The program is now available and registration is open. • Updated the community on the new release schedule: Navigating FreeBSD’s New Quarterly and Biennial Release Schedule • Announced: New CIS® FreeBSD 14 Benchmark: Secure Your Systems with Expert-Guided Best Practices • Shared more information about the Sovereign Tech Fund’s investment in the Foundation: Sovereign Tech Fund to Invest €686,400 in FreeBSD Infrastructure Modernization • Announced the joint investment by Quantum Leap Research and FreeBSD Foundation to Improve Laptop Support and Usability and more on why we are making this investment. • Published additional blogs including: □ FreeBSD Ports and Packages: What you need to know □ Why You Should Use FreeBSD □ Enhancing Memory Safety in Programming: Insights from the FreeBSD Vendor Summit □ FreeBSD as a Platform for Your Future Technology □ Celebrating FreeBSD: Insights from Deb Goodkin • Participated in the following contributed articles, interviews and podcasts: □ Get to Know: Deb Goodkin, Executive Director, FreeBSD Foundation □ All Things Open Blog: Unlocking the Potential of FreeBSD □ Why Open Source Can Be the Perfect Place for New Developers – and How to Get Started, with Deb Goodkin from the FreeBSD Foundation □ Steady in a shifting Open Source world: FreeBSD’s enduring stability □ Apple’s Open Source Roots: The BSD Heritage Behind macOS and iOS • Published the July 2024, August 2024, and September 2024 FreeBSD Foundation Updates. • Released the May/June 2024 and July/August 2024 issues of the FreeBSD Journal with HTML versions of the articles. Legal/FreeBSD IP The Foundation owns the FreeBSD trademarks, and it is our responsibility to protect them. We also provide legal support for the core team to investigate questions that arise. Go to https://freebsdfoundation.org to find more about how we support FreeBSD and how we can help you! ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FreeBSD Release Engineering Team Links: FreeBSD 13.4-RELEASE announcement URL: https://www.freebsd.org/releases/13.4R/announce/ FreeBSD 14.2-RELEASE schedule URL: https://www.freebsd.org/releases/14.2R/schedule/ FreeBSD releases URL: https://download.freebsd.org/releases/ISO-IMAGES/ FreeBSD development snapshots URL: https://download.freebsd.org/snapshots/ISO-IMAGES/ Contact: FreeBSD Release Engineering Team, The FreeBSD Release Engineering Team is responsible for setting and publishing release schedules for official project releases of FreeBSD, announcing code freezes and maintaining the respective branches, among other things. The Team managed 13.4-RELEASE, leading to the final RELEASE build and announcement in September. Planning has started for the upcoming 14.2-RELEASE cycle. The Release Engineering Team continued providing weekly development snapshot builds for the main, stable/14, and stable/13 branches. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Continuous Integration Links: FreeBSD Jenkins Instance URL: https://ci.FreeBSD.org FreeBSD CI Tinderbox view URL: https://tinderbox.freebsd.org FreeBSD CI artifact archive URL: https://artifact.ci.FreeBSD.org Hosted CI wiki URL: https://wiki.FreeBSD.org/HostedCI 3rd Party Software CI URL: https://wiki.FreeBSD.org/3rdPartySoftwareCI Tickets related to freebsd-testing@ URL: https://bugs.freebsd.org/bugzilla/buglist.cgi?bug_status=open&email1=testing%40FreeBSD.org&emailassigned_to1=1&emailcc1=1&emailtype1=equals FreeBSD CI Repository URL: https://github.com/freebsd/freebsd-ci dev-ci Mailing List URL: https://lists.FreeBSD.org/subscription/dev-ci Contact: Jenkins Admin Contact: Li-Wen Hsu Contact: freebsd-testing Mailing List Contact: IRC #freebsd-ci channel on EFNet In the fourth quarter of 2024, we worked with the project contributors and developers to address their testing requirements. Concurrently, we collaborated with external projects and companies to enhance their products by testing more on FreeBSD. Important completed tasks: • Update main and stable/14 build environment to 14.1-RELEASE Work in progress tasks: • Improving the src/tests/ci work to support running test suites • Merging Pre-commit CI with CIRRUS-CI • Designing and implementing pre-commit CI building and testing and pull/ merge-request based system (to support the workflow working group) • Proof of concept system is in progress. • Designing and implementing use of CI cluster to build release artifacts as release engineering does, starting with snapshot builds • Simplifying CI/test environment setting up for contributors and developers • Setting up the CI stage environment and putting the experimental jobs on it • Redesigning the hardware test lab and adding more hardware for testing Open or queued tasks: • Collecting and sorting CI tasks and ideas • Setting up public network access for the VM guest running tests • Implementing use of bare-metal hardware to run test suites • Adding drm ports building tests against -CURRENT • Helping more software get FreeBSD support in its CI pipeline (Wiki pages: 3rdPartySoftwareCI, HostedCI) • Working with hosted CI providers to have better FreeBSD support Please see freebsd-testing@ related tickets for more WIP information, and do not hesitate to join the effort! Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Ports Collection Links: About FreeBSD Ports URL:https://www.FreeBSD.org/ports/ Contributing to Ports URL: https://docs.freebsd.org/en/articles/contributing/#ports-contributing Ports Management Team URL: https://www.freebsd.org/portmgr/ Ports Tarball URL: http://ftp.freebsd.org/pub/FreeBSD/ports/ports/ Contact: Tobias C. Berner Contact: FreeBSD Ports Management Team The Ports Management Team is responsible for overseeing the overall direction of the Ports Tree, building packages, and personnel matters. Below is what happened in the last quarter. According to INDEX, there are currently 36,504 ports in the Ports Collection. There are currently ~3,379 open ports PRs. The last quarter saw 11,594 commits by 154 committers on the main branch and 832 commits by 78 committers on the 2024Q3 branch. Compared to last quarter, this means a slight increase in the number of commits on the main branch (from 10,525) and about half of the backports to the quarterly branch (compared to 1,771). The number of ports also increased (up from 32,471). The most active committers to main were: • 5133 sunpoet@FreeBSD.org • 1262 yuri@FreeBSD.org • 375 jbeich@FreeBSD.org • 357 vvd@FreeBSD.org • 331 bofh@FreeBSD.org • 192 uzsolt@FreeBSD.org • 185 eduardo@FreeBSD.org • 172 diizzy@FreeBSD.org • 148 mfechner@FreeBSD.org • 131 arrowd@FreeBSD.org A lot has happened in the ports tree in the last three quarter, an excerpt of the major software upgrades are: • Default version of PostgreSQL switched to 16 • chromium updated from 126.0.6478.126 to 129.0.6668.100 • firefox updated from 127.0.2 to 131.0-rc1 • firefox-esr updated from 115.9.1 to 128.3.0-rc1 • rust updated from 1.79.0 to 1.81.0 • sdl2 updated from 2.30.3 to 2.30.7 • wlroots updated from 0.17.4 to 0.18.1 • wine-devel updated from 9.4 to 9.16 • qt5 updated from 5.15.14 to 5.15.15 • qt6 updated from 6.7.2 to 6.7.3 • plasma6 updated from 6.1.1 to 6.1.2 During the last quarter, pkgmgr@ ran 24 exp-runs to test various ports upgrades, updates to default versions of ports, and base system changes. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Bugmeister Team Links: FreeBSD Bugzilla URL: https://wiki.freebsd.org/Bugzilla Contact: Bugmeister Charts and graphs Ed Maste from the FreeBSD Foundation has expressed an interest in seeing useful charts and graphs added to Bugzilla. The few that we have now are not very informative. Many of the interesting Bugzilla queries for them have been documented, but the information there is really dense. If you are interested in working on this task, contact Ed directly. Bugzilla version upgrade Recently, upstream Bugzilla has released 5.0.4.1, which is a minor bugfix release. Preliminary work suggests that the update will be unobtrusive. Work is continuing. PR statistics PRs continue to come in and get triaged. Over the longer term, we are nearly at steady-state. The number of PRs over the past quarter (and year) has fluctuated. Vladimir Druzenko pointed out that the number dropped by around 200 during 2023Q4. (We have not done the data analysis to find out why that was.) However, slowly, the number has come back to where it was a year ago. But we do seem to be closing incoming PRs more quickly these days. For reference: https://bugs.freebsd.org/bugzilla/page.cgi?id=dashboard.html&days=365 The overall number of PRs remains at slightly over 11,600. We do have a lot of technical debt. Bugmeister is also working towards restarting the Bugathons. Acknowledgements Bugmeister would like to thank a number of people who have assisted with bugbusting, including new triagers Alexander Vereeken, Alexander Ziaee, and Frederick Lee. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FreeBSD Samba Team Links: FreeBSD Samba Team Wiki URL: https://wiki.freebsd.org/Samba Samba Homepage URL: https://www.samba.org/ Contact: FreeBSD Samba Team Samba provides secure, stable and fast file and print services for all clients using the SMB/CIFS protocol. It is an important component to seamlessly integrate FreeBSD/Linux/Unix Servers and Desktops into Active Directory environments. It can function both as a domain controller or as a regular domain member. The new FreeBSD Samba Team was created to better coordinate maintenance efforts of the Samba ports and its dependencies, in particular: • databases/ldb22 • databases/ldb25 • databases/ldb28 • databases/tdb • devel/talloc • devel/tevent • net/samba416 • net/samba419 Notable changes in the last quarter include: • Creation of the FreeBSD Samba Team by Timur Bakeyev, Xavier Beaudouin, Yasuhiro Kimura, Mateusz Piotrowski, and Mikaël Urankar. • Added SAMBA_LDB_PORT to Mk/Uses/samba.mk (sponsored by Klara, Inc.) • Switching net/samba419 to use external dependencies by default instead of vendoring (sponsored by Klara, Inc.) • Updating net/samba419 to 4.19.8 Currently, the FreeBSD Samba team is coordinating efforts in the following areas: • Switching the default version of Samba from 4.16 to 4.19 (Bugzilla PR# 280769). • Current blockers are: • Broken fruit:posix_rename = yes (Bugzilla PR#281360) • Broken replication in Samba 4.19.8_1 (Bugzilla PR#281672) • Adding Samba 4.20 to the ports tree (Bugzilla PR#280533) • Adding Samba 4.21 to the ports tree (Bugzilla PR#281262) Testing and community contributions are welcome, please reach out on Bugzilla or via the team email. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Projects Projects that span multiple categories, from the kernel and userspace to the Ports Collection or external projects. Audio Stack Improvements Contact: Christos Margiolis The FreeBSD audio stack is one of those fields that does not attract the same attention and development as others do, since it has been left largely unmaintained, and, although high in quality, there is still room for improvement — from lack of audio development frameworks, to missing userland utilities and kernel driver-related bugs. This project is meant to touch on all those areas, and as such, is more of a general improvement project, than an implementation of a specific feature. Important work since last report: • Several sound(4) fixes. • Wrote mixer(8) and sound(4) tests. • mixer(8): Implement hot-swapping • audio(8): Initial revision • sound: Implement dummy driver • Improved and added sound examples. • mididump(1): Initial revision • virtual_oss patches. • Gave a talk at the 09/2024 DevSummit in Dublin, Ireland. Future work includes: • More bug fixes and improvements. • Finalize and commit of audio(8) and mididump(1). • Implement a generic MIDI layer, similar to pcm/, and improve/modernize the MIDI codebase in general. • Implement a bluetooth device management utility. • More virtual_oss patches and improvements. • Attempt to implement an snd_hda(4) pin-patching mechanism. • Investigate SOF/DMIC support. You can also follow the development process in freebsd-multimedia@, where I post regular reports. Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ A bhyve management GUI written in Freepascal/Lazarus Links: Bhyvemgr URL: https://github.com/alonsobsd/bhyvemgr/ Contact: José Alonso Cárdenas Márquez Bhyvemgr is a bhyve management GUI written in Freepascal/Lazarus on FreeBSD. It needs a bunch of tools mostly installed by the base system and some installed from ports/packages. The main goal is to be a desktop application focus on desktop user to easily and quickly setup and run virtual machines on FreeBSD hosts. It should be used for virtual machines testing purpose (not for production). For a tool for production virtual machines management, take a look at sysutils/ vm-bhyve, sysutils/bmd, or sysutils/cbsd. Bhyvemgr supports aarch64 on 15-CURRENT only, and amd64 from FreeBSD 13.x to 15-CURRENT. It can be compiled from sysutils/bhyvemgr as a port, or installed as packages with gtk2, qt5, or qt6 interface support. People interested in helping the project are welcome. Version at the end of 2024Q3: 1.1.0 TODO • Test on real aarch64 hardware • Add uart device support • Add missing global setting entries (bios, board, chassis, system) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Changes to dhclient to speed up the FreeBSD boot process Links: Speeding up the FreeBSD boot process URL: https://wiki.freebsd.org/SummerOfCode2024Projects/SpeedingUpTheFreeBSDBootProcess dhclient Pull Request URL: https://github.com/freebsd/freebsd-src/pull/1368 Contact: Isaac Cilia Attard As part of my Google Summer of Code 2024 project, involving speeding up the FreeBSD boot process, I have worked on decreasing the time it takes for ARP resolution within dhclient to happen. This involved reducing the default ARP resolution timeout from 2000 ms to 250 ms, and adding an option to disable it altogether. The latter is useful within cloud environments, where a node is certain to have an IP address allotted to it. As a consequence of this, connecting to a DHCP network is now faster, including the boot process during which this happens. The speedup experienced is about 2 seconds. This causes FreeBSD systems to boot significantly faster than before. Sponsor: Google LLC (GSoC 2024) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Capsicum and Bhyve Code Audit Contact: Ed Maste Contact: Pierre Pronchery < pierre@freebsdfoundation.org> With the support of the Alpha-Omega project, the FreeBSD Foundation undertook code audits of two important subsystems — the bhyve hypervisor, and the Capsicum sandboxing framework. In addition to uncovering vulnerabilities in these systems to correct, the audits look to identify classes of vulnerabilities and/or suboptimal coding practices that we can look to address across the project. The Foundation interviewed several firms, and selected Synacktiv to perform the audit. A number of issues with critical and high severity were identified, which have been fixed as documented in security advisories: • FreeBSD-SA-24:09.libnv • FreeBSD-SA-24:10.bhyve • FreeBSD-SA-24:11.ctl • FreeBSD-SA-24:12.bhyve • FreeBSD-SA-24:14.umtx • FreeBSD-SA-24:15.bhyve • FreeBSD-SA-24:16.libnv Fixes are in progress for a number of lower-severity issues. The code audit report will be shared in the near future, after issues above a severity threshold have been addressed. The FreeBSD Foundation will also publish a report including commentary on the impact of the Synacktiv code audit report, classes of vulnerabilities identified, and lessons learned. More information is available in the Alpha-Omega repository. Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Endpoint-Independent NAT Contact: Tom Jones This project aims to add support for Endpoint-Independent Mappings for UDP to the pf and ipfw firewalls. End Point Independent NAT enables applications behind a NAT speaking to multiple remote hosts to receive the same mappings. This allows an application without any NAT traversal mechanisms to work around NAT issues to perform peer discovery. From the remote hosts perspective the NAT is transparent and it is as-if there is no NAT at all. This form of NAT has been given several names over the last few decades and might be known as 'full-cone' NAT. Patches to pf landed in early September based on work by Damjan Jovanovic and Naman Sood with updates to work on pf in main. The patches add a new 'endpoint-independent' suffix to UDP pf nat rules. ipfw support for endpoint-independent is going to be made available via libalias, allowing any system which uses libalias for address translation to benefit from the change. There is an in-progress review D46689 to add support to libalias. The in-progress change and the committed pf change could both benefit from testing in more and diverse environments. Sponsor: The FreeBSD Foundation Sponsor: Tailscale ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Kyua Jail Support Contact: Igor Ostapenko The FreeBSD test suite is executed by the kyua(1) utility. Kyua supports parallel execution of tests with kyua -v parallelism= test, however many network tests leverage jail(8) features like VNET(9) and have conflicts with jail naming and network configuration. As a result they are marked with the is_exclusive=true metadata property to prevent them from running at the same time and interfering with each other. It creates a dilemma when a project aims to increase test coverage, but the accumulation of exclusive tests proportionally increases the time required to run them. This, in turn, affects the development process from multiple angles. Kyua has recently got a change in 15-CURRENT to support a new concept called "execution environment". By default, tests run in the so-called "host" execution environment, where they are executed as before. A test can opt-in to use a brand new execution environment, the "jail" one. In this case, kyua creates a jail before running the test, and then executes the test within the jail. That opens up the opportunity to run more tests in parallel due to the extra isolation provided by the jail concept itself, and specifically by the VNET. It depends on hardware and configuration, but there are reports that having the same environment netpfil/pf tests can be run around 4 times faster — a few minutes instead of half an hour. The following Makefile change is a quick demo of how netpfil/pf tests were switched to run in parallel with jail execution environment: -# Tests reuse jail names and so cannot run in parallel. -TEST_METADATA+= is_exclusive=true +# Allow tests to run in parallel in their own jails +TEST_METADATA+= execenv="jail" +TEST_METADATA+= execenv_jail_params="vnet allow.raw_sockets" More details: • The key commit with detailed description: 257e70f1d5ee61037c8c59b116538d3b6b1427a2 • The man pages covering the "execenv" feature: kyuafile(5), kyua.conf(5) This change also brings new sysctl read-only variables, which expose more details about current jail, and may be generally useful: • security.jail.children.max: Maximum number of child jails • security.jail.children.cur: Current number of child jails A hint: the sysctl -n security.jail.children.cur run from prison0 provides the number of all jails in the system. Further improvements to Kyua, such as requirements definition and automatic resolution, are currently in the design phase. Potentially new metadata properties like required_klds and required_pkgs provide a clue to these topics. Please contact Igor to discuss ideas and use cases that can help shape these upcoming Kyua enhancements. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Linux Source Compatibility Wiki page Links: Linux Source Compatibility URL: https://wiki.freebsd.org/LinuxSourceCompatibility Contact: Edward Tomasz Napierala There is now a wiki page to track source compatibility differences between FreeBSD and Linux — and it needs your input! FreeBSD and Linux are already largely compatible at the source code level due to both being Unix systems and following the same standards. There are however certain system calls specific to Linux; there are also differences in header files, constants and so on. Implementing them in FreeBSD would make porting software easier. Not all of the items there are fixable. Some differences cannot be eliminated due to naming clashes, disagreements on how the system is supposed to work, or because it would make autoconf pick up a less functional compatibility API instead of the native one. In such cases we should document it and advise what API to use instead. The wiki page aims to provide an overview and help track progress. That is where your help is needed. I need people who actually port software to FreeBSD to add missing APIs, based on their experiences. This also includes non-syscall items, like missing headers and unsupported constants. Preferably also mention the name of the software that could use them. • Add missing items • Add prospective API consumers Sponsor: Innovate UK ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Userland Changes affecting the base system and programs in it. Service jails — Automatic jailing of rc.d services Links: rc-article part for Service Jails URL: https://docs.freebsd.org/en/articles/rc-scripting/#rcng-service-jails service jail patches for ports in our bugtracker URL: https://bugs.freebsd.org/bugzilla/buglist.cgi?quicksearch=service+jail+aware Contact: Alexander Leidinger Service jails extend the rc(8) system to allow automatic jailing of rc.d services. A service jail inherits the filesystem of the parent host or jail, but uses all other limits of the jail (process visibility, restricted network access, filesystem mounting permissions, sysvipc, …​) by default. Additional configuration allows inheritance of the IPs of the parent, sysvipc, memory page locking, and use of the bhyve virtual machine monitor (vmm(4)). Since the last report several ports have been modified to come with a service jail config. Out of about 1460 start scripts in the ports collection, about 80 start scripts are changed. Prominent examples out of those are postgresql, DNS servers, FTP servers, PHP, dovecot, postfix, rspamd, amavisd-new and clamav. Some more changes are waiting for a treatment by the corresponding port maintainers. Any help in changing more start scripts (most of the time just one line to add) is welcome. If you want to help, you can check the bugtracker link above for changes which are already under review. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Userspace UFS Driver (fuse-ufs) Links fuse-ufs GitHub URL: https://github.com/realchonk/fuse-ufs Contact: Benjamin Stürz During this year’s Summer of Code, I wrote a userspace UFS driver using FUSE and Rust. The project was meant to ease the process of mounting FreeBSD UFS filesystems on other operating systems. Up to this point, only read-only filesystem access has been implemented. But as a bonus, fuse-ufs has the ability to mount filesystems with endianness different from the host’s endianness. I am currently working on splitting the project into a binary and library part, to make it easier to integrate it into other operating systems. As part of this refactoring, an additional FUSE2 backend will be implemented, to be able to run it on OpenBSD. Currently there is testing infrastructure for Linux and FreeBSD with OpenBSD coming in the future. Although there is no CI for MacOS, a friend of mine tested it with MacFUSE and it works. Once the big refactor is done, I will start concentrating on implementing write support. Thanks to being bribed by Robert Clausecker, I will also add soft-updates and mounting Sun’s UFS in the future. The driver can be installed using cargo install fuse-ufs, or (if on Arch Linux) using your favorite AUR helper. Thanks to Robert Clausecker a port for FreeBSD exists in sysutils/fusefs-ufs. A big thanks to Alan Somers and Kirk McKusick for mentoring me and thanks to Robert Clausecker for the FreeBSD port and suggesting this GSoC project to me in the first place. Another thanks to Davids Paskevics for writing a fuzzer for me. Sponsor: Google Summer of Code 2024 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Kernel Updates to kernel subsystems/features, driver support, filesystems, and more. FreeBSD V4L2 & kernel USB Video Class driver Links: Public development repository URL: https://github.com/AlvinChen1028/freebsd-src/tree/feature-uvc Upstreaming preparation repository URL: https://github.com/lwhsu/freebsd-src/pull/2 Contact: Alvin Chen Contact: Li-Wen Hsu This work is to create FreeBSD UVC (USB Video Class) kernel driver and follow v4l2 APIs, so that most of the Linux camera applications can be easily ported to FreeBSD. The code is still cleaning up and will be submitted to official review after completing. Current Status: 1. The key functions of the UVC driver are enabled. 2. The key v4l2 IOCTLs are implemented. 3. Support most of USB cameras (up to 4K resolution): Jabra, Logitech, etc. 4. Some applications validated: VLC, Cheese, pwcview. Future Work: 1. A couple of v4l2 IOCTLs need be implemented: make all cases in v4l2-compliance test suite be passed. 2. Some UVC APIs need be implemented: uvc control mapping callbacks, etc. 3. UVC lock issue related to USB. 4. PCI based AI camera supporting. 5. Code refactoring if needed. Sponsor: Dell Technologies for the development Sponsor: The FreeBSD Foundation for assistance of upstreaming ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ mac_do(4), setcred(2), mdo(1) Contact: Olivier Certner Contact: Baptiste Daroussin This project aims at allowing controlled process credentials transitions without using setuid executables but instead leveraging our MAC framework. Traditional programs for credentials change have to execute preliminary operations as root (if not as the effective UID, at a minimum as the saved UID). Some of these programs (e.g., sudo(8)) have lots of lines of codes and comprise features (e.g., loadable security modules) that can be dangerous from a security standpoint. Thus, they have a non-negligible attack surface and are difficult to prove correct. Additionally, in most scenarios, the extra features they bring are not necessary. More generally, the threat model for the mac_do(4) kernel module part is that of compromised userland programs, be they credentials changers or credentials providers ones. This stance implies that calls to the kernel’s credentials-changing API must be monitored by the kernel without upcalls to userland. In practice, mac_do(4) must be configured beforehand by the administrator to indicate which transitions of credentials are valid (through a sysctl(8) knob, security.mac.do.rules). Currently, the companion userland program, mdo(1), is the only one that can be authorized to proceed by mac_do(4) (for now, based on the executable path). This tiny program simply establishes the new credentials via calls to setuid(2) , and optionally initgroups(3) (calling setgroups(2)) and setgid(2) (if -i was not passed). The resulting set of groups is either that of the target UID based on the password database, or that before the change in UID (when using -i). The second alternative can be a security hazard in some cases (as the effective GID is not changed either), whereas the first contradicts the threat model above. The current mac_do(4) rules specification indeed only allows to express simple UID transitions towards explicit UIDs from other explicit UIDs or GIDs, without taking into account groups. Consequently, the kernel module currently cannot check the content of setgroups(2) and setgid(2) system calls' parameters, relying completely on mdo(1) passing the right information. A new version of mac_do(4) has been in the works for approximately a month. Besides fixing concurrency, per-jail settings and MAC policies composition problems, it features a revamp of the rules specification in order to make it possible to finely control which groups are allowed in the resulting credentials. Notably, primary and secondary groups can now be specified independently, and for the latter, GIDs can be tagged as allowed, mandatory or forbidden. A special alias, ., can be used to indicate the current process' UIDs or GIDs depending on the context. These new features imply that the mac_do(4) module is able to apply credentials change at once, since the allowed final credentials depend on the initial ones through the configured rules. The traditional userland interface (e.g., setuid (2), setuid(2), setgroups(2), etc.) is at odds with this requirement as it necessitates multiple calls to reach the desired final credentials, making the process pass by several successive states that themselves may not be allowed by mac_do(4)'s rules. We overcome this limitation by introducing a new system call, setcred(2), which allows to request arbitrary transitions of credentials at once. Beside its usefulness in conjunction with mac_do(4), it has the benefit of simplifying coding of credentials change in userland. Since it is also extensible, it may have the potential to be adopted later by other systems. Pre-requisite changes are currently under review (see in particular revisions D46886 to D46889 and D46896 to D46923). The bulk of changes in mac_do(4)/mdo(1) proper will soon be pushed under review as well. An older version of the full series can be seen on GitHub. Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Scheduling Priorities: 256-queue Runqueues Sub-Project Contact: Olivier Certner The goal of the 256-queue runqueues sub-project is to fix FreeBSD’s POSIX compliance in that different priority levels in the SCHED_FIFO or SCHED_RR scheduling classes must lead to immediate preemption by threads having higher priority. It is part of the bigger scheduling priorities revamp project aiming at rationalizing FreeBSD scheduling interfaces, including having consistent rtprio(2) and POSIX interface behaviors (where it makes sense), enhancing POSIX compliance, removing duplicate code and fixing existing bugs, and enhancing the non-standard parts both for better control and security. Expected benefits are increased usage of FreeBSD as a soft real-time platform, e.g., for video and audio processing in casual desktop uses to professional settings. Readers interested in this topic are invited to consult AsiaBSDCon 2024’s paper and EuroBSDCon 2024’s slides for a wider view, and to contact me for questions, feedbacks or discussions. Currently, priority levels specified either through the prio field of struct rtprio (rtprio(2) interface) or the sched_priority one of struct sched_param, for real-time scheduling classes (RTP_PRIO_FIFO and RTP_PRIO_REALTIME for the former, SCHED_FIFO and SCHED_RR for the latter) as well as idle-time ones (RTP_PRIO_IDLE), are conflated as follows: Each priority level that has the same quotient when divided by 4 is internally treated the same. In particular, threads being in the same such equivalence class but having higher priority will not preempt other threads in the same class, violating POSIX expectations for SCHED_FIFO and SCHED_RR. To remedy this situation, we have chosen an impacting internal change on the number of queues per runqueue, and defer to the above-mentioned EuroBSDCon 2024’s slides for more details. The switch to 256-queue runqueues having non-trivial impacts on the ULE scheduler, we have been analyzing it and tuning the scheduler to preserve its previous behavior with respect to anti-starvation and the effect of nice values. With the goal to perform further testing, we have revived Jeff Roberson’s initial ULE’s test tool, called late (currently available on GitHub ). All the modifications made as part of this sub-project are currently under review, starting with Phabricator’s review D45387 (click on the "Stack" tab to see the full series of reviews). In the course of this project, we have noticed that the effect of nice values is especially weak, and consequently have produced experimental patches to make their effect stronger. However, it is not clear at this point whether we can increase their effect satisfactorily enough in the current ULE setting. We have also started another scheduler project about adapting ULE to hybrid architectures, which might also trigger more drastic scheduler changes. Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Wireless Update Links: Categorised Wireless Problem Reports URL: https://bugs.freebsd.org/bugzilla/showdependencytree.cgi?id=277512&hide_resolved=0 Contact: Bjoern A. Zeeb Contact: The FreeBSD wireless mailing list The ongoing wireless efforts are trying to bring more support for recent chipsets as well as newer standards. With iwlwifi(4) and rtw88(4) being supported we received patches and initial reports for rtw89 and ath10k working for some people. Additionally ath11k, ath12k and various chipsets supported by mt76 are waiting for someone to find the time to finish compat code, test and debug. Work is ongoing to update drivers to Linux v6.11 using the now bootstrapped vendor branches, which should help maintenance a lot in the future. One particular focus for this update is also to find ways to minimize incompatibilities between wireless compat code versions in order to support multiple Linux versions as needed. After the native kern_malloc changes got committed, LinuxKPI is seeing ongoing work for memory allocation to play better by the rules set out in Linux which should help with DMA problems seen. There is further work pending to add missing bus_dmamap_sync() calls. There is work to support rtw88(4) SDIO devices (being tested on an r2s-plus) and ongoing work to stabilize updated USB support which should start landing once the driver updates have finished. Lastly there are more updates in the queue to finish 11n support for LinuxKPI 802.11 compat code as well as improving native net80211 code. If you have questions or feedback please use the freebsd-wireless mailing list. That way everyone will see, be able to join in, and the answers will be publicly archived. Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ VirtIO Sockets and AF_VSOCK support Links: Source code URL: https://github.com/daniloegea/freebsd-src/tree/virtio_vsocks Contact: Danilo Egea Gondolfo The VirtIO Socket device is used to enable communication between guests and host without networking. The AF_VSOCK protocol family enables it to be used through the sockets API. For the past many months I have been working on a guest driver for the VirtIO Socket device and an implementation of the AF_VSOCK protocol family. Originally, I wanted to get the lxd-agent daemon working on FreeBSD but the communication with the LXD host daemon is done through VSOCKs. LXD is a nice container and virtual machine manager based on Linux/KVM and my end goal is to make FreeBSD a LXD first-class citizen. At the moment I have it working well enough to enable the lxd-agent to work. I adapted the golang.org/x/sys library and the lxd-agent to support AF_VSOCK on FreeBSD. Features such as command execution, interactive consoles and file transfer are working. On Linux, AF_VSOCK can be used with VirtIO, HyperV and VMware sockets as transports. I am trying to design my implementation so it will also be possible to use it with different transports in the future. After getting the current work in a good shape, ideas for future work include integration of AF_VSOCK and HyperV Sockets (which is already supported on FreeBSD through AF_HYPERV), VIRTIO_VSOCK_F_SEQPACKET, VirtIO Socket device for bhyve and the host side of the driver. I will continue to slowly work on this on my limited free time and hopefully have something more concrete for the next time. There is still a lot of work to be done until it become ready for code review. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Architectures Updating platform-specific features and bringing in support for new hardware platforms. Pinephone Pro Support Links: Repository on Codeberg URL: https://codeberg.org/Honeyguide/freebsd-pinephonepro Contact: Toby Kurien A new project trying to make FreeBSD usable on the Pinephone Pro has been started during August. The current FreeBSD RELEASE images already boot on a Pinephone Pro, but no screen output or other devices are supported. The aim is to step by step support additional components so that the device one day might be usable as a highly mobile FreeBSD device. Over the last few weeks, the groundwork has been implemented like getting used to the device, cross-compiling and booting a 15.0-CURRENT custom kernel as well as toggling the LEDs (red/green/blue in the front). Also, the LCD backlight can be turned on already and the USB-C hub is enabled even though it is not yet functional due to missing power management support. The next step is to write a driver for the RK818 power management chip. Without it, most of the hardware will not power on like the USB-C port above. This will be done by trying to modify the existing RK808 driver. RK818 support should then make it possible to access a lot more of the devices, e.g. allowing to enable the screen, USB peripherals or WiFi. Additional feedback and testers are welcome. Sponsor: Honeyguide Group ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ SIMD enhancements for aarch64 Links: EuroBSDCon 2024 presentation URL: https://www.youtube.com/live/OzX38cWdivc?si=VsMrEmT_IdKpjv7W&t=22070 Slides from presentation (PDF) URL: http://fuz.su/~fuz/talks/eurobsdcon-str-talk.pdf Google Summer of Code (GSoC) project description URL: https://summerofcode.withgoogle.com/programs/2024/projects/TKRS35FA simd(7) URL: https://man.freebsd.org/cgi/man.cgi?query=simd&sektion=7&manpath=FreeBSD+15.0-CURRENT Contact: Getz Mikalsen The porting effort of the SIMD enhanced libc string functions from amd64 to aarch64 has been successfully completed. There are now optimized implementations for 16 libc string functions in addition to those with implementations already available as part of the ARM optimized subroutines library. There is also a presentation regarding the general method for these methods from EuroBSDCon 2024 available on YouTube with a short description in the end of how the porting has been done with regards to the aarch64 architecture. These enhancements significantly improve performance of string functions for all FreeBSD systems on the aarch64 platform. The code is currently undergoing acceptance testing in the form of an exp-run building all the ports, once without and once with the patch set applied to see if it has caused any new failures. Sponsor: Google LLC (GSoC 2024) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Cloud Updating cloud-specific features and bringing in support for new cloud platforms. FreeBSD on Microsoft HyperV and Azure Links: Microsoft Azure article on FreeBSD wiki URL: https://wiki.freebsd.org/MicrosoftAzure Microsoft HyperV article on FreeBSD wiki URL: https://wiki.freebsd.org/HyperV Contact: Microsoft FreeBSD Integration Services Team Contact: freebsd-cloud Mailing List Contact: The FreeBSD Azure Release Engineering Team Contact: Wei Hu Contact: Souradeep Chakrabarti Contact: Colin Su Contact: Li-Wen Hsu In this quarter, we have published the 13.4-RELEASE on Azure Marketplace. Souradeep Chakrabarti from Microsoft has added a feature to use hypercalls for TLB shootdown on Hyper-V and Azure. Micro-benchmark shows 30-40% performance improvement on TLB shootdown. This has been presented at the DevSummit 202409 Wei Hu root-caused an issue on missing CDROM device when booting FreeBSD on the latest Azure v6 VM SKU. V6 type only offers NVMe disks to guest OS. He also continues bug fixing for FreeBSD MANA NIC device. Work in progress tasks: • Automating the image publishing process and merging to src/release/. (Li-Wen Hsu) • Colin Su is testing adding FreeBSD support in Azure Pipelines □ https://github.com/microsoft/azure-pipelines-agent/pull/3266 □ Building and publishing snapshot builds to Azure community gallery. Open tasks: • Update FreeBSD-related doc at Microsoft Learn • Update sysutils/azure-agent to the latest version • Upstream local modifications of Azure agent • Port Linux Virtual Machine Extensions for Azure Sponsor: Microsoft for people in Microsoft, and for resources for the rest Sponsor: The FreeBSD Foundation for everything else ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FreeBSD on EC2 Contact: Colin Percival FreeBSD is available on both amd64 (Intel and AMD) and arm64 (Graviton) EC2 instances. In the past quarter, a new "small" flavour of EC2 AMI has been added, without debug symbols, tests, 32-bit compatibility libraries, or the LLVM debugger, and without the Amazon SSM Agent pre-installed or the AWS CLI installed by default at first boot. Build performance tests are now being performed weekly using the snapshot AMIs built by the release engineering team. These tests revealed several performance regressions which have now been fixed; in particular a bug fix to the use of the EFI RNG in the boot loader produced a dramatic speedup on Graviton instances. Sponsor: Amazon Sponsor: https://www.patreon.com/cperciva ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ OpenStack on FreeBSD Links: OpenStack URL: https://www.openstack.org/ OpenStack on FreeBSD URL: https://github.com/openstack-on-freebsd Contact: Chih-Hsin Chang Contact: Li-Wen Hsu The OpenStack on FreeBSD project aims to bring OpenStack cloud infrastructure to the FreeBSD operating system, using FreeBSD’s special features while keeping it compatible with OpenStack. In the third quarter of 2024, we continued working on several important tasks. Our work on porting OpenStack Ironic is still ongoing, with tests now running on arm64 servers. In this setup, the service node is amd64, and the provisioning node is arm64. This helps us explore more options for running mixed environments in OpenStack on FreeBSD. In August, we gave a presentation at COSCUP 2024 to share the project’s progress and our experiences. This helped us get more attention and interest from people in the community. We also updated some of the OpenStack components, like Keystone, Glance, and Placement, from FreeBSD 14.0-STABLE to FreeBSD 15.0-CURRENT. This update helps us keep up with the latest changes in FreeBSD, making the project run better. Another notable item was testing the bhyve serial console over TCP patch and using it in the OpenStack workflow. This brings us closer to stopping the use of the custom socat-manager solution and moving to a built-in serial console solution. Although we are still planning to turn the OpenStack manual installation process into FreeBSD ports, there has not been much progress yet. We hope to work more on this in the next few months. Existing work can be found in the openstack repository. Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Documentation Noteworthy changes in the documentation tree, manual pages, or new external books/documents. Documentation Engineering Team Link: FreeBSD Documentation Project URL: https://www.freebsd.org/docproj/ Link: FreeBSD Documentation Project Primer for New Contributors URL: https://docs.freebsd.org/en/books/fdp-primer/ Link: Documentation Engineering Team URL: https://www.freebsd.org/administration/#t-doceng Contact: FreeBSD Doceng Team The doceng@ team is a body to handle some of the meta-project issues associated with the FreeBSD Documentation Project; for more information, see FreeBSD Doceng Team Charter. Benedict Reuschling steps down from doceng@. doceng@ would like to thank bcr@ for his service. Document changes • Handbook: Document the automatic creation of XDG directories starting with FreeBSD 14.1. The VNET config example script has been fixed. • Architecture Handbook: remove K&R prototypes in MAC chapter. • Website: Some improvements regarding the top banner and layout, visually rearrange buttons and more. • Documentation repository: fix of all malformed tables warnings. Removal of deprecated attributes to conform to new gohugo releases. FreeBSD Translations on Weblate Link: Translate FreeBSD on Weblate URL: https://wiki.freebsd.org/Doc/Translation/Weblate Link: FreeBSD Weblate Instance URL: https://translate-dev.freebsd.org/ Q3 2024 Status • 17 team languages • 214 registered users 1 new translator joined Weblate: • matthew (id) Languages • Chinese (Simplified) (zh-cn) (progress: 7%) • Chinese (Traditional) (zh-tw) (progress: 3%) • Dutch (nl) (progress: 1%) • French (fr) (progress: 1%) • German (de) (progress: 1%) • Greek (el) (progress: 1%) • Indonesian (id) (progress: 1%) • Italian (it) (progress: 5%) • Korean (ko) (progress: 32%) • Norwegian (nb-no) (progress: 1%) • Persian (fa-ir) (progress: 3%) • Polish (progress: 2%) • Portuguese (progress: 0%) • Portuguese (pt-br) (progress: 24%) • Spanish (es) (progress: 36%) • Turkish (tr) (progress: 2%) We want to thank everyone that contributed, translating or reviewing documents. And please, help promote this effort on your local user group, we always need more volunteers. Packages maintained by DocEng During this quarter the following work was done in packages maintained by doceng@: • textproc/docproj: Bump gohugo dependency to 0.133.1 • www/gohugo: update to 0.134.3 Open issues There are 2 Open PRs in bugzilla assigned to doceng@: • 276923 www/gohugo link error under poudriere • 267274 Please remove the zh-CN Handbook of the current FreeBSD website During this quarter doceng@ closed 3 PRs: • 266107 FreeBSD Handbook and other books: PDF: broken links – crossref • 279815 status reports: ERR_TOO_MANY_REDIRECTS • 281396 handbook: ERROR: : line 149: dropping cells from incomplete row detected ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FreeBSD Wiki Links: FreeBSD wiki front page URL: https://wiki.freebsd.org/FrontPage Contact: Mark Linimon Contact: Wiki admin < wiki-admin@freebsd.org> The FreeBSD wiki is a repository of information that does not fit well in the official project documentation because it is too specific, too disparate, or too transient. Current projects: Mark Linimon has started attacking various stale pages. The focus has been on pages that we show to new, interested, users. (Recent Foundation newsletters refer to some of these pages directly.) Unfortunately, many of these pages have become stale, to the point where they were actually not good recommendations. The pages that have received the most work are: • IdeasPage (referenced in Foundation documentation) • JuniorJobs (referenced in Foundation documentation) • SummerOfCodeIdeas • various pages under CategoryProject • various pages under CategoryTodo • MentorMatch In addition to removing obviously stale entries, all entries have now been datestamped with the time that they were added to the various pages. wiki-admin@ would like to request that we carry forward this tradition into the future. As well, wiki-admin@ has been sending email to ask committers/contributors to the above pages "should we keep this entry?" This task will continue until the pages have been cleaned up. (NB: the fact that content in the wiki was stale was mentioned by numerous respondents in the FreeBSD Foundation 2024 Community Survey Report.) Previous plans that have stalled Plans are still underway to familiarize our audience on Discord with the wiki (there are too many "silos" in our FreeBSD community). The team has simply not had enough cycles to do this. However, contact Setesh on the FreeBSD Discord for more information. Preliminary work was being done on updating the wiki software itself. Earlier, we were looking at switching implementations because MoinMoin development seemed to have stalled, leaving us with an unwanted hanging python2 dependency. However, MoinMoin now claims that they are nearing a 2.0 release. We have not yet tried an install of their latest beta version to test compatibility. Testers welcome. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ The FreeBSD Russian Documentation Project Links: FAQ URL: https://docs.freebsd.org/ru/books/faq/ Handbook URL: https://docs.freebsd.org/ru/books/handbook/ Web URL: https://www.freebsd.org/ru/ Contact: Andrei Zakhvatov The FreeBSD Russian Documentation Project’s current goal is to provide up-to-date Russian translations of the most important parts of FreeBSD documentation (FAQ, Handbook, Web). It is important to support Russian speakers with high-quality official technical materials and increase acceptance of the operating system around the globe. We hope that this activity will receive some support from the Russian-speaking FreeBSD community and lead to more translated materials. There is some progress in document translation: • FAQ: PR #277008 and PR #282062 • Handbook: Chapter 1. Introduction: PR #276334 • Handbook: Chapter 2. Installing FreeBSD: PR #280610 • Handbook: Chapter 3. FreeBSD Basics: PR #282059 Check the official translation guide if you are willing to help. We always appreciate your help with translation of the following materials: • Handbook chapters and sections • Articles • Web pages ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Ports Changes affecting the Ports Collection, whether sweeping changes that touch most of the tree, or individual ports themselves. GCC on FreeBSD Links: GCC Project URL: https://gcc.gnu.org/ GCC 11 release series URL: https://gcc.gnu.org/gcc-11/ GCC 12 release series URL: https://gcc.gnu.org/gcc-12/ GCC 13 release series URL: https://gcc.gnu.org/gcc-13/ GCC 14 release series URL: https://gcc.gnu.org/gcc-14/ Contact: Lorenzo Salvadore This quarter the main news is about the new GCC releases: • lang/gcc11 has been updated to 11.5.0, which is the last GCC 11 planned released; • lang/gcc12 has been updated to 12.4.0; • lang/gcc13 has been updated to 13.3.0; • lang/gcc14 has been updated to 14.2.0. The exp-run to update GCC default version from 13 to 14 has started. As usual, thanks to everyone involved. If you maintain any of the affected ports or want to give a hand preparing and testing some patches, please consider trying adding -fpermissive to CFLAGS in affected ports: GCC 14 has transformed some warnings into errors, which is the cause of many of the failed builds. The -fpermissive flag switches those errors back to warnings. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Freepascal and Lazarus on FreeBSD aarch64 Links: Freepascal Project URL: https://www.freepascal.org/ Lazarus IDE URL: https://www.lazarus-ide.org/ Contact: José Alonso Cárdenas Márquez Free Pascal is a mature, versatile, open source Pascal compiler. It can target many operating systems and processor architectures: Intel x86 (16 and 32 bit), AMD64/x86-64, PowerPC, PowerPC64, SPARC, SPARC64, ARM, AArch64, MIPS, Motorola 68k, AVR, and the JVM. Additionally, support for RISC-V (32/64), Xtensa, and Z80 architectures, and for the LLVM compiler infrastructure is available in the development version. Also, the Free Pascal team maintains a transpiler for pascal to Javascript called pas2js. Lazarus is a Delphi compatible cross-platform IDE for Rapid Application Development. It has a variety of components ready for use and a graphical form designer to easily create complex graphical user interfaces. Three years ago, Mikaël Urankar began porting the Free Pascal compiler to FreeBSD aarch64 and it was merged into Free Pascal source code (main branch). Some months ago, I added lang/fpc-devel (3.3.1) and editors /lazarus-devel (3.99) to the ports tree only for i386 and amd64 because aarch64 was not ready yet. The binaries generated on aarch64 did not run because of ELF issues. Finally, some days ago the issues were resolved and support for FreeBSD aarch64 was completed. lang/fpc-devel and editors/lazarus-devel were updated to 3.3.1.20240913 and 3.99.20240913 with support for aarch64 respectively. It brings to FreeBSD users a new language and platform working on FreeBSD aarch64 for console, graphic, or any kind of apps development. TODO • Update fpc/lazarus based ports (such as sysutils/bhyvemgr and archivers/ peazip) to support FreeBSD/aarch64 • Push FreeBSD RISC-V support ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Third Party Projects Many projects build upon FreeBSD or incorporate components of FreeBSD into their project. As these projects may be of interest to the broader FreeBSD community, we sometimes include brief updates submitted by these projects in our quarterly report. The FreeBSD project makes no representation as to the accuracy or veracity of any claims in these submissions. Containers and FreeBSD: Pot, Potluck and Potman Links: Pot organization on GitHub URL: https://github.com/bsdpot Contact: Luca Pizzamiglio (Pot) Contact: Bretton Vine (Potluck) Contact: Michael Gmelin (Potman) Pot is a jail management tool that also supports orchestration through Nomad. Potluck aims to be to FreeBSD and Pot (and potentially one day also Podman) what Dockerhub is to Linux and Docker: a repository of container descriptions and complete container images for usage with Pot and in many cases Nomad. During this quarter, there were two bugfixes to Pot that will be released soon. Potluck images saw some updates again. All images have been rebuilt again to include the latest fixes and quarterly packages. Additionally, some images like Loki or Vault have also received additional updates and bugfixes. Also, we have done some research regarding potential future support of OCI, Buildah and Podman images in Potluck. Two blog posts, one describing a basic Buildah and Podman setup and one describing how to orchestrate Podman containers with Nomad and Consul have been published. As always, feedback and patches are welcome. Sponsors: Nikulipe UAB, Honeyguide Group From nobody Thu Nov 7 19:43: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 4Xksvh0swVz5cTFl for ; Thu, 07 Nov 2024 19:44:00 +0000 (UTC) (envelope-from shuriku@shurik.kiev.ua) Received: from mail.flex-it.com.ua (mail.flex-it.com.ua [193.239.74.7]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Xksvg18V1z4k6M for ; Thu, 7 Nov 2024 19:43:59 +0000 (UTC) (envelope-from shuriku@shurik.kiev.ua) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of shuriku@shurik.kiev.ua designates 193.239.74.7 as permitted sender) smtp.mailfrom=shuriku@shurik.kiev.ua; dmarc=none Received: from 93.183.208.50.ipv4.datagroup.ua ([93.183.208.50] helo=[192.168.200.135]) by mail.flex-it.com.ua with esmtpsa (TLS1.3) tls TLS_AES_128_GCM_SHA256 (Exim 4.98 (FreeBSD)) (envelope-from ) id 1t98Q3-00000000MY3-1InD for freebsd-current@FreeBSD.org; Thu, 07 Nov 2024 21:43:51 +0200 Message-ID: <95a67972-ea73-4821-bbec-3c8857b1f2f4@shurik.kiev.ua> Date: Thu, 7 Nov 2024 21:43:50 +0200 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: FreeBSD Current From: Oleksandr Kryvulia Subject: panic after a97f683fe3c425 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ACL-Warn: SPF failed. 93.183.208.50 is not allowed to send mail from shurik.kiev.ua. X-Spamd-Result: default: False [-2.96 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.67)[-0.667]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:35297, ipnet:193.239.72.0/22, country:UA]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_ALL(0.00)[]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@FreeBSD.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DMARC_NA(0.00)[shurik.kiev.ua]; TO_DN_ALL(0.00)[]; ARC_NA(0.00)[] X-Rspamd-Queue-Id: 4Xksvg18V1z4k6M X-Spamd-Bar: -- Hi, @current My laptop now panics while boot with [1]. git bisect shows a97f683fe3c425b425cf8cc466319f54ea957c20 as offending commit. [1] https://imgur.com/a/Pb6eakW From nobody Thu Nov 7 19:59:18 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 4XktFc53txz5cVlp for ; Thu, 07 Nov 2024 19:59:32 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [IPv6:2607:f8b0:4864:20::102c]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4XktFb5VNYz4lpf for ; Thu, 7 Nov 2024 19:59:31 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20230601.gappssmtp.com header.s=20230601 header.b=AhJxmeNU; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::102c) smtp.mailfrom=wlosh@bsdimp.com; dmarc=none Received: by mail-pj1-x102c.google.com with SMTP id 98e67ed59e1d1-2e2ad9825a7so1080899a91.0 for ; Thu, 07 Nov 2024 11:59:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1731009570; x=1731614370; 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=IZLY9v1plm78WYOTtBitTbNHqCwNiRO/EPAeV9uHWlM=; b=AhJxmeNUPdWTY3x1dplcBirbJAxLr1lit7XFf/A/R3z6Vm1JCc5F3Wso0m1JmwBfSM GFC28xo2pzFScDEWoSzlfcKW4avtodVfpzaWJ4Z4HkMuKIn2K6v3ODv+s1BgaisolSdh oQFkGOludBGrk1xV6KL0RPGX9o9kv4KhYCTt9NnquMVgbHecgPeqvkQl8SkHiCIDSWWb nx7BgiYea+R2nYrEGO1VUnXFhoikVYAd6zBVB7yZLymceiBkTVee1KK1Y97FjeNqd9Lb 55bnS939zX9GT7LmDFRUJshAW0U4sLM1RhyuXdEtW1XC1PhsjLyh7qL8SpXcfaELZImj auIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731009570; x=1731614370; 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=IZLY9v1plm78WYOTtBitTbNHqCwNiRO/EPAeV9uHWlM=; b=JQGRTdV4AiduYk2m/2PqhcD6e9Fj/szYymJju8p/xn/DzyM7uuc9h+7hLZZ2zaPgzA zOidHvo/Zr+ip8ithxTpFa8z1h1W4zBAZRIQxLUls/jd1NFXujZ7maI6ky3EZ3F40Nqy /A9QBBvlt3+kTQCKv15/5gWUYZyPGn2oTQV9pOlDXIVPmDPrMpxYbU/FKCRhmhVLTZNh bBT420E4hz0HSbzkrBhm863iiYBl7MByshTOaC/R1VC1GLnE6F7ZoHbmrMMUaEF9gzbg JxlHvAXrLbcNDW7RHWONDaJKqM07WIQ3KmDOF8erAYtXt09RvGE6p4FIv9e7Jc9eUwSD 5E0A== X-Gm-Message-State: AOJu0Yw6Rt2eyb+fZAPvfghK81XfGZMa0Tg34YqNjyiesPUZQqxIjtHB 82XzId7tNxXDgW1UGr0fLPy2S8fT8K8ic6FYXsXmM6wNiIpc9FEn8kHIOFtbZc+WjaRfPCD3yoC Isj6kpWexP2R7EIHOzW+GqAYHGO6qRdmIDUvAFNlgmSk1PVSjmMrJLQ== X-Google-Smtp-Source: AGHT+IEOEe5iA38hTfGp6namvvG0S1KYzH+qd25ctyJJeImKdP2ofCVnQJU3cFUwJ6AR2rmV+pRzMuNXUbiUhshLVag= X-Received: by 2002:a17:90b:4acb:b0:2e2:af53:9326 with SMTP id 98e67ed59e1d1-2e9b177fc76mr568931a91.30.1731009570229; Thu, 07 Nov 2024 11:59:30 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: <8cf9adb0e7ca6340460c695ffd64a0df@Leidinger.net> <896b9ce404ffcb126dcdd6008583b117@Leidinger.net> In-Reply-To: From: Warner Losh Date: Thu, 7 Nov 2024 11:59:18 -0800 Message-ID: Subject: Re: No valid device tree blob found! To: Alexander Leidinger Cc: Current FreeBSD Content-Type: multipart/alternative; boundary="000000000000897232062658128b" X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20230601.gappssmtp.com:s=20230601]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_ONE(0.00)[1]; R_SPF_NA(0.00)[no SPF record]; SUBJECT_ENDS_EXCLAIM(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MISSING_XM_UA(0.00)[]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[bsdimp.com]; RCPT_COUNT_TWO(0.00)[2]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::102c:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; DKIM_TRACE(0.00)[bsdimp-com.20230601.gappssmtp.com:+] X-Rspamd-Queue-Id: 4XktFb5VNYz4lpf X-Spamd-Bar: -- --000000000000897232062658128b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Nov 6, 2024 at 3:41=E2=80=AFAM Alexander Leidinger wrote: > Am 2024-11-02 17:08, schrieb Warner Losh: > > > > On Sat, Nov 2, 2024, 10:03=E2=80=AFAM Alexander Leidinger > wrote: > > Am 2024-10-30 22:11, schrieb Alexander Leidinger: > > > WARNING! Trying to fire up the kernel, but no device tree blob found! > > For anyone interested, I opened > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D282493 for this. > > > Yea. This is a hang or a bad console. The warning is lame and misleading. > > Can you bisect? > > Found it. > > # git bisect bad > c87b3f0006be9ac5813f1ff636f18c9b4a41b08e is the first bad commit > commit c87b3f0006be9ac5813f1ff636f18c9b4a41b08e (HEAD) > Author: Warner Losh > Date: Mon Oct 14 15:58:10 2024 -0600 > > uart: uart_getenv: check for NULL class last, not first > > This allows one to specify dt:XXXX when the default class isn't > compiled > into the kernel. It's not an error to not have a class until we're do= ne > parsing the spec, so defer checking until then. > > Sponsored by: Netflix > Reviewed by: adrian, andrew, markj > Differential Revision: https://reviews.freebsd.org/D47078 > > sys/dev/uart/uart_subr.c | 14 +++++++------- > 1 file changed, 7 insertions(+), 7 deletions(-) > > -current as of today without this change boots just fine on the Ampere > system in the Oracle cloud. > what's your loader.conf? this should only matter if something is set there... Warner --000000000000897232062658128b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Nov 6, 2024 at 3:41=E2=80=AFA= M Alexander Leidinger <Alexan= der@leidinger.net> wrote:

Am 2024-11-02 17:08, schrieb War= ner Losh:



On Sat, Nov 2, 2024, 10:03=E2=80=AFAM Alexander Leidinger = <Alexander@leidinger.net> wrote:
Am 2024-10-30 22:11, schrieb Alexander Leidinge= r:

> WARNING! Trying to fire up the kernel, but no device tree bl= ob found!

For anyone interested, I opened
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D282= 493 for this.
=C2=A0
Yea. This is a hang or a bad console. The warning is lame= and misleading.
=C2=A0
Can you bisect?

Found it.

# git bisect bad
c87b3f0006be9ac5813f1ff6= 36f18c9b4a41b08e is the first bad commit
commit c87b3f0006be9ac5813f1ff6= 36f18c9b4a41b08e (HEAD)
Author: Warner Losh <imp@FreeBSD.org>
D= ate: =C2=A0 Mon Oct 14 15:58:10 2024 -0600

=C2=A0 =C2=A0 uart: uart_getenv: check for N= ULL class last, not first

=C2=A0 =C2=A0 This allows one to specify dt:= XXXX when the default class isn't compiled
=C2=A0 =C2=A0 into the ke= rnel. It's not an error to not have a class until we're done
=C2= =A0 =C2=A0 parsing the spec, so defer checking until then.

=C2=A0 =C2=A0 Sponsored by: =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Netflix
=C2=A0 =C2=A0 Reviewed by: =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0adrian, andrew, markj
=C2=A0 =C2=A0 Different= ial Revision: =C2=A0https://reviews.freebsd.org/D47078

=C2=A0sys/dev/uart/uart_subr.c | 14 +++++++-= ------
=C2=A01 file changed, 7 insertions(+), 7 deletions(-)

-current as of today without this change boots just fine on the Ampere s= ystem in the Oracle cloud.


= what's your loader.conf? this should only matter if something is set th= ere...=C2=A0=C2=A0

Warner=C2=A0
--000000000000897232062658128b-- From nobody Thu Nov 7 20:03: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 4XktLY3dXJz5cWZ0 for ; Thu, 07 Nov 2024 20:03:49 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com [IPv6:2607:f8b0:4864:20::22b]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4XktLX3qXWz4pjY for ; Thu, 7 Nov 2024 20:03:48 +0000 (UTC) (envelope-from markjdb@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-oi1-x22b.google.com with SMTP id 5614622812f47-3e5fa17a79dso967599b6e.1 for ; Thu, 07 Nov 2024 12:03:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1731009827; x=1731614627; darn=freebsd.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:from:to:cc:subject:date:message-id :reply-to; bh=mxr9tDZI9cfx4k84fCIvhQgthtrwVIm9XYF+qxFw94g=; b=b90TTXC3zdS4uDgrCFfGTMjgskaBMrI+vvF9yzVDoDuEDcH3w8iOplHua69Cxi9u3j V5m5/IuOc7pegiVLJ5zfLX4/hfV3LSPuYzzlI2Pe15fGJK0C2cIkPMJpMqUJgAV4Nd3j aCShfXrfuduiyaXLWSHEyGoMDJpQRBDQXA/Y/Sp4boSR12xtJ+E9o7S171wYCer5taCh OQjZLxI3L67xAOx8xK9Vd1r6PW5BcbCGc1QVGNmvVSTsTDlx9B55hF6GEWWKAiNNNyzD Z0bbyexPrs9dwPfhB2GKmD8oCrPyaZKpmiDcIZ2IOv81CTseeguE8ZJs8ibq9TIJSNO3 Kaaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731009827; x=1731614627; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=mxr9tDZI9cfx4k84fCIvhQgthtrwVIm9XYF+qxFw94g=; b=HDQ4X5ty7hUD9v6/7nLlLfx3hmlx/vGomBd39aRv+YlPEpFyPPDsAEfV8AbD5fT6kU 0mJVSXBrP30H7UJPEm/lIWnxpaQzdvYy6nnb5JqhgMeRdOmz5ha9U9kqB9Vzf74fIrjl ncYeRnoCdMIk7y6BnR4HEZdP/MZiFs3CR+9naJXCxKaQehEJ2ZneVg0n9MMhbDxOIbm5 mf9i5Mn+zKzfx/Bbqg2Wh1kg1pYGN9cEXS68mTCxri0tvIMU5o0i9oXd1GBuy4u0GHhM NlpueM4HdS69cHKU9HHHruomFgHLDCeXna+LjyHv7DohX6xO/PUDHHULAoNYi4fEpiOt VIeQ== X-Gm-Message-State: AOJu0YzkrlJtYaVBf8sBmWVWatBevDbiiZs/eLg9C2GQyUUnIFLbbIyF 3MZar4DbbtQTo0EcGvH69h8o9uwnYz7V8ILtuZ1RE8VqAIuY1stcwlaWMQ== X-Google-Smtp-Source: AGHT+IE4LHzW96TeF+KzZvyV0eF+8Vn4Hxu1sKV27QGUjJjizYb3cPZuKYTk29QcuI1M99soTqty3g== X-Received: by 2002:a05:6808:15a8:b0:3e5:f534:ddc4 with SMTP id 5614622812f47-3e79458571fmr564819b6e.13.1731009827426; Thu, 07 Nov 2024 12:03:47 -0800 (PST) Received: from nuc (192-0-220-237.cpe.teksavvy.com. [192.0.220.237]) by smtp.gmail.com with ESMTPSA id 8926c6da1cb9f-4de5f7e35c4sm447158173.3.2024.11.07.12.03.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Nov 2024 12:03:47 -0800 (PST) Date: Thu, 7 Nov 2024 15:03:43 -0500 From: Mark Johnston To: Oleksandr Kryvulia Cc: FreeBSD Current Subject: Re: panic after a97f683fe3c425 Message-ID: References: <95a67972-ea73-4821-bbec-3c8857b1f2f4@shurik.kiev.ua> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://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: <95a67972-ea73-4821-bbec-3c8857b1f2f4@shurik.kiev.ua> 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: 4XktLX3qXWz4pjY X-Spamd-Bar: ---- On Thu, Nov 07, 2024 at 09:43:50PM +0200, Oleksandr Kryvulia wrote: > Hi, @current > > My laptop now panics while boot with [1]. > git bisect shows a97f683fe3c425b425cf8cc466319f54ea957c20 as offending > commit. > > [1] https://imgur.com/a/Pb6eakW I believe the patch below will fix the problem. diff --git a/sys/amd64/vmm/vmm.c b/sys/amd64/vmm/vmm.c index 77e0adda86f5..9569f8ace909 100644 --- a/sys/amd64/vmm/vmm.c +++ b/sys/amd64/vmm/vmm.c @@ -513,8 +513,9 @@ static moduledata_t vmm_kmod = { * * - VT-x initialization requires smp_rendezvous() and therefore must happen * after SMP is fully functional (after SI_SUB_SMP). + * - vmm device initialization requires an initialized devfs. */ -DECLARE_MODULE(vmm, vmm_kmod, SI_SUB_SMP + 1, SI_ORDER_ANY); +DECLARE_MODULE(vmm, vmm_kmod, MAX(SI_SUB_SMP, SI_SUB_DEVFS) + 1, SI_ORDER_ANY); MODULE_VERSION(vmm, 1); static void From nobody Thu Nov 7 20:27:30 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 4Xktsw5FQlz5cYDT for ; Thu, 07 Nov 2024 20:27:32 +0000 (UTC) (envelope-from shuriku@shurik.kiev.ua) Received: from mail.flex-it.com.ua (mail.flex-it.com.ua [193.239.74.7]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Xktsw2kQ3z4sTN; Thu, 7 Nov 2024 20:27:32 +0000 (UTC) (envelope-from shuriku@shurik.kiev.ua) Authentication-Results: mx1.freebsd.org; none Received: from 93.183.208.50.ipv4.datagroup.ua ([93.183.208.50] helo=[192.168.200.135]) by mail.flex-it.com.ua with esmtpsa (TLS1.3) tls TLS_AES_128_GCM_SHA256 (Exim 4.98 (FreeBSD)) (envelope-from ) id 1t996I-0000000094V-3Iyu; Thu, 07 Nov 2024 22:27:30 +0200 Message-ID: <21b5e9f7-b3c3-415a-b34a-e0a89215bc66@shurik.kiev.ua> Date: Thu, 7 Nov 2024 22:27:30 +0200 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: panic after a97f683fe3c425 To: Mark Johnston Cc: FreeBSD Current References: <95a67972-ea73-4821-bbec-3c8857b1f2f4@shurik.kiev.ua> Content-Language: uk-UA From: Oleksandr Kryvulia In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ACL-Warn: SPF failed. 93.183.208.50 is not allowed to send mail from shurik.kiev.ua. 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:35297, ipnet:193.239.72.0/22, country:UA] X-Rspamd-Queue-Id: 4Xktsw2kQ3z4sTN X-Spamd-Bar: ---- 07.11.24 22:03, Mark Johnston: > On Thu, Nov 07, 2024 at 09:43:50PM +0200, Oleksandr Kryvulia wrote: >> Hi, @current >> >> My laptop now panics while boot with [1]. >> git bisect shows a97f683fe3c425b425cf8cc466319f54ea957c20 as offending >> commit. >> >> [1] https://imgur.com/a/Pb6eakW > I believe the patch below will fix the problem. > > diff --git a/sys/amd64/vmm/vmm.c b/sys/amd64/vmm/vmm.c > index 77e0adda86f5..9569f8ace909 100644 > --- a/sys/amd64/vmm/vmm.c > +++ b/sys/amd64/vmm/vmm.c > @@ -513,8 +513,9 @@ static moduledata_t vmm_kmod = { > * > * - VT-x initialization requires smp_rendezvous() and therefore must happen > * after SMP is fully functional (after SI_SUB_SMP). > + * - vmm device initialization requires an initialized devfs. > */ > -DECLARE_MODULE(vmm, vmm_kmod, SI_SUB_SMP + 1, SI_ORDER_ANY); > +DECLARE_MODULE(vmm, vmm_kmod, MAX(SI_SUB_SMP, SI_SUB_DEVFS) + 1, SI_ORDER_ANY); > MODULE_VERSION(vmm, 1); > > static void > Yes, your patch solves a panic. Thank you! From nobody Thu Nov 7 21:29:08 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 4XkwF15PNPz5cf8j for ; Thu, 07 Nov 2024 21:29:09 +0000 (UTC) (envelope-from leres@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 "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4XkwF14vhXz440y; Thu, 7 Nov 2024 21:29:09 +0000 (UTC) (envelope-from leres@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1731014949; 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=nSEgAv6SM3seRHZIbWmJTDkHNMvwV5DarXu0kmvEEc0=; b=qbPHNvYCS9tNhn7fj64T+asukw21Bn//ovOkjQrqJPKnkRcrUMqV601UZBzIrp1Fiw9G+7 jIHyF4fEqMFvfYr/BatHLgWM7O4nH3VHmocA2mV7vnpo9YiDVe9j0sGxeuN+05L5P9Pzbm ReJZWm8wiQ2KkQw8AGxhJgsFFFU1gfaVtGSiumwr47qWLZhQYNgkUHhC6hsLBkYPOu0ZRp s5eGkqb/CwkX8+FDUfqxyfnAbkzpFCG5UmtX/mNFA623vyVcLZeGa7ebjji1jh4yuXbieo re/LSYEob3WcGgObB5UcS4WxBh+Yf423o/HmtSsJvkgNtSkFmi/ub5SyjgFhsg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1731014949; 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=nSEgAv6SM3seRHZIbWmJTDkHNMvwV5DarXu0kmvEEc0=; b=P2IMzMIBudxMOm4HYChSHkxHM5mRSXfUvdb9XzFlT5Z1rmurPtq2uSkYkBv5/0rSWlk+qk hF5x6Avii2rsfYBN4WmZuD+A5mgLg6pWA6Zt3DysA48oTuolnfW/YfeFziNWRqL83sP6CE tD6Z4dN0B1vju+Tuc+f0qondDnNXMHsjJxuweqfDza+1DOUrBo6/e3fAqhVcCdVTYA9V/w q3f10U32IFtIC1/vXgkoX6whhrZI4XMULHJyp2R2VP2jGhyBm78f8BCG/c41PQzeFU37Zv R3syKp55qODByvXuEezHw+YwmhmAFK/kJ/ks/FJT5p8lnkP1pBIY47PslJWIuw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1731014949; a=rsa-sha256; cv=none; b=pxtghUgylyN7rO/ETLa0qC8NwmdHLSvwBeBKTfViUZdWYTPsGe6xET1gTPNQvvsyW7/Zrf p0331gGGKapnLS1HKV0bMvo65qTalC9+30IyZrXSiNhKmxEj1tTBB1gVYFqtEfkf05V4Bi n824Q0pGRQXFqVy3wExFJbm9r/wE6W9Ozv6i8kUr+g7hVwVwHwhqWCe2UeTmbcM6pj+Hho KWsgJNvuICxlomZHrfIAdjbnNIKV0eoGH48oGXWI83mHBWl70Kyb2PISOGKAsYWO0cZ3Ua d1ZpFudS6DKnSnBDyK//p1f6Zw4mEeqnNbpxDPu/DH4IyXRQwjreyVNgS7ULuw== Received: from [IPV6:fd:1965::2] (unknown [IPv6:2600:1700:ab1b:6800:2e0:edff:fece:8f27]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: leres) by smtp.freebsd.org (Postfix) with ESMTPSA id 4XkwF124GVzJYY; Thu, 7 Nov 2024 21:29:09 +0000 (UTC) (envelope-from leres@freebsd.org) Message-ID: <1498094c-b287-49a0-ad02-e7d517c5d01e@freebsd.org> Date: Thu, 7 Nov 2024 13:29:08 -0800 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: BRT copying feature To: Ronald Klop Cc: Johan Hendriks , FreeBSD Current References: <1568966692.4590.1730895354064@localhost> <97788ab0-db70-4413-8b18-f9d95f1d120f@gmail.com> <982644351.5078.1730980565800@localhost> <2016215695.9786.1730993474125@localhost> From: Craig Leres Content-Language: en-US In-Reply-To: <2016215695.9786.1730993474125@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 11/7/24 07:31, Ronald Klop wrote: > Another option is this. > > The installer /usr/sbin/bsdinstall uses a script called /usr/libexec/ > bsdinstall/zfsboot. Zfsboot defines this: > > # > # Default options to use when creating zroot pool > # > : ${ZFSBOOT_POOL_CREATE_OPTIONS:=-O compress=lz4 -O atime=off} > > You can set this environment variabele to your liking before starting > bsdinstall. > > ZFSBOOT_POOL_CREATE_OPTIONS="-O compress=lz4 -O atime=off -o > feature@block_cloning=disabled" bsdinstall > > If you are booting from an USB stick installer you can also change the > zfsboot script on the USB stick and restart the installer. > > NB: don't confuse the option with ZFSBOOT_BOOT_POOL_CREATE_OPTIONS. ZFSBOOT_POOL_CREATE_OPTIONS is exactly the hint I needed; why not just allow the user to edit the options? Something along the lines of: https://reviews.freebsd.org/D47478 Add an option to edit the ZFS pool creation options. Craig From nobody Thu Nov 7 21:45: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 4Xkwbt726Rz5cgf2 for ; Thu, 07 Nov 2024 21:45:30 +0000 (UTC) (envelope-from leres@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 "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Xkwbt4yWfz45bt; Thu, 7 Nov 2024 21:45:30 +0000 (UTC) (envelope-from leres@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1731015930; 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=ScEC8rJ8js4CSm2hUMh1tYOo7XAG6BIqu0JnhO0p66E=; b=emQ51S7jtSpnLupbEjfL7igU8hwCR0VyZf4jNlZPGlb2K4I0KK+EIP3AV/zsCwjCiUOmkU QHA99UcjXuryHvngqj3nVLZOfW0YySZEU5wdCzEqiWZ9EbMrNVIRDKSyfGsRu6BCOB2TZm LQP0UZiEIR9hSZRi2Zgw0Y/DAbe33Qn/rJCPuL0oQu/D4ZBRSjrhPIvAU/rVIlzgAu/M53 aIvHnGMXxMBY9cqW8r4x09L81WmsJo6gAJLTd/Qk8m0ohuXGJ8Pr+NaqbYGR3dGZ0xyVWT f4V8EOrVdk/a9T+MZXaT+LtxhzKSlZNJDNJeIwgPiaaMmB5sYEax9+sBXe28lg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1731015930; 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=ScEC8rJ8js4CSm2hUMh1tYOo7XAG6BIqu0JnhO0p66E=; b=UuMbgZ8jggH7QnWzifCw8SCEOTp5H6KKR6WXKpVaw3IkhSI+FiRBw/QKpWv3QvruFdwdVj 9uBF2lPKz8lv5sXoqIgEDaFqGf6RvFz8fiYjRAKDFqa+hIAQtDVnIZv88m3vzQXk5b4o4y TGTTe7MjmZ05BcKMOOcT5OLWJuu++ZSTNqeVfILz0F2Xf5J8jiW1oqqnY/sXPUpy8s0oc8 LBHckGCjAozzp7YrUTmKvyzGX/lQI88WbUIvVQ5HP5Fx5Zujzt+5/I3QYs5/BCTa4Ne0dl jTCsfwUrkuqWf80BUnVoZkXvFa1hvWQ58TBmjrlSMhoJyPuO8mjbxH8KeRCMAQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1731015930; a=rsa-sha256; cv=none; b=PL7O4jL47AN0xhvb8X+0WTzO+W1YNozu5caXlwCjPj6E3DmJ2HUpUsQJGUql47dXOJ6xN8 7YMTWbmU+J576PIMnRSOmd1JTU4GDfRrg2ehAs0uMz65N00RKWYtm0VJT8Q5ihusCphPCe T+IgFjiw7PoeVrqNlsSrcqNGTmM5HitZJePDzZ2Bip5BDcDO2B0EZrSw/UABVZoWiptJdd t6PhL57KOj1Er6zmeq7pO8XuF+v4MN5g9DZOyMDN65slCF938YRW5nbK1ARvLERWa7hu/z U6y6mKUP+jLmNW47sIMsCqWV42J8+va/P2kyORBa7VY84mCOgLh2BfpzzrmBtw== Received: from [IPV6:fd:1965::2] (unknown [IPv6:2600:1700:ab1b:6800:2e0:edff:fece:8f27]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: leres) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Xkwbt1YVTzJrq; Thu, 7 Nov 2024 21:45:30 +0000 (UTC) (envelope-from leres@freebsd.org) Content-Type: multipart/mixed; boundary="------------Kpy14uaX1c1PV87lLjJL1oK2" Message-ID: <553294a3-fa7f-4ee1-a16a-0594fb5e7bb5@freebsd.org> Date: Thu, 7 Nov 2024 13:45:29 -0800 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: BRT copying feature From: Craig Leres To: Ronald Klop Cc: Johan Hendriks , FreeBSD Current References: <1568966692.4590.1730895354064@localhost> <97788ab0-db70-4413-8b18-f9d95f1d120f@gmail.com> <982644351.5078.1730980565800@localhost> <2016215695.9786.1730993474125@localhost> <1498094c-b287-49a0-ad02-e7d517c5d01e@freebsd.org> Content-Language: en-US In-Reply-To: <1498094c-b287-49a0-ad02-e7d517c5d01e@freebsd.org> This is a multi-part message in MIME format. --------------Kpy14uaX1c1PV87lLjJL1oK2 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit (Forgot to include screen grabs) --------------Kpy14uaX1c1PV87lLjJL1oK2 Content-Type: image/png; name="zfsboot1.png" Content-Disposition: attachment; filename="zfsboot1.png" Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAjQAAAHgEAIAAABtPryzAAAAA3NCSVQLCwtrg/PAAAAgAElE QVR4nO3dv5Lcupk3YPMrJw7lyDXKNLq2zbYc+hocujbba+tRNlMbSaFCfAF1yjzGAfCS4P9+ HlWpRhw2CLJbM/j1iwaHlFJK6U8AAAAU/L+jOwAAAHB2f57+YxiG4ce3o7oCAABwHiml9OnL +LWKEwAAQMOf27vU/DuBtRxby6r3M+9b/LzibUZEjrvPlZz2pOeIpTOKX3NVUAAAjtdZccoH teOWsw12S/0cTYfseWAonUu8zbn9vMpVjYj3/LrnCADA/W06Ve9OQ+H4WfTHJwAA4Fw6p+rF zZ2EdtQUr/FRY5vx6tP+1p18OD3r+rGWPUdbiBz9PFMfAQC4ttUrTtPIsexzMvW4Ep9WVx80 R4JE3tp5KkjbTT6MTxScbt+zzhZ/3oUiAADWsXrFadmUtpL4EHzuYL0UikrxII8iVxmU12to Pc4QI3uedwAAiNptqt4y68awiFK0qE9mO794UIyYO3lvO4IQAAB7uNB9nOKT5daaVreshbNN FavXmq4bBXNnm04JAMB9DCmllNKvfwxzB/rbLeGwbsvxRQLW2nPr+zjley6ridX7WTpKvLfx PmyxfIh7QwEAsFxK/x5PdgYnAACAe5oGpwtN1QMAADiG4AQAANAgOAEAADQITgAAAA2CEwAA QIPgBAAA0CA4AQAANAhOAAAADYITAABAw5+XPvDf99AFAAC4jmH48W3uYxYHpyUHAwAAuCJT 9QAAABoEJwAAgAbBCQAAoEFwAgAAaBCcAAAAGgQnAACABsEJAACgQXACAABoEJwAAAAaBCcA AIAGwQkAAKBBcAIAAGgQnAAAABoEJwAAgAbBCQAAoEFwAgAAaBCcAAAAGgQnAACABsEJAACg QXACAABoEJwAAAAaBCcAAIAGwQkAAKBBcAIAAGgQnAAAABoEJwAAgAbBCQAAoEFwAgAAaBCc AAAAGgQnAACABsEJAACgQXACAABoEJwAAAAaBCcAAIAGwQkAAKBBcAIAAGgQnAAAABoEJwAA gAbBCQAAoEFwAgAAaBCcAAAAGgQnAACABsEJAACgQXACAABoEJwAAAAaBCcAAIAGwQkAAKBB cAIAAGgQnAAAABoEJwAAgAbBCQAAoEFwAgAAaBCcAAAAGgQnAACABsEJAACgQXACAABoEJwA AAAaBCcAAIAGwQkAAKBBcAIAAGgQnAAAABoEJwAAgAbBCQAAoEFwAgAAaBCcAAAAGgQnAACA BsEJAACgQXACAABoEJwAAAAaBCcAAIAGwQkAAKBBcAIAAGgQnAAAABoEJwAAgAbBCQAAoOHP R3eArbw/3h8/09G9AAA4r89fP3/9y3B0L7gGFScAAIAGFSfgVv7x93/8/eV13Tb/+a9//uvj LdLyuOfc9ustL2uzvw/5caf77NOrrcXP6H7nDsBcKk7AbY0D3HyYO3d7Pmhea+h8huH4dmcH AHei4gTcylp1kumepYpQvBKVK/Wqp82tPXOgeuZzB2AkOAE0TMPMPvWZevwr7Rmf8lfaMz+7 yHHr7SyzbHpkz1XqP/d1nyMAzsZUPeC25taaptGo9JmffBC8dXWofhb175aG7PHJinPDYaQ/ 9X5GtpdM29/z3Ld4jgA4GxWnJ/Ly+vLqVzL39fH28db3bv3ciXzTYe749T4VgzNP59va1pWu tfQ8R35WQ79hGIbhDxYZf3+8P94f+/eHexCcnlT/EBPObN1FF/b/PNJ5AkCPPZe+KB3rilfS z2folwekz18/f/389aj+cA+m6gFPpH9y3dYxKT7p62xK0+Ge7XM7Z36OAOgxpJRSSr/+MQzD j2/Hdoi1vD/eHz/TdMt0+od3NLmrtZYlmNvmundwWmtxiFJNLL74wVrLM8w9r/gR57YW6cOe S1Pkx3q2qAn7GCtOf1yJ+ssfTOqDUUopffoyfi043ZbgBOypZ4EEgK0JTiwzDU6m6gEAADRY HAKAFZTudpXvs3/fAKCf4ATAakQj4Hr+usGCLt/9JLwhU/UAAAAaBCe6jB+1nN4bYf/7JOR9 KO2zZ6/OY3p91roO8Xae+coDAHdiqh4L5avTHBWZ3AW8pPQcuW4AAHOpODFbadh95oH4mfu2 hfM8R8925QGAu1JxYmV/fIeE31eiSvuM26f7R1or7R85bi5vrd63yNGXndfWkaO/h2td+XVf IaU24/sLewBATsWJDU0Hu5GBdb5/ac9pa/mW+vZ4b/O6TbyGk59vfcg+PW7p3NdV6uGeV36L V0jpes6/QgAA/6bixK72iQRnU49eo2OvyXmiRf8rpFSVqp/jea4AAHBOghMru/rCA0dN2bru FTuneMUPACDCVD0Wqk+Rqu95Nuec3NV/3a7yHK179Po0v/qjzv9aBQCOMqSUUkq//jEMw49v x3aItbw/3h8/03TLy+vL68uve2N/vH28fXTd0zq+AED8o//5d3uWH6gPguP7R84r/wTOFgsk zLXFogul9uvPTqQP8X3qr5C5z2O9fQDuYe+3Dr93jbI4j5RS+vRl/Fpwuq2tg9OdxBdv2L9v W7v32QHASHBimWlwMlUPAACgweIQ0DXF67qm56vuBABQJzjBL88WG57tfAEAepiqBwAA0CA4 AQAANAhOAAAADYITAABAg+AEAADQIDgBAAA0WI6cLlvdbxsAeA4ppZRS6bsfbx9vH2979gdK BCdW4I5AAMAyeTR6eX15fXk9qj9QYqoeAABAg+AEAADQIDgBAAA0CE4AAAANghMAAECDVfW4 jM9fP3/9y3B0L1jH++P98bO4+Cxn4H8ckPPTm2em4gQAANCg4gSbSCmlvzbuQTEMw/B985v6 TXvSc8TSGeVtxvfk/FJK6dOX+j7DMAw/vu3Tn2PlV2Ofc58et37E+p5b9P88r5D4VYq3MxW5 nv1HL7Xf87wDa1Fx4mJS+tOf/vo6/t3aM6W/vkYCTHzPuDEk5FGhtP384j2/7jmSywdh45bp 9sjQ+R6uPiTdov/566G+/fziPb/uOQLLCE5czDD86U+/Dcfr8Wk6cK+HovieAPszQKfOKwT2 YaoelzTGp2n1aRqofr/nMHx/m9aUSpWQ+J7rioe6+P6lfUrT9kyuo9/cKVv9E6K2aHPu0ePW aifew8j0rT2neMWfx/j+c89968l1dZGjx89o7rn0HL3eMjwPFScu7B7Vp9J0vrwPeeyph8D4 RMHpdvU36sahVT6Miw+q4p/DiR+lvme8zfqekbMriU9mm27vmTAWaSE+aO5X6mF+9PjzPvfc S9d2n+mmkaPHzyj+Con/j4s/R/CcVJy4vDtVn+ryXk2397QsIBEXjxBz94wPy+otx9uZOxCc 2891j/48ptd53fh67DU/zzO+7isZnofgxOVNa02lyPTbntGwsW4sWVdeEeqJdqUzFaW4ri2i HfvLax3j38uetbmT99Z17NGBtZiqx4U9W2Sq15pEHa5oWXUor0XUH7XWnv3D3PjEuWdWrzUJ Gz1cPeghOHFJ549MecgpbY8Enkg79WmHkUdF+hw/o8ienF8+zCoNvOJ7xj9lsWzP+rC7Z8/I Wa+lFOTqAa9+dvEAuUU/lx29/hxNxZ/ZSJ/jZzS3z/VHxc9o2dHzYwmlEGeqHhdz/sg0t51I 4Nm6P3sea/T+eH/8TGsdke1sN+1tu89KHbVnXKTNnuNGosXWx9rn6HNb2/NYax19revW86qb bn9/vD/iR4V7EZy4mHpY+v2evdEFAABGpuoBAAA0qDhxGSZ3wZ78jwOAKRUnAACABhUnLuP/ 3j5//fw1suffXud9ePUff//H318a67z981///NfHJp+DKh192REj59J/lK1Nz2LsYf28SmeR t9Pfn/7WnsHnr5+/fv76/ljzY+RbtHmU8VymW7a4VvWW17qekWMB3IOKExczhqJpNMq3zJUP gsct0+1zA8nco28xEC+d17pH2Uf9XLZ7dkpHh2WmcWX6J49SPfYMMMIS8DxUnLiMSDTqiU/3 EBninzkGzK0RTetR49/TR535TJnLAH1drifAXIITzBafXLfuNLx1rVulOc+5zz3uskmApccu m1h4/qmApXrIdPCd71OaxJVvj+yZf3dua/UzqgeJ809I2/qs44+q96enTYBjmaoHf2BawRi3 5APi+vA3vudRIhMUS3vm2+vnHplWt9bnkeJTH+v9XHbcdds8g9LUsnzP/Lul/fNhdLzN0j6l 3pbi3NaT5fYUOetR5HqW2lwWbOrPjrAEXIuKE/yB+GA3UmGYu+ee6lPd6o+KtH+2853Kz326 vf7Y0v7L2jxzuCrVcNYa8uZBa63W6ubGpGsN8fujYM/zXgrDW7+WALYmOAG/s1blJ97Cukec K6+GxQPknm0eK14juoqr938fc5/3SFS732sJeB6m6sFC8VrKmasuo7kD+mVnlNdh+vWErnpd KP45pXya4tw2p48626ul9KmYc05s6+lV/bHjd8951rn+fi573iOTJOe2CXAeQ0oppV/3hh+G Yfjx7dgOsZb3x/vjZ5pueXl9ef1tQPbx9vG2xjvfR71fmN/TqWc9vbWWE1i2QMJ2d5HqOa+5 n8vqP/e5yzBE2qzv39PmsomX8VfUeWpT+ywPUGotMkyf7lmaDBZpOV5L6f+Jt8V9nCKLZMy9 nvV9SseN9KfeJuw5Ytkqun8/xc9w+qWU0qcv49eC023dOzixhXhwWmtYf+wkPe7EzyK4E8GJ 85gGJ59xAg4LMMISAHAVPuMETyq+8ls+kexsn8PhmU3fLfZpGQC2o+IET2rukutb9weWMT0P gH2oOAEAADSoOMGG69rdydxV9fbpiedlTxZgAOCZqTjBHwy+xy1zF7m+t9JVGr92fQCAexOc gC77x6c81rKd0nILlmEA4NmYqgez9d8AN9+/f89lrW2n3s+1ItbcmxTnj9ri2byT/NalJuwB 8JxUnOAPlJbqzreUhuD1PfNjRfbM9ykd/dhpdZGrFJkemW+PhJO1rvyyZ/PehCUAnpmKExfz f2+1CUJ/e11/YNdT04jfK2mt457Nsqs0/e5aPam3tvWzeV15fWlagxKlAHgeghMXs0U0yuUD 5XoNp97O+HW9tYjSkP3MUeoq0WL/Z/MqStFIZALg2ZiqB0XxcJLXIurViVJr9RbOKV6BiVeW 1ooiy67nWs8mAHAnQ0oppfTrH8Mw/Ph2bIdYy/vj/fEzTbe8vL68/ja8+3j7eFtjYHqP6Tql oXx8+/S7pTZLe9b3n7tEQf2IPdPhtjujfP9lZ73ukg9nW2wD4HnsOWLZao3Q734v3ERKKX36 Mn4tON2W4AQAXJHgxHlMg5OpegAAAA2CEwAAQIPgBAAA0CA4AQAANLiPEyxcM22tG6FucePX uWvQrXUU68vdm8VgAHhmKk7QuI/Q1nfp2SJsjG2WzmvdyLRWmwAAZyY4QVE9PgkMPIPSQr1b LeALAGdlqh7M0HNT1/ijSo/dIqTFe1jaszRlce614pzGiXnTmGTCHgDPScUJZohXmdadzLZd 2IhPU4xP/6t/+mvrqY9sR1gC4JmpOHEx//dWmyD0t9ezDOzGwDCGhLnLSKy17MR5TK/G0X1h nry+NK1BiVIAPA/BiYs5TzSKyOsw49/3iEM8g1I0EpkAeDam6kFRT+WnXmvq/2TRVVy9/wAA I8EJ/mBwXw88pf3ryycsC1HxfSL9ybfPPXr9Wo3qn2tSbQMArmhIKaWUfv1jGIYf347tEGt5 f7w/fqbplpfXl9ffBq8fbx9vawxefc4BAFjXniOWrW6u8N1bhDeRUkqfvoxfqzgBAAA0CE4A AAANghMAAECD4AQAANDgPk5cxvTWt9O7OeW3xJ17r6fIynLbrQVXOvqyI5bWuFv3KHBmFq0B YAsqTlxGKQ5Nty+7PW4eHsYt+9xPKT9Wf2uR7SITAECc4MQl5VUmStyCFgCgn6l6MFt82ttV JshF+lkPYNc9d+rqdziZToeb7jluz7fUWy5Nrovsme9TPzoAzKXixCWNU/K2qzuNg/7p0D// pFA9KsT33Eck9vRMUKyf+z6THtnOGDym8SOPInmIqgehvM1S+InsWeqhyATAWlSc4A/EqyL1 pReW7bm/7Xp1zvMlLh6HSo+K71+vbs3dEwDWJThxYVvXne6hHthKlbG1Ao+JefdgnToAMFUP Flo2je2Z5RMgOb9SZOqv+cRbUF8C4AyGlFJK6dc/hmH48e3YDrGW98f742eabnl5fXn9bcD6 8fbxtkYdYM/3oev3axq/u2w58rnLGKy7OMS6d5GqH3HP+pLFIe5h2eIQ+XcjLfcsDlF/lFoZ XMueI5at3pr57jfdTaSU0qcv49eC023dLzgBAM9AcOI8psHJVD0AAIAGwQkAAKBBcAIAAGgQ nLg8y5Gvy9p3AAA593HiwnpW0puKh4R7rwhXWnMv/+50n9L2Zcct2frK18/9DPZfpbC0ll18 ey6yCp8lZwA4JxUn+IOh57jlnAPoo0SuRk9kcs1L6ldpu9rgNLos+3r6Z9ryNBpN/7hfEwBn JjhxSWvVmiKeYUC/rN6yXZXm3lf7OUUqSKpMAJyZqXpc3p4harTFbW3r++95Y9m5cajnuNPJ fpHqU/+th/Pj5t+de5vgrZ/3Y2NkPn2ufypdXl8qVa4A4DxUnLiYfWLSdCg/HdrGPwXUU7cp PXaLKVv9VaP+qWKlc6lf+dK5x69n6bv19vd/3iOPjTxqT2Momv7J98kn6ZmqB8CZqTjBH4gP Ruu1i2VtRva/66p3+fXMz3TZuW8xmbDnea9X20qtHRWZ5taa5laN8vik7gTA2QhOXFK+BPn+ E/aOtcWguRRR4kP//sUh8pZLx40f5cxKdbb6Nd+3j+srRSNLRABwZqbqcTFjNJr+Pd2+Z0+2 qPnklZbIUXruvDSdJFaatDa3zWV6phpGPq201v2p1nre67Wm+1UU8zgkIAFwLUNKKaX06x/D MPz4dmyHWMv74/3xM023vLy+vP42FPt4+3hbY0B8hkk1/bWmuZWNnkUCetpc1vJc8aF8/32c 1lpKYa2rVD+XdZ/3+HIgpUftGWtL91yq75MrLTVRbxl4NnuOWLZ6E+f75WcHMEoppU9fxq8F p9t6nuAEANyJ4MR5TIOTqXoAAAANghMAAECD4AQAANAgOAEAADS4jxMXk9/BKTd3hb340s/3 uItOyVorth27XlzPKn9zW163/bOZfmB6+nHqZSvsWUIGgKtTceJi8ns35fd0mqt0/6K7Doi3 Vr8f1NZ3KNr61sD5a+N+91walaLOdHspMo3b63ELAK5FcOJWtrgNrhC1lshdoVznc4rEntJS v2pNANyDqXoww9xJaJH9969XRKol+9xoda3bBNcfVXps5PqLcwDASMWJCxs/7zT9e62Wx8H0 9O9xe3wSWn1yV6mFkvhkwshRIn3bJzDEjxK/nvHj9rS5T7A8j7FqZLodAM9MxYkL22Ji3mi7 ofCymDTdPo1zPa1dS37u0+31x5b2X9bms0UmAGCk4gQX9myD+C0WZpjb5jNP3lN3AuCZCU7c yroT9kZ5RWJZC2u1NnfIfp4133piXr0uFP/sU/25eIa18raWx6rSohEAcC1DSiml9OsfwzD8 +HZsh1jL++P98TNNt7y8vrz+NhD8ePt4W+P98v2HRMfexylXWmCgvvBAZIDeM2Fsi0UUSvtH Wii1Frny8SUcSm0uW4Rj6/tNnV/9Xkyl//vu4AT023PEslUV/fttfzs8m5RS+vRl/Fpwuq27 BidG8eB078E9APcjOHEe0+Bkqh5cjFAEALA/wQkuIL7yWz4hzWd1AAD6WY4cLiBeWVKDAgDY gooTALd19cXTr95/gDtRceJi6qvqLbslbnxtt7kt9/Rkrduw3unWrus+U/3rBz6b6SB+ek+n yP2d5t4Dqn/JmbkfBJ/7kfFSDyPrCpb2yftc2g7A/lScuJhpNBq/nv697D5O+XB5ixut0iMP df0hR0yKmw7cSxEoH+6X9p9uL21Zq7f5d0vHLZ1RvJ/5VZpuL+2zRewEYAuCE1zSWuFh6za3 dq3eXlEphCwLOZFHXbGu0n+VrnjWAM/GVD2Yree2tvn+pT3zGkv8VrlbtFlvOX7uy6LOtLeR 6tOyPiy7rXDPuS+7/fF5nG24f/4pbaX6W/51/bFnPkeAu1Jx4sLGiXnTv5d9xilXX/57Olgv DZrnroMXmS4Yrwht0WbPLXfXmvRYuubTNnsm9ZX6WW8zfkZbtHlO4+B++uecA/1pD/c8bj5J zzQ8gPNTceLC1opJufgiCmu1eUX1mtX+R9+i0pXb4nyvFZMiix+cMyblSss27Nn/PD5d5eoB PBvBCWYo1VWuNfC9onr1b8/rv0UAvlaoLi17QET901CuJ8CZmaoHzHZsUOyZGrduz6/SZr98 QH/OIf6x8aN0lUp1rWXtq0cBHGVIKaWUfv1jGIYf347tEGt5f7w/fqbplpfXl9ffhmIfbx9v a7zDvf8v8nzB8f4Je2stkBAx99NE00f13MVorTaXLZBQOlbPPZf27+e6i4LE+3kGkfsORabw Rdpcq7f1RcNLj43X0yJxqD4VcNkVE5x4BnuOWLZ6q+X7iX6G0yOllD59Gb8WnG7rrsEJIOJO P53udC4QIThxHtPgZKoeADd0j08NiUwA5yE4AXBbV48cV+8/wJ0ITgAAAA2CEwAAQIP7OHFJ pbX1xu3L1tnrWbPunHpWeLvWmbK17VbAA4CrEJy4mFI0yqNU3P1ua3u/M+Io9XWoxCcAnoep etxE/92ccverutTPaPzu/c4aAKCf+zjd1r3v4zStL60Vmeq3Z51bq4ncMnXryYGRG87Gb8B6 11u7skz8JrP5rXL37SlwPe7jxHm4Ae5TuHdwmtozREWmwNWDQb7n3GOte0b1vsV7HrkaPkN1 D5HINP3uGX5KANciOHEe0+DkM05c3nRZiJ7FIabyYJAHj0gFZlmdam5v4y3nZxQ/Yn9Q5OpE IACemeDExZSi0TQ+zW2zFAPiE+ribe4TJLY4o3rLJSpL9zA3MuVT9bbsHQDsweIQXFLPGnp1 9VARWVxhu6Mf22Y9Csbrb2pQ1xKf3DLdc/pn3/4CwFZUnLikUn1pn4UiIqa1nVJUiGxfq2IT +SRVvA+ReFk6dzWoK4p8BmC6CETpu9v0DgD2YHGI23qexSGuzpIJ3MPcRSMASiwOwXlMF4cw VQ8AAKDBVD04TGmlPnUnrshUPQDuTXCCwwhI3I+ABMBdmaoHAADQoOLEZUzX0MtXz6t/t6S+ 5lv8u89TO4osJn6Gq1Hq5xn6dhWlezHlk/EiH7ZWiQLg6lScuIxIHJq7HHl8GG3AnQfFc16T ej/dRSquFHWm20uRKb+P01brVgHAXgQnLmlaX1r3Zrjxm7SeOTzsyRV4BpHYU1rqV60JgHsw VQ9miE8Ai0evuZPfIn3YYkJd6ba20wAZj515m3O/WzoXQQ4A2IKKE5c0Tskba01zp+f1iFeZ tpgEWP9U1T6fuSpNfistpF66YnnUKbVcOpd4UHzOT6Otq77UOAA8AxUn2MkWUWpZTWYt+dFL d6aqtzP3c0drRU0AgDgVJy5si1qTTy6VlKbh9VyrrRec8GyuS90JgGcmOMElHbs6XP3o9aDS H2OsjHdmeawqLRoBANcypJRSSr/+MQzDj2/Hdoi1vD/eHz/TdMvL68vrb8PNj7ePtzXeg99z SHSG+zhFRBY8qPehtGd8/y3uYrTFIhbxluPHLbWs7jRX/V5Mpf/77uAE9NtzxLJVFf273zg3 kVJKn76MXwtOt3W/4MQzE4EAnofgxHlMg5OpegAAAA2CE3Bqy1bqAwBYl+XIgVMzMQ8AOAMV JwAAgAYVJy5jum7eaFw9r7Q93nJ86te9qx/rLsBw1G1559piBcJ7mH5gOl9Pb7qntfUAeAYq TlzGNA5Fvo7Lh8hunNpj69varqXeT5+kKkWd6fZSZBq31+MWAFyL4AQNZx76X4treF2R2FNa 6letCYB7MFWPCxsn6S2rMi1Tr0LMvbVr/Va524nUVXqm7U3Pq1TVyb8bb3Pud/M9l50XAPDM VJzgD0yH9fUIUQoh8elqkeF7fDJh5CiRvvXX2UqT38a/l53RdJ+85bnnnnOb3ZKxamS6HQDP TMWJS5rWmvLFIfptN2heFpOm2+vxY9kRt5ZXhJbdnWludS5+7iITAFCn4sTFlCbm7Tlh7zzO OdwvTcPr6eHWC074JFuEuhMAz0xwgoa5n8YptbBWa3MH98euDjf3U2Hx7/YfnS3ksaq0aAQA XMuQUkop/frHMAw/vh3bIdby/nh//EzTLS+vL6+/DSI/3j7e1nhn/aghUT5Vr6fi1B9jStWV yD2Clt1HqF5r6okr/ZWiuYs0xK9AfxAqncs5a3fHqt+LqfR/3x2cgH57jli2qqJ/93vkJlJK 6dOX8WvB6bbuHZyIB6dniwHPfO4A9yA4cR7T4GSqHlyMYAAAsD/BCS4gsjD6dM/6lrt65nMH ALZmOXK4gHhl6ZlrUM987gDA1lScAAAAGlScuLD81rfL1tbbYkJXfVW9fM9Im+u2Ntey1f+O bT/+eTCfHIuwGAwAz0zFiUuaLkE+DUt5lJqrdCPUudu3uGFr5Ojbfapnu1vE9iytDgCwD8GJ iyndtannPk71+DH380Vb39T1TkrXef+rtF0svLrSQr1bLeALAGdlqh5sYjpVb4vqU0T/jWXP EyTit/Qt7Zk/C3PPuud2xqWWe25VvI9xYt40JpmwB8BzUnGC35lba5pGo3wQXKplrTX9rBTM 4pPfrjtNrl4hjExrjIfYntsNl/p5VJzuISwB8MwEJ+gyHfLOnaTXH0t6jt6/51HO0MN1P7E2 DcBnC1F5fSmvQQHAMxCc4Jd111Wr16B6WuZO9lzeY5lSlUn1CYBnIzhxSfnqeaVFI/r1T647 digcP/p5+nnmCYRbT7Nc9ygAwFqGlFJK6dc/hmH48e3YDrGW98f740zZTcAAAAyHSURBVGea bnl5fXn9bSj28fbxtkbd46iPia91B6fRWlPm5rY5t/q0xWIG8T23u4vUFosu1NtfdpetZf2M H6vUJsCz2XPEstXE4+9+ht9ESil9+jJ+LTjd1r2DE8/GDWoBnofgxHlMg5OpegAAAA2CE3Bq +SQ3n/8BAPbnBrjAqZmYBwCcgYoTAABAg+AEAADQIDgBAAA0CE4AAAANghMAAECD4AQAANBg OXJWkN91O6WUUjqqPwAAsC7BiS7vj/fH+yPf/vH28ebeOwAA3IWpegAAAA2CEwAAQIPgBAAA 0CA4AQAANAhOAAAADYITAABAg+AEAADQIDgBAAA0CE4AAAANghMAAECD4AQAANAgOAEAADT8 +egOcIyX15fXl9ejewEAsL5hGIZhOLoX3I3g9KQ+3j7ePt6O7gUAwPreH++P98d0y+evn79+ /npUf7gHU/UAAAAaBCcAAIAGwQkAAKBBcAIAAGgQnAAAABqsqgcc4PPXz1//ElooNqWU/hpa On8YhuH7k64V+f54f/xMR/cCAO5MxQkAAKBBxQm4jHpNaaxNxetOpVrW/pWraU+euW52D//7 P//7P//7P6Xv/td//9d//9d/79mfZUpncZX+A2xBxQk4nZRS+vRl/HvcMo0TY8yIT+ErGds8 f1DJrwbHKt1Gcxo2rh4wxv5HzsJNRYHnITgBJ/KfYenHt/b+ffHp/KbXQXw61hgS3h/vj/fH dHspMl09PkWMV0N8Ap6BqXrAKdQj03QaXqn6lG/Pj9JTX4q3WY9z4/6lfUrT9sZrMq0+RYIl aylFpog8PkUmws2d8hfff4tpeNP4tOwqAZyfihNwsHiVKZ+kV4pSke/O62GszfqeU6Xvth+l +rSvLcLAdCJcKdLkMaa0Z/6oUgSq71mPXhGqT8C9qTgBh5k7Me8/H9uqMm0xkW9Zm+t+kiqv Pn28fbz9PPUnta5ou/pJf0SJqFeQtuuD6hNwV4ITcJj49LN6hade1Vm/z0cvJpEHToPTLawV APon5m1hu89fiUzAXZmqBxxs7vSzZdFlrbX44m3mAa//6D01OpaZO/2sPoluq16Wjx6JZPE9 60Qm4N6GlFJKv+4379fwnbw/3h8/03TLy+vL68uvQdvH28fbh4k9HObz189f/zLk2/NgMPfu TP9up7WQQyTGLFtwYtnSFPmj/vPo5ciU/39nC/VgEF90YVlEGdvJH1vaPvfocytg0/1FJs6v 9Crd6lN5R89NYC2/+/0rON2V4MSZlYLT6D/rTkNxz6kzTKLbQqTKJDjtSUiYcjW4CsGJZaa/ hX3GCTid/5y8d2xvjuYtrbMREqZcDeB5+IwTAABAg4oTcID41LKPt4+32PvZpqsBANsRnDiR 0jxjU0EAoIffsNBPcOJ0Sj/E8x/6pWWCr/Vr4Or9hx7HLi0QP/rVl0CIf/y99NH5+E/mUjtX MXepgOmZ9iwzEF/4PrJnfv33WxQB7stnnLiM6Q/9yNdXMfb5ij0HriX/adP/86fU2nUH5aUz ivyuqf9uilz5yNEje173+sOZCU4A0HD1tzYi/a/XmgzER3PrNsuufP+ewBZM1ePm4tNItpgy t26bpUFM/Vzq+5f23PPXc+Qq9Z9RpOV6a6U2I48qHX0tPWcduZ6RNvOWp+rXZ59ns+fo9bOe e/T49Xxm6/5kAOin4sRtTQcopakO9T3732Fdt8082EQG8aUt9Zb3fHc5cpVKQ/lSa5E98ys5 3Z63Fvk6/qpbV70PPa+Q+Ksufu75d0v7L3slR849fvTIMxh5LU3bjFzPKxrPov9c5l7P/FE9 R897Uj+v7Z7ByNFLe+7zkweejYrTk3p5fXl9eR2/HoZhGIajerLdD/f8l1l9GLTdr71127yf uVepFFp69pzuExmgRGLGdMueg5izDZj27M95/sddPQ7lr/M88uWPyrevNYiPXM+5/9/jx+1v Z+ujR56duuu+VmFPgtMT+Xj7ePt4y7efbZi1rvj7kVu8T1kaRqx1lKu761Xa+l1wcnd9LR3L 1Ys7Q1TuiU9+RkGEqXrcVn2SzLIWGK01IecMImeRD0fiw/R4FWut63ns85If/R6vk4jtzvSo /3HTeun+A+tzvnLO9v8rd4YIB3c1pJRSSr/+MQzDj2/Hdoi1vD/eHz/T0b2YJ/4+WWl4Wt+n tGe8zbnqw+i5k0/yCWD17aXvlgJAJBjkLR91ldZ6Hue2PDc4RfqQt1/fM9JC/VVR6nP9ys99 NUaOXm8t3s/60evXNn4u9fOa+3Mp/r94us92/+MiPSk9C6Vj9b+e663t83M7Ir+G/a+Q+rF6 Xkv1fj6brULm9z+Y48MVpZTSpy/j14LTbd07OHEGnq91rRuc1u0bZ+D5ZV1eUSPBibppcPIZ J05ni3cQWZdft+tyPanzCqHfVvEAnomK021dseIELOPtBoBlVJyoM1WPDn99PboHAADnJjjd xTQ4WVUPAACgQXACAABoEJwAAAAaBCcAAIAGwQkAAKBBcAIAAGgQnAAAABoEJwAAgAbBCQAA oEFwAgAAaBCcAAAAGgQnAACABsEJAACg4c9Hd4Cr+f52dA8AAGBvKk4AAAANghMAAECD4AQA ANAgOAEAADQITgAAAA2CEwAAQIPgBAAA0CA4AQAANAhOAAAADYITAABAg+AEAADQIDgBAAA0 CE4AAAANghMAAECD4AQAANAgOAEAADQITgAAAA2CEwAAQIPgBAAA0CA4AQAANAhOAAAADYIT AABAg+AEAADQIDgBAAA0CE4AAAANghMAAECD4AQAANAgOAEAADQITgAAAA2CEwAAQIPgBAAA 0CA4AQAANAhOAAAADYITAABAg+AEAADQIDgBAAA0CE4AAAANghMAAECD4AQAANAgOAEAADQI TgAAAA2CEwAAQIPgBAAA0CA4AQAANAhOAAAADYITAABAg+AEAADQIDgBAAA0CE4AAAANghMA AECD4AQAANAgOAEAADQITgAAAA2CEwAAQIPgBAAA0CA4AQAANAhOAAAADYITAABAg+AEAADQ IDgBAAA0CE4AAAANghMAAECD4AQAANAgOAEAADQITgAAAA2CEwAAQIPgBAAA0CA4AQAANAhO AAAADYITAABAg+AEAADQIDgBAAA0CE4AAAANghMAAECD4AQAANAgOAEAADQITgAAAA2CEwAA QIPgBAAA0CA4AQAANAhOAAAADYITAABAg+AEAADQMKSUUkq//jEMwzAc2yEAAIAzmGYlFScA AICGP6/V0Pvj/fH+GL/+/PXz189fxy3j12sdpd/+vZpemZLpFYvsWWp52ZXPn7vIo7ZzzlfO XKVn56ieRI5e33Of10nkKGf4X3yV1+fZ/nfn1np9AsDm0sSyFvIhxbglEgP2t3+vSkfs2V7f Z9k5nuf5Ok9P1nLsGcWPHtlzn3OpH+Uq1/M8ztzndV+fALCuaVbqmqpXev/PO4JT+dVY9r5p ZH9Xntz9XhX3OyMiPO8AHGu1qXq50qSyfFpaKVqUWpu7Z6km1n/0o9SvYX9v49Ol8l4t23Pu czS3//uf0brq0zLj2yMtz71WZ3u9lfafPmrZKySu3ttlz9qy53StV2a8b8t+wpf273/e629d LXvtRXoCwA31TNWbO3Ein0hW//W57Fg9k3z6j97Tt+k++Z/4o3r6FnlGSlt69qw/apm7ntHc 9tf6v1Pap/9Vl2/Z539x/FmOfzf+qLn9XLbnWj8ZIm1ufT3ntlM/92U/Geb2GYCrW22q3jKR 2sj0F17kl2X/4GDrNucar8z0T2T/8euePi97DzX+qP3fo73fGY3uOnTrv57TSsL0KpVa3uIZ jPwMKVWZetosHWVe7/vaPE8dZv/XEgD3tuFUvfHXzHbD1lL7/QPK7QZS606byVubOxSDu8rf SthnsNvzc6neT4P1oxz1WgLgbFaoOJWmN6z7q+XYMLDd0dedQrNnf7bYcwt3OqNpMM6/3r8/ W+i/tnkL9TcUjn199rzZEQ9jS3u3pJ2r/H9f1po3pwCe2TD9dNMwDMMwzG2i9Ktl7j7L9q// Ylv24em5va2L/Iot/TKu93/uoyL97PnAdP+epUdd8Yzqz3v/K6r+Ou85eulazd0+94ymLdS3 1M+otGfpKkVeIXOv59yfS5EAvOz1GX/918Vf88uOGHl15Zb99I6/kuOvJQDu6ncrQfTfxwnO ybvC1J3nFXKenvS4x1kAwNTBi0MAMIrUmgCAM1hhqh6czbqTLbmfY18h/RPnzsb/OADu6ndZ ySQ9AACAOlP1AAAAGv4/i1H/W5m1XAsAAAAASUVORK5CYII= --------------Kpy14uaX1c1PV87lLjJL1oK2 Content-Type: image/png; name="zfsboot2.png" Content-Disposition: attachment; filename="zfsboot2.png" Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAjQAAAHgEAIAAABtPryzAAAAA3NCSVQLCwtrg/PAAAAUNElE QVR4nO3dvZLbyKGGYeOUEoW70amZbDnXttmWQ1+DQ9dme22kMrJOtAoVtgPKJRxjga9BAMQP n8dVrlkKAhogJeGd7iGbUkop5W8AAAD0+J+1BwAAALB1n9r/0TRN8/XLWkMBAADYjlJK+emX +9dmnAAAAIJPeZMhPwosWXcua3ic3bHVn1f9PmvUHPc5V7I9kilH7Duj+mtuFhQAgPVNnHHq 3tTeH9nazW7fOO/at+zdYOg7l/p9jh3nXq5qjfqR7/ccAQA4vkWX6h3pVrj+LKbnEwAAsC0T l+rVG7sIba0lXvffdd9n/ezT8827+LB91sPHeuw5WkLN0bez9BEAgH2bfcapnRyP/ZzMcK7U L6sbvmmuCYnu3rYzg7Tc4sP6hYLtx585z1b/vIsiAADmMfuM02NL2vrU34KPvVnvi6K+POim yF5uyofn0KbYQkZOed4BAKDW05bqPWbeDKvRlxbDi9m2rz4Ua4xdvLccIQQAwDPs6HOc6hfL zbWs7rE9bG2p2PBc035TsGtryykBADiOppRSSvn+H83YG/3l3sJh3j3Xv0nAXFsu/TlO3S0f mxMbHmffUepHWz+GJd4+xGdDAQDwuFJ+3E9ODCcAAIBjaofTjpbqAQAArEM4AQAABMIJAAAg EE4AAACBcAIAAAiEEwAAQCCcAAAAAuEEAAAQCCcAAIDg06O/8cdn6AIAAOxH03z9Mvb3PBxO jxwMAABgjyzVAwAACIQTAABAIJwAAAAC4QQAABAIJwAAgEA4AQAABMIJAAAgEE4AAACBcAIA AAiEEwAAQCCcAAAAAuEEAAAQCCcAAIBAOAEAAATCCQAAIBBOAAAAgXACAAAIhBMAAEAgnAAA AALhBAAAEAgnAACAQDgBAAAEwgkAACAQTgAAAIFwAgAACIQTAABAIJwAAAAC4QQAABAIJwAA gEA4AQAABMIJAAAgEE4AAACBcAIAAAiEEwAAQCCcAAAAAuEEAAAQCCcAAIBAOAEAAATCCQAA IBBOAAAAgXACAAAIhBMAAEAgnAAAAALhBAAAEAgnAACAQDgBAAAEwgkAACAQTgAAAIFwAgAA CIQTAABAIJwAAAAC4QQAABAIJwAAgEA4AQAABMIJAAAgEE4AAACBcAIAAAiEEwAAQCCcAAAA AuEEAAAQCCcAAIBAOAEAAATCCQAAIBBOAAAAgXACAAAIhBMAAEAgnAAAAALhBAAAEAgnAACA QDgBAAAEwgkAACAQTgAAAIFwAgAACIQTAABAIJwAAAAC4QQAABAIJwAAgEA4AQAABMIJAAAg EE4AAACBcAIAAAiEEwAAQCCcAAAAAuEEAAAQCCcAAIBAOAEAAATCCQAAIBBOAAAAgXACAAAI hBMAAEAgnAAAAALhBAAAEAgnAACAQDgBAAAEwgkAACAQTgAAAIFwAgAACIQTAABAIJwAAAAC 4QQAABAIJwAAgEA4AQAABMIJAAAgEE4AAACBcAIAAAiEEwAAQCCcAAAAAuEEAAAQCCcAAIBA OAEAAATCCQAAIBBOAAAAgXACAAAIhBMAAEAgnAAAAALhBAAAEAgnAACAQDgBAAAEwgkAACAQ TgAAAIFwAgAACIQTAABAIJwAAAAC4QQAABAIJwAAgEA4AQAABMIJAAAgEE4AAACBcAIAAAiE EwAAQCCcAAAAAuEEAAAQCCcAAIBAOAEAAATCCQAAIBBOAAAAgXACAAAIhBMAAEAgnAAAAALh BAAAEAgnAACAQDgBAAAEwgkAACAQTgAAAIFwAgAACD6tPQDYh+v5ev5W1h4FAMf0/vH+8blZ exTAEDNOAAAAgRkn4FD+8fd//P3tNO8+//mvf/7rdqnZ833Lsfsf3vNj+5w+hu5x29s8Z1RL qz+j4507AGOZcQIO636D273NHft496Z5rlvnLdyOL3d2AHAkZpyAQ5lrnqS9Zd+MUP1MVFff qKbsc2mvHFSvfO4A3AkngKAdM8+ZnxnOv74t65f89W3ZPbua4w7v5zGPLY+ccpWmn/u8zxEA W2OpHnBYY+ea2mnU9zM/3ZvgpWeHhs9i+Ff7btnrFyuOjcOa8QyPs+bxPu39P/Pcl3iOANga M07woLfT28ktzpbcLrfLtO/Wj13I177NvX/9nBmDLS/nW9rSM11zmfIc+bvlSJqmaZq/eJPx 6/l6vp6fPx5gCuEEM5h+y8685n3Thef/PNJ2AmCKZ771Rd+x9ngl/X1yJN1Aev94/3j/WGs8 wBSW6gEvZPriuqUzqX7R19b0LYd7tZ/b2fJzBMAUTSmllPL9P5qm+fpl3QHBNl3P1/O30n6k vZzGd4i3Y663JRi7z3k/wWmuN4fomxOrf/ODud6eYex51R9x7N5qxvDMt6boHuvVUvPV3Gec /nom6vNfLOoD1lVKKT/9cv9aOEEV4QTDprxBArwO4QT70g4nS/UAAAACbw4BwAz6Pu2qu83z xwYA0wknAGYjjeBxPy/wtiJ/+vMIs7FUDwAAIDDjBCsb/kyP9g8Qd7f0EYpz6ftx7VdQf+5H vUrtP1nHOzvG8jct0Ec4wcru/yQPvc/Sfx4fjihgrKOmIFP4mxboY6keAFUEBgCvzIwTHFb9 gpMpW/Ztv8Ryl5p9tucQhpdgdfc2dvvhbWrGUG/46GOPW3/uY5/HeZ+jvn3WjKR+hFt73vuO WP8amD7OJV7JNcuSHzvuEn/XAXT5AFyosvQH4I69NRxeYlSz8K9mPN0bqZp9Tj/69DOqH9WU Xx1+/P718FLMx869/mZ3+rnXb1k/zuHtl34tLX1G7V99zmt+iSv/nDOqP+70cx97lYZHOEXN Wc/Ju+rBNO0PwDXjBBuyxD/Pc23Z993f+u/sTrfUjcUyR29fmXmf2e5z0XfcdQ2P87E9DL/q llZzRnM971NCZfqV7+6t+/WU/dSc12PHqj/3ea8S8AqEExzWlDmEmpvy4VufJW5t102C7QTJ qxl7w31Uxzj3Y5wF8Jq8OQS8kCnfW+3+3rHfrzUH9ZxjHemaTH/VLTGGZ6o/3+3PnIz9Ns0S r/ntXyVgy/yME1S5npf6Gae+W8OaLYd/15Q9d5cJjV0YVn/0ejX7HP4Jh/oxP3Y9lzjrsUfv W95Wv/++69Y1/SoNP0fLLUec/qfjsb1NGe3wPseOoe9q9135Ja553/7HvpKXfjZr9lxvbEBO 5WecYJr2zzgJJ6iyXDjBXCyCOqpXe2aPfb7CCfalHU6W6gHARh07IQD2RTgB7F77e9V+imPv 7s/gayaTVzKwZd5VD2D3Xu32+the+dl85XMHts+MEwAAQCCcAAAAAuEEAAAQCCcAAIBAOAEA AATCCQAAIPB25LAhPrcEYC2llFJK36/eLrfL7fLM8QBbI5xgc3ySCcDzddPo7fR2ejutNR5g ayzVAwAACIQTAABAIJwAAAAC4QQAABAIJwAAgMC76gEAo9V/fIJ3CgWOwYwTAD5DDAACM05w cN0bYt/93Zeln8H7/td6Vaz7+qw/93Wv0nLa13/47Oq3BDgqM05wWO1bvfaNjrmFfek+g8fg 9bmuvus/ZUuAYxNOcEB93x1300PbWrMoe3x9bnlsADyHpXrACH2zAd3bypolWN3FP91b6r5t xu5zyjinn/vwnucyPFdTP6uwzOieYeyrrvvI8NxXzWuj75U8dpxjLX3uluoBCCegSt+NYN8N VvcmbHieof2r3aVBfXvoPtK3fc04h8f/2LkPb9l3tafcmNaP/Hi3vzVnWnN9+rasOXrfK3n4 iMPfMqgZW82fuCnnfrxXC8BYwgl2Y7lb7SlqjtuXLkscq2/7sfNI3f10v+M+HIE1W9afS411 b3a38Pqc/hp7jvpX3WP7n+tPHABtwgl2w3d8l1B/Vef9bv1ymVGfTPUzZjXWfX0+dp3X8tiz M3YPAMzLm0PAYc17Wzy8z5otp3vOTXDNOQ4v/6vZsj0T1f3flJHXxEPfEdedoXrlJWHTXyHb TESAIzHjBAfUvlnvLhtbep9LHL275759tn+1Zl6o74a1u/0SW9YYzrO9zLG0Lf367Ht8+LXa HcPYKz99nGP31t1nzQjr/4zUbwnwCppSSinl+380TfP1y7oDgm26nq/nb6X9yNvp7fR2un99 u9wut8v0o7g16ePKwNbUJ/p+/+Q+8+/5pb7l8ecMY4ZXVkopP/1y/9pSPQAAgEA4AZvWXSy0 7ngAgNfkZ5yATdvvIh84Nn82gVdjxgkAACAQTgAAAIFwAgAACIQTAABAIJwAAAAC4QQAABB4 O3LYnO6nFZVSSilrjQcAAOEEG9L3uSi3y+1yuzx/PAAA3FmqBwAAEAgnAACAQDgBAAAEwgkA ACAQTgAAAIFwAgAACIQTAABAIJwAAAAC4QQAABAIJwAAgEA4AQAABMIJAAAg+LT2AOAI3k5v p7fT2qMAYFuapmmaZu1RAPMQTjCD2+V2uV3WHgUA23I9X8/Xc/uR94/3j/ePtcYDTGGpHgAA QCCcAAAAAuEEAAAQCCcAAIBAOAEAAATeVQ9YwfvH+8dnb9E7m+v5ev5W1h4FAByZGScAAIDA jBPA30op5adfuo83TdN8/VJKKT+f/vvxPy99jy871lf1f5cfn37zv6fr+Xq+P3L/et2x1fvj 9z9+/+P37uO//vbrb7/+9vzxAFDPjBOwOfeM6YuZJY51//qeSd1tanJouWR65tVYV98Hg7YD qZ1Mzx/hdPdAqskkH5MKsDXCCdiQmoxZ+lg1x23PNS09y9Qez1Hz6R4J1/N/zx31zSnta5bp MferIZ8AtsNSPWATnplMc3nmwrwfiwb/M/u0l6s0rC+ZanTzqWYhXN823S3Hbr/EMrx2Pj12 lQCYixknYGV7TKa77s84Le1Is09LxEB7IVxf0nQzpm/L7u/qS6DhLYfTq4bZJ4AtMOMErGa/ ybSu7uzT7XK7fNvNm1IsN38yPVFqDM8gLTcGs08A6xJOwGr2u/ys/a569/9/5rK9bnDu6yZ6 rgBo/wRU35zSc1Kqbbn3x5NMAOuyVA9Y2RaWn7WPu+UlcEeao6tfftZ9D73nvxF5dwlfTZLV bzlMMgFsQVNKKeX7583v/Z9hWM71fD1/K+1H3k5vp7fvP99yu9wut90slNqC94/3j89N9/Hn h8HwJzj92Gbtz3EavjLd1+e+DIdBN5z6kumxRLnPEXV/b9/j7V+tOfrYGbD29pLpePqe06V+ hs0ny8E0/+/fX+EENYTTvPrC6e5I8yrT1VyNvYfTnUhoczWOSjjBvrT/FfYzTsDmiKW217ka IqHN1QDYGj/jBAAAEJhxAlZwjKVlAMDrMOMEAAAQCCcAAIBAOAEAAATCCQAAIBBOAAAAgXAC AAAIvB05zODt9HZ6O92/bpqmaZp1xwMAwLyEEzzodrldbpfu49fz9Xw9P388AAAsx1I9AACA QDgBAAAEwgkAACAQTgAAAIFwAgAACLyrHlR5/3j/+LzAm4z/fJp/nwAAzM2MEwAAQCCcAAAA AuEEAAAQCCcAAIBAOAEAAATCCQAAIBBOAAAAgXACAAAIhBMAAEAgnAAAAALhBAAAEAgnAACA QDgBAAAEn9YeALy2Py9rjwAAgMyMEwAAQCCcAAAAAuEEAAAQCCcAAIBAOAEAAATCCQAAIBBO AAAAgXACAAAIhBMAAEAgnAAAAALhBAAAEAgnAACAQDgBAAAEwgkAACAQTgAAAIFwAgAACIQT AABAIJwAAAAC4QQAABAIJwAAgEA4AQAABMIJAAAgEE4AAACBcAIAAAiEEwAAQCCcAAAAAuEE AAAQCCcAAIBAOAEAAATCCQAAIBBOAAAAgXACAAAIhBMAAEAgnAAAAALhBAAAEAgnAACAQDgB AAAEwgkAACAQTgAAAIFwAgAACIQTAABAIJwAAAAC4QQAABAIJwAAgEA4AQAABMIJAAAgEE4A AACBcAIAAAiEEwAAQCCcAAAAAuEEAAAQCCcAAIBAOAEAAATCCQAAIBBOAAAAgXACAAAIhBMA AEAgnAAAAALhBAAAEAgnAACAQDgBAAAEwgkAACAQTgAAAIFwAgAACIQTAABAIJwAAAAC4QQA ABAIJwAAgEA4AQAABMIJAAAgEE4AAACBcAIAAAiEEwAAQCCcAAAAAuEEAAAQCCcAAIBAOAEA AATCCQAAIBBOAAAAgXACAAAIhBMAAEAgnAAAAALhBAAAEAgnAACAQDgBAAAEwgkAACAQTgAA AIFwAgAACIQTAABAIJwAAAAC4QQAABAIJwAAgEA4AQAABMIJAAAgEE4AAACBcAIAAAiEEwAA QCCcAAAAAuEEAAAQCCcAAIBAOAEAAATCCQAAIBBOAAAAgXACAAAIhBMAAEAgnAAAAALhBAAA EAgnAACAQDgBAAAEwgkAACAQTgAAAIFwAgAACIQTAABAIJwAAAAC4QQAABAIJwAAgEA4AQAA BMIJAAAgEE4AAACBcAIAAAiEEwAAQCCcAAAAAuEEAAAQCCcAAIBAOAEAAATCCQAAIBBOAAAA gXACAAAIhBMAAEAgnAAAAALhBAAAEAgnAACAQDgBAAAEwgkAACAQTgAAAIFwAgAACIQTAABA IJwAAAAC4QQAABAIJwAAgEA4AQAABMIJAAAgEE4AAACBcAIAAAiEEwAAQCCcAAAAAuEEAAAQ CCcAAIBAOAEAAATCCQAAIBBOAAAAgXACAAAIhBMAAEAgnAAAAALhBAAAEAgnAACAQDgBAAAE wgkAACAQTgAAAIFwAgAACIQTAABAIJwAAAAC4QQAABAIJwAAgEA4AQAABMIJAAAgEE4AAACB cAIAAAiEEwAAQCCcAAAAAuEEAAAQCCcAAIBAOAEAAATCCQAAIBBOAAAAgXACAAAIhBMAAEAg nAAAAALhBAAAEAgnAACAQDgBAAAETSmllLL2MAAAALbLjBMAAEDwb4BSvaHc41+qAAAAAElF TkSuQmCC --------------Kpy14uaX1c1PV87lLjJL1oK2-- From nobody Thu Nov 7 22:41: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 4Xkxs55tR3z5clld for ; Thu, 07 Nov 2024 22:42:01 +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 "E6" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Xkxs528Glz4G1r for ; Thu, 7 Nov 2024 22:42:01 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Authentication-Results: mx1.freebsd.org; none List-Id: Discussions about the use of FreeBSD-current List-Archive: https://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=1731019312; 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=8IuY9wbahtRYmUmrPV8mKEK2ZXB3r9tPSY2seK+ZnD0=; b=nkG+ZNWDHWGooebGOoJN6d/2/kOiO4y7xWzvdPvhGCA7S3ut6sq3d6nFj5/ikqVeua9xSi 0WOrmH787fES7K/L1aNN+KjA+JNPrcCxFYVdsP48PyTyaWcHLDYpGX4QM7MPHc8z5clfBl jpF5JB6ZOE/AlZHNUrArUtRG+btjQZ0zffSPOIjdiGMeKXS2nvY+M2Iq/G0qXvMmpy1c78 UjxLKB4kAvtNCGdP2h8V/D+0hVQl9QMlAHOR/ZmwYSpFIq45zYlVuXz6ZC0kvyhDb+R3vO E19AcgIQhCZ1ffgr+ubK9gTSt5LNYAnGlco0DpzMWW25meap3gLDlHWaf37yBQ== Date: Thu, 07 Nov 2024 23:41:23 +0100 From: Alexander Leidinger To: Warner Losh Cc: Current FreeBSD Subject: Re: No valid device tree blob found! In-Reply-To: References: <8cf9adb0e7ca6340460c695ffd64a0df@Leidinger.net> <896b9ce404ffcb126dcdd6008583b117@Leidinger.net> Message-ID: <132ca9158817a4706d1b9e78c3567973@Leidinger.net> Organization: No organization, this is a private message. Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=_4d9f453636eef0c498b23b37525abefe"; micalg=pgp-sha256 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:34240, ipnet:89.238.64.0/18, country:DE] X-Rspamd-Queue-Id: 4Xkxs528Glz4G1r X-Spamd-Bar: ---- This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --=_4d9f453636eef0c498b23b37525abefe Content-Type: multipart/alternative; boundary="=_9b537057f29aedb8651e4dedd0ab2b26" --=_9b537057f29aedb8651e4dedd0ab2b26 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8; format=flowed Am 2024-11-07 20:59, schrieb Warner Losh: > On Wed, Nov 6, 2024 at 3:41 AM Alexander Leidinger > wrote: > > Am 2024-11-02 17:08, schrieb Warner Losh: > > On Sat, Nov 2, 2024, 10:03 AM Alexander Leidinger > wrote: Am 2024-10-30 22:11, schrieb Alexander > Leidinger: > >> WARNING! Trying to fire up the kernel, but no device tree blob found! > > For anyone interested, I opened > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282493 for this. > > Yea. This is a hang or a bad console. The warning is lame and > misleading. > > Can you bisect? Found it. # git bisect bad c87b3f0006be9ac5813f1ff636f18c9b4a41b08e is the first bad commit commit c87b3f0006be9ac5813f1ff636f18c9b4a41b08e (HEAD) Author: Warner Losh Date: Mon Oct 14 15:58:10 2024 -0600 uart: uart_getenv: check for NULL class last, not first This allows one to specify dt:XXXX when the default class isn't compiled into the kernel. It's not an error to not have a class until we're done parsing the spec, so defer checking until then. Sponsored by: Netflix Reviewed by: adrian, andrew, markj Differential Revision: https://reviews.freebsd.org/D47078 sys/dev/uart/uart_subr.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) -current as of today without this change boots just fine on the Ampere system in the Oracle cloud. what's your loader.conf? this should only matter if something is set there... loader.conf: autoboot_delay="1" hw.usb.no_boot_wait="0" beastie_disable="YES" boot_serial="YES" loader_logo="none" cryptodev_load="YES" xz_load="YES" zfs_load="YES" geom_eli_load="YES" tcphpts_load="yes" tcp_rack_load="YES" hw.mca.enabled="1" vm.exec_map_entries="32" net.link.ifqmaxlen="256" net.inet.tcp.soreceive_stream="1" kern.random.fortuna.concurrent_read="1" kern.msgbuf_show_timestamp="1" Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_9b537057f29aedb8651e4dedd0ab2b26 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Am 2024-11-07 20:59, schrieb Warner Losh:

 

On Wed, Nov 6, 2024 at 3:41=E2=80= =AFAM Alexander Leidinger <Alexander@leidinger.net> wrote:

Am 2024-11-02 17:08, schrieb W= arner Losh:



On Sat, Nov 2, 2024, 10:03=E2=80=AFAM Alexander Leidinger = <Alexander= @leidinger.net> wrote:
Am 2024-10-30 22:11, schrieb Alexander Leidinger:<= br />
> WARNING! Trying to fire up the kernel, but no device tree b= lob found!

For anyone interested, I opened
https://bugs.freebsd.org/bugzilla/show_bug.cgi?i= d=3D282493 for this.
 
Yea. This is a hang or a bad console. The warning is lame= and misleading.
 
Can you bisect?

Found it.

# git bisect bad
c87b3f0006be9ac5813f= 1ff636f18c9b4a41b08e is the first bad commit
commit c87b3f0006be9ac581= 3f1ff636f18c9b4a41b08e (HEAD)
Author: Warner Losh <imp@FreeBSD.org&= gt;
Date:   Mon Oct 14 15:58:10 2024 -0600

    uart: uart_getenv: check for= NULL class last, not first

    This allows one to specify d= t:XXXX when the default class isn't compiled
    into the ke= rnel. It's not an error to not have a class until we're done
  &n= bsp; parsing the spec, so defer checking until then.

    Sponsored by:     =       Netflix
    Reviewed by:     =        adrian, andrew, markj
    Differe= ntial Revision:  https://reviews.freebsd.org/D47078<= /a>

 sys/dev/uart/uart_subr.c | 14 ++++++= +-------
 1 file changed, 7 insertions(+), 7 deletions(-)

-current as of today without this change boots just fine on the Ampere s= ystem in the Oracle cloud.

 
what's your loader.conf? this should only matter if something is set t= here...  

loader.conf:

autoboot_delay=3D"1"
hw.usb.no_boot_w= ait=3D"0"
beastie_disable=3D"YES"
boot_serial=3D"YES"
loader= _logo=3D"none"
cryptodev_load=3D"YES"
xz_load=3D"YES"
zfs_lo= ad=3D"YES"
geom_eli_load=3D"YES"

tcphpts_load=3D"yes"
tcp_rack_load=3D= "YES"

hw.mca.enabled=3D"1"
vm.exec_map_entr= ies=3D"32"

net.link.ifqmaxlen=3D"256"
net.inet.t= cp.soreceive_stream=3D"1"
kern.random.fortuna.concurrent_read=3D"1"kern.msgbuf_show_timestamp=3D"1"

Bye,
Alexander.

 --=_9b537057f29aedb8651e4dedd0ab2b26-- --=_4d9f453636eef0c498b23b37525abefe Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc; size=833 Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIyBAEBCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmctQiQACgkQEg2wmwP4 2IY7eQ/yAj1SrxNp1OnbxNTBvvgNjnEZgwnRGnztAUDXWb6F1whXNZbQMb0md5DF B8RSRxsqzxhr1B+YuoUq30CZ4r3MEcTVVbUUakCyQk3b52FSg52e84HXQHoVL/qE 2UQ/H2TLk2PGwJDfvctiZx63b+brLnuMJX/s9nqHxOY/eyOVEm7F9ZV25peP1Slk U0bLE4g58GaxIlWF/mt8AEm2Yr8rE6l9FJ+rwP+43J11EEWMOUrADwwBbexuQRE+ EsrfI8RDeRGPj7p694lIuURgPlatr9EDtmcuZ+F21bCAmX1VEodMqezADaLz0mb6 G8qmOhvAVS8HBxTHpE+RPcYuI/Ubp8Ej9XTHpxVKQuXZJ3SAGq3P82AR20uPfPI9 ljQMJRc3PKAuf9XJ9ndhl6UsO4Vy+WKshE2bTkQwxlArXUq1FDTkc0f2fEKqVYUM 8xWxJklRwi01mKvxzUCxjnIiUtfkYauQI//eB8AngOZHVK/NBpaZ1mUTh3B8ggDF r4MOa2YvpPbECEdjABzhr5TyxNFpb+JnYMCOw1hKIZ4oB8nYFWrjMhr1X9aOtvbN mcgLfM92RvX23byPafMMA6kv8OfDr2QAUFbB85RxGDNBm6BtyIyiP2mNhDdMeq6p xVfMh1qEdKtlQvYc5+hJmp9TjyZz7LcZHvT+I4i10RXWwGQb3w== =IsYD -----END PGP SIGNATURE----- --=_4d9f453636eef0c498b23b37525abefe-- From nobody Fri Nov 8 01:43:18 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 4Xl1td0P4Nz5bnMt for ; Fri, 08 Nov 2024 01:43:37 +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 4Xl1tb2qQRz4bmk for ; Fri, 8 Nov 2024 01:43:35 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=mPoi7Cjl; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1731030213; bh=kWrd/Ti62OdmSi7tOJTRqeKC7rbBC6/CsgG9G+TUlYo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=mPoi7CjlifVcADNUrvPgfFoqfUg7UvLwbD3RygdnFCQEKhObqnDQs+vd0C0F6AQIJp4I1vGhZdl2e+/HOHWD12GtDkfqzHpIUfD7WJAvH5pXuQDHADI1CZBER1fx3ozBKXQuEy8kCBuNHkqctA1MNGEC8/4QOg4DrT0N9BpFXRX5hDi2QejZDIFiXMqoPZ8Ls8AsHp5pIujzkNoOKl9abn+G0QjMHXZN40Pvn/RNTJoU0BxdAVyfVTcG03sijJUqRV1XXbykxObPAVg7oec1+3RwzS058yUWVz19vn5fzV4k1XKHaefDC8UFUFn6Q1ryqB69UGL4d8ZbYZDajKQiYg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1731030213; bh=9h/q/TtNFDvmePiZr2zHzm6m4hV0tAkSJQIovwH+sxQ=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=iKYXantxHMnKqux3D3UQV0i3Aumb/jF3etmfzzqERTQW6I0GSHT9kup+1UufP8KTQdMnoh77IUGvuhq5CVl5/JBxhfOWdSY2gH9vJPSbtYXhYXpB68Q7HSsIMHLzLx1ieLBpor/WsaQ3fb92NFK27CgWIUOGbNwJogtn5Zfpw/1x9Dx2rJkkUTmYjzVz0NonTms3E76XFyNUfyif5KLMJYf/DvXeaeryUXD1+gGHlSTSm9UrdKrkLiRHi+lufoGnw/wHj4GmVsxdyA7F8dTqxx9QluHCXpXwkuL3ilvT1uiK0Htb16t7NH4YjVE7rnxTxbE0x/OYHa0ODrluswLngQ== X-YMail-OSG: wnt9BdMVM1lrHAcj.bz3zsE.FNXzYfKd_JDQZn5LdDR0Ex1XmPczLcMNkRD4Q.h 0lK.Ef2eaJKX4lqXRMjOGEmSfHegy.3clpwzOKqt91wKa.UN.I2kJtb0StSsjpY9prSwgeTCJRST ZAo8rH34ThLbTDqeGun8aDMPx_5VmqfuXIZU.cURPcvXVA4LSQMkyo1dCUifnT2Ut1DZNSbHhc0I htnCPCgmLVJ_AEdk4IeHyv.vDiIL_dTO15IAn_.H5KiosvbRaPyM3M3T5V__Et4QLAP6PYc2spMY o9xE0Y36AbAMgP9stQ4CDbEefeASFZkSBIhLtmQ1fQdlxCOtJo44w6UCT_GtGC3VkhkNnc_83CM9 bYfoaYtn60dlbVQb7HTy17zsRWPb81l1Rv6gkD56uMbjAo6TeSxzLVXN71MGpzNrhPashZOnxEic aW3wy9Rg_g0B6LR47Zzu4wmydoA783RRI6siiZOEPxsuhpV6JbRelcHaKC_PtuSmO6TuUQ.eVgJY WvBRPTSzIruHTyAPJPQMp1jZNUG81OBU8UnfmCw9.vmsc99V18utP9ensbwr_U3FYuOyiQh8.os4 jdeOkSgsZzIoIn28YKJDkrdlXS4WKZK3VPkY2_CXGFk6aoqGOe2A1WCaaSGejHB.Mitp.3quGwcx MIc140N4_Op_3YAzKPKnNBVVtxXKLbWOkmYeEVTnphitkV7HfpyuyAW41.LQU_tNN301DWYv0ZRL 8MTMEpYyLuU6bxmuVuI8NqqQUa73ikEn79N5yWbunLLIyuwCEGLqUJE0AmZLOMdpZphwIMCb7WP. pH.29LQz_L5_GcQg_USqHsVsT3vZXzp97LXztWufv9FgziFXHIHzp3Qv50kSmsS42aTs46HV6ihi IQcHvrannbUFxX57SqK9zQ0SdiWlRkGmxglq2ix1QDYczdd8h2WzVzk28ga1XEzfj38tSgQUaIPH 8nHTeJh6ZQAvs8Ekx3uXKbbD5wfcZ23f2MOwAABAEQY2p33t1_zxWDEcVU01nBR.STKS0OPi1pWb re1X_gC8IyvKnsLPn8T7bdakc3gqlgqUUnxWy2nilp3G3Rtjs9LFIcq_Yj.36.FUYYvn0KR8fyr5 Eq6cFnCd4SPnB871ruB.z1NNSZTJ7cRrH_BlxScISRCcVYYSNcqeTyLqguPDrwrY74yFxgFUc6YU 8_4VJKW1mKVX8CmUAUpNfNQn7wUSSIWro1NGOLp1_cnFn.1Oby87e6Q0V23Yp8EuoSQanhtW8d13 jrLKPsOmGv1dGp.pD86ctJQjD_rbq6UEksbe72a.o4B1lAJN_oKmiqFNWtDa_zWiRTwd2JZUo21e 1rWE8AGvN_BJspcdOQGRj7vLACTIsgiwzARJsE94HrcDOnDT.R3FafGQfSwnNaxp9JTFCbGjMyaI 8cYcuR18YUzpvJ4D4NZnV8YyBcVz_gToNJIpbzQ5DxIjVDYq0qDW05iVa.6gugFKZX_2fOJY8DuY cx0Ffw6U1SFTCdSWe.XAm2GSzudsfwSUW8TrKtfY_hPaO4xzTjYcLnFtz98mU8WOjmYUKMeIHNPE KdvEgygc9gQnbj6dmqJgL5luAoNyhXdnpz0id7bO1EZbmzYX30pvnJsbBB7lA140D_fAHE7HCsu0 OBwTYkjtfYvosDH0AoOPXUjLDulrAOARjap.X6iA5O3odyVuH.AaW3cNhuntoMxCpXqyUFqGkEL3 TuwAKezOL0otk2Ke2X1JbQ_oN20L5.M0pyX3rA3kIj1uVxtJv9UVtW9vEpxzTB6_P5WaHkTgKKe. p8Hela8suyxYocGqukF.ms4XcQYrS5P05RAKC7oPQ6v34KGFlTGSo_Y2sLzaEpz_W76El0tmvQCr YGyfLu065pwP8HvD2fivFeQDdcqFMFKGr9joLcvVj_mtuTXlrYlQYAw9c7E8PuQa.CxKrHeL6rS4 J1aDrySqwTcMF3QsuyjPrqYtLPbAAWDoEg2F3.r_QoLrJcSY7Nbf_8bhtTssdJfBm_hTLqwN7Qm7 YQj7xGGLAOMEsrdu1zXNePCNH142kCb8YtcW0bYz7eT0dX.BjGdo8FgQr3UvMf8RhCJ8Wbj7.gAF T3vDjWtV..GS2Wvie9jTC6vHqX2KdxRUpOXnTy_ve0aukxM5hWDQsR6mu8XooNhlKAbh.9PZcaHL Djxw1hpN4KZ0tdgwCgMVcahQC5ewV5Cp5EdiPB6gx__C2sdQAX8qfDeXLzwLeABvRSkRwh6lJGFq XLSYRZfat6Y118wpMbiy2ip3b2UWhILf7rSHYihvS.57HpKVbgtoKbNOXP1kulWlEsJmC.KMdATx 4EGW08hynD5UFDfnV X-Sonic-MF: X-Sonic-ID: 86c5c851-98c2-402a-bea5-9d0a5c9c9db5 Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Fri, 8 Nov 2024 01:43:33 +0000 Received: by hermes--production-gq1-5dd4b47f46-5qmz7 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 6b4df5938a207403316ddc228b6131ee; Fri, 08 Nov 2024 01:43:29 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51\)) Subject: Re: Official armv7 PkgBase kernel-NODEBUG installation's USB2 boot gets "Fatal kernel mode data abort: 'Alignment Fault' on write" very early, at least on an OrangePi+ 2ed From: Mark Millard In-Reply-To: Date: Thu, 7 Nov 2024 17:43:18 -0800 Cc: Dimitry Andric Content-Transfer-Encoding: quoted-printable Message-Id: <74468E62-5A74-4FB4-94F6-599E5BA3A9A1@yahoo.com> References: To: FreeBSD ARM List , Current FreeBSD , FreeBSD Toolchain X-Mailer: Apple Mail (2.3776.700.51) X-Spamd-Result: default: False [-3.90 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.90)[-0.905]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; DKIM_TRACE(0.00)[yahoo.com:+]; TO_DN_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_THREE(0.00)[4]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.206:from]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.206:from] X-Rspamd-Queue-Id: 4Xl1tb2qQRz4bmk X-Spamd-Bar: --- [The change to LLVM 19 is what leads to the Alignment Fault' on write failure. Details later below.] On Nov 7, 2024, at 01:42, Mark Millard wrote: > Note: Unfortunately, the panics here are too early for a > dump device to be available. >=20 > Context started PkgBase upgrade from: >=20 > # uname -apKU > FreeBSD OPiP2E-RPi2v1p1 15.0-CURRENT FreeBSD 15.0-CURRENT = main-n272821-37798b1d5dd1 GENERIC-NODEBUG arm armv7 1500025 1500025 >=20 > Installed packages to be UPGRADED: > FreeBSD-dtb: 15.snap20241009161500 -> 15.snap20241028121139 = [base] > FreeBSD-kernel-generic: 15.snap20241011221604 -> = 15.snap20241106134422 [base] > FreeBSD-kernel-generic-dbg: 15.snap20241011221604 -> = 15.snap20241106134422 [base] > FreeBSD-kernel-generic-mmccam: 15.snap20241011221604 -> = 15.snap20241106134422 [base] > FreeBSD-kernel-generic-mmccam-dbg: 15.snap20241011221604 -> = 15.snap20241106134422 [base] > FreeBSD-kernel-generic-nodebug: 15.snap20241011221604 -> = 15.snap20241106134422 [base] > FreeBSD-kernel-generic-nodebug-dbg: 15.snap20241011221604 -> = 15.snap20241106134422 [base] > FreeBSD-src-sys: 15.snap20241011221604 -> 15.snap20241106160110 = [base] >=20 > (Those were installed but the FreeBSD-dtb had linux 6.4 > dtb files, not the 6.8 ones. 6.8 ones from a personal build > were copied to where they need to be. I've separately > reported the 6.4 vs. 6.8 issue.) >=20 > # ~/pkgbase-snapshot-list.sh > Via pkg-static info -C -x '^FreeBSD-' . . . > 1 FreeBSD-*-15.snap20241106160110 > 6 FreeBSD-*-15.snap20241106134422 > 1 FreeBSD-*-15.snap20241028121139 > 3 FreeBSD-*-15.snap20241011221604 > 2 FreeBSD-*-15.snap20241011210446 > 38 FreeBSD-*-15.snap20241011182434 > 4 FreeBSD-*-15.snap20241011073851 > 5 FreeBSD-*-15.snap20241010141501 > 1 FreeBSD-*-15.snap20241010120743 > 296 FreeBSD-*-15.snap20241009161500 > Instead via /var/cache/pkg/*.snap*.pkg . . . > 1 FreeBSD-*-15.snap20241106160110 > 6 FreeBSD-*-15.snap20241106134422 > 1 FreeBSD-*-15.snap20241028121139 > 10 FreeBSD-*-15.snap20241011221604 > 2 FreeBSD-*-15.snap20241011210446 > 38 FreeBSD-*-15.snap20241011182434 > 4 FreeBSD-*-15.snap20241011073851 > 5 FreeBSD-*-15.snap20241010141501 > 1 FreeBSD-*-15.snap20241010120743 > 297 FreeBSD-*-15.snap20241009161500 >=20 >=20 > The failure (kernel-GENERIC-NODEBUG): >=20 > . . . > Root mount waiting for: usbus3 CAM > Fatal kernel mode data abort: 'Alignment Fault' on write > trapframe: 0xc6c9ac10 > FSR=3D00000801, FAR=3Ddb23209b, spsr=3D20000013 > r0 =3Ddb232080, r1 =3D00000000, r2 =3D00000006, r3 =3D00000024 > r4 =3Ddb19e280, r5 =3D00000000, r6 =3D00000001, r7 =3D00000006 > r8 =3Dc6c9ad20, r9 =3Dc0b7973c, r10=3Dc092074c, r11=3Dc6c9acb8 > r12=3D00000000, ssp=3Dc6c9aca0, slr=3Dc01b01d8, pc =3Dc01aff88 >=20 > panic: Fatal abort > cpuid =3D 1 > time =3D 3 > KDB: stack backtrace: > db_trace_self() at db_trace_self > pc =3D 0xc0667004 lr =3D 0xc0078630 = (db_trace_self_wrapper+0x30) > sp =3D 0xc6c9a9c8 fp =3D 0xc6c9aae0 > db_trace_self_wrapper() at db_trace_self_wrapper+0x30 > pc =3D 0xc0078630 lr =3D 0xc0328db8 (vpanic+0x140) > sp =3D 0xc6c9aae8 fp =3D 0xc6c9ab08 > r4 =3D 0x00000100 r5 =3D 0x00000000 > r6 =3D 0xc084d1f1 r7 =3D 0xc0b69a94 > vpanic() at vpanic+0x140 > pc =3D 0xc0328db8 lr =3D 0xc0328c78 (vpanic) > sp =3D 0xc6c9ab10 fp =3D 0xc6c9ab14 > r4 =3D 0xc6c9ac10 r5 =3D 0x00000013 > r6 =3D 0xdb23209b r7 =3D 0x00000001 > r8 =3D 0x00000801 r9 =3D 0x00000013 > r10 =3D 0xdb23209b > vpanic() at vpanic > pc =3D 0xc0328c78 lr =3D 0xc068c8e8 (abort_align) > sp =3D 0xc6c9ab1c fp =3D 0xc6c9ab48 > r4 =3D 0x00000001 r5 =3D 0x00000801 > r6 =3D 0x00000013 r7 =3D 0xdb23209b > r8 =3D 0xc6c9ab14 r9 =3D 0xc0328c78 > r10 =3D 0xc6c9ab1c > abort_align() at abort_align > pc =3D 0xc068c8e8 lr =3D 0xc068c958 (abort_align+0x70) > sp =3D 0xc6c9ab50 fp =3D 0xc6c9ab68 > r4 =3D 0xc6d21c00 r10 =3D 0xdb23209b > abort_align() at abort_align+0x70 > pc =3D 0xc068c958 lr =3D 0xc068c5e0 (abort_handler+0x430) > sp =3D 0xc6c9ab70 fp =3D 0xc6c9ac08 > r4 =3D 0x00000000 r10 =3D 0xdb23209b > abort_handler() at abort_handler+0x430 > pc =3D 0xc068c5e0 lr =3D 0xc0669868 (exception_exit) > sp =3D 0xc6c9ac10 fp =3D 0xc6c9acb8 > r4 =3D 0xdb19e280 r5 =3D 0x00000000 > r6 =3D 0x00000001 r7 =3D 0x00000006 > r8 =3D 0xc6c9ad20 r9 =3D 0xc0b7973c > r10 =3D 0xc092074c > exception_exit() at exception_exit > pc =3D 0xc0669868 lr =3D 0xc01b01d8 (usb_msc_auto_quirk+0xfc) > sp =3D 0xc6c9aca0 fp =3D 0xc6c9acb8 > r0 =3D 0xdb232080 r1 =3D 0x00000000 > r2 =3D 0x00000006 r3 =3D 0x00000024 > r4 =3D 0xdb19e280 r5 =3D 0x00000000 > r6 =3D 0x00000001 r7 =3D 0x00000006 > r8 =3D 0xc6c9ad20 r9 =3D 0xc0b7973c > r10 =3D 0xc092074c r12 =3D 0x00000000 > bbb_command_start() at bbb_command_start+0x4c > pc =3D 0xc01aff88 lr =3D 0xc01b01d8 (usb_msc_auto_quirk+0xfc) > sp =3D 0xc6c9acc0 fp =3D 0xc6c9acf8 > r4 =3D 0xdb16d800 r5 =3D 0xdb19e280 > r6 =3D 0x00000001 r10 =3D 0xc092074c > usb_msc_auto_quirk() at usb_msc_auto_quirk+0xfc > pc =3D 0xc01b01d8 lr =3D 0xc01a4bd8 (usb_alloc_device+0x9c4) > sp =3D 0xc6c9ad00 fp =3D 0xc6c9ad68 > r4 =3D 0x00000000 r5 =3D 0x00000001 > r6 =3D 0x00000000 r7 =3D 0x00000002 > r8 =3D 0xdb16d800 r9 =3D 0xda241c78 > r10 =3D 0x000003ee > usb_alloc_device() at usb_alloc_device+0x9c4 > pc =3D 0xc01a4bd8 lr =3D 0xc01ad16c (uhub_explore+0x494) > sp =3D 0xc6c9ad70 fp =3D 0xc6c9adc0 > r4 =3D 0x00000000 r5 =3D 0x00000000 > r6 =3D 0xdb16e800 r7 =3D 0x00000000 > r8 =3D 0xdb18c200 r9 =3D 0x00000001 > r10 =3D 0x00000000 > uhub_explore() at uhub_explore+0x494 > pc =3D 0xc01ad16c lr =3D 0xc0198654 (usb_bus_explore+0x1d4) > sp =3D 0xc6c9adc8 fp =3D 0xc6c9add8 > r4 =3D 0xda241c78 r5 =3D 0xdb16e800 > r6 =3D 0x00000000 r7 =3D 0xda241d6c > r8 =3D 0xc09b0b5f r9 =3D 0x00000001 > r10 =3D 0xda241d1c > usb_bus_explore() at usb_bus_explore+0x1d4 > pc =3D 0xc0198654 lr =3D 0xc01b22d0 (usb_process+0x124) > sp =3D 0xc6c9ade0 fp =3D 0xc6c9ae10 > r4 =3D 0xda241d0c r5 =3D 0xda241d14 > usb_process() at usb_process+0x124 > pc =3D 0xc01b22d0 lr =3D 0xc02da4f0 (fork_exit+0xb0) > sp =3D 0xc6c9ae18 fp =3D 0xc6c9ae38 > r4 =3D 0xc6c9ae40 r5 =3D 0xc6d21c00 > r6 =3D 0xc6d08740 r7 =3D 0xda241d0c > r8 =3D 0xc01b21ac r9 =3D 0x00000000 > r10 =3D 0x00000000 > fork_exit() at fork_exit+0xb0 > pc =3D 0xc02da4f0 lr =3D 0xc06697fc (swi_exit) > sp =3D 0xc6c9ae40 fp =3D 0x00000000 > r4 =3D 0xc01b21ac r5 =3D 0xda241d0c > r6 =3D 0x00000000 r7 =3D 0x00000000 > r8 =3D 0x00000000 r10 =3D 0x00000000 > swi_exit() at swi_exit > pc =3D 0xc06697fc lr =3D 0xc06697fc (swi_exit) > sp =3D 0xc6c9ae40 fp =3D 0x00000000 > KDB: enter: panic > [ thread pid 14 tid 100069 ] > Stopped at kdb_enter+0x54: ldrb r15, [r15, r15, ror r15]! > db> Using just available official artifact kernels for testing I've established that 0953460ce149 (and various from before that) does not have the problem:=20 Wed, 23 Oct 2024 =E2=80=A2 git: 5c92f84bb607 - main - LinuxKPI: update = rcu_dereference_*() and lockdep_is_held() Bjoern A. Zeeb =E2=80=A2 git: 6fa91acca40d - main - conf/NOTES: Remove trailing = whitespace Li-Wen Hsu=20 =E2=80=A2 git: 91b7b225b2ce - main - LINT: Add mac_do Li-Wen Hsu=20 =E2=80=A2 git: 419249c1cacc - main - Revert "LINT: Add mac_do" = Li-Wen Hsu=20 =E2=80=A2 Re: git: 419249c1cacc - main - Revert "LINT: Add mac_do" = Baptiste Daroussin=20 =E2=80=A2 Re: git: 13da1af1cd67 - main - libcxxrt: Update to = upstream 698997bfde1f John Baldwin=20 =E2=80=A2 Re: git: 419249c1cacc - main - Revert "LINT: Add mac_do" = John Baldwin=20 =E2=80=A2 git: 0953460ce149 - main - libc: fix access mode tests in = fmemopen(3) Ed Maste So the above one worked. The next available kernel to test was f3dbef108212 (the bump for LLVM19 at the end of the below): =E2=80=A2 RE: git: 6a07e67fb7a8 - main - vm_meter: Fix laundry = accounting Mark Millard=20 =E2=80=A2 git: 6b9f7133aba4 - main - libc: Add one more check in new = fmemopen test Ed Maste=20 =E2=80=A2 git: 0fca6ea1d4ee - main - Merge llvm-project main = llvmorg-19-init-18630-gf2ccf80136a0 Dimitry Andric=20 =E2=80=A2 git: 36b606ae6aa4 - main - Merge llvm-project release/19.x = llvmorg-19.1.0-rc1-0-ga4902a36d5c2 Dimitry Andric=20 =E2=80=A2 git: 3f157662c0ef - main - Tentatively apply = https://github.com/llvm/llvm-project/pull/101403 Dimitry Andric=20 =E2=80=A2 git: d575077527d4 - main - bsd.sys.mk: for clang >=3D 19, = similar to gcc >=3D 8.1, turn off -Werror for = -Wcast-function-type-mismatch. Dimitry Andric=20 =E2=80=A2 git: 36d486cc2ecd - main - Fix enum warning in ath_hal's = ar9002 Dimitry Andric=20 =E2=80=A2 git: 6846ab2fb663 - main - libcxx simd_utils.h: only = enable _LIBCPP_HAS_ALGORITHM_VECTOR_UTILS for clang >=3D 15, since older = versions do not support the required builtins. Dimitry Andric=20 =E2=80=A2 git: 81e300df5e65 - main - libcxx atomic_ref.h: add = typename keyword for difference_type declarations, otherwise older clang = versions cannot compile this header. Dimitry Andric=20 =E2=80=A2 git: 6b4981df6008 - main - libcxx cstdlib, cwchar: avoid = using long long functions if not supported, even for older compilers = that do not support the using_if_exists attribute. Dimitry Andric=20 =E2=80=A2 git: 2f6d6eaf2d51 - main - libcxx-compat: revert = llvmorg-19-init-18063-g561246e90282: Dimitry Andric=20 =E2=80=A2 git: 04f5b79cfa49 - main - libcxx-compat: revert = llvmorg-19-init-18062-g4dfa75c663e5: Dimitry Andric=20 =E2=80=A2 git: e8054e44f4ca - main - libcxx-compat: revert = llvmorg-19-init-17853-g578c6191eff7: Dimitry Andric=20 =E2=80=A2 git: 0bec0529b1d7 - main - libcxx-compat: revert = llvmorg-19-init-17728-g30cc12cd818d: Dimitry Andric=20 =E2=80=A2 git: e8847079df1b - main - libcxx-compat: revert = llvmorg-19-init-17727-g0eebb48fcfbc: Dimitry Andric=20 =E2=80=A2 git: 2f2ebe758bea - main - libcxx-compat: revert = llvmorg-19-init-17473-g69fecaa1a455: Dimitry Andric=20 =E2=80=A2 git: 1199d38d8ec7 - main - libcxx-compat: revert = llvmorg-19-init-8667-g472b612ccbed: Dimitry Andric=20 =E2=80=A2 git: a7b2d7f261b8 - main - libcxx-compat: revert = llvmorg-19-init-5639-ga10aa4485e83: Dimitry Andric=20 =E2=80=A2 git: f3859a1a13a1 - main - libcxx-compat: revert = llvmorg-19-init-4504-g937a5396cf3e: Dimitry Andric=20 =E2=80=A2 git: 072b5fb698ab - main - libcxx-compat: revert = llvmorg-19-init-4003-g55357160d0e1: Dimitry Andric=20 =E2=80=A2 git: b60301d8b594 - main - libcxx-compat: don't remove = headers that were reintroduced by reverts Dimitry Andric=20 =E2=80=A2 git: 2e861daab905 - main - libcxx-compat: install headers = that were reintroduced by reverts Dimitry Andric=20 =E2=80=A2 git: ff6c8447844b - main - libcxx-compat: update = libcxx.imp for headers that were reintroduced by reverts Dimitry Andric=20= =E2=80=A2 git: 52418fc2be8e - main - Merge llvm-project release/19.x = llvmorg-19.1.0-rc2-0-gd033ae172d1c Dimitry Andric=20 =E2=80=A2 git: 62987288060f - main - Merge llvm-project release/19.x = llvmorg-19.1.0-rc3-0-g437434df21d8 Dimitry Andric=20 =E2=80=A2 git: 6c4b055cfb6b - main - Merge llvm-project release/19.x = llvmorg-19.1.0-rc4-0-g0c641568515a Dimitry Andric=20 =E2=80=A2 git: 835c3a3e69af - main - Merge commit 6dbdb8430b49 from = llvm git (by Nikolas Klauser): Dimitry Andric=20 =E2=80=A2 git: c80e69b00d97 - main - Merge llvm-project release/19.x = llvmorg-19.1.0-0-ga4bf6cd7cfb1 Dimitry Andric=20 =E2=80=A2 git: 6e516c87b6d7 - main - Merge llvm-project release/19.x = llvmorg-19.1.1-0-gd401987fe349 Dimitry Andric=20 =E2=80=A2 git: 5deeebd8c6ca - main - Merge llvm-project release/19.x = llvmorg-19.1.2-0-g7ba7d8e2f7b6 Dimitry Andric=20 =E2=80=A2 git: f3dbef108212 - main - Bump __FreeBSD_version for llvm = 19.1.2 merge Dimitry Andric=20 f3dbef108212 gets the: "Fatal kernel mode data abort: 'Alignment Fault' on write" boot failure for artifact kernel. 6b9f7133aba4 does nit seem a likely source of the problem, basically leaving the LLVM changes as what is at issue. I'll note that artifact kernels are witness kernels. So this exploration adds to the distinctions observed compared to the prior notes. > Looking at bbb_command_start() 's pc: >=20 > # llvm-addr2line -e /boot/kernel.GENERIC-NODEBUG/kernel 0xc01aff88 > /home/pkgbuild/worktrees/main/sys/dev/usb/usb_msctest.c:554 >=20 > What leads to that line is: >=20 > = /*------------------------------------------------------------------------= * > * bbb_command_start - execute a SCSI command synchronously =20 > * =20 > * Return values > * 0: Success > * Else: Failure > = *------------------------------------------------------------------------*= / > static int > bbb_command_start(struct bbb_transfer *sc, uint8_t dir, uint8_t lun, = =20 > void *data_ptr, size_t data_len, void *cmd_ptr, size_t cmd_len, > usb_timeout_t data_timeout) > { > sc->lun =3D lun; > sc->dir =3D data_len ? dir : DIR_NONE; > sc->data_ptr =3D data_ptr; > sc->data_len =3D data_len; > sc->data_rem =3D data_len; > sc->data_timeout =3D (data_timeout + USB_MS_HZ); > sc->actlen =3D 0; > sc->error =3D 0; > sc->cmd_len =3D cmd_len; > memset(&sc->cbw->CBWCDB, 0, sizeof(sc->cbw->CBWCDB)); >=20 > The memset line is line 554 of sys/dev/usb/usb_msctest.c . The below looks to be a separate problem based on some later FreeBSD kernel update than the above. > I'll note that attempting to use the WITNESS variant of the kernel > ( /boot/kernel/ ) gets a different, even earlier failure: >=20 > . . . > VT: init without driver. > panic: acquiring blockable sleep lock with spinlock or critical = section held (sleep mutex) pmap @ = /home/pkgbuild/worktrees/main/sys/arm/arm/pmap-v6.c:6455 I do know that d021d3b3c675 at the end of the below shows this failure --before the system has a chance to get the usb related write alignment failure reported above. I have not explored where in the below range the behavior changes (for what is available as an official artifact kernel). It seems unlikely that any of the below would actually boot: it is likely a question of which of the 2 (or more) failure types happen for each instead. Thu, 24 Oct 2024 =E2=80=A2 git: 34951b0b9e78 - main - swap_pager: move = scan_all_shadowed, use iterators Doug Moore=20 =E2=80=A2 git: 2ac21f2c98ed - main - x86 specialreg.h: visually = align %cr4 and MSR_EFER bit mask definitions Konstantin Belousov=20 =E2=80=A2 git: cc11bc1150d5 - main - x86 specialreg.h: add all = defined bits for %cr4 Konstantin Belousov=20 =E2=80=A2 git: cc4b25f10211 - main - x86 specialreg: reorder %cr3 = bits masks definitions by value Konstantin Belousov=20 =E2=80=A2 git: 5999b74e9637 - main - x86 specialreg: add bit masks = definitions for LAM in %cr3 Konstantin Belousov=20 =E2=80=A2 git: 6308db659f2a - main - x86 specialreg: add bit masks = definitions for EFER features Konstantin Belousov=20 =E2=80=A2 git: 9f718b57b846 - main - x86 specialreg: add bit masks = definitions for LASS and LAM features Konstantin Belousov=20 =E2=80=A2 git: 3360a15898ce - main - net: route: convert routing = statistics to a sysctl Kyle Evans=20 =E2=80=A2 Re: git: 3360a15898ce - main - net: route: convert routing = statistics to a sysctl Kyle Evans=20 =E2=80=A2 git: 77b70ad751df - main - e1000: Move I219 LM19/V19 to = ADL Kevin Bowling=20 =E2=80=A2 git: d64442a89896 - main - arm{,64}: use genassym for = INTR_ROOT_* values Kyle Evans=20 =E2=80=A2 git: 536c8d948e85 - main - intrng: change multi-interrupt = root support type to enum Kyle Evans=20 =E2=80=A2 git: 4f12b529f404 - main - sys/intr.h: formally depend on = machine/intr.h Kyle Evans=20 =E2=80=A2 git: a5b1eecbed07 - main - Apply workaround for building = llvm-project with WITHOUT_LLVM_ASSERTIONS Dimitry Andric=20 =E2=80=A2 git: 1c83996beda7 - main - Adjust = LLVM_ENABLE_ABI_BREAKING_CHECKS depending on NDEBUG Dimitry Andric=20 =E2=80=A2 git: b2dd4970c7b5 - main - dev/gpio: Mask all pl011 = interrupts Andrew Turner=20 =E2=80=A2 git: 3b03e1bb8615 - main - intrng: Store the IPI priority = Andrew Turner=20 =E2=80=A2 git: 6204391e99ca - main - arm64: Check TDP_NOFAULTING in = a data abort Andrew Turner=20 =E2=80=A2 git: a84653c5db25 - main - arm64: Don't enable interrupts = when in a spinlock Andrew Turner=20 =E2=80=A2 git: d7f930b80e89 - main - arm64: Implement = efi_rt_arch_call Andrew Turner=20 =E2=80=A2 git: 8efb1500d4f1 - main - arm64: Enable handling EFI = runtime service faults Andrew Turner=20 =E2=80=A2 git: 9693241188aa - main - sound: Call DSP_REGISTERED = before PCM_DETACHING Christos Margiolis=20 =E2=80=A2 git: bb5e3ac1a7b7 - main - sound: Use DSP_REGISTERED in = dsp_clone() Christos Margiolis=20 =E2=80=A2 git: a4111e9dc722 - main - sound: Change PCMDIR_* = numbering Christos Margiolis=20 =E2=80=A2 git: 802c78f5194e - main - sound: Untangle dsp_cdevs[] and = dsp_unit2name() confusion Christos Margiolis=20 =E2=80=A2 git: b1bb6934bb87 - main - sound: Fix build error in = chm_mkname() KASSERT Christos Margiolis=20 =E2=80=A2 git: ce20b48a60fb - main - sctp: improve debug output = Michael Tuexen=20 =E2=80=A2 git: e4ac0183a1a8 - main - sctp: cleanup Michael Tuexen=20 =E2=80=A2 git: 8c8ebbb04518 - main - bhyve ahci: Improve robustness = of TRIM handling John Baldwin=20 =E2=80=A2 git: f0bc751d6fb4 - main - csa: Use pci_find_device to = simplify clkrun_hack John Baldwin=20 =E2=80=A2 git: d96ba5a62365 - main - config: Remove a stray = semicolon Zhenlei Huang=20 =E2=80=A2 git: 56b17de1e836 - main - makefs: Remove a stray = semicolon Zhenlei Huang=20 =E2=80=A2 git: 88b71d1fe054 - main - arm64: rockchip: Remove a stray = semicolon Zhenlei Huang=20 =E2=80=A2 git: b4856b8e9d87 - main - LinuxKPI: Remove stray = semicolons Zhenlei Huang=20 =E2=80=A2 git: 75ff90814aec - main - enic: Remove a stray semicolon = Zhenlei Huang=20 =E2=80=A2 git: 6ccf4f4071c5 - main - mana: Remove stray semicolons = Zhenlei Huang=20 =E2=80=A2 git: 86a2c910c05c - main - mpi3mr: Remove a stray = semicolon Zhenlei Huang=20 =E2=80=A2 git: 36756195a342 - main - ocs_fc: Remove a stray = semicolon Zhenlei Huang=20 =E2=80=A2 git: 2f395cfda8b5 - main - tcp cc: Remove a stray = semicolon Zhenlei Huang=20 =E2=80=A2 git: f3a097d0312c - main - netstat: switch to using the = sysctl-exported stats for live stats Kyle Evans=20 =E2=80=A2 git: 656991b0c629 - main - locks: augment lock_class with = lc_trylock method Gleb Smirnoff=20 =E2=80=A2 git: efcb2ec8cb81 - main - callout: provide = CALLOUT_TRYLOCK flag Gleb Smirnoff=20 =E2=80=A2 git: bffebc336f4e - main - tcp: use CALLOUT_TRYLOCK for = the TCP callout Gleb Smirnoff=20 =E2=80=A2 git: d021d3b3c675 - main - tcp: get rid of = TDP_INTCPCALLOUT Gleb Smirnoff=20 > cpuid =3D 0 > time =3D 1 > KDB: stack backtrace: > Fatal kernel mode data abort: 'Translation Fault (L1)' on read > trapframe: 0xc0f14568 > FSR=3D00000005, FAR=3Ddb7fcfb1, spsr=3D200001d3 > r0 =3Dc0f1465c, r1 =3D00000001, r2 =3Ddb7fcfae, r3 =3D1b000a4e > r4 =3Dc07fc55c, r5 =3D8fce1b89, r6 =3D00006f3e, r7 =3D81000000 > r8 =3Dc07c4b6c, r9 =3Dc094ace8, r10=3Dc09741d8, r11=3Dc0f14618 > r12=3Dc0f146c4, ssp=3Dc0f145fc, slr=3Dc0601428, pc =3Dc062686c >=20 > panic: Fatal abort > cpuid =3D 0 > time =3D 1 > KDB: stack backtrace: > Fatal kernel mode data abort: 'Translation Fault (L1)' on read > trapframe: 0xc0f141f0 > FSR=3D00000005, FAR=3Ddb7fcfb1, spsr=3D200001d3 > r0 =3Dc0f142e4, r1 =3D00000001, r2 =3Ddb7fcfae, r3 =3D1b000a4e > r4 =3Dc07fc55c, r5 =3D8fce1b89, r6 =3D00006f3e, r7 =3D81000000 > r8 =3Dc07c4b6c, r9 =3Dc094ace8, r10=3Dc09741d8, r11=3Dc0f142a0 > r12=3Dc0f1434c, ssp=3Dc0f14284, slr=3Dc0601428, pc =3Dc062686c >=20 > panic: Fatal abort > cpuid =3D 0 > time =3D 1 > KDB: stack backtrace: > Fatal kernel mode data abort: 'Translation Fault (L1)' on read > trapframe: 0xc0f13e78 > FSR=3D00000005, FAR=3Ddb7fcfb1, spsr=3D200001d3 > r0 =3Dc0f13f6c, r1 =3D00000001, r2 =3Ddb7fcfae, r3 =3D1b000a4e > r4 =3Dc07fc55c, r5 =3D8fce1b89, r6 =3D00006f3e, r7 =3D81000000 > r8 =3Dc07c4b6c, r9 =3Dc094ace8, r10=3Dc09741d8, r11=3Dc0f13f28 > r12=3Dc0f13fd4, ssp=3Dc0f13f0c, slr=3Dc0601428, pc =3Dc062686c >=20 > panic: Fatal abort > cpuid =3D 0 > time =3D 1 > KDB: stack backtrace: > Fatal kernel mode data abort: 'Translation Fault (L1)' on read > trapframe: 0xc0f13b00 > FSR=3D00000005, FAR=3Ddb7fcfb1, spsr=3D200001d3 > r0 =3Dc0f13bf4, r1 =3D00000001, r2 =3Ddb7fcfae, r3 =3D1b000a4e > r4 =3Dc07fc55c, r5 =3D8fce1b89, r6 =3D00006f3e, r7 =3D81000000 > r8 =3Dc07c4b6c, r9 =3Dc094ace8, r10=3Dc09741d8, r11=3Dc0f13bb0 > r12=3Dc0f13c5c, ssp=3Dc0f13b94, slr=3Dc0601428, pc =3Dc062686c >=20 > panic: Fatal abort > cpuid =3D 0 > time =3D 1 > KDB: stack backtrace: > Fatal kernel mode data abort: 'Translation Fault (L1)' on read > trapframe: 0xc0f13788 > FSR=3D00000005, FAR=3Ddb7fcfb1, spsr=3D200001d3 > r0 =3Dc0f1387c, r1 =3D00000001, r2 =3Ddb7fcfae, r3 =3D1b000a4e > r4 =3Dc07fc55c, r5 =3D8fce1b89, r6 =3D00006f3e, r7 =3D81000000 > r8 =3Dc07c4b6c, r9 =3Dc094ace8, r10=3Dc09741d8, r11=3Dc0f13838 > r12=3Dc0f138e4, ssp=3Dc0f1381c, slr=3Dc0601428, pc =3Dc062686c >=20 > . . . >=20 > Looking: >=20 > # llvm-addr2line -e /boot/kernel.GENERIC-NODEBUG/kernel 0xc062686c > /home/pkgbuild/worktrees/main/sys/vm/uma_core.c:5676 >=20 > static int > sysctl_handle_uma_zone_frees(SYSCTL_HANDLER_ARGS) > { > uma_zone_t zone =3D arg1; > uint64_t cur; >=20 > cur =3D uma_zone_get_frees(zone); > return (sysctl_handle_64(oidp, &cur, 0, req)); > } >=20 > The "return" line is 5676 of sys/vm/uma_core.c . >=20 >=20 > Also, for what leads up to: >=20 > /home/pkgbuild/worktrees/main/sys/arm/arm/pmap-v6.c:6455 >=20 > /* =20 > * The implementation of pmap_fault() uses IN_RANGE2() macro which > * depends on the fact that given range size is a power of 2. > */ > CTASSERT(powerof2(NB_IN_PT1)); > CTASSERT(powerof2(PT2MAP_SIZE)); >=20 > #define IN_RANGE2(addr, start, size) \ > ((vm_offset_t)(start) =3D=3D ((vm_offset_t)(addr) & ~((size) - 1))) >=20 > /* > * Handle access and R/W emulation faults. > */ > int > pmap_fault(pmap_t pmap, vm_offset_t far, uint32_t fsr, int idx, bool = usermode) > { > pt1_entry_t *pte1p, pte1; > pt2_entry_t *pte2p, pte2; >=20 > if (pmap =3D=3D NULL) > pmap =3D kernel_pmap; >=20 > /* > * In kernel, we should never get abort with FAR which is in = range of > * pmap->pm_pt1 or PT2MAP address spaces. If it happens, stop = here > * and print out a useful abort message and even get to the = debugger > * otherwise it likely ends with never ending loop of aborts. > */ =20 > if (__predict_false(IN_RANGE2(far, pmap->pm_pt1, NB_IN_PT1))) { > /* > * All L1 tables should always be mapped and present. > * However, we check only current one herein. For user = mode, =20 > * only permission abort from malicious user is not = fatal. > * And alignment abort as it may have higher priority. > */ > if (!usermode || (idx !=3D FAULT_ALIGN && idx !=3D = FAULT_PERM_L2)) { > CTR4(KTR_PMAP, "%s: pmap %#x pm_pt1 %#x far = %#x", > __func__, pmap, pmap->pm_pt1, far); > panic("%s: pm_pt1 abort", __func__); > } > return (KERN_INVALID_ADDRESS); > }=20 > if (__predict_false(IN_RANGE2(far, PT2MAP, PT2MAP_SIZE))) { > /* > * PT2MAP should be always mapped and present in = current > * L1 table. However, only existing L2 tables are = mapped > * in PT2MAP. For user mode, only L2 translation abort = and > * permission abort from malicious user is not fatal. > * And alignment abort as it may have higher priority. > */ > if (!usermode || (idx !=3D FAULT_ALIGN && > idx !=3D FAULT_TRAN_L2 && idx !=3D FAULT_PERM_L2)) = { > CTR4(KTR_PMAP, "%s: pmap %#x PT2MAP %#x far = %#x", > __func__, pmap, PT2MAP, far); > panic("%s: PT2MAP abort", __func__); > } > return (KERN_INVALID_ADDRESS); > } >=20 > /* > * A pmap lock is used below for handling of access and R/W = emulation > * aborts. They were handled by atomic operations before so = some > * analysis of new situation is needed to answer the following = question: > * Is it safe to use the lock even for these aborts? > * > * There may happen two cases in general: > * > * (1) Aborts while the pmap lock is locked already - this = should not > * happen as pmap lock is not recursive. However, under pmap = lock only > * internal kernel data should be accessed and such data should = be > * mapped with A bit set and NM bit cleared. If double abort = happens, > * then a mapping of data which has caused it must be fixed. = Further, > * all new mappings are always made with A bit set and the bit = can be > * cleared only on managed mappings. > * > * (2) Aborts while another lock(s) is/are locked - this = already can > * happen. However, there is no difference here if it's either = access or > * R/W emulation abort, or if it's some other abort. > */ >=20 > PMAP_LOCK(pmap); >=20 > That "PMAP_LOCK(pmap);" line is line 6455 of sys/arm/arm/pmap-v6.c . >=20 >=20 > FYI: Running the prior kernel.GENERIC-NODEBUG/ ( called > kernel.GENERIC-NODEBUG.good/ ) continues to operate > normally. I do not have the older PkgBase kernel/ around > to try, unfortunately. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Nov 8 03:15:18 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 4Xl3wn6mBMz5bwps for ; Fri, 08 Nov 2024 03:15:37 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-8.consmr.mail.gq1.yahoo.com (sonic315-8.consmr.mail.gq1.yahoo.com [98.137.65.32]) (using TLSv1.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 4Xl3wm4j76z4lCN for ; Fri, 8 Nov 2024 03:15:36 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=klW05NnE; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1731035734; bh=4IVonQrmhQ4Iipd/TAerbhtoTEy/ta5awMv2GP7cFUs=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=klW05NnEJ+WLt9MAdo12Y2ha3JTIzbx0LKtyYUXOrp0+SS/W9RqVmzDpdS68d5wdlP1nzmjK9CcGyW7ZPjGucszW7BkO6B/NE4tLX5p0vKHbgkDOZyCXznndzr+eX5nnOR/AToPcvuAqVK+1ydTIuYW44JFsDlCRKKV2Nm1M0FTp7Rle1jO9/BV7/SF6bHB3sD27j2LUkbeI7alM9AOyVI3JT42Etueaz41Ha/4qAN/KpPIsQYfsRw/CR622c1ea7YR2qx0SNK7fXcRrp6jc8ge+FIsJgJ//p/9h1l3hpawO+V24eoTESEbG47y1teqOK2nnzJub8Fi8OMbAvLEl7w== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1731035734; bh=vHaBVrtgYcX5VOu4w1m59Hz6+oyDiwt7locjRkvWxrW=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=j8HzTFpcyturxWTtCH26j6jmV5wY4kN/Zarvt/4hLaI8TuYu4Qs4I4f9dx78UzG6kju5+i2V4IFPF/IWYz/6oBlj/3+zQEx7Sn1L/vwRDaCZbHETAmYJZKq2Xuw0Ue07PYD/m1Qr+yMUsU81Pyu05GH+rzJYYJXvYMcLlEjXCzDwGYxKStQXaVblBA2ZBLkPdwUdb/ZTKpF/SOiBfB14yJTFlIcKzqtj/j8Fz7p4Uu+XjC26E1/GYu8VhxamjrOgIyU4LZmHm/aQA/9Djhe/chc0zN6I7Uvr/Gls1jmxyphCujv+E/6BF+UmF2PvYrw24hYpDb8yG2Dj9L4fIv57+A== X-YMail-OSG: WbrGo9EVM1lb5ABs6854WfstEI6uqCbz5JieN9Dc4rHtiEBk6Oz66LjmrzjKGfk _pzbsN8XawG6aMpB4nDHJzFMG5I.sCJQcja.eWMQrkJsKINTGdEDDTCZPCWgbgqu0oQWI73r2kLC vFLahp4KDWIdUrmvPQNclCIQTRg1cQQaxJYbCABrWs4VSu4ZBm.FZS.X1DzLxbaP5yhPkTivvBar M54DOPG_aXszJvw4aJ3zVAy8Fh2Qk87YYW0c28vwS9bEr6lbSPjkaF7kpjYvbPNxOuZuoNuOvoQt zAKVsI9fd6uqXXizgv08ctMkyeb.F0xCX1Ar8YHkt5ay18smQfq49fec9dNFoHxTXAClQVa_7Sti sPseRAVMh0QHq5anBjpWiIwHHi.tRcRRpi7Jq.rrLeW93XXQz.w8OP2jFcihA2S6icARpwtmn9vW qO7KnWUGow.QpBpO1qhzfzOY0zs8b7ohvwK55yQK8Ttom.5FfEHNICoEjBpuN_4vktyCYiQjq3uT eC9ozOkHXWqJkCJ6Iu92N0yNMzLk.9xJ4TKigRbOhk9TS9M849fa5GulXVZXAtqLZRbPMBXXPQ96 Oe_OKoVIZ.DGG3DZDhNR9VvMdz5CNnYNgO8oXJpuQRoyVgb6dyNF_8MTDwYIKDzEx_iZRGsdyd_E suPFFof6nSiU19i75r0r3cZfRrTFhBh7skHSx6lREFKZSaX__2x9Qpio1Ny2PMszDqWp.3BeJjTg 2XzbYzBnwyNCrW_A5oHl6ydGSlK6EC4Xv7DuxLAud2BJTLtcYX.ZTgo6FmdVzuWHKUm4lNNdyEh9 dlc0Q_sbbhscUxT7FarONRXQETlqo_iFcmrxSmVIBg8scXCOCrOW40Yv11SQjk2CQLiZ_Xdyj_sK gyrOhMl66UTx5mNkhmePN7l2gA562C8Nl_mzAwM89rwqDVMUyDxY7EQW82r3XW2MAqjA3rcUEigl bLYNWfnfiM4dlIo4honIABaR5lFzJIWbU6aZRfNSPZd7CyAefGizW8lDPClfzSmyDMoUMcJC2S6E Xkomf.KDoiQIF2toI7Fei8hTaLpib7AuURFFaeCY0awRsMTehqxT80FM90DSPlccOrJQvoLxdcox m7q1CKefHWl9YK.808JPYCrLDf7D2dZWXzTBAADVltfHAOE6LqHEKwKZrU0vesT5enwGGLlJ_8QB mi5c_41EQYZNWIS3PjwW8xOM3on4Y1TjkTG3JU_npc1zzEg6gikE6WxYq.e5CDAvzY52RWWIXNwH x_vZyr2OXjAazj0heuxyuZtjm_33W3uW2jdDIiKXFIpEpXgnyWicm66df0SOCyihAC7G1axtmoRH 5Dn34YNJn8F8I6n43_.bN45M701spS_P5L57IPBlper53Fr6zuHx5X_s3_..AQZqhu9bKY2Xwlds cGOMyYIZ6PLHe5PF_XhxN5oWykFYAt62Jfpn95U7NOepiznNjamxVUELmN3I0gBg5iSt7km.U3tB 1f0vxBjDskCM94n434rxD7p1aHgdd__9P6RXWfFAGEL481BqkgSEQHCmV0HTHcYB.jRIdOuiMb9w CmY904eVi_gb_7ER37Hku.Y6QhOzjXxz8jN_qZ7GKX9OB20bOhdU19BtQAm4LT0xEWE_tp0yIJfP PYAuADPLSpBBY62gO2Kau0wWcsX3Fa7uZ1_3rpJTxhaMhct46iGCt3RRMEcVZbQsq1aQsnnn5Ln0 D2w1VuNOIFt8LTz6oPA5Ui8HIpOrW0vgX6Hjvr8ImjNBQQxUUp5AZ8C16yqYxF2E4pbFqLO2_epP HGCJUuiYwiOtjL194gWI0dqjSExU_3kA.FJid3Od5R2U2cxrCe6mNRBacjjJMospADbM2ullzOB2 axdlIpjMNJVURrOibozCNaMoGFxzjMMC5j1K5iSducBqmNWwlkhSlnj8fTwhfRBi8lkGufjOK60L ie1ZeNlYoumgjFWQfea6WMyI.3drR1yW17SE5Cg7r2N8h4WGrES7EE3aIhF.ud4z8TyW8WqndPX8 x1K2Dj7Hz5OA6.DwA4HkQMNlG.Hem3hAa.5UVBNGnCIDqJcq.jcNrdCO1Rp0VF_Iz4YSiGwnZjwU Qyn.a0p1CcyZPiqG7Z_sc5XPSO7TPFTF6WxUxBox_wPvOyDXikbc1Lb0CDBZHVEf2Eh.mmqx48bv 7thuxx7FrCHpM0qKcSFRf7K6N18RVbav.cwNtBzS59uGlondjxdjZiYzoVw9845w0JDIwuAmmxyX MBz_Tv0R9352oQ1m4T_yrmmQG14729ddRqIjMyUsSJIvPf2qaNgnw5xSp9CiZfZmzGksuJ5Ak2Jm _q80jrLOnZKjejUDE X-Sonic-MF: X-Sonic-ID: 2f6959b0-4c57-41fd-9672-c5071359c1f1 Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Fri, 8 Nov 2024 03:15:34 +0000 Received: by hermes--production-gq1-5dd4b47f46-n48bg (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID b082948f48ce2adb44549802e6fb55f7; Fri, 08 Nov 2024 03:15:29 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51\)) Subject: Re: Official armv7 PkgBase kernel-NODEBUG installation's USB2 boot gets "Fatal kernel mode data abort: 'Alignment Fault' on write" very early, at least on an OrangePi+ 2ed From: Mark Millard In-Reply-To: <74468E62-5A74-4FB4-94F6-599E5BA3A9A1@yahoo.com> Date: Thu, 7 Nov 2024 19:15:18 -0800 Cc: Dimitry Andric , "dougm@freebsd.org" , Kyle Evans Content-Transfer-Encoding: quoted-printable Message-Id: References: <74468E62-5A74-4FB4-94F6-599E5BA3A9A1@yahoo.com> To: FreeBSD ARM List , Current FreeBSD , FreeBSD Toolchain X-Mailer: Apple Mail (2.3776.700.51) X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; 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)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_DN_SOME(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_DN_EQ_ADDR_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.32:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.32:from]; RCPT_COUNT_FIVE(0.00)[6] X-Rspamd-Queue-Id: 4Xl3wm4j76z4lCN X-Spamd-Bar: --- [I narrowed the artifact kernel range for the change in the type of failure that happens.] On Nov 7, 2024, at 17:43, Mark Millard wrote: > [The change to LLVM 19 is what leads to the Alignment > Fault' on write failure. Details later below.] >=20 > On Nov 7, 2024, at 01:42, Mark Millard wrote: >=20 >> Note: Unfortunately, the panics here are too early for a >> dump device to be available. >>=20 >> Context started PkgBase upgrade from: >>=20 >> # uname -apKU >> FreeBSD OPiP2E-RPi2v1p1 15.0-CURRENT FreeBSD 15.0-CURRENT = main-n272821-37798b1d5dd1 GENERIC-NODEBUG arm armv7 1500025 1500025 >>=20 >> Installed packages to be UPGRADED: >> FreeBSD-dtb: 15.snap20241009161500 -> 15.snap20241028121139 = [base] >> FreeBSD-kernel-generic: 15.snap20241011221604 -> = 15.snap20241106134422 [base] >> FreeBSD-kernel-generic-dbg: 15.snap20241011221604 -> = 15.snap20241106134422 [base] >> FreeBSD-kernel-generic-mmccam: 15.snap20241011221604 -> = 15.snap20241106134422 [base] >> FreeBSD-kernel-generic-mmccam-dbg: 15.snap20241011221604 -> = 15.snap20241106134422 [base] >> FreeBSD-kernel-generic-nodebug: 15.snap20241011221604 -> = 15.snap20241106134422 [base] >> FreeBSD-kernel-generic-nodebug-dbg: 15.snap20241011221604 -> = 15.snap20241106134422 [base] >> FreeBSD-src-sys: 15.snap20241011221604 -> 15.snap20241106160110 = [base] >>=20 >> (Those were installed but the FreeBSD-dtb had linux 6.4 >> dtb files, not the 6.8 ones. 6.8 ones from a personal build >> were copied to where they need to be. I've separately >> reported the 6.4 vs. 6.8 issue.) >>=20 >> # ~/pkgbase-snapshot-list.sh >> Via pkg-static info -C -x '^FreeBSD-' . . . >> 1 FreeBSD-*-15.snap20241106160110 >> 6 FreeBSD-*-15.snap20241106134422 >> 1 FreeBSD-*-15.snap20241028121139 >> 3 FreeBSD-*-15.snap20241011221604 >> 2 FreeBSD-*-15.snap20241011210446 >> 38 FreeBSD-*-15.snap20241011182434 >> 4 FreeBSD-*-15.snap20241011073851 >> 5 FreeBSD-*-15.snap20241010141501 >> 1 FreeBSD-*-15.snap20241010120743 >> 296 FreeBSD-*-15.snap20241009161500 >> Instead via /var/cache/pkg/*.snap*.pkg . . . >> 1 FreeBSD-*-15.snap20241106160110 >> 6 FreeBSD-*-15.snap20241106134422 >> 1 FreeBSD-*-15.snap20241028121139 >> 10 FreeBSD-*-15.snap20241011221604 >> 2 FreeBSD-*-15.snap20241011210446 >> 38 FreeBSD-*-15.snap20241011182434 >> 4 FreeBSD-*-15.snap20241011073851 >> 5 FreeBSD-*-15.snap20241010141501 >> 1 FreeBSD-*-15.snap20241010120743 >> 297 FreeBSD-*-15.snap20241009161500 >>=20 >>=20 >> The failure (kernel-GENERIC-NODEBUG): >>=20 >> . . . >> Root mount waiting for: usbus3 CAM >> Fatal kernel mode data abort: 'Alignment Fault' on write >> trapframe: 0xc6c9ac10 >> FSR=3D00000801, FAR=3Ddb23209b, spsr=3D20000013 >> r0 =3Ddb232080, r1 =3D00000000, r2 =3D00000006, r3 =3D00000024 >> r4 =3Ddb19e280, r5 =3D00000000, r6 =3D00000001, r7 =3D00000006 >> r8 =3Dc6c9ad20, r9 =3Dc0b7973c, r10=3Dc092074c, r11=3Dc6c9acb8 >> r12=3D00000000, ssp=3Dc6c9aca0, slr=3Dc01b01d8, pc =3Dc01aff88 >>=20 >> panic: Fatal abort >> cpuid =3D 1 >> time =3D 3 >> KDB: stack backtrace: >> db_trace_self() at db_trace_self >> pc =3D 0xc0667004 lr =3D 0xc0078630 = (db_trace_self_wrapper+0x30) >> sp =3D 0xc6c9a9c8 fp =3D 0xc6c9aae0 >> db_trace_self_wrapper() at db_trace_self_wrapper+0x30 >> pc =3D 0xc0078630 lr =3D 0xc0328db8 (vpanic+0x140) >> sp =3D 0xc6c9aae8 fp =3D 0xc6c9ab08 >> r4 =3D 0x00000100 r5 =3D 0x00000000 >> r6 =3D 0xc084d1f1 r7 =3D 0xc0b69a94 >> vpanic() at vpanic+0x140 >> pc =3D 0xc0328db8 lr =3D 0xc0328c78 (vpanic) >> sp =3D 0xc6c9ab10 fp =3D 0xc6c9ab14 >> r4 =3D 0xc6c9ac10 r5 =3D 0x00000013 >> r6 =3D 0xdb23209b r7 =3D 0x00000001 >> r8 =3D 0x00000801 r9 =3D 0x00000013 >> r10 =3D 0xdb23209b >> vpanic() at vpanic >> pc =3D 0xc0328c78 lr =3D 0xc068c8e8 (abort_align) >> sp =3D 0xc6c9ab1c fp =3D 0xc6c9ab48 >> r4 =3D 0x00000001 r5 =3D 0x00000801 >> r6 =3D 0x00000013 r7 =3D 0xdb23209b >> r8 =3D 0xc6c9ab14 r9 =3D 0xc0328c78 >> r10 =3D 0xc6c9ab1c >> abort_align() at abort_align >> pc =3D 0xc068c8e8 lr =3D 0xc068c958 (abort_align+0x70) >> sp =3D 0xc6c9ab50 fp =3D 0xc6c9ab68 >> r4 =3D 0xc6d21c00 r10 =3D 0xdb23209b >> abort_align() at abort_align+0x70 >> pc =3D 0xc068c958 lr =3D 0xc068c5e0 (abort_handler+0x430) >> sp =3D 0xc6c9ab70 fp =3D 0xc6c9ac08 >> r4 =3D 0x00000000 r10 =3D 0xdb23209b >> abort_handler() at abort_handler+0x430 >> pc =3D 0xc068c5e0 lr =3D 0xc0669868 (exception_exit) >> sp =3D 0xc6c9ac10 fp =3D 0xc6c9acb8 >> r4 =3D 0xdb19e280 r5 =3D 0x00000000 >> r6 =3D 0x00000001 r7 =3D 0x00000006 >> r8 =3D 0xc6c9ad20 r9 =3D 0xc0b7973c >> r10 =3D 0xc092074c >> exception_exit() at exception_exit >> pc =3D 0xc0669868 lr =3D 0xc01b01d8 (usb_msc_auto_quirk+0xfc) >> sp =3D 0xc6c9aca0 fp =3D 0xc6c9acb8 >> r0 =3D 0xdb232080 r1 =3D 0x00000000 >> r2 =3D 0x00000006 r3 =3D 0x00000024 >> r4 =3D 0xdb19e280 r5 =3D 0x00000000 >> r6 =3D 0x00000001 r7 =3D 0x00000006 >> r8 =3D 0xc6c9ad20 r9 =3D 0xc0b7973c >> r10 =3D 0xc092074c r12 =3D 0x00000000 >> bbb_command_start() at bbb_command_start+0x4c >> pc =3D 0xc01aff88 lr =3D 0xc01b01d8 (usb_msc_auto_quirk+0xfc) >> sp =3D 0xc6c9acc0 fp =3D 0xc6c9acf8 >> r4 =3D 0xdb16d800 r5 =3D 0xdb19e280 >> r6 =3D 0x00000001 r10 =3D 0xc092074c >> usb_msc_auto_quirk() at usb_msc_auto_quirk+0xfc >> pc =3D 0xc01b01d8 lr =3D 0xc01a4bd8 (usb_alloc_device+0x9c4) >> sp =3D 0xc6c9ad00 fp =3D 0xc6c9ad68 >> r4 =3D 0x00000000 r5 =3D 0x00000001 >> r6 =3D 0x00000000 r7 =3D 0x00000002 >> r8 =3D 0xdb16d800 r9 =3D 0xda241c78 >> r10 =3D 0x000003ee >> usb_alloc_device() at usb_alloc_device+0x9c4 >> pc =3D 0xc01a4bd8 lr =3D 0xc01ad16c (uhub_explore+0x494) >> sp =3D 0xc6c9ad70 fp =3D 0xc6c9adc0 >> r4 =3D 0x00000000 r5 =3D 0x00000000 >> r6 =3D 0xdb16e800 r7 =3D 0x00000000 >> r8 =3D 0xdb18c200 r9 =3D 0x00000001 >> r10 =3D 0x00000000 >> uhub_explore() at uhub_explore+0x494 >> pc =3D 0xc01ad16c lr =3D 0xc0198654 (usb_bus_explore+0x1d4) >> sp =3D 0xc6c9adc8 fp =3D 0xc6c9add8 >> r4 =3D 0xda241c78 r5 =3D 0xdb16e800 >> r6 =3D 0x00000000 r7 =3D 0xda241d6c >> r8 =3D 0xc09b0b5f r9 =3D 0x00000001 >> r10 =3D 0xda241d1c >> usb_bus_explore() at usb_bus_explore+0x1d4 >> pc =3D 0xc0198654 lr =3D 0xc01b22d0 (usb_process+0x124) >> sp =3D 0xc6c9ade0 fp =3D 0xc6c9ae10 >> r4 =3D 0xda241d0c r5 =3D 0xda241d14 >> usb_process() at usb_process+0x124 >> pc =3D 0xc01b22d0 lr =3D 0xc02da4f0 (fork_exit+0xb0) >> sp =3D 0xc6c9ae18 fp =3D 0xc6c9ae38 >> r4 =3D 0xc6c9ae40 r5 =3D 0xc6d21c00 >> r6 =3D 0xc6d08740 r7 =3D 0xda241d0c >> r8 =3D 0xc01b21ac r9 =3D 0x00000000 >> r10 =3D 0x00000000 >> fork_exit() at fork_exit+0xb0 >> pc =3D 0xc02da4f0 lr =3D 0xc06697fc (swi_exit) >> sp =3D 0xc6c9ae40 fp =3D 0x00000000 >> r4 =3D 0xc01b21ac r5 =3D 0xda241d0c >> r6 =3D 0x00000000 r7 =3D 0x00000000 >> r8 =3D 0x00000000 r10 =3D 0x00000000 >> swi_exit() at swi_exit >> pc =3D 0xc06697fc lr =3D 0xc06697fc (swi_exit) >> sp =3D 0xc6c9ae40 fp =3D 0x00000000 >> KDB: enter: panic >> [ thread pid 14 tid 100069 ] >> Stopped at kdb_enter+0x54: ldrb r15, [r15, r15, ror r15]! >> db> >=20 > Using just available official artifact kernels for testing > I've established that 0953460ce149 (and various from before > that) does not have the problem:=20 >=20 > Wed, 23 Oct 2024 > =E2=80=A2 git: 5c92f84bb607 - main - LinuxKPI: update = rcu_dereference_*() and lockdep_is_held() Bjoern A. Zeeb > =E2=80=A2 git: 6fa91acca40d - main - conf/NOTES: Remove trailing = whitespace Li-Wen Hsu=20 > =E2=80=A2 git: 91b7b225b2ce - main - LINT: Add mac_do Li-Wen Hsu=20 > =E2=80=A2 git: 419249c1cacc - main - Revert "LINT: Add mac_do" = Li-Wen Hsu=20 > =E2=80=A2 Re: git: 419249c1cacc - main - Revert "LINT: Add mac_do" = Baptiste Daroussin=20 > =E2=80=A2 Re: git: 13da1af1cd67 - main - libcxxrt: Update to = upstream 698997bfde1f John Baldwin=20 > =E2=80=A2 Re: git: 419249c1cacc - main - Revert "LINT: Add mac_do" = John Baldwin=20 > =E2=80=A2 git: 0953460ce149 - main - libc: fix access mode tests in = fmemopen(3) Ed Maste >=20 > So the above one worked. >=20 > The next available kernel to test was f3dbef108212 (the bump for = LLVM19 > at the end of the below): >=20 > =E2=80=A2 RE: git: 6a07e67fb7a8 - main - vm_meter: Fix laundry = accounting Mark Millard=20 > =E2=80=A2 git: 6b9f7133aba4 - main - libc: Add one more check in = new fmemopen test Ed Maste=20 > =E2=80=A2 git: 0fca6ea1d4ee - main - Merge llvm-project main = llvmorg-19-init-18630-gf2ccf80136a0 Dimitry Andric=20 > =E2=80=A2 git: 36b606ae6aa4 - main - Merge llvm-project = release/19.x llvmorg-19.1.0-rc1-0-ga4902a36d5c2 Dimitry Andric=20 > =E2=80=A2 git: 3f157662c0ef - main - Tentatively apply = https://github.com/llvm/llvm-project/pull/101403 Dimitry Andric=20 > =E2=80=A2 git: d575077527d4 - main - bsd.sys.mk: for clang >=3D 19, = similar to gcc >=3D 8.1, turn off -Werror for = -Wcast-function-type-mismatch. Dimitry Andric=20 > =E2=80=A2 git: 36d486cc2ecd - main - Fix enum warning in ath_hal's = ar9002 Dimitry Andric=20 > =E2=80=A2 git: 6846ab2fb663 - main - libcxx simd_utils.h: only = enable _LIBCPP_HAS_ALGORITHM_VECTOR_UTILS for clang >=3D 15, since older = versions do not support the required builtins. Dimitry Andric=20 > =E2=80=A2 git: 81e300df5e65 - main - libcxx atomic_ref.h: add = typename keyword for difference_type declarations, otherwise older clang = versions cannot compile this header. Dimitry Andric=20 > =E2=80=A2 git: 6b4981df6008 - main - libcxx cstdlib, cwchar: avoid = using long long functions if not supported, even for older compilers = that do not support the using_if_exists attribute. Dimitry Andric=20 > =E2=80=A2 git: 2f6d6eaf2d51 - main - libcxx-compat: revert = llvmorg-19-init-18063-g561246e90282: Dimitry Andric=20 > =E2=80=A2 git: 04f5b79cfa49 - main - libcxx-compat: revert = llvmorg-19-init-18062-g4dfa75c663e5: Dimitry Andric=20 > =E2=80=A2 git: e8054e44f4ca - main - libcxx-compat: revert = llvmorg-19-init-17853-g578c6191eff7: Dimitry Andric=20 > =E2=80=A2 git: 0bec0529b1d7 - main - libcxx-compat: revert = llvmorg-19-init-17728-g30cc12cd818d: Dimitry Andric=20 > =E2=80=A2 git: e8847079df1b - main - libcxx-compat: revert = llvmorg-19-init-17727-g0eebb48fcfbc: Dimitry Andric=20 > =E2=80=A2 git: 2f2ebe758bea - main - libcxx-compat: revert = llvmorg-19-init-17473-g69fecaa1a455: Dimitry Andric=20 > =E2=80=A2 git: 1199d38d8ec7 - main - libcxx-compat: revert = llvmorg-19-init-8667-g472b612ccbed: Dimitry Andric=20 > =E2=80=A2 git: a7b2d7f261b8 - main - libcxx-compat: revert = llvmorg-19-init-5639-ga10aa4485e83: Dimitry Andric=20 > =E2=80=A2 git: f3859a1a13a1 - main - libcxx-compat: revert = llvmorg-19-init-4504-g937a5396cf3e: Dimitry Andric=20 > =E2=80=A2 git: 072b5fb698ab - main - libcxx-compat: revert = llvmorg-19-init-4003-g55357160d0e1: Dimitry Andric=20 > =E2=80=A2 git: b60301d8b594 - main - libcxx-compat: don't remove = headers that were reintroduced by reverts Dimitry Andric=20 > =E2=80=A2 git: 2e861daab905 - main - libcxx-compat: install headers = that were reintroduced by reverts Dimitry Andric=20 > =E2=80=A2 git: ff6c8447844b - main - libcxx-compat: update = libcxx.imp for headers that were reintroduced by reverts Dimitry Andric=20= > =E2=80=A2 git: 52418fc2be8e - main - Merge llvm-project = release/19.x llvmorg-19.1.0-rc2-0-gd033ae172d1c Dimitry Andric=20 > =E2=80=A2 git: 62987288060f - main - Merge llvm-project = release/19.x llvmorg-19.1.0-rc3-0-g437434df21d8 Dimitry Andric=20 > =E2=80=A2 git: 6c4b055cfb6b - main - Merge llvm-project = release/19.x llvmorg-19.1.0-rc4-0-g0c641568515a Dimitry Andric=20 > =E2=80=A2 git: 835c3a3e69af - main - Merge commit 6dbdb8430b49 from = llvm git (by Nikolas Klauser): Dimitry Andric=20 > =E2=80=A2 git: c80e69b00d97 - main - Merge llvm-project = release/19.x llvmorg-19.1.0-0-ga4bf6cd7cfb1 Dimitry Andric=20 > =E2=80=A2 git: 6e516c87b6d7 - main - Merge llvm-project = release/19.x llvmorg-19.1.1-0-gd401987fe349 Dimitry Andric=20 > =E2=80=A2 git: 5deeebd8c6ca - main - Merge llvm-project = release/19.x llvmorg-19.1.2-0-g7ba7d8e2f7b6 Dimitry Andric=20 > =E2=80=A2 git: f3dbef108212 - main - Bump __FreeBSD_version for = llvm 19.1.2 merge Dimitry Andric=20 >=20 > f3dbef108212 gets the: >=20 > "Fatal kernel mode data abort: 'Alignment Fault' on write" >=20 > boot failure for artifact kernel. 6b9f7133aba4 does nit > seem a likely source of the problem, basically leaving the > LLVM changes as what is at issue. >=20 > I'll note that artifact kernels are witness kernels. So > this exploration adds to the distinctions observed > compared to the prior notes. >=20 >> Looking at bbb_command_start() 's pc: >>=20 >> # llvm-addr2line -e /boot/kernel.GENERIC-NODEBUG/kernel 0xc01aff88 >> /home/pkgbuild/worktrees/main/sys/dev/usb/usb_msctest.c:554 >>=20 >> What leads to that line is: >>=20 >> = /*------------------------------------------------------------------------= * >> * bbb_command_start - execute a SCSI command synchronously =20 >> * =20 >> * Return values >> * 0: Success >> * Else: Failure >> = *------------------------------------------------------------------------*= / >> static int >> bbb_command_start(struct bbb_transfer *sc, uint8_t dir, uint8_t lun, = =20 >> void *data_ptr, size_t data_len, void *cmd_ptr, size_t cmd_len, >> usb_timeout_t data_timeout) >> { >> sc->lun =3D lun; >> sc->dir =3D data_len ? dir : DIR_NONE; >> sc->data_ptr =3D data_ptr; >> sc->data_len =3D data_len; >> sc->data_rem =3D data_len; >> sc->data_timeout =3D (data_timeout + USB_MS_HZ); >> sc->actlen =3D 0; >> sc->error =3D 0; >> sc->cmd_len =3D cmd_len; >> memset(&sc->cbw->CBWCDB, 0, sizeof(sc->cbw->CBWCDB)); >>=20 >> The memset line is line 554 of sys/dev/usb/usb_msctest.c . >=20 > The below looks to be a separate problem based on > some later FreeBSD kernel update than the above. >=20 >> I'll note that attempting to use the WITNESS variant of the kernel >> ( /boot/kernel/ ) gets a different, even earlier failure: >>=20 >> . . . >> VT: init without driver. >> panic: acquiring blockable sleep lock with spinlock or critical = section held (sleep mutex) pmap @ = /home/pkgbuild/worktrees/main/sys/arm/arm/pmap-v6.c:6455 >=20 > I do know that d021d3b3c675 at the end of the below > shows this failure --before the system has a chance > to get the usb related write alignment failure > reported above. >=20 > I have not explored where in the below range the > behavior changes (for what is available as an > official artifact kernel). It seems unlikely that > any of the below would actually boot: it is likely > a question of which of the 2 (or more) failure > types happen for each instead. The last before "Thu, 24, Oct 2024" was: =E2=80=A2 git: 8b2e7da70855 - main - llvm19: permit incremental = builds from llvm18 Brooks Davis=20 That is the last available artifact kernel that gets the original usb related write alignment type of failure. > Thu, 24 Oct 2024 > =E2=80=A2 git: 34951b0b9e78 - main - swap_pager: move = scan_all_shadowed, use iterators Doug Moore=20 > =E2=80=A2 git: 2ac21f2c98ed - main - x86 specialreg.h: visually = align %cr4 and MSR_EFER bit mask definitions Konstantin Belousov=20 > =E2=80=A2 git: cc11bc1150d5 - main - x86 specialreg.h: add all = defined bits for %cr4 Konstantin Belousov=20 > =E2=80=A2 git: cc4b25f10211 - main - x86 specialreg: reorder %cr3 = bits masks definitions by value Konstantin Belousov=20 > =E2=80=A2 git: 5999b74e9637 - main - x86 specialreg: add bit masks = definitions for LAM in %cr3 Konstantin Belousov=20 > =E2=80=A2 git: 6308db659f2a - main - x86 specialreg: add bit masks = definitions for EFER features Konstantin Belousov=20 > =E2=80=A2 git: 9f718b57b846 - main - x86 specialreg: add bit masks = definitions for LASS and LAM features Konstantin Belousov=20 > =E2=80=A2 git: 3360a15898ce - main - net: route: convert routing = statistics to a sysctl Kyle Evans=20 > =E2=80=A2 Re: git: 3360a15898ce - main - net: route: convert = routing statistics to a sysctl Kyle Evans=20 > =E2=80=A2 git: 77b70ad751df - main - e1000: Move I219 LM19/V19 to = ADL Kevin Bowling The last above is the first available artifact kernel that that gets the different error. There are no armv7 artifact kernels between 8b2e7da70855 and 77b70ad751df . So something from 34951b0b9e78 .. 77b70ad751df leads to the change in the type of failure. I've no clue what. It looked to me like the x86 commits and e1000 commit had no chance of contributing to the armv7 context. Thus who I added to the CC vs. did not add. > =E2=80=A2 git: d64442a89896 - main - arm{,64}: use genassym for = INTR_ROOT_* values Kyle Evans=20 > =E2=80=A2 git: 536c8d948e85 - main - intrng: change multi-interrupt = root support type to enum Kyle Evans=20 > =E2=80=A2 git: 4f12b529f404 - main - sys/intr.h: formally depend on = machine/intr.h Kyle Evans=20 > =E2=80=A2 git: a5b1eecbed07 - main - Apply workaround for building = llvm-project with WITHOUT_LLVM_ASSERTIONS Dimitry Andric=20 > =E2=80=A2 git: 1c83996beda7 - main - Adjust = LLVM_ENABLE_ABI_BREAKING_CHECKS depending on NDEBUG Dimitry Andric=20 > =E2=80=A2 git: b2dd4970c7b5 - main - dev/gpio: Mask all pl011 = interrupts Andrew Turner=20 > =E2=80=A2 git: 3b03e1bb8615 - main - intrng: Store the IPI priority = Andrew Turner=20 > =E2=80=A2 git: 6204391e99ca - main - arm64: Check TDP_NOFAULTING in = a data abort Andrew Turner=20 > =E2=80=A2 git: a84653c5db25 - main - arm64: Don't enable interrupts = when in a spinlock Andrew Turner=20 > =E2=80=A2 git: d7f930b80e89 - main - arm64: Implement = efi_rt_arch_call Andrew Turner=20 > =E2=80=A2 git: 8efb1500d4f1 - main - arm64: Enable handling EFI = runtime service faults Andrew Turner=20 > =E2=80=A2 git: 9693241188aa - main - sound: Call DSP_REGISTERED = before PCM_DETACHING Christos Margiolis=20 > =E2=80=A2 git: bb5e3ac1a7b7 - main - sound: Use DSP_REGISTERED in = dsp_clone() Christos Margiolis=20 > =E2=80=A2 git: a4111e9dc722 - main - sound: Change PCMDIR_* = numbering Christos Margiolis=20 > =E2=80=A2 git: 802c78f5194e - main - sound: Untangle dsp_cdevs[] = and dsp_unit2name() confusion Christos Margiolis=20 > =E2=80=A2 git: b1bb6934bb87 - main - sound: Fix build error in = chm_mkname() KASSERT Christos Margiolis=20 > =E2=80=A2 git: ce20b48a60fb - main - sctp: improve debug output = Michael Tuexen=20 > =E2=80=A2 git: e4ac0183a1a8 - main - sctp: cleanup Michael Tuexen=20= > =E2=80=A2 git: 8c8ebbb04518 - main - bhyve ahci: Improve robustness = of TRIM handling John Baldwin=20 > =E2=80=A2 git: f0bc751d6fb4 - main - csa: Use pci_find_device to = simplify clkrun_hack John Baldwin=20 > =E2=80=A2 git: d96ba5a62365 - main - config: Remove a stray = semicolon Zhenlei Huang=20 > =E2=80=A2 git: 56b17de1e836 - main - makefs: Remove a stray = semicolon Zhenlei Huang=20 > =E2=80=A2 git: 88b71d1fe054 - main - arm64: rockchip: Remove a = stray semicolon Zhenlei Huang=20 > =E2=80=A2 git: b4856b8e9d87 - main - LinuxKPI: Remove stray = semicolons Zhenlei Huang=20 > =E2=80=A2 git: 75ff90814aec - main - enic: Remove a stray semicolon = Zhenlei Huang=20 > =E2=80=A2 git: 6ccf4f4071c5 - main - mana: Remove stray semicolons = Zhenlei Huang=20 > =E2=80=A2 git: 86a2c910c05c - main - mpi3mr: Remove a stray = semicolon Zhenlei Huang=20 > =E2=80=A2 git: 36756195a342 - main - ocs_fc: Remove a stray = semicolon Zhenlei Huang=20 > =E2=80=A2 git: 2f395cfda8b5 - main - tcp cc: Remove a stray = semicolon Zhenlei Huang=20 > =E2=80=A2 git: f3a097d0312c - main - netstat: switch to using the = sysctl-exported stats for live stats Kyle Evans=20 > =E2=80=A2 git: 656991b0c629 - main - locks: augment lock_class with = lc_trylock method Gleb Smirnoff=20 > =E2=80=A2 git: efcb2ec8cb81 - main - callout: provide = CALLOUT_TRYLOCK flag Gleb Smirnoff=20 > =E2=80=A2 git: bffebc336f4e - main - tcp: use CALLOUT_TRYLOCK for = the TCP callout Gleb Smirnoff=20 > =E2=80=A2 git: d021d3b3c675 - main - tcp: get rid of = TDP_INTCPCALLOUT Gleb Smirnoff >> cpuid =3D 0 >> time =3D 1 >> KDB: stack backtrace: >> Fatal kernel mode data abort: 'Translation Fault (L1)' on read >> trapframe: 0xc0f14568 >> FSR=3D00000005, FAR=3Ddb7fcfb1, spsr=3D200001d3 >> r0 =3Dc0f1465c, r1 =3D00000001, r2 =3Ddb7fcfae, r3 =3D1b000a4e >> r4 =3Dc07fc55c, r5 =3D8fce1b89, r6 =3D00006f3e, r7 =3D81000000 >> r8 =3Dc07c4b6c, r9 =3Dc094ace8, r10=3Dc09741d8, r11=3Dc0f14618 >> r12=3Dc0f146c4, ssp=3Dc0f145fc, slr=3Dc0601428, pc =3Dc062686c >>=20 >> panic: Fatal abort >> cpuid =3D 0 >> time =3D 1 >> KDB: stack backtrace: >> Fatal kernel mode data abort: 'Translation Fault (L1)' on read >> trapframe: 0xc0f141f0 >> FSR=3D00000005, FAR=3Ddb7fcfb1, spsr=3D200001d3 >> r0 =3Dc0f142e4, r1 =3D00000001, r2 =3Ddb7fcfae, r3 =3D1b000a4e >> r4 =3Dc07fc55c, r5 =3D8fce1b89, r6 =3D00006f3e, r7 =3D81000000 >> r8 =3Dc07c4b6c, r9 =3Dc094ace8, r10=3Dc09741d8, r11=3Dc0f142a0 >> r12=3Dc0f1434c, ssp=3Dc0f14284, slr=3Dc0601428, pc =3Dc062686c >>=20 >> panic: Fatal abort >> cpuid =3D 0 >> time =3D 1 >> KDB: stack backtrace: >> Fatal kernel mode data abort: 'Translation Fault (L1)' on read >> trapframe: 0xc0f13e78 >> FSR=3D00000005, FAR=3Ddb7fcfb1, spsr=3D200001d3 >> r0 =3Dc0f13f6c, r1 =3D00000001, r2 =3Ddb7fcfae, r3 =3D1b000a4e >> r4 =3Dc07fc55c, r5 =3D8fce1b89, r6 =3D00006f3e, r7 =3D81000000 >> r8 =3Dc07c4b6c, r9 =3Dc094ace8, r10=3Dc09741d8, r11=3Dc0f13f28 >> r12=3Dc0f13fd4, ssp=3Dc0f13f0c, slr=3Dc0601428, pc =3Dc062686c >>=20 >> panic: Fatal abort >> cpuid =3D 0 >> time =3D 1 >> KDB: stack backtrace: >> Fatal kernel mode data abort: 'Translation Fault (L1)' on read >> trapframe: 0xc0f13b00 >> FSR=3D00000005, FAR=3Ddb7fcfb1, spsr=3D200001d3 >> r0 =3Dc0f13bf4, r1 =3D00000001, r2 =3Ddb7fcfae, r3 =3D1b000a4e >> r4 =3Dc07fc55c, r5 =3D8fce1b89, r6 =3D00006f3e, r7 =3D81000000 >> r8 =3Dc07c4b6c, r9 =3Dc094ace8, r10=3Dc09741d8, r11=3Dc0f13bb0 >> r12=3Dc0f13c5c, ssp=3Dc0f13b94, slr=3Dc0601428, pc =3Dc062686c >>=20 >> panic: Fatal abort >> cpuid =3D 0 >> time =3D 1 >> KDB: stack backtrace: >> Fatal kernel mode data abort: 'Translation Fault (L1)' on read >> trapframe: 0xc0f13788 >> FSR=3D00000005, FAR=3Ddb7fcfb1, spsr=3D200001d3 >> r0 =3Dc0f1387c, r1 =3D00000001, r2 =3Ddb7fcfae, r3 =3D1b000a4e >> r4 =3Dc07fc55c, r5 =3D8fce1b89, r6 =3D00006f3e, r7 =3D81000000 >> r8 =3Dc07c4b6c, r9 =3Dc094ace8, r10=3Dc09741d8, r11=3Dc0f13838 >> r12=3Dc0f138e4, ssp=3Dc0f1381c, slr=3Dc0601428, pc =3Dc062686c >>=20 >> . . . >>=20 >> Looking: >>=20 >> # llvm-addr2line -e /boot/kernel.GENERIC-NODEBUG/kernel 0xc062686c >> /home/pkgbuild/worktrees/main/sys/vm/uma_core.c:5676 >>=20 >> static int >> sysctl_handle_uma_zone_frees(SYSCTL_HANDLER_ARGS) >> { >> uma_zone_t zone =3D arg1; >> uint64_t cur; >>=20 >> cur =3D uma_zone_get_frees(zone); >> return (sysctl_handle_64(oidp, &cur, 0, req)); >> } >>=20 >> The "return" line is 5676 of sys/vm/uma_core.c . >>=20 >>=20 >> Also, for what leads up to: >>=20 >> /home/pkgbuild/worktrees/main/sys/arm/arm/pmap-v6.c:6455 >>=20 >> /* =20 >> * The implementation of pmap_fault() uses IN_RANGE2() macro which >> * depends on the fact that given range size is a power of 2. >> */ >> CTASSERT(powerof2(NB_IN_PT1)); >> CTASSERT(powerof2(PT2MAP_SIZE)); >>=20 >> #define IN_RANGE2(addr, start, size) \ >> ((vm_offset_t)(start) =3D=3D ((vm_offset_t)(addr) & ~((size) - 1))) >>=20 >> /* >> * Handle access and R/W emulation faults. >> */ >> int >> pmap_fault(pmap_t pmap, vm_offset_t far, uint32_t fsr, int idx, bool = usermode) >> { >> pt1_entry_t *pte1p, pte1; >> pt2_entry_t *pte2p, pte2; >>=20 >> if (pmap =3D=3D NULL) >> pmap =3D kernel_pmap; >>=20 >> /* >> * In kernel, we should never get abort with FAR which is in = range of >> * pmap->pm_pt1 or PT2MAP address spaces. If it happens, stop = here >> * and print out a useful abort message and even get to the = debugger >> * otherwise it likely ends with never ending loop of aborts. >> */ =20 >> if (__predict_false(IN_RANGE2(far, pmap->pm_pt1, NB_IN_PT1))) { >> /* >> * All L1 tables should always be mapped and present. >> * However, we check only current one herein. For user = mode, =20 >> * only permission abort from malicious user is not = fatal. >> * And alignment abort as it may have higher priority. >> */ >> if (!usermode || (idx !=3D FAULT_ALIGN && idx !=3D = FAULT_PERM_L2)) { >> CTR4(KTR_PMAP, "%s: pmap %#x pm_pt1 %#x far = %#x", >> __func__, pmap, pmap->pm_pt1, far); >> panic("%s: pm_pt1 abort", __func__); >> } >> return (KERN_INVALID_ADDRESS); >> }=20 >> if (__predict_false(IN_RANGE2(far, PT2MAP, PT2MAP_SIZE))) { >> /* >> * PT2MAP should be always mapped and present in = current >> * L1 table. However, only existing L2 tables are = mapped >> * in PT2MAP. For user mode, only L2 translation abort = and >> * permission abort from malicious user is not fatal. >> * And alignment abort as it may have higher priority. >> */ >> if (!usermode || (idx !=3D FAULT_ALIGN && >> idx !=3D FAULT_TRAN_L2 && idx !=3D FAULT_PERM_L2)) = { >> CTR4(KTR_PMAP, "%s: pmap %#x PT2MAP %#x far = %#x", >> __func__, pmap, PT2MAP, far); >> panic("%s: PT2MAP abort", __func__); >> } >> return (KERN_INVALID_ADDRESS); >> } >>=20 >> /* >> * A pmap lock is used below for handling of access and R/W = emulation >> * aborts. They were handled by atomic operations before so = some >> * analysis of new situation is needed to answer the following = question: >> * Is it safe to use the lock even for these aborts? >> * >> * There may happen two cases in general: >> * >> * (1) Aborts while the pmap lock is locked already - this = should not >> * happen as pmap lock is not recursive. However, under pmap = lock only >> * internal kernel data should be accessed and such data should = be >> * mapped with A bit set and NM bit cleared. If double abort = happens, >> * then a mapping of data which has caused it must be fixed. = Further, >> * all new mappings are always made with A bit set and the bit = can be >> * cleared only on managed mappings. >> * >> * (2) Aborts while another lock(s) is/are locked - this = already can >> * happen. However, there is no difference here if it's either = access or >> * R/W emulation abort, or if it's some other abort. >> */ >>=20 >> PMAP_LOCK(pmap); >>=20 >> That "PMAP_LOCK(pmap);" line is line 6455 of sys/arm/arm/pmap-v6.c . >>=20 >>=20 >> FYI: Running the prior kernel.GENERIC-NODEBUG/ ( called >> kernel.GENERIC-NODEBUG.good/ ) continues to operate >> normally. I do not have the older PkgBase kernel/ around >> to try, unfortunately. I'll remind that this is from using official FreeBSD builds of the kernel versions that I tested, not from my personal build context. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Nov 8 04:46: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 4Xl5y00rR3z5c4jT for ; Fri, 08 Nov 2024 04:46:48 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Xl5xz43jYz4tYB for ; Fri, 8 Nov 2024 04:46:47 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pg1-x535.google.com with SMTP id 41be03b00d2f7-7ed9c16f687so1203380a12.0 for ; Thu, 07 Nov 2024 20:46:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1731041206; x=1731646006; 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=w1BwYxWHqpk5JMnU/q96aDjRfqtYMDkO+0I/J5dYVL8=; b=YLceG5rWOIWIzQm3nk5QAt55dwBEW0jM7MUKEE7sIudM4MEaMcF2RVXNiOJVUXUDX3 OQ7hVzOaJATZycby4qgR67D4BqLDTPoxcJ428LWZejU9rWhr+Es/LR5TRli4QrEX82Hz RYVXbw9CM8nShp12+r6jmB4gRQtPsN+j+ggXn1bSMZHSuSdqgLD/Ei78SsUSULoKsEP0 zyt02BQorD90sNrS5GRtxH/n3SXLzHFwJSGNrfBDoegMt1+R1KvpBiz3QD04/BE+J9nT yhjMFxRr8R8GBVpPNwhGAQOzvZO7z++vX+8lWKjcNhhgEZ4VN7AOL3Ww7qc/7mnEPxrO 0GVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731041206; x=1731646006; 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=w1BwYxWHqpk5JMnU/q96aDjRfqtYMDkO+0I/J5dYVL8=; b=BIm5bV7DCKnSv0NsS5DF8du6fM5aEzDjgj5VZWEB/luESB3rZ6wWcIdzKPlzVRPISc dpJdwHCw+mUR/Q2GKiU7Fnf7ZQvr3ujmTAP1vXy7kaNl6I8GOb6a2fdVpHlG87LkYtta eTvr4GhSKLfufWZrkNwDtAgoMThNG4YrCtJWuZWWw+Yt2SH3kk705XADyOqLKEEDph09 jIGTsY5kQsRrx9tqHKhxzxiREfjhbenJWKRX4GIHEGe/phA4V+2xEzgMyFH6pXRcrsjt J/DysaYy42NBEjl4EdIYqcaujRE6bJkhA+92ZKJhgAbexsmRw0UvFCTpLM1t99Re6UOo 8OBg== X-Gm-Message-State: AOJu0YyhJEXcWqFhIwKFcfHSuu8Bo1NYN0XOVBaqukCm0OCbVDpKnGLA +Kh3bRjtlHhZgSG9P+R/quUZXmA/FIdW3likRdGS1U0L3BDBgwE2A1/m3dTp4h0nSOa4B3fdTO4 x0GHtaHAu6/c3rZXt+1lpxnDeqLBLFisJN5n+EBVB8AsqvUfTtL+B3lvP X-Google-Smtp-Source: AGHT+IHSKJKtP30bxCJkRQkgBsgKyqqd6ahQMQpQw+QAuroqWum3Dj1vhygNENPdxFct8hcWlMHm3kySfg0o6/DLB+4= X-Received: by 2002:a05:6a21:20b:b0:1db:e329:83f5 with SMTP id adf61e73a8af0-1dc229901admr1411196637.14.1731041206130; Thu, 07 Nov 2024 20:46:46 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: <8cf9adb0e7ca6340460c695ffd64a0df@Leidinger.net> <896b9ce404ffcb126dcdd6008583b117@Leidinger.net> <132ca9158817a4706d1b9e78c3567973@Leidinger.net> In-Reply-To: <132ca9158817a4706d1b9e78c3567973@Leidinger.net> From: Warner Losh Date: Thu, 7 Nov 2024 20:46:34 -0800 Message-ID: Subject: Re: No valid device tree blob found! To: Alexander Leidinger Cc: Current FreeBSD Content-Type: multipart/alternative; boundary="0000000000002f0a9806265f7056" 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: 4Xl5xz43jYz4tYB X-Spamd-Bar: ---- --0000000000002f0a9806265f7056 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable OK. I'm confused... but no matter. Three more things to help... (1) kenv after boot with a fixed kernel (2) sudo efivar --device-path 8be4df61-93ca-11d2-aa0d-00e098032b8c-ConIn (3) sudo efivar --device-path 8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut Warner On Thu, Nov 7, 2024 at 2:41=E2=80=AFPM Alexander Leidinger wrote: > Am 2024-11-07 20:59, schrieb Warner Losh: > > > > On Wed, Nov 6, 2024 at 3:41=E2=80=AFAM Alexander Leidinger < > Alexander@leidinger.net> wrote: > > Am 2024-11-02 17:08, schrieb Warner Losh: > > > > On Sat, Nov 2, 2024, 10:03=E2=80=AFAM Alexander Leidinger > wrote: > > Am 2024-10-30 22:11, schrieb Alexander Leidinger: > > > WARNING! Trying to fire up the kernel, but no device tree blob found! > > For anyone interested, I opened > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D282493 for this. > > > Yea. This is a hang or a bad console. The warning is lame and misleading. > > Can you bisect? > > Found it. > > # git bisect bad > c87b3f0006be9ac5813f1ff636f18c9b4a41b08e is the first bad commit > commit c87b3f0006be9ac5813f1ff636f18c9b4a41b08e (HEAD) > Author: Warner Losh > Date: Mon Oct 14 15:58:10 2024 -0600 > > uart: uart_getenv: check for NULL class last, not first > > This allows one to specify dt:XXXX when the default class isn't > compiled > into the kernel. It's not an error to not have a class until we're do= ne > parsing the spec, so defer checking until then. > > Sponsored by: Netflix > Reviewed by: adrian, andrew, markj > Differential Revision: https://reviews.freebsd.org/D47078 > > sys/dev/uart/uart_subr.c | 14 +++++++------- > 1 file changed, 7 insertions(+), 7 deletions(-) > > -current as of today without this change boots just fine on the Ampere > system in the Oracle cloud. > > > what's your loader.conf? this should only matter if something is set > there... > > loader.conf: > > autoboot_delay=3D"1" > hw.usb.no_boot_wait=3D"0" > beastie_disable=3D"YES" > boot_serial=3D"YES" > loader_logo=3D"none" > cryptodev_load=3D"YES" > xz_load=3D"YES" > zfs_load=3D"YES" > geom_eli_load=3D"YES" > > tcphpts_load=3D"yes" > tcp_rack_load=3D"YES" > > hw.mca.enabled=3D"1" > vm.exec_map_entries=3D"32" > > net.link.ifqmaxlen=3D"256" > net.inet.tcp.soreceive_stream=3D"1" > kern.random.fortuna.concurrent_read=3D"1" > kern.msgbuf_show_timestamp=3D"1" > > Bye, > Alexander. > -- > http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF > http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF > --0000000000002f0a9806265f7056 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
OK. I'm confused... but no matter.=C2=A0

Three more things to help...=C2=A0
(1) kenv after boot with= a fixed kernel
(2) sudo efivar --device-path 8be4df61-93ca-11d2-= aa0d-00e098032b8c-ConIn
(3) sudo efivar --device-path 8be4df61-93= ca-11d2-aa0d-00e098032b8c-ConOut

Warner

On Th= u, Nov 7, 2024 at 2:41=E2=80=AFPM Alexander Leidinger <Alexander@leidinger.net>= wrote:

Am 2024-11= -07 20:59, schrieb Warner Losh:

=C2=A0

On Wed, Nov 6, 2024 at 3:41=E2=80=AFAM Alexander Leidinger= <Alexander@leidinger.net> wrote:

Am 2024-11-02 17:08, schrieb Warner Losh:



On Sat, Nov 2, 2024, 10:03=E2=80=AFAM Alexander Leidinger = <Alexander@leidinger.net> wrote:
Am 2024-10-30 22:11, schrieb Alexander Leidinge= r:

> WARNING! Trying to fire up the kernel, but no device tree bl= ob found!

For anyone interested, I opened
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D282= 493 for this.
=C2=A0
Yea. This is a hang or a bad console. The warning is lame= and misleading.
=C2=A0
Can you bisect?

Found it.

# git bisect bad
c87b3f0006be9ac5813f1ff6= 36f18c9b4a41b08e is the first bad commit
commit c87b3f0006be9ac5813f1ff6= 36f18c9b4a41b08e (HEAD)
Author: Warner Losh <imp@FreeBSD.org>
D= ate: =C2=A0 Mon Oct 14 15:58:10 2024 -0600

=C2=A0 =C2=A0 uart: uart_getenv: check for N= ULL class last, not first

=C2=A0 =C2=A0 This allows one to specify dt:= XXXX when the default class isn't compiled
=C2=A0 =C2=A0 into the ke= rnel. It's not an error to not have a class until we're done
=C2= =A0 =C2=A0 parsing the spec, so defer checking until then.

=C2=A0 =C2=A0 Sponsored by: =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Netflix
=C2=A0 =C2=A0 Reviewed by: =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0adrian, andrew, markj
=C2=A0 =C2=A0 Different= ial Revision: =C2=A0https://reviews.freebsd.org/D47078

=C2=A0sys/dev/uart/uart_subr.c | 14 +++++++-= ------
=C2=A01 file changed, 7 insertions(+), 7 deletions(-)

-current as of today without this change boots just fine on the Ampere s= ystem in the Oracle cloud.

=C2=A0
what's your loader.conf? this should only matter if something is s= et there...=C2=A0=C2=A0

loader.conf:

autoboot_delay=3D"1"
hw.usb.no_= boot_wait=3D"0"
beastie_disable=3D"YES"
boot_seri= al=3D"YES"
loader_logo=3D"none"
cryptodev_load=3D= "YES"
xz_load=3D"YES"
zfs_load=3D"YES"<= br>geom_eli_load=3D"YES"

tcphpts_load=3D"yes"
tcp_rack_l= oad=3D"YES"

hw.mca.enabled=3D"1"
vm.exec_ma= p_entries=3D"32"

net.link.ifqmaxlen=3D"256"
net.= inet.tcp.soreceive_stream=3D"1"
kern.random.fortuna.concurrent= _read=3D"1"
kern.msgbuf_show_timestamp=3D"1"

Bye,
Alexander.

--
http://= www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF
http:= //www.FreeBSD.org =C2=A0 =C2=A0netchild@FreeBSD.org =C2=A0: PGP 0x8F31830F9F2772BF
--0000000000002f0a9806265f7056-- From nobody Fri Nov 8 08:34:31 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 4XlC1L5Qgxz5cPgs for ; Fri, 08 Nov 2024 08:35:02 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:313::1:5]) (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 "E6" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4XlC1L1J7Rz3xpK for ; Fri, 8 Nov 2024 08:35:02 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Authentication-Results: mx1.freebsd.org; none List-Id: Discussions about the use of FreeBSD-current List-Archive: https://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=1731054892; 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=EUvpdoljs+TxrNIXtg3csjCkvVnizkFDWGfXBrv5S+A=; b=YziaLnL/KZnaiyPL9r4pqoGnGsI0UYb3kUFKwV1Py5R3m/CeOCEPDSPEsICkevAc5VVecF Pekxuq0dtyVD7sjh891EJ1SZKVghl6MtjnyBjU8GNzAp2/9yX/00hvruviFcpddWUkzSug J5PRxIuvTY5vjaH5a7s5RrWnH419B4rBIF3F09ELrth05YhbSIVyxivhRHTUP0qCi04afn YGJaDOznUpjMuDeW5QYe+AN1G/1vJaGODMO8vYKKNfzG++K5Fs4IHsyn4HsmS0mn1dCJHi GqXEeuNkjXtuYzuUE/X4xiQLh4QigjVxuCxmFP0OhyGO0VcLYIWFYHXm7jtDAg== Date: Fri, 08 Nov 2024 09:34:31 +0100 From: Alexander Leidinger To: Warner Losh Cc: Current FreeBSD Subject: Re: No valid device tree blob found! In-Reply-To: References: <8cf9adb0e7ca6340460c695ffd64a0df@Leidinger.net> <896b9ce404ffcb126dcdd6008583b117@Leidinger.net> <132ca9158817a4706d1b9e78c3567973@Leidinger.net> Message-ID: <0389774b2a7a86ebf538807f71239802@Leidinger.net> Organization: No organization, this is a private message. Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=_840859b68618c0d64dfe586f0d6f2eed"; micalg=pgp-sha256 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:34240, ipnet:2a00:1828::/32, country:DE] X-Rspamd-Queue-Id: 4XlC1L1J7Rz3xpK X-Spamd-Bar: ---- This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --=_840859b68618c0d64dfe586f0d6f2eed Content-Type: multipart/alternative; boundary="=_9d4c8b632bc81518f5ad9a111033835c" --=_9d4c8b632bc81518f5ad9a111033835c Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8; format=flowed Am 2024-11-08 05:46, schrieb Warner Losh: > OK. I'm confused... but no matter. > > Three more things to help... > (1) kenv after boot with a fixed kernel COLUMNS="100" LINES="31" acpi.oem="BOCHS " acpi.revision="2" acpi.rsdp="0x00000006385c0018" acpi.rsdt="0x0000000000000000" acpi.xsdt="0x00000006385cfe98" acpi.xsdt_length="36" acpi_dsdt_load="NO" acpi_dsdt_name="/boot/acpi_dsdt.aml" acpi_dsdt_type="acpi_dsdt" acpi_video_load="NO" audit_event_load="NO" audit_event_name="/etc/security/audit_event" audit_event_type="etc_security_audit_event" autoboot_delay="1" beastie_disable="YES" bitmap_load="NO" bitmap_name="splash.bmp" bitmap_type="splash_image_data" boot_multicons="YES" boot_serial="YES" bootenv_autolist="YES" bootenvs[0]="zfs:zroot/ROOT/2024-10-30-121420_ko" bootenvs[10]="zfs:zroot/ROOT/2024-07-15-110946" bootenvs[11]="zfs:zroot/ROOT/2024-09-12-140543" bootenvs[1]="zfs:zroot/ROOT/2024-10-14-233343_ko" bootenvs[2]="zfs:zroot/ROOT/2024-10-14-160359" bootenvs[3]="zfs:zroot/ROOT/2024-10-14-160358" bootenvs[4]="zfs:zroot/ROOT/2024-10-13-232308" bootenvs[5]="zfs:zroot/ROOT/2024-10-14-102617" bootenvs[6]="zfs:zroot/ROOT/2024-10-11-084349" bootenvs[7]="zfs:zroot/ROOT/2024-11-06-084833" bootenvs[8]="zfs:zroot/ROOT/2024-08-15-222928" bootenvs[9]="zfs:zroot/ROOT/2024-07-16-094205" bootenvs_count="12" bootfile="kernel" console="efi" cpu_microcode_load="NO" cpu_microcode_name="/boot/firmware/ucode.bin" cpu_microcode_type="cpu_microcode" cryptodev_load="YES" currdev="zfs:zroot/ROOT/2024-11-06-084833:" efi-version="2.70" efi_com_port="0" efi_com_speed="38400" efi_max_resolution="1x1" entropy_cache_load="YES" entropy_cache_name="/boot/entropy" entropy_cache_type="boot_entropy_cache" entropy_efi_seed="YES" entropy_efi_seed_size="2048" geom_eli_load="YES" hint.acpi.0.disabled="0" hint.smbios.0.mem="0x63bed0000" hostuuid_load="YES" hostuuid_name="/etc/hostid" hostuuid_type="hostuuid" hw.mca.enabled="1" hw.uart.console="db:8,dt:pl011,mm:0x9000000,rs:0,rw:1,pa:none,br:9600,xo=0" hw.usb.no_boot_wait="0" kern.msgbuf_show_timestamp="1" kern.random.fortuna.concurrent_read="1" kernel="kernel" kernel_options="" kernel_path="/boot/kernel" kernelname="/boot/kernel/kernel" kernels_autodetect="YES" loaddev="zfs:zroot/ROOT/2024-11-06-084833:" loader.efi="1" loader_conf_dirs="/boot/loader.conf.d" loader_logo="none" local_loader_conf_files="/boot/loader.conf.local" module_blacklist="drm drm2 radeonkms i915kms amdgpu" module_path="/boot/kernel;/boot/modules;/boot/dtb;/boot/dtb/overlays" module_verbose="2" net.inet.tcp.soreceive_stream="1" net.link.ifqmaxlen="256" nextboot_conf="/boot/nextboot.conf" ram_blacklist_load="NO" ram_blacklist_name="/boot/blacklist.txt" ram_blacklist_type="ram_blacklist" screensave_load="NO" screensave_name="green_saver" script.lang="lua" smbios.bios.reldate="06/16/2021" smbios.bios.revision="0.0" smbios.bios.vendor="EFI Development Kit II / OVMF" smbios.bios.version="1.5.1" smbios.chassis.maker="QEMU" smbios.chassis.tag="OracleCloud.com" smbios.chassis.type="Other" smbios.chassis.version="virt-4.2" smbios.memory.enabled="25165824" smbios.socket.enabled="1" smbios.socket.populated="1" smbios.system.maker="QEMU" smbios.system.product="KVM Virtual Machine" smbios.system.uuid="14fd7a5a-8f68-44d4-88b6-68498f8b55fb" smbios.system.version="virt-4.2" smbios.version="3.0" splash="/boot/images/freebsd-logo-rev.png" splash_bmp_load="NO" splash_pcx_load="NO" splash_txt_load="NO" tcp_rack_load="YES" tcphpts_load="YES" twiddle_divisor="16" verbose_loading="NO" vesa_load="NO" vfs.root.mountfrom="zfs:zroot/ROOT/2024-11-06-084833" vm.exec_map_entries="32" xz_load="YES" zfs-bootonce="zfs:zroot/ROOT/2024-11-06-084833:" zfs_be_active="zfs:zroot/ROOT/2024-10-14-160358" zfs_be_currpage="1" zfs_be_root="zroot/ROOT" zfs_load="YES" > (2) sudo efivar --device-path > 8be4df61-93ca-11d2-aa0d-00e098032b8c-ConIn 8be4df61-93ca-11d2-aa0d-00e098032b8c-ConIn : UsbHID(0xffff,0xffff,0x1,0x1),/VenHw(d3987d4b-971a-435f-8caf-4967eb627241)/Uart(38400,8,N,1)/VenVt100() > (3) sudo efivar --device-path > 8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut 8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut : PciRoot(0x0)/Pci(0x1,0x0)/AcpiAdr(0x80010300),/VenHw(d3987d4b-971a-435f-8caf-4967eb627241)/Uart(38400,8,N,1)/VenVt100() Bye, Alexander. > Warner > > On Thu, Nov 7, 2024 at 2:41 PM Alexander Leidinger > wrote: > > Am 2024-11-07 20:59, schrieb Warner Losh: > > On Wed, Nov 6, 2024 at 3:41 AM Alexander Leidinger > wrote: > > Am 2024-11-02 17:08, schrieb Warner Losh: > > On Sat, Nov 2, 2024, 10:03 AM Alexander Leidinger > wrote: Am 2024-10-30 22:11, schrieb Alexander > Leidinger: > >> WARNING! Trying to fire up the kernel, but no device tree blob found! > > For anyone interested, I opened > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282493 for this. > > Yea. This is a hang or a bad console. The warning is lame and > misleading. > > Can you bisect? Found it. # git bisect bad c87b3f0006be9ac5813f1ff636f18c9b4a41b08e is the first bad commit commit c87b3f0006be9ac5813f1ff636f18c9b4a41b08e (HEAD) Author: Warner Losh Date: Mon Oct 14 15:58:10 2024 -0600 uart: uart_getenv: check for NULL class last, not first This allows one to specify dt:XXXX when the default class isn't compiled into the kernel. It's not an error to not have a class until we're done parsing the spec, so defer checking until then. Sponsored by: Netflix Reviewed by: adrian, andrew, markj Differential Revision: https://reviews.freebsd.org/D47078 sys/dev/uart/uart_subr.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) -current as of today without this change boots just fine on the Ampere system in the Oracle cloud. what's your loader.conf? this should only matter if something is set there... loader.conf: autoboot_delay="1" hw.usb.no_boot_wait="0" beastie_disable="YES" boot_serial="YES" loader_logo="none" cryptodev_load="YES" xz_load="YES" zfs_load="YES" geom_eli_load="YES" tcphpts_load="yes" tcp_rack_load="YES" hw.mca.enabled="1" vm.exec_map_entries="32" net.link.ifqmaxlen="256" net.inet.tcp.soreceive_stream="1" kern.random.fortuna.concurrent_read="1" kern.msgbuf_show_timestamp="1" Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_9d4c8b632bc81518f5ad9a111033835c Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Am 2024-11-08 05:46, schrieb Warner Losh:

OK. I'm confused... but no matter. 
 
Three more things to help... 
(1) kenv after boot with a fixed kernel
 
COLUMNS=3D"100"
LINES=3D"31"
acpi.oem=3D"BOCHS "
acpi.r= evision=3D"2"
acpi.rsdp=3D"0x00000006385c0018"
acpi.rsdt=3D"0x000= 0000000000000"
acpi.xsdt=3D"0x00000006385cfe98"
acpi.xsdt_length= =3D"36"
acpi_dsdt_load=3D"NO"
acpi_dsdt_name=3D"/boot/acpi_dsdt.a= ml"
acpi_dsdt_type=3D"acpi_dsdt"
acpi_video_load=3D"NO"
audi= t_event_load=3D"NO"
audit_event_name=3D"/etc/security/audit_event"
audit_event_type=3D"etc_security_audit_event"
autoboot_delay=3D"1"beastie_disable=3D"YES"
bitmap_load=3D"NO"
bitmap_name=3D"spl= ash.bmp"
bitmap_type=3D"splash_image_data"
boot_multicons=3D"YES"=
boot_serial=3D"YES"
bootenv_autolist=3D"YES"
bootenvs[0]=3D= "zfs:zroot/ROOT/2024-10-30-121420_ko"
bootenvs[10]=3D"zfs:zroot/ROOT/2= 024-07-15-110946"
bootenvs[11]=3D"zfs:zroot/ROOT/2024-09-12-140543"bootenvs[1]=3D"zfs:zroot/ROOT/2024-10-14-233343_ko"
bootenvs[2]=3D"= zfs:zroot/ROOT/2024-10-14-160359"
bootenvs[3]=3D"zfs:zroot/ROOT/2024-1= 0-14-160358"
bootenvs[4]=3D"zfs:zroot/ROOT/2024-10-13-232308"
boo= tenvs[5]=3D"zfs:zroot/ROOT/2024-10-14-102617"
bootenvs[6]=3D"zfs:zroot= /ROOT/2024-10-11-084349"
bootenvs[7]=3D"zfs:zroot/ROOT/2024-11-06-0848= 33"
bootenvs[8]=3D"zfs:zroot/ROOT/2024-08-15-222928"
bootenvs[9]= =3D"zfs:zroot/ROOT/2024-07-16-094205"
bootenvs_count=3D"12"
bootf= ile=3D"kernel"
console=3D"efi"
cpu_microcode_load=3D"NO"
cpu= _microcode_name=3D"/boot/firmware/ucode.bin"
cpu_microcode_type=3D"cpu= _microcode"
cryptodev_load=3D"YES"
currdev=3D"zfs:zroot/ROOT/2024= -11-06-084833:"
efi-version=3D"2.70"
efi_com_port=3D"0"
efi_= com_speed=3D"38400"
efi_max_resolution=3D"1x1"
entropy_cache_load= =3D"YES"
entropy_cache_name=3D"/boot/entropy"
entropy_cache_type= =3D"boot_entropy_cache"
entropy_efi_seed=3D"YES"
entropy_efi_seed= _size=3D"2048"
geom_eli_load=3D"YES"
hint.acpi.0.disabled=3D"0"hint.smbios.0.mem=3D"0x63bed0000"
hostuuid_load=3D"YES"
hostu= uid_name=3D"/etc/hostid"
hostuuid_type=3D"hostuuid"
hw.mca.enabled=3D"1"
hw.uart.cons= ole=3D"db:8,dt:pl011,mm:0x9000000,rs:0,rw:1,pa:none,br:9600,xo=3D0"
hw= =2Eusb.no_boot_wait=3D"0"
kern.msgbuf_show_timestamp=3D"1"
kern.r= andom.fortuna.concurrent_read=3D"1"
kernel=3D"kernel"
kernel_opti= ons=3D""
kernel_path=3D"/boot/kernel"
kernelname=3D"/boot/kernel/= kernel"
kernels_autodetect=3D"YES"
loaddev=3D"zfs:zroot/ROOT/2024= -11-06-084833:"
loader.efi=3D"1"
loader_conf_dirs=3D"/boot/loader= =2Econf.d"
loader_logo=3D"none"
local_loader_conf_files=3D"/boot/= loader.conf.local"
module_blacklist=3D"drm drm2 radeonkms i915kms amdg= pu"
module_path=3D"/boot/kernel;/boot/modules;/boot/dtb;/boot/dtb/over= lays"
module_verbose=3D"2"
net.inet.tcp.soreceive_stream=3D"1"net.link.ifqmaxlen=3D"256"
nextboot_conf=3D"/boot/nextboot.conf"ram_blacklist_load=3D"NO"
ram_blacklist_name=3D"/boot/blacklist.txt= "
ram_blacklist_type=3D"ram_blacklist"
screensave_load=3D"NO"
screensave_name=3D"green_saver"
script.lang=3D"lua"
smbios.bios= =2Ereldate=3D"06/16/2021"
smbios.bios.revision=3D"0.0"
smbios.bio= s.vendor=3D"EFI Development Kit II / OVMF"
smbios.bios.version=3D"1.5.= 1"
smbios.chassis.maker=3D"QEMU"
smbios.chassis.tag=3D"OracleClou= d.com"
smbios.chassis.type=3D"Other"
smbios.chassis.version=3D"vi= rt-4.2"
smbios.memory.enabled=3D"25165824"
smbios.socket.enabled= =3D"1"
smbios.socket.populated=3D"1"
smbios.system.maker=3D"QEMU"=
smbios.system.product=3D"KVM Virtual Machine"
smbios.system.uuid= =3D"14fd7a5a-8f68-44d4-88b6-68498f8b55fb"
smbios.system.version=3D"vir= t-4.2"
smbios.version=3D"3.0"
splash=3D"/boot/images/freebsd-logo= -rev.png"
splash_bmp_load=3D"NO"
splash_pcx_load=3D"NO"
spla= sh_txt_load=3D"NO"
tcp_rack_load=3D"YES"
tcphpts_load=3D"YES"
twiddle_divisor=3D"16"
verbose_loading=3D"NO"
vesa_load=3D"NO"<= br />vfs.root.mountfrom=3D"zfs:zroot/ROOT/2024-11-06-084833"
vm.exec_m= ap_entries=3D"32"
xz_load=3D"YES"
zfs-bootonce=3D"zfs:zroot/ROOT/= 2024-11-06-084833:"
zfs_be_active=3D"zfs:zroot/ROOT/2024-10-14-160358"
zfs_be_currpag= e=3D"1"
zfs_be_root=3D"zroot/ROOT"
zfs_load=3D"YES"
 
(2) sudo efivar --device-path 8be4df61-93ca-11d2-aa0d-00e098032b8c-Con= In
 
8be4df61-93ca-11d2-aa0d-00e098032b8c-ConIn
: UsbHID(0xffff,0xffff,0x1,0x1),/VenHw(d3987d4b-971a-435f-8caf-4967eb6= 27241)/Uart(38400,8,N,1)/VenVt100()
 
(3) sudo efivar --device-path 8be4df61-93ca-11d2-aa0d-00e098032b8c-Con= Out
 
8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut
: PciRoot(0x0)/Pci(0x= 1,0x0)/AcpiAdr(0x80010300),/VenHw(d3987d4b-971a-435f-8caf-4967eb627241)/Uar= t(38400,8,N,1)/VenVt100()
 
Bye,
Alexander.
 
Warner

On Thu, Nov 7, 2024 at 2:41=E2=80= =AFPM Alexander Leidinger <Alexander@leidinger.net> wrote:

Am 2024-= 11-07 20:59, schrieb Warner Losh:

 

On Wed, Nov 6, 2024 at 3:41=E2=80=AFAM Alexander Leidinger= <Alexande= r@leidinger.net> wrote:

Am 2024-11-02 17:08, schrieb Warner Losh:



On Sat, Nov 2, 2024, 10:03=E2=80=AFAM Alexander Leidinger = <Alexander= @leidinger.net> wrote:
Am 2024-10-30 22:11, schrieb Alexander Leidinger:<= br />
> WARNING! Trying to fire up the kernel, but no device tree b= lob found!

For anyone interested, I opened
https://bugs.freebsd.org/bugzilla/show_bug.cgi?i= d=3D282493 for this.
 
Yea. This is a hang or a bad console. The warning is lame= and misleading.
 
Can you bisect?

Found it.

# git bisect bad
c87b3f0006be9ac5813f= 1ff636f18c9b4a41b08e is the first bad commit
commit c87b3f0006be9ac581= 3f1ff636f18c9b4a41b08e (HEAD)
Author: Warner Losh <imp@FreeBSD.org&= gt;
Date:   Mon Oct 14 15:58:10 2024 -0600

    uart: uart_getenv: check for= NULL class last, not first

    This allows one to specify d= t:XXXX when the default class isn't compiled
    into the ke= rnel. It's not an error to not have a class until we're done
  &n= bsp; parsing the spec, so defer checking until then.

    Sponsored by:     =       Netflix
    Reviewed by:     =        adrian, andrew, markj
    Differe= ntial Revision:  https://reviews.freebsd.org/D47078<= /a>

 sys/dev/uart/uart_subr.c | 14 ++++++= +-------
 1 file changed, 7 insertions(+), 7 deletions(-)

-current as of today without this change boots just fine on the Ampere s= ystem in the Oracle cloud.

 
what's your loader.conf? this should only matter if something is set t= here...  

loader.conf:

autoboot_delay=3D"1"
hw.usb.no_boot_w= ait=3D"0"
beastie_disable=3D"YES"
boot_serial=3D"YES"
loader= _logo=3D"none"
cryptodev_load=3D"YES"
xz_load=3D"YES"
zfs_lo= ad=3D"YES"
geom_eli_load=3D"YES"

tcphpts_load=3D"yes"
tcp_rack_load=3D= "YES"

hw.mca.enabled=3D"1"
vm.exec_map_entr= ies=3D"32"

net.link.ifqmaxlen=3D"256"
net.inet.t= cp.soreceive_stream=3D"1"
kern.random.fortuna.concurrent_read=3D"1"kern.msgbuf_show_timestamp=3D"1"

Bye,
Alexander.

--


--
= http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF
http:/= /www.FreeBSD.org    n= etchild@FreeBSD.org  : PGP 0x8F31830F9F2772BF
--=_9d4c8b632bc81518f5ad9a111033835c-- --=_840859b68618c0d64dfe586f0d6f2eed Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc; size=833 Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmctzSYACgkQEg2wmwP4 2IaYpQ/+IXPn+R9bTc1qX/ZlF5DMLwja6X0GvGHQu2MpyPwShTopwumGbDLxCsJR GJ7egrgnxV6HCaBgxVvWJ7b+I9lOKXADN1JqCwMeNNRVe9gGRYK5g2w1/kJhrDFl mcercYvmife9wi4K0DJAAXE5MAWJrDI6SbmDKyNgPmauLnGUMg7zLV0Jwp/ckGmh ahSNxURup6qcU1i2GtI6pk0hP6fpb8ZiDayxoQCyO08qqmgkIRsIU7ZjN9WnYVhi cAzUVqrECVFxg/nDYurpIHFWtvnWZbzicERyW4IMvWdDrtVUQzNIyXMa+rHwUkPq p82fqECARJci11TWGXmFGiszYTfWEPJAAZWPaiEn/+cYuXjBEQzs52XX1AZ2hY2Q w4BCCjnZFSZohElWrNzqjtaPc/grJYAta0yDc3lakgjLTJWib6qAcQUJtrxBrnEI CKJEABiUZIfE9Or2zZeYbb948CJAj3ISA/JsYMqmeu+cR1thC/z8MwI0IWT/hyk9 pea/lZtIBnwh59xjpF2t5AIHkZZOKwFA0WW9gUCTNNWEorDtggdwQqG/EMs48Tvl BuqNN00qYFAyHU2eev01nzzkCo7FtwA4hJuhWvXKdU6slGjogsYa3lyL2lbXLXB/ xGxI5/bcBauTNS8W6e9UDO8+FtjcfTS5qrYSgRe01/rknqzTGV8= =VqOn -----END PGP SIGNATURE----- --=_840859b68618c0d64dfe586f0d6f2eed-- From nobody Fri Nov 8 10:49:12 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 4XlG0p27QWz5cYwT; Fri, 08 Nov 2024 10:49:46 +0000 (UTC) (envelope-from thj@freebsd.org) Received: from fhigh-a7-smtp.messagingengine.com (fhigh-a7-smtp.messagingengine.com [103.168.172.158]) (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 4XlG0n4Qcyz4C9g; Fri, 8 Nov 2024 10:49:45 +0000 (UTC) (envelope-from thj@freebsd.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=KbL3IngW; spf=softfail (mx1.freebsd.org: 103.168.172.158 is neither permitted nor denied by domain of thj@freebsd.org) smtp.mailfrom=thj@freebsd.org; dmarc=fail reason="No valid SPF, DKIM not aligned (relaxed)" header.from=freebsd.org (policy=none) Received: from phl-compute-02.internal (phl-compute-02.phl.internal [10.202.2.42]) by mailfhigh.phl.internal (Postfix) with ESMTP id AD1E9114016C; Fri, 8 Nov 2024 05:49:41 -0500 (EST) Received: from phl-imap-07 ([10.202.2.97]) by phl-compute-02.internal (MEProxy); Fri, 08 Nov 2024 05:49:41 -0500 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:message-id:mime-version:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1731062981; x=1731149381; bh=Xgc+PZwhlvnPC7JkSRM0hlbSNLKsuaBjiAv KYCEHdGM=; b=KbL3IngWl7UsagTbXH+HZ4atWLYuDCCUhvjPJ0HASycMvlMAUGZ IFBc2jy5+2wCEGRQAHwn5dIcU7DAycKfKHFf0B4v+GPDm+2P0d6DMuARzhi8NoCi pVk7fibtBdQptkjixYlzTR61PHa7+B92AuTZfce8Tn0PwddXXI9PPdrMx4VWYoLu 5omm6GNILBpnBjmK2Add+PISNQNV7Xq5LXQfxx5hHu54MWZAdDP4kllk94zxp6Em KbmOVPgfmgExCcKP/pvlEWe8e+Fr1mkU1rXt+mt8Z0qbngePq+9giq0SWdMbyRZn TEmhj+QhwfzB9gaBPfeYC/Xu4M+tL1gVQkw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrtdeigddujecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdpuffr tefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecunecujfgurhepofggfffhvf fkufgtgfesthejredtredttdenucfhrhhomhepfdfvohhmucflohhnvghsfdcuoehthhhj sehfrhgvvggsshgurdhorhhgqeenucggtffrrghtthgvrhhnpeefvdevhedtheekveffge dtieehhedvgedvteevgffhleehhfefieeuhfeijeetteenucffohhmrghinheprgguvhgv nhhtuhhrihhsthdrmhgvnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomhepthhhjhesfhhrvggvsghsugdrohhrghdpnhgspghrtghpthhtohepvddp mhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepfhhrvggvsghsugdqtghurhhrvghnth esfhhrvggvsghsugdrohhrghdprhgtphhtthhopehfrhgvvggsshguqdhnvghtsehfrhgv vggsshgurdhorhhg X-ME-Proxy: Feedback-ID: ib75146ab:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 34E3CBA006F; Fri, 8 Nov 2024 05:49:41 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Date: Fri, 08 Nov 2024 10:49:12 +0000 From: "Tom Jones" To: freebsd-net@freebsd.org, freebsd-current@freebsd.org Message-Id: <1bd82a50-605f-4fe0-b231-775029e9a4e4@app.fastmail.com> Subject: Network Status Report Week 45 2024 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [-3.48 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.995]; R_DKIM_ALLOW(-0.20)[messagingengine.com:s=fm3]; RWL_MAILSPIKE_VERYGOOD(-0.20)[103.168.172.158:from]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[103.168.172.158:from]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : No valid SPF, DKIM not aligned (relaxed),none]; XM_UA_NO_VERSION(0.01)[]; FREEFALL_USER(0.00)[thj]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim]; ASN(0.00)[asn:151847, ipnet:103.168.172.0/24, country:AU]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-net@freebsd.org]; RCVD_COUNT_THREE(0.00)[3]; R_SPF_SOFTFAIL(0.00)[~all]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; TO_DN_NONE(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[messagingengine.com:+] X-Rspamd-Queue-Id: 4XlG0n4Qcyz4C9g X-Spamd-Bar: --- Hi, I have written a 7th Network Status Report, which you can find here: https://adventurist.me/posts/00333 All prior reports are here: https://adventurist.me/tag/networkstatus https://adventurist.me/fbsd-networkstatus.xml Please let me know by email if you find any of the typos I have hidden throughout the post to encourage engagement. - Tom From nobody Fri Nov 8 12:49:38 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 4XlJgB52Fdz5ch26; Fri, 08 Nov 2024 12:49:42 +0000 (UTC) (envelope-from mmel@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 "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4XlJgB4mL8z4PMm; Fri, 8 Nov 2024 12:49:42 +0000 (UTC) (envelope-from mmel@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1731070182; h=from:from:reply-to: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=9LlXb8H2+LcsXQWJSEEatWWX0dEd4CwU2jjehLmAZVc=; b=ywgyzkItRZ69sndSXhU21GFC6qx4E5XAvnAHQLFUc0CbtNxN3/5aSWlmDqHabQz1hqZev2 964k6O5aQCypVgr3LakZ9eznTaErGhLyHjKPG8GG5zW9jirjf4CGeM6US/clJxSDzbXEjU Rjv8ZiNhL3MC0NjuziJxY/1K2XP6kmywEzNrb9RDAwQDdQY59GE+QSxpnNx3n84g/p/Onx 7kv4ZHGxSS0e5XMhOO7kt6oehSY6tWN8moD61dVF9P8Fn85wLEIikq3BIGnxgsbcKwn8+f W12anITGsQ6t+NU1U8hAh84zjEmmz+1fIafgKFy4LxpXSpIDTd0OEEvZshcXdg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1731070182; h=from:from:reply-to: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=9LlXb8H2+LcsXQWJSEEatWWX0dEd4CwU2jjehLmAZVc=; b=Wq0WEgqCgfil7UTvRaD+/0hLZE6zxc5iaR4AONl8wfUkTMMB07ZFMQD2s44gf0p/ILivgM yOv5DaePB/y4SPcDQD+nFmZRbjYUAdJQljAbl2keBuMhv9AZorqdGQE0D1eeprEXgpsqhz OpY8O4VrG3lI7JHAEvlI0wSRVFjW1XNIdL0Gyh0ASZJ6h4Zzi7ywHE0VyUWFNjgNf8uMJa 0gW/Gw0uN+QXbOBKBH15PSI0TU1hsaH9an8/qRh2C7DQHu1wSHlUHxwvfJt+ARSVweTCcR ICkXsq2CZpkO6rUVt3BjQr/bSYtwzYU0poOjXpLErwrgWTwr9fi8Hsw4KZsJnQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1731070182; a=rsa-sha256; cv=none; b=jIdEThVl+eSeYShVyifIhwsmXi72DMhr6u3q6C7Ou9h3w8kVzaKSQhnRR/zyZ5DYhFgv9i XjbiSqk54yp9Z6wSvJJfPc7bPkQORtZ3L0vC0mMogH8OL4JcI/vWr3S4O/y0qRaUMV2CAp Ru1rw3WzACz/hvbdpqPbEzAw2RY0oSdKxKpWBWqWg/aUpjJnQUXi4AV0SfTBSSJU6qmtqe dK6E0ax5BOYMNcJ4ndSgzXzNP9YdxV0Yf1OgyUOqUrVWbsWH6QhjtrbVTZ4plCg3ffX3qc 4tnR8iDIDydOTTLsmr3NS5Lo6N7Eh8bFK5czKTJQV2reXgtQHpxGwZkVBMx6mw== Received: from [192.168.168.195] (lety.radiolinkplus.cz [109.205.241.143]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: mmel/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4XlJg94zpKzdFl; Fri, 8 Nov 2024 12:49:41 +0000 (UTC) (envelope-from mmel@FreeBSD.org) Message-ID: <4c29d5cb-0a31-4131-a3a9-846fd4ce926f@FreeBSD.org> Date: Fri, 8 Nov 2024 13:49:38 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Reply-To: mmel@FreeBSD.org Subject: Re: Official armv7 PkgBase kernel-NODEBUG installation's USB2 boot gets "Fatal kernel mode data abort: 'Alignment Fault' on write" very early, at least on an OrangePi+ 2ed To: Mark Millard , FreeBSD ARM List , Current FreeBSD , FreeBSD Toolchain Cc: Dimitry Andric , "dougm@freebsd.org" , Kyle Evans References: <74468E62-5A74-4FB4-94F6-599E5BA3A9A1@yahoo.com> Content-Language: cs, en-US From: Michal Meloun In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 08.11.2024 4:15, Mark Millard wrote: > [I narrowed the artifact kernel range for the change in the type of > failure that happens.] > > On Nov 7, 2024, at 17:43, Mark Millard wrote: > >> [The change to LLVM 19 is what leads to the Alignment >> Fault' on write failure. Details later below.] >> >> On Nov 7, 2024, at 01:42, Mark Millard wrote: >> >>> Note: Unfortunately, the panics here are too early for a >>> dump device to be available. >>> >>> Context started PkgBase upgrade from: >>> >>> # uname -apKU >>> FreeBSD OPiP2E-RPi2v1p1 15.0-CURRENT FreeBSD 15.0-CURRENT main-n272821-37798b1d5dd1 GENERIC-NODEBUG arm armv7 1500025 1500025 >>> >>> Installed packages to be UPGRADED: >>> FreeBSD-dtb: 15.snap20241009161500 -> 15.snap20241028121139 [base] >>> FreeBSD-kernel-generic: 15.snap20241011221604 -> 15.snap20241106134422 [base] >>> FreeBSD-kernel-generic-dbg: 15.snap20241011221604 -> 15.snap20241106134422 [base] >>> FreeBSD-kernel-generic-mmccam: 15.snap20241011221604 -> 15.snap20241106134422 [base] >>> FreeBSD-kernel-generic-mmccam-dbg: 15.snap20241011221604 -> 15.snap20241106134422 [base] >>> FreeBSD-kernel-generic-nodebug: 15.snap20241011221604 -> 15.snap20241106134422 [base] >>> FreeBSD-kernel-generic-nodebug-dbg: 15.snap20241011221604 -> 15.snap20241106134422 [base] >>> FreeBSD-src-sys: 15.snap20241011221604 -> 15.snap20241106160110 [base] >>> >>> (Those were installed but the FreeBSD-dtb had linux 6.4 >>> dtb files, not the 6.8 ones. 6.8 ones from a personal build >>> were copied to where they need to be. I've separately >>> reported the 6.4 vs. 6.8 issue.) >>> >>> # ~/pkgbase-snapshot-list.sh >>> Via pkg-static info -C -x '^FreeBSD-' . . . >>> 1 FreeBSD-*-15.snap20241106160110 >>> 6 FreeBSD-*-15.snap20241106134422 >>> 1 FreeBSD-*-15.snap20241028121139 >>> 3 FreeBSD-*-15.snap20241011221604 >>> 2 FreeBSD-*-15.snap20241011210446 >>> 38 FreeBSD-*-15.snap20241011182434 >>> 4 FreeBSD-*-15.snap20241011073851 >>> 5 FreeBSD-*-15.snap20241010141501 >>> 1 FreeBSD-*-15.snap20241010120743 >>> 296 FreeBSD-*-15.snap20241009161500 >>> Instead via /var/cache/pkg/*.snap*.pkg . . . >>> 1 FreeBSD-*-15.snap20241106160110 >>> 6 FreeBSD-*-15.snap20241106134422 >>> 1 FreeBSD-*-15.snap20241028121139 >>> 10 FreeBSD-*-15.snap20241011221604 >>> 2 FreeBSD-*-15.snap20241011210446 >>> 38 FreeBSD-*-15.snap20241011182434 >>> 4 FreeBSD-*-15.snap20241011073851 >>> 5 FreeBSD-*-15.snap20241010141501 >>> 1 FreeBSD-*-15.snap20241010120743 >>> 297 FreeBSD-*-15.snap20241009161500 >>> >>> >>> The failure (kernel-GENERIC-NODEBUG): >>> >>> . . . >>> Root mount waiting for: usbus3 CAM >>> Fatal kernel mode data abort: 'Alignment Fault' on write >>> trapframe: 0xc6c9ac10 >>> FSR=00000801, FAR=db23209b, spsr=20000013 >>> r0 =db232080, r1 =00000000, r2 =00000006, r3 =00000024 >>> r4 =db19e280, r5 =00000000, r6 =00000001, r7 =00000006 >>> r8 =c6c9ad20, r9 =c0b7973c, r10=c092074c, r11=c6c9acb8 >>> r12=00000000, ssp=c6c9aca0, slr=c01b01d8, pc =c01aff88 >>> >>> panic: Fatal abort >>> cpuid = 1 >>> time = 3 >>> KDB: stack backtrace: >>> db_trace_self() at db_trace_self >>> pc = 0xc0667004 lr = 0xc0078630 (db_trace_self_wrapper+0x30) >>> sp = 0xc6c9a9c8 fp = 0xc6c9aae0 >>> db_trace_self_wrapper() at db_trace_self_wrapper+0x30 >>> pc = 0xc0078630 lr = 0xc0328db8 (vpanic+0x140) >>> sp = 0xc6c9aae8 fp = 0xc6c9ab08 >>> r4 = 0x00000100 r5 = 0x00000000 >>> r6 = 0xc084d1f1 r7 = 0xc0b69a94 >>> vpanic() at vpanic+0x140 >>> pc = 0xc0328db8 lr = 0xc0328c78 (vpanic) >>> sp = 0xc6c9ab10 fp = 0xc6c9ab14 >>> r4 = 0xc6c9ac10 r5 = 0x00000013 >>> r6 = 0xdb23209b r7 = 0x00000001 >>> r8 = 0x00000801 r9 = 0x00000013 >>> r10 = 0xdb23209b >>> vpanic() at vpanic >>> pc = 0xc0328c78 lr = 0xc068c8e8 (abort_align) >>> sp = 0xc6c9ab1c fp = 0xc6c9ab48 >>> r4 = 0x00000001 r5 = 0x00000801 >>> r6 = 0x00000013 r7 = 0xdb23209b >>> r8 = 0xc6c9ab14 r9 = 0xc0328c78 >>> r10 = 0xc6c9ab1c >>> abort_align() at abort_align >>> pc = 0xc068c8e8 lr = 0xc068c958 (abort_align+0x70) >>> sp = 0xc6c9ab50 fp = 0xc6c9ab68 >>> r4 = 0xc6d21c00 r10 = 0xdb23209b >>> abort_align() at abort_align+0x70 >>> pc = 0xc068c958 lr = 0xc068c5e0 (abort_handler+0x430) >>> sp = 0xc6c9ab70 fp = 0xc6c9ac08 >>> r4 = 0x00000000 r10 = 0xdb23209b >>> abort_handler() at abort_handler+0x430 >>> pc = 0xc068c5e0 lr = 0xc0669868 (exception_exit) >>> sp = 0xc6c9ac10 fp = 0xc6c9acb8 >>> r4 = 0xdb19e280 r5 = 0x00000000 >>> r6 = 0x00000001 r7 = 0x00000006 >>> r8 = 0xc6c9ad20 r9 = 0xc0b7973c >>> r10 = 0xc092074c >>> exception_exit() at exception_exit >>> pc = 0xc0669868 lr = 0xc01b01d8 (usb_msc_auto_quirk+0xfc) >>> sp = 0xc6c9aca0 fp = 0xc6c9acb8 >>> r0 = 0xdb232080 r1 = 0x00000000 >>> r2 = 0x00000006 r3 = 0x00000024 >>> r4 = 0xdb19e280 r5 = 0x00000000 >>> r6 = 0x00000001 r7 = 0x00000006 >>> r8 = 0xc6c9ad20 r9 = 0xc0b7973c >>> r10 = 0xc092074c r12 = 0x00000000 >>> bbb_command_start() at bbb_command_start+0x4c >>> pc = 0xc01aff88 lr = 0xc01b01d8 (usb_msc_auto_quirk+0xfc) >>> sp = 0xc6c9acc0 fp = 0xc6c9acf8 >>> r4 = 0xdb16d800 r5 = 0xdb19e280 >>> r6 = 0x00000001 r10 = 0xc092074c >>> usb_msc_auto_quirk() at usb_msc_auto_quirk+0xfc >>> pc = 0xc01b01d8 lr = 0xc01a4bd8 (usb_alloc_device+0x9c4) >>> sp = 0xc6c9ad00 fp = 0xc6c9ad68 >>> r4 = 0x00000000 r5 = 0x00000001 >>> r6 = 0x00000000 r7 = 0x00000002 >>> r8 = 0xdb16d800 r9 = 0xda241c78 >>> r10 = 0x000003ee >>> usb_alloc_device() at usb_alloc_device+0x9c4 >>> pc = 0xc01a4bd8 lr = 0xc01ad16c (uhub_explore+0x494) >>> sp = 0xc6c9ad70 fp = 0xc6c9adc0 >>> r4 = 0x00000000 r5 = 0x00000000 >>> r6 = 0xdb16e800 r7 = 0x00000000 >>> r8 = 0xdb18c200 r9 = 0x00000001 >>> r10 = 0x00000000 >>> uhub_explore() at uhub_explore+0x494 >>> pc = 0xc01ad16c lr = 0xc0198654 (usb_bus_explore+0x1d4) >>> sp = 0xc6c9adc8 fp = 0xc6c9add8 >>> r4 = 0xda241c78 r5 = 0xdb16e800 >>> r6 = 0x00000000 r7 = 0xda241d6c >>> r8 = 0xc09b0b5f r9 = 0x00000001 >>> r10 = 0xda241d1c >>> usb_bus_explore() at usb_bus_explore+0x1d4 >>> pc = 0xc0198654 lr = 0xc01b22d0 (usb_process+0x124) >>> sp = 0xc6c9ade0 fp = 0xc6c9ae10 >>> r4 = 0xda241d0c r5 = 0xda241d14 >>> usb_process() at usb_process+0x124 >>> pc = 0xc01b22d0 lr = 0xc02da4f0 (fork_exit+0xb0) >>> sp = 0xc6c9ae18 fp = 0xc6c9ae38 >>> r4 = 0xc6c9ae40 r5 = 0xc6d21c00 >>> r6 = 0xc6d08740 r7 = 0xda241d0c >>> r8 = 0xc01b21ac r9 = 0x00000000 >>> r10 = 0x00000000 >>> fork_exit() at fork_exit+0xb0 >>> pc = 0xc02da4f0 lr = 0xc06697fc (swi_exit) >>> sp = 0xc6c9ae40 fp = 0x00000000 >>> r4 = 0xc01b21ac r5 = 0xda241d0c >>> r6 = 0x00000000 r7 = 0x00000000 >>> r8 = 0x00000000 r10 = 0x00000000 >>> swi_exit() at swi_exit >>> pc = 0xc06697fc lr = 0xc06697fc (swi_exit) >>> sp = 0xc6c9ae40 fp = 0x00000000 >>> KDB: enter: panic >>> [ thread pid 14 tid 100069 ] >>> Stopped at kdb_enter+0x54: ldrb r15, [r15, r15, ror r15]! >>> db> >> >> Using just available official artifact kernels for testing >> I've established that 0953460ce149 (and various from before >> that) does not have the problem: >> >> Wed, 23 Oct 2024 >> • git: 5c92f84bb607 - main - LinuxKPI: update rcu_dereference_*() and lockdep_is_held() Bjoern A. Zeeb >> • git: 6fa91acca40d - main - conf/NOTES: Remove trailing whitespace Li-Wen Hsu >> • git: 91b7b225b2ce - main - LINT: Add mac_do Li-Wen Hsu >> • git: 419249c1cacc - main - Revert "LINT: Add mac_do" Li-Wen Hsu >> • Re: git: 419249c1cacc - main - Revert "LINT: Add mac_do" Baptiste Daroussin >> • Re: git: 13da1af1cd67 - main - libcxxrt: Update to upstream 698997bfde1f John Baldwin >> • Re: git: 419249c1cacc - main - Revert "LINT: Add mac_do" John Baldwin >> • git: 0953460ce149 - main - libc: fix access mode tests in fmemopen(3) Ed Maste >> >> So the above one worked. >> >> The next available kernel to test was f3dbef108212 (the bump for LLVM19 >> at the end of the below): >> >> • RE: git: 6a07e67fb7a8 - main - vm_meter: Fix laundry accounting Mark Millard >> • git: 6b9f7133aba4 - main - libc: Add one more check in new fmemopen test Ed Maste >> • git: 0fca6ea1d4ee - main - Merge llvm-project main llvmorg-19-init-18630-gf2ccf80136a0 Dimitry Andric >> • git: 36b606ae6aa4 - main - Merge llvm-project release/19.x llvmorg-19.1.0-rc1-0-ga4902a36d5c2 Dimitry Andric >> • git: 3f157662c0ef - main - Tentatively apply https://github.com/llvm/llvm-project/pull/101403 Dimitry Andric >> • git: d575077527d4 - main - bsd.sys.mk: for clang >= 19, similar to gcc >= 8.1, turn off -Werror for -Wcast-function-type-mismatch. Dimitry Andric >> • git: 36d486cc2ecd - main - Fix enum warning in ath_hal's ar9002 Dimitry Andric >> • git: 6846ab2fb663 - main - libcxx simd_utils.h: only enable _LIBCPP_HAS_ALGORITHM_VECTOR_UTILS for clang >= 15, since older versions do not support the required builtins. Dimitry Andric >> • git: 81e300df5e65 - main - libcxx atomic_ref.h: add typename keyword for difference_type declarations, otherwise older clang versions cannot compile this header. Dimitry Andric >> • git: 6b4981df6008 - main - libcxx cstdlib, cwchar: avoid using long long functions if not supported, even for older compilers that do not support the using_if_exists attribute. Dimitry Andric >> • git: 2f6d6eaf2d51 - main - libcxx-compat: revert llvmorg-19-init-18063-g561246e90282: Dimitry Andric >> • git: 04f5b79cfa49 - main - libcxx-compat: revert llvmorg-19-init-18062-g4dfa75c663e5: Dimitry Andric >> • git: e8054e44f4ca - main - libcxx-compat: revert llvmorg-19-init-17853-g578c6191eff7: Dimitry Andric >> • git: 0bec0529b1d7 - main - libcxx-compat: revert llvmorg-19-init-17728-g30cc12cd818d: Dimitry Andric >> • git: e8847079df1b - main - libcxx-compat: revert llvmorg-19-init-17727-g0eebb48fcfbc: Dimitry Andric >> • git: 2f2ebe758bea - main - libcxx-compat: revert llvmorg-19-init-17473-g69fecaa1a455: Dimitry Andric >> • git: 1199d38d8ec7 - main - libcxx-compat: revert llvmorg-19-init-8667-g472b612ccbed: Dimitry Andric >> • git: a7b2d7f261b8 - main - libcxx-compat: revert llvmorg-19-init-5639-ga10aa4485e83: Dimitry Andric >> • git: f3859a1a13a1 - main - libcxx-compat: revert llvmorg-19-init-4504-g937a5396cf3e: Dimitry Andric >> • git: 072b5fb698ab - main - libcxx-compat: revert llvmorg-19-init-4003-g55357160d0e1: Dimitry Andric >> • git: b60301d8b594 - main - libcxx-compat: don't remove headers that were reintroduced by reverts Dimitry Andric >> • git: 2e861daab905 - main - libcxx-compat: install headers that were reintroduced by reverts Dimitry Andric >> • git: ff6c8447844b - main - libcxx-compat: update libcxx.imp for headers that were reintroduced by reverts Dimitry Andric >> • git: 52418fc2be8e - main - Merge llvm-project release/19.x llvmorg-19.1.0-rc2-0-gd033ae172d1c Dimitry Andric >> • git: 62987288060f - main - Merge llvm-project release/19.x llvmorg-19.1.0-rc3-0-g437434df21d8 Dimitry Andric >> • git: 6c4b055cfb6b - main - Merge llvm-project release/19.x llvmorg-19.1.0-rc4-0-g0c641568515a Dimitry Andric >> • git: 835c3a3e69af - main - Merge commit 6dbdb8430b49 from llvm git (by Nikolas Klauser): Dimitry Andric >> • git: c80e69b00d97 - main - Merge llvm-project release/19.x llvmorg-19.1.0-0-ga4bf6cd7cfb1 Dimitry Andric >> • git: 6e516c87b6d7 - main - Merge llvm-project release/19.x llvmorg-19.1.1-0-gd401987fe349 Dimitry Andric >> • git: 5deeebd8c6ca - main - Merge llvm-project release/19.x llvmorg-19.1.2-0-g7ba7d8e2f7b6 Dimitry Andric >> • git: f3dbef108212 - main - Bump __FreeBSD_version for llvm 19.1.2 merge Dimitry Andric >> >> f3dbef108212 gets the: >> >> "Fatal kernel mode data abort: 'Alignment Fault' on write" >> >> boot failure for artifact kernel. 6b9f7133aba4 does nit >> seem a likely source of the problem, basically leaving the >> LLVM changes as what is at issue. >> >> I'll note that artifact kernels are witness kernels. So >> this exploration adds to the distinctions observed >> compared to the prior notes. >> >>> Looking at bbb_command_start() 's pc: >>> >>> # llvm-addr2line -e /boot/kernel.GENERIC-NODEBUG/kernel 0xc01aff88 >>> /home/pkgbuild/worktrees/main/sys/dev/usb/usb_msctest.c:554 >>> >>> What leads to that line is: >>> >>> /*------------------------------------------------------------------------* >>> * bbb_command_start - execute a SCSI command synchronously >>> * >>> * Return values >>> * 0: Success >>> * Else: Failure >>> *------------------------------------------------------------------------*/ >>> static int >>> bbb_command_start(struct bbb_transfer *sc, uint8_t dir, uint8_t lun, >>> void *data_ptr, size_t data_len, void *cmd_ptr, size_t cmd_len, >>> usb_timeout_t data_timeout) >>> { >>> sc->lun = lun; >>> sc->dir = data_len ? dir : DIR_NONE; >>> sc->data_ptr = data_ptr; >>> sc->data_len = data_len; >>> sc->data_rem = data_len; >>> sc->data_timeout = (data_timeout + USB_MS_HZ); >>> sc->actlen = 0; >>> sc->error = 0; >>> sc->cmd_len = cmd_len; >>> memset(&sc->cbw->CBWCDB, 0, sizeof(sc->cbw->CBWCDB)); >>> >>> The memset line is line 554 of sys/dev/usb/usb_msctest.c . >> >> The below looks to be a separate problem based on >> some later FreeBSD kernel update than the above. >> >>> I'll note that attempting to use the WITNESS variant of the kernel >>> ( /boot/kernel/ ) gets a different, even earlier failure: >>> >>> . . . >>> VT: init without driver. >>> panic: acquiring blockable sleep lock with spinlock or critical section held (sleep mutex) pmap @ /home/pkgbuild/worktrees/main/sys/arm/arm/pmap-v6.c:6455 >> >> I do know that d021d3b3c675 at the end of the below >> shows this failure --before the system has a chance >> to get the usb related write alignment failure >> reported above. >> >> I have not explored where in the below range the >> behavior changes (for what is available as an >> official artifact kernel). It seems unlikely that >> any of the below would actually boot: it is likely >> a question of which of the 2 (or more) failure >> types happen for each instead. > > The last before "Thu, 24, Oct 2024" was: > > • git: 8b2e7da70855 - main - llvm19: permit incremental builds from llvm18 Brooks Davis > > That is the last available artifact kernel that gets the > original usb related write alignment type of failure. > >> Thu, 24 Oct 2024 >> • git: 34951b0b9e78 - main - swap_pager: move scan_all_shadowed, use iterators Doug Moore >> • git: 2ac21f2c98ed - main - x86 specialreg.h: visually align %cr4 and MSR_EFER bit mask definitions Konstantin Belousov >> • git: cc11bc1150d5 - main - x86 specialreg.h: add all defined bits for %cr4 Konstantin Belousov >> • git: cc4b25f10211 - main - x86 specialreg: reorder %cr3 bits masks definitions by value Konstantin Belousov >> • git: 5999b74e9637 - main - x86 specialreg: add bit masks definitions for LAM in %cr3 Konstantin Belousov >> • git: 6308db659f2a - main - x86 specialreg: add bit masks definitions for EFER features Konstantin Belousov >> • git: 9f718b57b846 - main - x86 specialreg: add bit masks definitions for LASS and LAM features Konstantin Belousov >> • git: 3360a15898ce - main - net: route: convert routing statistics to a sysctl Kyle Evans >> • Re: git: 3360a15898ce - main - net: route: convert routing statistics to a sysctl Kyle Evans >> • git: 77b70ad751df - main - e1000: Move I219 LM19/V19 to ADL Kevin Bowling > > The last above is the first available artifact kernel that > that gets the different error. There are no armv7 artifact > kernels between 8b2e7da70855 and 77b70ad751df . > > So something from 34951b0b9e78 .. 77b70ad751df leads to > the change in the type of failure. I've no clue what. > > It looked to me like the x86 commits and e1000 commit had > no chance of contributing to the armv7 context. Thus > who I added to the CC vs. did not add. > >> • git: d64442a89896 - main - arm{,64}: use genassym for INTR_ROOT_* values Kyle Evans >> • git: 536c8d948e85 - main - intrng: change multi-interrupt root support type to enum Kyle Evans >> • git: 4f12b529f404 - main - sys/intr.h: formally depend on machine/intr.h Kyle Evans >> • git: a5b1eecbed07 - main - Apply workaround for building llvm-project with WITHOUT_LLVM_ASSERTIONS Dimitry Andric >> • git: 1c83996beda7 - main - Adjust LLVM_ENABLE_ABI_BREAKING_CHECKS depending on NDEBUG Dimitry Andric >> • git: b2dd4970c7b5 - main - dev/gpio: Mask all pl011 interrupts Andrew Turner >> • git: 3b03e1bb8615 - main - intrng: Store the IPI priority Andrew Turner >> • git: 6204391e99ca - main - arm64: Check TDP_NOFAULTING in a data abort Andrew Turner >> • git: a84653c5db25 - main - arm64: Don't enable interrupts when in a spinlock Andrew Turner >> • git: d7f930b80e89 - main - arm64: Implement efi_rt_arch_call Andrew Turner >> • git: 8efb1500d4f1 - main - arm64: Enable handling EFI runtime service faults Andrew Turner >> • git: 9693241188aa - main - sound: Call DSP_REGISTERED before PCM_DETACHING Christos Margiolis >> • git: bb5e3ac1a7b7 - main - sound: Use DSP_REGISTERED in dsp_clone() Christos Margiolis >> • git: a4111e9dc722 - main - sound: Change PCMDIR_* numbering Christos Margiolis >> • git: 802c78f5194e - main - sound: Untangle dsp_cdevs[] and dsp_unit2name() confusion Christos Margiolis >> • git: b1bb6934bb87 - main - sound: Fix build error in chm_mkname() KASSERT Christos Margiolis >> • git: ce20b48a60fb - main - sctp: improve debug output Michael Tuexen >> • git: e4ac0183a1a8 - main - sctp: cleanup Michael Tuexen >> • git: 8c8ebbb04518 - main - bhyve ahci: Improve robustness of TRIM handling John Baldwin >> • git: f0bc751d6fb4 - main - csa: Use pci_find_device to simplify clkrun_hack John Baldwin >> • git: d96ba5a62365 - main - config: Remove a stray semicolon Zhenlei Huang >> • git: 56b17de1e836 - main - makefs: Remove a stray semicolon Zhenlei Huang >> • git: 88b71d1fe054 - main - arm64: rockchip: Remove a stray semicolon Zhenlei Huang >> • git: b4856b8e9d87 - main - LinuxKPI: Remove stray semicolons Zhenlei Huang >> • git: 75ff90814aec - main - enic: Remove a stray semicolon Zhenlei Huang >> • git: 6ccf4f4071c5 - main - mana: Remove stray semicolons Zhenlei Huang >> • git: 86a2c910c05c - main - mpi3mr: Remove a stray semicolon Zhenlei Huang >> • git: 36756195a342 - main - ocs_fc: Remove a stray semicolon Zhenlei Huang >> • git: 2f395cfda8b5 - main - tcp cc: Remove a stray semicolon Zhenlei Huang >> • git: f3a097d0312c - main - netstat: switch to using the sysctl-exported stats for live stats Kyle Evans >> • git: 656991b0c629 - main - locks: augment lock_class with lc_trylock method Gleb Smirnoff >> • git: efcb2ec8cb81 - main - callout: provide CALLOUT_TRYLOCK flag Gleb Smirnoff >> • git: bffebc336f4e - main - tcp: use CALLOUT_TRYLOCK for the TCP callout Gleb Smirnoff >> • git: d021d3b3c675 - main - tcp: get rid of TDP_INTCPCALLOUT Gleb Smirnoff > > > >>> cpuid = 0 >>> time = 1 >>> KDB: stack backtrace: >>> Fatal kernel mode data abort: 'Translation Fault (L1)' on read >>> trapframe: 0xc0f14568 >>> FSR=00000005, FAR=db7fcfb1, spsr=200001d3 >>> r0 =c0f1465c, r1 =00000001, r2 =db7fcfae, r3 =1b000a4e >>> r4 =c07fc55c, r5 =8fce1b89, r6 =00006f3e, r7 =81000000 >>> r8 =c07c4b6c, r9 =c094ace8, r10=c09741d8, r11=c0f14618 >>> r12=c0f146c4, ssp=c0f145fc, slr=c0601428, pc =c062686c >>> >>> panic: Fatal abort >>> cpuid = 0 >>> time = 1 >>> KDB: stack backtrace: >>> Fatal kernel mode data abort: 'Translation Fault (L1)' on read >>> trapframe: 0xc0f141f0 >>> FSR=00000005, FAR=db7fcfb1, spsr=200001d3 >>> r0 =c0f142e4, r1 =00000001, r2 =db7fcfae, r3 =1b000a4e >>> r4 =c07fc55c, r5 =8fce1b89, r6 =00006f3e, r7 =81000000 >>> r8 =c07c4b6c, r9 =c094ace8, r10=c09741d8, r11=c0f142a0 >>> r12=c0f1434c, ssp=c0f14284, slr=c0601428, pc =c062686c >>> >>> panic: Fatal abort >>> cpuid = 0 >>> time = 1 >>> KDB: stack backtrace: >>> Fatal kernel mode data abort: 'Translation Fault (L1)' on read >>> trapframe: 0xc0f13e78 >>> FSR=00000005, FAR=db7fcfb1, spsr=200001d3 >>> r0 =c0f13f6c, r1 =00000001, r2 =db7fcfae, r3 =1b000a4e >>> r4 =c07fc55c, r5 =8fce1b89, r6 =00006f3e, r7 =81000000 >>> r8 =c07c4b6c, r9 =c094ace8, r10=c09741d8, r11=c0f13f28 >>> r12=c0f13fd4, ssp=c0f13f0c, slr=c0601428, pc =c062686c >>> >>> panic: Fatal abort >>> cpuid = 0 >>> time = 1 >>> KDB: stack backtrace: >>> Fatal kernel mode data abort: 'Translation Fault (L1)' on read >>> trapframe: 0xc0f13b00 >>> FSR=00000005, FAR=db7fcfb1, spsr=200001d3 >>> r0 =c0f13bf4, r1 =00000001, r2 =db7fcfae, r3 =1b000a4e >>> r4 =c07fc55c, r5 =8fce1b89, r6 =00006f3e, r7 =81000000 >>> r8 =c07c4b6c, r9 =c094ace8, r10=c09741d8, r11=c0f13bb0 >>> r12=c0f13c5c, ssp=c0f13b94, slr=c0601428, pc =c062686c >>> >>> panic: Fatal abort >>> cpuid = 0 >>> time = 1 >>> KDB: stack backtrace: >>> Fatal kernel mode data abort: 'Translation Fault (L1)' on read >>> trapframe: 0xc0f13788 >>> FSR=00000005, FAR=db7fcfb1, spsr=200001d3 >>> r0 =c0f1387c, r1 =00000001, r2 =db7fcfae, r3 =1b000a4e >>> r4 =c07fc55c, r5 =8fce1b89, r6 =00006f3e, r7 =81000000 >>> r8 =c07c4b6c, r9 =c094ace8, r10=c09741d8, r11=c0f13838 >>> r12=c0f138e4, ssp=c0f1381c, slr=c0601428, pc =c062686c >>> >>> . . . >>> >>> Looking: >>> >>> # llvm-addr2line -e /boot/kernel.GENERIC-NODEBUG/kernel 0xc062686c >>> /home/pkgbuild/worktrees/main/sys/vm/uma_core.c:5676 >>> >>> static int >>> sysctl_handle_uma_zone_frees(SYSCTL_HANDLER_ARGS) >>> { >>> uma_zone_t zone = arg1; >>> uint64_t cur; >>> >>> cur = uma_zone_get_frees(zone); >>> return (sysctl_handle_64(oidp, &cur, 0, req)); >>> } >>> >>> The "return" line is 5676 of sys/vm/uma_core.c . >>> >>> >>> Also, for what leads up to: >>> >>> /home/pkgbuild/worktrees/main/sys/arm/arm/pmap-v6.c:6455 >>> >>> /* >>> * The implementation of pmap_fault() uses IN_RANGE2() macro which >>> * depends on the fact that given range size is a power of 2. >>> */ >>> CTASSERT(powerof2(NB_IN_PT1)); >>> CTASSERT(powerof2(PT2MAP_SIZE)); >>> >>> #define IN_RANGE2(addr, start, size) \ >>> ((vm_offset_t)(start) == ((vm_offset_t)(addr) & ~((size) - 1))) >>> >>> /* >>> * Handle access and R/W emulation faults. >>> */ >>> int >>> pmap_fault(pmap_t pmap, vm_offset_t far, uint32_t fsr, int idx, bool usermode) >>> { >>> pt1_entry_t *pte1p, pte1; >>> pt2_entry_t *pte2p, pte2; >>> >>> if (pmap == NULL) >>> pmap = kernel_pmap; >>> >>> /* >>> * In kernel, we should never get abort with FAR which is in range of >>> * pmap->pm_pt1 or PT2MAP address spaces. If it happens, stop here >>> * and print out a useful abort message and even get to the debugger >>> * otherwise it likely ends with never ending loop of aborts. >>> */ >>> if (__predict_false(IN_RANGE2(far, pmap->pm_pt1, NB_IN_PT1))) { >>> /* >>> * All L1 tables should always be mapped and present. >>> * However, we check only current one herein. For user mode, >>> * only permission abort from malicious user is not fatal. >>> * And alignment abort as it may have higher priority. >>> */ >>> if (!usermode || (idx != FAULT_ALIGN && idx != FAULT_PERM_L2)) { >>> CTR4(KTR_PMAP, "%s: pmap %#x pm_pt1 %#x far %#x", >>> __func__, pmap, pmap->pm_pt1, far); >>> panic("%s: pm_pt1 abort", __func__); >>> } >>> return (KERN_INVALID_ADDRESS); >>> } >>> if (__predict_false(IN_RANGE2(far, PT2MAP, PT2MAP_SIZE))) { >>> /* >>> * PT2MAP should be always mapped and present in current >>> * L1 table. However, only existing L2 tables are mapped >>> * in PT2MAP. For user mode, only L2 translation abort and >>> * permission abort from malicious user is not fatal. >>> * And alignment abort as it may have higher priority. >>> */ >>> if (!usermode || (idx != FAULT_ALIGN && >>> idx != FAULT_TRAN_L2 && idx != FAULT_PERM_L2)) { >>> CTR4(KTR_PMAP, "%s: pmap %#x PT2MAP %#x far %#x", >>> __func__, pmap, PT2MAP, far); >>> panic("%s: PT2MAP abort", __func__); >>> } >>> return (KERN_INVALID_ADDRESS); >>> } >>> >>> /* >>> * A pmap lock is used below for handling of access and R/W emulation >>> * aborts. They were handled by atomic operations before so some >>> * analysis of new situation is needed to answer the following question: >>> * Is it safe to use the lock even for these aborts? >>> * >>> * There may happen two cases in general: >>> * >>> * (1) Aborts while the pmap lock is locked already - this should not >>> * happen as pmap lock is not recursive. However, under pmap lock only >>> * internal kernel data should be accessed and such data should be >>> * mapped with A bit set and NM bit cleared. If double abort happens, >>> * then a mapping of data which has caused it must be fixed. Further, >>> * all new mappings are always made with A bit set and the bit can be >>> * cleared only on managed mappings. >>> * >>> * (2) Aborts while another lock(s) is/are locked - this already can >>> * happen. However, there is no difference here if it's either access or >>> * R/W emulation abort, or if it's some other abort. >>> */ >>> >>> PMAP_LOCK(pmap); >>> >>> That "PMAP_LOCK(pmap);" line is line 6455 of sys/arm/arm/pmap-v6.c . >>> >>> >>> FYI: Running the prior kernel.GENERIC-NODEBUG/ ( called >>> kernel.GENERIC-NODEBUG.good/ ) continues to operate >>> normally. I do not have the older PkgBase kernel/ around >>> to try, unfortunately. > > I'll remind that this is from using official FreeBSD builds > of the kernel versions that I tested, not from my personal > build context. > > > === > Mark Millard > marklmi at yahoo.com > > Hi Mark, Please see https://reviews.freebsd.org/D47485 Unfortunately, I see 2 problems with llvm 19. The first is regression, the compiler generates inline memset() accessing non-aligned data with sub-optimal instructions (with word access). This regression triggers bug in the kernel (which should be fixed in D47485). Second, regarding "panic: acquiring blockable sleep lock" is due to an bug in lld. It mis-links the ".ARM.exidx" section on the output binary, which is used by the stack unwinder in the kernel. I don't have a fix for this for now, so you have to use the linker from llvm18 as a workaround. I'm not sure if I have enough free cycles to manage both issues on the llvm side... Michal From nobody Fri Nov 8 13:27:38 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 4XlKWD11W2z5ckby for ; Fri, 08 Nov 2024 13:27:52 +0000 (UTC) (envelope-from wlosh@bsdimp.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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4XlKWC5xMGz4Stn for ; Fri, 8 Nov 2024 13:27:51 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pg1-x529.google.com with SMTP id 41be03b00d2f7-7f12ba78072so1650591a12.2 for ; Fri, 08 Nov 2024 05:27:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1731072470; x=1731677270; 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=2hNyF2SR+XkdirHUng5ozTTof/e+jZoeA/kBRzfVY1c=; b=n3J32Unx9PSd4REXEd83K0iaxxvE4P9g6rC+zOf58rLnsBq71K+83n/KSKpDOoB9Df C2t1HzK63CnEqd2+DjN/D+i5LtPB4CObCP12rylAtFhgwaQ0O37H4sX/bf1at+0dPt8S IgU4INP1DRNUtT8Gg+pgeAzfjS6ktDO6qMopSUFsCraBh5Ph0AFXi70i08B03a1DBTU3 T1KN2HX03ZwxS7FBtWdSyEa9ceaC0sF2n9zCgML+W2S+HqulkE2VCGvxlcUuqKoRc9Ed F5LP5cih7MRx549y46lYQxxzfwtcRHnFTIRDlUVS2SL/lScwq+Pc+iOiJarI+ohN8IZC Id2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731072470; x=1731677270; 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=2hNyF2SR+XkdirHUng5ozTTof/e+jZoeA/kBRzfVY1c=; b=mqhy3fe5Z3Ld6XwHSL3HFkvs0XlVseFR66kRMTz/UQ18qzbxW+4Yr10ktWL9019+Xn mwoqZ27iEfzJV/3BJs25n0Do0c2kPCjVOOl0Ch1s6gs16MrNLxvGwZ5L9+MM1ffpHDwC PYHmUkBNTgoIAPMa1VXJFC8aZahd3+ffbTtVM2OOj98GmLbp4zEzd61pO0n4Yxn1h/Su gbvtxTFsmsjg3wHUSqE1zH7QwWrqiTJiO+c5kiZd8EDEzz5tXzBcvLbceT6W1IbPD2ms v1Jh8Ar/ElqCH0nuZY43N4M6V6mhAlU+qlRG9TYuQ3H6Yl1vSWQRKV1G/vip6DDbXjVI QbMQ== X-Gm-Message-State: AOJu0YwPePwHtzP4oTqVArFYv6Ttc5Etp4IUVsHgxmVILd9iqoHqXFeL c4S6lzu/ozKjOY0Sg5srPNcah3RSnfy3s+G+Ey+yKqHaNVmEx0RRcmKb+gcsNh04aO5ES2lkmAl 5QGKBvdFQE/fLcVUo1wR3zyFpXywi+NaloTjC6wrw0Csv4C40 X-Google-Smtp-Source: AGHT+IGo0ag6ldI5daOUqFUAtKAWHX+iPYbYPQ+jhkBwe4r4zomOumrzv0bXJU2sP94QfLcmDEPojh9DMH/JhayJohg= X-Received: by 2002:a17:90b:3811:b0:2e9:2329:8d98 with SMTP id 98e67ed59e1d1-2e9b16ef07amr3572967a91.8.1731072470338; Fri, 08 Nov 2024 05:27:50 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: <8cf9adb0e7ca6340460c695ffd64a0df@Leidinger.net> <896b9ce404ffcb126dcdd6008583b117@Leidinger.net> <132ca9158817a4706d1b9e78c3567973@Leidinger.net> <0389774b2a7a86ebf538807f71239802@Leidinger.net> In-Reply-To: <0389774b2a7a86ebf538807f71239802@Leidinger.net> From: Warner Losh Date: Fri, 8 Nov 2024 05:27:38 -0800 Message-ID: Subject: Re: No valid device tree blob found! To: Alexander Leidinger Cc: Current FreeBSD Content-Type: multipart/alternative; boundary="000000000000aceb92062666b75b" 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: 4XlKWC5xMGz4Stn X-Spamd-Bar: ---- --000000000000aceb92062666b75b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Nov 8, 2024, 12:34=E2=80=AFAM Alexander Leidinger wrote: > Am 2024-11-08 05:46, schrieb Warner Losh: > > OK. I'm confused... but no matter. > > Three more things to help... > (1) kenv after boot with a fixed kernel > > > COLUMNS=3D"100" > LINES=3D"31" > acpi.oem=3D"BOCHS " > acpi.revision=3D"2" > acpi.rsdp=3D"0x00000006385c0018" > acpi.rsdt=3D"0x0000000000000000" > acpi.xsdt=3D"0x00000006385cfe98" > acpi.xsdt_length=3D"36" > acpi_dsdt_load=3D"NO" > acpi_dsdt_name=3D"/boot/acpi_dsdt.aml" > acpi_dsdt_type=3D"acpi_dsdt" > acpi_video_load=3D"NO" > audit_event_load=3D"NO" > audit_event_name=3D"/etc/security/audit_event" > audit_event_type=3D"etc_security_audit_event" > autoboot_delay=3D"1" > beastie_disable=3D"YES" > bitmap_load=3D"NO" > bitmap_name=3D"splash.bmp" > bitmap_type=3D"splash_image_data" > boot_multicons=3D"YES" > boot_serial=3D"YES" > bootenv_autolist=3D"YES" > bootenvs[0]=3D"zfs:zroot/ROOT/2024-10-30-121420_ko" > bootenvs[10]=3D"zfs:zroot/ROOT/2024-07-15-110946" > bootenvs[11]=3D"zfs:zroot/ROOT/2024-09-12-140543" > bootenvs[1]=3D"zfs:zroot/ROOT/2024-10-14-233343_ko" > bootenvs[2]=3D"zfs:zroot/ROOT/2024-10-14-160359" > bootenvs[3]=3D"zfs:zroot/ROOT/2024-10-14-160358" > bootenvs[4]=3D"zfs:zroot/ROOT/2024-10-13-232308" > bootenvs[5]=3D"zfs:zroot/ROOT/2024-10-14-102617" > bootenvs[6]=3D"zfs:zroot/ROOT/2024-10-11-084349" > bootenvs[7]=3D"zfs:zroot/ROOT/2024-11-06-084833" > bootenvs[8]=3D"zfs:zroot/ROOT/2024-08-15-222928" > bootenvs[9]=3D"zfs:zroot/ROOT/2024-07-16-094205" > bootenvs_count=3D"12" > bootfile=3D"kernel" > console=3D"efi" > cpu_microcode_load=3D"NO" > cpu_microcode_name=3D"/boot/firmware/ucode.bin" > cpu_microcode_type=3D"cpu_microcode" > cryptodev_load=3D"YES" > currdev=3D"zfs:zroot/ROOT/2024-11-06-084833:" > efi-version=3D"2.70" > efi_com_port=3D"0" > efi_com_speed=3D"38400" > efi_max_resolution=3D"1x1" > entropy_cache_load=3D"YES" > entropy_cache_name=3D"/boot/entropy" > entropy_cache_type=3D"boot_entropy_cache" > entropy_efi_seed=3D"YES" > entropy_efi_seed_size=3D"2048" > geom_eli_load=3D"YES" > hint.acpi.0.disabled=3D"0" > hint.smbios.0.mem=3D"0x63bed0000" > hostuuid_load=3D"YES" > hostuuid_name=3D"/etc/hostid" > hostuuid_type=3D"hostuuid" > hw.mca.enabled=3D"1" > hw.uart.console=3D"db:8,dt:pl011,mm:0x9000000,rs:0,rw:1,pa:none,br:9600,x= o=3D0" > hw.usb.no_boot_wait=3D"0" > kern.msgbuf_show_timestamp=3D"1" > kern.random.fortuna.concurrent_read=3D"1" > kernel=3D"kernel" > kernel_options=3D"" > kernel_path=3D"/boot/kernel" > kernelname=3D"/boot/kernel/kernel" > kernels_autodetect=3D"YES" > loaddev=3D"zfs:zroot/ROOT/2024-11-06-084833:" > loader.efi=3D"1" > loader_conf_dirs=3D"/boot/loader.conf.d" > loader_logo=3D"none" > local_loader_conf_files=3D"/boot/loader.conf.local" > module_blacklist=3D"drm drm2 radeonkms i915kms amdgpu" > module_path=3D"/boot/kernel;/boot/modules;/boot/dtb;/boot/dtb/overlays" > module_verbose=3D"2" > net.inet.tcp.soreceive_stream=3D"1" > net.link.ifqmaxlen=3D"256" > nextboot_conf=3D"/boot/nextboot.conf" > ram_blacklist_load=3D"NO" > ram_blacklist_name=3D"/boot/blacklist.txt" > ram_blacklist_type=3D"ram_blacklist" > screensave_load=3D"NO" > screensave_name=3D"green_saver" > script.lang=3D"lua" > smbios.bios.reldate=3D"06/16/2021" > smbios.bios.revision=3D"0.0" > smbios.bios.vendor=3D"EFI Development Kit II / OVMF" > smbios.bios.version=3D"1.5.1" > smbios.chassis.maker=3D"QEMU" > smbios.chassis.tag=3D"OracleCloud.com" > smbios.chassis.type=3D"Other" > smbios.chassis.version=3D"virt-4.2" > smbios.memory.enabled=3D"25165824" > smbios.socket.enabled=3D"1" > smbios.socket.populated=3D"1" > smbios.system.maker=3D"QEMU" > smbios.system.product=3D"KVM Virtual Machine" > smbios.system.uuid=3D"14fd7a5a-8f68-44d4-88b6-68498f8b55fb" > smbios.system.version=3D"virt-4.2" > smbios.version=3D"3.0" > splash=3D"/boot/images/freebsd-logo-rev.png" > splash_bmp_load=3D"NO" > splash_pcx_load=3D"NO" > splash_txt_load=3D"NO" > tcp_rack_load=3D"YES" > tcphpts_load=3D"YES" > twiddle_divisor=3D"16" > verbose_loading=3D"NO" > vesa_load=3D"NO" > vfs.root.mountfrom=3D"zfs:zroot/ROOT/2024-11-06-084833" > vm.exec_map_entries=3D"32" > xz_load=3D"YES" > zfs-bootonce=3D"zfs:zroot/ROOT/2024-11-06-084833:" > zfs_be_active=3D"zfs:zroot/ROOT/2024-10-14-160358" > zfs_be_currpage=3D"1" > zfs_be_root=3D"zroot/ROOT" > zfs_load=3D"YES" > > > (2) sudo efivar --device-path 8be4df61-93ca-11d2-aa0d-00e098032b8c-ConIn > > > 8be4df61-93ca-11d2-aa0d-00e098032b8c-ConIn > : > UsbHID(0xffff,0xffff,0x1,0x1),/VenHw(d3987d4b-971a-435f-8caf-4967eb627241= )/Uart(38400,8,N,1)/VenVt100() > > > (3) sudo efivar --device-path 8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut > > > 8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut > : > PciRoot(0x0)/Pci(0x1,0x0)/AcpiAdr(0x80010300),/VenHw(d3987d4b-971a-435f-8= caf-4967eb627241)/Uart(38400,8,N,1)/VenVt100() > Oh and a dmesg? Warner > > Bye, > Alexander. > > > Warner > > On Thu, Nov 7, 2024 at 2:41=E2=80=AFPM Alexander Leidinger < > Alexander@leidinger.net> wrote: > > Am 2024-11-07 20:59, schrieb Warner Losh: > > > > On Wed, Nov 6, 2024 at 3:41=E2=80=AFAM Alexander Leidinger < > Alexander@leidinger.net> wrote: > > Am 2024-11-02 17:08, schrieb Warner Losh: > > > > On Sat, Nov 2, 2024, 10:03=E2=80=AFAM Alexander Leidinger > wrote: > > Am 2024-10-30 22:11, schrieb Alexander Leidinger: > > > WARNING! Trying to fire up the kernel, but no device tree blob found! > > For anyone interested, I opened > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D282493 for this. > > > Yea. This is a hang or a bad console. The warning is lame and misleading. > > Can you bisect? > > Found it. > > # git bisect bad > c87b3f0006be9ac5813f1ff636f18c9b4a41b08e is the first bad commit > commit c87b3f0006be9ac5813f1ff636f18c9b4a41b08e (HEAD) > Author: Warner Losh > Date: Mon Oct 14 15:58:10 2024 -0600 > > uart: uart_getenv: check for NULL class last, not first > > This allows one to specify dt:XXXX when the default class isn't > compiled > into the kernel. It's not an error to not have a class until we're do= ne > parsing the spec, so defer checking until then. > > Sponsored by: Netflix > Reviewed by: adrian, andrew, markj > Differential Revision: https://reviews.freebsd.org/D47078 > > sys/dev/uart/uart_subr.c | 14 +++++++------- > 1 file changed, 7 insertions(+), 7 deletions(-) > > -current as of today without this change boots just fine on the Ampere > system in the Oracle cloud. > > > what's your loader.conf? this should only matter if something is set > there... > > loader.conf: > > autoboot_delay=3D"1" > hw.usb.no_boot_wait=3D"0" > beastie_disable=3D"YES" > boot_serial=3D"YES" > loader_logo=3D"none" > cryptodev_load=3D"YES" > xz_load=3D"YES" > zfs_load=3D"YES" > geom_eli_load=3D"YES" > > tcphpts_load=3D"yes" > tcp_rack_load=3D"YES" > > hw.mca.enabled=3D"1" > vm.exec_map_entries=3D"32" > > net.link.ifqmaxlen=3D"256" > net.inet.tcp.soreceive_stream=3D"1" > kern.random.fortuna.concurrent_read=3D"1" > kern.msgbuf_show_timestamp=3D"1" > > Bye, > Alexander. > -- > http://www.Leidinger.net Alexander@Leidinger.net: > <#m_-4440668305350821778_NOP> PGP 0x8F31830F9F2772BF > http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF > > > -- > http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF > http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF > --000000000000aceb92062666b75b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable



On Fri, Nov 8, 2024, 12:34=E2=80=AFAM Alex= ander Leidinger <Alexander@le= idinger.net> wrote:

Am 2024-11-08 05:46, schrieb Wa= rner Losh:

OK. I'm confused... but no matter.=C2=A0
=C2=A0
Three more things to help...=C2=A0
(1) kenv after boot with a fixed kernel
=C2=A0
COLUMNS=3D"100"
LINES=3D"31"
acpi.oem=3D&quo= t;BOCHS "
acpi.revision=3D"2"
acpi.rsdp=3D"0x0000= 0006385c0018"
acpi.rsdt=3D"0x0000000000000000"
acpi.xs= dt=3D"0x00000006385cfe98"
acpi.xsdt_length=3D"36"acpi_dsdt_load=3D"NO"
acpi_dsdt_name=3D"/boot/acpi_dsdt.= aml"
acpi_dsdt_type=3D"acpi_dsdt"
acpi_video_load=3D&q= uot;NO"
audit_event_load=3D"NO"
audit_event_name=3D&qu= ot;/etc/security/audit_event"
audit_event_type=3D"etc_security= _audit_event"
autoboot_delay=3D"1"
beastie_disable=3D&= quot;YES"
bitmap_load=3D"NO"
bitmap_name=3D"splas= h.bmp"
bitmap_type=3D"splash_image_data"
boot_multicon= s=3D"YES"
boot_serial=3D"YES"
bootenv_autolist=3D= "YES"
bootenvs[0]=3D"zfs:zroot/ROOT/2024-10-30-121420_ko&= quot;
bootenvs[10]=3D"zfs:zroot/ROOT/2024-07-15-110946"
boo= tenvs[11]=3D"zfs:zroot/ROOT/2024-09-12-140543"
bootenvs[1]=3D&= quot;zfs:zroot/ROOT/2024-10-14-233343_ko"
bootenvs[2]=3D"zfs:z= root/ROOT/2024-10-14-160359"
bootenvs[3]=3D"zfs:zroot/ROOT/202= 4-10-14-160358"
bootenvs[4]=3D"zfs:zroot/ROOT/2024-10-13-23230= 8"
bootenvs[5]=3D"zfs:zroot/ROOT/2024-10-14-102617"
bo= otenvs[6]=3D"zfs:zroot/ROOT/2024-10-11-084349"
bootenvs[7]=3D&= quot;zfs:zroot/ROOT/2024-11-06-084833"
bootenvs[8]=3D"zfs:zroo= t/ROOT/2024-08-15-222928"
bootenvs[9]=3D"zfs:zroot/ROOT/2024-0= 7-16-094205"
bootenvs_count=3D"12"
bootfile=3D"ke= rnel"
console=3D"efi"
cpu_microcode_load=3D"NO&qu= ot;
cpu_microcode_name=3D"/boot/firmware/ucode.bin"
cpu_mic= rocode_type=3D"cpu_microcode"
cryptodev_load=3D"YES"=
currdev=3D"zfs:zroot/ROOT/2024-11-06-084833:"
efi-version= =3D"2.70"
efi_com_port=3D"0"
efi_com_speed=3D&quo= t;38400"
efi_max_resolution=3D"1x1"
entropy_cache_load= =3D"YES"
entropy_cache_name=3D"/boot/entropy"
ent= ropy_cache_type=3D"boot_entropy_cache"
entropy_efi_seed=3D&quo= t;YES"
entropy_efi_seed_size=3D"2048"
geom_eli_load=3D= "YES"
hint.acpi.0.disabled=3D"0"
hint.smbios.0.me= m=3D"0x63bed0000"
hostuuid_load=3D"YES"
hostuuid_= name=3D"/etc/hostid"
hostuuid_type=3D"hostuuid"
hw.mca.enabled=3D"1"=
hw.uart.console=3D"db:8,dt:pl011,mm:0x9000000,rs:0,rw:1,pa:none,br= :9600,xo=3D0"
hw.usb.no_boot_wait=3D"0"
kern.msgbuf_sh= ow_timestamp=3D"1"
kern.random.fortuna.concurrent_read=3D"= ;1"
kernel=3D"kernel"
kernel_options=3D""kernel_path=3D"/boot/kernel"
kernelname=3D"/boot/kernel/= kernel"
kernels_autodetect=3D"YES"
loaddev=3D"zfs= :zroot/ROOT/2024-11-06-084833:"
loader.efi=3D"1"
loade= r_conf_dirs=3D"/boot/loader.conf.d"
loader_logo=3D"none&q= uot;
local_loader_conf_files=3D"/boot/loader.conf.local"
mo= dule_blacklist=3D"drm drm2 radeonkms i915kms amdgpu"
module_pa= th=3D"/boot/kernel;/boot/modules;/boot/dtb;/boot/dtb/overlays"module_verbose=3D"2"
net.inet.tcp.soreceive_stream=3D"1&= quot;
net.link.ifqmaxlen=3D"256"
nextboot_conf=3D"/boo= t/nextboot.conf"
ram_blacklist_load=3D"NO"
ram_blackli= st_name=3D"/boot/blacklist.txt"
ram_blacklist_type=3D"ram= _blacklist"
screensave_load=3D"NO"
screensave_name=3D&= quot;green_saver"
script.lang=3D"lua"
smbios.bios.reld= ate=3D"06/16/2021"
smbios.bios.revision=3D"0.0"
s= mbios.bios.vendor=3D"EFI Development Kit II / OVMF"
smbios.bio= s.version=3D"1.5.1"
smbios.chassis.maker=3D"QEMU"smbios.chassis.tag=3D"OracleCloud.com"
smbios.chassis.type=3D= "Other"
smbios.chassis.version=3D"virt-4.2"
smbio= s.memory.enabled=3D"25165824"
smbios.socket.enabled=3D"1&= quot;
smbios.socket.populated=3D"1"
smbios.system.maker=3D&= quot;QEMU"
smbios.system.product=3D"KVM Virtual Machine"<= br>smbios.system.uuid=3D"14fd7a5a-8f68-44d4-88b6-68498f8b55fb"smbios.system.version=3D"virt-4.2"
smbios.version=3D"3.0= "
splash=3D"/boot/images/freebsd-logo-rev.png"
splash_= bmp_load=3D"NO"
splash_pcx_load=3D"NO"
splash_txt= _load=3D"NO"
tcp_rack_load=3D"YES"
tcphpts_load= =3D"YES"
twiddle_divisor=3D"16"
verbose_loading= =3D"NO"
vesa_load=3D"NO"
vfs.root.mountfrom=3D&qu= ot;zfs:zroot/ROOT/2024-11-06-084833"
vm.exec_map_entries=3D"32= "
xz_load=3D"YES"
zfs-bootonce=3D"zfs:zroot/ROOT/= 2024-11-06-084833:"
zfs_be_active=3D"zfs:zroot/ROOT/2024-10-14-160358"
zfs_be= _currpage=3D"1"
zfs_be_root=3D"zroot/ROOT"
zfs_lo= ad=3D"YES"
=C2=A0
(2) sudo efivar --device-path 8be4df61-93ca-11d2-aa0d-00e098032b8c-Con= In
=C2=A0
8be4df61-93ca-11d2-aa0d-00e098032b8c-ConIn
: UsbHID(0xffff,0xffff,0x1,0x1),/VenHw(d3987d4b-971a-435f-8caf-4967eb6= 27241)/Uart(38400,8,N,1)/VenVt100()
=C2=A0
(3) sudo efivar --device-path 8be4df61-93ca-11d2-aa0d-00e098032b8c-Con= Out
=C2=A0
8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut
: PciRoot(0x0)/Pci(0x1,= 0x0)/AcpiAdr(0x80010300),/VenHw(d3987d4b-971a-435f-8caf-4967eb627241)/Uart(= 38400,8,N,1)/VenVt100()

Oh and a dmesg?

Warner=C2=A0

Bye,
Alexander.
=C2=A0
Warner

On Thu, Nov 7, 2024 at 2:41=E2=80=AFPM Alexander Leidinger= <Alexander@leidinger.net> wrote:

Am 2024-11-07 20:59, schrieb Warner Losh:

=C2=A0

On Wed, Nov 6, 2024 at 3:41=E2=80=AFAM Alexander Leidinger= <Alexander@leidinger.net> wrote:

Am 2024-11-02 17:08, schrieb Warner Lo= sh:



On Sat, Nov 2, 2024, 10:03=E2=80=AFAM Alexander Leidinger = <Alexander@leidinger.net> wrote:
Am 2024-10-30 22:11, schrieb Alexander Leidinger:
> WARNING! Trying to fire up the kernel, but no device tree blob found!=

For anyone interested, I opened
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D2= 82493 for this.
=C2=A0
Yea. This is a hang or a bad console. The warning is lame= and misleading.
=C2=A0
Can you bisect?

Found it.

# git bisect bad
c87b3f0006be9ac5813f1ff6= 36f18c9b4a41b08e is the first bad commit
commit c87b3f0006be9ac5813f1ff6= 36f18c9b4a41b08e (HEAD)
Author: Warner Losh <imp@FreeBSD.org>
D= ate: =C2=A0 Mon Oct 14 15:58:10 2024 -0600

=C2=A0 =C2=A0 uart: uart_getenv: check for N= ULL class last, not first

=C2=A0 =C2=A0 This allows one to specify dt:= XXXX when the default class isn't compiled
=C2=A0 =C2=A0 into the ke= rnel. It's not an error to not have a class until we're done
=C2= =A0 =C2=A0 parsing the spec, so defer checking until then.

=C2=A0 =C2=A0 Sponsored by: =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Netflix
=C2=A0 =C2=A0 Reviewed by: =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0adrian, andrew, markj
=C2=A0 =C2=A0 Different= ial Revision: =C2=A0https://reviews.freebsd.or= g/D47078

=C2=A0sys/dev/uart/uart_subr.c | 14 +++++++-= ------
=C2=A01 file changed, 7 insertions(+), 7 deletions(-)

-current as of today without this change boots just fine on the Ampere s= ystem in the Oracle cloud.

=C2=A0
what's your loader.conf? this should only matter if something is s= et there...=C2=A0=C2=A0

loader.conf:

autoboot_delay=3D"1"
hw.usb.no_= boot_wait=3D"0"
beastie_disable=3D"YES"
boot_seri= al=3D"YES"
loader_logo=3D"none"
cryptodev_load=3D= "YES"
xz_load=3D"YES"
zfs_load=3D"YES"<= br>geom_eli_load=3D"YES"

tcphpts_load=3D"yes"
tcp_rack_l= oad=3D"YES"

hw.mca.enabled=3D"1"
vm.exec_ma= p_entries=3D"32"

net.link.ifqmaxlen=3D"256"
net.= inet.tcp.soreceive_stream=3D"1"
kern.random.fortuna.concurrent= _read=3D"1"
kern.msgbuf_show_timestamp=3D"1"

Bye,
Alexander.

--
http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org =C2=A0 =C2=A0netchild= @FreeBSD.org =C2=A0: PGP 0x8F31830F9F2772BF


--
= http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F318= 30F9F2772BF
http://www.FreeBSD.org =C2=A0 =C2=A0n= etchild@FreeBSD.org =C2=A0: PGP 0x8F31830F9F2772BF
--000000000000aceb92062666b75b-- From nobody Fri Nov 8 13:53:20 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 4XlL541mhmz5cH0F for ; Fri, 08 Nov 2024 13:53:44 +0000 (UTC) (envelope-from dch@skunkwerks.at) Received: from fout-b2-smtp.messagingengine.com (fout-b2-smtp.messagingengine.com [202.12.124.145]) (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 4XlL5370c7z4XGl for ; Fri, 8 Nov 2024 13:53:43 +0000 (UTC) (envelope-from dch@skunkwerks.at) Authentication-Results: mx1.freebsd.org; none Received: from phl-compute-02.internal (phl-compute-02.phl.internal [10.202.2.42]) by mailfout.stl.internal (Postfix) with ESMTP id DC2BE1140131; Fri, 8 Nov 2024 08:53:42 -0500 (EST) Received: from phl-imap-02 ([10.202.2.81]) by phl-compute-02.internal (MEProxy); Fri, 08 Nov 2024 08:53:42 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=skunkwerks.at; h=cc:cc:content-transfer-encoding:content-type:content-type :date:date:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:subject:subject:to:to; s=fm1; t=1731074022; x=1731160422; bh=7U8+2JBQIDF7E4YJi9cKFmKj4Qz7NqH4 u4uPlzKhkrA=; b=XRXSip0lYPBnFVA76lII7BGoiQjefsgrBxXrn2jbDb01y7kN q032idFmwWMhjpU3ZQhnic0oWMqExA6OdM94hDfhC+tnosEi2MF524fTGRJGAF4S wbTb03WIo097MtfdlKltQCkNk5leWXVBIsOmYZYIZoLPz2SkTU0JQF55EUIx5S8G MSJ8FlNkZHuYekC5nafO0gwS9svJPlKTuOGxS/dX4Mg8ElIPkMagoAjfwWZ1s6z8 HBZVQWdGAio5/gnO4SRXxlgsMev4TQBIhik0j2AqWYIUIfRALmIcVdkLwrskYzUj Fv4D/jxxmo5bA9aEZpMImNn804+BYw7DpVJgjQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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-sender:x-me-sender:x-sasl-enc; s=fm3; t=1731074022; x= 1731160422; bh=7U8+2JBQIDF7E4YJi9cKFmKj4Qz7NqH4u4uPlzKhkrA=; b=P zz4dz2vb3Yql7ZbdlVScECgSolYSU7DNPec429icT4LFolC+pYMpypn//N49KZFd 8v5ELhvE8ChhKmyqkrv6i9BFulShk0Mk4HDtnagom80z6JAMbSbeJSDQFE4s4QQ4 cJLIXkKt3aQXv916Q+83zCEHOaitIDCIYWiGSPzNW8pyBwOhpHXtyTFcpqFFJwYO qdgvhaA1XzIebUrSWYZJIl3vvSBuTjWbyLSiDyhAKKwKXOfuHPTM5YBMGXAzf/Z0 jOWTyX/wK4RU7hDC9/hZgF+gAEcQw0kri55gbI7HBn9mp+6G434LiEiUEDH0hWLY pavJJjuIq4pvXpMvWwymw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrtdeigdehgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdpuffr tefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnth hsucdlqddutddtmdenucfjughrpefoggffhffvvefkjghfufgtgfesthhqredtredtjeen ucfhrhhomhepfdffrghvvgcuvehothhtlhgvhhhusggvrhdfuceouggthhesshhkuhhnkh ifvghrkhhsrdgrtheqnecuggftrfgrthhtvghrnhepteelffevhfetuedvtedutdekgfej veduvefhleehueefffehveffgfehkeeihfeinecuffhomhgrihhnpehfrhgvvggsshgurd horhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhep uggthhesshhkuhhnkhifvghrkhhsrdgrthdpnhgspghrtghpthhtohepfedpmhhouggvpe hsmhhtphhouhhtpdhrtghpthhtohepihhmphessghsughimhhprdgtohhmpdhrtghpthht ohepfhhrvggvsghsugdqtghurhhrvghnthesfhhrvggvsghsugdrohhrghdprhgtphhtth hopegrlhgvgigrnhguvghrsehlvghiughinhhgvghrrdhnvght X-ME-Proxy: Feedback-ID: ic0e84090:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 2C7AFB00068; Fri, 8 Nov 2024 08:53:42 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Date: Fri, 08 Nov 2024 13:53:20 +0000 From: "Dave Cottlehuber" To: "Alexander Leidinger" , "Warner Losh" Cc: freebsd-current Message-Id: <42552643-382a-4ef0-b27e-437a82878936@app.fastmail.com> In-Reply-To: <132ca9158817a4706d1b9e78c3567973@Leidinger.net> References: <8cf9adb0e7ca6340460c695ffd64a0df@Leidinger.net> <896b9ce404ffcb126dcdd6008583b117@Leidinger.net> <132ca9158817a4706d1b9e78c3567973@Leidinger.net> Subject: Re: No valid device tree blob found! Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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)[] X-Rspamd-Queue-Id: 4XlL5370c7z4XGl X-Spamd-Bar: ---- On Thu, 7 Nov 2024, at 22:41, Alexander Leidinger wrote: > Am 2024-11-07 20:59, schrieb Warner Losh: > >> =20 >>=20 >> On Wed, Nov 6, 2024 at 3:41=E2=80=AFAM Alexander Leidinger wrote: >>> Am 2024-11-02 17:08, schrieb Warner Losh: >>>=20 >>>>=20 >>>>=20 >>>> On Sat, Nov 2, 2024, 10:03=E2=80=AFAM Alexander Leidinger wrote: >>>>> Am 2024-10-30 22:11, schrieb Alexander Leidinger: >>>>>=20 >>>>> > WARNING! Trying to fire up the kernel, but no device tree blob f= ound! >>>>>=20 >>>>> For anyone interested, I opened=20 >>>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D282493 for thi= s.=20 >>>> =20 >>>> Yea. This is a hang or a bad console. The warning is lame and misle= ading. >>>> =20 >>>> Can you bisect? >>> Found it. >>>=20 >>> # git bisect bad >>> c87b3f0006be9ac5813f1ff636f18c9b4a41b08e is the first bad commit >>> commit c87b3f0006be9ac5813f1ff636f18c9b4a41b08e (HEAD) >>> Author: Warner Losh >>> Date: Mon Oct 14 15:58:10 2024 -0600 >>>=20 >>> uart: uart_getenv: check for NULL class last, not first >>>=20 >>> This allows one to specify dt:XXXX when the default class isn't = compiled >>> into the kernel. It's not an error to not have a class until we'= re done >>> parsing the spec, so defer checking until then. >>>=20 >>> Sponsored by: Netflix >>> Reviewed by: adrian, andrew, markj >>> Differential Revision: https://reviews.freebsd.org/D47078 >>>=20 >>> sys/dev/uart/uart_subr.c | 14 +++++++------- >>> 1 file changed, 7 insertions(+), 7 deletions(-) >>>=20 >>> -current as of today without this change boots just fine on the Ampe= re system in the Oracle cloud. >>>=20 >> =20 >> what's your loader.conf? this should only matter if something is set = there... =20 I see this too using our latest snapshots, so GENERIC kernel etc, same h= /w as Alex. https://cgit.freebsd.org/src/tree/release/tools/oracle.conf#n49 autoboot_delay=3D"5" beastie_disable=3D"YES" boot_serial=3D"YES" loader_logo=3D"none" cryptodev_load=3D"YES" opensolaris_load=3D"YES" xz_load=3D"YES" zfs_load=3D"YES"=20 A+ Dave From nobody Fri Nov 8 14:05:31 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 4XlLMg0ysjz5cHmy for ; Fri, 08 Nov 2024 14:06:23 +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 "E6" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4XlLMf3wKKz4Yjy for ; Fri, 8 Nov 2024 14:06:22 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Authentication-Results: mx1.freebsd.org; none List-Id: Discussions about the use of FreeBSD-current List-Archive: https://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=1731074780; 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=FIoa5OI7AlHkoZj+dWlsj3Kmu+e/Rv+Mpf5PFSnAFOE=; b=rF769tzhWkiSQ/FTR4DmQE94VVn4KtbSN5aU181LWPA/u+S878+ACSJS8Q0NJz9N5FwPK7 Tg7zIZtKjLvcHwQwGhDj97OjihiZhSfpSdWwQSsrPk9pL0jbV/cOCRh+r9d34PC10lfQiF xsUCl6ZKMTQ45llEeOlfCvIb6waCBG6US96A0LYxnrbpW25LP2Qy9beztVZXZCb580aWw6 iQN2QabPayTINW+gDWwd8ndRjlwUnuPYz46eoPCEpSILIOx+rudMbe6U8kEQfb9q5Qv4Y7 GHtXlurP40mlmtc2BLuqOGJFI9TS9zN+aMapbW6FvA2xTKSOMOAjGQec03K3lQ== Date: Fri, 08 Nov 2024 15:05:31 +0100 From: Alexander Leidinger To: Warner Losh Cc: Current FreeBSD Subject: Re: No valid device tree blob found! In-Reply-To: References: <8cf9adb0e7ca6340460c695ffd64a0df@Leidinger.net> <896b9ce404ffcb126dcdd6008583b117@Leidinger.net> <132ca9158817a4706d1b9e78c3567973@Leidinger.net> <0389774b2a7a86ebf538807f71239802@Leidinger.net> Message-ID: <738fb7615a0f3d87a394413d6327479d@Leidinger.net> Organization: No organization, this is a private message. Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=_3eb424eb17b7ffc28bced07b5d905122"; micalg=pgp-sha256 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:34240, ipnet:89.238.64.0/18, country:DE] X-Rspamd-Queue-Id: 4XlLMf3wKKz4Yjy X-Spamd-Bar: ---- This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --=_3eb424eb17b7ffc28bced07b5d905122 Content-Type: multipart/mixed; boundary="=_619464079b8b191d8b67e82273e7326c" --=_619464079b8b191d8b67e82273e7326c Content-Type: multipart/alternative; boundary="=_cb08be3010725a0f32f23f36cd278682" --=_cb08be3010725a0f32f23f36cd278682 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8; format=flowed Am 2024-11-08 14:27, schrieb Warner Losh: > On Fri, Nov 8, 2024, 12:34 AM Alexander Leidinger > wrote: > > Am 2024-11-08 05:46, schrieb Warner Losh: > > OK. I'm confused... but no matter. > > Three more things to help... > (1) kenv after boot with a fixed kernel > > COLUMNS="100" > LINES="31" > acpi.oem="BOCHS " > acpi.revision="2" > acpi.rsdp="0x00000006385c0018" > acpi.rsdt="0x0000000000000000" > acpi.xsdt="0x00000006385cfe98" > acpi.xsdt_length="36" > acpi_dsdt_load="NO" > acpi_dsdt_name="/boot/acpi_dsdt.aml" > acpi_dsdt_type="acpi_dsdt" > acpi_video_load="NO" > audit_event_load="NO" > audit_event_name="/etc/security/audit_event" > audit_event_type="etc_security_audit_event" > autoboot_delay="1" > beastie_disable="YES" > bitmap_load="NO" > bitmap_name="splash.bmp" > bitmap_type="splash_image_data" > boot_multicons="YES" > boot_serial="YES" > bootenv_autolist="YES" > bootenvs[0]="zfs:zroot/ROOT/2024-10-30-121420_ko" > bootenvs[10]="zfs:zroot/ROOT/2024-07-15-110946" > bootenvs[11]="zfs:zroot/ROOT/2024-09-12-140543" > bootenvs[1]="zfs:zroot/ROOT/2024-10-14-233343_ko" > bootenvs[2]="zfs:zroot/ROOT/2024-10-14-160359" > bootenvs[3]="zfs:zroot/ROOT/2024-10-14-160358" > bootenvs[4]="zfs:zroot/ROOT/2024-10-13-232308" > bootenvs[5]="zfs:zroot/ROOT/2024-10-14-102617" > bootenvs[6]="zfs:zroot/ROOT/2024-10-11-084349" > bootenvs[7]="zfs:zroot/ROOT/2024-11-06-084833" > bootenvs[8]="zfs:zroot/ROOT/2024-08-15-222928" > bootenvs[9]="zfs:zroot/ROOT/2024-07-16-094205" > bootenvs_count="12" > bootfile="kernel" > console="efi" > cpu_microcode_load="NO" > cpu_microcode_name="/boot/firmware/ucode.bin" > cpu_microcode_type="cpu_microcode" > cryptodev_load="YES" > currdev="zfs:zroot/ROOT/2024-11-06-084833:" > efi-version="2.70" > efi_com_port="0" > efi_com_speed="38400" > efi_max_resolution="1x1" > entropy_cache_load="YES" > entropy_cache_name="/boot/entropy" > entropy_cache_type="boot_entropy_cache" > entropy_efi_seed="YES" > entropy_efi_seed_size="2048" > geom_eli_load="YES" > hint.acpi.0.disabled="0" > hint.smbios.0.mem="0x63bed0000" > hostuuid_load="YES" > hostuuid_name="/etc/hostid" > hostuuid_type="hostuuid" > hw.mca.enabled="1" > hw.uart.console="db:8,dt:pl011,mm:0x9000000,rs:0,rw:1,pa:none,br:9600,xo=0" > hw.usb.no_boot_wait="0" > kern.msgbuf_show_timestamp="1" > kern.random.fortuna.concurrent_read="1" > kernel="kernel" > kernel_options="" > kernel_path="/boot/kernel" > kernelname="/boot/kernel/kernel" > kernels_autodetect="YES" > loaddev="zfs:zroot/ROOT/2024-11-06-084833:" > loader.efi="1" > loader_conf_dirs="/boot/loader.conf.d" > loader_logo="none" > local_loader_conf_files="/boot/loader.conf.local" > module_blacklist="drm drm2 radeonkms i915kms amdgpu" > module_path="/boot/kernel;/boot/modules;/boot/dtb;/boot/dtb/overlays" > module_verbose="2" > net.inet.tcp.soreceive_stream="1" > net.link.ifqmaxlen="256" > nextboot_conf="/boot/nextboot.conf" > ram_blacklist_load="NO" > ram_blacklist_name="/boot/blacklist.txt" > ram_blacklist_type="ram_blacklist" > screensave_load="NO" > screensave_name="green_saver" > script.lang="lua" > smbios.bios.reldate="06/16/2021" > smbios.bios.revision="0.0" > smbios.bios.vendor="EFI Development Kit II / OVMF" > smbios.bios.version="1.5.1" > smbios.chassis.maker="QEMU" > smbios.chassis.tag="OracleCloud.com" > smbios.chassis.type="Other" > smbios.chassis.version="virt-4.2" > smbios.memory.enabled="25165824" > smbios.socket.enabled="1" > smbios.socket.populated="1" > smbios.system.maker="QEMU" > smbios.system.product="KVM Virtual Machine" > smbios.system.uuid="14fd7a5a-8f68-44d4-88b6-68498f8b55fb" > smbios.system.version="virt-4.2" > smbios.version="3.0" > splash="/boot/images/freebsd-logo-rev.png" > splash_bmp_load="NO" > splash_pcx_load="NO" > splash_txt_load="NO" > tcp_rack_load="YES" > tcphpts_load="YES" > twiddle_divisor="16" > verbose_loading="NO" > vesa_load="NO" > vfs.root.mountfrom="zfs:zroot/ROOT/2024-11-06-084833" > vm.exec_map_entries="32" > xz_load="YES" > zfs-bootonce="zfs:zroot/ROOT/2024-11-06-084833:" > zfs_be_active="zfs:zroot/ROOT/2024-10-14-160358" > zfs_be_currpage="1" > zfs_be_root="zroot/ROOT" > zfs_load="YES" > > (2) sudo efivar --device-path > 8be4df61-93ca-11d2-aa0d-00e098032b8c-ConIn > > 8be4df61-93ca-11d2-aa0d-00e098032b8c-ConIn > : > UsbHID(0xffff,0xffff,0x1,0x1),/VenHw(d3987d4b-971a-435f-8caf-4967eb627241)/Uart(38400,8,N,1)/VenVt100() > > (3) sudo efivar --device-path > 8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut > > 8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut > : > PciRoot(0x0)/Pci(0x1,0x0)/AcpiAdr(0x80010300),/VenHw(d3987d4b-971a-435f-8caf-4967eb627241)/Uart(38400,8,N,1)/VenVt100() Oh and a dmesg? > Attached. Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_cb08be3010725a0f32f23f36cd278682 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Am 2024-11-08 14:27, schrieb Warner Losh:

On Fri, Nov 8, 2024, 12:34=E2=80=AF= AM Alexander Leidinger <Alexander@leidinger.net> wrote:

Am 2024-11-08 05:46, schrieb = Warner Losh:

OK. I'm confused... but no matter. 
 
Three more things to help... 
(1) kenv after boot with a fixed kernel
 
COLUMNS=3D"100"
LINES=3D"31"
acpi.oem=3D"BOCHS "
acpi.r= evision=3D"2"
acpi.rsdp=3D"0x00000006385c0018"
acpi.rsdt=3D"0x000= 0000000000000"
acpi.xsdt=3D"0x00000006385cfe98"
acpi.xsdt_length= =3D"36"
acpi_dsdt_load=3D"NO"
acpi_dsdt_name=3D"/boot/acpi_dsdt.a= ml"
acpi_dsdt_type=3D"acpi_dsdt"
acpi_video_load=3D"NO"
audi= t_event_load=3D"NO"
audit_event_name=3D"/etc/security/audit_event"
audit_event_type=3D"etc_security_audit_event"
autoboot_delay=3D"1"beastie_disable=3D"YES"
bitmap_load=3D"NO"
bitmap_name=3D"spl= ash.bmp"
bitmap_type=3D"splash_image_data"
boot_multicons=3D"YES"=
boot_serial=3D"YES"
bootenv_autolist=3D"YES"
bootenvs[0]=3D= "zfs:zroot/ROOT/2024-10-30-121420_ko"
bootenvs[10]=3D"zfs:zroot/ROOT/2= 024-07-15-110946"
bootenvs[11]=3D"zfs:zroot/ROOT/2024-09-12-140543"bootenvs[1]=3D"zfs:zroot/ROOT/2024-10-14-233343_ko"
bootenvs[2]=3D"= zfs:zroot/ROOT/2024-10-14-160359"
bootenvs[3]=3D"zfs:zroot/ROOT/2024-1= 0-14-160358"
bootenvs[4]=3D"zfs:zroot/ROOT/2024-10-13-232308"
boo= tenvs[5]=3D"zfs:zroot/ROOT/2024-10-14-102617"
bootenvs[6]=3D"zfs:zroot= /ROOT/2024-10-11-084349"
bootenvs[7]=3D"zfs:zroot/ROOT/2024-11-06-0848= 33"
bootenvs[8]=3D"zfs:zroot/ROOT/2024-08-15-222928"
bootenvs[9]= =3D"zfs:zroot/ROOT/2024-07-16-094205"
bootenvs_count=3D"12"
bootf= ile=3D"kernel"
console=3D"efi"
cpu_microcode_load=3D"NO"
cpu= _microcode_name=3D"/boot/firmware/ucode.bin"
cpu_microcode_type=3D"cpu= _microcode"
cryptodev_load=3D"YES"
currdev=3D"zfs:zroot/ROOT/2024= -11-06-084833:"
efi-version=3D"2.70"
efi_com_port=3D"0"
efi_= com_speed=3D"38400"
efi_max_resolution=3D"1x1"
entropy_cache_load= =3D"YES"
entropy_cache_name=3D"/boot/entropy"
entropy_cache_type= =3D"boot_entropy_cache"
entropy_efi_seed=3D"YES"
entropy_efi_seed= _size=3D"2048"
geom_eli_load=3D"YES"
hint.acpi.0.disabled=3D"0"hint.smbios.0.mem=3D"0x63bed0000"
hostuuid_load=3D"YES"
hostu= uid_name=3D"/etc/hostid"
hostuuid_type=3D"hostuuid"
hw.mca.enabled=3D"1"
hw.uart.cons= ole=3D"db:8,dt:pl011,mm:0x9000000,rs:0,rw:1,pa:none,br:9600,xo=3D0"
hw= =2Eusb.no_boot_wait=3D"0"
kern.msgbuf_show_timestamp=3D"1"
kern.r= andom.fortuna.concurrent_read=3D"1"
kernel=3D"kernel"
kernel_opti= ons=3D""
kernel_path=3D"/boot/kernel"
kernelname=3D"/boot/kernel/= kernel"
kernels_autodetect=3D"YES"
loaddev=3D"zfs:zroot/ROOT/2024= -11-06-084833:"
loader.efi=3D"1"
loader_conf_dirs=3D"/boot/loader= =2Econf.d"
loader_logo=3D"none"
local_loader_conf_files=3D"/boot/= loader.conf.local"
module_blacklist=3D"drm drm2 radeonkms i915kms amdg= pu"
module_path=3D"/boot/kernel;/boot/modules;/boot/dtb;/boot/dtb/over= lays"
module_verbose=3D"2"
net.inet.tcp.soreceive_stream=3D"1"net.link.ifqmaxlen=3D"256"
nextboot_conf=3D"/boot/nextboot.conf"ram_blacklist_load=3D"NO"
ram_blacklist_name=3D"/boot/blacklist.txt= "
ram_blacklist_type=3D"ram_blacklist"
screensave_load=3D"NO"
screensave_name=3D"green_saver"
script.lang=3D"lua"
smbios.bios= =2Ereldate=3D"06/16/2021"
smbios.bios.revision=3D"0.0"
smbios.bio= s.vendor=3D"EFI Development Kit II / OVMF"
smbios.bios.version=3D"1.5.= 1"
smbios.chassis.maker=3D"QEMU"
smbios.chassis.tag=3D"OracleClou= d.com"
smbios.chassis.type=3D"Other"
smbios.chassis.version=3D"vi= rt-4.2"
smbios.memory.enabled=3D"25165824"
smbios.socket.enabled= =3D"1"
smbios.socket.populated=3D"1"
smbios.system.maker=3D"QEMU"=
smbios.system.product=3D"KVM Virtual Machine"
smbios.system.uuid= =3D"14fd7a5a-8f68-44d4-88b6-68498f8b55fb"
smbios.system.version=3D"vir= t-4.2"
smbios.version=3D"3.0"
splash=3D"/boot/images/freebsd-logo= -rev.png"
splash_bmp_load=3D"NO"
splash_pcx_load=3D"NO"
spla= sh_txt_load=3D"NO"
tcp_rack_load=3D"YES"
tcphpts_load=3D"YES"
twiddle_divisor=3D"16"
verbose_loading=3D"NO"
vesa_load=3D"NO"<= br />vfs.root.mountfrom=3D"zfs:zroot/ROOT/2024-11-06-084833"
vm.exec_m= ap_entries=3D"32"
xz_load=3D"YES"
zfs-bootonce=3D"zfs:zroot/ROOT/= 2024-11-06-084833:"
zfs_be_active=3D"zfs:zroot/ROOT/2024-10-14-160358"
zfs_be_currpag= e=3D"1"
zfs_be_root=3D"zroot/ROOT"
zfs_load=3D"YES"
 
(2) sudo efivar --device-path 8be4df61-93ca-11d2-aa0d-00e098032b8c-Con= In
 
8be4df61-93ca-11d2-aa0d-00e098032b8c-ConIn
: UsbHID(0xffff,0xffff,0x1,0x1),/VenHw(d3987d4b-971a-435f-8caf-4967eb6= 27241)/Uart(38400,8,N,1)/VenVt100()
 
(3) sudo efivar --device-path 8be4df61-93ca-11d2-aa0d-00e098032b8c-Con= Out
 
8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut
: PciRoot(0x0)/Pci(0x= 1,0x0)/AcpiAdr(0x80010300),/VenHw(d3987d4b-971a-435f-8caf-4967eb627241)/Uar= t(38400,8,N,1)/VenVt100()
 
 
Oh and a dmesg?

Attached.

Bye,
Alexander.

--
= http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF
http:/= /www.FreeBSD.org    n= etchild@FreeBSD.org  : PGP 0x8F31830F9F2772BF
--=_cb08be3010725a0f32f23f36cd278682-- --=_619464079b8b191d8b67e82273e7326c Content-Transfer-Encoding: base64 Content-Type: text/plain; name=dmesg.boot Content-Disposition: attachment; filename=dmesg.boot; size=10109 LS0tPDxCT09UPj4tLS0KR0RCOiBubyBkZWJ1ZyBwb3J0cyBwcmVzZW50CktEQjogZGVidWdnZXIg YmFja2VuZHM6IGRkYgpLREI6IGN1cnJlbnQgYmFja2VuZDogZGRiCkNvcHlyaWdodCAoYykgMTk5 Mi0yMDI0IFRoZSBGcmVlQlNEIFByb2plY3QuCkNvcHlyaWdodCAoYykgMTk3OSwgMTk4MCwgMTk4 MywgMTk4NiwgMTk4OCwgMTk4OSwgMTk5MSwgMTk5MiwgMTk5MywgMTk5NAoJVGhlIFJlZ2VudHMg b2YgdGhlIFVuaXZlcnNpdHkgb2YgQ2FsaWZvcm5pYS4gQWxsIHJpZ2h0cyByZXNlcnZlZC4KRnJl ZUJTRCBpcyBhIHJlZ2lzdGVyZWQgdHJhZGVtYXJrIG9mIFRoZSBGcmVlQlNEIEZvdW5kYXRpb24u CkZyZWVCU0QgMTUuMC1DVVJSRU5UICMwIGxvY2FsY2hhbmdlcy1uMjY1OTQwLWY2NjliYzljZTA1 ZTogV2VkIE5vdiAgNiAxMjowNjoxMCBDRVQgMjAyNAogICAgcm9vdEBhbGNhdHJhejovdXNyL29i ai91c3Ivc3JjL2FybTY0LmFhcmNoNjQvc3lzL0FMQ0FUUkFaIGFybTY0CkZyZWVCU0QgY2xhbmcg dmVyc2lvbiAxOS4xLjIgKGh0dHBzOi8vZ2l0aHViLmNvbS9sbHZtL2xsdm0tcHJvamVjdC5naXQg bGx2bW9yZy0xOS4xLjItMC1nN2JhN2Q4ZTJmN2I2KQpbMV0gVlQ6IGluaXQgd2l0aG91dCBkcml2 ZXIuClsxXSBtb2R1bGUgc2NtaSBhbHJlYWR5IHByZXNlbnQhClsxXSByZWFsIG1lbW9yeSAgPSAy NTc2OTgwMzc3NiAoMjQ1NzYgTUIpClsxXSBhdmFpbCBtZW1vcnkgPSAyNTA5Mzg0MDg5NiAoMjM5 MzEgTUIpClsxXSBTdGFydGluZyBDUFUgMSAoMSkKWzFdIFN0YXJ0aW5nIENQVSAyICgyKQpbMV0g U3RhcnRpbmcgQ1BVIDMgKDMpClsxXSBGcmVlQlNEL1NNUDogTXVsdGlwcm9jZXNzb3IgU3lzdGVt IERldGVjdGVkOiA0IENQVXMKWzFdIHJhbmRvbTogdW5ibG9ja2luZyBkZXZpY2UuClsxXSBUQ1Ag SHB0cyBjcmVhdGVkIDQgc3dpIGludGVycnVwdCB0aHJlYWRzIGFuZCBib3VuZCAwIHRvIGNwdXMK WzFdIHJhbmRvbTogZW50cm9weSBkZXZpY2UgZXh0ZXJuYWwgaW50ZXJmYWNlClsxXSBrYmQwIGF0 IGtiZG11eDAKWzFdIGFjcGkwOiA8Qk9DSFMgQlhQQ0ZBQ1A+ClsxXSBhY3BpMDogUG93ZXIgQnV0 dG9uIChmaXhlZCkKWzFdIGFjcGkwOiBTbGVlcCBCdXR0b24gKGZpeGVkKQpbMV0gYWNwaTA6IENv dWxkIG5vdCB1cGRhdGUgYWxsIEdQRXM6IEFFX05PVF9DT05GSUdVUkVEClsxXSBwc2NpMDogPEFS TSBQb3dlciBTdGF0ZSBDby1vcmRpbmF0aW9uIEludGVyZmFjZSBEcml2ZXI+IG9uIGFjcGkwClsx XSBzbWNjYzA6IDxBUk0gU01DQ0MgdjEuMT4gb24gcHNjaTAKWzFdIGdpYzA6IDxBUk0gR2VuZXJp YyBJbnRlcnJ1cHQgQ29udHJvbGxlciB2My4wPiBpb21lbSAweDgwMDAwMDAtMHg4MDBmZmZmLDB4 ODBhMDAwMC0weDhmZmZmZmYgb24gYWNwaTAKWzFdIGl0czA6IDxBUk0gR0lDIEludGVycnVwdCBU cmFuc2xhdGlvbiBTZXJ2aWNlPiBtZW0gMHg4MDgwMDAwLTB4ODA5ZmZmZiBvbiBnaWMwClsxXSBn ZW5lcmljX3RpbWVyMDogPEFSTSBHZW5lcmljIFRpbWVyPiBpcnEgMzQsMzUsMzYsMzcgb24gYWNw aTAKWzFdIFRpbWVjb3VudGVyICJBUk0gTVBDb3JlIFRpbWVjb3VudGVyIiBmcmVxdWVuY3kgMjUw MDAwMDAgSHogcXVhbGl0eSAxMDAwClsxXSBFdmVudCB0aW1lciAiQVJNIE1QQ29yZSBFdmVudHRp bWVyIiBmcmVxdWVuY3kgMjUwMDAwMDAgSHogcXVhbGl0eSAxMDAwClsxXSBlZmlydGMwOiA8RUZJ IFJlYWx0aW1lIENsb2NrPgpbMV0gZWZpcnRjMDogcmVnaXN0ZXJlZCBhcyBhIHRpbWUtb2YtZGF5 IGNsb2NrLCByZXNvbHV0aW9uIDEuMDAwMDAwcwpbMV0gc21iaW9zMDogPFN5c3RlbSBNYW5hZ2Vt ZW50IEJJT1M+ClsxXSBzbWJpb3MwOiBWZXJzaW9uOiAzLjAKWzFdIHRybmcwOiA8QXJtIFNNQ0ND IFRSTkc+IG9uIHNtY2NjMApbMV0gcmFuZG9tOiByZWdpc3RlcmluZyBmYXN0IHNvdXJjZSBBcm0g U01DQ0MgVFJORwpbMV0gcG11MDogPFBlcmZvcm1hbmNlIE1vbml0b3JpbmcgVW5pdD4gb24gYWNw aTAKWzFdIGNwdTA6IDxBQ1BJIENQVT4gb24gYWNwaTAKWzFdIHVhcnQwOiA8UHJpbWVDZWxsIFVB UlQgKFBMMDExKT4gaW9tZW0gMHg5MDAwMDAwLTB4OTAwMGZmZiBpcnEgMCBvbiBhY3BpMApbMV0g dWFydDA6IGNvbnNvbGUgKDk2MDAsbiw4LDEpClsxXSBwY2liMDogPEdlbmVyaWMgUENJIGhvc3Qg Y29udHJvbGxlcj4gb24gYWNwaTAKWzFdIHBjaTA6IDxQQ0kgYnVzPiBvbiBwY2liMApbMV0gdmly dGlvX3BjaTA6IDxWaXJ0SU8gUENJIChtb2Rlcm4pIEdQVSBhZGFwdGVyPiBtZW0gMHgxMzAxOTAw MC0weDEzMDE5ZmZmLDB4ODAzMDAwMDAwMC0weDgwMzAwMDNmZmYgYXQgZGV2aWNlIDEuMCBvbiBw Y2kwClsxXSB2dGdwdTA6IDxWaXJ0SU8gR1BVPiBvbiB2aXJ0aW9fcGNpMApbMV0gVlQ6IGluaXRp YWxpemUgd2l0aCBuZXcgVlQgZHJpdmVyICJ2aXJ0aW9fZ3B1Ii4KWzFdIHhoY2kwOiA8WEhDSSAo Z2VuZXJpYykgVVNCIDMuMCBjb250cm9sbGVyPiBtZW0gMHg4MDMwMDA4MDAwLTB4ODAzMDAwYmZm ZiBhdCBkZXZpY2UgMi4wIG9uIHBjaTAKWzFdIHhoY2kwOiAzMiBieXRlcyBjb250ZXh0IHNpemUs IDY0LWJpdCBETUEKWzFdIHVzYnVzMCBvbiB4aGNpMApbMV0gcGNpYjE6IDxQQ0ktUENJIGJyaWRn ZT4gbWVtIDB4MTMwMTgwMDAtMHgxMzAxOGZmZiBhdCBkZXZpY2UgMy4wIG9uIHBjaTAKWzFdIHBj aTE6IDxQQ0kgYnVzPiBvbiBwY2liMQpbMV0gdmlydGlvX3BjaTE6IDxWaXJ0SU8gUENJIChtb2Rl cm4pIE5ldHdvcmsgYWRhcHRlcj4gbWVtIDB4MTJlMDAwMDAtMHgxMmUwMGZmZiwweDgwMDAwMDAw MDAtMHg4MDAwMDAzZmZmIGF0IGRldmljZSAwLjAgb24gcGNpMQpbMV0gdnRuZXQwOiA8VmlydElP IE5ldHdvcmtpbmcgQWRhcHRlcj4gb24gdmlydGlvX3BjaTEKWzFdIHZ0bmV0MDogRXRoZXJuZXQg YWRkcmVzczogMDI6MDA6MTc6MDY6MDY6NDIKWzFdIHZ0bmV0MDogbmV0bWFwIHF1ZXVlcy9zbG90 czogVFggMi8yNTYsIFJYIDIvMTI4ClsxXSAwMDAuMDAwMDc4IFsgNDUyXSB2dG5ldF9uZXRtYXBf YXR0YWNoICAgICAgIHZ0bmV0IGF0dGFjaGVkIHR4cT0yLCB0eGQ9MjU2IHJ4cT0yLCByeGQ9MTI4 ClsxXSBwY2liMjogPFBDSS1QQ0kgYnJpZGdlPiBtZW0gMHgxMzAxNzAwMC0weDEzMDE3ZmZmIGF0 IGRldmljZSAzLjEgb24gcGNpMApbMV0gcGNpMjogPFBDSSBidXM+IG9uIHBjaWIyClsxXSBwY2li MzogPFBDSS1QQ0kgYnJpZGdlPiBtZW0gMHgxMzAxNjAwMC0weDEzMDE2ZmZmIGF0IGRldmljZSAz LjIgb24gcGNpMApbMV0gcGNpMzogPFBDSSBidXM+IG9uIHBjaWIzClsxXSBwY2liNDogPFBDSS1Q Q0kgYnJpZGdlPiBtZW0gMHgxMzAxNTAwMC0weDEzMDE1ZmZmIGF0IGRldmljZSAzLjMgb24gcGNp MApbMV0gcGNpNDogPFBDSSBidXM+IG9uIHBjaWI0ClsxXSBwY2liNTogPFBDSS1QQ0kgYnJpZGdl PiBtZW0gMHgxMzAxNDAwMC0weDEzMDE0ZmZmIGF0IGRldmljZSAzLjQgb24gcGNpMApbMV0gcGNp NTogPFBDSSBidXM+IG9uIHBjaWI1ClsxXSBwY2liNjogPFBDSS1QQ0kgYnJpZGdlPiBtZW0gMHgx MzAxMzAwMC0weDEzMDEzZmZmIGF0IGRldmljZSAzLjUgb24gcGNpMApbMV0gcGNpNjogPFBDSSBi dXM+IG9uIHBjaWI2ClsxXSBwY2liNzogPFBDSS1QQ0kgYnJpZGdlPiBtZW0gMHgxMzAxMjAwMC0w eDEzMDEyZmZmIGF0IGRldmljZSAzLjYgb24gcGNpMApbMV0gcGNpNzogPFBDSSBidXM+IG9uIHBj aWI3ClsxXSBwY2liODogPFBDSS1QQ0kgYnJpZGdlPiBtZW0gMHgxMzAxMTAwMC0weDEzMDExZmZm IGF0IGRldmljZSAzLjcgb24gcGNpMApbMV0gcGNpODogPFBDSSBidXM+IG9uIHBjaWI4ClsxXSBw Y2liOTogPFBDSS1QQ0kgYnJpZGdlPiBtZW0gMHgxMzAxMDAwMC0weDEzMDEwZmZmIGF0IGRldmlj ZSA0LjAgb24gcGNpMApbMV0gcGNpOTogPFBDSSBidXM+IG9uIHBjaWI5ClsxXSBwY2liMTA6IDxQ Q0ktUENJIGJyaWRnZT4gbWVtIDB4MTMwMGYwMDAtMHgxMzAwZmZmZiBhdCBkZXZpY2UgNC4xIG9u IHBjaTAKWzFdIHBjaTEwOiA8UENJIGJ1cz4gb24gcGNpYjEwClsxXSBwY2liMTE6IDxQQ0ktUENJ IGJyaWRnZT4gbWVtIDB4MTMwMGUwMDAtMHgxMzAwZWZmZiBhdCBkZXZpY2UgNC4yIG9uIHBjaTAK WzFdIHBjaTExOiA8UENJIGJ1cz4gb24gcGNpYjExClsxXSBwY2liMTI6IDxQQ0ktUENJIGJyaWRn ZT4gbWVtIDB4MTMwMGQwMDAtMHgxMzAwZGZmZiBhdCBkZXZpY2UgNC4zIG9uIHBjaTAKWzFdIHBj aTEyOiA8UENJIGJ1cz4gb24gcGNpYjEyClsxXSBwY2liMTM6IDxQQ0ktUENJIGJyaWRnZT4gbWVt IDB4MTMwMGMwMDAtMHgxMzAwY2ZmZiBhdCBkZXZpY2UgNC40IG9uIHBjaTAKWzFdIHBjaTEzOiA8 UENJIGJ1cz4gb24gcGNpYjEzClsxXSBwY2liMTQ6IDxQQ0ktUENJIGJyaWRnZT4gbWVtIDB4MTMw MGIwMDAtMHgxMzAwYmZmZiBhdCBkZXZpY2UgNC41IG9uIHBjaTAKWzFdIHBjaTE0OiA8UENJIGJ1 cz4gb24gcGNpYjE0ClsxXSBwY2liMTU6IDxQQ0ktUENJIGJyaWRnZT4gbWVtIDB4MTMwMGEwMDAt MHgxMzAwYWZmZiBhdCBkZXZpY2UgNC42IG9uIHBjaTAKWzFdIHBjaTE1OiA8UENJIGJ1cz4gb24g cGNpYjE1ClsxXSBwY2liMTY6IDxQQ0ktUENJIGJyaWRnZT4gbWVtIDB4MTMwMDkwMDAtMHgxMzAw OWZmZiBhdCBkZXZpY2UgNC43IG9uIHBjaTAKWzFdIHBjaTE2OiA8UENJIGJ1cz4gb24gcGNpYjE2 ClsxXSBwY2liMTc6IDxQQ0ktUENJIGJyaWRnZT4gbWVtIDB4MTMwMDgwMDAtMHgxMzAwOGZmZiBh dCBkZXZpY2UgNS4wIG9uIHBjaTAKWzFdIHBjaTE3OiA8UENJIGJ1cz4gb24gcGNpYjE3ClsxXSBw Y2liMTg6IDxQQ0ktUENJIGJyaWRnZT4gbWVtIDB4MTMwMDcwMDAtMHgxMzAwN2ZmZiBhdCBkZXZp Y2UgNS4xIG9uIHBjaTAKWzFdIHBjaTE4OiA8UENJIGJ1cz4gb24gcGNpYjE4ClsxXSBwY2liMTk6 IDxQQ0ktUENJIGJyaWRnZT4gbWVtIDB4MTMwMDYwMDAtMHgxMzAwNmZmZiBhdCBkZXZpY2UgNS4y IG9uIHBjaTAKWzFdIHBjaTE5OiA8UENJIGJ1cz4gb24gcGNpYjE5ClsxXSBwY2liMjA6IDxQQ0kt UENJIGJyaWRnZT4gbWVtIDB4MTMwMDUwMDAtMHgxMzAwNWZmZiBhdCBkZXZpY2UgNS4zIG9uIHBj aTAKWzFdIHBjaTIwOiA8UENJIGJ1cz4gb24gcGNpYjIwClsxXSBwY2liMjE6IDxQQ0ktUENJIGJy aWRnZT4gbWVtIDB4MTMwMDQwMDAtMHgxMzAwNGZmZiBhdCBkZXZpY2UgNS40IG9uIHBjaTAKWzFd IHBjaTIxOiA8UENJIGJ1cz4gb24gcGNpYjIxClsxXSBwY2liMjI6IDxQQ0ktUENJIGJyaWRnZT4g bWVtIDB4MTMwMDMwMDAtMHgxMzAwM2ZmZiBhdCBkZXZpY2UgNS41IG9uIHBjaTAKWzFdIHBjaTIy OiA8UENJIGJ1cz4gb24gcGNpYjIyClsxXSBwY2liMjM6IDxQQ0ktUENJIGJyaWRnZT4gbWVtIDB4 MTMwMDIwMDAtMHgxMzAwMmZmZiBhdCBkZXZpY2UgNS42IG9uIHBjaTAKWzFdIHBjaTIzOiA8UENJ IGJ1cz4gb24gcGNpYjIzClsxXSBwY2liMjQ6IDxQQ0ktUENJIGJyaWRnZT4gbWVtIDB4MTMwMDEw MDAtMHgxMzAwMWZmZiBhdCBkZXZpY2UgNS43IG9uIHBjaTAKWzFdIHBjaTI0OiA8UENJIGJ1cz4g b24gcGNpYjI0ClsxXSB2aXJ0aW9fcGNpMjogPFZpcnRJTyBQQ0kgKG1vZGVybikgU0NTSSBhZGFw dGVyPiBtZW0gMHgxMDAwMDAwMC0weDEwMDAwZmZmLDB4ODAyZTAwMDAwMC0weDgwMmUwMDNmZmYg YXQgZGV2aWNlIDAuMCBvbiBwY2kyNApbMV0gdnRzY3NpMDogPFZpcnRJTyBTQ1NJIEFkYXB0ZXI+ IG9uIHZpcnRpb19wY2kyClsxXSB2aXJ0aW9fcGNpMzogPFZpcnRJTyBQQ0kgKG1vZGVybikgTmV0 d29yayBhZGFwdGVyPiBtZW0gMHgxMzAwMDAwMC0weDEzMDAwZmZmLDB4ODAzMDAwNDAwMC0weDgw MzAwMDdmZmYgYXQgZGV2aWNlIDYuMCBvbiBwY2kwClsxXSB2dG5ldDE6IDxWaXJ0SU8gTmV0d29y a2luZyBBZGFwdGVyPiBvbiB2aXJ0aW9fcGNpMwpbMV0gdnRuZXQxOiBFdGhlcm5ldCBhZGRyZXNz OiAwMjowMDoxNzowMjpiMDpmNwpbMV0gdnRuZXQxOiBuZXRtYXAgcXVldWVzL3Nsb3RzOiBUWCAy LzI1NiwgUlggMi8xMjgKWzFdIDAwMC4wMDAwNzkgWyA0NTJdIHZ0bmV0X25ldG1hcF9hdHRhY2gg ICAgICAgdnRuZXQgYXR0YWNoZWQgdHhxPTIsIHR4ZD0yNTYgcnhxPTIsIHJ4ZD0xMjgKWzFdIGFj cGlfZ2VkMDogPEdlbmVyaWMgRXZlbnQgRGV2aWNlPiBpcnEgMzMgb24gYWNwaTAKWzFdIGFjcGlf Z2VkMDogUmF3IElSUSA0MQpbMV0gYWNwaV9idXR0b24wOiA8UG93ZXIgQnV0dG9uPiBvbiBhY3Bp MApbMV0gYXJtdjhjcnlwdG8wOiA8QUVTLUNCQyxBRVMtWFRTLEFFUy1HQ00+ClsxXSBUaW1lY291 bnRlcnMgdGljayBldmVyeSAxLjAwMCBtc2VjClsxXSB1c2J1czA6IDUuMEdicHMgU3VwZXIgU3Bl ZWQgVVNCIHYzLjAKWzFdIHVnZW4wLjE6IDwoMHgxYjM2KSBYSENJIHJvb3QgSFVCPiBhdCB1c2J1 czAKWzFdIHVodWIwIG9uIHVzYnVzMApbMV0gdWh1YjA6IDwoMHgxYjM2KSBYSENJIHJvb3QgSFVC LCBjbGFzcyA5LzAsIHJldiAzLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXMwClsxXSBaRlMgZmls ZXN5c3RlbSB2ZXJzaW9uOiA1ClsxXSBaRlMgc3RvcmFnZSBwb29sIHZlcnNpb246IGZlYXR1cmVz IHN1cHBvcnQgKDUwMDApClsxXSBDUFUgIDA6IEFSTSBOZW92ZXJzZS1OMSByM3AxIGFmZmluaXR5 OiAgMApbMV0gICAgICAgICAgICAgICAgICAgIENhY2hlIFR5cGUgPSA8SURDLDY0IGJ5dGUgQ1dH LDY0IGJ5dGUgRVJHLDY0IGJ5dGUgRC1jYWNoZWxpbmUsUElQVCBJLWNhY2hlLDY0IGJ5dGUgSS1j YWNoZWxpbmU+ClsxXSAgSW5zdHJ1Y3Rpb24gU2V0IEF0dHJpYnV0ZXMgMCA9IDxEUCxSRE0sQXRv bWljLENSQzMyLFNIQTIsU0hBMSxBRVMrUE1VTEw+ClsxXSAgSW5zdHJ1Y3Rpb24gU2V0IEF0dHJp YnV0ZXMgMSA9IDxSQ1BDLTguMyxEQ1BvUD4KWzFdICBJbnN0cnVjdGlvbiBTZXQgQXR0cmlidXRl cyAyID0gPD4KWzFdICAgICAgICAgIFByb2Nlc3NvciBGZWF0dXJlcyAwID0gPENTVjMsQ1NWMixS QVMsR0lDLEFkdlNJTUQrSFAsRlArSFAsRUwzLEVMMixFTDEsRUwwIDMyPgpbMV0gICAgICAgICAg UHJvY2Vzc29yIEZlYXR1cmVzIDEgPSA8UFNUQVRFLlNTQlMgTVNSPgpbMV0gICAgICAgICAgUHJv Y2Vzc29yIEZlYXR1cmVzIDIgPSA8PgpbMV0gICAgICAgTWVtb3J5IE1vZGVsIEZlYXR1cmVzIDAg PSA8VEdyYW40LFRHcmFuNjQsVEdyYW4xNixTTlNNZW0sQmlnRW5kLDE2Yml0IEFTSUQsMjU2VEIg UEE+ClsxXSAgICAgICBNZW1vcnkgTW9kZWwgRmVhdHVyZXMgMSA9IDxQQU4rQVRTMUUxLExPLEhQ RCtUVFBCSEEsVkgsMTZiaXQgVk1JRCxIQUYrRFM+ClsxXSAgICAgICBNZW1vcnkgTW9kZWwgRmVh dHVyZXMgMiA9IDwzMmJpdCBDQ0lEWCw0OGJpdCBWQSxVQU8sQ25QPgpbMV0gICAgICAgTWVtb3J5 IE1vZGVsIEZlYXR1cmVzIDMgPSA8PgpbMV0gICAgICAgTWVtb3J5IE1vZGVsIEZlYXR1cmVzIDQg PSA8PgpbMV0gICAgICAgICAgICAgIERlYnVnIEZlYXR1cmVzIDAgPSA8RG91YmxlTG9jayxTUEUs MiBDVFggQktQVHMsNCBXYXRjaHBvaW50cyw2IEJyZWFrcG9pbnRzLFBNVXYzcDEsRGVidWd2OHAy PgpbMV0gICAgICAgICAgICAgIERlYnVnIEZlYXR1cmVzIDEgPSA8PgpbMV0gICAgICAgICAgQXV4 aWxpYXJ5IEZlYXR1cmVzIDAgPSA8PgpbMV0gICAgICAgICAgQXV4aWxpYXJ5IEZlYXR1cmVzIDEg PSA8PgpbMV0gQUFyY2gzMiBJbnN0cnVjdGlvbiBTZXQgQXR0cmlidXRlcyA1ID0gPFJETSxDUkMz MixTSEEyLFNIQTEsQUVTK1ZNVUxMLFNFVkw+ClsxXSBBQXJjaDMyIE1lZGlhIGFuZCBWRlAgRmVh dHVyZXMgMCA9IDxGUFJvdW5kLEZQU3FydCxGUERpdmlkZSxEUCBWRlB2Myt2NCxTUCBWRlB2Myt2 NCxBZHZTSU1EPgpbMV0gQUFyY2gzMiBNZWRpYSBhbmQgVkZQIEZlYXR1cmVzIDEgPSA8U0lNREZN QUMsRlBIUCBBcml0aCxTSU1ESFAgQXJpdGgsU0lNRFNQLFNJTURJbnQsU0lNRExTLEZQRE5hTixG UEZ0Wj4KWzFdIENQVSAgMTogQVJNIE5lb3ZlcnNlLU4xIHIzcDEgYWZmaW5pdHk6ICAxClsxXSBD UFUgIDI6IEFSTSBOZW92ZXJzZS1OMSByM3AxIGFmZmluaXR5OiAgMgpbMV0gQ1BVICAzOiBBUk0g TmVvdmVyc2UtTjEgcjNwMSBhZmZpbml0eTogIDMKWzFdIGdpYzA6IHVzaW5nIGZvciBJUElzClsx XSBSZWxlYXNlIEFQcy4uLlRyeWluZyB0byBtb3VudCByb290IGZyb20gemZzOnpyb290L1JPT1Qv MjAyNC0xMS0wNi0wODQ4MzMgW10uLi4KWzFdIGRvbmUKWzFdIHBhc3MwIGF0IHZ0c2NzaTAgYnVz IDAgc2NidXMwIHRhcmdldCAwIGx1biAwCnBhc3MwOiA8UUVNVSBRRU1VIFRBUkdFVCAyLjU+IEZp eGVkIFVuaW5zdGFsbGVkIFNQQy0zIFNDU0kgZGV2aWNlIChvZmZsaW5lKQpwYXNzMDpkYTAgYXQg dnRzY3NpMCBidXMgMCBzY2J1czAgdGFyZ2V0IDAgbHVuIDEKWzFdIGRhMDogPE9SQUNMRSBCbG9j a1ZvbHVtZSAxLjA+IEZpeGVkIERpcmVjdCBBY2Nlc3MgU1BDLTUgU0NTSSBkZXZpY2UKZGEwOiAz MDAuMDAwTUIvcyB0cmFuc2ZlcnMKZGEwOiBDb21tYW5kIFF1ZXVlaW5nIGVuYWJsZWQKZGEwOiAy MDQ4MDBNQiAoNDE5NDMwNDAwIDUxMiBieXRlIHNlY3RvcnMpClsxXSAgMzAwLjAwME1CL3MgdHJh bnNmZXJzCnBhc3MwOiBDb21tYW5kIFF1ZXVlaW5nIGVuYWJsZWQKWzFdIChkYTA6dnRzY3NpMDow OjA6MSk6IFJFQUQoNikvV1JJVEUoNikgbm90IHN1cHBvcnRlZCwgaW5jcmVhc2luZyBtaW5pbXVt X2NtZF9zaXplIHRvIDEwLgpbMV0gR0VPTTogd2FybmluZzogZGEwIGxiYV9zdGFydCAzIDwgcmVx dWlyZWQgbWluIDM0ClsyXSB1aHViMDogOCBwb3J0cyB3aXRoIDggcmVtb3ZhYmxlLCBzZWxmIHBv d2VyZWQKWzJdIHVnZW4wLjI6IDxRRU1VIFFFTVUgVVNCIFRhYmxldD4gYXQgdXNidXMwClsyXSBS b290IG1vdW50IHdhaXRpbmcgZm9yOiB1c2J1czAKWzNdIHVnZW4wLjM6IDxRRU1VIFFFTVUgVVNC IEtleWJvYXJkPiBhdCB1c2J1czAKWzNdIHVrYmQwIG9uIHVodWIwClszXSB1a2JkMDogPFFFTVUg UUVNVSBVU0IgS2V5Ym9hcmQsIGNsYXNzIDAvMCwgcmV2IDIuMDAvMC4wMCwgYWRkciAyPiBvbiB1 c2J1czAKWzNdIGtiZDEgYXQgdWtiZDAKWzNdIHVnZW4wLjQ6IDxRRU1VIFFFTVUgVVNCIE1vdXNl PiBhdCB1c2J1czAKWzNdIChkYTA6dnRzY3NpMDowOjA6MSk6IFNZTkNIUk9OSVpFIENBQ0hFKDEw KS4gQ0RCOiAzNSAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAKWzNdIChkYTA6dnRzY3NpMDow OjA6MSk6IENBTSBzdGF0dXM6IFNDU0kgU3RhdHVzIEVycm9yClszXSAoZGEwOnZ0c2NzaTA6MDow OjEpOiBTQ1NJIHN0YXR1czogQ2hlY2sgQ29uZGl0aW9uClszXSAoZGEwOnZ0c2NzaTA6MDowOjEp OiBTQ1NJIHNlbnNlOiBJTExFR0FMIFJFUVVFU1QgYXNjOjIwLDAgKEludmFsaWQgY29tbWFuZCBv cGVyYXRpb24gY29kZSkKWzNdIChkYTA6dnRzY3NpMDowOjA6MSk6IEVycm9yIDIyLCBVbnJldHJ5 YWJsZSBlcnJvcgpbM10gRHVhbCBDb25zb2xlOiBTZXJpYWwgUHJpbWFyeSwgVmlkZW8gU2Vjb25k YXJ5Cls0XSBHRU9NX0VMSTogRGV2aWNlIGdwdC9zd2FwLmVsaSBjcmVhdGVkLgpbNF0gR0VPTV9F TEk6IEVuY3J5cHRpb246IEFFUy1YVFMgMTI4Cls0XSBHRU9NX0VMSTogICAgIENyeXB0bzogYWNj ZWxlcmF0ZWQgc29mdHdhcmUKWzZdIGJyaWRnZTA6IEV0aGVybmV0IGFkZHJlc3M6IDU4OjljOmZj OjAwOmNkOjE1Cls2XSB2dG5ldDA6IHByb21pc2N1b3VzIG1vZGUgZW5hYmxlZApbNl0gYnJpZGdl MDogbGluayBzdGF0ZSBjaGFuZ2VkIHRvIERPV04KWzZdIGxvMDogbGluayBzdGF0ZSBjaGFuZ2Vk IHRvIFVQCls2XSB2dG5ldDA6IGxpbmsgc3RhdGUgY2hhbmdlZCB0byBVUApbNl0gYnJpZGdlMDog bGluayBzdGF0ZSBjaGFuZ2VkIHRvIFVQCls2XSB2dG5ldDE6IGxpbmsgc3RhdGUgY2hhbmdlZCB0 byBVUApbMTBdIHVoaWQwIG9uIHVodWIwClsxMF0gdWhpZDA6IDxRRU1VIFFFTVUgVVNCIFRhYmxl dCwgY2xhc3MgMC8wLCByZXYgMi4wMC8wLjAwLCBhZGRyIDE+IG9uIHVzYnVzMApbMTBdIHVtczAg b24gdWh1YjAKWzEwXSB1bXMwOiA8UUVNVSBRRU1VIFVTQiBNb3VzZSwgY2xhc3MgMC8wLCByZXYg Mi4wMC8wLjAwLCBhZGRyIDM+IG9uIHVzYnVzMApbMTBdIHVtczA6IDMgYnV0dG9ucyBhbmQgW1hZ Wl0gY29vcmRpbmF0ZXMgSUQ9MAo= --=_619464079b8b191d8b67e82273e7326c-- --=_3eb424eb17b7ffc28bced07b5d905122 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc; size=833 Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmcuGroACgkQEg2wmwP4 2IY0nxAAp0z/L40kfbrFNXCE+sZ7BcSOIfd8mXAeidwuCI4bCQRa0ivtcQ2O2zmK o6GmQ5sSLGaNy9ja3ZybKxia9pAssgwnYp2n15VxOGhbU1wV5TYc2OQg96Jv3Hly rgA3WFtndTOqE7+3bY19V9aUdLOF56EMa/9dA8N9r0lfG6yV6qyYZvIL0keSHhlj ZydG5gnEK2OdDezci0z6knFUcE0DxEkywlEYnHinkSoJHQM9sAa7R5Fc6URkkb29 hE88CDcMky+ptAd963/F1fwWUHo8YRFbMzhEwdV/ok2mhe/dCAYfDR+4SaMc6Uex 50QOR171H/KKH2HgSbHHvyqO1rg9/+St8Oc1ouGjU5pTrrfZ4K9rcIdAGSXqtiCK jSAKhjADZlNyScXJiX0OPmysAJ/HIfZI+dulFAZ81oNvafG7M+hkfHW+ZhccFWFt 4BlOPDBJ6oG4gZwyWoaL9/lF+VsAjLLbWeWmqnWzQU5SEqOFsWEFfkLHvFmv9ccJ 4VeR+1o1iGD5NMx8K25tgeWQXWpObyqVYuyoZEr6JYJgVx4GDbGrdJacWIWSrNbg OTX0EbDLiUl6Qky/d5CrSKgp0GYsoppWprgkVXwU9EpfPJY2ttIsyHlXnKk7TyYj OFala8QeS5VXZbg+4KnIvKM+3npTCSThtcie5P1ag9tqmBvQsfQ= =+E4o -----END PGP SIGNATURE----- --=_3eb424eb17b7ffc28bced07b5d905122-- From nobody Fri Nov 8 18:16:35 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 4XlRwh02p4z5cbbH for ; Fri, 08 Nov 2024 18:16:52 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-20.consmr.mail.gq1.yahoo.com (sonic305-20.consmr.mail.gq1.yahoo.com [98.137.64.83]) (using TLSv1.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 4XlRwg4cRrz43ZK for ; Fri, 8 Nov 2024 18:16:51 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1731089810; bh=ahaQpF9BGD/q6I6WpaKWU0skt6XjzYN1uC319aS2qY8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=kBfsQT7My5gZMDRMrNZV/1qhRGptfjJw84xaInq7lPY/KCwSA0uOvC4UPjYF+8v8jQXe3xqmmKlaeBe7gmtcQnNE0kbXZQ0iPjbUOJycL7QtP/Z5M4ymX+Y+hgfA0etPjTk4zuqJKsQ2rfYmiC3riZ/xIv7fB44qZYIqi2jJCrgl2JL3OvhJC0TqQs3nqKdsxDPksTvFOCZN8Vp9Yma/hMvps3dsRWHVR/v2Zb4ve6wOnb9xvicdRM+ORqqD7++EY/JuOxxwXvgH8REdev7WwG2ZEt2yl+DpIq9HhsURnd2PEcBCW3+t/Xwv+xOr3TwduZ/u40wiJQrA6mbdjd1WUQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1731089810; bh=MMhIOqmN70GHiVw8HG3I8FKeJojSZjF/hXUCXSsQjWy=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=tHgBfPiyA1rb0gWArn1s8UyVRCKVjIWw/ZRlhKJ1vKP7lg6pBGpeoNrex1ZbL7+kKro68QmgKIsFUFD92B5GjjPjk1LFKj0iRkkTm+UwOjQt9fjJXRwS1YmOkqSmVLeKuTOMF1ZhJPblKCYZbroYXR/0HGl7Pyv9GYq6xNViEHqYGmaKi16AR9y9Rn54FixgfXbpShAqTRmwN2pDdcY1c83aqoR9MXQrfcTsEPW6ZmLJZHNTj1Qm85ougHMBW3mEbwrlmXmjvk/b/8cE5exLpY1IrUaI0LT/ItffUwAInybjXdZcorGIwJr0dRwOmjpvdJKkwlVbtUfivkR0M0vtvA== X-YMail-OSG: QoJHbRYVM1kvxCKgSUWFUBluhR223_Ap6l7AL.iabuCbcBrunba5M4tC7AJ7erM hROrUX.4q4ZfEMSdaag4q9yY..HwlLxZRRGMxocxDOaMfe0Fj95qCBKvsrkX61ceyqWO5_wY9ySb wGO6ENDZ.GGQWRckea9C5pr9tAJLmPcDLMd9QRwVr3x8GVHHuyswhtN_1uoJG5qh33kvN1pUHRUv pG78uODX2B19Etm.ank5x2Swgs3ilqjBpUcwm5mJ90h_FNpOqvFhqUKEpr5j3d5mBCwiwobco6mG sdNwpyNWrO2BrtX4UoyIN5eiKtUHHtqbPS9bOHo_1XqKocUqkwUGzTTYEfQDA2ohE5EmCr2oBjMM OjDPp75eHPP0r8Kb2fFqX8PvzFrijonqWOUB4R3P0PAW.XQhWxyaZ4eaca1s4weWmD6ugKBLVCFZ qT9qb9radILHqU1Nwde6UXQD.SiZ2bb1dhHM2kYnbw9X095Gq69NCIYZ_PyicIoHtypGV5gkT..G KOOSKSBkTuVQ0koe_2HnVzLsdgAX4Hr.vo7nyMsrDuJdTiqIwp31hed9IBvzwp3pD5QHG7znmfND FsBBsiyw2uDPt0jr5yb6TfNFydQtUgbT7FkokQdoeEAV97cpyJkSUwNet61zX5T3HC52tOXtA_k8 MYGKuID52gN1o1UQltHLd3KbWdY.E9NhNIBc2FGXrpmPEHITPXn3ATVFHB82r7ZC385r6ZpRpa7S Xtxs4JLOJq45T1_8q4Ywz0kNqmWdrhlkh2SbnrKyAbcG1TYyAamrhLoOtBP2si4qRVjIg8sK3IwE iwoJJZ1FG7G2.jXvBS7oYmQ6vA37ky1HrRCRqHsfjPchZ7OAck__KEsFPrREf19qhTlJKH41_dXh 7jKALb8njjGer_gytKBLy05WB3jAND.18o2r6MWXkze2O_ElFtAb.UCrUqunYnCRpeA7jjreu0e7 ywf28uupedOsYEWXLJRhwF.66PkSq5NUj9Wr1R2Bq3IEnzQ6biJnL_AP6srKRuZKJRGoyif1Jq4h eh..42hzI8Zuj7kGg8rp3hrLxJ5J32XAqBvcy_EWyn52sefrpaX6mPzg.aMPbTKSeMG4SvkSvsPW eRJYYnXCHRLa0nctuadQ6p9bsOSBHAnCHkRxbYX0_rf3lM95UMNgU3uWFYJpll5TSXo8I_NCodE4 hx7p9xxre7O1QNS1_AQ7DzXhgWANYcNvdVEPZd0h90Qd9NLSKoYIhK4lRNzx.ct9b4aF7a.RgftN E7tdVIzCKVTbsJOmdljDgE4kMEjhY9t3jU_HjSoSvF5AhBJbmy7DAvug32j12wupLt_x7eYG_th8 Ge4loFBLd2TdjTLhmj.Qq7qf6dtVywk.NIEcR3cGT6IMBOQ3wmJ949kgJN8MsZ_J3XRtEVFKHHla vm4QN0UwrwUR0vT7Os_aSZHWYjTRiMDE3E4weDvyi1EbJJDu530nucZDQici1pWX_tk86p0ZbgRZ CBGuz0E1SYKGpMQLCx6_tzH.7Vekk8yZUGmiv9_oG0ZDC7O22lu83k15Am4fVef6HDdsXVfJo8h. 7JacxCEbZEQFJkEjFU3jkChvMXJo0PCPLRA8VDm71O3Xe3tHED3S5Hzt2I4i3.2LblEHQGOmj6_h pDIDP7._GJbWd8wrR_g4toQ2t5qbSHYcSjK0ex8IT_J2F._PN2yCXzVS24Fn8ZI_cAXTOPrVIo_p TA7r.rRMHBsm9vpl9vjRmyUH0VnNu0U_B4AhzK6CIl6UpG5PngHGhnlJPbSJakiQJpeh2iC_Upgp _w8pQHNq8cU3BdbvoNfB25psw1a.HYjRp8R9cwi4bOBRacQay2KFcSNlE4D_wrgWptChDT6si9Ks oAvKfewf2ERVANxlChlAuWjebNdmrgl.PgvzctnaibcKHaFiDiaCzPjLDFhYGOxVfhuXqSoF9bHy YInLvTAaTZ7q.EglTC9I6iM.XjzRLOtsvwSd1RldKVly45PzmRlIpaRdXd0uGapb6WB2ez.5XY9Z 086KjxCFwAKoOkmYjVwsAVSP1BJTyrBsdu.smoXVTIxT5Ybsi8nV_GHh2hJK3G_OI8DVgr2aJy1X t_.9vGyTpwAUOnJd8gfCtzhYLutwWc5j1FP.DngsniqtaGv3DpzZ1m1opxi75FCDGd5OHz5Gh9Oo CjOEDGZR9rAu1Gc8.khfU.bQSyJ87vGIfDEAEGyY39uXvHyoDdYNZ0ihKiGliPay1i22.Y5TOuJa PW2t6jsz9I0.aCE0WDP8i3mmy3idN63eI5PoVOhj286E9ezj28UJzofoo1tG4LKCyvmtHgKnqXPI JjNuAbAHqpTT96hXvm0g- X-Sonic-MF: X-Sonic-ID: 97381f05-9a3d-4f34-bd78-c7f9e847ea25 Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Fri, 8 Nov 2024 18:16:50 +0000 Received: by hermes--production-gq1-5dd4b47f46-bxhh2 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 2c56abce08fd9a1392a762ae31f2c3f3; Fri, 08 Nov 2024 18:16:46 +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 \(3776.700.51\)) Subject: Re: Official armv7 PkgBase kernel-NODEBUG installation's USB2 boot gets "Fatal kernel mode data abort: 'Alignment Fault' on write" very early, at least on an OrangePi+ 2ed From: Mark Millard In-Reply-To: <4c29d5cb-0a31-4131-a3a9-846fd4ce926f@FreeBSD.org> Date: Fri, 8 Nov 2024 10:16:35 -0800 Cc: FreeBSD ARM List , Current FreeBSD , FreeBSD Toolchain , Dimitry Andric Content-Transfer-Encoding: quoted-printable Message-Id: References: <74468E62-5A74-4FB4-94F6-599E5BA3A9A1@yahoo.com> <4c29d5cb-0a31-4131-a3a9-846fd4ce926f@FreeBSD.org> To: "mmel@freebsd.org" X-Mailer: Apple Mail (2.3776.700.51) X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Queue-Id: 4XlRwg4cRrz43ZK X-Spamd-Bar: ---- On Nov 8, 2024, at 04:49, Michal Meloun wrote: > On 08.11.2024 4:15, Mark Millard wrote: >> [I narrowed the artifact kernel range for the change in the type of >> failure that happens.] >> On Nov 7, 2024, at 17:43, Mark Millard wrote: >>> [The change to LLVM 19 is what leads to the Alignment >>> Fault' on write failure. Details later below.] >>>=20 >>> On Nov 7, 2024, at 01:42, Mark Millard wrote: >>>=20 >>>> . . . > Hi Mark, >=20 > Please see https://reviews.freebsd.org/D47485 Wow. Use of the likes of: #ifdef ARM_NEW_PMAP . . . #define VM_MEMATTR_UNCACHEABLE VM_MEMATTR_SO /*name is misused by DMA */ . . . #else /* Memory attribute configuration. */ #define VM_MEMATTR_DEFAULT 0 #define VM_MEMATTR_UNCACHEABLE 1 +#endif and later versions of the header realtive to VM_MEMATTR_UNCACHEABLE goes back to: QUOTE author Ian Lepore 2015-03-26 21:13:53 +0000 committer Ian Lepore 2015-03-26 21:13:53 +0000 . . . New pmap code for armv6. Disabled by default, option ARM_NEW_PMAP = enables it. This is pretty much a complete rewrite based on the existing i386 code. = The patches have been circulating for a couple years and have been = looked at by plenty of people, but I'm not putting anybody on the hook = as having reviewed this in any formal sense except myself. After this has gotten wider testing from the user community, = ARM_NEW_PMAP will become the default and various dregs of the old pmap = code will be removed. Submitted by: Svatopluk Kraus , Michal Meloun END QUOTE So 9+ years, with after late-enough in 2016-May being with unaligned access being supported. > Unfortunately, I see 2 problems with llvm 19. >=20 > The first is regression, the compiler generates inline memset() = accessing non-aligned data with sub-optimal instructions (with word = access). This regression triggers bug in the kernel (which should be = fixed in D47485). If I read the just-above right, the LLVM 19 memset issue is a sub-optimal issue rather than a its-broken issue: The VM_MEMATTR_SO use is the aspect that is broken in the area. (Given the below issue, general testing of the use of VM_MEMATTR_NOCACHE instead seems problematical.) > Second, regarding "panic: acquiring blockable sleep lock" is due to an = bug in lld. It mis-links the ".ARM.exidx" section on the output = binary, which is used by the stack unwinder in the kernel. > I don't have a fix for this for now, so you have to use the linker = from llvm18 as a workaround. If I read the just-above right, the .ARM.exidx issue means that main [so: 15] after the LLVM 19 update is simply broken for armv7, at least for kernels, even with a kernel avoiding the VM_MEMATTR_SO issue. > I'm not sure if I have enough free cycles to manage both issues on the = llvm side... But you have already taken the analysis far beyond what I was going to be able to figure out. The major reason I still have armv7 active in my environment is to notice when some of these sorts of oddities show up in my simple context and to report some evidence about them when they happen: some earlier reporting. So, my armv7 context is not really broken by being broken. It is serving its purpose. I'll just leave the boot media as-is for the world (so: pre-LLVM19) until I have a (then) modern kernel that again works. I've got older kernels that work for this context that I'll keep around for now as well. [I've dropped Doug and Kyle from the CC based on your analysis.] Thanks, Mark =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun Nov 10 20:22:57 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 4XmkdY4LYDz5cCfm for ; Sun, 10 Nov 2024 20:23:13 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-55.consmr.mail.gq1.yahoo.com (sonic308-55.consmr.mail.gq1.yahoo.com [98.137.68.31]) (using TLSv1.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 4XmkdW6d7tz4WZR for ; Sun, 10 Nov 2024 20:23:11 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=DKDokpCe; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1731270189; bh=MWSLkfBsNGKQsUP2zIpg+NYLxCmQks2WsyI4WUe1G1c=; h=From:Subject:Date:Cc:To:References:From:Subject:Reply-To; b=DKDokpCenE35Diwpigtdu3nAd3qXXgWcIxL+TN5R1Zr2nAyT+FhbheThhAxV74b+0oTkr4VbyUewsq2k3k3Q8D371QoIL8gd+3JU2Lzdq2kec+wuGXXyBUU63Y8EhW74TnLuewz0VLlXeBtrbg7qbg5rErQFbJMpYwH0Eh5/E1KlFifu2NwDvfpDWyJuDpfT5AVQo5JJ6D5A8jAqfujpctjGJIB2lXcksn01zmE0dUP2YA6jk4u7i8/+i7d3w+/Z15YYZW6tNEJDuqvYrEGoc8vysy6SuqOdRvb3KVpbq8NocjJuj8KT2y6ISKaOeXv2det9CfG3r0ks4ftxliKClg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1731270189; bh=NVVy0q/mb6KnHwLxQQYl1tGf/MytH/Q3UPVYNiA/uTJ=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=ZvaI3m2zHldzRfJ2PEBcBD4alO2GSHGhQrQeZFZvg0z7mRqzxH5MrfgftI6CtxpIrCsLE8+C8j9B/MDiTmbSjsRTt7Kepg7kJ64hg/1zLtgMPRFk/rj2AzfiQrszSYOxYOevrzczvp2y7jdgRvoGh6D2MpLcHhlMvkF6i7Oimppex3Mh+S9mfpheVeWMzLg0aWQMaPvEqKk6WdYmMqKfAF5l9Zhc5DLMAduoBsfyC+uvR84+4puO8IkdxN8jkoYTWquF9XVeqarj2eIoz3yJSSr0rnbXVCNpfWDCwGs1RPOE0Q5AKVKYq29+oe48mrGkIev5fUF8aMV2ewovb2W06Q== X-YMail-OSG: XYedeZsVM1mVkEU8f0vxplTfTJzoh_aE.RCHXAWUfICl9boDOlODpqZmGiQDvXr aiaKkNQPpZOc88SJAMB7WjlChQouZgOqeAPaByO.7RFyRoT4qTawa0IWZvbRRaKKhXI4Z9SyGFNq XHL6JBLnbe8G4.8LkneMWOAq0sRVOMttyVggMjrwE57MUy2I4g5ZOwOrxD0r2jraDWYx9GzSi_GD W3.4IbQMJhnMstNgc6rguOm5_yhmEa3oPVE.pKF7_uGVPuQk_U5N8_at855YOYAOHfkgh0nqNlrD 6XElbywCYrW.g_vfKDmM4nkQxx6tWXs0LdtjS7hwkzEH_QN5CbPo9Gwdp3u7wivC5Ifu2x3Ty4uY ABfWSzw2DK5hCbOmzuZua9ibwlE7jInTjUqG6DctUxrJ9sVl70ER0N_JthZFFSQtARFCFw65LhNV z5s36XKj38oE4_30gR_KxrNSTGDQGO0PDUXQ5QL3_go7MRSjgQUf_293NZA7XswZWZ_Xg_mLPhsL 7JyzAovXBz55ium2Rb7IyM1soT275EMgqMuUuzb1f.WW2c8u2F8ILQce1MvCfvDGjUQh.Q1QuZk_ Ip.Bfp9aisOwao64Srs2V61VQquoZs94t4CJwALt0qQZIkszT.Ks3O5FEP2j3nCxtofyydg1wlgA yV_q2ew00_UyI70AfheGMPJK.NyMxyCU4xVi1S1tqwLgqKT2RYtPcnxMZAst4RJGfBIGkmp9d7vR .miNjWMMbt4jvxfjZv2wnUfrZykZQsdFJPMdDdP0p2.d7hmiqrman7wnImtt7d0WatQSFHDFQyCN 5bE5Q7S.eIfn1d5WU37JHjzEcONni9vhWUf14X5l.rom4JlJcL4sh4fLpYifxw.6WuHKuV3CAZ2x HNSwSdxgEx.tlOgzC92mUPIw9j7QPJcfCMUzXsIgRFh1ys6FwYrxBQFJMGJW.N3dbMy.BfhRqA7t HOGMw27zj2ALe1T_8GfspPtldBdoI9TlUucJ1nQcyNL4_hEUwOrCWmp4RHJ8hqsjqN_Xe8i2BN4_ .PR24czzM_51Rma00OLVRKV2CgJQJvF.bP._MT3MHu0Lx.bCBZIr6GVr48vnOfIEeYVgtJXpmwUj fEzhnJFfXStZFPJPr7F20jJXQMHp24DACIGpvlW8WcKndkfPfXNa8DOxMJxpmSVeRQ9iClACBa4p 2QmCmN1_PQL6hXTI5DtriCdbxxeStMCooRsSks9onJu_Z5dSplKILTlRF2CEBYt_xtX9ciN3fNIg qOYRxVCGSXzsiEjhCV41VYurLPnJ7sYFqKgLUu8dhPNauPpjl7EFd9a7Vq.g1HpIEL4pf4UZ.IgH qj7xgH22LOChiPrfk3hxkLT5kd_ADIoEdvqX2hnSRJjvQgVbrU0.0DW6xpyhPz1RP3g8YkQicsH3 M_svs5dTPLQW4_TYqnP_wQ2A.K66tczNtGspg3PKJ0DbN3SiEdGc_Zj3fiBW_mU0DurC1nxX5Jc5 rGxZU33VGpPakomEOK9DoG2pdIzSf7F70Zp6AklrxNSOPukcKIUB4DFMSdXFXa6Idoh7axj2.PY5 bcuqkCla1FNDGsv8hyjanggk1uGhFijMPXTyt4xPjvxoBioDEp0g88D_tna4SmMpx7YkVo7Fft5T 7ErObCvhOWmr1B5LEAeSO8Of1vbFE25AI5bH3aQa6vcYy905hEYT33r.hTW_ZJu79KZDq4HSGzqo y6.KsIRJrxT6W5uAkBZ4MdYsrlbMVxEd41MLo6FlCUsJ50m6qc6dl.48C5LFkVzYjlvgf2WkKEaq O57YRAVMHIEMFFf00qLsT9d2Ukl85nR3m4H1xnkUn3NZTa4NS6ToRJrjRmGroFDQhBYzMAjSKUlb uqPZJ5B5my8icRxOlpf3Yil9Cz6j0_Q8GRiY7uKSnJMivn22ogba_9D0pFe.7p5WgrKBCHv9mW7j k3jwFmNwqJXN4scMMViO5idEycMTgII.VRszeQAJ6CcbqEwZWE7Vimx9PtHW6JcSS_bMrKgbHlIQ ngLsDJ_BPxSPOxmswG22WD_kzKQSzg7XvPZ88mKyG5PrFEyqQmNBEXXs8dIZMiNHcSEnOlh4XPPa EVnNrZ96ekI8cHj3T03qabFekTLVfeAtjcpj1D1sc_WLBfHyl_Z5D2CJM_SSMdIIipO4EmdG0Tg0 sn6NO_kmaj6eqYHXl6jjUI8dfV2bVv_bn5.4BxqmDEWbnGQX0fAyDOe8i3IoRdb8Z10z99rcTrku IWewdRiFyHset00wuD0b24D7qVaSPezCoZIQ.yg6C5sY8GCyCziQUPDiAO08yCGiZvczxwo3Gaz0 XF89Bzn68A2vHWbE- X-Sonic-MF: X-Sonic-ID: 5277974d-fc01-4119-9fbd-d8f5eb5c43c9 Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Sun, 10 Nov 2024 20:23:09 +0000 Received: by hermes--production-gq1-5dd4b47f46-qfm2r (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID f9f6c9021863f87c751ad60e9fdc089f; Sun, 10 Nov 2024 20:23:08 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51\)) Subject: "man loader.efi" and comconsole vs. eficom for aarch64 for 14.* and later Message-Id: <3D054DF2-843C-4270-8EE5-38534C873B50@yahoo.com> Date: Sun, 10 Nov 2024 12:22:57 -0800 Cc: Warner Losh To: Current FreeBSD , FreeBSD-STABLE Mailing List X-Mailer: Apple Mail (2.3776.700.51) References: <3D054DF2-843C-4270-8EE5-38534C873B50.ref@yahoo.com> X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; DKIM_TRACE(0.00)[yahoo.com:+]; TO_DN_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_THREE(0.00)[3]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.31:from]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.31:from] X-Rspamd-Queue-Id: 4XmkdW6d7tz4WZR X-Spamd-Bar: --- # man -K comconsole /usr/share/man/man8/loader.8.gz: console variable, or set it to = serial console (=E2=80=9Ccomconsole=E2=80=9D) if the /usr/share/man/man8/loader.efi.8.gz: work) and =E2=80=9Ccomconsole=E2=80= =9D for the serial on COM1 at the default baud rate. /usr/share/man/man8/loader.efi.8.gz: =E2=80=9Ccomconsole=E2=80=9D. = The default port is COM1 with an I/O address of 0x3f8. /usr/share/man/man8/loader.efi.8.gz: comconsole_port is used to set = this to a different port address. /usr/share/man/man8/loader.efi.8.gz: comconsole_speed is used to set = the of the serial port (the default is /usr/share/man/man8/loader.efi.8.gz: 9600). If you have console set = to =E2=80=9Cefi,comconsole=E2=80=9D you will get output /usr/share/man/man8/loader_4th.8.gz: console variable, or set it to = serial console (=E2=80=9Ccomconsole=E2=80=9D) if the /usr/share/man/man8/loader_lua.8.gz: console variable, or sets it to = serial console (=E2=80=9Ccomconsole=E2=80=9D) if the /usr/share/man/man8/loader_simp.8.gz: console variable, or set it to = serial console (=E2=80=9Ccomconsole=E2=80=9D) if the /usr/share/man/man5/loader.conf.5.gz: console = (=E2=80=9Cvidconsole=E2=80=9D) =E2=80=9Ccomconsole=E2=80=9D selects = serial console, # man -K eficom # Note: The above is for both main and stable/14 . No mention of eficom or in what types of contexts it should be used vs. not. But: #if defined(__aarch64__) && __FreeBSD_version < 1500000 static void comc_probe_compat(struct console *sc) { comc_probe(&eficom); if (eficom.c_flags & (C_PRESENTIN | C_PRESENTOUT)) { printf("comconsole: comconsole device name is = deprecated, switch to eficom\n"); } /* * Note: We leave the present bits unset in sc to avoid = ghosting. */ } #endif There are other places with the documentation issue, for example https://wiki.freebsd.org/HyperV references: QUOTE Enable the serial in the VM. Below is the example of FreeBSD VM. =E2=80=A2 echo 'console=3D"comconsole"' >> /boot/loader.conf END QUOTE I got into this from trying to get a Windows Dev Kit 2023 running Windows Pro 11 Hyper-V to be operational for running FreeBSD. Its output stops after the mask line for the efi buffer reporting. (Hyper-V indicates 12% cpu usage. 1 core of 8 busy?) I was looking for any extra instructions that I'd not previously found. (I had remembered that eficom activity had happened --but not all the detail.) =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun Nov 10 22:21:17 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 4XmnG3148Xz5cM7s for ; Sun, 10 Nov 2024 22:21:31 +0000 (UTC) (envelope-from joh.hendriks@gmail.com) Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4XmnG23BzWz4l8K; Sun, 10 Nov 2024 22:21:30 +0000 (UTC) (envelope-from joh.hendriks@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b="EK/ooC4V"; spf=pass (mx1.freebsd.org: domain of joh.hendriks@gmail.com designates 2607:f8b0:4864:20::102f as permitted sender) smtp.mailfrom=joh.hendriks@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-pj1-x102f.google.com with SMTP id 98e67ed59e1d1-2e2e88cb0bbso2968094a91.3; Sun, 10 Nov 2024 14:21:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1731277289; x=1731882089; 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=ZtZjYHeYxm620yq16DJ430SVhPFsVM+3Jkh5tat9wBA=; b=EK/ooC4VMwxFVz8TYYnVy96PsqFqY6c7hreipO3kT1BmyGjJZQ9fOVo5RX4FS9EkM3 xSqRnFTFnMjabMYgfR3wKEAZuwgIjAb+v9YUQCSeVoOKiiFkvJuwshwSPiBv+UmHwuVP thL0AqudSbbXc+g6/mMOzPsj+XpItC1QqzSh4nnVeyJdIHESPvq1Z+wx1H1SfFdAOKqN bnA6d/opZ3fdjlJPrw8JpjZ3UxgqNcpgyrvuEiUS1Cj0/EEejp0fGqoLUtKIw6qJjHv1 kJ72KzPSzwZ0VKUdvjzjYwESQ2pwtWJfJOnMMAeRXlhve9MAKCYSr6s7g6ML4Ku8bAT/ +UrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731277289; x=1731882089; 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=ZtZjYHeYxm620yq16DJ430SVhPFsVM+3Jkh5tat9wBA=; b=SPPjHgQlT265V5RKNqIq4fCL+lDBgrODKOoPGIFzZpYoh/KG4mlkN0/pHsy/Sh2vbn nj0XjD00zhzaFv8Z0RjkEiW+zryCzEnrz86SvoeBRWhZ+Qyb8UPCNpmt9zPeTK4q9SFx xc5oF0+FhON9ap+PY7z8+Lq0fI4Q1UtbtruNjmFjOJnsKI3jPB/5eFvthuoXI0JYwkRX Ug4G7lj6NBCilppUwWhuNxLHGEweuclsBJ+lCxrA1kkUbNah6zh8c8Frpu+Hp+UpEOLJ 9e4MHaIfqcTB/fF+Eb/XMDWCxfTqJ7bCzUQLzhRSSz8aAiao7OJ6u5WpbQAW0HlkFb4r JDJA== X-Forwarded-Encrypted: i=1; AJvYcCVXCIdSnajV6vSEclzAI935mG5kr1hWM4YrMBxED6DRwgRbjt1wBf81eWsXTud76z89n/iu9IDR23HSrBKJhXc=@freebsd.org X-Gm-Message-State: AOJu0Yxiscjn8O+Jz9R5WJy5Q4sdL6jhYh+rgEZKXF61BL9qoNiOXBTF UNUv2HKylefOOb7Pjns5DcEWyYEVHP1JdlHzPXWL/4lq2N/GQNPSMI9cuXzmK02bhR0oGcqC+Sd nWGcbdS1vaTeBb//eNilmXVXxlGroYg== X-Google-Smtp-Source: AGHT+IHSl3SWlXKSQSgmKZUEZC03u8I1tU98UEJ+PayFA4hYPwYeGnbI41wKCZ018MwGa4x/pa4UrjFxokZ9ZgntYXc= X-Received: by 2002:a17:90b:17c8:b0:2e7:8593:8365 with SMTP id 98e67ed59e1d1-2e9b16f05e9mr14150900a91.5.1731277288731; Sun, 10 Nov 2024 14:21:28 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: <1568966692.4590.1730895354064@localhost> <97788ab0-db70-4413-8b18-f9d95f1d120f@gmail.com> <982644351.5078.1730980565800@localhost> <2016215695.9786.1730993474125@localhost> <1498094c-b287-49a0-ad02-e7d517c5d01e@freebsd.org> <553294a3-fa7f-4ee1-a16a-0594fb5e7bb5@freebsd.org> In-Reply-To: <553294a3-fa7f-4ee1-a16a-0594fb5e7bb5@freebsd.org> From: Johan Hendriks Date: Sun, 10 Nov 2024 23:21:17 +0100 Message-ID: Subject: Re: BRT copying feature To: Craig Leres Cc: Ronald Klop , FreeBSD Current Content-Type: multipart/alternative; boundary="000000000000cd7ff50626966766" X-Spamd-Result: default: False [-3.99 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-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:c]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TAGGED_FROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_FROM(0.00)[gmail.com]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::102f:from]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-Rspamd-Queue-Id: 4XmnG23BzWz4l8K X-Spamd-Bar: --- --000000000000cd7ff50626966766 Content-Type: text/plain; charset="UTF-8" I just tried the patch and it works. I think this is a nice addition to the FreeBSD installer. regards, Johan Hendriks Op do 7 nov 2024 om 22:45 schreef Craig Leres : > (Forgot to include screen grabs) > --000000000000cd7ff50626966766 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I just tried the patch and it works. I think thi= s is a nice addition to the FreeBSD installer.

regards,
Johan Hendriks

Op do 7 nov 2024 om 22:45 schreef Craig Leres <leres@freebsd.org>:
(Forgot to include screen grabs= )
--000000000000cd7ff50626966766--